IFTT Service Virtualization with dynamic response - Step-by-step procedure

The typical setup consists following steps:

1. Identification of the interfaces to and from the external system

First, you need to analyze the current setup and flow of the messages exchanged between SAP and the external system(s). Then, you need to identify which messages are being sent from the system, which IFTT will virtualize. You need to know what response is expected based on a particular request.

As an example of the use-case of the Service Virtualization, we are going to implement the test scenario for the following business process:

On the backend system, a PO document is being created. Confirmation quantity based on % should be provided in header text. The creation of this document triggers the integration to the third-party system.
That operation will trigger the Delivery Document creation in the Backend System.
The third-party system receives the message with information about the Purchase Order and the Delivery and sends a shipping confirmation response message. The item quantity in this document should reflect the information provided in the header text of the Purchase order.

2. Implementation of virtualization logic in XSLT or middleware mapping.

You need to specify the transformation logic based on what response is expected based on a particular request. It should be as dynamic as possible.

Transformation logic can be implemented using middleware mapping (PI/PO mapping or the CPI mapping) or the XSLT technology.

To fulfill this scenario, we have created a CPI mapping that will be used to simulate the response message.

To test the scenario of the confirmation quantity based on the input factor, we have added a Groovy Script to the CPI mapping.

In case the XSLT transformation is used instead of the PI/PO or CPI mapping, please refer to the section:

https://int4support.atlassian.net/wiki/spaces/IUM/pages/688619530 for more information.

3. Creation of the test case responsible for the creation of the Business Document and the listener test case

Create a parent test case (first in the sequence). Like in the classic E2E testing, the full flow will be triggered by a parent test case responsible for creating the first Business Document.

For creating the document, you should use one of the techniques used in the Business Flow testing, like, for instance, Manual Creation or the eCATT.

The following test case, which should exist, will be responsible for waiting for the virtualized answer from the external system. Use (or create a new one) the Automaton Object that is pointing to the Response message for that purpose. Use Test Type as the “PI Listener” (21), so then the Test Case will check (listen) if the answer from the external system reached the PI/PO system. Please remember to configure the Variables in the Automation Object, so then the correct document number will be fetched, for example:

Please write down the test case number as you will use it in the following steps.

For more information on how to create a sequence of test cases for the E2E testing, please refer to the section: https://int4support.atlassian.net/wiki/spaces/IUM/pages/709394556

4. Creation of Int4 IFTT automation objects

As a next step, create an Automation Object that will be responsible for the implementation of the virtualization logic.

The Automation Object should point to the integration, which is aimed to be virtualized by IFTT. For instance, the expected response message from the external system. For more information about the creation of the Automation Object, please read the section of the https://int4support.atlassian.net/wiki/spaces/IUM/pages/258135, which fits this particular scenario.

5. Activate the scenario by scheduling a virtualization job using the sequence of the test cases.

In our example scenario, we have created the sequence of the test cases

The parent test case, made in step 3. In our example, it is an eCATT type test case, creating the Purchase Order document in the Backend system
The test case used for checking if the answer (with ORDERS) reached the PI/PO system, of type “PI Listener”

3. The test case used to virtualize the answer sent from the Backend to the external third-party system, the response for the message fetched from the “PI Listener” test case. This test case should be of type “PI Responder”, and as the Parent, you should set up the Test Case number you wrote down earlier (the “PI Listener” test case). As an Automation Object, create or use the one pointing out to the integration, which is used to respond to the message sent by the external system.

Don’t modify the Automation Object yet, just assure that it would read the Document Number

Until (and including) this step, the configuration is the same, independently of which type of mapping will be used.

4. Now, you need to create a test case that will map from the answer to the response message. Set up test type as the “SAP CPI E2E Inbound”. As an Automation object, point out the object assigned to the CPI script, created at the beginning of the process.

If you are using the XSLT transformation, you don't need to use the Automation Object. Instead, you need to upload the XSLT file using the button "Container". In this case type of the test case should be "PI Manual Inbound".
In the case of the "PI Mapping", the test type should be "PI Unit Test" and, as the Automation object, provide the same used in the "PI Listener" test case.

5. As the last step of the configuration, you need to modify the Automation Object used by the “PI Responder” test case. Go to the Additional Parameters, provide Parameter name “TRANSP_INP2” and the “PI listener” test case number as the parameter value

Test Cases Execution

To test the entire solution (and virtualization of the external system), you need to run the sequence of the test cases.

While the first test case runs, the entire process is triggered. eCatt will simulate the creation of the Purchase Order document. Please note that the confirmation quantity based on % is provided in header text with a value of 25 (25% of 200)

We can see the document number also in the Test Case Execution Report:

Next in the sequence, test cases of the “PI Listener” and “PI Responder” test types are being run, which simulates the response from the third-party system.

As a result, all test cases results passed successfully, and the Shipping Notification document was created in the backend system. The quantity of the item reflects the factor provided in the header text of the Purchase Order (25% of the 200)