Implementation Guide

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.

 

 

Basic concepts

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.

Please review the section https://int4support.atlassian.net/wiki/spaces/IUM/pages/264384 to get an overview of the Interface Testing Tool and gain knowledge how it can help your organization to automate the testing process. It is also explained in the Int4 IFTT OpenSAP course: Open SAP W1U5: Int4 IFTT Basics. It requires a login to an openSAP account linked to the proper lesson.

Testing Pyramid

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.

Features

Service Virtualization

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.

Repeater

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.

Testing Types and Supported Technologies

Int4 IFTT allows testing of various interface types. Details of what these testing types are and how to use them are described in relevant sections for https://int4support.atlassian.net/wiki/spaces/IUM/pages/704905755, , , other integration platforms as well as .

Landscape Definition

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: .

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.

The available options of installations and the initial customizing steps are covered in the video: Open SAP W3U1: Installation and Initial Customization.
The detailed summary is available under List of the installation and customizing steps.

SAP PO connectivity & customizing

A communication user in a tested PI/PO system should be created before establishing a connection to the SAP PI/PO system, accordingly to .

Besides you should ensure that SAP PI/PO persistence settings are set correctly like described here and .

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.

SAP CPI connectivity & customizing

Similarly, as for SAP PI/PO, the connection between the system where Int4 IFTT is installed and the tested CPI system should be made, like described in section .

Besides, the initial customizing should be performed accordingly to Initial Customizing for SAP CPI.

Boomi connectivity & customizing

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 .

Optionaly, specific processes may require Boomi Dispatcher process deployment for test case execution.

SAP Backend (ECC, S/4HANA) connectivity and customizing

During Int4 IFTT usage, the following communication users will be needed in terms of SAP Backend: .

Initial Customizing

To finalize Int4 IFTT installation and initial customizing, you should set different global settings: . Part of the initial customizing is to add environments in your landscape (for example, DEV, TST, PRD). Later, you need to map the business systems and components to allow exchange test cases (at least for SAP PI/PO) between them. Please review the underlying sections of .

First Test case and user interface

After finishing initial customizing and making sure that the tool is configured correctly, please go to the section and create your first IFTT test case (for SAP PO). To make it easier for you to navigate through the tool, please also refer to the main IFTT transaction user interface description here: .

Use Cases

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.

SAP PO Continuous Testing

Introduction

The continuous testing use case helps you in the Business As Usual activities. The background is discussed here: OpenSAP W2U1: Business as Usual (BAU) SAP PI/PO and SAP CPI Testing and here: Open SAP W1U4: Testing in DevOps. ( To move to the correct section, you need to login to an openSAP account )

We described the technical capabilities in another OpenSAP lesson regarding SAP Process Orchestration Testing (W3U3)

To check what are the test types for SAP PO please look here: SAP PI/PO Test Types

Automation object

Concept

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).

After reading this article: , you will have a better overview of the requirements for different test types. Please note that for SAP PO testing, you don’t need to create them manually.

The detailed information about the automation objects and all available settings start here:

Creation of automation objects for SAP PI/PO unit tests

As mentioned above, there are three ways to create automation objects automatically.


The first one is to use the SAP PI/PO wizard:
E-learning video: https://www.youtube.com/watch?v=_Lh3eJnr2nQ&feature=youtu.be&ab_channel=Int4
Documentation :

The second approach is related to the SAP PI/PO crawler. By using this tool you will not only create automation objects, but even the test cases. Here you will find the necessary information: . This topic is explained fully in the next chapter.

The third method is to create the objects based on the sample messages:

You can also create the objects manually. Here you will find a detailed description: . Also please note that some scenarios may require testing the adapter modules: .

SAP PI ABAP Stack

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::

Exception List

Your test case results may differ from reference messages because of some dynamic logic in the interface implementation. For example, the mapping can put the current date & time. For this purpose, the automation object contains the .
It is possible also to create those exceptions directly from the test case results:

Data Scrambling

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:

E-learning video: https://www.youtube.com/watch?v=Q4zpTKmMu24&feature=youtu.be&ab_channel=Int4
Documentation:

Additional Parameters

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.

The easiest way is to use the Message Selector:

Manually with message selector

E-learning video: https://www.youtube.com/watch?v=8DlrXeREzDs&feature=youtu.be&ab_channel=Int4

and we can refer you again to the . Here in this example, the test case was created by Message Selector.

You can also create the test cases manually just by providing the known message GUID number.

Robotic Crawler

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.

E-learning video: https://www.youtube.com/watch?v=aGREgQccLjE&feature=youtu.be&ab_channel=Int4

Manually with creation of automation object

The last method was also mentioned in the Automation Object section. This way is used to create both the test case and the automation object in one step.

Test Case Execution

Under the link below, you can check the details of the TC execution: .

In terms of SAP PI/PO testing, the results are built based on comparing reference messages stored in test case definitions with current outputs. The way how Int4 IFTT does it is available here:

Scheduling test case execution

While performing continuous testing, it is essential to automate the test case execution. To achieve this fact, you can schedule Int4 IFTT tests as SAP Jobs. Please refer to this guide:

Automatic defects/incidents creation

In performing continuous testing is important to assure that there is no chance that the error will be unnoticed. For that purpose, there is an additional module in Int4 IFTT that integrates the execution runs with incident management systems and creates the incidents automatically:

Calling Int4 IFTT test cases from DevOps Management tools

Many companies already have their integrated test management or DevOps software. In such a case, the Int4 IFTT can be fully integrated with them. Then, the external software will initiate test case execution. Please find more details under:
OpenSAP W3U6: Overview of Int4 IFTT API and Defect Management Integration

Documentation to Int4 IFTT API: .

( The API can be called by RFC or SOAP webservice. )

Here: you will find details on how to call Int4 IFTT from Microfocus UFT, Tricentis Tosca, and other tools.

Testing EDI splitter

The EDI splitter of SAP PO B2B add-on is a subset of other SAP PO use cases. However, the approach is so different that we put it separately. Here you will find details: . In general, this approach can be used when one interface call another (ICO calls ICO).
Please note that in a very similar way you can test the Asynchronous to Synchronous Bridge scenario.

Testing the adapter modules in the sender communication channel

An example:

Testing the adapter modules in the receiver communication channel

An example:

SAP PI to SAP PO migration

Concept

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 )

The idea is to create test cases from the old production environment and execute them from day 1 of the migration project on the new environment.
From an Int4 IFTT standpoint, you will need .
Then it would help if you found a way to create the test cases most efficiently. The most helpful tool could be the Robotic Crawler:r:
E-learning video: https://www.youtube.com/watch?v=aGREgQccLjE&feature=youtu.be&ab_channel=Int4

or using .

After the test cases are created, you will start continuous execution on the new environment. Please make familiar with different test case execution options: .

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.

Change of Interface Names and Namespaces

It may happen that the migration project will also be an opportunity to do some clean-up and, for example, adjust old interfaces to meet the current naming convention. Thus some of the objects may be named differently. It would not be possible to execute directly old test cases in the new environment. Int4 IFFT offers help in such a case.
First review this video: Automated Testing of SAP PO upgrade / migration with Int4 IFTT.
Then please review the description of .

Missing systems

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.

SAP CPI continuous testing

Concept

The CPI continuous testing use case helps you in the BAU activities. The background is discussed here: OpenSAP W2U1: Business as Usual (BAU) SAP PI/PO and SAP CPI Testing. ( it requires a login to an openSAP account to be moved to the proper section )

The technical capabilities are described in another OpenSAP lesson regarding SAP Cloud Platform Integration Testing (W3U4).

Creation of automation object

The concept of creating an automation object for the CPI interface is the same as for the other interface types. It has been presented in the video attached above, the OpenSAP lesson regarding SAP Cloud Platform Integration Testing (W3U4). For more information on this topic, please see the subchapters of the following section: .

Creation of test cases

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 .

SAP PO to SAP CPI migration

Concepts

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 ).

Migration of existing SAP PO test cases

Follow this article to learn how you can convert existing SAP PO test cases into SAP CPI:

External middleware to SAP PO migration

Int4 IFTT provides a functionality thanks to which you can quickly upload test cases into IFTT. A tool called can be used to upload, e.g., payloads extracted from other middleware during migration projects to SAP PO.

SAP S/4HANA continuous testing

Concept

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.

For more information, refer to the” Inbound Interface from 3rd party to SAP environment”: section in the document 

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 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

  • Variables for

    • 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

Please check the overview .
Then review the OpenSAP e-learning video: <add link currently page not working> .
In addition, please check the e-learning videos:

For the creation of the automation object header, you should follow the right subchapter of .

Predefined Automation Objects

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:

Manual test case creation: SAP PO/CPI/IDoc/Proxy

At the moment, Int4 IFTT supports users in either manual or automatic test case creation. This section will cover Manual Test Case creation: and also come back to the description of the Message Selector:

E-learning video: https://www.youtube.com/watch?v=8DlrXeREzDs&feature=youtu.be&ab_channel=Int4

Robotic crawler for SAP PI / PO

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.

E-learning video: https://www.youtube.com/watch?v=aGREgQccLjE&feature=youtu.be&ab_channel=Int4

Testing outbound scenarios

Concept

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.

You can perform this kind of testing in multiple ways, so please refer to the” Outbound Interface from SAP environment to 3rd party” section in the document  as a start.

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: .

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).

This technique allows using an existing output message (NAST printouts/outputs). If this is relevant to you, follow the instructions in: . This article describes both the automation object requirements as well as test case creation.

Using the eCatt recordings

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.

The automation object creation:
The test case creation:

Using the inbound interface to trigger the output message

A third technique is used when an inbound interface triggers an output message. First, you need to create a regular inbound test case: . TThen the inbound test case needs to have a variable with the document number and will be passed to the second test case.

Using API to fetch and validate an interface message by Int4 IFTT

In this scenario, UI recording will trigger the message in external testing software (Tricentis Tosca, Worksoft, etc.). Steps:

  • Record your transaction that triggers message.

  • Call Int4 IFTT API and pass the new document value (the one that will be created during UI script execution) as a container parameter. The API request specification is available here:

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.

To execute this type of testing, you need to define a test case that will trigger the message from SAP Backend. For instruction, follow the documentation:
Automation object:
Test case:

Capturing the final output in SAP CPI

Automation object:
Test case:

Capturing the final output in IDoc layer

Suppose the backend interface is IDoc, and you don’t want to check output in the integration platform. In that case, you can make it directly in the SAP Backend system.

Test case:
Automation object:

SAP S/4HANA conversion testing

Concept

The SAP S/HANA conversion testing use case helps you identify and minimize integration failures during S/HANA conversion projects. The background is discussed here: OpenSAP W2U4: SAP S/4HANA Conversion Testing or . ( it requires a login to an openSAP account to move to the proper section ).
A deeper introduction is available here: SAP Insider Online - Automated testing and Virtualization of SAP Application Interfaces in SAP S/4HANA Conversion Projects

Calling Int4 IFTT test cases by API

Introduction and basic execution

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.

E-learning video: #6 Int4 IFTT: API
OpenSAP W3U6: Overview of Int4 IFTT API and Defect Management Integration
Documentation: . This section contains examples of connecting different applications with Int4 IFTT.

End to end testing of the business processes with external system virtualization

Another compelling feature of Int4 IFTT is the possibility of testing not only one integration scenario but also the whole business process.

E-learning video: #9 Int4 IFTT: Business Process sequences

Documentation:

Rollouts

 

 

© 2017 - 2022 Int4 AG All rights reserved