1. IRT 2102 release notes

  1. [Testing Tool, PRO] Added an option irt.testing.pro.delay-after-updating-special-testing-scenarios to define timeout (in milliseconds) to wait after test case running if at least one special testing scenario was updated.

  2. [Testing Tool, CPI] Allowed custom Accept, Accept-language, Accept-encoding headers during CPI message sending.

  3. [Common] Fixed a minor security vulnerability.

Patches

2102.1

  1. [DevOps] Added email notifications sent to ticket reviewers when all transports from the ticket are in WAITING_FOR_APPROVAL status and email notifications sent to the ticket creator and assignee when all transports have IN_PROGRESS or DECLINED statuses.

  2. [DevOps] Added a possibility not to allow transport creator to approve created transports. The feature is configured by Transport creator can approve own transports option on Application page. If it’s enabled, then transports can be approved by all users in reviewers list. If it’s disabled, then transports can be approved by user if he is in reviewers list and he is not a transport creator.

  3. [Change Management, CPI] Added a possibility to download and compare message mappings.

  4. [Common] Added the new bootstrap parameter irt.smtp.starttls.enable (default value false), it must be set to true to get STARTTLS working.

  5. [Audit] Added audit logging of user logout (AUTHENTICATION event type).

  6. [Audit] Added audit logging of unsuccessful user login (AUTHENTICATION event type).

  7. [Audit] Added audit logging of roles update (USER_MANAGEMENT event type).

  8. [Audit] Added audit logging of user creation (USER_MANAGEMENT event type).

  9. [FIX, Testing Tool, CPI] Fixed a bug when message properties were compared incorrectly when iflow had message header and exchange property with the same lowercased name.

  10. [FIX, Testing Tool, PRO] Fixed a bug for SAP Log module and PI message log when polling didn’t work for sender agreements without EDI splitter which had message or recipient split at the wildcard ICO side.

  11. [FIX, Common] Fixed a bug when emails weren’t sent when SMTP username was configured as an email.

  12. [FIX, UI] Fixed a bug when Active user checkbox wasn’t shown in Edit User dialog box.

Notes for upgrade from 2101 to 2102

  1. Previous configuration in IRT hasn’t been affected.

IRT 2101 release notes

  1. [Common] Added optional integration with SSO provider (only Open ID Connect protocol is supported).

  2. [Change Management, PRO] Added a possibility to download and compare message mappings.

  3. [Change Management, DevOps, API Mgmt] Added support of Key Value Maps. Only KVMs with lifecycle information are synchronized. Only non encrypted KVMs are added to git repository. If KVM is encrypted, you will see only stub on UI on transport configuration page. If transport configuration for encrypted KVM has a blank value for some landscape items, then transport will have invalid status.

  4. [Change Management, API Hub] Added a possibility to compare files in OpenAPI (Swagger specification v.3) format.

  5. [DevOps, API Mgmt] Added a possibility to configure transport configuration for API proxies and Key Value Maps.

  6. [DevOps, CPI] Added a possibility to transport only iflow configuration.

  7. [Audit] Added audit logging of successful user login (AUTHENTICATION event type).

  8. [Support Tool] Improved Support Tool external integrations:

    1. added Don’t send notifications automatically flag on Rule page to define whether notifications should be sent automatically or not;

    2. set default value to 60 for Don’t send similar notifications for (min) property on Rule page.

  9. [FIX, Testing Tool, UI] Fixed a bug when Recording Configuration dialog wasn’t opened from Recording Requests tab of Integration Object page.

  10. [FIX, Testing Tool, UI] Fixed a bug when payloads with the same names couldn’t be attached to loaders after rows deletion and recreation on the manual test case creation page.

Notes for upgrade from 2.15 to 2101

  1. Previous configuration in IRT hasn’t been affected.

  2. It’s required to process reinitialization operation on Agents page for CPI and API Management agents with configured Git integration. Then, if automatic update of build.gradle, settings.gradle is not configured, copy the content of updated templates build-irt.gradle and settings-irt.gradle to these files manually. Also, copy new parameters from gradle-irt.properties to your gradle.properties.

2. Versioning concept

Since 2101 release the following versioning concept is applied:

<global version number>.<patch version number>

Where

  • <global version number> - is a release date, has YYMM format where YY is year and MM is month.

  • <patch version number> - includes bugfix or minor updates of global version number.

3. Key concepts of the tool and what it can do

Initially IRT was designed as a tool for regression testing of SAP PRO (Process Orchestration) scenarios. The idea and the main process in the tool initially was quite simple:

  1. Configure SAP PRO system(s) connection settings.

  2. Select a needed object (e.g. an Integrated Configuration).

  3. Record a several groups of messages on that scenario (or manually prepares them for uploading). A group of messages is a set of messages which is associated with one scenario run, it contains one inbound message and one or more outbound messages. At that time the recording process worked only through additional EJB component (Agent Module). That integration approach is supported in the actual IRT version as well. Agent module is added to the communication channel’s modules chain and intercepts target messages.

  4. Create a regression test case with previously prepared messages. We use the term regression because the main goal of the current test case type is to check that scenario responds each time in the same way if we send one set of inbound messages several times.

  5. Run a regression test case on a linked test scenario (user selects it during test case creation). During that step application takes all inbound messages from the test case and sends them to SAP PRO system through special XI 3.0 sender channel. Then outbound testing results are intercepted by Agent Module and sent asynchronously (through JMS) to IRT application, where they are compared with outbound messages from the test case (expected messages).

  6. Finally user can see the testing results, browse message differences on UI and/or download excel report which includes full info about the test run.

That flow is simple, but it covers quite small amount of use cases. For the last years we have been resolving many issues and implemented a lot of features. Here are some of them:

  1. Issues related to connectivity with SAP systems:

    • JMS engine on PRO system has a limitation of a payload size (around 10Mb), so, it’s not enough to have only JMS integration. As a result, IRT supports polling of messages from Agent Module database as well.

    • Sometimes it’s not possible to require Agent Module installation. As a result, IRT supports two noninvasive integrations with SAP PRO system (both are implemented through polling of messages):

      • PI Message Log (looks for BI and AM logged message stages),

      • Sap Log Module (similar to IRT Agent Module, standard localejbs/AF_Modules/MessageLoggerBean is added to the channel’s modules chain with specific identifier irtLogStage<number>, then IRT looks for messages using these stage identifiers).

  2. Features related to testing use cases:

    • Possibility to test and compare the whole set of messages, not only outbound messages. As a result, IRT has an additional type of test cases: baseline. When you run a baseline test case, IRT doesn’t send any inbound messages to the test system, it creates a recording request linked with the test run instead. Then it records target messages in the same way as a standard recording. Finally, recorded messages are saved as the testing results and compared with all expected messages from the test case (inbound and outbound).

    • Possibility to group several test cases and work with that group as a single unit. IRT has an object titled Test suite, it’s an aggregation of several test cases with the following functionality:

      • run all included test cases in the context of the one test suite run,

      • get report which contains entries about all test cases included to the test suite,

      • schedule test suite runs using internal cron jobs,

      • schedule email notification about test runs finished with errors (report is sent by email).

    • Possibility to track changes and store versions of objects from target SAP system (ICOs, Sender/Receiver agreements, Communication channels, etc.). When you test your integration scenarios, you usually test their changes, and you want to verify that the change is correct and scenario works as expected. Tracking object changes in IRT was developed as the primary part of functionality to support that use case in the easiest and automated way.

    • SAP Cloud Platform Integration support in addition to SAP Process Orchestration systems.

    • Extended alerting functionality and error tracking. IRT can listen to consumer alerts on PRO systems and check for integration flow errors on CPI platform.

    • Testing of scenario transports. Once you import changes into your test/QA environment you want to be able to validate it is correct. With the use of IRT you can run the same test on your QA system. IRT allows you to take the same test and run them on QA system. You can either do the test manually or you can trigger the test running with some REST calls to the IRT system. You will then need to integrate it within your CHARM system.

    • Documentation of whole scenario development and testing process. As developers, we are looking for a way to make it easier to document what we have developed. But we still want some traceability to understand what was changed and the reason for the change. To achieve it we need an automated approach that allows us to track everything we have worked on. Documentation sitting in Word is hopelessly old and will never get updated, so you would never care about checking it.

So, now Integration Regression Tool is not only about regression testing of integration scenarios. The testing engine is a core part of it. You can request the most suitable license for your business cases and combine functionality of three main parts of IRT:

  • testing tool,

  • change tracking tool,

  • support tool.

All these three parts give a comprehensive way to handle development and testing issues on SAP PRO/CPI platforms.

4. Requirements

Figaf IRT can be run on a local machine or a real server. Required setup is viewed in the following table:

Local machine Real server

OS

Linux, Windows 8.1/10

Java version

Java 8/11

Server configs

RAM: minimum 2GB free memory

RAM: minimum 8GB (recommended 16GB). CPUs depend on the number of tests and frequency to be performed.

Database

PostgreSQL, Oracle, MSSQL, DB2, or H2.

PostgreSQL, Oracle, MSSQL, DB2, or H2. If you run Figaf IRT in a Hyperscaler (AWS, Google, Azure), it is recommended to use the managed PostgreSQL database services.

SSL

-

Certificate can be installed on the server to encrypt communication.

Figaf IRT works with the following agent components:

  • SAP PI/PRO 7.31, 7.4, and 7.5.

  • SAP CPI.

  • API Management.

5. Installation

You can also learn how to install and configure IRT by watching videos in the course.

Application components:

You can download application component from the following page: https://irt.figaf.com/download

  • irt-<version>.jar - IRT web application.

  • irt-agent-<version>.sca - (optional, only for PRO systems) this is the Agent Module. Install it on all SAP PI/PO systems where you are going to use IRT Agent Module integration type. It’s not required because you can choose PI Message Log or SAP Log Module integration types.

To get the latest update about new functionality be sure to sign up to https://figaf.com/irt.

5.1. Agent component deployment and configuration (optional, only for PRO systems)

  1. Deploy Agent component on your development system. It can be done with NetWeaver Developer Studio or your favorite deployment tool. For the first integration it is easier just to test on one system, you can always add more systems later.

  2. Create new user:

    1. Open UMEAdminApp(/useradmin) and import users (your user should have Administrator role in the UME).

    2. Then select Overwrite Existing Data checkbox.

    3. Put the configuration below into the text area and click upload button (this step should be done on both (Agent and Test) systems). The configuration depends on the IRT tools you are going to work with:

      1. Testing Tool needs user to have SAP_XI_API_DEVELOP_J2EE (to have read/write permissions in the integration directory), SAP_XI_MONITOR_J2EE (to use AdapterMessageMonitoring WS API for fetching payloads that required for SAP Log Module integration), IRTAgent (it is created during deployment of agent component), and custom role (to send messages through created XI channel) with the following action:

        action for custome role

        Custom role example:

        [role]
        rid=SOAP_XI_SENDER
        action=ACTN.AUTH_DS.un:L$sap.com/com.sap.aii.adapter.soap.app$xi_adapter_soap_message

        Example of user to work with Testing Tool:

        [User]
        uid=IRTAGENTUser
        last_name=IRTAGENTUser
        accessibility=0
        role=SAP_XI_API_DEVELOP_J2EE;SAP_XI_MONITOR_J2EE;SOAP_XI_SENDER;IRTAgent;
      2. Operations needs user to have SAP_XI_ALERT_CONSUMER (used by Support Tool) and IRTAgent (it is created during deployment of agent component):

        [User]
        uid=IRTAGENTUser
        last_name=IRTAGENTUser
        accessibility=0
        role=SAP_XI_ALERT_CONSUMER;IRTAgent;
      3. DevOps needs user to have SAP_XI_ADMINISTRATOR_JEE (required for transports) and IRTAgent (it is created during deployment of agent component):

        [User]
        uid=IRTAGENTUser
        last_name=IRTAGENTUser
        accessibility=0
        role=SAP_XI_ADMINISTRATOR_JEE;IRTAgent;

      If you want to work with Testing Tool, Operations, and DevOps IRT tools, create user with SAP_XI_API_DEVELOP_J2EE, SAP_XI_ADMINISTRATOR_J2EE, SAP_XI_ALERT_CONSUMER, and IRTAgent (it is created during deployment of agent component) roles:

      [User]
      uid=IRTAGENTUser
      last_name=IRTAGENTUser
      accessibility=0
      role=SAP_XI_API_DEVELOP_J2EE;SAP_XI_ADMINISTRATOR_J2EE;SAP_XI_ALERT_CONSUMER;IRTAgent;
  3. Change security policy to the “Technical user” and configure passwords for created user.

  4. Open NetWeaver Administrator (/nwa), then tabs SOA → Application and Scenario Communication → Single Service Administration

    3 1 2

    Type "irt" in the search field and click "Go". Enable authentication by User ID/Password for each IRT web service (see the screenshot below):

    3 1 3

5.2. SAP PRO system user roles configuration (integration without Agent component)

You can configure connection with SAP systems by entering your user credentials (or some another available user). Be sure that the user has roles depending on the IRT tools you are going to work with:

  1. Testing Tool: SAP_XI_API_DEVELOP_J2EE (to have read/write permissions in the integration directory), SAP_XI_MONITOR_J2EE (to use AdapterMessageMonitoring WS API for fetching payloads that required for SAP Log Module integration), and custom role (to send messages through created XI channel) with the following action:

    action for custome role

    Custom role example:

    [role]
    rid=SOAP_XI_SENDER
    action=ACTN.AUTH_DS.un:L$sap.com/com.sap.aii.adapter.soap.app$xi_adapter_soap_message
  2. Operations: SAP_XI_ALERT_CONSUMER (used by Support Tool).

  3. DevOps: SAP_XI_ADMINISTRATOR_JEE (required for transports).

If you want to work with Testing Tool, Operations, and DevOps IRT tools, user should have SAP_XI_API_DEVELOP_J2EE, SAP_XI_ADMINISTRATOR_J2EE, and SAP_XI_ALERT_CONSUMER roles.

If UME authorization is enabled, you should also add a XiMdt.ExtendedMonitor role, otherwise it won’t be possible to load message payloads through AdapterMessageMonitoring web service. It affects Support Tool and Testing Tool functioinality if noninvasive integration types (without Agent component) are used.

5.3. IRT Application running

  1. Prepare database for IRT application. By default, H2 database will be used (database dir: <user_home_dir>/FigafIRT/irt-db), skip that step if you are not going to use another database system. For now, you are able to use 5 database systems: H2, Oracle, PostgreSQL, DB2, MS SQL. You should configure databases, schemas and user which will be used by IRT:

    • For Oracle and DB2 configure database with schema: IRT.

    • For PostgreSQL, MS SQL Server configure database with schema irt.

      Database table names must be case insensitive in the queries. Be sure that collation parameter is configured properly.
  2. Download the Jar file.

  3. To start the server open a command prompt (Win + R → type cmd → Press enter).

  4. In the command prompt navigate to the folder where you have saved the IRT application (cd <path>).

  5. Run the application with java <proxySettings> <trustStoreType VM option> <libs path property> -jar <irt jar name>.jar <application properties> (see examples). Where:

    • <proxySettings> is a VM parameters that define proxies, e.g. -Dhttp.proxyHost=<host>, -Dhttp.proxyPort=<port>, -Dhttps.proxyHost=<host>, -Dhttps.proxyPort=<port>. You can find more parameters here.

    • <trustStoreType VM option> is a VM parameter -Djavax.net.ssl.trustStoreType=Windows-ROOT - it must be set if you are going to use HTTPS protocol to communicate with SAP system,

    • <libs path property> is a VM parameter -Dloader.path=<path to libs folder>. It must be set:

      • if you use PostgreSQL, Oracle, DB2, or MS SQL Server database, you should put corresponding JDBC driver in libs folder.

      • if you use PRO Agents and want to work with DevOps, additional SAP PRO client libraries com.sap.aii.utilxi.core.jar, com.sap.xpi.ib.core.jar, and sap.com~tc~bl~guidgenerator~impl.jar (see requierements) must be available in runtime classpath and put in libs folder.

      • if you use dual stack PRO Agents, you should put additional libraries sapjco3.dll and sapjco3.jar (can be downloaded here) to libs folder.

    • <application properties> is a list of additional settings. Syntax: --<property name>=<value>. Available properties:

      • server.port - IRT application port, by default 8089

      • irt.db.type - database type which will be used by application. Possible values: h2 (default), postgresql, oracle, db2, mssql.

      • irt.db.host - database host name, required for PostgreSQL, Oracle, DB2 and MS SQL Server

      • irt.db.port - database port, required for PostgreSQL, Oracle, DB2 and MS SQL Server

      • irt.db.name - database name, required for PostgreSQL, Oracle, DB2 and MS SQL Server

      • irt.db.username - database user, required for PostgreSQL, Oracle, DB2 and MS SQL Server

      • irt.db.password - database password, required for PostgreSQL, Oracle, DB2 and MS SQL Server

      • irt.url - host url, by default http://localhost:8089. Notice that application context path /irt shouldn’t be defined here.

      • irt.testing-tool.xi-sender.ignored-modules - modules that will not be moved to Specific infrastructure scenario during testing with sender modules (see Decide to test with/without sender modules automatically option on Integration Object Details page for more details). Modules should be divided by ,, for example: --irt.testing-tool.xi-sender.ignored-modules=module_name1,module_name2.

      • irt.cloud-connector.url - the URL from the CPI to IRT. Usage: --irt.cloud-connector.url=http://<HOSTFROMCPI>:<PORT>/irt/api/cpi-testing-mock-data/step/. This property is used during testing with mock data on CPI systems.

      • irt.cloud-connector.locationId - the location of the cloud connector. Usage: --irt.cloud-connector.locationId=<YOURLOCATION>. This property is used during testing with mock data on CPI systems.

      • irt.config.ticket-id-prefix - prefix of generated ticket id, by default ISSUE.

      • irt.config.transport-id-prefix - prefix of generated transport id, by default TRANSPORT.

      • irt.config.exclude-package-prefixes - prefixes of packages which will be ignored during synchronization. Use package IDs separated by ,. Example --irt.config.exclude-package-prefixes=ZFigaf,Zqa.

      • irt.testing.start-polling-messages-automatically - whether polling is started automatically after all messages have been sent to CPI system or not. Default value is true.

      • irt.testing.pro.disable-correlation-id-lookup - an option to skip lookup by correlation id in the message monitoring client. Use this option if request with a defined correlation id filter on system fails with timeout in a few minutes. Default value is false.

      • irt.testing.pro.delay-after-updating-special-testing-scenarios defines timeout (in milliseconds) to wait after test case running if at least one special testing scenario was updated. This option helps you to avoid SENT_WITH_ERROR issue when XI integration object is not available yet after the update during test case running. Default value is 0.

      • irt.smtp.starttls.enable enables STARTTLS. Default value is false. Set it to true to get STARTTLS working.

      • irt.demo-logon enables auto logon for default root administrator (username: superUser, password: default) if there is only one user and its password hasn’t been changed. Default value is false, enabled only if irt.logon-mode parameter is equal to LOCAL_USERS or MIXED_MODE.

      • irt.logon-mode defines allowed type(s) of login. Available values are:

        • LOCAL_USERS (default) - login for users registered in IRT application.

        • SSO_USERS - login only with SSO account. Authentication and authorization are handled by Identity Server Provider. See this example with SSO configuration.

        • MIXED_MODE - login for both types of users: SSO and default root administrator (username: superUser, password: default). Authentication is handled by Identity Server Provider and authorization is handled by IRT. IRTUser role is assigned to user during the first login with SSO account. See this example with SSO configuration.

      • irt.sso.logout.url is a url where user will be redirected from logout page, when IRT logout completes successfully. For Microsoft installation it’s https://login.microsoftonline.com/common/oauth2/v2.0/logout.

      • irt.sso.logout.callback-url-param-name is a parameter that sets name of callback url that will be passed to Identities provider logout url. For case when Microsoft is used as Identity Service Provider value should be post_logout_redirect_uri.

      • irt.sso.logout.callback-url is a url address of local IRT installation.

      • irt.sso.claims-mapping contains rules for mapping fields received from Identity Server Provider. It configures which parameter from received claims will be used for finding out user information, roles information, etc. In the example, property preferred_username will be used as a source of username information.

        Sometimes displayName property is a concatenation for several properties, so for the display name it’s possible to specify a several properties separated by ,, and IRT will concatenate fields, received from Identity Server Provider.

      • irt.sso.custom-properties - properties set as key values pair that will be added as query parameters to the authentication request to auth server. In the example, request to authorization server will contain following data http://auth-server/tokens…<main_sso_params_here>&customParam1Name=customParam1Value

      • cluster.configuration.discovery-type - discovery type for clusterization configuration, possible values: TCP_IP and MULTICAST. By default TCP_IP. If parameter is defined but has wrong value, MULTICAST type will be applied.

      • cluster.configuration.members - list of domain names or IP addresses divided by semicolon which will be used in the lookup and form a cluster for IRT application, by default localhost. Used only if TCP_IP discovery type is applied.

      • cluster.configuration.port - hazelcast initial port in the range, by default 5701.

      • cluster.configuration.port-count - hazelcast port range for current cluster, by default 20. This means, that ${cluster.configuration.port-count} ports starting from ${cluster.configuration.port} will be checked in the lookup during determination of cluster nodes.

      • server.ssl.keyStoreType - required for HTTPS configuration, key store type, e.g., PKCS12.

      • server.ssl.key-store - required for HTTPS configuration, key store file path, e.g., keystore.p12.

      • server.ssl.key-store-password - required for HTTPS configuration, key store password, e.g., 123456.

      • server.ssl.keyAlias - required for HTTPS configuration, key alias, e.g., IRT.

    If an application property has some special characters, you need to wrap its value by quotes.

  6. After it boots up you can access the application using http://localhost:8089/irt:

    login form
  7. To login use default root administrator credentials (username: superUser, password: default). Enter these values and click Log In.

    The root administrator has full access to application because it has both roles IRTSuperUser and IRTAdmin. You can learn more about user management and permissions here.

  8. After login you will see home page:

    home page

Examples

If you use Java 11, we recommend to run IRT with additional jwm args:

--add-modules=java.se
--add-exports=java.base/jdk.internal.ref=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.nio=ALL-UNNAMED
--add-opens=java.base/sun.nio.ch=ALL-UNNAMED
--add-opens=java.management/sun.management=ALL-UNNAMED
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED

For example, run application on H2 database, keep all settings by default:

java --add-modules=java.se --add-exports=java.base/jdk.internal.ref=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.management/sun.management=ALL-UNNAMED --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED -jar irt-<version>.jar
  • Run application on H2 database, keep all settings by default:

    java -jar irt-<version>.jar
  • Run application on H2 database, on port 8092:

    java -jar irt-<version>.jar --server.port=8092 --irt.url=http://localhost:8092
  • Run application on H2 database, with SSL connection support, with defining custom trust store for secured Agents connection (actual for PRO), on port 8443 and with access through domain name:

    java -Djavax.net.ssl.trustStoreType=Windows-ROOT -jar irt-<version>.jar --server.port=8443 --server.ssl.key-store=keystore.p12 --server.ssl.key-store-password=123456 --server.ssl.keyStoreType=PKCS12 --server.ssl.keyAlias=IRT --irt.url=https://irt.internal.company.com:8443
  • Run application on Oracle database having minimum configuration:

    java -Dloader.path=<path to libs folder with ojdbc<version>.jar> -jar irt-<version>.jar --irt.db.type=oracle --irt.db.host=localhost --irt.db.port=1521 --irt.db.name=XE --irt.db.username=IRT --irt.db.password=HereYourPassword123
  • Run application on DB2 database having minimum configuration:

    java -Dloader.path=<path to libs folder with db2jcc<version>.jar> -jar irt-<version>.jar --irt.db.type=db2 --irt.db.host=localhost --irt.db.port=50000 --irt.db.name=IRT --irt.db.username=IRT --irt.db.password=HereYourPassword123
  • Run application on PostgreSQL database having minimum configuration:

    java -Dloader.path=<path to libs folder with postgresql-<version>.jar> -jar irt-<version>.jar --irt.db.type=postgresql --irt.db.host=localhost --irt.db.port=5543 --irt.db.name=irt --irt.db.username=irt --irt.db.password=HereYourPassword123
  • Run application on MS SQL Server database having minimum configuration:

    java -Dloader.path=<path to libs folder with mssql-jdbc-<version>.jar> -jar irt-<version>.jar --irt.db.type=mssql --irt.db.host=localhost --irt.db.port=1433 --irt.db.name=irt --irt.db.username=irt --irt.db.password=HereYourPassword123
  • Run application with SSO configuration:

    • Prepare <IRTPath>/config/application.yml file (<IRTPath> is the folder where you have saved the IRT application):

      server:
        ssl:
          key-store: file:config/keystore.p12
          key-store-password: password
          key-store-type: PKCS12
          key-alias: testCert
      spring:
        security:
          oauth2:
            client:
              registration:
                oidc-provider:
                  client-id: <client_id_here>
                  client-secret: <client_secret_here>
                  authorization-grant-type: authorization_code
                  redirectUri: "https://localhost:8089/irt/login/oauth2/code/oidc-provider"
                  scope:
                    - openid
                    - profile
              provider:
                oidc-provider:
                  authorization-uri: <authorization endpoint>
                  token-uri: <token endpoint>
                  user-info-uri: <user info endpoint>
                  jwk-set-uri: <jwk set endpoint>
                  user-name-attribute: sub #in most cases, otherwise define your
      irt:
        logon-mode: SSO_USERS
        sso:
          sso-login-page-url: "/oauth2/authorization/oidc-provider"
          logout:
            url: <logout endpoint from oidc provider>
            callback-url-param-name: "post_logout_redirect_uri"
            callback-url:  "https://localhost:8089/irt/#/login"
          claims-mapping:
            username: email
            display-name: firstName, lastName  # for example
            roles: roles
          custom-properties:
            customParam1Name: customParam1Value

      In the file you can configure other application properties.

    • Run IRT application

      java -jar irt-<version>.jar

5.4. License installation

  1. Signup on https://figaf.com/irt to get the license key via email for trial access or contact [email protected] to purchase the real license.

  2. Open the License tab on the Configuration page.

  3. Enter your license key in the form below:

    empty license
    See License synchronizations problems if you have connection issues.
  4. Configure object licenses (to work with Testing Tool and DevOps):

    Object licenses can be configured automatically:

    1. During message record or test case creation for unlicensed object you get the following error:

      request license testing error
    2. During attaching unlicensed object to development ticket you get the following error:

      request license devops error
    3. During attaching unlicensed object to migration ticket you get the following error:

      request license migration error

    Click on Request missing licenses to update object licenses.

    1. Add Object Licenses clicking on Add Object Licenses button. It opens 'Add new object licenses' dialog box where you can select an Agent, click on Add Object Licenses button, select objects, and submit the dialog box:

      add new object licenses dialog

      To delete unnecessary objects select them and click on red trash.

      The following license types can be configured:

      1. Testing - message record, test case creation.

      2. DevOps - development ticket creation, attaching object to development ticket.

      3. Migration - migration ticket creation, attaching object to migration ticket.

    2. Modify Object Licenses clicking on Modify Object Licenses button. It opens 'Add new object licenses' dialog box where you can select new license type(s) for licensed objects.

      You can’t unselect previously selected license type(s).

5.5. Agents integration configuration

5.5.1. Agents integration configuration (PRO platform)

  1. Go to the Agents tab on Configuration page and add your agent system through Add button:

    new agent PRO
  2. Configure the following properties:

    • System ID - the system identifier of SAP system.

    • Platform - select the type of your agent system - PRO.

    • Version - the version of Process Orchestration system. It’s used to create correct XI 3.0 sender channel.

    • Username, Password, Protocol, Host, Port - common connection settings.

    • Virtual - set this flag if you are not going to use that agent for messages recording (e.g., after transferring test data from one system to another). Virtual agents can’t be synchronized, JMS connection will not be established for virtual agents while application bootstrap and you also can’t test their configuration.

    • Production system disables testing on current agent.

    • Has confidential data - when enabled, all messages, recorded on that system will be marked as confidential. Only users with the role IRTSensitivePayloadViewer will be able to see the real payloads and testing results of confidential messages. Other users will have only encoded versions. Example.

    • Secured test system - set this flag if you are going to use the current agent for running test cases with confidential data. It can be configured only for not production systems (Production system is false)with Messages retrieving way equals to `IRT Agent Module`.

      Only administrators with IRTSensitivePayloadViewer role can enable Has confidential data and Secured test system properties.

    • Decentral Adapter Engine configures decentral adapter engine (a separate PI/PO system that is used for message processing in order to distribute the load).

      decentral adapter engine

      Type Decentral Adapter Engine Label (is used in the communication channels) and select Parent Agent (is a link to the main system with central adapter engine, required field).

      Decentral Adapter Engine configuration example: if you have PRO system with the central adapter engine (e.g. DPC) and 2 PRO systems with the decentral adapter engine (e.g. DPD1 and DPD2), you need to create the following agents:

      • Agent DPC with empty Decentral Adapter Engine property because it is the central adapter engine.

      • Agents DPD1 and DPD2 with enabled Decentral Adapter Engine property and the following configuration:

        • Decentral Adapter Engine Label is label in <AdapterEngineName> tag in a channel payload:

          decentral adapter engine label
        • Parent Agent is previously created DPC agent.

    • Timezone - SAP instance timezone, must be defined in GMT format (e.g., GMT+1, GMT-4). Since 2.15.2 release IRT tries to fetch timezone from the server. If it can’t be fetched, you’ll see an error and have to define this value manually. Also the actual timezone are fetched and updated in the agent model during the synchronization startup.

    • P4 Host - internal hostname of the SAP instance, it is used for connecting to P4 port (JMS integration, EJB client integration). By default the main Host value will be used. You must configure that field separately if the Host value is a hostname of your HTTP load balancer. That hostname can’t be used for connecting to P4 port.

    • P4 Port - P4 port value, defined in the SAP instance.

    • Messages retrieving way - type of integration with current agent, the way of fetching messages from PRO system:

      • IRT Agent Module requires installation of Agent component. The main part of Agent component is the Agent Module. Agent component also includes some secured web services which are used by web application for synchronous communication and JMS queue which provides asynchronous integration. Agent Module is a EJB stateless component which implements com.sap.aii.af.lib.mp.module.Module interface. Agent Module (IRT/SaveModule) is automatically added to the communication channel’s modules chain at specific positions. The main purpose of that module is to intercept exact message, send it to local JMS queue (if JMS integration is enabled and zipped size of the message is smaller than 5 Mb) or save it to SAP database (if JMS integration is disabled or zipped message size is greater or equal to 5 Mb). The existent message payload or dynamic properties are not modified by Agent Module, except the only one situation: for regression test case it has specific option to replace synchronous service response on the test scenario by related recorded expected message from the test case. If you want such behavior for your synchronous scenario, you need to enable that option manually on integration object’s Test Configuration page. IRT Agent Module integration type has the following configuration:

        agent module parameters

        The main benefit of Agent Module - its performance. Receiving messages through JMS is asynchronous and it’s much faster than polling approach. It especially makes great sense if the size of payloads is not large. For large messages there is no way to use JMS, Agent component has a web service for that purpose. Messages are saved in the local SAP system database and then they are polled by the web application through the web service. This approach is used for smaller messages automatically if JMS integration is disabled. You can configure scheduled polling for current integration type (for other types too) by enabling it and entering a value for Polling Cron Expression.

        Allow only manual modules update prevents automatic modules update for whole Agent, so no communication channels will be touched. IRT will only manage its own XI scenarios, created by the tool for sending messages through the system. You can configure ignored channels for ICOs on Integration Object page.

      • SAP Log Module - noninvasive integration type. It uses standard SAP Log Module (localejbs/AF_Modules/MessageLoggerBean) to log exact message state. This module is automatically added to the communication channel’s modules chain at the same positions as Agent Module. SAP Log Module integration type has the following configuration:

        sap log module parameters

        The only one way to retrieve a message is the messages polling functionality. You can make it scheduled by enabling it and defining a cron job expression. In order to receive message payloads from SAP systems, IRT looks for new root AdapterFrameworkData (AFD) entries using AdapterMessageMonitoringVi#getMessageList web service (by applying special filters), determines relationships of AFD entries and builds a tree of them (for complicated cases). Then if the option Msg payload download approach is set as Use web service (for newer system), it looks for a message payload using AdapterMessageMonitoringVi#getLoggedMessageBytes web service, otherwise, if the option is set as Use web page scraping, it parses AFD page and downloads payloads through provided links on the page. If your system has AdapterMessageMonitoringVi#getLoggedMessageBytes web service (was introduced in some patch in Oct. 2017), use Use web service (for newer system) option. It’s a bit faster than web page scraping. SAP Log Module integration type is slower than IRT Agent Module, but the main benefit is that you don’t need to deploy any third party components on your production system. You can mix SAP Log Module integration type with IRT Agent Module without any problems. For example, you agent system can be integrated through SAP Log Module, and test system is integrated through IRT Agent Module.

        Allow only manual modules update prevents automatic modules update for whole Agent, so no communication channels will be touched. IRT will only manage its own XI scenarios, created by the tool for sending messages through the system. You can configure ignored channels for ICOs on Integration Object page.

      • PI Message Log - "the most" noninvasive integration type. If you enable that type, application won’t add any modules to the communication channel’s modules chain. You just need to be sure that all needed scenarios have logging options enabled for stages BI and AM. The cons of that approach - you need to maintain these logging options manually and the state of logged messages sometimes is different to the state obtained through previous integration type. We can’t control, when BI and AM stages will be logged, for some cases we even don’t have the final logs at all (e.x. message splitting case, it doesn’t log payloads after the splitting, only before). That behavior leads to problems when you want to mix PI Message Log approach with SAP Log Module or IRT Agent Module. For example, you can configure your agent system using PI Message Log integration type and test system using SAP Log Module integration type. It will work until you get scenario with custom modules or scenario with message splitter. In the first case the different state of the same message will be received, in the second case the messages received through SAP Log Module will have outbound state after splitting, the messages received through PI Message Log will have outbound state before splitting. So, amount of outbound messages will be different. PI Message Log integration type has the same configuration as SAP Log Module:

        pi message log parameters

        Similar to SAP Message Log approach it uses polling to retrieve messages from SAP PRO system. The polling options are the same. Only one difference, it looks for message entries by combination of labels BI and AM (instead of irtLogStage<1..4> labels for SAP Log Module), so, these stages must be logged.

    • Synchronize used sap repository objects on demand enables synchronization of used sap repository objects. If it is false, all sap repository objects will be synchronized.

    • Enable dual stack recording enables dual stack recording (since of 2.12) and has the following configuration:

      jco destination properties

      JCO Destination properties should be copied from *.jcoDestination file.

      JCo library must be added to the external libraries folder which is defined by -Dloader.path=<path to libs folder> VM parameter (go to IRT Application running for more details). You can download it here.

      User, configured in Username and Password fields, should have permissions to ping dual stack system and poll messages from it.

    • Partial test case running - enable it if you want to restrict number of messages sent from IRT to remote system in unit of time.

      Actual number of messages sent from IRT can vary depending on count of inbound messages in one group. All messages from one group are sent together.

    • Reset synchronization query - use that function to remove cached values of last change dates for each tracked object types. These dates are used in synchronization algorithm to minimize amount of objects to check (checking only changed objects).

  3. Test configuration for created agent. Select it and click on Test configuration button. Test connection settings dialog box will be opened:

    test connection dialog PRO

    If Enable dual stack recording is true for selected agent, Test connection settings dialog box contains two additional settings Pinging dual stack through JCo and Polling messages from dual stack through JCo.

    If Receiving test message through JMS setting is loading, wait for a while and click on Refresh button. If it doesn’t help, open Edit Agent dialog box (click on it’s edit button) and click on Save. Test configuration for the agent again.

5.5.2. Agents integration configuration (CPI platform)

  1. Go to the Agents tab on Configuration page and add your agent system through Add button:

    new agent CPI
  2. Configure the following properties:

    • System ID - the system identifier of SAP system.

    • Platform - select the type of your agent system - CPI.

    • Username, Password, Protocol, Host, Port - common connection settings.

    • Virtual - set this flag if you are not going to use that agent for messages recording (e.g., after transferring test data from one system to another). Virtual agents can’t be synchronized.

    • Production system disables testing on current agent.

    • Has confidential data - when enabled, all messages, recorded on that system will be marked as confidential. Only users with the role IRTSensitivePayloadViewer will be able to see the real payloads and testing results of confidential messages. Other users will have only encoded versions. Example.

    • Secured test system - set this flag if you are going to use the current agent for running test cases with confidential data. It can be configured only for not production systems (Production system is false).

      Only administrators with IRTSensitivePayloadViewer role can enable Has confidential data and Secured test system properties.

    • IFLMap Host - host name which is used as an endpoint path part for some adapters in CPI system. It’s used by IRT for regression testing of integration flows. For example: m0403-iflmap.hcisbp.eu1.hana.ondemand.com, where m0403 is a CPI system id.

    • CPI Platform Type - select the type of your CPI system (NEO or CLOUD_FOUNDRY). There are two more settings IFlow Client Id and IFlow Client Secret for CLOUD_FOUNDRY.

    • Enable Git Integration enables git integration, learn more about related configuration here.

    • Partial test case running - enable it if you want to restrict number of messages sent from IRT to remote system in unit of time.

      Actual number of messages sent from IRT can vary depending on count of inbound messages in one group. All messages from one group are sent together.

    • Keep iflow in trace mode for active recording/testing - enable it if you want to keep the iflow in trace mode until all required number of message is received.

    • Reset synchronization query - use that function to remove cached values of last change dates for each tracked object types. These dates are used in synchronization algorithm to minimize amount of objects to check (checking only changed objects).

  3. Test configuration for created agent. Select it and click on Test configuration button. Test connection settings dialog box will be opened:

    test connection dialog CPI

5.5.3. Agents integration configuration (Api Management platform)

  1. Go to the Agents tab on Configuration page and add your agent system through Add button:

    new agent API
  2. Configure the following properties:

    • System ID - the system identifier of SAP system.

    • Platform - select the type of your agent system - Api Management.

    • Username, Password, Protocol, Host, Port - common connection settings.

    • Virtual - set this flag if you are not going to use that agent for messages recording (e.g., after transferring test data from one system to another). Virtual agents can’t be synchronized.

    • Production system disables testing on current agent.

    • CPI Platform Type - select the type of your Api Management system (NEO or CLOUD_FOUNDRY).

    • Enable Git Integration enables git integration, learn more about related configuration here.

    • Reset synchronization query - use that function to remove cached values of last change dates for each tracked object types. These dates are used in synchronization algorithm to minimize amount of objects to check (checking only changed objects).

  3. Test configuration for created agent. Select it and click on Test configuration button. Test connection settings dialog box will be opened:

    test connection dialog API

5.5.4. Agents integration configuration (API_HUB platform)

See this blog post for more details.

  1. Go to the Agents tab on Configuration page and add your agent system through Add button:

    new agent API HUB
  2. Configure the following properties:

    • System ID - the system identifier of SAP system.

    • Platform - select the type of your agent system - API_HUB.

    • Username and Password.

  3. Test configuration for created agent. Select it and click on Test configuration button. Test connection settings dialog box will be opened:

    test connection dialog API HUB

5.6. Troubleshooting

5.6.1. License synchronizations problems

If some connection issues occur during license synchronization, you will see the following dialog:

handle connection issues dialog

To finish the process do the following:

  1. Copy JSON clicking on Copy request button.

  2. Go to https://app.figaf.com/irt-lic/#/.

  3. Paste copied request to Request json field.

  4. Click on Upload button.

  5. Copy response clicking on Copy response button.

  6. Go back to IRT.

  7. Paste copied response to Response from the License Server field.

  8. Click on Save.

Next time when you will need to add some objects to the license it will ask you to do the same thing.

6. Change Tracking Tool

6.1. Change Tracking Tool overview

6.1.1. What is Change Tracking Tool

Change Tracking Tool (CTT) is the core part of the Integration Regression Tool, CTT provides functionality to fetch, browse and store the state of large set of objects on PRO and CPI systems. CTT has a complex synchronization algorithm which checks whether some object is created, changed or deleted. On UI you can view the differences between object versions, relationships between different objects and download an object payload if it needs.

6.1.2. Supported business objects

CTT is tracking changes of the following list of object types:

Object Type Registry System

Communication Party

Integration Directory

PRO

Business Component

Integration Directory

PRO

Business System

Integration Directory

PRO

Communication Channel

Integration Directory

PRO

Integrated Configuration

Integration Directory

PRO

Sender Agreement

Integration Directory

PRO

Receiver Agreement

Integration Directory

PRO

Integration Flow

Integration Directory

PRO

Configuration Scenario

Integration Directory

PRO

Receiver Determination

Integration Directory

PRO

Interface Determination

Integration Directory

PRO

ID File Transport

Integration Directory

PRO

ID CTS Child Transport

Integration Directory

PRO

Context Objects

Enterprise Service Repository

PRO

Data Type

Enterprise Service Repository

PRO

Data Type Enhancement

Enterprise Service Repository

PRO

External Definition

Enterprise Service Repository

PRO

External Message

Enterprise Service Repository

PRO

Folder

Enterprise Service Repository

PRO

Function Library

Enterprise Service Repository

PRO

Function Module

Enterprise Service Repository

PRO

IDoc

Enterprise Service Repository

PRO

Imported Archive

Enterprise Service Repository

PRO

Mapping Template

Enterprise Service Repository

PRO

Message Mapping

Enterprise Service Repository

PRO

Message Type

Enterprise Service Repository

PRO

Operation

Enterprise Service Repository

PRO

Operation Mapping

Enterprise Service Repository

PRO

RFC Message

Enterprise Service Repository

PRO

Service Interface

Enterprise Service Repository

PRO

ESR File Transport

Enterprise Service Repository

PRO

ESR CTS Child Transport

Enterprise Service Repository

PRO

Package

Cloud Integration

CPI

Integration Flow

Cloud Integration

CPI

Archive

Cloud Integration

CPI

Integration Flow External Configuration

Cloud Integration

CPI

Schema

Cloud Integration

CPI

Script

Cloud Integration

CPI

Value Mapping

Cloud Integration

CPI

Documents (File and URL)

Cloud Integration

CPI

Api Proxy

Api Management

API Management

Api Proxy Endpoint

Api Management

API Management

Api Resource

Api Management

API Management

Api Target Endpoint

Api Management

API Management

Api Documentation

Api Management

API Management

Api File Resource

Api Management

API Management

Api Policy

Api Management

API Management

6.2. Tutorials and Samples

6.2.1. Synchronization with Agent system

Check that you’ve configured an Agent entry and tested integration with it. See that section to learn how to do it.

You can run synchronization from 2 pages on UI: Tracked Objects page and Integration Objects page. They are configured a bit differently for PRO agents. Synchronization request on Integration Objects page includes only Integration Directory types for PRO system (see Supported business objects section), but synchronization request on Tracked Objects page includes both registries: Integration Directory and Enterprise Service Repository (ESR). Usually the total size of all objects in the ESR is much larger than in the Integration Directory. Initial synchronization can take even several hours depending on amount of data and computation resources. Once all objects are synchronized, further synchronizations are much faster, they depend on amount of changes during current period. If you work only with Testing Tool and don’t care about ESR tracking, just use synchronization from Integration Objects page.

Synchronization with Agent system step-by-step
  1. Click on Change Tracking Tool on the side menu or click on the tile on the home page. It opens Tracked Objects page.

    empty tracked objects page
  2. Select needed agent system and click on Synchronize button to run synchronization. It will synchronize all object types for current SAP system type listed in the Supported business objects section.

    For PRO and CPI Agent systems you can configure synchronization settings:

    1. for PRO Agent system you are able to configure the following settings:

      synchronization config dialog

      Rebuild links for the latest versions forcibly is required when you mix different synchronization settings. For example, first time you synchronize objects on Integration Objects page (that synchronization includes only Integration Directory types), then you synchronize them on Tracked Objects page to browse ESR objects in CTT. It’s related to the fact that all objects have only one-way links in the received metadata. An Integrated configuration object has links to Operation Mapping object, but Operation Mapping object doesn’t contain any links to Integrated configuration. So, if an Integrated Configuration object has been already synchronized, it won’t be possible to link it with currently synchronized Operation Mapping object having only Operation Mapping differences information. If the flag is enabled, synchronization algorithm will check all latest versions for chosen object types and build links between them properly.

      Check metadata of all existent objects runs synchronization without last change date filter for CTT object types.

      It is possible to clear this filter manually (see field Reset synchronization query on Edit Agent Dialog).

      Synchronize used sap repository objects runs synchronization for used sap repository objects. If it is false, all sap repository objects will be synchronized.

      Synchronize all dependent sap objects recursively runs synchronization for child sap objects even if the object hasn’t been changed/created/deleted. If it is false, child sap objects will be synchronized only if the object on the current level has been changed/created/deleted.

      Synchronize used sap repository objects and Synchronize all dependent sap objects recursively settings are available only if Synchronize used sap repository objects on demand field is enabled on Edit Agent Dialog.

    2. for CPI Agent system you are able to configure the following settings:

      synchronization config dialog cpi

      Synchronize objects forcibly - use that function to remove cached values of last change dates for each tracked object types. These dates are used in synchronization algorithm to minimize amount of objects to check (checking only changed objects).

      Synchronize all packages - if true, all packages will be synchronized. If false, you can select packages to be synchronized.

  3. Once synchronization is started, you can see the dialog with progress information:

    synchronization result dialog

    The dialog information is updated automatically time-to-time. Synchronization is finished when the Synchronization Stage field is equal to Synchronization finished.

6.2.2. Git Integration (CPI, API Mgmt). Repository initialization and getting changes from SAP Agent.

  1. Enable and configure Git integration on Agent.

  2. Go back to Agents page and click initialize repository button button. It starts synchronization on chosen Agent. Once it’s done, check the folder with cloned Git repository, specified in Local Path To Repo:

    initialized local repo

    Folders at root level are related to packages (CPI agents) or API Proxies (API Management agents). Some files are added automatically to repository during initialization: .gitignore-irt, build-irt.gradle, settings-irt.gradle, gradle-irt.properties. These files contains configuration modular structure and Figaf Gradle plugins. If you want to use them in your development workflow, remove irt suffix and save them as .gitignore, build.gradle, settings.gradle, gradle.properties. Or copy required configuration to existent files.

  3. Now let’s make some changes in target object, for example CPI IFlow. We’ve added a Content Modifier from SAP UI. Then we need to process synchronization in IRT for chosen Agent. It can be done manually or by scheduled job if you have configured it. Once synchronization is finished, you can see a new commit with related changes:

    repo after object update

6.2.3. Use IFlow as a configurable template to create many IFlows (CPI)

If you have multiple organizations, like a sales division for Denmark, Germany, Sweden, and some flows may need to run for all organizations, you can develop the flow once and then configure it for multiple organizations using distribution configuration.

  1. Open the IFlow details you want to use as a configurable template to create many IFlows.

  2. Click on Create distribution configuration button. It creates distribution configuration that is used for configuring external configuration for target IFlows created from the selected IFlow.

  3. Click on Add target IFlow to add target IFlows to the distribution configuration. It opens 'Add iFlows to distribution configuration' dialog box where you can configure target IFlows technical and displayed names:

    add iflows to distribution configuration
  4. If you want to change external configuration of target IFlows, deselect Inherit (source) for parameter, define values, and Save configuration:

    configure external configuration
  5. You can Upload all IFlows or Update target IFlow (in menu of target IFlow).

    If you want to deploy target IFlows, click on edit, enable Deploy uploaded objects, and click on save.

    If you want to update target IFlows after source IFlow changes, click on edit, enable Update target objects automatically, and click on save. After that if source IFlow is updated (the changes are handled during synchronization), target IFlows will be updated automatically.

  6. If you want to delete the distribution configuration, click on Delete button. It marks distribution configuration as deleted. If you want to delete distribution configuration that marked as deleted from CTT, click on Delete from CTT button.

IFlow can be linked only with one distribution configuration.

6.3. Git integration

Since of 2.10 IRT supports integration with Git for CPI and API Management Agent systems. It includes:

  1. Synchronization of all IFlows(for CPI)/API Proxies(for API Management) with configured Git repository. All found changes will be saved in the repository during CTT synchronization. It’s also possible to initialize/reinitialize repository by pushing all objects through manual operation. See this section to learn more about configuration options.

  2. IRT Gradle plugin for running IRT test suites remotely through Gradle task. It helps to build flexible development workflow with unit and integration tests. See this section to learn more.

It’s needed to run the command git config --system core.longpaths true as an admin in command prompt if you use OS Windows in order to prevent a problem with long file names.

6.3.1. Git integration configuration

Open ConfigurationAgents page, click Edit on needed Agent. If you don’t have Agent configured read this section at first. Enable checkbox Enable Git Integration. Then you will see the following fields:

agent git integration config
  1. Skip Synchronization Of IFlows In Git (CPI) or Skip Synchronization Of API Proxies In Git (Api Management) - if true, IFlows or API Proxies won’t be added to git repository (only folders will be initialized).

  2. Update build.gradle automatically - if true, build.gradle will be updated automatically after synchronization. Enable this option if you don’t need to change build.gradle manually. If this option is disabled, you have to update build.gradle file when version of gradle plugin is upgraded.

  3. Update settings.gradle automatically - if true, settings.gradle will be updated automatically after synchronization. Enable this option if you don’t need to change settings.gradle manually. If this option is disabled, you have to update settings.gradle file when objects, stored in Git, are changed on remote system.

  4. Update .gitignore automatically - if true, .gitignore will be updated tomatically after synchronization. Enable this option if you don’t need to change .gitignore manually.

  5. Git Remote Url - url to remote repository.

  6. Local Path To Repo (only for on-premise version) - local folder, where repository will be cloned. If it’s not defined, it will use /<origin repository name> as a local path relatively to irt.jar. You can define either absolute or relative paths here, a relative path will be calculated from the same folder where IRT is executed.

  7. Branch Name - branch used by IRT. If it doesn’t exist, it will be created automatically. We recommend to define a special branch for IRT and then merge it with your working branch when it needs. Changes are committed to this branch during synchronization operation. But you can also initialize/reinitialize a full state of all objects at one time manually.

  8. Git Username - username for accessing remote Git repository. IRT will make commits on behalf specified user, but with its own name in commits.

  9. Git Password - password related to specified Git user.

  10. Ignore Files - paths used when you are downloading/uploading IFlow/ApiProxy through cpi-plugin or api-management-plugin. All matched files and folders won’t be added to bundled archive. Define only relative paths, the root is IFlow/ApiProxy bundled folder. By default it ignores src/test, build.gradle, settings.gradle, gradle.properties. The main reason to have some project files excluded is that they are not a part of bundled model. But some of them (like src/test, where you can keep your unit tests for groovy scripts) makes CPI IFlow non-operational, i.e. upload will be successful, but IFlow won’t work in runtime.

The following packages on CPI won’t be added to the repository during synchronization:

  1. Packages created by IRT through transport to virtual landscape item (their name starts with Z_<landscape item label>|, for example Z_QA|).

  2. Packages created by IRT for regression testing (their name starts with Z_Figaf|)

6.3.2. Groovy scripts unit testing

IRT provides a possibility to generate unit tests for groovy scripts using the state of the recorded messages in CPI test cases. To use that feature you should open a Messages tab on the Test Case page. It has a button Generate groovy scripts test data. There are two options:

  1. Add to git repository. If git integration is configured and enabled, IRT will build test data files and commit them to repository.

  2. Download archive. All needed files will be archived and downloaded to your computer.

There are several files which are generated for testing:

  1. Files in common folder. These files are the basis for unit testing of groovy scripts.
    GroovyTestData and MessageTestData are a model.
    MessageImpl is a simple implementation of SAP Message interface.
    AbstractGroovyTest is an abstract class which does all the testing and has several methods which can be extended.

  2. Files in <iflow_package_name>/<iflow_name> folder.
    GroovyScriptsTest.groovy is a test which is ready to be run. It has all the needed links and methods.
    Files in resources folder are the test data for GroovyScriptsTest.groovy. Each file has input and expected output data. Each file contains an integer in the end of the name. If you select Download archive these numbers just start from 1. If you select Add to git repository IRT will not overwrite the existing test files. Instead of it IRT will find the maximum number among the existing files and increment this number.

You need to manually download CPI client jars and put them to the libs folder at root project level. If you want to change folder name, type your folder in Gradle dependency definition in common/build.gradle:

compile fileTree(dir: '../libs', include: '*.jar')

You can extend testing and write custom tests using AbstractGroovyTest.groovy. It’s not recommended to edit GroovyScriptsTest.groovy because it can be overwritten next time by IRT. It’s better to write custom tests in a separate class which should extend AbstractGroovyTest. The following methods can be overridden:

  1. processMessageData(String groovyScriptPath, String testDataFilePath, String methodName) - it calls methodName of the groovy script for test data and returns messageDataExpected and messageDataActual.

  2. assertMessages(MessageTestData messageDataExpected, MessageTestData messageDataActual, List<String> ignoredKeysPrefixes, List<String> ignoredKeys) - assert messageDataExpected and messageDataActual excluding the keys presented in ignoredKeysPrefixes and ignoredKeys.

  3. basicGroovyScriptTest(String groovyScriptPath, String testDataFilePath, String methodName, List<String> ignoredKeysPrefixes, List<String> ignoredKeys) - aggregate two previous methods.

  4. getIgnoredKeysPrefixes() - if a key starts from this list’s value, this key will be excluded from assertion in assertMessages method.

  5. getIgnoredKeys() - if a key is presented in this list, this key will be excluded from assertion in assertMessages method.

For example if you want to use processMessageData but have your own assertions you can easily do it.

import org.junit.jupiter.api.Test

import static org.assertj.core.api.Assertions.assertThat
import static org.mockito.BDDMockito.then

class SampleTest extends AbstractGroovyTest {

    @Test
    void customTest() {

        // given
        initMessageLogFactoryMocks()

        String groovyScriptPath = "src/main/resources/script/script1.groovy"
        String testDataFilePath = "src/test/resources/test-data-files/script1/processData/test-data-1.json"

        // when
        def (MessageTestData messageDataExpected, MessageTestData messageDataActual) = processMessageData(groovyScriptPath, testDataFilePath, "processData")

        // then

        // assert custom messageLog interaction
        then(messageLog).should().addAttachmentAsString("error.xml", messageDataExpected.getBody() as String, "application/xml")
        then(messageLog).should().addAttachmentAsString("responseError", "daniel test attachment", "text/plain")

        // assert properties/headers/body
        def propertyKey = "newError3"
        String actualPropertyValue = messageDataActual.getProperties().get(propertyKey)

        assertThat(actualPropertyValue).
                overridingErrorMessage("Property with key '%s' must be not null", propertyKey).
                isNotNull()
        assertThat(actualPropertyValue).
                overridingErrorMessage("Property with key '%s' must end with 'Test3', but actual value was '%s'", propertyKey, actualPropertyValue).
                endsWith("Test3")

    }
}

6.4. Troubleshooting

  1. Try to process synchronization with forcible linking. Rebuild links for the latest versions forcibly is required when you mix different synchronization settings. For example, first time you synchronize objects on Integration Objects page (that synchronization includes only Integration Directory types), then you synchronize them on Tracked Objects page to browse ESR objects in CTT. It’s related to the fact that all objects have only one-way links in the received metadata. An Integrated configuration object has links to Operation Mapping object, but Operation Mapping object doesn’t contain any links to Integrated configuration. So, if an Integrated Configuration object has been already synchronized, it won’t be possible to link it with currently synchronized Operation Mapping object having only Operation Mapping differences information. If the flag is enabled, synchronization algorithm will check all latest versions for chosen object types and build links between them properly.

  2. If the first step doesn’t help, try to clear cached last change dates (Reset synchronization query button on the Agent settings page). By default, CTT will check only new/changed/deleted objects, each time when it synchronized concrete object type, CTT saves a last change date for each object type. Next time it doesn’t check objects older than cached date. Once cached dates are cleared, process synchronization with forcible linking.

6.4.2. CTT doesn’t see changes of some objects

Try to clear cached last change dates (Reset synchronization query button on the Agent settings page). By default, CTT will check only new/changed/deleted objects, each time when it synchronized concrete object type, CTT saves a last change date for each object type. Next time it doesn’t check objects older than cached date. Once cached dates are cleared, process synchronization with forcible linking.

7. Testing Tool

7.1. Testing Tool overview

7.1.1. What is Testing Tool

Integration Scenario Testing Tool - the oldest part of the IRT, provides functionality for regression and baseline testing of integration scenarios on PRO or CPI systems. It provides a flexible way to configure test cases and supports different ways to communicate with source SAP system. Once you run a test case, IRT sends an inbound message to SAP system and then fetches results using chosen integration type. Results are compared and finally you can browse the differences on UI or in the test case’s excel report. Test cases can be aggregated as a test suite and run as single unit of testing. Test suite has it’s own excel report and can be scheduled. Scheduled testing and our REST API gives you a real opportunity to automate your testing flow or integrate IRT to existent processes.

Regression testing is an approach when you test that integration scenario produces expected outbound response for the same inbound data.

Baseline testing is a bit different - it compares the whole set of messages, so it checks that integration scenario consumes expected inbound request and produces expected outbound response.

7.1.2. How Testing Tool works

In this section we skip test cases preparation part as well as many features related to Testing Tool and show only the core testing process in action.

Agent is a configuration entity which represents a SAP system (PRO or CPI).

Agent System is an Agent where you take messages for test cases in the context of current testing flow.

Test System is an Agent where test cases will be run in the context of current testing flow.

Agent object is an integration scenario on Agent System in the context of current testing flow.

Test object is an integration scenario on Test System in the context of current testing flow.

Regression testing on PRO systems

The idea of regression testing is to check response of an integration scenario having identical request. PRO system has a lot of different sender side adapters and most of them can’t be easily triggered by IRT. Fortunately, it has a way to send a message through the system using a XI 3.0 Sender channel and a specific request. IRT requires special infrastructure scenarios to be able to send requests to PRO system. There are 2 types of infrastructure scenarios:

  1. Common infrastructure scenario. Only one per system.

    common pro infr scenario
  2. Specific infrastructure scenario. Such scenario is created per Agent Object/Test object pair only when it requires to add something to the sender channel.

    For example if you’ve chosen testing with Agent Sender Channel custom modules or testing with NumberRange module.

    specific pro infr scenario

All infrastructure scenarios have the same sender/receiver business component |TEST_MigrationHelper and receiver channel TEST_MigrationHelperReceiverStub which is never called.

IRT creates these infrastructure scenarios and checks their state automatically, so, you don’t need to do anything yourself. Just be sure that user defined in the Agent configuration has needed access.

When you run a test case IRT takes each inbound message, prepares a special request which includes information about target Test Object, inbound message payload and its Dynamic Properties (we filter adapter-specific properties), then sends it to XI 3.0 Sender Channel of infrastructure scenario on the Test System. Then the message is processed by XI 3.0 Sender Channel and forwarded directly to target Test Object ignoring its sender channel. That’s why it requires to create scenario-specific infrastructure scenarios when some custom modules should be used on the sender side. The first running of test cases takes a bit more time because it creates infrastructure scenario.

testing flow diagram

When messages are processed on PRO system, outbound messages can be received by IRT. It’s processed manually or automatically depending on your Agent configuration. Once outbound messages are received, IRT processes comparison of outbound message payloads and metadata.

test run details
diff viewer

Finally it builds an excel report for current test run.

Regression testing on CPI systems

The concept is the same as described above. CPI also supports many types of adapters but it doesn’t have any unified mechanism (at least for now) for sending messages directly to integration flows. For all adapters except HTTPS and SOAP, IRT uses CPI API to copy integration flow structure and replace sender adapter by HTTPS adapter in the copied version. Then it saves the new integration flow in the package FigafIRT <original package name> and deploys it. For integration flows with HTTPS or SOAP senders IRT sends messages directly to them. Similar to infrastructure scenarios update described in the previous section, IRT checks and updates copies of integration flows during test case running.

Baseline testing

The idea of baseline testing is to check both request and response of an integration scenario. IRT doesn’t use any additional infrastructure objects for that type of testing.

When you run a baseline test case, IRT creates a new recording request linked with current test run. Once messages are triggered and available on target system, they can be received by IRT. It’s processed manually or automatically depending on your Agent configuration. Once inbound outbound messages are received, IRT distributes them to testing results, processes comparison of message payloads and metadata. Finally it also builds an excel report for current test run.

7.1.3. When do you need Testing Tool

Some end-to-end use cases:
  1. Test when you are doing a SAP PI Upgrade/Patch in this case you want to make sure that nothing vital has changed on the SAP PI system. IRT allows you to run the test fast and validated all documentation.

  2. Test when you have done any development or modification of an SAP Interface. IRT allows you to fast run the test again.

  3. Test once you have done a migration from a dual stack to a single stack or from an other integration platform. You can then upload the in- and outbound messages and process them on the PI system.

  4. Test that your Seeburger Migration works and have not have any impact on your existing integrations.

  5. Extend the test cases from other testing applications like UFT or ALM with validation of the SAP PI/CPI interfaces. This will give you an extended validation of that the messages is created correctly. In this case you need to use the baseline option of Figaf IRT Testing Tool.

7.2. Get started with Testing Tool

Requirements:

Required Agent System has been configured (see that section to learn how to do that).

7.2.1. E2e testing of scenario (common use case)

In this section we describe the standard use case with e2e testing of scenario.

  1. Go to the Integration Objects tab on the Testing Tool page.

  2. Select required Agent and run synchronization (see Synchronization with Agent system section).

  3. Choose the integration objects that you want to create test cases for.

  4. Click on Record messages. It opens Create recording requests dialog box.

    create recording request
  5. Enter Title of created Test Suite (e.g. Test Suite 1) and click on Save. If chosen objects haven’t been licensed yet, you will see the following error:

    request license testing error

    Click on Request missing licenses to update object licenses.

    After confirming the dialog box, Test Suite: Test Suite 1 page is opened.

    test suite new recordings
  6. Select all recordings and click on play. It starts the selected recordings.

  7. Send the messages to the scenario or wait for messages if the scenario is scheduled.

  8. Go to the STARTED RECORDINGS tab.

  9. Select all recordings and click on Poll remote messages.

    You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

    Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

    Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

    • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

    • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

    If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

    It opens Polling results dialog box.

    polling results
  10. When Status of all recordings is COMPLETED, close the dialog box.

  11. Select all recordings and click on play with plus. It opens Test Case Creation dialog box, where you can configure Test Objects. Once you finish, click on Create Test Case(s).

  12. Go to the LINKED TEST CASES tab.

  13. To run created test suite (it runs all linked test cases) click on run.

  14. Go to the LAST RESULT tab.

  15. Click on Poll remote results.

    You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

    Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

    Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

    • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

    • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

    If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

    When polling is finished, close the dialog box clicking on Close.

    If data in the table is not refreshed, click on refresh.

  16. You can see last test suite run results in the table.

    last result with errors
  17. To check details of exact test run result click on its menu button and then click on View results. It opens Test Run Details page.

    test run details page
  18. To open diff viewer and check differences between expected and actual messages, click on the inspected item’s menu button and then click on Diffs. It opens Differences dialog box. Here you can add items (click twice on the required item) and message properties (click on the required message property) to ignore list.

    Add items and message properties to ignore list once.

    differences add to ignore list
  19. When you finish with adding items and message properties to ignore list, close the dialog box and navigate back to Test Suite: Test Suite 1 page clicking on back.

  20. Run test suite again clicking on run.

  21. Poll remote messages again clicking on Poll remote messages.

    You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

    Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

    Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

    • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

    • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

    If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

  22. To view all test suite run results go to the RESULTS HISTORY tab.

7.2.2. E2e testing of receiver determination (PRO, dual stack system)

In this section we describe an use case with e2e testing of receiver determination (since of 2.12 IRT supports this feature).

Agent System should be configured with enabled dual stack recording (property Enable dual stack recording on Agent dialog).

  1. Go to the Integration Objects tab on the Testing Tool page.

  2. Select required Agent and run synchronization (see Synchronization with Agent system section).

  3. Choose the integration objects that you want to create test cases for.

  4. Click on Record messages. It opens Create recording requests dialog box.

    rd create recording request
  5. Enter Title of created Test Suite (e.g. Test Suite 1), choose 'RD historic lookup period' (the left bound is calculated as current time minus specified lookup period. E.g., if 'X hours' lookup period is selected, then ALL messages which satisfy interface filter and have been sent during last X hours will be polled), and click on Save. If chosen objects haven’t been licensed yet, you will see the following error:

    request license testing error

    Click on Request missing licenses to update object licenses.

    After confirming the dialog box, Test Suite: Test Suite 1 page is opened.

    rd test suite new recordings
  6. Trigger agent scenario.

  7. Select all recordings and click on play. It starts the selected recordings.

  8. Go to the STARTED RECORDINGS tab.

  9. Select all recordings and click on Poll remote messages. It opens Polling results dialog box.

    rd polling results
  10. When Status of all recordings is COMPLETED, close the dialog box.

  11. Select all recordings and click on play with plus. It opens Test Case Creation dialog box, where you can configure Test Objects. Once you finish, click on Create Test Case(s).

  12. Go to the LINKED TEST CASES tab.

  13. To run created test suite (it runs all linked test cases) click on run.

  14. Go to the LAST RESULT tab.

  15. Wait for messages to be polled (refresh the page from time to time).

    If data in the table is not refreshed, click on refresh.

  16. You can see last test suite run results in the table.

    last result with errors
  17. To check details of exact test run result click on its menu button and then click on View results. It opens Test Run Details page.

    test run details page
  18. To open diff viewer and check differences between expected and actual messages, click on the inspected item’s menu button and then click on Diffs. It opens Differences dialog box. Here you can add items (click twice on the required item) and message properties (click on the required message property) to ignore list.

    Add items and message properties to ignore list once.

    differences add to ignore list
  19. When you finish with adding items and message properties to ignore list, close the dialog box and navigate back to Test Suite: Test Suite 1 page clicking on back.

  20. Run test suite again clicking on run.

  21. Wait for messages to be polled (refresh the page from time to time).

  22. To view all test suite run results go to the RESULTS HISTORY tab.

7.2.3. E2e secured testing of scenario with sensitive data (common use case)

Secured testing with sensitive data limits the access granted to developers, to ensure they will not see confidential data. Such testing can be used when your test data is confidential and it isn’t advisable to share this information with people that have not been cleared for it.

Below we describe the standard use case with e2e secured testing of scenario with sensitive data (since of 2.12 IRT supports this feature).

Agent System should be configured with confidential data (property Has confidential data on Agent dialog).

Testing with sensitive data is run on secured test systems, so you need to configure Agent (it can be the same Agent or another) as secured (property Secured test system on Agent dialog).

The following actions have to be done on the PRO system configured as secured to prevent browsing of sensitive payloads sent from IRT:

  1. Add the rules in SAPWebDispatcher file (e.g., <path_to_PRO_system>\SYS\global\security\data\icm_filter_rules.txt):

    if %{REMOTE_ADDR} !stricmp 127.0.0.1 [AND]
    if %{REMOTE_ADDR} !stricmp ::1  [AND]
    if %{REQUEST_METHOD} stricmp "GET" [AND]
    if %{FORMFIELD:afwmsgkey} !stricmp ""
    RegIRedirectUrl ^/webdynpro/dispatcher/sap.com/tc~lm~itsam~ui~mainframe~wd/FloorPlanApp.*$ /webdynpro/resources/figaf.com/irt-message-filter/MessagePageServlet [QSA]
    
    
    if %{REMOTE_ADDR} !stricmp 127.0.0.1 [AND]
    if %{REMOTE_ADDR} !stricmp ::1  [AND]
    if %{REQUEST_METHOD} stricmp "GET" [AND]
    if %{FORMFIELD:afwmsgkey} !stricmp ""
    RegIRedirectUrl ^/webdynpro/resources/sap.com/tc~lm~itsam~ui~mainframe~wd/FloorPlanApp.*$ /webdynpro/resources/figaf.com/irt-message-filter/MessagePageServlet [QSA]
    
    if %{REMOTE_ADDR} !stricmp 127.0.0.1 [AND]
    if %{REMOTE_ADDR} !stricmp ::1 [AND]
    if %{REQUEST_METHOD} stricmp "GET"
    RegIRedirectUrl ^/webdynpro/resources/sap.com/tc~lm~itsam~co~ui~xi~msg~wd/Components/com.sap.tc.lm.itsam.co.ui.xi.msg.ximessagedetailed.XIMessageDetailed(.*)$ /webdynpro/resources/figaf.com/irt-message-filter/MessageContentPartsServlet$1 [QSA]
    
    if %{REMOTE_ADDR} !stricmp 127.0.0.1 [AND]
    if %{REMOTE_ADDR} !stricmp ::1 [AND]
    if %{REQUEST_METHOD} stricmp "GET"
    RegIRedirectUrl ^/mdt/messagecontent$ /webdynpro/resources/figaf.com/irt-message-filter/DownloadMessageContentServlet [QSA]
  2. Restart the system.

  3. Deploy IRT-MESSAGE-FILTER-1.0.sca component.

  1. Go to the Integration Objects tab on the Testing Tool page.

  2. Select required Agent and run synchronization (see Synchronization with Agent system section).

  3. Choose the integration objects that you want to create test cases for.

  4. Click on Record messages. It opens Create recording requests dialog box.

    create recording request
  5. Enter Title of created Test Suite (e.g. Test Suite 1) and click on Save. If chosen objects haven’t been licensed yet, you will see the following error:

    request license testing error

    Click on Request missing licenses to update object licenses.

    After confirming the dialog box, Test Suite: Test Suite 1 page is opened.

    test suite new recordings
  6. Select all recordings and click on play. It starts the selected recordings.

  7. Send the messages to the scenario or wait for messages if the scenario is scheduled.

  8. Go to the STARTED RECORDINGS tab.

  9. Select all recordings and click on Poll remote messages.

    You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

    Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

    Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

    • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

    • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

    If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

    It opens Polling results dialog box.

    polling results
  10. When Status of all recordings is COMPLETED, close the dialog box.

  11. Select all recordings and click on play with plus. It opens Test Case Creation dialog box, where you can configure Test Objects. Once you finish, click on Create Test Case(s).

    Test Objects only from secured Agents can be selected.

  12. Go to the LINKED TEST CASES tab.

  13. To run created test suite (it runs all linked test cases) click on run.

  14. Go to the LAST RESULT tab.

  15. Click on Poll remote results.

    You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

    Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

    Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

    • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

    • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

    If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

    When polling is finished, close the dialog box clicking on Close.

    If data in the table is not refreshed, click on refresh.

  16. You can see last test suite run results in the table.

    last result with errors
  17. To check details of exact test run result click on its menu button and then click on View results. It opens Test Run Details page.

    test run details page
  18. To open diff viewer and check differences between expected and actual messages, click on the inspected item’s menu button and then click on Diffs. It opens Differences dialog box. Here you can add items (click twice on the required item) and message properties (click on the required message property) to ignore list.

    Add items and message properties to ignore list once.

    If current user doesn’t have role IRTSensitivePayloadViewer, he/she will view encoded payloads, e.g.:

    encoded differences add to ignore list

    Users with role IRTSensitivePayloadViewer are allowed to view encoded and original version of payloads, e.g.:

    decoded differences add to ignore list

    To encode XML and JSON documents they are parsed and only element values and attributes (for XML) are replaced in the following way:

    • Uppercased letterX

    • Lowcased letterx

    • Number9

    • Space character → no changes

    • Symbol character#

    • Strings with length greater than 20 are truncated, is added to the end of string.

      Encoded view is supported only for XML and JSON documents. For other types payloads won’t be viewed for users without IRTSensitivePayloadViewer role.

  19. When you finish with adding items and message properties to ignore list, close the dialog box and navigate back to Test Suite: Test Suite 1 page clicking on back.

  20. Run test suite again clicking on run.

  21. Poll remote messages again clicking on Poll remote messages.

    You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

    Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

    Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

    • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

    • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

    If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

  22. To view all test suite run results go to the RESULTS HISTORY tab.

7.2.4. Manual test case creation (PRO)

Sometimes automatic message recording isn’t appropriate (e.g. hundreds of them are used). So it is possible to manually create test cases from prepared messages:

  1. Go to the Integration Objects tab on the Testing Tool page.

  2. Select required Agent (PRO) and run synchronization (see Synchronization with Agent system section).

  3. Choose the integration object for which you want to create test case.

  4. Click on Create Test Case button. It opens Test case creation page:

    test case creation page
  5. Type new Test Suite title or select existent one and select message source type (field Upload messages from):

    • Archive: load archive from your local environment.

    • Table: configure inbound and outbound messages and their properties, load payloads.

    • Archive from server: define the path to archive from server.

      You can enable Forcibly calculate order numbers using expressions from recording configuration when Upload messages from is Archive or Archive from server. If it’s enabled, order numbers will be recalculated during test case upload. Settings Order expressions and Use alphanumeric order number (configured on Recording Configuration tab of Integration Object page) will be used during recalculation.

      Archive has to contain all inbound and outbound messages and package-info.json file, that you can create from Test case creation page:

      1. Select Archive type of message uploading.

      2. Click on Build package-info.json button. It opens Create package-info.json for manual upload page:

        create package info json for manual upload page
      3. Configure all properties carefully.

        For example, we have 3 inbound messages and 1 outbound message per inbound message and we don’t use DC filename template. We have prepared the following payloads:

        folder with payloads for manual test case creation

        Then our configuration will be:

        example create package info json for manual upload page

        It is almost done. Only configuration of From and To components is left.

        If you change Outbound messages count per one inbound, click on Build JSON button.

      4. Once you finish with configuration click on Build JSON button and Download package-info.json.

        Also you can view built json clicking on hide.

      5. Move downloaded package-info.json file to the folder with payloads and create an archive.

  6. Once you finish with configuration, click on Create Test Case button. It creates test suite and test case and links them. As the result Test Case Details page will be opened:

    tc info
  7. To run created test case go to Testing Results tab and click on Run button. You will see results in the table.

  8. Select unfinished results and click on Poll remote messages.

    You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

    Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

    Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

    • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

    • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

    If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

  9. Inspect result clicking on its menu button and then clicking on View results. It opens Test Run Details page.

    test run details page
  10. To open diff viewer and check differences between expected and actual messages, click on the inspected item’s menu button and then click on Diffs. It opens Differences dialog box. Here you can add items (click twice on the required item) and message properties (click on the required message property) to ignore list.

    Add items and message properties to ignore list once.

    differences add to ignore list
  11. When you finish with adding items and message properties to ignore list, close the dialog box and navigate back to Test Case Details page clicking on back.

  12. Run test case again clicking on run.

  13. Poll remote messages again clicking on Poll remote messages.

    You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

    Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

    Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

    • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

    • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

    If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

7.2.5. Migrate test cases from PI to CPI

PI test case has been created (see E2e testing of scenario (common use case)).

At least one CPI agent is configured.

  1. Go to Integration Objects page.

  2. Select PI agent.

  3. Click on required object Interface Name. It opens Integration Object Details page.

  4. Go to Agent Test Cases tab.

  5. Select previously created test case.

  6. Click on menu full and then on Migrate to CPI IFlow button. It opens Migrate Test Cases dialog:

    migrate test cases dialog

    Where you can configure test suite (new or existent one) and CPI IFlow. If you want to open Test Suite: Test Suite Title page, enable Open Test Suite’s page after test cases migration option.

    Once you configure all fields, click on Save. It opens confirmation:

    migrate test cases confirmation

    As the result, new test case will be created and attached to the test suite.

    During the copying of the messages, interface related parameters (stepId, activity, branchId) of the last stage are initialized by value ${determineDuringFirstRun}. For other stages for bridges and BE scenario value ${shouldBeMappedManually} is used. Original stage number is temporary saved in the step number, then it will be replaced by real value - it needs for BE and bridges to distinguish different original stages.

  7. Run created test case (either run test suite (e.g. from Test Suites page) or test case separately (e.g. from Test Cases page)).

  8. Open Test Run Details page (e.g. view Test Case Details page, go to Testing Results tab, click on result’s menu and click on View results).

    During the first run of the migrated test case, interface metadata of the last stage (4th for BE or bridges, 2nd for other) is automatically updated. For BE/bridges, 2nd stage entries will have UNFINISHED state. You can chose, which UNEXPECTED message should match this result: click on message’s menu and click on Map interface metadata.

    Once unexpected testing result matched with the unfinished result, missing data is copied to UNFINISHED result, UNEXPECTED results are deleted, and if it needs, the message are sent to the comparison.

7.3. Test with Testing Tool

This section includes detailed description of all pages and dialog boxes in Testing Tool.

7.3.1. Integration Objects page

Integration Objects page looks:

integration objects

On this page you can:

  • synchronize integration objects of the required Agents (see Synchronization with Agent system section);

  • view last synchronization result (to do it click on Last Sync Result button);

    Last Sync Result button is available after synchronization and until page is refreshed.

  • view the integration objects of the selected Agent;

  • view deleted objects (to do it click on Browse deleted objects switcher) - it shows the objects that have been deleted on remote system after previous synchronization;

  • remove deleted objects (to do it select the object(s) and click on trash) - it deletes all related objects in scope of Testing Tool (e.g. recordings, test cases), and it doesn’t delete the object(s) from Change Tracking Tool;

    You should switch view for deleted objects to be able to delete them.

  • add, remove modules for PRO systems (to do it click on menu full and choose the action):

    • Add modules adds IRT Agent Module or SAP Log Module (depending on chosen value of Messages retrieving way option on Agent dialog box) to communication channel’s modules chain;

    • Remove modules is opposite to Add modules;

    • Remove ALL modules triggers removing from all objects. It is used while uninstallation;

      Add modules and Remove modules can be used only for primary objects (sender agreements for wildcard sender ICOs, wildcard receiver ICOs for receiver agreements, sender scenario in the bridges).

  • record messages to start configuring testing (to do it select the object(s) and click on Record messages button) - it opens Create recording requests dialog box;

  • create test case for PRO systems (to do it select the object and click Create Testcase) - it opens Test case creation page;

    Record messages and Create Testcase can be used only for primary objects (sender agreements for wildcard sender ICOs, wildcard receiver ICOs for receiver agreements, sender scenario in the bridges).

    Selected objects should be licensed for Testing (see Configure Object Licenses for details).

  • open details of integration objects (to do it click on recordings io or test cases io buttons) - it opens Integration Object Details page (see Integration Object Details page).

Integration Object Details page

Integration Object Details page includes several tabs with various information about integration object:

  1. Common Information tab shows the object metadata. It looks a little bit different for PRO and CPI objects:

    1. For PRO objects:

      io details pro

      Here you can open Tracked Object Details clicking on Tracked Object, and configure the following parameters:

      1. Channel selection strategy configures strategy applied to channels listed in Channels filter for modules update (EXCLUDE_CHANNELS (default) or INCLUDE_CHANNELS).

      2. Channels filter for modules update - is a list of communication channels which shouldn’t be updated (if Channel selection strategy is EXCLUDE_CHANNELS) or which should be updated (if Channel selection strategy is INCLUDE_CHANNELS). Start typing the communication channel name and select it to add it to the list.

        Channel selection strategy and Channels filter for modules update options must be configured for each ICO/SA/RA separately.
      3. Message interfaces which should be polled - is a list of message interfaces to be polled.

      4. Update channels with passwords. If false, it prevents updating of communication channels if they have password parameters in the modules chain.

      5. Has external sender. This option should be set manually if separate splitter scenario is used for triggering current scenario or when external correlation id is sent with the message and SAP Log Module or PI Message Log integration types are configured on Agent. Regarding the second case, it is required because we search Adapter Framework Data entries (entries in the SAP Message Monitoring) and determine root entries where root entry is calculated by default as an entry with matching interface info and without parent id and correlation id. Enabling Has external sender option disables some checks for root entry determination and makes it possible to have root entry with the link to external parent. But such configuration will cause issues when non-root messages with the same interface and with the link to real parent entry are fetched from SAP Message Monitoring.

    2. For CPI objects:

      io details cpi
  2. Recording Configuration tab shows current recording configuration and provides functionality to change the configuration. The following settings are configured:

    1. For PRO objects:

      io recording config PRO
      • Messages Count defines how many messages will be recorded.

      • per unique message/partner combination sets up a recording strategy per message/partner, so that expected message groups count means n messages per message/partner. It also requires a timeout is hours to define an expected period of recording.

      • Message Expression defines some specific text, e.g. 'demo2019'.

      • Partner Expression defines XPath expression, e.g. '//Seller'. This means that once it is processing this data it will then go into it.

      • Order expressions means when you are receiving messages if there are some correlation or some id that you need to use for ordering these. You need it if you have a message that being split, otherwise it is pretty difficult to see which of the messages you need to compare.

      • Message Filter and Partner Filter define interfaces to be recorded.

      • Use alphanumeric order number enables calculation of order number as a string instead of a number.

      • Don’t calculate order number for a single entry - if true, order number is set to 1 (if there are 1 inbound and 1 outbound messages).

      • Record synchronous service response if exists is used when you have sync call. We test it the following way:

        • You have a message that being processed.

        • The first part is the sender adapter.

        • Then we go to the receiver adapter.

        • We log it before it’s been sent to the SOAP channel for instance.

        • We log it in the response coming back from the SOAP channel.

        • We log it just before it’s delivered to livery segment system.

        • If Record synchronous service response if exists is true, we log response coming back and use that to set up testing.

    2. For CPI objects:

      io recording config CPI
      • Messages Count defines how many messages will be recorded.

      • Message Expression defines some specific text, e.g. 'demo2019'.

      • Partner Expression defines XPath expression, e.g. '//Seller'. This means that once it is processing this data it will then go into it.

      • Order expressions means when you are receiving messages if there are some correlation or some id that you need to use for ordering these. You need it if you have a message that being split, otherwise it is pretty difficult to see which of the messages you need to compare.

      • Use alphanumeric order number enables calculation of order number as a string instead of a number.

      • Don’t calculate order number for a single entry - if true, order number is set to 1 (if there are 1 inbound and 1 outbound messages).

      • Download MPL attachments - if true, MPL attachments are recorded.

      • Use only finishing run steps enables functionality when only the last messages in a test case will be compared. If true, Run steps selection strategy and Run steps filter (modelStepId or modelStepId|activity) can’t be set.

      • Run steps selection strategy and Run steps filter (modelStepId or modelStepId|activity) configure steps which should be recorded.

  3. Test Configuration tab shows test configurations of the integration object. There are the following properties can be configured here:

    1. Comparison Type defines used comparison strategy. Most of the time AUTO is fine.

    2. EDI functional group correlation key path defines path to data element or component element which can be used as a group identifier during comparison. Define a value if there are several functional groups in EDI outbound messages. The path format is described below.

    3. EDI message correlation key path defines path to data element or component element which can be used as a message identifier during comparison. Define a value if there are several messages in EDI outbound messages. Don’t define a value if there are several groups with 1 message in each group.

      EDI functional group correlation key path and EDI message correlation key path must be configured in the special format:

      <segment prefix><data element index><component element index (optional)>

      where:

      • <segment prefix> - shouldn’t contain [ or ], for example, UNE, DTM+137.

      • <data element index: for example, 1

      • <component element index: for example, 1

      Examples:

      • Only segment prefix: UNE, DTM+137.

      • Segment prefix with data element index: UNH[0], IMD[1].

      • Segment prefix with data element index and component element index: UNB[2][4].

    4. Item Ignore defines XPath expressions (divided by semicolon) to ignore, e.g. '/Invoice/Date'.

      For EDI type you can configure items in the special format

      <segment prefix><data element indexes and options><component element indexes (optional)>+<data element indexes and options><component element indexes (optional)>+<data element indexes and options><component element indexes (optional)>+...

      where:

      • <segment prefix> - shouldn’t contain [ or ], for example, UNE, DTM+137.

      • <data element indexes and options>: [<standalone/ranged index>, …​, <standalone/ranged index>|<option1>, <option2>]

      • <component element indexes>: [<standalone/ranged index>, …​, <standalone/ranged index>]

        • <standalone index>: for example, 1

        • <ranged index>: for example, 0-4

        • Available options:

          • empty-missing

          • java formatting which matches regex %[\\d.]*([dfeg]{1})$, for example: %.3f, %.6e.

      Examples:

      • Only segment prefix: UNE, DTM+137.

      • Segment prefix with data element indexes: UNH[0], IMD[0-2], IMD[0,2].

      • Segment prefix with data element indexes and options and component element indexes: UNB[0][1|empty-missing][0][2-5,7-8,9-10][4,5].

      For XML type you can configure items in the special format

      <XPath><options>

      where:

      • <XPath> - standard XPath expression, for example, //targetElem.

      • <options>: {{<option1>,<option2>}}

        • Available options:

          • empty-missing

          • java formatting which matches regex %[\\d.]*([dfeg]{1})$, for example: %.3f, %.6e.

      Examples:

      • Only XPath expression: //targetElem.

      • XPath expression with additional ignoring options: /targetElem{empty-missing,%.3f}.

    5. Message Properties Ignore defines dynamic properties (divided by semicolon) to ignore, e.g. 'X-Vcap-Request-Id'. If you have a lot of dynamic properties with the same prefix (e.g. DynamicProperty1 and DynamicProperty2), you can define just common prefix (DynamicProperty) to ignore all dynamic properties with this prefix during comparison.g

      Item Ignore and Message Properties Ignore properties can be configured during result comparison in Differences dialog that can be opened from Test Run Details page.

    6. Order Expressions defines how to order messages.

    7. Collection Item Identification Expressions (only for XML type) defines rules to compare a collection with the different order of elements in the expected and actual messages. This setting should be configured in the following format:

      <path to the collection>-><relative path to the identification element>

      If path to your collection is /example/collection and path to element identified collection id example/collection/object/id, then Collection Item Identification Expressions is /example/collection->object/id.

    8. Result Notification Delay (in minutes). When current test object is used in some test suite, value of this option is used in the calculation of the min amount of time between the time when test suite run report is generated and its sending through email. Result Notification Delay for test suite is calculated as the max of Result Notification Delay values configured for each test object used by this test suite. Configure delay properly when testing of current scenario takes a lot of time.

    9. Use alphanumeric order number enables calculation of order number as a string instead of a number.

    10. Don’t calculate order number for a single entry - if true, order number is set to 1 (if there are 1 inbound and 1 outbound messages).

    11. Use expected message encoding during comparison. Enable if you want to forcibly use encoding from expected message instead of dynamically determined encoding from actual result. Have effect only for the following message types: EDIFACT, X12, TEXT.

    12. For PRO objects you can configure additional settings for testing:

      1. Don’t use original receiver communication (mock endpoints) (for BE scenarios) enables testing with mock data. It uses the replacement of original receiver channel links in the test scenario by our REST channel links. For each original receiver channel, IRT creates and keeps actual the REST channel with the prefix FigafIRT_. That channel calls endpoint which just receives code 200 without the body. All custom modules from the original channel are copied to that REST channel. So requests to the original receiver are avoided.

      2. Use splitter - if true, B2B splitter is used. If you have B2B messages and you want to send them in with the B2B splitter, you can specify which scenario to set them up and to send them in with this specific splitter.

        io test config splitter

        There is also global splitter setting that you can use (see Agents integration configuration, field Default splitter on Agent dialog box).

      3. Decide to test with/without sender modules automatically - true by default. When sender communication channel has custom modules, the standard way of testing for PRO scenarios in IRT (through common infrastructure scenario) will not work correctly because these custom modules will not be triggered. IRT determines such case automatically if Decide to test with/without sender modules automatically is true, as a result, special infrastructure scenario will be created for making correct test. Otherwise you can decide to apply or not such behavior for current test object.

        After disabling Decide to test with/without sender modules automatically new option Run migration tests with modules on sender side is available. You have to decide by yourself should it be selected or not.

      4. Generate new numbers for each message - it adds the NumberRange Module to the test channel, so you can use the B2B NRO to maintain a list of numbers.

      5. Don’t send message after testing - it can be applied only to standard EO/EOIO scenarios and only when IRT Agent Module integration type is configured on Agent. Agent Module throws specific exception after processing of 2nd stage message (after sender mapping). Then IRT triggers cancellation of such message. As a result, the message is not sent to real receiver but tested in IRT. It causes critical limitation for BE scenarios because only sender mapping is tested.

      6. Test 3rd stage messages in baseline test cases - if true, it creates test run result for 3rd stage message (sync service response) so comparison between expected and actual results is processed.

    13. For CPI objects you can configure:

      1. Step Ignore defines model step ids and activity (e.g. 'MessageFlow_11|processExchange') or just model step id (e.g. 'CallActivity_16') to ignore. Several values are divided by semicolon.

        Step Ignore property can be configured in Differences dialog that can be opened from Test Run Details page.

      2. Don’t use original receiver communication (mock endpoints) enables testing with mock data. Linked test cases are run with replacing real receivers responses by previously recorded responses (from corresponding receivers) on Agent Object. IRT clones original test object (IFlow) with replacing sender and receiver channels to HTTPS where receiver channel endpoints are special IRT API. To use this mocking service you need to have configured IRT to use the cloud connector (see cloud connector properties configured in run command).

      3. Use only finishing run steps enables functionality when only the last messages in a test case will be compared. If true, Run steps selection strategy and Run steps filter (modelStepId or modelStepId|activity) can’t be set.

      4. Run steps selection strategy and Run steps filter (modelStepId or modelStepId|activity) configure steps which should be tested.

  4. Recording Requests tab looks:

    io recordings

    Several actions can be done on this tab:

    1. Viewing and managing recordings:

      1. Switching between 'New' and 'Started' recordings.

      2. Doing actions related to exact recording type:

        1. For both 'New' and 'Started' recordings you can configure or view recording configuration clicking on dots icon and then on Config button and copy recording clicking on dots icon and then on Copy button. It opens 'Copy Recording Requests' dialog box.

          copy recordings dialog

          In this dialog box you can configure created recording:

          1. Fetch policy switches the way how messages will be fetched from the message monitoring. There are two possible values:

            • Fetch historic messages - takes messages from message monitoring in order of their creation depending on specified period in Historic lookup period property (the left bound is calculated as current time minus specified lookup period). When you use Fetch historic messages option, be sure that historic messages have enough metadata to record them. For SAP Log Module integration type messages should have logged state with irtLogStage<x> labels, where x=1…4, for PI Message Log integration type messages should have logged state with BI and AM labels.

            • Fetch future messages - only messages sent after recording creation will be recorded.

              Fetch historic messages is used only when Agent has Messages retrieving way equals to SAP Log Module or PI Message Log (see Agents integration configuration).
          2. RD historic lookup period (only for PRO agents) is shown for agents with enabled dual stack recording (see property Enable dual stack recording on Agents integration configuration) and similar to Historic lookup period (only for PRO Agents).

          3. Update channels with password (PRO Agents).

          4. You can configure more properties clicking on config:

            • For PRO objects:

              • Messages Count defines how many messages will be recorded.

              • per unique message/partner combination sets up a recording strategy per message/partner, so that expected message groups count means n messages per message/partner. It also requires a timeout is hours to define an expected period of recording.

              • Message Expression defines some specific text, e.g. 'demo2019'.

              • Partner Expression defines XPath expression, e.g. '//Seller'. This means that once it is processing this data it will then go into it.

              • Order expressions means when you are receiving messages if there are some correlation or some id that you need to use for ordering these. You need it if you have a message that being split, otherwise it is pretty difficult to see which of the messages you need to compare.

              • Message Filter and Partner Filter define interfaces to be recorded.

              • Use alphanumeric order number enables calculation of order number as a string instead of a number.

              • Don’t calculate order number for a single entry - if true, order number is set to 1 (if there are 1 inbound and 1 outbound messages).

              • Record synchronous service response if exists is used when you have sync call. We test it the following way:

                • You have a message that being processed.

                • The first part is the sender adapter.

                • Then we go to the receiver adapter.

                • We log it before it’s been sent to the SOAP channel for instance.

                • We log it in the response coming back from the SOAP channel.

                • We log it just before it’s delivered to livery segment system.

                • If Record synchronous service response if exists is true, we log response coming back and use that to set up testing.

            • For CPI objects:

              • Messages Count defines how many messages will be recorded.

              • Message Expression defines some specific text, e.g. 'demo2019'.

              • Partner Expression defines XPath expression, e.g. '//Seller'. This means that once it is processing this data it will then go into it.

              • Order expressions means when you are receiving messages if there are some correlation or some id that you need to use for ordering these. You need it if you have a message that being split, otherwise it is pretty difficult to see which of the messages you need to compare.

              • Use alphanumeric order number enables calculation of order number as a string instead of a number.

              • Don’t calculate order number for a single entry - if true, order number is set to 1 (if there are 1 inbound and 1 outbound messages).

              • Download MPL attachments - if true, MPL attachments are recorded.

              As a result of recording coping, new recording will be created. It can be in New or Started state (it depends on value of Start recording immediately property).

        2. For 'New' recordings you can:

          1. Delete selected recording requests clicking on red trash button.

          2. Start selected recordings clicking on play button. After the recordings are started they should be removed from new recordings table and be added to started recordings table.

        3. For 'Started' recordings you can:

          1. Stop selected recordings clicking on stop button.

            In current version of IRT recordings are not stopped, they are deleted.
          2. Create Test Cases clicking on play with plus button. It opens 'Test Case creation' dialog box. After test case is created the source recording should be removed from started recordings table.

            1. You should create test cases for recordings having recorded inbound/outbound messages, otherwise you will get the error.

            2. You can create test cases for recordings having not enough (less than configured Messages Count) recorded inbound/outbound messages, then test case with available messages will be created, and recording will stay in Started Recordings table (having less messages count).

          3. Poll remote messages clicking on Poll remote messages button. Before polling remote messages you should send the messages to the scenario or wait for messages if the scenario is scheduled, otherwise, you won’t get any messages.

            You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

            Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

            Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

            • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

            • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

            If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

          4. Open last polling result clicking on Open Last Polling Result button.

            Open Last Polling Result button is available after polling remote data and until page is refreshed.

    2. Viewing recording details clicking on details. It opens 'Recording Request Details' page.

    3. Viewing related test suites clicking on Test Suite Title. It opens Test Suite: Test Suite Title page page.

  5. Agent Test Cases tab shows test cases which have current Integration Object as Agent Object. This tab looks:

    io agent test cases

    On this tab you can:

    1. View test case details clicking on details. It opens Test Case Details page.

    2. Select the test case(s) and do actions:

      1. Run the test case(s) clicking on run or run on buttons:

        • Run uses static links to test objects defined in the test case.

        • Run on resolves these links dynamically at the moment of test run. It is possible to see how these links are resolved through Current Mapping Configuration button - it opens 'Mapping Configuration' dialog box:

          mapping configuration

          There are Agent Objects (parent nodes) and Test Objects (child nodes) in opened dialog box.

    3. Click on table’s menu full button and choose:

      1. Create Test Case (PRO) opens Test case creation page.

      2. Merge Test Cases merges two selected test cases' messages. It removes previous test cases run results.

        You should select two test cases with the same Agent Object, Message and Partner.
      3. Add to test suite adds selected test case(s) to new or existing test suite. It opens 'Create Test Suite' dialog box:

        create test suite

        You can choose to create new test suite or to use existing one. If you enable Open Test Suite’s page after creation option, Test Suite: Test Suite Title page will be opened after saving.

      4. Trim tests removes messages from selected test case(s). It keeps number of inbound messages equals to the value of How many messages to keep in the test case? property of 'Trim Test Cases' dialog box:

        trim test case
      5. Migrate to CPI IFlow (PRO) migrates PI test cases to CPI (see Migrate test cases from PI to CPI scenario). It opens Migrate Test Cases dialog:

        migrate test cases dialog

        Where you can configure test suite (new or existent one) and CPI IFlow. If you want to open Test Suite: Test Suite Title page, enable Open Test Suite’s page after test cases migration option.

        Once you configure all fields, click on Save. It opens confirmation:

        migrate test cases confirmation

        As the result, new test case will be created and attached to the test suite.

        During the copying of the messages, interface related parameters (stepId, activity, branchId) of the last stage are initialized by value ${determineDuringFirstRun}. For other stages for bridges and BE scenario value ${shouldBeMappedManually} is used. Original stage number is temporary saved in the step number, then it will be replaced by real value - it needs for BE and bridges to distinguish different original stages.

      6. Delete removes selected test case(s).

      7. Clean removes all test run results and reports of selected test case(s).

  6. Linked Test Cases tab shows test cases which have current Integration Object as test object. This tab looks:

    io linked test cases

    On this tab you can:

    1. View test case details clicking on details. It opens Test Case Details page.

    2. Select the test case(s) and do actions:

      1. Run the test case(s) clicking on run or run on buttons:

        • Run uses static links to test objects defined in the test case.

        • Run on resolves these links dynamically at the moment of test run. It is possible to see how these links are resolved through Current Mapping Configuration button - it opens 'Mapping Configuration' dialog box:

          mapping configuration

          There are Agent Objects (parent nodes) and Test Objects (child nodes) in opened dialog box.

      2. Detach link between current Integration Object and selected test case clicking on Detach button.

7.3.2. Test Suites page

Test Suites page shows all existing test suites. The page looks:

test suites

On this page you can:

  • view test suites unrelated or related to tickets (to see test suites related to tickets click on Hide Ticket related Test Suites switcher);

  • delete selected test suite(s) clicking on Delete;

  • delete selected test suite(s) run results clicking on Clean;

  • run selected test suite(s) clicking on play blue;

  • view test suite details clicking on details button. It opens 'Test Suite: Test Suite Title' page (see Test Suite: Test Suite Title page).

Test Suite: Test Suite Title page

Test Suite: Test Suite Title page includes several tabs with various data related to the test suite:

On each tab you are able to edit the test suite data (to start editing click on edit button):

  • Test Suite Title.

    Test Suite Title must be unique.
  • Scheduled - if true, TestSuiteRunner task runs this test suite according to configured cron expression (configure TestSuiteRunner property on Application Configuration page).

    Agent Objects used for testing should be licensed, otherwise, scheduled test suites won’t be run.
  • Send report by email - if true, TestSuiteResultNotifier task sends test suite excel report to email configured on Application Configuration page (configure TestSuiteResultNotifier, SMTP host, SMTP port, SMTP username, ` SMTP password`, Email Protocol, Email From, Email To properties on Application Configuration page).

  • Use default test systems for running enables Run on behavior for scheduled test suite running - test suite will be run on all Agents licensed as test systems excluding marked as production systems.

    You can check licensed Agents on License page. Production systems can be checked on Agent dialog box.

To save changes click on save button, to reset - reset.

To run the test suite click on run or run on buttons:

  • Run uses static links to test objects defined in the test case.

  • Run on resolves these links dynamically at the moment of test run. It is possible to see how these links are resolved through Current Mapping Configuration button - it opens 'Mapping Configuration' dialog box:

    mapping configuration

    There are Agent Objects (parent nodes) and Test Objects (child nodes) in opened dialog box.

You can’t run test suite without linked test cases.
  1. NEW RECORDINGS tab looks:

    ts new recordings

    Here you can:

    1. View Agent Object clicking on Agent Object Title (it opens Integration Object Details page).

    2. Delete and start selected recordings (see corresponding actions here).

    3. Update recording configuration clicking on dots icon and then on Config button (see settings here).

    4. Copy recording clicking on dots icon and then on Copy button (see settings here).

  2. STARTED RECORDINGS tab shows all started recordings in current test suite and looks:

    ts started recordings

    Here you can:

    1. View Agent Object clicking on Agent Object Title (it opens Integration Object Details page).

    2. Stop recordings, create test case, poll remote messages, view recording details (see corresponding actions here).

    3. Delete and start selected recordings (see corresponding actions here).

    4. View recording configuration clicking on dots icon and then on Config button (see settings here).

    5. Copy recording clicking on dots icon and then on Copy button (see settings here).

  3. LINKED TEST CASES tab shows test cases linked to current test suite and looks:

    ts linked test cases

    Here you can:

    1. View Agent Object clicking on Agent Object Title (it opens Integration Object Details page).

    2. Add test cases clicking on plus button. It opens 'Add Test Cases to the test suite' dialog box:

      ts add test cases dialog

      Just select the Agent, the object and required test cases and click on 'OK'.

    3. Select test case(s) and do actions:

      1. Detach test case(s) from test suite clicking on red trash button. It deletes the link between current test suite and selected test case(s).

      2. Extract recordings from selected test cases clicking on copy button. It opens 'Copy Recording Requests' dialog box (see Copy Recordings Dialog box).

    4. View test case details clicking on details button. It opens Test Case Details page.

  4. LAST RESULT tab shows last test suite run result and looks:

    ts last result

    On this tab you can:

    1. View Agent and Test Objects clicking on Agent Object Title or Test Object Title. It opens Integration Object Details page.

    2. Poll remote results clicking on Poll remote results.

      You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

      Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

      Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

      • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

      • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

      If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

    3. View last polling result clicking on Open Last Polling Result.

      Open Last Polling Result button is available after polling remote data and until page is refreshed.
    4. Export as a test case to PIT (only for PRO) clicking on Export as a Test Case to PIT.

      Export as a Test Case to PIT is available only for licensed version after the test suite running.
    5. Compare testing results and build reports clicking on check button.

      The option reprocesses comparison and report generation asynchronously. It makes sense to execute the option once you have configured a new "ignore rule".
    6. Do the following actions clicking on menu and choosing corresponding option:

      1. Rerun reruns required test case.

      2. View testcase opens 'Test Case Details' page.

      3. Download report.

        Report type can be one of 2 types:

        1. xlsx report:

          • Contains information about test run/test suite run results.

          • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

        2. zip archive with 3 csv reports:

          • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

          • diff-report.csv - contains diff report for test run/test suite run.

          • processed-messages-report.csv - contains processed messages report for test run/test suite run.

        The report type is defined from Use bundled CSV report generation strategy property configured on Configuration → Application page. If it’s true, the report type is zip, otherwise, it’s xlsx.

      4. View results opens Test Run Details page.

  5. RESULTS HISTORY tab shows results of all test suite runs and looks:

    ts results history

    On this tab you can:

    1. Configure Running Date filter to hide some test suite run results.

    2. Select the result and do actions:

      1. Compare testing results and build reports clicking on check button.

        The option reprocesses comparison and report generation asynchronously. It makes sense to execute the option once you have configured a new "ignore rule".
      2. Poll remote results for unfinished runs clicking on Poll remote results.

        You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

        Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

        Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

        • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

        • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

        If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

      3. View last polling result clicking on Open Last Polling Result.

        Open Last Polling Result button is available after polling remote data and until page is refreshed.
      4. Export as a test case to PIT (only for PRO) clicking on Export as a Test Case to PIT.

      5. Delete testing results clicking on red trash button.

    3. Download report of the test suite run result clicking on download button in the table row.

      Report type can be one of 2 types:

      1. xlsx report:

        • Contains information about test run/test suite run results.

        • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

      2. zip archive with 3 csv reports:

        • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

        • diff-report.csv - contains diff report for test run/test suite run.

        • processed-messages-report.csv - contains processed messages report for test run/test suite run.

      The report type is defined from Use bundled CSV report generation strategy property configured on Configuration → Application page. If it’s true, the report type is zip, otherwise, it’s xlsx.

    4. View Test Suite Run details clicking on details. It opens Test Suite Run page.

7.3.3. Test Suite Runs page

Test Suite Runs page shows the test suites that were run in period defined in Running Date filter and looks:

ts runs

The following actions are available on this page:

  1. Viewing test suite details: click on Test Suite and it opens Test Suite: Test Suite Title page.

  2. Testing results comparison and reports building clicking on check button.

    The option reprocesses comparison and report generation asynchronously. It makes sense to execute the option once you have configured a new "ignore rule".
  3. Remote results polling. Select unfinished test suite run(s) and click on Poll remote results button.

    You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

    Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

    Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

    • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

    • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

    If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

  4. Downloading consolidated diff report for test suite runs. Select test suite run(s) and click on Diff report button. It will take diff info from all related test runs/test run results with ERROR status and build CSV file (semicolon as a separator) with the following information:

    consolidated diff report

    Combination of fields Message, Partner, Diff State, Old Value, New Value organize a unique key, Affected Test Suites and Affected Messages count are aggregated. Affected Messages count - is count of failed test run results (outbound messages) which contain the error determined by the key. Obviously, if some error occurred in one message several times, that message will be counted only once.

    Correlation between old and new value for now properly added only for EDI types (EDIFACT and X12).

  5. Export as a test case to PIT.

  6. Deleting selected testing results.

  7. Downloading report.

    Report type can be one of 2 types:

    1. xlsx report:

      • Contains information about test run/test suite run results.

      • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

    2. zip archive with 3 csv reports:

      • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

      • diff-report.csv - contains diff report for test run/test suite run.

      • processed-messages-report.csv - contains processed messages report for test run/test suite run.

    The report type is defined from Use bundled CSV report generation strategy property configured on Configuration → Application page. If it’s true, the report type is zip, otherwise, it’s xlsx.

  8. Viewing Test Suite Run details clicking on details. It opens Test Suite Run page.

Test Suite Run page

Test Suite Run page opens a historical test suite run and browse related test runs:

ts run page

On this page you can:

  1. View linked test suite. It opens Test Suite: Test Suite Title page.

  2. Download test suite run report clicking on download ts run report. This button is disabled if report is not ready.

    Report type can be one of 2 types:

    1. xlsx report:

      • Contains information about test run/test suite run results.

      • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

    2. zip archive with 3 csv reports:

      • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

      • diff-report.csv - contains diff report for test run/test suite run.

      • processed-messages-report.csv - contains processed messages report for test run/test suite run.

    The report type is defined from Use bundled CSV report generation strategy property configured on Configuration → Application page. If it’s true, the report type is zip, otherwise, it’s xlsx.

  3. Work with test runs:

    1. View Agent and Test Objects clicking on Agent Object Title or Test Object Title. It opens Integration Object Details page.

    2. Poll remote results clicking on Poll remote results.

      You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

      Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

      Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

      • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

      • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

      If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

    3. View last polling result clicking on Open Last Polling Result.

      Open Last Polling Result button is available after polling remote data and until page is refreshed.
    4. Compare testing results and build reports clicking on check button.

      The option reprocesses comparison and report generation asynchronously. It makes sense to execute the option once you have configured a new "ignore rule".
    5. Do the following actions clicking on menu and choosing corresponding option:

      1. Rerun reruns required test case.

      2. View testcase opens 'Test Case Details' page.

      3. Download report.

        Report type can be one of 2 types:

        1. xlsx report:

          • Contains information about test run/test suite run results.

          • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

        2. zip archive with 3 csv reports:

          • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

          • diff-report.csv - contains diff report for test run/test suite run.

          • processed-messages-report.csv - contains processed messages report for test run/test suite run.

        The report type is defined from Use bundled CSV report generation strategy property configured on Configuration → Application page. If it’s true, the report type is zip, otherwise, it’s xlsx.

      4. View results opens Test Run Details page.

7.3.4. Test Cases page

Test Cases page shows all existing test cases and looks:

test cases

On this page you can:

  1. View Agent Object clicking on Agent object. It opens Integration Object Details page.

  2. View Test Objects clicking on corresponding menu full button and selecting the object. It opens Integration Object Details page.

  3. View Test Suites clicking on corresponding menu full button and selecting the test suite. It opens Test Suite: Test Suite Title page.

  4. Run selected test case(s) clicking on run or run on buttons:

    • Run uses static links to test objects defined in the test case.

    • Run on resolves these links dynamically at the moment of test run. It is possible to see how these links are resolved through Current Mapping Configuration button - it opens 'Mapping Configuration' dialog box:

      mapping configuration

      There are Agent Objects (parent nodes) and Test Objects (child nodes) in opened dialog box.

  5. Click on table’s menu full button and choose:

    1. Create Test Case opens Test case creation page.

    2. Merge Test Cases merges two selected test cases' messages. It removes previous test cases run results.

      You should select two test cases with the same Agent Object, Message and Partner.
    3. Add to test suite adds selected test case(s) to new or existing test suite. It opens 'Create Test Suite' dialog box:

      create test suite

      You can choose to create new test suite or to use existing one. If you enable Open Test Suite’s page after creation option, Test Suite: Test Suite Title page will be opened after saving.

    4. Trim tests removes messages from selected test case(s). It keeps number of inbound messages equals to the value of How many messages to keep in the test case? property of 'Trim Test Cases' dialog box:

      trim test case
    5. Delete removes selected test case(s).

    6. Clean removes all test run results and reports of selected test case(s).

  6. View Details of the test case clicking on it’s details button. It opens Test Case Details page.

Test Case Details page

Test Case Details page includes several tabs with various data related to the test suite:

  1. Test Case Information tab shows general information about the test case, linked test objects and test suites. This tab looks:

    tc info

    On this tab you can:

    1. Edit the test case title, message or partner (to start editing click on edit button). To save changes click on save button, to reset - reset.

    2. View Agent Object clicking on Agent Object Title. It opens Integration Object Details page.

    3. View Test Objects clicking on required Test Object Title. It opens Integration Object Details page.

    4. View Test Suites that the test case is linked to clicking on required Test Suite Title. It opens Test Suite: Test Suite Title page.

    5. Add or remove Test Object(s) clicking on plus or decline buttons respectively.

      Test Objects are only from the same platform as Agent Object can be added.
    6. Add the test case to new or existing Test Suite or remove the test case from Test Suite(s) clicking on plus or decline buttons respectively.

  2. Messages tab shows inbound/outbound messages in the test case and looks differently for PRO and CPI Agent Objects:

    1. For PRO Agent Objects:

      tc messages pro

      The following actions can be executed for both PRO and CPI Agent Objects:

      1. Calculate ordering numbers.

      2. Options available in the message’s menu button:

        1. View/Edit message opens 'Message Details' page.

        2. Delete message group removes all messages with the same 'Inb. Group' as the one that the option selected for.

        3. Copy message group copies all messages (with the same 'Inb. Group' as the one that the option selected for) to selected test case(s).

        4. Change interface metadata opens 'Change message interface metadata' dialog box:

          change message metadata

          You can configure required changes here. Change messages globally applies changes to all messages with 'Source Message Interface Metadata'.

        5. Download downloads message xml file for PRO and file without extension for CPI.

    2. For CPI Agent Objects:

      tc messages cpi

      The following actions can be executed for CPI Agent Objects:

      1. Generate groovy scripts test data generates groovy scripts (see Groovy scripts unit testing).

      2. Options available in the message’s menu button:

        1. Build groovy script generates groovy script (see Groovy scripts unit testing).

        2. Generate test data for current message generates json.

  3. Messages Anonymization tab helps to configure anonymized test case based on current test case and looks:

    tc message anonym
    It works only for XML messages.

    On this tab you can:

    1. Add message mappings selecting Message group id and clicking twice on the element you want to anonymize:

      message anonymization create
      You also can add message mappings clicking on plus button in Applied mappings table. In such case you have to define Element path by yourself.

      It opens 'Create mapping' dialog box:

      create mapping

      Select desired function:

      • Multiply by random value from range multiplies source values by a random number from the range defined by values of From and to properties. If you want to get integers, set Count of number after a decimal point property value as 0, otherwise, define desired value. Example with filled properties:

        create mapping random ex

        To test function enter Test value and click on Test function.

      • Generate value from template generates values from Template property value. You can define template using special characters ('#' for number, '?' for uppercased character, '*' for lowcased character, e.g. ### - template for 3 random numbers) or anonymization variables defined in Anonymization variables, e.g. $Figaf ${lastname}. Example with filled properties:

        create mapping template ex

        To test function click on Test function.

    2. Edit message mapping clicking on edit button in Applied mappings table.

    3. Delete message mapping clicking on decline button in Applied mappings table.

    4. Create new test case with anonymized data clicking on Clone anonymized test case button. It opens 'Clone anonymized test case' dialog box:

      clone anonymized tc

      After submitting the dialog new test case will be created.

  4. Testing Results tab shows the test case run results and looks:

    tc results

    On this tab you can:

    1. View Test Object clicking on 'Test Object'. It opens Integration Object Details page.

    2. Run the test case clicking on run or run on buttons:

      • Run uses static links to test objects defined in the test case.

      • Run on resolves these links dynamically at the moment of test run. It is possible to see how these links are resolved through Current Mapping Configuration button - it opens 'Mapping Configuration' dialog box:

        mapping configuration

        There are Agent Objects (parent nodes) and Test Objects (child nodes) in opened dialog box.

    3. Select test case run result(s) and:

      1. Poll remote messages and Open Last Polling Result.

        You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

        Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

        Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

        • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

        • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

        If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

        Open Last Polling Result button is available after polling remote data and until page is refreshed.

      2. Compare results clicking on check.

        The option reprocesses comparison and report generation asynchronously. It makes sense to execute the option once you have configured a new "ignore rule".
      3. Delete the result(s) clicking on red trash.

    4. The options available in result’s menu button:

      1. Download report.

        Report type can be one of 2 types:

        1. xlsx report:

          • Contains information about test run/test suite run results.

          • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

        2. zip archive with 3 csv reports:

          • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

          • diff-report.csv - contains diff report for test run/test suite run.

          • processed-messages-report.csv - contains processed messages report for test run/test suite run.

        The report type is defined from Use bundled CSV report generation strategy property configured on Configuration → Application page. If it’s true, the report type is zip, otherwise, it’s xlsx.

      2. View results opens Test Run Details page.

      3. Mark as Test Case creates new test case from chosen groups of testing results. Testing results become expected messages in the new test case.

      4. Update Test Case using Test Run Results replaces all messages in current test case by chosen groups of testing results.

7.3.5. Test Case Runs page

Test Case Runs page shows the test cases that were run in period defined in Running Date filter and looks:

test case runs

On this page you can:

  1. Poll remote messages.

    Open Last Polling Result button is available after polling remote data and until page is refreshed.

  2. Compare results clicking on check.

    The option reprocesses comparison and report generation asynchronously. It makes sense to execute the option once you have configured a new "ignore rule".
  3. View Agent Object clicking on 'Agent Object'. It opens Integration Object Details page.

  4. View Test Object clicking on 'Test Object'. It opens Integration Object Details page.

  5. The options available in run’s menu button:

    1. Download report.

      Report type can be one of 2 types:

      1. xlsx report:

        • Contains information about test run/test suite run results.

        • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

      2. zip archive with 3 csv reports:

        • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

        • diff-report.csv - contains diff report for test run/test suite run.

        • processed-messages-report.csv - contains processed messages report for test run/test suite run.

      The report type is defined from Use bundled CSV report generation strategy property configured on Configuration → Application page. If it’s true, the report type is zip, otherwise, it’s xlsx.

    2. View results opens Test Run Details page.

Test Run Details page

Test Run Details page looks:

test run details

On this page you can:

  1. Poll remote messages.

    Open Last Polling Result button is available after polling remote data and until page is refreshed.

  2. Compare results clicking on check.

    The option reprocesses comparison and report generation asynchronously. It makes sense to execute the option once you have configured a new "ignore rule".
  3. Open related test case. It opens Test Case Details page.

  4. Open related test suite run. It opens Test Suite Run page. The link is shown only if you run test suite linked with related test case.

  5. Open Agent and Test Objects.

  6. View ignore lists (Applied items ignore expressions and Applied Message properties ignore expressions). IT shows ignore lists configured on Test Configuration tab of Integration Object page.

  7. Open actual test configuration. It opens Test Configuration tab of Integration Object page.

  8. View used comparison configurations. It opens Comparison Configuration dialog.

  9. Execute actions available in run’s menu full button:

    1. Download report.

      Report type can be one of 2 types:

      1. xlsx report:

        • Contains information about test run/test suite run results.

        • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

      2. zip archive with 3 csv reports:

        • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

        • diff-report.csv - contains diff report for test run/test suite run.

        • processed-messages-report.csv - contains processed messages report for test run/test suite run.

      The report type is defined from Use bundled CSV report generation strategy property configured on Configuration → Application page. If it’s true, the report type is zip, otherwise, it’s xlsx.

    2. Mark selected message group as Test Case. IT creates new test case from chosen groups of testing results. Testing results become expected messages in the new test case.

    3. Update Test Case using Test Run Results replaces all messages in current test case by chosen groups of testing results.

  10. Execute actions available in message’s menu button:

    1. View result. It opens Test Run Result page.

    2. Download inbound message, expected result, actual result.

    3. Build groovy script (see Groovy scripts unit testing).

    4. Diffs opens Differences dialog box. Here you can add items (click twice on the required item) and message properties (click on the required message property) to ignore list.

      Add items and message properties to ignore list once.

      differences add to ignore list
    5. Binary diffs opens Differences dialog box (see above) with binary comparison.

    6. Ignore step (CPI) adds current step to ignore list.

    7. Browse related messages (PRO) is runtime viewer for related message monitoring entries. It looks for message monitoring entries on the PI system by the currently persisted PI message id (used in id and refId filters). For not received entries we know only the id of the sent message, then once the message is received it’s overwritten by a related AFD message id.

      test run related messages

      From the Related messages dialog it’s possible to open PI message page on SAP system and browse message log in the separate dialog:

      test run message log

      Use these options to analyze the root cause of the UNFINISHED state of the result to check what’s going on on PI system.

    8. Open message monitor (PRO).

    9. Open message monitor via dispatcher (PRO).

7.3.6. Shared Configuration page

Shared Configuration page contains shared configurations and looks:

comparison configuration

On this page you can:

  1. Create shared configuration clicking on plus button. It opens Create shared configuration:

    create comparison configuration dialog
    1. Title of shared configuration. Should be unique.

    2. Platform for which shared configuration should be configured.

    3. Use is the way which should be used during shared configuration determination: Messages/Partners or Test Cases.

      1. Messages is messages list. for which the shared configuration is applied.

      2. Partners is partners list. for which the shared configuration.

      3. Test Cases is test cases list. This configuration can be used if you want to run different test cases with different configurations.

    4. Integration Objects is integration objects list. All integration objects are from the same agent.

      Shared configuration is applied to any combinations of Messages, Partners, Test Cases, and Integration Objects values during comparison.
    5. Comparison Type defines used comparison strategy. Most of the time AUTO is fine.

    6. EDI functional group correlation key path defines path to data element or component element which can be used as a group identifier during comparison. Define a value if there are several functional groups in EDI outbound messages. The path format is described below.

    7. EDI message correlation key path defines path to data element or component element which can be used as a message identifier during comparison. Define a value if there are several messages in EDI outbound messages. Don’t define a value if there are several groups with 1 message in each group.

      EDI functional group correlation key path and EDI message correlation key path must be configured in the special format:

      <segment prefix><data element index><component element index (optional)>

      where:

      • <segment prefix> - shouldn’t contain [ or ], for example, UNE, DTM+137.

      • <data element index: for example, 1

      • <component element index: for example, 1

      Examples:

      • Only segment prefix: UNE, DTM+137.

      • Segment prefix with data element index: UNH[0], IMD[1].

      • Segment prefix with data element index and component element index: UNB[2][4].

    8. Item Ignore defines XPath expressions (divided by semicolon) to ignore, e.g. '/Invoice/Date'.

      For EDI type you can configure items in the special format

      <segment prefix><data element indexes and options><component element indexes (optional)>+<data element indexes and options><component element indexes (optional)>+<data element indexes and options><component element indexes (optional)>+...

      where:

      • <segment prefix> - shouldn’t contain [ or ], for example, UNE, DTM+137.

      • <data element indexes and options>: [<standalone/ranged index>, …​, <standalone/ranged index>|<option1>, <option2>]

      • <component element indexes>: [<standalone/ranged index>, …​, <standalone/ranged index>]

        • <standalone index>: for example, 1

        • <ranged index>: for example, 0-4

        • Available options:

          • empty-missing

          • java formatting which matches regex %[\\d.]*([dfeg]{1})$, for example: %.3f, %.6e.

      Examples:

      • Only segment prefix: UNE, DTM+137.

      • Segment prefix with data element indexes: UNH[0], IMD[0-2], IMD[0,2].

      • Segment prefix with data element indexes and options and component element indexes: UNB[0][1|empty-missing][0][2-5,7-8,9-10][4,5].

      For XML type you can configure items in the special format

      <XPath><options>

      where:

      • <XPath> - standard XPath expression, for example, //targetElem.

      • <options>: {{<option1>,<option2>}}

        • Available options:

          • empty-missing

          • java formatting which matches regex %[\\d.]*([dfeg]{1})$, for example: %.3f, %.6e.

      Examples:

      • Only XPath expression: //targetElem.

      • XPath expression with additional ignoring options: /targetElem{empty-missing,%.3f}.

    9. Message Properties Ignore defines dynamic properties (divided by semicolon) to ignore, e.g. 'X-Vcap-Request-Id'. If you have a lot of dynamic properties with the same prefix (e.g. DynamicProperty1 and DynamicProperty2), you can define just common prefix (DynamicProperty) to ignore all dynamic properties with this prefix during comparison.g

      Item Ignore and Message Properties Ignore properties can be configured during result comparison in Differences dialog that can be opened from Test Run Details page.

    10. Order Expressions defines how to order messages.

    11. Collection Item Identification Expressions (only for XML type) defines rules to compare a collection with the different order of elements in the expected and actual messages. This setting should be configured in the following format:

      <path to the collection>-><relative path to the identification element>

      If path to your collection is /example/collection and path to element identified collection id example/collection/object/id, then Collection Item Identification Expressions is /example/collection->object/id.

    12. Use alphanumeric order number enables calculation of order number as a string instead of a number.

    13. Don’t calculate order number for a single entry - if true, order number is set to 1 (if there are 1 inbound and 1 outbound messages).

    14. Use expected message encoding during comparison. Enable if you want to forcibly use encoding from expected message instead of dynamically determined encoding from actual result. Have effect only for the following message types: EDIFACT, X12, TEXT.

    15. Test with mock data (CPI only) enables testing with mock data. Linked test cases are run with replacing real receivers responses by previously recorded responses (from corresponding receivers) on Agent Object. IRT clones original test object (IFlow) with replacing sender and receiver channels to HTTPS where receiver channel endpoints are special IRT API. To use this mocking service you need to have configured IRT to use the cloud connector (see cloud connector properties configured in run command).

    16. Use only finishing run steps (CPI only) enables functionality when only the last messages in a test case will be compared. If true, Run steps selection strategy and Run steps filter (modelStepId or modelStepId|activity) can’t be set.

    17. Run steps selection strategy (CPI only) and Run steps filter (modelStepId or modelStepId|activity) (CPI only) configure steps which should be tested.

  2. Edit/View shared configuration clicking on its edit or view button.

  3. Delete selected shared configurations.

  4. View messages, partners, test cases, and integration objects lists clicking on corresponding menu full button.

8. Operations

8.1. Get started with Operations

8.1.1. Receiving alerts from PRO system

At least 1 PRO Agent System should be configured. See that section to learn how to do that.

You should have enough systems licensed for monitoring (Number Of Systems For Monitoring property on License Configuration page) and Monitoring License End Date should be valid, otherwise it won’t be possible to create a consumer.

IRT uses consumers defined in alert rules on PRO System as a data source for retrieving Message Monitoring alerts. It’s important to note that it’s possible to fetch an alert from the specific consumer only one time, that’s why you need to create a specific consumer for IRT application and declare it only once in one IRT application. Otherwise, messages won’t be received properly.

To configure receiving alert process from PRO system do the following:

  1. Create new consumer on your PRO system:

    1. Use Integration Directory builder to manage alert rules and their consumers.

    2. Chose an existent alert rule or create a new one, configure it, and then add a new consumer, e.g., IRT_PRIMARY_CONSUMER.

      pro consumer config
  2. Open Support Tool page in IRT.

  3. Click on Manage Consumers. It opens Manage Consumers dialog box:

    manage consumers
  4. Select your PRO Agent system, click on Create Consumer, type the name of PRO consumer you have created before (in our example IRT_PRIMARY_CONSUMER), and save a new consumer.

    You will be asked about enabling alerts handling and reprocessing jobs, approve that action if you want to have handle new alerts automatically. You can disable them or change scheduling settings later on Application Configuration page. Consumer is created with a new default IRT rule, we will explain rules in further sections. It just needs to be noticed that default IRT rule doesn’t add anything to your filter configured on PRO alert rule.

  5. Now you can open Alerts tab and click on Poll Alerts to trigger lookup manually, or wait for a scheduled job if it’s enabled.

    pro alerts tab

8.1.2. Receiving alerts from CPI system

At least 1 CPI Agent System should be configured. See that section to learn how to do that.

You should have enough systems licensed for monitoring (Number Of Systems For Monitoring property on License Configuration page) and Monitoring License End Date should be valid, otherwise it won’t be possible to create a consumer.

To configure receiving alert process from CPI system do the following:

  1. Open Support Tool page in IRT.

  2. Click on Manage Consumers. It opens Manage Consumers dialog box:

    manage consumers
  3. Select your CPI Agent system, click on Create Consumer, type the name, and save the consumer.

    You will be asked about enabling alerts handling and reprocessing jobs, approve that action if you want to have handle new alerts automatically. You can disable them or change scheduling settings later on Application Configuration page. Consumer is created with a new default IRT rule. It just needs to be noticed that default IRT rule doesn’t add anything to your filter configured on IRT consumer for CPI Agent.

  4. Now you can open Alerts tab and click on Poll Alerts to trigger lookup manually, or wait for a scheduled job if it’s enabled.

    cpi alerts tab

8.1.3. Receiving alerts from Api Management system

At least 1 Api Management Agent System should be configured. See that section to learn how to do that.

You should have enough systems licensed for monitoring (Number Of Systems For Monitoring property on License Configuration page) and Monitoring License End Date should be valid, otherwise it won’t be possible to create a consumer.

IRT processes alerts only for Api Proxy objects with configured Figaf error handling policies. It’s important to note that it’s possible to fetch one entry only once, so you should configure IRT consumers without intersections, otherwise some consumers won’t receive alerts.

To configure receiving alert process from Api Management system do the following:

  1. Open Change Tracking Tool in IRT.

  2. View object details page for required Api Proxy. Click on Add/Reset Figaf error handling policies button to enable alert processing for the object. It creates new object version. Repeat this step for all Api Proxy objects.

  3. Open Support Tool page in IRT.

  4. Click on Manage Consumers. It opens Manage Consumers dialog box:

    manage consumers
  5. Select your Api Management Agent system, click on Create Consumer, type the name, and save the consumer.

    You will be asked about enabling alerts handling and reprocessing jobs, approve that action if you want to have handle new alerts automatically. You can disable them or change scheduling settings later on Application Configuration page. Consumer is created with a new default IRT rule. It just needs to be noticed that default IRT rule doesn’t add anything to your filter configured on IRT consumer for CPI Agent.

  6. Now you can open Alerts tab and click on Poll Alerts to trigger lookup manually, or wait for a scheduled job if it’s enabled.

    api alerts tab

8.2. Work with Support Tool

8.2.1. Manage consumers

Consumer aggregates information about the receiving alerts process.

At least 1 Agent System should be configured. See that section to learn how to do that.

You should have enough systems licensed for monitoring (Number Of Systems For Monitoring property on License Configuration page) and Monitoring License End Date should be valid, otherwise it won’t be possible to create a consumer.

  1. Go to Support Tool subsection of Operations section.

  2. Click Manage Consumers button. It opens Manage Consumers dialog box:

    manage consumers
  3. Select an Agent.

  4. Click on Create Consumer button. It opens Consumer dialog box where you can configure the following fields:

    1. Name of new consumer.

      If you create consumer for PRO Agent, you need to create consumer on your PRO system. And Name must be the same as the name of consumer created on PRO system (see Receiving alerts from PRO system for more details).

      For CPI Agent Name can be random.

    2. Type of consumer (only for CPI) is one of the following:

      1. Polling Consumer - datasource is Message Processing Logs API, all message log entries which satisfy the Condition will be registered as alerts in IRT.

        Condition must be valid in context of Message Processing Logs API, e.g., Status eq 'FAILED'. It’s also possible to validate the syntax of condition through Test Condition function.

        create polling consumer cpi
      2. Metric Consumer - datasource is CPI System Monitoring Module in IRT (metrics), metrics are analyzed and alerts are registered according to configured Threshold Rules.

        To add new Threshold Rule click on plus, select Metric Spec and Operation, type Value, and select Strategy (Alert per metric or Alert per Support Tool interval).

        To delete the threshold rule click on its decline button.

        create metric consumer cpi
        To use Metric Consumer you should enable CPI system monitoring on chosen CPI Agent (Enable Monitoring property).

    When you are ready with configuration, save the consumer. If you haven’t enabled support tool jobs on Application Configuration page, you will be asked about enabling alerts handling and reprocessing jobs:

    enable support tool jobs

    Approve that action if you want to have handle new alerts automatically. You can disable them or change scheduling settings later on Application Configuration page.

  5. Now you have created consumer. If you want to add more consumers, just repeat the steps above. If you need to edit or delete a consumer, click on its edit or decline buttons correspondingly.

    Type of consumer on CPI Agent can’t be changed.
  6. When you finish with consumer management, close the Manage Consumers dialog box.

8.2.2. Rules

At least one consumer should be created. See this section to learn how to do it.

Initially you have Default Rule created during consumer creation.

Rule is an approach to classify received alerts. To manage rules do the following:

  1. Select a consumer.

  2. Go to Rules tab.

  3. Open Rule page with new rule (click on Add Rule) or with existent rule (click on its details full).

    It is also possible to create rule from Alert Details page. In this case Expression and Test Payload settings will be filled with values from source alert.

    Rule page will be opened, e.g., with new rule:

    new rule page
  4. If you want to disable current rule, switch Enabled off. If you want to enable the rule, switch Enabled on.

  5. If you want to delete existent rule, click on Delete.

  6. Configure the following settings and once you finish, click on Save:

    Common settings
    1. Title of new rule, required.

    2. Step Number defines priority of rule. The less Step Number, the higher priority. Default rule has Step Number equaled to 1000. Hence, it doesn’t make sense to define this setting more than 1000. This setting is required.

    3. Expression - XPath expression which is used to determine whether alert should be caught by current rule, required. XPath is applied to alert metadata XML. Using the selection Test XML Payload Type below you can check the structure of different alert types.

    4. Namespace (only for PRO) - namespace information.

    5. Labels - list of tokens which can be assigned to each rule, then this list will be assigned to all alerts linked with this rule. Use it to simplify search of alerts.

    6. Initial Status of alert when it is handled by IRT.

    7. Action - operation which will be executed once alert is handled. Possible values:

      1. Nothing (default) - no action.

      2. Reprocess (only for PRO) - related AFD (Adapter Framework Data) entry on PRO system will be reprocessed.

      3. Canceled (only for PRO) - related AFD (Adapter Framework Data) entry on PRO system will be canceled.

    8. Lookup inbound message (only for PRO) - when it is enabled, IRT will try to find inbound message payload related to failed message (AFD). To get that payload downloaded successfully enable BI logging on related ICO object:

      enable BI logging on ICO PRO
    9. Criticality of alert.

    10. Test XML Payload Type - type of test payload. Possible values:

      1. CUSTOM - your custom value, doesn’t use any template.

      2. PRO_SCENARIO_ALERT (only for PRO) - sample payload of scenario alert.

      3. PRO_MESSAGE_ALERT (only for PRO) - sample payload of message alert.

      4. CPI_SCENARIO_ALERT (only for CPI) - sample payload of scenario alert.

      5. CPI_MESSAGE_ALERT (only for CPI) - sample payload of message alert.

      6. CPI_METRIC_ALERT (only for CPI) - sample payload of metric alert.

    11. Test Payload - sample alert payload which is used to check integrations (see below).

    Integrations
    1. Don’t send similar notifications for (min) - if several similar alerts have been polled during the period defined in this setting, you will receive only one notification. Default value is 60.

    2. Don’t send notifications automatically - if it’s true and the rule has some external integrations, notifications won’t be sent automatically, corresponding alerts will have Notification Status equals to REQUIRES_MANUAL_NOTIFICATION and it will be possible to complete these notifications only manually from Alerts page.

      If you configure Don’t send notifications automatically and Don’t send similar notifications for (min) simultaneously, all alerts received during configured period in Don’t send similar notifications for (min) will have NOTIFICATIONS_SHOULD_NOT_BE_SENT notification status except the earliest one (it will have REQUIRES_MANUAL_NOTIFICATION notification status).
    3. Attachments which should be sent defines the alert attachments names that will be added to notifications. Press Enter key after each attachment name.

    4. Email body template is a template of email. You can define dynamic data in the template using '${/xpath/expression}' (e.g., '${/alert/agentSystemId}'). You can check the template clicking on corresponding Test button.

    5. Email Integrations defines the emails to which notifications will be sent. Press Enter after each email.

      You have to configure connection to SMTP server. Go to Configuration → Application and configure SMTP host, SMTP port, SMTP username, SMTP password, Email Protocol, and Email From settings.

      You can check configured email integrations clicking on corresponding Test button.

    6. HTTP(S) Integrations

    7. HTTP(S) Attachment Type

8.2.3. Alerts

At least one consumer should be created. See this section to learn how to do it.

Alerts receiving
  1. Select a consumer.

  2. Go to Alerts tab.

  3. Set From and To dates.

  4. Click on Poll Alerts to trigger lookup manually or wait for a scheduled job if it’s enabled (setting SupportToolAlertsHandler on Application Configuration page). Alerts will be received and shown in the table (maybe it will be needed to refresh the table clicking on refresh):

    pro alerts tab

    For any alert you can:

    1. View the rule details clicking on Rule. It opens Rule details page.

    2. View the message on source system clicking on Message ID.

    3. View integration object details (if it is defined). It opens Integration Object Details page.

    4. View the alert details clicking on its details button. It opens Alert details page.

Alert details page

Alert details page for PRO system looks

pro alert details page 1
pro alert details page 2
pro alert details page 3

The following actions can be done on this page:

  • Resend Message

  • Cancel Message

  • Create Ticket - it opens Attach object to ticket dialog, where you can configure properties of new ticket or select existent one:

    attach object to ticket alert page

    You can attach to ticket with 2 ways:

    1. Create new ticket - the following settings can be configured:

      1. Title of the ticket. The same title can be used for several tickets.

      2. Release defines release, to which created ticket will be attached. See Release 'Title' page for details about release.

      3. Assignee defines the user, to whom the ticket will be assigned.

      4. Type defines type of new ticket. Since 2.11 release the following ticket types are available:

        1. Development is used with development within one landscape.

        2. Migration is used when it is needed to migrate objects from one landscape to another.

      5. Landscape defines a landscape for development ticket. See Landscapes page for details about landscapes.

      6. Source Landscape, Target Landscape, and Migration Landscape define landscapes for migration ticket. Defined landscapes have to satisfy the following:

        1. Source Landscape and Target Landscape have the same count of Agents (Landscape items) and do not have shared Agents.

        2. Migration Landscape must consist of two items: the 1st items from Source Landscape and Target Landscape correspondingly.

      7. External ticket id identifies an external ticket (e.g. in Jira).

      8. External ticket link defines a link on the external ticket. If you define the value, you can navigate directly to the external ticket from IRT.

      9. Description defines additional information.

      10. Create a test case with failed inbound message automatically

      11. Inbound message

    2. Attach to existing Ticket

  • Add Rule - it opens Rule page with predefined values for several settings.

  • Update

8.3. Work with Message Monitor

8.3.1. Configure message monitor filters

Do the following to configure message monitor filters:

  1. Choose required CPI Agent.

  2. Enable edit mode switching on edit mode switcher.

  3. Click on Create filter to create new message monitor filter or click on the message monitor filter to update existent message monitor filter. It opens Create message monitoring filter dialog box:

    create message monitor filter dialog
  4. Configure the fields:

    • Name of new message monitor, required.

      The name must be unique for your Organization.
    • Metadata access role is role created for current message monitor filter that provides access to its metadata. The role should be set to users having access to corresponding data. See User management for details.

    • Full access role is role created for current message monitor filter that provides full access to it. The role should be set to users having access to corresponding data. See User management for details.

    • Statuses of messages to be filtered. If the field is empty, messages with all supported statuses will be filtered.

      Supported statuses are FAILED, COMPLETED, RETRY, PROCESSING, ESCALATED, and CANCELLED.

    • Period for which you want to get messages.

    • Sender (optional)

    • Receiver (optional)

    • Artifact filter strategy sets the artifact strategy Apply filter to all artifacts or Apply filter to chosen artifacts (you can define these artifacts in Artifacts field).

    • Filtering condition shows filters condition using current values in the dialog. To recalculate condition click on refresh button.

  5. If you want to delete a message monitor filter, click on remove of the message monitor filter.

  6. Once you finish with required message monitor filters configuration, disable edit mode.

8.3.2. Browse messages

When you configure required message monitor filters, you can browse messages clicking on the message monitor filter:

message monitor filter icon

It opens Message Browser for filter page:

message browser for filter

You can configure filters (Time, Integration Flows, Custom Header Name, Custom Header Value, Statuses, Correlation Id, Sender, Receiver, Message Id, Application Message Id) and inspect message details clicking on the message in the table. Once you click on refresh button end date will be set to current time.

8.4. Work with SAP System Monitoring

Enable Monitoring setting (see Agents integration configuration) must be enabled for the chosen CPI Agent.

SAP System Monitoring processes the following metrics:

You can configure Time Period for all metrics if it is needed.
  • CPU Usage (%)

    cpu usage chart
  • IFlow Latency (ms)

    iflow latency chart
  • Memory Usage (%)

    memory usage chart
  • Monitoring Status Latency (ms)

    monitoring status latency chart
  • Processed Messages (count)

    processed messages chart

9. DevOps

Requirements:

  1. All required Agent Systems have been configured (see that section to learn how to do that).

  2. Synchronization of all required Agent Systems has been done (see Synchronization with Agent system section).

  3. You should have enough licensed tracked object versions in CTT (i.e. DevOps licensing plan), otherwise, once new version is registered, the oldest will be deleted if the limit is reached. It causes loss of transport items if deleted tracked object version was used in the transports.

  4. If you use PRO Agents, additional SAP PRO client libraries must be available in runtime classpath. They are not included into the build, so they should be added to a folder (you can create libs folder in the folder with jdbc driver) and then the path to that libs folder should be passed through -Dloader.path parameter in the bootstrap command (see that section). If any of these libraries are missing, you will see the following error during transport creation or checking imported objects:

    missing dependencies error

    Required libraries:

    • com.sap.aii.utilxi.core.jar - can be downloaded from <PRO system root url>/dir/directory/com.sap.aii.utilxi.core.jar

    • com.sap.xpi.ib.core.jar - can be downloaded from <PRO system root url>/dir/directory/com.sap.xpi.ib.core.jar

    • sap.com~tc~bl~guidgenerator~impl.jar - can be downloaded from <PRO system root url>/dir/directory/sap.com~tc~bl~guidgenerator~impl.jar

9.1. Get started with DevOps

9.1.1. E2e development flow (PRO, CTS+ transports)

  • If you work with a CTS+ Transport with Integration Directory objects, opened (not active) change list related to this transport must exist. Change lists should not be activated either automatically by PI engine or manually.

    To avoid automated activation a flag com.sap.aii.ibdir.core.ctstransport.autoActivation.default must be set to false:

    autoactivation configuration
  • Entries which have been deleted from CTS+ transport request won’t be deleted from root CTS+ Transport entry in IRT. As IRT uses only information from PRO system (Integration Directory and Enterprise Service Repository EJB clients), it doesn’t have any information about whether a CTS transport request item is deleted or not. It’s possible to delete child CTS transport manually from IRT, but it will be created again during the next update, because PRO system still has this information in the transports registry.

Since the 2.8 release, IRT provides management functionality for File/CTS+ transports. It doesn’t process transport itself, but it helps with documentation, change tracking and configuration of transported objects. The following example in current section should show this feature in action. Further explanation of behavior, configuration and use cases can be found in the next sections.

In the example let’s have 2 systems in the landscape (configure Name, Platform, Lookup transport automatically during synchronization, and Landscape items):

  • DI3 - source system (dev)

  • DPO - target system (qa)

Some objects on DI3 should be transported to DPO. A CTS+ transport request DI3K90001S has been created and required objects have been added to it. Transport request has 2 items, one of them related to Integration Directory, another one to Enterprise Service Repository. Transport entries (export direction) can be browsed from Integration Directory builder and ESR builder on DI3:

cts transport example int dir export di3
cts transport example esr export di3

Now let’s create a ticket in IRT. The purpose of that ticket for now is just to aggregate all needed information and objects related to transport. The ticket is called FIposting scenario update. Initially the ticket is not linked with any objects. Go to Tracked Objects tab and click on Attach Tracked Objects. Select DI3K90001S|Export CTS+ transport and attach it to the ticket. Select added CTS transport and click on Attach all dependent objects.

All DI3 object versions related to transport (and supported in CTT) were attached to the ticket:

tracked objects added to ticket after transport synchronization

Then transport request has been imported on DPO. Automated changelist activation is disabled, so all imported object versions are kept in the changelist. The next step is to synchronize imported objects on DPO.

Transport request contains some communication channels. Some channel parameters a non-transportable, new objects in the import changelist doesn’t have them at that moment. IRT provides a possibility to configure imported objects (for no only communication channels configuration is supported) once they are synchronized in the Transport object. Transport configuration by default is disabled and won’t be applied during synchronization of imported objects. There are 3 possible cases for transport configuration parameters:

  • Parameter value should be taken from source object version and set on the target object. Default behavior for all non-password parameters.

  • Parameter value should be kept from target object version, so, it won’t be updated. Default behavior for all password parameters.

  • Parameter value should be configured manually for chosen target system.

For communication channels it’s possible to configure adapter specific attributes and module parameters.

transport configuration example part1
transport configuration example part2

Now let’s open each child transport object in IRT and process Check import. Once it’s done, changelist is activated, channels which have enabled transport configuration are enriched with new parameter values depending on chosen strategy, imported object versions are linked with transport object and added to the ticket.

cts child transport item after import int dir
tracked objects added to ticket after import

Changes between source and target objects can be browsed from Ticket’s Tracked Objects tab:

channel changes after applying transport configuration

Actually applied transport configuration has also been added to the ticket:

transport configuration tracked object in the ticket

The payload of transport configuration tracked object has full information about applied parameters:

transport configuration tracked object in the ticket payload part

Finally, processed transport is documented in the ticket report:

ticket report transports

To summarize, it needs to be said that current example just shows an isolated case with transport. In more complicated scenario ticket can be linked with integration objects and test cases which should be processed after transport. In CTS+ it’s possible to have multiple imports of the same transport request, and there is also a workaround for keeping transport request mutable during these imports. All these aspects automatically generate various use cases. Transports support in IRT has been designed to theoretically cover almost all of them, but it would be difficult to provide full set of examples. Especially because each company has its own workflow. In the further sections we are trying to explain the behavior of this feature, it should provide some information about how it fits your requirements. If you would like to have some additional cases supported, contact us by this email: [email protected].

9.1.2. E2e development flow (PRO, external transport management)

In this section we describe e2e development flow for PRO systems (external transport management is used).

You should prepare and import transport(s) on your systems.

  1. Go to Configuration → Landscapes page.

  2. Create a landscape. Configure Name, Platform, Lookup transport automatically during synchronization, and Landscape items, e.g.:

    landscape dialog dev flow PRO
  3. Synchronize source system (in our example it’s D75 - dev) in Change Tracking Tool.

  4. Go to DevOps → Tickets page.

  5. Create new development ticket with created landscape (Type - Development, Landscape - created landscape). It creates new ticket and opens its page.

  6. Go to Tracked Objects tab.

  7. Click on Attach Tracked Objects and select transport(s) prepared on your systems.

  8. Select attached objects and click on Attach all dependent objects.

  9. Click on Start transport button:

    start transport button
  10. Go to Transports tab.

  11. Synchronize target system (in our example it’s T75 - qa). You can do it from Tracked Objects tab (Synchronize button) or from Change Tracking Tool.

    When synchronization is finished, IRT will automatically check import for created transports. Once it’s done, transports statuses will be IMPORTED and you will be allowed to Resolve the ticket.

9.1.3. E2e migration flow (PRO, integrated transport management)

In this section we describe e2e migration flow for PRO systems (integrated transport management is used).

  1. Go to the Landscapes tab on the Configuration page.

  2. Click on Create Landscape to register a landscape related to your old stack of systems (let’s call it Source Landscape). It opens Landscape dialog box, where Landscape Name, Platform, Integrated transport management, and Landscape items can be configured, e.g.:

    landscape dialog old
  3. Create landscape related to your new stack of systems (let’s call it Target Landscape), e.g.:

    landscape dialog new
  4. Create a special landscape for migration between old development system and new development system (let’s call it Migration Landscape), e.g.:

    landscape dialog migration

    If you are intended to migrate objects from one landscape to another, Source Landscape, Target Landscape, and Migration Landscape have to satisfy the following:

    • Source Landscape and Target Landscape have the same count of Agents (Landscape items) and do not have shared Agents.

    • Migration Landscape must consist of two items: the 1st items from Source Landscape and Target Landscape correspondingly.

  5. Go to the Releases tab on the DevOps page.

  6. Click on New Release to create a release. It opens Create release dialog box, where release fields can be configured, e.g.:

    create release dialog
    Make sure that Default Ticket Type is Migration, Default Source Landscape - Source Landscape, Default Target Landscape - Target Landscape, and Default Migration Landscape - Migration Landscape.
  7. The release details page is opened after release creation:

    release details page
  8. Click on Add Scenarios to add scenarios to the release. It opens Create new tickets for chosen scenarios dialog box, where new ticket properties can be configured (for now just set Test cases attachment strategy to Attach all available test cases for chosen scenarios):

    create new tickets for choosen scenarios
  9. Click on Add Scenarios and select the objects.

  10. Submit Create new tickets for chosen scenarios dialog box. It creates the tickets related to the selected scenarios. If selected objects haven’t been licensed yet, you will see the following error:

    request license migration error

    Click on Request missing licenses to update object licenses.

  11. Switch View perspective to Tickets:

    view perspective
  12. Go to Prepared tab.

  13. Select the ticket and click on Move to development button. It moves the ticket to In development status and navigates you to In Development tab.

    ticket move to development
  14. Select the ticket and click on Start transport button. It moves the ticket to In transport status, starts transports, and navigates you to In Transport tab.

  15. View created transports clicking on ticket transports button button.

    ticket transport list
  16. For repository transport click on its <Transport ID> (<Transport Status>): <Transport Name> link. It opens the transport details page:

    transport details page
  17. You can check estimated payload that will be created on the target landscape after migration clicking on check full button.

  18. You can configure transport configuration (not for any object) clicking on configuration button (see Transport Configuration page for details).

  19. Process the transport clicking on Import button. When import is finished, process other transports clicking on <Transport ID> (<Transport Status>) links (Transports from the same group field) and repeating last 2 steps for other transports.

    Transport of directory objects should be processed after others.
  20. Go to the release clicking on back button several times.

  21. Select the ticket and click on Finish transport on In Transport tab.

  22. Go to Migrated tab.

  23. Select the ticket and click on Create Development tickets. It creates development ticket on target system which can be used for moving current development landscape to production.

  24. Go to In Development tab and select the newly created development ticket and click on Start transport.

  25. Process all transports of the development ticket (see above).

  26. Go to the release clicking on back button several times.

  27. Select the development ticket and click on Finish transport on In Transport tab.

  28. Go to Migrated tab.

  29. Select the migration ticket and click on Migrate Transport Configurations. It opens 'Migrate Transport Configurations' dialog box, leave everything by default and submit the dialog box.

9.1.4. E2e development flow (CPI)

In this section we describe e2e development flow for CPI systems.

  1. Go to Configuration → Landscapes page.

  2. Create a landscape. Configure Name, Platform, Lookup transport automatically during synchronization, and Landscape items, e.g.:

    landscape dialog dev flow CPI
  3. Synchronize source system (in our example it’s p0201 - dev) in Change Tracking Tool.

  4. Go to DevOps → Tickets page.

  5. Create new development ticket with created landscape (Type - Development, Landscape - created landscape). It creates new ticket and opens its page.

  6. Go to Tracked Objects tab.

  7. Click on Attach Tracked Objects and select Iflows, Value Mappings, Packages.

  8. Select attached objects and click on Attach all dependent objects.

  9. Click on Start transport button:

    start transport button
  10. Go to Transports tab.

  11. Go to transport page clicking on details.

  12. You can configure transport configuration (not for any object) clicking on configuration button (see Transport Configuration page for details).

  13. Import transports. When all transports linked with the ticket are imported, you can Resolve the ticket.

9.1.5. E2e development flow (Api Management)

In this section we describe e2e development flow for Api Management systems.

  1. Go to Configuration → Landscapes page.

  2. Create a landscape. Configure Name, Platform, Lookup transport automatically during synchronization, and Landscape items, e.g.:

    landscape dialog dev flow API
  3. Synchronize source system (in our example it’s api-portal-dev - dev) in Change Tracking Tool.

  4. Go to DevOps → Tickets page.

  5. Create new development ticket with created landscape (Type - Development, Landscape - created landscape). It creates new ticket and opens its page.

  6. Go to Tracked Objects tab.

  7. Click on Attach Tracked Objects and select Api Proxies.

  8. Select attached objects and click on Attach all dependent objects.

  9. Click on Start transport button:

    start transport button
  10. Go to Transports tab.

  11. Import transports. When all transports linked with the ticket are imported, you can Resolve the ticket.

9.2. Develop with DevOps

This section includes detailed description of all pages and dialog boxes in DevOps.

9.2.1. Tickets page

At least one landscape has to be created. See this page to learn how to create landscape.

Tickets page shows all existing tickets and looks:

tickets

Ticket ID is generated automatically based on the prefix and corresponding incremented number. Prefix can be configured through irt.config.ticket-id-prefix parameter (see IRT Application running).

On this page you can:

  1. Create new ticket clicking on Create Ticket button. It opens 'Create new ticket' dialog box, where the following options can be set:

    1. Title of the ticket. The same title can be used for several tickets.

    2. Release defines release, to which created ticket will be attached. See Release 'Title' page for details about release.

    3. Assignee defines the user, to whom the ticket will be assigned.

    4. Type defines type of new ticket. Since 2.11 release the following ticket types are available:

      1. Development is used with development within one landscape.

      2. Migration is used when it is needed to migrate objects from one landscape to another.

    5. Landscape defines a landscape for development ticket. See Landscapes page for details about landscapes.

    6. Source Landscape, Target Landscape, and Migration Landscape define landscapes for migration ticket. Defined landscapes have to satisfy the following:

      1. Source Landscape and Target Landscape have the same count of Agents (Landscape items) and do not have shared Agents.

      2. Migration Landscape must consist of two items: the 1st items from Source Landscape and Target Landscape correspondingly.

    7. External ticket id identifies an external ticket (e.g. in Jira).

    8. External ticket link defines a link on the external ticket. If you define the value, you can navigate directly to the external ticket from IRT.

    9. Description defines additional information.

    Related test suite Test Suite: Test cases for ticket <Ticket ID> is created and linked with new ticket.
  2. Select existing ticket(s) and delete it(them) clicking on red trash button.

    Tickets attached to any release can’t be deleted. If you want to delete such tickets, you have to detach the tickets from the release and after that delete them.

  3. View a ticket details clicking on its details button. It opens Ticket: Ticket ID page.

  4. View linked release details clicking on <Release Title>. It opens Release 'Title' page.

Ticket: Ticket ID page

Ticket: Ticket ID page shows the ticket details and provides functionality for ticket management. It looks:

ticket details

There are the following tabs on this page:

On each tab you are able to:

  1. Open another ticket details clicking on open another button and selecting a ticket.

  2. View linked release details clicking on <Release Title>. It opens Release 'Title' page.

  3. Move the ticket to next or previous stages depending on its type:

    1. Development is used with development within one landscape.

    2. Migration is used when it is needed to migrate objects from one landscape to another.

Development and Migration ticket types provide similar workflow with small differences:

  • Development tickets have the following statuses:

    • In development is the stage when objects are attached, updated, detached from the ticket.

    • In transport is the stage when development part is done, operations available on In development stage are blocked, objects are prepared for transport through the landscape. If the landscape has Integrated transport management, transports with objects attached to the ticket will be created automatically. Otherwise, if Integrated transport management is false, user needs to attach transports to the ticket. Ticket can be resolved only if all related active transports are imported (see Transport Statuses for details).

    • In production is the stage when transport stage is successfully completed, the ticket is marked as In production. It means that all objects are available and operational on all systems in the landscape.

    • Canceled is finish stage if ticket can’t be resolved due to any reason.

      The picture below shows development ticket status transitions:

      development ticket diagram
  • Migration tickets have the following statuses:

    • Prepared is the stage similar to In development.

    • In development is the same as for development ticket, but for migration ticket we assume that changes will not be done with source objects because the main goal for migration is to migrate objects between landscapes, it is not about their changes in the old landscape.

    • In transport is the same as for development ticket.

    • Migrated is the stage when transport stage is successfully completed, the ticket is marked as Migrated. It means that all objects are available and operational on all systems in the landscape. It is possible to process development ticket creation and transport configuration copying on that stage.

    • Canceled is finish stage if ticket can’t be resolved due to any reason.

      The picture below shows migration ticket status transitions:

      migration ticket diagram
  1. Ticket Details tab provides ticket details updating. See almost all ticket properties here. Additional properties:

    1. Depends on tickets

    2. Dependent tickets

      Landscape (for development ticket), Source Landscape, Target Landscape, and Migration Landscape (for migration ticket) can’t be modified.
  2. Tracked Objects tab provides functionality for attached tracked object management:

    ticket tracked objects

    Here you can:

    1. Attach Tracked Objects clicking on Attach Tracked Objects button. It opens 'Attach tracked objects to ticket' dialog box with predefined Agent: for development ticket - the first item from target landscape, for migration ticket - the first item from migration landscape. So it is possible to manually attach only development objects.

      Attaching objects should be licensed for DevOps or Migration (see Configure Object Licenses for details).

      All object versions in the table are the latest.

      If the object has been already selected, it is not visible in the table, but you can see the count of such objects.

      Previous object version becomes detached.

    2. Update selected object(s) to the latest version clicking on Update to the latest version. It attaches the latest version of chosen object(s) to the ticket (versions are looked up in CTT).

    3. Attach all dependent objects of selected object(s) clicking on Attach all dependent objects. It attaches the latest versions of all child dependencies of chosen object(s) recursively.

      For channels, it gets a parent link to component/system and then again parent link to the party.

    4. Detach selected Tracked Objects clicking on Detach Tracked Objects. It marks chosen object versions in the ticket as detached, but versions are still visible in the table.

    5. Compare versions of two selected objects clicking on Compare Versions. It opens 'Tracked Object Differences' dialog box with two selected object versions.

      These objects must have the same type in Change Tracking Tool.

      BPMN model and Simplified model can be compared for integration flows.

    6. Start synchronization on chosen Agent clicking on Synchronize (read about synchronization here).

      It is possible to select Agents which are used in related landscape(s).
    7. View tracked object details clicking on its Name. It opens 'Name page' with tracked object details.

  3. Test Cases tab provides functionality for test case management and looks:

    ticket test cases

    Here you can:

    1. Add/remove recommended test cases clicking on Lookup related Test Cases. It opens 'Assign Test Cases To Ticket' dialog box, where you can select test cases recommended for adding or removal:

      assign test cases to ticket

      Test cases recommended for adding are test cases related to the attached ICO/SA/CPI_IFLOW tracked objects.

      Test cases recommended for removal are previously added test cases related to the detached from the ticket ICO/SA/CPI_IFLOW tracked objects.

    2. Open related test suite clicking on Open Test Suite. It opens Test Suite: Test Suite Title page.

    3. Detach selected test cases clicking on Detach from Ticket. It triggers test case detaching operation from test suite.

    4. Run the related test suite clicking on run or run on buttons:

      • Run uses static links to test objects defined in the test case.

      • Run on resolves these links dynamically at the moment of test run. It is possible to see how these links are resolved through Current Mapping Configuration button - it opens 'Mapping Configuration' dialog box:

        mapping configuration

        There are Agent Objects (parent nodes) and Test Objects (child nodes) in opened dialog box.

        You can’t run test suite without linked test cases.
  4. Last Testing Result tab shows results of last running. On this page you can:

    1. View Agent and Test Objects clicking on Agent Object Title or Test Object Title. It opens Integration Object Details page.

    2. Poll remote results clicking on Poll remote results.

      You don’t have to poll remote data if you have PRO Agent with selected IRT Agent Module and enabled JMS integration (properties Messages retrieving way and Enable JMS Integration on Agent dialog) and the messages aren’t large. It is enough just to refresh the page from time to time.

      Since IRT 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

      Since IRT 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

      • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

      • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

      If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling (on Configuration ⇒ Application page). When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

    3. View last polling result clicking on Open Last Polling Result.

      Open Last Polling Result button is available after polling remote data and until page is refreshed.
    4. Export as a test case to PIT (only for PRO) clicking on Export as a Test Case to PIT.

      Export as a Test Case to PIT is available only for licensed version after the test suite running.
    5. Compare testing results and build reports clicking on check button.

      The option reprocesses comparison and report generation asynchronously. It makes sense to execute the option once you have configured a new "ignore rule".
    6. Do the following actions clicking on menu and choosing corresponding option:

      1. Rerun reruns required test case.

      2. View testcase opens 'Test Case Details' page.

      3. Download report.

        Report type can be one of 2 types:

        1. xlsx report:

          • Contains information about test run/test suite run results.

          • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

        2. zip archive with 3 csv reports:

          • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

          • diff-report.csv - contains diff report for test run/test suite run.

          • processed-messages-report.csv - contains processed messages report for test run/test suite run.

        The report type is defined from Use bundled CSV report generation strategy property configured on Configuration → Application page. If it’s true, the report type is zip, otherwise, it’s xlsx.

      4. View results opens Test Run Details page.

  5. Alerts tab shows alerts attached to the ticket.

  6. Transports tab shows linked transports (see Transport: Name page for details about transports) and looks:

    ticket transports

    Here you can:

    1. View transport details clicking on its details button. It opens Transport: Name page.

    2. Delete selected transports clicking on red trash button.

  7. Reports tab contains built reports and looks:

    ticket reports

    Here you can:

    1. Build new report clicking on Report button. It starts report building and new row is added to the table (with IN PROGRESS status). To get built report wait for a while and click on Refresh button.

    2. Download built xlsx report clicking on report button.

    3. Delete a report clicking on its decline button.

9.2.2. Transports page

Transports page shows all created transports and looks:

transports

Transport ID is generated automatically based on the prefix and corresponding incremented number. Prefix can be configured through irt.config.transport-id-prefix parameter (see IRT Application running).

On this page you can:

  1. Switch between tabs:

    1. All transports to view all existent transports.

    2. My Approvals to view transports in WAITING_FOR_APPROVAL status and current user is reviewer for them.

    3. My Actions to view transports in CREATED, WAITING_FOR_APPROVAL, or IN_PROGRESS statuses which can be performed by current user.

  2. View linked tickets of required transport clicking on its menu full button. You also can open the ticket details page clicking on 'Ticket ID: Title'. It opens Ticket: Ticket ID page.

  3. View a transport details clicking on details button. It opens Transport: Name page

  4. Select transport(s) and delete it(them) clicking on red trash button.

Transport: Name page

Transport: Name page shows the transport details and looks:

transport details

On this page you can:

  1. View transport configuration of the transport item clicking on its configuration button. It opens Transport Configuration page with preselected Landscape and Tracked Object.

  2. Check estimated payload that will be created on the target landscape after migration clicking on its check full button. It opens 'Compare' dialog box:

    compare
  3. View linked ticket details clicking on the ticket title. It opens Ticket: Ticket ID page.

  4. View details of transports from the same group clicking on the transport ID. It opens the same page with different data.

  5. Validate transport configuration clicking on Validate Transport. It validates dir objects mapping and password settings:

    1. If a component is mapped from X to Y, but channel from X|ChannelName to Z|ChannelName, it shows an error about inconsistent mapping.

    2. If the password parameter has a static value config, its value shouldn’t be empty if it’s not empty on the source system. If the password parameter is inherited from target, target object should exist.

      Validate Transport is available only for transport with INTEGRATION_DIRECTORY registry type until the transport is approved or imported

      Transport configuration validation is processed automatically during transport creation, approval (if Require Transport Approval option is true on the landscape), import.

  6. Migrate passwords (for PRO) clicking on Migrate passwords if possible.

    Migrate passwords if possible is available only for transport with INTEGRATION_DIRECTORY registry type, containing at least one channel, and linked with migration ticket until the transport is approved or imported.

  7. Manage the transport statuses:

    1. CREATED is initial state for transport if Require Transport Approval option is true on the landscape, import and approval operations are not available at this stage.

    2. WAITING_FOR_APPROVAL is state when transport has not been approved yet, import operation is not available.

    3. IN_PROGRESS is initial state for transport if Require Transport Approval is false, and the next state for approved transport. Import operation is available only if it’s initial state for transport or all transports from the same group have been approved.

    4. IMPORTED is state when all transport items have been successfully imported on the latest landscape item.

      If corresponding landscape is for CPI platform and Require Transport Approval is true, only reviewers can import transport.
    5. DECLINED is state when transport has been declined by reviewer. It means the ticket should be moved to previous stage (to development) and transports have to be created again (automatically or manually), otherwise, import operation is not available for all transports from the same group.

    6. CANCELED is state when the related ticket has been moved to previous stage (to development) and transport has not been imported. It means the ticket should be moved to previous stage (to development) and transports have to be created again (automatically or manually), otherwise, import operation is not available for all transports from the same group.

      If corresponding landscape is for CPI platform and Require Transport Approval is true, only reviewers can cancel transport.

    The picture below shows transport status transitions:

    transport diagram

9.2.3. Transport Configuration page

Transport Configuration page shows the transport configuration of selected object on selected landscape and looks:

transport configuration

Transport Configuration is validated during opening, and validation errors are shown in warning message, e.g.:

tc validation errors

There are 3 possible cases for transport configuration parameters:

  • Parameter value should be taken from source object version and set on the target object. Default behavior for all non-password parameters.

  • Parameter value should be kept from target object version, so, it won’t be updated. Default behavior for all password parameters.

  • Parameter value should be configured manually for chosen target system.

Transport configuration is configured differently for varied objects:

  • PRO objects:

    For parties, components, systems, communication channels, and ICOs it’s possible to configure name mapping. For communication channels it’s also possible to configure adapter specific attributes and module parameters. You also can configure mappings and switch on/off Use scenario mapping option.

    Use scenario mapping option is disabled for channels and ICOs.

  • CPI Objects:

    You can override transport configuration for older IFlow versions (to enable this feature click on Override for a particular version and select a version).

    It is possible to select draft version only if it’s the latest (it’s impossible to select historical draft versions).

    Once transport is created for an object, corresponding transport configuration will be persisted. The following cases are possible:

    • There is no persisted transport configuration for an object and persistence is requested for the latest version, then IRT will persist new config for the latest version (by group id only).

    • There is no persisted config for an object and persistence is requested for particular version, then IRT will persist new config for particular version (by group id and tracked object id).

    • There is persisted config for the latest version and persistence is requested for latest version, then IRT will update persisted config for the latest version.

    • There is persisted config for the latest version and persistence is requested for the particular version

      • if a particular version is not the latest, then IRT will persist new config for the particular version.

      • if a particular version is the latest, then IRT will update the persisted latest version as a particular version.

    • There is a config only for a particular version and persistence is requested for the latest version

      • if a particular version is not the latest, then IRT will persist new config for the latest version (it’s not the real case for normal usage).

      • if a particular version is the latest, then IRT will update the content of the particular version without changing its type.

    • There is config only for a particular version and persistence is requested for a particular version, then IRT will update persisted config for the particular version.

    When a configuration is persisted for a concrete transport it’s possible to edit transport configuration for transport items which haven’t been approved yet.

  • Api Management Objects:

    You can configure Api Proxies (target endpoint properties and URL) and Key Value Maps.

9.2.4. Releases page

Releases page shows all existing releases and looks:

releases

On this page you can:

  1. Create new release clicking on New Release button. It opens 'Create release' dialog box where the following properties can be configured:

    1. Title of new release. Should be unique within the organization.

    2. Version of release.

    3. Default Assignee for group ticket creation.

    4. Default Ticket Type for group ticket creation. See Ticket Types for details.

    5. Default Landscape for group ticket creation. The same as Landscape for ticket (see Landscapes).

    6. Default Source Landscape, Default Target Landscape, and Default Migration Landscape for group ticket creation. The same as Source Landscape, Target Landscape, and Migration Landscape for ticket correspondingly (see Landscapes).

  2. Select release(s) and release it(them) clicking on Release button.

    Only releases which all attached tickets are in Migrated, In production, or Canceled statuses can be released.
  3. View a release details clicking on details button. It opens Release 'Title' page.

  4. Select release(s) and delete it(them) clicking on red trash button.

    The release(s) will be deleted with all attached tickets.
Release 'Title' page

Release 'Title' page provides the features for management and monitoring of ticket groups and looks:

release details page

There are the following operations can be executed on this page:

  1. Opening another release details clicking on open another button and selecting a release.

  2. Expanding the release configuration clicking on details button. It expands the configuration, which can be updated (see release fields here):

    release details with configuration

    If you want to save changes, click on save button. Otherwise, collapse the configuration.

  3. Release the release clicking on Release button.

    Only releases which all attached tickets are in Migrated, In production, or Canceled statuses can be released.
  4. Changing view perspective:

    view perspective change

    Release has two view perspectives:

    1. Integration scenarios perspective shows scenarios added to tickets attached to the release. Here you can:

      1. Add new scenario clicking on Add Scenarios button (available only if the release hasn’t been released yet). It opens Create new tickets for chosen scenarios dialog box:

        create new tickets for choosen scenarios

        In this dialog box configure properties of new tickets (see almost all of them here):

        1. Ticket creation strategy identifies how objects should be distributed between tickets: One ticket per scenario or All scenarios in one ticket.

        2. Test cases attachment strategy identifies whether test cases should be attached during tickets creation, or not: Attach all available test cases for chosen scenarios or Don’t attach any test cases. If Attach all available test cases for chosen scenarios is selected, ticket’s integration objects lookup and test cases attachment (all found test cases for resolved integration objects) will be processed for each created ticket.

          After configuring new ticket properties click on Add Scenarios. It opens 'Select integration scenarios' dialog box where you can select the objects (submit the dialog box to close it).

          If you have selected unnecessary objects, you can select them and click on Delete Scenarios button.

          Click on Save to create new ticket(s). Selected objects with all dependent objects will be attached to created ticket(s).

          Selected objects should be licensed for DevOps or Migration (see Configure Object Licenses for details).
      2. View integration scenario details clicking on the link of source integration scenario. It opens Integration Object Details page.

      3. View ticket details clicking on scenario tickets and selecting the ticket. It opens Ticket: Ticket ID page.

    2. Tickets perspective shows attached tickets and provides functionality for ticket management. Here you can:

      1. Attach tickets clicking on Attach Tickets button and selecting the tickets.

        You can attach tickets that are not associated with any release.

        Attach Tickets button is available only if the release hasn’t been released yet.

      2. Detach tickets selecting unnecessary tickets and clicking on Detach Tickets.

        Detach Tickets button is available only if the release hasn’t been released yet.

      3. View ticket details clicking on its id. It opens Ticket: Ticket ID page.

      4. Monitor ticket stages switching between Prepared, In Development, In Transport, Migrated, and In Production tabs.

        These tabs correspond to ticket stages described here.
      5. Move tickets to next stage depending on previous one:

        1. To development on Prepared tab.

        2. Start transport on In Development tab.

        3. Finish transport on In transport tab.

          To development, Start transport, and Finish transport buttons are available only if the release hasn’t been released yet.

      6. Create Development tickets from selected migration tickets on Migrated tab. It creates development tickets on target system which can be used for moving current development landscape to production.

        Create Development tickets button is available only if the release hasn’t been released yet.

      7. Migrate Transport Configuration of selected migration tickets on Migrated tab. It opens 'Migrate Transport Configurations' dialog box:

        migrate tc

        Where you can configure:

        1. Fill values of parameters inherited from target by static values from source landscape

        2. Migrate passwords if possible (PRO only)

          Migrate Transport Configuration button is available only if the release hasn’t been released yet.

10. Advanced configuration

10.1. Landscapes configuration

Landscapes page shows all existing landscapes and looks:

landscapes

On this page you can:

  1. Create new landscape clicking on Create Landscape button (see Landscape configuration examples to learn how to configure landscapes):

    1. See Landscape configuration (PRO platform) to create PRO landscape.

    2. See Landscape configuration (CPI platform) to create CPI landscape.

    3. See Landscape configuration (Api Management platform) to create Api Management landscape.

  2. Delete a landscape clicking on its decline button.

    Landscapes linked to any object (release, ticket, etc.) can’t be deleted.
  3. Edit landscapes clicking on its edit button.

    You can edit only Require Transport Approval and Transport Reviewer Emails settings (for PRO and Api Management landscapes) and Deploy after transport, Require approval, and Reviewer emails landscape items settings (for CPI landscapes).

    All transports linked with the landscape must be in IMPORTED, CANCELED, or DECLINED statuses, otherwise you will get an error that it is not possible to change transport approval value because some transports are in WAITING_FOR_APPROVAL, IN_PROGRESS or CREATED state.

  4. Expand/Collapse node of a landscape to view/hide landscape items.

Landscape configuration (PRO platform)
  1. Go to the Landscapes tab on Configuration page and add your agent system through Create Landscape button:

    create landscape PRO
  2. Configure the following properties:

    • Name of new landscape. Should be unique within the organization.

    • Platform - select the type of your landscape - PRO.

    • Integrated transport management - if true, IRT will use file transport EJB API to process transport of ESR (Enterprise Service Repository) objects and integration directory WS (Web Service) for Directory objects. Otherwise, user should attach transports to tickets (transports are synchronized in CTT).

    • Lookup transport automatically during synchronization finds IRT transport (with IN_PROGRESS status and the landscape has a flag Lookup transports during synchronization) when new transports with Import type were handled by CTT during synchronization. That operation is asynchronously executed at the end of synchronization.

      This option can be enabled if Integrated transport management is disabled.
    • Require Transport Approval enables review step between transport creation and import.

    • Transport Reviewer Emails defines reviewers. This option is available only if Require Transport Approval is true.

    • Landscape Items describe groups of Agents in specific order and assignment. Landscape items can be added by clicking on plus and deleted by clicking on its decline.

      The items have the following configuration:

      • System Id is selected agent.

      • System description is description for current system (e.g. qa).

Landscape configuration (CPI platform)
  1. Go to the Landscapes tab on Configuration page and add your agent system through Create Landscape button:

    create landscape CPI
  2. Configure the following properties:

    • Name of new landscape. Should be unique within the organization.

    • Platform - select the type of your landscape - CPI.

    • Define virtual items manually enables possibility to define virtual landscape items manually. Enable this option if you need landscape configuration similar to System A → System B (virtual) → System B → System C.

      If this option is disabled, agent system is marked as virtual for the 2nd and subsequent inclusions (see Landscape configurations examples).

    • Landscape Items describe groups of Agents in specific order and assignment. Landscape items can be added by clicking on plus and deleted by clicking on its decline.

      The items have the following configuration:

      • System Id is selected agent.

      • System description is description for current system (e.g. qa).

      • Virtual defines whether landscape item is virtual or not. It’s editable only if Define virtual items manually option is enabled for current landscape.

      • Deploy after transport defines whether objects imported to current system are deployed or not.

      • Require approval defines whether transports to current system require approval or not.

        if CPI landscape item has approval flag enabled, all next landscape items must have that flag also enabled.
      • Reviewer emails defines reviewers. Available only if Require approval is true for current item.

If landscape has 3 or more landscape items, the state of the object from previous landscape item is chosen during importing transport.
Landscape configuration (Api Management platform)
  1. Go to the Landscapes tab on Configuration page and add your agent system through Create Landscape button:

    create landscape API
  2. Configure the following properties:

    • Name of new landscape. Should be unique within the organization.

    • Platform - select the type of your landscape - Api Management.

    • Require Transport Approval enables review step between transport creation and import.

    • Transport Reviewer Emails defines reviewers. This option is available only if Require Transport Approval is true.

    • Define virtual items manually enables possibility to define virtual landscape items manually. Enable this option if you need landscape configuration similar to System A → System B (virtual) → System B → System C.

      If this option is disabled, agent system is marked as virtual for the 2nd and subsequent inclusions (see Landscape configurations examples).

    • Landscape Items describe groups of Agents in specific order and assignment. Landscape items can be added by clicking on plus and deleted by clicking on its decline.

      The items have the following configuration:

      • System Id is selected agent.

      • System description is description for current system (e.g. qa).

      • Virtual defines whether landscape item is virtual or not. It’s editable only if Define virtual items manually option is enabled for current landscape.

Landscape configuration examples
  1. If development and debugging process is executed on the following systems: C73 (dev system) → P73 (qa system) → P74 (prod system), then landscape configuration is:

    landscape example 1
  2. If development and debugging process is executed on the following systems: C73 (dev and qa system) → P74 (prod system), then landscape configuration is:

    landscape example 2

    In this case Agent system C73 will be marked as virtual for the 2nd inclusion.

    Agent system is marked as virtual for the 2nd and subsequent inclusions. You need to use Agent system twice to define configurations like DP1 (dev and qa system) → DP2 (prod system).

10.2. User management and permissions

10.2.1. User management

Each request in the IRT requires authorization. Having non-community license installed, when you open some page, you will see login popup, where you should enter your email and password.

In the community version it automatically uses the special community user with full administrator permissions. You don’t need to configure anything.

To create new user click on plus. It opens Add User dialog:

add user dialog
  • Configure Email, Password, Confirm Password, and Display Name.

  • Select User roles for a new user (see IRT roles and permissions section to learn more about existent roles).

  • (optional) Select Message Monitor Filter roles if the user should have access to some filters. Message Monitor Filter roles are created automatically after Message Monitor Filter creation (see this section to learn how to create it).

    Users with IRTAdmin role have full access to all message monitor filters.
  • (optional) Configure Mapped SAP user names if you want to set up a mapping of system usernames with IRT users.

    Usernames can only be assigned to one user.

    Once you configure such mapping, the Figaf user (instead of the system user) will be shown in Change Tracking Tool and Testing tool.

10.2.2. IRT roles and permissions

IRT web app provides the following roles:

  1. IRTSuperUser - root administrator role. Only one user can be marked as a super user (default user). IRTSuperUser role gives full access to user management in the IRT, testing functions are not available for him.

  2. IRTAdmin - administrator role. User with that role has full access to the application functions.

  3. IRTLicenseRequester - standard user role. User with that role is able to request new licenses for the objects. Except possibility to change credentials of root administrator.

  4. IRTSensitivePayloadViewer - additional user role, should be used with administrator or/and any standard role. IRTSensitivePayloadViewer role allows user to configure confidential and secured agents and view original payloads of confidential messages.

  5. IRTOperator - standard user role. See permissions below.

  6. IRTConfigurator - standard user role. See permissions below.

  7. IRTUser - standard user role. User with that role can only browse pages and run tests. See permissions below.

  8. IRTDevOpsOperator - standard user role. User with this role can work with ticket, release, and transports.

  9. IRTDevOpsConfigurator - standard user role. IRTDevOpsConfigurator role allows to modify transport configuration.

The following abbreviations are used in the table below:

  • IRTU - IRTUser role;

  • IRTC - IRTConfigurator role;

  • IRTO - IRTOperator role;

  • IRTA - IRTAdmin role;

  • IRTSU - IRTSuperUser role;

  • IRTDOO - IRTDevOpsOperator role;

  • IRTDOC - IRTDevOpsConfigurator role.

Action\Role IRTU IRTC IRTO IRTA IRTSU IRTDOO IRTDOC

Authentication on IRT

+

+

+

+

+

+

+

Browsing pages

+

+

+

+

+

+

+

Testing Tool

Synchronization with agent system

+

+

+

+

+

+

+

Add/remove modules

-

-

+

+

-

-

-

Update Recording Configuration on integration object

-

-

+

+

-

-

-

Update Test Configuration on integration object

-

+

+

+

-

-

-

Start/stop recording

-

-

+

+

-

-

-

Create test suites/test cases

-

-

+

+

-

-

-

Run test suites/test cases

+

+

+

+

+

+

+

Merge test cases

-

-

+

+

-

-

-

Trim test cases (remove all messages from test case except defined number of message groups)

-

-

+

+

-

-

-

Update test case information (message/dynamic properties), delete messages from test case by group

-

+

+

+

-

-

-

Clean test suites/test cases (delete their all testing results)

-

+

+

+

-

-

-

Delete test cases (delete their all testing results, messages and test cases themselves)

-

-

+

+

-

-

-

Update test suite

-

+

+

+

-

-

-

Check test case/test suite results

+

+

+

+

-

-

-

Delete test suite (delete their all testing results and templates themselves). Note: linked test cases will not be deleted!

-

-

+

+

-

-

-

Delete testing results

-

+

+

+

-

-

-

Configure comparison configurations

-

+

-

+

-

-

-

View comparison configurations

-

+

+

+

-

-

-

Change Tracking Tool

Synchronization with agent system

+

+

+

+

+

+

+

DevOps

Manage releases (create, modify, release, add scenarios, attach/detach tickets)

-

-

-

+

-

+

-

Manage tickets (create, modify, attach/detach tracked objects, attach test cases, change status)

-

-

-

+

-

+

-

Manage transports (create, import, change status)

-

-

-

+

-

+

-

Run ticket

+

+

+

+

+

+

+

Modify transport configuration

-

-

-

+

-

-

+

Configuration

Application configuration update

-

-

-

+

-

-

-

Agents configuration update (except confidential and secured agents). Note: confidential and secured agents configuration available for administrator with additional role IRTSensitivePayloadViewer!

-

-

-

+

-

-

-

Test agent configuration

+

+

+

+

-

-

-

Landscapes configuration

-

-

-

+

-

-

+

User management

-

-

-

+

+

-

-

License update (add object licenses, modify object licenses)

-

-

-

+

-

-

-

Scenario mapping configuration update

-

-

+

+

-

-

-

10.3. Scenario mappings

You can have a case when scenario interfaces on the Agent system and Test system are a little different. Thus, messages which were recorded on the Agent system can’t be immediately used in the testing process because internal interface determination will fail and you will get only unexpected testing results. Use scenario mapping feature to solve that issue.
You can configure it on Configuration page (Mapping tab):

scenario mappings tab

There two ways of configuring mappings:

  1. Table with mappings on UI. You need to open Configuration page (Mapping tab) and edit the table with mappings.

  2. Define all mappings in csv file and them upload the file. On the first line you need to define systems for which you want to configure a mapping. The number of systems is not restricted. The names of the systems must be separated by a semicolon. Each line below must contain the same number of values (or empty strings) as the first line has. The values must be separated by a semicolon as well:

    csv file example

In both cases each value of the mapping has to follow the pattern:
<party>|<component> or <party>|<component>|<interface_name>|<interface_namespace>.
If you don’t have some part, skip it, but keep | in the mapping entry.

10.3.1. Value mapping

Look at the example above. Assume you have DPO as a Test system and DI3 as an Agent system, you have two integrated configurations with one receiver and one interface on DPO and DI3.

  1. DI3:

    • Party: MASTERCARD

    • Component: B2BAGENT

    • Interface name: INT_OUT

    • Interface namespace: http://figaf.com/irt

  2. DPO:

    • Party: MASTERCARD

    • Component: B2BTEST

    • Interface name: INT_OUT

    • Interface namespace: http://figaf.com/irt.

If you define that scenario mapping, IRT will expect testing result with MASTERCARD|B2BTEST|INT_OUT|http://figaf.com/irt interface, not MASTERCARD|B2BAGENT|INT_OUT|http://figaf.com/irt, despite recorded message has the second one.
In this case, interface name and interface namespaces are the same. So it wasn’t necessary to add them in the mapping. If they are not the same, you can also map them.

10.3.2. Generic mapping

It’s possible to avoid configuring lots of similar mappings if they have common parts.
For example, in the table below you can see some mappings which have the service pattern: BS*P (or even *P) on Agent system and BS*Q (or even *Q) on Test system.

Agent System Test System

B2B|BS_ERP1_P|intName|int_ns||

B2B|BS_ERP1_Q|intName|int_ns||

B2B|BS_ERP2_P|intName|int_ns||

B2B|BS_ERP2_Q|intName|int_ns||

B2B|BS_ERP3_P|intName|int_ns||

B2B|BS_ERP3_Q|intName|int_ns||

B2B|BS_DDL1_P|intName|int_ns||

B2B|BS_DDL1_Q|intName|int_ns||

B2B|BS_DDL2_P|intName|int_ns||

B2B|BS_DDL2_Q|intName|int_ns||

B2B|BS_DDL3_P|intName|int_ns||

B2B|BS_DDL3_Q|intName|int_ns||

B2B|BS_DDL4_P|intName|int_ns||

B2B|BS_DDL4_Q|intName|int_ns||

…​

…​

Instead of 7 different mappings, it can be covered by one generic mapping: B2B|BS*PB2B|BS*Q.
The star * in that mapping means identical part on both sides. For example for scenarios B2B|BS_DDL3_P|intName|int_ns|| and B2B|BS_DDL3_Q|intName|int_ns|| it’s possible to apply mapping B2B|BS*PB2B|BS*Q. Here * is _DDL3_.
The same can be done for party/interface name/interface namespace as well.
Value mappings have higher priority than generic mappings: firstly IRT looks for a value mapping. If it’s not found IRT looks for a generic mapping.

Important
Party and service can be a wildcard (value equal to *, e.g., B2B|* or *|*|OUTB_INT|http://company.com). In this case, such mapping must be determined as value mapping, not as generic mapping.

10.4. Anonymization variables

If you test some confidential data and you don’t want test them directly, you can use anonymization to anonymize your data. Message anonymization variables contain fields that can be used in your scenarios. Anonymization Variables page looks:

anonymization variables

On this page you can:

  1. Edit anonymization variables:

    1. Load csv file with new data.

    2. Edit data in the table. To enable edit mode click on edit button. After that you can add new variables, update or delete existing ones. To save changes click on save button, to reset - reset.

  2. Download current anonymization variables clicking on download light button.

11. Uninstallation

11.1. Process Orchestration agents

11.1.1. Removing modules added by IRT from communication channels

  1. Check that Agent has IRT Agent Module or SAP Log Module integration type enabled.

  2. Open Integration Objects page, click on the "menu" button above the table and then click the "Remove ALL modules" button. It will check all communication channels and remove previously added IRT modules (IRT Agent modules or SAP Log Modules with irtStage* parameter group), except IRT modules on our infrastructural XI 3.0 channels (because these objects are excluded in synchronization).

    agent objects page

    It will run removing function asynchronously, but you can monitor intermediate results in the dialog. It takes some time depending on the number of objects to process. Wait until the process is finished.

    removing progress dialog

11.1.2. Removing infrastructure scenarios added by IRT

  1. If Agent has been used for the testing purpose (test cases are run there), it also needs to remove infrastructure scenarios. Open Integration Directory Builder, search Integrated Configurations by TEST_MigrationHelper sender component name and remove these objects:

    pro infrastructure scenarios
  2. Then open TEST_MigrationHelper business component and remove it as well (all inner IRT communication channels will be removed):

    pro infrastructure component

11.1.3. Undeploying an Agent Component

  1. Switch Agent integration type to SAP Log Module or PI Message Log. Otherwise just enable "Is virtual" flag on Agent page. It will disable integration with Agent system.

  2. Use some tool to undeploy IRT Agent component (there is one SCA component which includes 2 DC components, one for DB and another one is EAR). For example, we are using Deployment perspective from Netweaver Developer Studio:

    nwds undeployment view

11.2. Cloud Integration agents

11.2.1. Removing testing scenarios added by IRT

Open Design page on the CPI system. Find and remove packages which name starts with FigafIRT, they also have a description like Package contains copies of agent objects of the package Demos with the replaced sender integration.

cpi packages

12. IRT Course

IRT Course is available here.

13. IRT public API

IRT public API is available here.

14. Change Log

2.15.8

  1. [Testing Tool, PRO] Added an option irt.testing.pro.disable-correlation-id-lookup (possible values: false - default, true) to skip lookup by correlation id in the message monitoring client.

2.15.7

  1. [FIX, DevOps] Fixed a bug when selection of transport configuration by group id and revision limit failed on MSSQL Server.

2.15.6

  1. [DevOps, CPI] Added a possibility to configure transport configuration for particular released version of CPI IFlow.

  2. [DevOps, CPI] Added a possibility to configure not approved/imported landscape items, transport configuration now becomes immutable only for the landscape item which has been approved.

  3. [FIX, DevOps, CPI] Fixed a bug when the latest state of CPI object was taken as a source during transport instead of specified version in transport. For example: let’s have a landscape dev → qa → prod and Iflow_x (v1) has been transported to qa. Then if user update object on qa manually, further transport to prod can use that updated version instead of the state Iflow_x (v1). Now IRT always take persisted specified version of the object. Also, we decided to block transport of the state X from system A to system B when the state X doesn’t exist anymore on system A. Use additional virtual landscape items to persist intermediate state if you want to update the state of object on system A quite often, for example A → A' → B.

  4. [FIX, CPI] Fixed a bug when object name of CPI object was shown as hash on License page and it wasn’t possible to modify (request additional license options) that object license item. It affected CPI objects which have different displayed and technical names. Process synchronization with the license server from License tab to migrate affected entries.

Notes for upgrade to 2.15.6

  1. Previous configuration in IRT hasn’t been affected.

  2. It’s required to process synchronization of license to migrate affected entries (see bug description in release notes).

2.15.5

  1. [Testing Tool] Added a possibility to configure test parameters per test case on Shared configuration page.

  2. [Testing Tool, CPI] Added two options Run steps selection strategy and Run steps filter (modelStepId or modelStepId|activity) to select steps which should be recorded/tested.

  3. [Testing Tool, CPI] Added an option Use only finishing run steps to fetch the first and last message in a test case.

  4. [Common] Added new user role IRTLicenseRequester to request new licenses for the objects.

  5. [FIX] Fixed a bug when users with roles IRTDevOpsOperator and IRTDevOpsConfigurator couldn’t update their own passwords.

Notes for upgrade to 2.15.5

  1. Previous configuration in IRT hasn’t been affected.

  2. It’s required to process forcible synchronization (option Synchronize objects forcibly) for CPI agents from CTT page.

2.15.4

  1. [FIX, DevOps, CPI, API Mgmt] Fixed a bug with landscape items validation when virtual items were defined manually.

2.15.3

  1. [Change Management, API Hub] Added API_HUB agent platform. This agent synchronizes and tracks changes in APIs added to the favourites list of connected account. See configuration here.

  2. [Support Tool, CPI] Added Cancelled status support to Message Monitor.

  3. [Testing Tool, CPI] Added support for all HTTP methods in HTTPS Adapter during testing.

  4. [DevOps, CPI, API Mgmt] Added a possibility to define virtual landscape items manually.

  5. [Testing Tool, CPI] Added recording of non-successful messages.

  6. [Testing Tool, CPI] Added a possibility to record MPL attachments.

  7. [FIX] Fixed a bug where IRT didn’t use proxy settings for CPI and API Mgmt.

2.15.2

  1. [Common] Added automatic determination of timezone for PRO agents.

  2. [CPI, Git integration] Added support of value mapping upload, download, and deploy to cpi-plugin.

  3. [CTT, CPI] Added a flag Synchronize objects forcibly to CPI synchronization request.

  4. [Testing Tool, PRO] Added a possibility to define list of channels where modules should be added.

  5. [Testing Tool] Added possibility to view polling statistics when there is polling in progress.

  6. [Change Management, Git integration, CPI, API Mgmt] Added option Update .gitignore automatically.

  7. [FIX, CTT] Fixed a bug where options Synchronize objects forcibly and Rebuild links for the latest versions forcibly didn’t delete incorrect links (only added missed ones).

  8. [FIX, DevOps, 'CPI`] Fixed a bug where transport configuration wasn’t cached after transport approval.

  9. [FIX, Change Management, Git integration, CPI, API Mgmt] Fixed a bug where build.gradle and settings.gradle were not committed with the enabled corresponding checkboxes.

Notes for upgrade to 2.15.2

  1. Previous configuration in IRT hasn’t been affected.

  2. It’s required to process reinitialization operation on Agents page for CPI agents with configured Git integration. Then, if automatic update of build.gradle, settings.gradle is not configured, copy the content of updated templates build-irt.gradle and settings-irt.gradle to these files manually.

    IRT 2.15.2 uses cpi-plugin 2.0.RELEASE with support of value mapping upload, download, and deploy. IFlow tasks were renamed to uploadArtifact, downloadArtifact, deployArtifact. The same tasks are used for Value Mappings. Folders VM_<valueMappingName>, created by IRT previously, aren’t used anymore and should be deleted.

2.15.1

  1. [FIX, CPI, Git integration] Fixed a bug where dependencies from the common module were not visible from IFlow module.

  2. [Common] Increased the range of exceptions where manual license request is available.

2.15

  1. [Change Management,DevOps, Testing Tool, CPI, Api Management] Added support of Cloud Foundry environment.

  2. [Testing Tool, CPI] Added automated polling of CPI IFlow after message sending.

  3. [Testing Tool] Added support and comparison of TRADACOMS messages.

  4. [DevOps] Added new public API to fetch information about the ticket and process transport.

  5. [Change Management, UI] Added visual viewer of Iflow BPMN model differences.

The build also includes minor changes and bugfix.

Notes for upgrade from 2.14 to 2.15

  1. Previous configuration in IRT hasn’t been affected.

  2. It’s required to process reinitialization operation on Agents page for CPI and API Management agents with configured Git integration. Then, if automatic update of build.gradle, settings.gradle is not configured, copy the content of updated templates build-irt.gradle and settings-irt.gradle to these files manually. Also, copy new parameters from gradle-irt.properties to your gradle.properties.

2.14.1

  1. [Testing Tool, CPI] Added a possibility to keep integration flow in trace mode.

  2. [DevOps, PRO] Added support of import transports with objects which don’t exist in IRT.

  3. [Change Management] Added a possibility to view object payload without download.

  4. [Testing Tool] Added an option to avoid recalculation of order number for 1→1 relation.

  5. [Testing Tool] Added an option to configure identification of collection items for XML messages.

  6. [DevOps, PRO] Extended CTS+ transports support:

    • CTS+ transport with all its children is saved into one group.

    • CTS+ transport with all its children can be sent to approval, approved, and declined in batch mode.

  7. [Support Tool] Added skipping of alerts if it’s not possible to determine active rule.

  8. [FIX, Testing Tool] Fixed test case extraction for test runs with aggregation.

  9. [FIX, Testing Tool] Fixed a bug when rerun test cases ran test case only on one test system.

  10. [FIX, Change Management, CPI] Fixed parsing of IFlow BPMN model with the wrong position of documentation element.

2.14

  1. [DevOps,Change Management, PRO] Extended support of File and CTS+ transports in the IRT DevOps functionality:

    • Added change tracking for File and CTS+ transports.

    • Integrated usage of PRO transport objects in the ticket

  2. [Change Management, CPI] Added possibility to use iflow as a configurable template to create many iflows. See new functionality for distribution configuration to learn more.

  3. [Change Management, CPI] Added possibility to restore last iflow version of deleted iflow.

  4. [Testing Tool] Added possibility to externalize comparison configuration and share it between different scenarios using message+partner+integration object identification. See overview of comparison configuration page to learn more.

  5. [Testing Tool] Optimization of test run/test suite run report generation:

    • New optional report generation strategy replaces Excel report by bundled CSV report which contain 3 files: processed messages report, diff report and test runs metadata report. Enable an option Use bundled CSV report generation strategy on the Application config page. That option will have effect only for new test suite runs or separate test runs.

    • Test run report generation won’t be triggered if at least one of the testing result is scheduled or currently in progress with comparison.

    • Test suite run report generation won’t be triggered if at least one related test run currently is not completed in the active polling or if at least one related test run scheduled or currently in progress with the report generation.

  6. [Testing Tool] Added an option for test runs/test suite runs for re-comparison of testing results in the context of the same test run. It’s possible to skip comparison of all SUCCESS entries or all compared entries.

  7. [Testing Tool] Added a possibility to extract message groups related to chosen results/test runs as new test case(s) from the test run/test suite run pages. Optionally it’s possible to link new test case(s) with the new/existent test suite. It provides a possibility to isolate problematic messages and test them separately without processing of the whole original test case/test suite all time.

  8. [Testing Tool] Added statistics of scheduled/active messages sending/comparisons/report generations for test runs.

  9. [Testing Tool] Added CSV export of Testing tool data with the applied filter for Test Cases, Test Runs, Test Run Results, Test Suites, Test Suite runs.

  10. [Testing Tool] Added support of ignoring options for XML comparison.

  11. [Testing Tool] Added pagination for Test Cases and Test Runs on UI.

  12. [Testing Tool] Updated rerun function in the test suite run. Now it’s possible to select and rerun many test runs at once.

  13. [Testing Tool] Added possibility to resend NOT_SENT messages from test run/test suite run pages.

  14. [FIX, DevOps, Git Integration] Deleted package/object now are also deleted from settings-irt.gradle or settings.gradle.

The build also includes many minor changes and bug fixes.

Notes for upgrade from 2.13 to 2.14

  1. Previous configuration hasn’t been affected.

  2. To use restoring of last iflow versions already registered in CTT before upgrade, enable forcible synchronization for related CPI Agent using a function Reset synchronization query on Agent dialog and then process full synchronization (or select required packages). It will download and save iflow bundles in IRT (that data wasn’t persisted in CTT before 2.14).

  3. Build has data migrations for big IRT tables. Depending on amount of test run results and test runs in the system, the first bootstrap will take some time. For example, we had a case with 15 min bootstrap time on the instance with 1.5 million testing results.

  4. Critical changes were made in the DevOps and Testing Tool related tables in the database schema. Data migrations are configured to be automatically executed during the first bootstrap.

2.13.8

  1. [Change Management, Git integration, CPI] Added 2 options on Agent to update build.gradle and/or settings.gradle automatically during synchronization.

  2. [FIX, Testing Tool, PRO] Fixed cancellation of EOIO messages. Also added support for cases when sender channel has quality of service EO but outbound message is EOIO.

  3. [FIX, Testing Tool, Change Management,DevOps, Monitoring] Refactored usage of detached transactions in the whole app. They could cause a deadlock in concurrently processed operations when IRT uses SQL server database.

2.13.7

  1. [FIX, Testing Tool, CPI] Fixed testing (both standard and with mock data) of integration flow with the local subprocess.

2.13.6

  1. [Testing Tool, CPI] Added initial support of iflows with the multiple sender endpoints.

  2. [Testing Tool] Check Testing Results option on Test Run and Test Suite Run now triggers comparison of received results. That also leads to regeneration of test run/test suite run report.

  3. [Testing Tool] Added an option for calculation of alphanumeric order number (by default it extracts digits from the source string).

  4. [Testing Tool] Added an option for recalculation of the order number during manual test case upload.

  5. [DevOps] Test Cases lookup from the Ticket now also works for non-integration object entries attached to the ticket.

  6. [FIX, Monitoring] Fixed a bug when one alert could be handled multiple times due to overlapped scheduled polling.

  7. [FIX, Testing Tool, CPI] Fixed CPI test object determination in the Run On operation (affected in 2.13.5).

  8. [FIX, Testing Tool, Monitoring, CPI] Fixed a bug when it wasn’t possible to register CPI IFlow integration object with the version label greater than 10 characters (also affected alerts handling for such iflows).

The patch also includes many minor changes and bug fixes.

2.13.5

  1. [Testing Tool] Consolidated report generation from selected Test Suite Runs. The function is available on the Test Suite Runs page.

  2. [Testing Tool] Test cases migration from PI scenario to CPI iflow. See more details here.

  3. [Testing Tool, UI] Separate page for Test Suite Run. Navigation is available from Test Suite Runs page, Test Suite page (Results History tab), Test Run Details page

  4. [Testing Tool, PRO] Added an option on Test Run Result item to browse related messages from PI Message Monitoring. Available on Test Run Details page.

  5. [Testing Tool, PRO] Added an internal job for checking JMS connection (if JMS integration is enabled and Agent is not virtual) and refreshing JMS context when connection is broken. That job is executed each 5 min by default.

  6. [FIX, Testing Tool, PRO] Fixed a bug when messages received through JMS due to PI redelivery were not filtered.

  7. [FIX, Testing Tool] Fixed X12 message determination for some combinations of segment and element separators.

  8. [FIX, Testing Tool] Fixed EDIFACT/X12 segment comparison for cases when one document has empty segment like PCI' and another document has segment with empty data element like PCI+'.

The patch also includes many minor changes and bug fixes.

2.13.4

  1. [Common, UI] Added possibility to configure mapping between SAP username to IRT username on User Details dialog to show IRT username in the Created By, Changed By and Deployed By columns of CTT and Integration object tables.

  2. [FIX, CPI, UI] Fixed IFlow deployment status on Integration objects page.

The patch also includes some minor changes and bug fixes.

2.13.3

  1. [Change Management, CPI] Added an option to synchronize only objects from selected packages.

  2. [FIX, Operations, Monitoring, CPI] Fixed the max length of condition parameter.

  3. [FIX, Operations, Monitoring] Fixed usage of emailTo parameter from application settings instead of email integration entry during alert notification.

The patch also includes some minor changes and bug fixes.

2.13.2

If you have CPI landscapes created in 2.13 and older versions, since 2.13.2 it’s possible to use them again. Just open landscape and reconfigure approval and deployment settings. Notice that unfinished transports must be deleted or cancelled.

  1. [DevOps] Added possibility to update approval and deployment settings in the existent landscape.

  2. [DevOps] Added and configured new user roles for DevOps operations.

  3. [UI] Landscapes configuration is moved to Configuration section.

  4. [Change Management, Git integration, CPI] Added configuration of additional Gradle modules layer for packages. As a result, now it’s possible to perform CPI/IRT plugin tasks at the package level.

    Remove the file settings-irt.gradle in the branch, configured in IRT, or remove all iflow module definitions from it. It must be done because new modules have different naming. Folder structure is not changed.

  5. [FIX,DevOps, Change Management, CPI] Fixed a bug when unprocessed tracked objects were marked as deleted unexpectedly after transport.

  6. [FIX,DevOps, CPI] Fixed deployment of value mapping after transport.

  7. [FIX,Testing Tool, PRO] Fixed recording request creation for dualstack systems (affected in 2.13.1).

The patch also includes many minor changes and other bug fixes.

2.13.1

  1. [DevOps, CPI] Changed the behavior of transport flow for CPI objects. Previously, during each import it always took the state of an object from the first system in the landscape. Now it takes the state of the previously transported object. So, having the landscape DEV → QA → PROD, import from QA to PROD will take an object state from QA instead of the DEV. Transport configuration will be applied as usual.

  2. [DevOps, CPI] Review is configurable now for each landscape item separately instead of the global config.

  3. [DevOps, CPI] Only transport reviewers are able to process import on the target system. It has an effect only when the review is configured.

  4. [DevOps, CPI] Added an option on landscape item to deploy artifacts after transport. By default deployment is disabled.

  5. [FIX, DevOps, CPI] Fixed a bug when it wasn’t possible to process import if transport contains object versions which already exist on target system. Now transport of these objects is skipped, after that transport items are linked with already existent versions in CTT.

2.13

  1. [Common, UI] Now it’s easier to get started with tool. Both login with the default user, guides to get started with adding license and agents. Updated tours to see the tool in action.

  2. [Testing Tool] Improved EDIFACT comparison and ignoring of specific segments/fields.

  3. [Testing Tool, PRO] Added a possibility to test aggregation scenarios. For now only integration through SAP Log Module is available. Test cases must be loaded manually.

  4. [Testing Tool] Added an option on Agent to control a max amount of test messages to be sent to Agent system per defined interval (configured as cron expression).

  5. [Testing Tool, PRO] Added an option to test on decentral adapter engine.

  6. [Testing Tool, PRO] Added a possibility to test BE scenarios with mock data on PRO systems.

  7. [Testing Tool, PRO] Support of sender agreements with EDI separator and fix of testing with sender modules in case of EDI separator flow.

  8. [Change Management, CPI] Added change tracking for packages, value mappings and documents.

  9. [DevOps, CPI] Added transport of packages and value mappings.

  10. [Monitoring, CPI] Added monitoring of persisted messages in the Message Monitor

  11. [Change Management, Git integration, CPI, API Mgmt] Added an option on Agent to prevent commits of iflow/api proxy changes during synchronization in IRT to avoid duplication of changes committed by user and IRT.

The build also includes many minor changes and bug fixes.

Notes for upgrade from 2.12 to 2.13

  1. Previous configuration hasn’t been affected.

  2. Critical changes were made in the CPI related tables in the database schema. Old table for integration packages are no longer used and will be deleted automatically once data migration is finished.

2.12.2

  1. [Testing Tool, CPI] Implemented recording and testing of integration flows on CPI system with confidential data.

  2. [Common] Default timezone is switched to GMT in the license validation.

  3. [FIX, Testing Tool, PRO] Fixed a bug with encoding of special characters in recorded payloads when SAP Log Module integration is used.

  4. [FIX, Testing Tool, PRO] Fixed a bug when it wasn’t possible to parse XI message during recording using SAP Log Module integration if that XI message didn’t have a default payload attachment name equal to MainDocument.

The build also includes many minor changes and bug fixes.

2.12.1

  1. [FIX, Testing Tool, PRO] Fixed a bug when it wasn’t possible to find messages on dualstack system for plain scenarios with only one message entry.

2.12

  1. [Testing Tool,PRO] Implemented recording of Receiver Determination objects (dualstack). See that section to learn more.

  2. [Testing Tool, PRO] Implemented recording and testing of asynchronous scenarios (plain EO/EOIO) on PRO system with confidential data. See that section to learn more.

  3. [DevOps,PRO] Implemented transport of Sender/Receiver agreement.

  4. [Change Management, Agent Synchronization, PRO] Added change tracking of receiver determination and interface determination objects (dualstack).

  5. [Change Management, Agent Synchronization, PRO] Improved synchronization algorithm to handle large data set from SimpleQuery.

  6. [Change Management, Agent Synchronization, PRO] Synchronization of external messages and operations is processed during the synchronization of external definitions and service interfaces. It speeds up the process, because external messages and operations are inner objects.

  7. [Common] Added configuration to support Java 11 runtime. See that section to learn more.

  8. [UI] UI5 libraries now are embedded within the Web application (as dependencies), now there is no requirement for having access to cloud distribution of OpenUI5.

The build also includes many minor changes and bug fixes.

Notes for upgrade from 2.11 to 2.12

  1. Previous configuration hasn’t been affected.

  2. No critical changes were made in the database schema.

2.11.6

2.11.6 has a data migration for external message/operation CTT objects, it can take some time depending on count of PRO agents and total count of external message/operation objects which were previously synchronized

  1. [CTT, PRO] Optimization for synchronization and data storage: payloads of external messages and operation objects now are not loaded from PI system during synchronization, because they are identical to payloads of related external definition/service interface objects.

  2. [CTT, CPI] Added runtime generation of simplified IFlow model, also added possibility to compare simplified models instead of standard BPMN models. It gives better way to see, what has been changed in the IFlow structure.

  3. [FIX, Testing] Fixed a bug when test suites were not run by scheduler if at least one object in any test suite is not licensed for testing.

  4. Many minor fixes and improvements

2.11.5

  1. [CTT] Added a new option on PRO Agent for synchronizing SAP ESR objects on demand. Use it if SimpleQuery can’t load metadata for all objects of any ESR type (in most cases Data Type) or if you don’t want to synchronize such objects at all.

  2. [DevOps] Information about last ticket run is added on the ticket page (see Last Testing Result tab)

  3. Some minor fixes and improvements

2.11.4

  1. [Common] Added alternative way for requesting object licenses when Java doesn’t have access to network. It’s enough to have access to https://app.figaf.com/irt-lic/#/ in the browser. You just need to copy provided request in IRT and use it on license server UI.

  2. Some minor fixes and improvements on UI.

2.11.3

  1. [Common] Improved UI for requesting object licenses.

  2. [FIX, DevOps] Fixed a bug when some ESR objects on target system were not linked with the ticket after transport (transport finished successfully).

  3. [FIX, Security] Email check during authorization now is case insensitive.

2.11.2

  1. [FIX, UI] Fixed a bug when landscapes were not loaded on the Create ticket dialog on the tickets page.

2.11.1

  1. [Common] Added possibility to request missing object licenses from license error dialog.

  2. [FIX, DevOps] Fixed a bug when transports created for several tickets at the same time were not linked with each other

  3. [FIX,DevOps, PRO] Fixed a bug when all business component’s channels were attached to the ticket during dependent objects attachment. As a result, ticket has too many attached channels instead of used by chosen scenario. Now it doesn’t take channels for components/systems or components/systems for parties during dependent object lookup.

  4. Some minor fixes and improvements on UI.

2.11

  1. [DevOps] New development and transport workflow. See that section to learn more.

  2. [DevOps] New migration workflow which simplifies e2e migration between 2 landscapes. Write to [email protected] to get a demo or support with configuration.

  3. [Common] Licensing model has been changed to fit requirements of the new functionality. If you already have an IRT with old license, see notes for upgrade to 2.11 below.

The build also includes many minor changes and bug fixes.

Notes for upgrade from 2.10 to 2.11

  1. Transport configuration has completely new model in 2.11 and it’s not possible to migrate old data, so, existing entries will be deleted.

  2. Critical changes were made in the tables related to DevOps functionality, the Testing Tool and Monitoring hasn’t been affected, small changes were made in CTT tables.

  3. Old installed license will no longer be used by the app, contact [email protected] to migrate your existent license to the new format.

2.10.6

  1. [Testing Tool, UI] New generic Test Suite Runs page under Testing Tool section.

  2. [FIX] Fixed alerts cleaner task.

  3. [FIX,PRO] Fixed a bug where communication channel update failed due to wrongly decoded characters.

2.10.5

  1. [FIX, CPI] Fixed propagation of original vendor and description during transport of integration flow.

  2. [FIX, CPI] Fixed determination of start event during test object creation. If integration flow had a local subprocess or exception subprocess, test object wasn’t not created properly. Current limitation - integration flows with several sender endpoints won’t be tested correctly, support of current case is scheduled for future releases.

  3. [FIX, CPI] Fixed a bug related to generated common testing classes for groovy scripts unit testing, where common tests failed when script doesn’t use messageLogFactory (added lenient = true to the mock).

2.10.4

  1. [FIX, PRO] Fixed a behavior of option Don’t send message after testing for BE scenarios. Now Agent Component throws an exception after 2nd stage (After Mapping) and Testing Result for 4th stage (After Result Mapping) is not registered in the test run at all, so, it won’t be compared.

2.10.3

  1. [FIX] Fixed missing default value for run_with_mock_data field for existent Test Suites (reproduced on MS SQL Server). Affected in 2.9.

2.10.2

  1. [DevOps, Testing Tool, CPI] Added messageLogFactory and messageLog mock objects to common module for unit testing of groovy scripts.

  2. [Testing Tool, PRO] Added support for Sender and Receiver agreements (Java stack) in the manual test case creation.

  3. [Testing Tool, UI] New generic Test Cases page under Testing Tool section.

  4. [FIX,Testing Tool, PRO] Fixed selectors for manual test case creation through archive upload. Now it’s possible to assign all needed interfaces and components.

  5. [FIX,Change Management, Agent Synchronization, PRO] Fixed wrong link to business component when channel has a * in the name.

  6. [FIX,Change Management, Agent Synchronization, PRO] Fixed missing link to business systems for communication channels.

2.10.1

  1. [DevOps, Testing Tool, CPI] Added a function for generating test data and unit tests for groovy scripts, defined in the integration flow. You can learn more here.

  2. [Operations, Monitoring] Added a Test function for rule external integrations (email and https).

  3. [Operations, Monitoring, UI] Improved Rules and Alerts UI.

  4. [Testing Tool, PRO] Added possibility to create test case manually using only UI form (it’s an alternative approach).

  5. [Testing Tool, CPI] Added possibility to run test cases and test suites on virtual landscape systems.

  6. [FIX] Fixed a bug when only default support rule was linked with new alerts (affected in 2.10).

  7. [FIX, Testing Tool] Fixed a bug where Test Suite excel reports were not sent to specified email correctly.

2.10

  1. [Change Management] Git integration for CPI and Api Management Agents. See that section to learn more.

  2. [Operations, Monitoring] Possibility to send alert attachments through email or webhooks integration.

  3. [Testing Tool] Possibility to mark Agent system as a Production system. It prevents testing on chosen Agent system.

The build also includes many minor changes and bug fixes.

Notes for upgrade from 2.9 to 2.10

  1. Previous configuration hasn’t been affected.

  2. No critical changes were made in the database schema.

2.9.1

  1. [FIX, Operations, Transport] Fixed a bug when post synchronization failed if only ESR objects are transported.

  2. [FIX, Testing] Fixed a bug when test suites couldn’t be run by a scheduled job.

2.9

  1. [Change Management] Added implementation of CPI shared resources (scripts, mappings, schemas, archives). There are many places where it makes sense to have scripts that are being used in multiple iflows. But if you want to make a change to the script you will end up with separate versions. It can be a pain to maintain it and also test it. We have added an option to take a script and turn it into a shared resource. You can then add this shared script to your iflows. If you make a modification to it the new version can easily be applied to all iflows where it is used. It will also allow you to test the change in all your iflows. You can learn more about new feature here.

  2. [Testing] Added possibility to test CPI iflows with mock data. Over the last year, we have improved the way we make it possible to test your CPI iflows. Now we have added a new option to test with a mock service hosted by the Figaf IRT application. IRT will then make a copy of the iflow you want to test. All Request Reply connections will be replaced with a call to the Figaf IRT mock data service that will respond with what needed changes in headers and payload. It means that it will be a lot easier to run a test for scripts or configurations that have been changed. If you own to use IRT hosted on your own environment you will need to specify cloud connector information to access IRT. Learn more here.

  3. [Operations, Transport] Added a warning if a secure resource like password or certificate is are not available on the target instance. In Figaf IRT you can configure which password/certificate properties you want across the landscape. So when you transport across the landscape you will see if the values are there.

  4. [Operations, Transport, Testing] Added improvement to the virtual SAP CPI landscape, so you can run Dev and QA on the same system. That way you can save a CPI system. Figaf now supports the Process Direct adapter in virtual environment, so you also will be able to test that functionality.

  5. [UI] Testing Templates have been renamed to Testing Suites, because it is a more standard name for grouping a set of test cases.

There is also a number of bug fixes and usability improvements.

Notes for upgrade to 2.9

  1. Previous configuration hasn’t been affected.

  2. No critical changes were made in the database schema.

2.8.2

  1. [FIX, Testing] Fixed a bug when test case report generation was processing infinitely if any test run result doesn’t have a link to inbound message. Current state in general is unexpected.

2.8.1

  1. [FIX, Common] Fixed a bug when it wasn’t possible to delete CPI Agent if at least one metric has been registered by SAP System Monitoring.

  2. [FIX, Transport] Fixed a bug when it wasn’t possible to define P4 host for PRO Agent if Agent Component integration type is not used.

2.8

  1. [Operations, Transport] Added support for PRO transports (file and CTS), added possibility to configure channels during transport. You can learn more about new feature here.

  2. [Change Management] Added documentation of IRT tickets. This is an excel report which contains common ticket metadata, attached object versions, related integration objects, result of the latest ticket run and information about processed transports.

  3. [Change Management] Added documentation of CPI Integration Flows.

  4. [Operations, Monitoring] Added alerting for CPI Tenants status monitoring events.

  5. [Operations, Monitoring] Added possibility to mute identical alerts for defined period of time.

  6. [Operations, Monitoring] Added a scheduled task for alerts deletion. User can configure it on Application Configuration page. By default, alerts are stored for 90 days.

  7. [UI] Home page has been changed. Now in addition to the menu tiles it contains a list of configured landscapes with most used links per each Agent system in the landscape. You can find more information here.

Notes for upgrade from 2.7 to 2.8

  1. Timezone parameter has been added to PRO agents. New transport functionality requires this parameter for correct object version identification. SimpleQuery API doesn’t have information about timezone in the response, all dates are sent in local datetime format. It’s strongly recommended to configure that new parameter properly even if transport functionality in the IRT won’t be used for a while or when your Agent system is hosted in the same timezone as IRT. The new parameter has default settings: GMT timezone. Configuration of timezone parameter should also be done in GMT format: GMT+2, GMT-5, etc. Agent timezone can be found on NetWeaver Administrator page (/nwa).

  2. Critical changes were made in the previously released features:

    • Metrics (affected database schema and model in CPI Tenants status monitoring, irt-2.7).

    • Transport configuration (affected database schema and model in CPI IFlow transports, irt-2.6).

2.7.2

  1. [FIX, Testing] Fixed null pointer exception during checking of MigrationHelper scenario (PRO, affected in 2.7.1)

  2. [FIX, Change Management] Fixed missing updates during PRO synchronization due to wrong time zones used in SimpleQuery. Correct Agent system timezone must be configured manually on Agent dialog. Default value is GMT.

2.7.1

  1. [FIX, Testing] Link to folder now is not lost after channel update

2.7

  1. [Change Management,Operations, Transport, Monitoring] Added support of API Management agents, added change management, monitoring and transport for API Proxies with their related resources (policies, endpoints, etc.). You can learn more about API Proxy change management and transport here, about monitoring of API Proxies - here.

  2. [Operations, Monitoring] CPI Tenants status monitoring. It includes several metrics such as CPU/Memory usage, iflow latency, processed messages. You can learn more about that new feature here.

  3. [Operations, Monitoring] Runtime Message Monitor for CPI Agents, in addition to the possibility to define flexible filters, it allows you to configure role-based access to these filters and decide which IRT user can access to exact filter and what kind of access: browsing messages metadata only or with attachments as well. You can learn more about it here.

  4. [Operations, Monitoring] New alerting engine in IRT. We improved its performance and throughput, made alert metadata structured, improved determination of Tracked Objects and Integration Objects (depending on alert type and system type). Since an alert is a temporary entity and doesn’t require long storage, we decided to clear them all during automated database migration because it’s not possible to correctly migrate old alerts (and actually, it doesn’t make sense). In the future releases we are going to improve post processing actions for alerts and provide a flexible strategies for notification and reprocessing (when it’s actual).

  5. [Change Management] Test Cases coverage for PRO Agents. We improved operation mapping usage report and added additional information about actual test cases coverage and usage statistics for communication channels. You can learn more about new feature here.

  6. [Testing] Integration with new Process Integration Testing tool, provided by SAP in SP14. For now it’s possible to create PIT test case from testing template run in IRT. You can learn more about it here.

  7. [Testing] Added native support for regression testing of IFlows with Process Direct sender for CPI Agents. It uses special infrastructure IFlow with HTTPS sender and Process Direct receiver instead of copying full source IFlow and replacing its sender side by HTTPS sender (old approach). For now that infrastructure IFlow should be configured manually.

2.6.2, 2.6.3, 2.6.4

  1. [Migration from IRT 1.4.*/1.5.*] Improved migration functionality, fixed some bugs

2.6.1

  1. [FIX, Security] Custom roles check during authorization

2.6

  1. [Security] Custom API-key authentication approach has been replaced by OAuth 2.0.

  2. [Operations, Transport] Transport functionality for Integration Flows on CPI Agents. Possibility to define custom IFlow configuration which is applied during transport.

  3. [Operations, Monitoring] Reprocessing of CPI alerts. You need to add our script to the IFlow at the specific places, that script saves needed header properties and the payload of the message. Then it is possible to reprocess an alert and resend failed message again to the origin endpoint.

  4. [Operations, Monitoring] Improved performance of alerts handling.

  5. [Operations, Monitoring] Possibility to trigger alerts lookup for chosen consumer manually.

  6. [Change Management] Possibility to build and download documentation of Integrated Configurations (PRO systems).

  7. [FIX, Change Management] Restoring of previously deleted tracked objects. When some object is deleted on SAP system, it’s marked as deleted in IRT. Then if you create a new object with the same name again, it will be added as a new version in IRT after synchronization with a link to the previous version, so, the history of your changes won’t be lost.