In this section is presented This section presents an overview of the mandatory elements for the use of Int4 IFTT on a non-SAP middleware platform. Before the regression testing starts, there are several elements that Int4 IFTT requires in order to create and execute test cases.
Let’s add a diagram with external systems and IFTT
...
Pls describe the diagram. What are the preparation steps, how it works
...
As you can see on the diagram below, the testing is separated into two parts. So let us have a look at each part's details to make clear what exact steps are performed.
...
Before Testing
Think of any process, and it has a connector to receive input messages. Then the processing logic manipulates the input message according to the requirements. Finally, at the end of your process, another connector sends the messages to SAP ECC or the S/4HANA system.
To perform regression testing and validate the processing logic, we need to take an already successfully processed input message, re-run it and compare the outputs.
For that purpose, before testing, Int4 IFTT needs to receive both input and output message payloads.
Technical Preparation Steps
As shown on the diagram, Int4 IFTT requires the logging of payloads before processing (exactly after the start connector) and after the processing logic (before the send connector).
In many cases, the payload logging is already implemented in the original processes. In that case, the current common logic for logging can be reused, and just
...
in the logging process needs to be
...
Describe the idea of dispatcher. that this is a flow that receives the test messages from Int4 IFTT and virtualizes the sender systems by sending messages to original receiver channels of tested flows.
The following interface elements are obligatory for the Int4 IFTT logic:
Test case creation: message payloads persistence, before and after processing, according to the interface testing type
HTTP Client URL - only in case of direct process call from Int4 IFTT (to bym dal do sekcji dispatchera, ze w przypadku interfejsow typu HTTP, mozna go pominac i wyslac bezposrednio z iFTT)
Te szczegoly bym przesunal do artykulu ktory jest ponizej i opisuje wymagania odnoscnie logowania.
...
Additional interface details:
Process/Interface Name
Interface namespace (optional)
Landscape (e.g. DEV, TST, PRD)
Message ID - unique for every processed message
Execution ID - unique for every process execution and common for all the related messages of each execution
Correlation ID - common for every message of a single test case execution (optional)
Step - INPUT or OUTPUT
System ID (e.g. Boomi, Mulesoft)
...
modified to call a Payload Persistence Process that will save the payload to Int4 IFTT.
Otherwise, when there is no logging mechanism on your processes, the persistence for payloads must be provided by changing the initial processes.
The Testing
During test case execution, Int4 IFTT can inject the input message into the correct Dell Boomi process. This feature is handled by an additional process called Int4 IFTT Dispatcher. After the message enters the original process, it gets processed as usual. At this step, we will also need the payloads before and after processing. In the same way like before testing, the message payloads will be stored in Int4 IFTT and will get compared accordingly. Finally, you end up with the Int4 IFTT Test Results Report.
Technical Preparation Steps
To achieve the injection of the input messages into the corresponding process, an additional process called Int4 IFTT Dispatcher is required. The Dispatcher is a process that allows virtualizing the sender systems by sending the messages to the original processes.
Inside the Dispatcher, there needs to be configured a corresponding routing logic for the processes that will be tested. To complete the Dispatcher routing, Int4 IFTT provides additional details on HTTP custom headers together with the input message, so the Dispatcher knows which process needs to be called.