In this section is presented 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
the persistence for payloads needs to be provided by changing the original flows. In many cases the current common logic for logging can be reused, and just this part needs to be modifed
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)
Test case execution: injection of the message into the correct process/interface (Int4 IFTT Dispatcher)
...