The Implementation Guide is a complex e-learning solution for Int4 IFTT Customers and Partners. It contains all our e-learning materials categorized by use case scenarios and a brief introduction to each of the capabilities. We recommend reading the entire guide and then extending the knowledge by included links to the detailed materials.
This document contains the end-to-end implementation guidelines.
Int4 IFTT is the automated testing software for SAP API. The testing covers integration platforms like SAP PO and SAP CPI and the interface processing in SAP ABAP backend systems like SAP S/4HANA. This holistic approach allows testing the whole SAP Landscape.
The classical test pyramid contains three significant types of testing areas. On the bottom are unit tests. The middle level represents testing the application programming interfaces (API). The top level of the pyramid shows user interface and end-to-end testing. This topic, together with the answer to how Int4 IFTT fill the pyramid by testing the integration scenarios, is covered here: OpenSAP W1U1: Introduction to Testing of Integration Scenarios with Int4 IFTT.
Thanks to the Int4 IFTT service virtualization feature, it is not required to access the 3rd party systems to perform SAP landscape testing. Int4 IFTT virtualizes the senders and receivers in the asynchronous scenarios using historical messages (incoming or outgoing) and reprocessing them again at the integration platform level, as they would come from original systems. In the case of outbound scenarios (communication from SAP Landscape to the external world), the test result will be based on the message leaving the integration platform. In the synchronous scenarios, Int4 IFTT virtualizes the sender system. The testing is done based on the response from the receiver.
Test cases in Int4 IFTT are created from existing interface messages and associated business documents. Therefore test case creation is codeless and takes seconds. There is also no need to define results for each test case. Respectively a final integration platform output or newly created document will be compared with the snapshot. The outcome of the comparison is a part of the test case.
Separation of test case data and validation rules (Automation Object)
One of the Int4 IFTT's concepts is to separate the test case data from common rules for the tested interface. That means that the user should define all the validation rules, comparison, properties for a particular interface in the Automation Object. Then the test case creation is done separately but using the properties already defined in the Automation Object. Please note that the detailed approach, both for the https://int4support.atlassian.net/wiki/spaces/IUM/pages/241511 and test case creation, will be explained in following sections.
API Transport layer and API Functional layer testing
You can divide The SAP API testing into two different blocks: SAP API Functional layer testing and SAP API Transport layer testing. SAP API Transport Layer testing is related to the integration platforms used to connect SAP with external systems. There are integration platforms, both from SAP (SAP Process Orchestration or SAP Cloud Platform Integration) and other non-SAP solutions. A typical example of a project that needs API Transport Layer testing is the SAP PO Migration.
SAP API Functional Testing focuses on testing the integration scenario in the whole SAP Landscape. It means that this would combined testing of the integration platform and the SAP backend system (ABAP-based business system). In addition to the transport layer, Int4 IFTT will test the interface elements like IDOC or Proxy Layer, custom ABAP user-exists, BRF+, and SAP customizing. The results will be built based on the business documents (ex. sales order) posted by the interface scenario.
The most significant example where this type of testing can be used is the S/4HANA conversion project.
Single Int4 IFTT instance tests all the non-productive environments like development, test, quality. It also connects read-only to the production. For exchanging test cases between environments, at least for SAP PI/PO, it is also necessary to map the business system names. Please follow this article to understand the concept: https://int4support.atlassian.net/wiki/spaces/IUM/pages/254017539.
Deployment and Installation
The Int4 IFTT is an SAP ABAP Add-on, and therefore its deployment should be performed by the Basis team, according to the steps standardized by SAP. Details of the installation are described in a separate guide.
And then initial customizing should be done as per following instruction: Initial Customizing for SAP PI/PO. Moreover a special technical ICO and communication channels are needed in the SAP PO. This is described in the installation manual.
Int4 IFTT utilize Boomi standard APIs to get the message payloads for test case creation as well as on test case execution. For that purpose, one main RFC is needed to connect Int4 IFTT with the Boomi APIs. The communication user should be created with proper authorizations to get the document data. Also, before starting the test case collection it is obligatory to make sure that each process that should be tested is deployed with General Process Mode. All the details for the initial configuration can be found under https://int4support.atlassian.net/wiki/spaces/IUM/pages/2026143757.
Optionaly, specific processes may require Boomi Dispatcher process deployment for test case execution.
SAP Backend (ECC, S/4HANA) connectivity and customizing
This section contains all necessary content and links to learn how to use Int4 IFTT based on the particular use cases. For each tested technology, it starts with the Continuous Testing use case, which describes the technical capabilities of the tool, and then we discuss the other appliances. Therefore the knowledge from the Continuous Testing use case is essential for the further ones.
Automation object is a starting point for adding any new interface/scenario to Int4 IFTT. It is a group of common rules that belongs to a particular tested interface. Please see the OpenSAP introduction lesson: Configuration of an Automated Object (requires login to an openSAP account).
Int4 IFTT supports both ABAP and JAVA stack. For instance, in SAP PI/PO configuration wizard, you can define if automation objects will be created from one or another. Here you have a collective article that describes the settings needed for handling the ABAP stack. It starts from SAP PI settings, then shows what are the global settings in Int4 IFTT, and finally describes the settings on the automation object level, to indicate that this is an interface implemented in ABAP stack:: https://int4support.atlassian.net/wiki/spaces/IUM/pages/484802598
Data scrambling is a feature to deal with sensitive data. This functionality is significant when the test cases are created directly from production messages. Here you find materials on how you can configure it in Int4 IFTT:
A lot of control settings are managed as automation object additional parameters. Please review the list and description.
Test case creation
After creating the automation object (or even before), you are ready to make the test cases. Please note that asynchronous interfaces will have test type SAP PI/PO unit test, and synchronous will have type SAP PI/PO synchronous. How you create the test cases for the SAP PO JAVA stack and ABAP stack is the same. It only requires different settings in the automation object.
Please note that test cases downloaded from Production landscape might contain sensitive data. This data is stored in IFTT tables and might be sent to other systems during test case execution. Sensitive data can be scrambled by appropriate rules in the automation objects.
You can also create the test cases manually just by providing the known message GUID number.
The Robotic Crawler is a handy tool when you need to create massively test cases for different interfaces. In terms of testing SAP PI/PO, we can successfully create a regression test database just by collecting already processed messages.
Int4 IFTT helps you to identify and minimize integration failures during SAP PI to SAP PO migration projects. The background is discussed here: OpenSAP W2U2: SAP PI/PO Migration. ( it requires a login to an openSAP account to move to the appropriate section )
Building test cases based on Production system inputs and Quality system outputs
n many companies, the persistence level is set to the minimum to increase performance and reduce database utilization. In such a case, the production SAP PI/PO system stores only the input payload of processed messages. Assuming that the old production and old quality system are the same in terms of the integration logic, the solution is to create SAP PO inbound test cases from the production system first. These test cases will contain only the input messages. Then the next step is to execute the above test cases in the Quality system, where the persistence is set to store the input and output. The last step is to recreate the SAP PI/PO Unit Test cases from the Quality system.
There are circumstances where an interface has multiple receivers in the QA environment and only one in DEV. In such a case, we need to add this exclusion system rule. It is still necessary to run the test case correctly, disregarding the absence of the particular receiver system. This feature is known as Maintain Landscape Exclusion Systems List.
To create a test case for the CPI scenario, you need to perform similar steps as for the PI/PO test cases. However, you should pay attention to activate the trace for messages to capture the SAP CPI interfaces' content correctly. How to do it and how to create CPI test cases using Int4 IFTT is described here https://int4support.atlassian.net/wiki/spaces/IUM/pages/704938513.
SAP PO to SAP CPI migration
Int4 IFTT helps you to identify and minimize integration failures during SAP PO to SAP CPI migration projects. The background is discussed here: OpenSAP W2U3: SAP PI/PO to SAP CPI Migrations. ( it requires a login to an openSAP account to move to the proper section ).
The SAP S/HANA continuous testing use case helps you in the BAU activities. The background is discussed here OpenSAP W3U5: SAP S/4HANA Back-End Testing. ( it requires a login to an openSAP account to move to the proper section ).
In this use case, we need to pay a lot of attention to the crucial Int4 IFTT features.
Linking flows that start in the integration platform (SAP PO, SAP CPI, DELL Boomi, etc.) and checking the final interface outcome by validating the final business document created by the message (for example, sales order, delivery, invoice, etc.)
Integrating Int4 IFTT with eCATT scripts for UI automation and validating the interface messages triggered by user actions
Testing full business flows that will combine inbound interface steps, outbound interfaces, and manual actions.
Calling Int4 IFTT by API and combining complete end to end tests automation with external software
Testing inbound flows
The inbound flow test case is a combination of an original input message from the integration platform and the validation of the final transactional document created on its basis in the backend system.
As is stated in the article, there are multiple test types for inbound testing that differentiate the integration platform name. Most of the examples and information will refer to the SAP PI/PO platform, but all the concepts are the same. Moreover, the testing might be limited only to the S/4HANA integration layer without the integration platform. In such a case, Int4 IFTT can handle the https://int4support.atlassian.net/wiki/spaces/IUM/pages/704840103 messages. The reasons to bypass the integration platform testing might be various:
lack of test messages in the integration platform but access to all historical IDocs
Int4 IFTT does not support the specific integration platform
Automation Object with document validation for inbound flows
As we described in the above use cases for testing the integration platforms, the critical thing for testing each interface is building an automation object.
Typically in an inbound end to end scenario in an SAP environment following features of automation object is needed:
Header with identification to the interface in the integration platform
linking the interface messages and the reference and current transactional document to perform the validation (document comparison)
searching based on business values by Message Selector or SAP PI/PO Robotic Crawler
Database validation rules - the set of tables and fields that need to be compared to show the differences
Data scrambling rules if input message contain sensitive data from the production system
In Int4 IFTT, many predefined automation objects exist and contain database rules and definitions for the most common SAP S/4HANA or SAP ECC transactional documents. You can use those definitions and speed up the creation of your Automation Objects for specific interfaces: https://int4support.atlassian.net/wiki/spaces/IUM/pages/1219100673
The Robotic Crawler is a handy tool when you need to create massively test cases for different interfaces. In terms of testing SAP PI/PO, we can successfully create a regression test database just by collecting already processed messages. The Robotic Crawler is not only limited to the SAP PI/PO unit testing. You can create the test cases with back-end validation (the Inbound E2E type or Synchronous E2E type). Please remember to change the default interface type on the selection screen. As well as please make sure that automation objects contain database validation rules.
In this scenario, Int4 IFTT tests all the process steps when the SAP Backend business transaction document triggers the interface messages, which are later sent out to the receivers by the integration platform.
In general outbound scenario is always a combination of two test cases. The first one is a backend trigger to populate the interface message from SAP S/4HANA. The second test case is an E2E outbound test case that will search for a proper message in the integration platform and compare it with the reference. The parent ID field links the first and a second test case. And, the configuration of the variable from automation objects passes the document numbers. There is one exception, it is possible to test E2E outbound scenarios for application interfaces based on SAP Output Control. A single test case approach is described here: https://int4support.atlassian.net/wiki/spaces/IUM/pages/1407877121.
Below you will see following methods for the first triggering test case.
The triggering test case
Using the output control test type
It is the easiest method for transactional documents that use message control to control the output messages (IDOCs or ABAP proxies, or others).
Another way is a replication of the entire playback of the document created by the GUI recording. The new document will trigger the interface message that the second test case will capture. This method has the most compressive testing scope. The validation of the interface message also checks the whole business transaction. It is also the most time-consuming in terms of the test case creation as it requires SAP eCATT recordings.
This process would trigger the SAP PI/PO Outbound test case, and the results will be passed back to the external software.
The outbound test case
If the first test case precedes the triggering of the interface message from SAP Backend, it is time to build the second one. The role of this testing type is to capture the final output message from the integration platform.
Depending on what is an interface technology, there are several E2E outbound test types in Int4 IFTT.
Capturing the final output in SAP PO
You should use PI E2E Outbound test type to check the flow in which a business document at SAP Backend triggers the message to SAP PI/PO. Then this message generates a final version of an XML or flat file to be ready to be sent out to the 3rd party receiver.
API service, which is included in the Int4 IFTT landscape, can be used to perform testing from external software or be called locally from custom SAP ABAP programs. The whole process will speed up and automate testing operations.