Blog > Testing business processes with Int4 IFTT

Testing business processes with Int4 IFTT

Krzysztof Łuka SAP Integration Architect, SAP Press Author
icon__calendar 2020-06-26


Application Interfaces are most usually part of a larger business process. They tend to play a significant role in these scenarios and being able to test them properly is important to ensure the entire process is correct.

As you know, with Int4 IFTT you can test not only the integration platform layer like SAP PO or SAP CPI (transport API testing) but also the backend applications like SAP ECC or S/4HANA (functional API testing). This article is a more detailed version of a Case Study that is also available on our website.

Reading time: 5 minutes

The challenge

In such scenarios, it is sometimes challenging to test an application interface as a standalone solution. For example, to be able to test an inbound interface that creates a purchasing invoice, you need a fresh set of the purchase order and inbound delivery. That means every time you want to re-test the invoice, you also need to create the preceding documents. Whether the preceding documents are created via interfaces, or they are created manually, in both cases you can include those steps as test cases in your Int4 IFTT test scenario.

Alternatively, if you need to test your sales process end-to-end, you need to cover a lot of steps, which might involve manual operations (e.g. picking, goods issue, etc.) or several inbound and outbound interfaces, which are all crucial pieces of the complete scenario. And all of them can also be part of your Int4 IFTT test scenario.

These testing capabilities are ensured by three Int4 IFTT functionalities:

  • The ability to create new instances of messages, by replacing key data (e.g. customer purchase order number) with completely new values every time a test case is a rerun
  • The ability to link test cases together, forming a new business process chain, and passing the key data between the test cases
  • eCATT integration to cover manual operations in the testing scenario

The following example will present these features and explain how this is achieved.

Testing sales process end-to-end

In this example, we will have a look at an end-to-end order-to-cash scenario, configured by our Int4 Labs. This scenario starts with an inbound sales order message arriving from a customer and ends with a sales invoice being sent out to the customer. In between, there are also important steps of delivery creation, goods issue, and invoice posting in the backend system. All steps are executed automatically by Int4 IFTT.

The entire scenario is presented in Figure 1.

End-to-end sales process configured in Int4 IFTT

Figure 1 End-to-end sales process configured in Int4 IFTT

During the execution of this scenario in Int4 IFTT, the following steps are performed.

1. Sales order inbound

An inbound IDoc of type ORDERS.ORDERS05 is sent into the SAP S/4HANA. As a result, a new sales order document is created. The IDoc is created based on live data from the production environment or the SAP ECC that is going to be replaced by SAP S/4HANA.

The newly created document is validated by Int4 IFTT.

The validation is done on the field by field level. Each field of the new document is compared to the reference sales order document, which was originally created by original IDoc, and which is now the basis of our new test case.

Sales order document validation in Int4 IFTT

Figure 2 Sales order document validation in Int4 IFTT

2. Sales Order confirmation

Sales order confirmation IDoc is sent from the newly created sales order. The outbound IDoc of type ORDRSP.ORDERS05 is validated by Int4 IFTT, where each field of the outbound IDoc is compared to the original outbound IDoc (same source as above).

Outbound IDoc validation in Int4 IFTT

Figure 3 Outbound IDoc validation in Int4 IFTT

3. Create delivery

In this manual step, an SAP eCATT script is executed in the backend system that will create an outbound delivery document. To create the new delivery, the number of the newly created sales order in step 1 is used as a reference.

The number of the delivery document is stored by Int4 IFTT for further use.

  • Validate delivery

In this sub-step, the newly created delivery document is validated to confirm if it is correct.

Just to let you know, the recording and playback for testing the manual steps might be also done in other testing tools like Worksoft Certify or Tricentis Tosca and integrated with Int4 IFTT API validation.

4. Send ASN

Outbound IDoc of type DESADV.DELVRY07 is sent back to the customer and the complete message is validated. The delivery IDoc is validated automatically against the original IDoc.

5. PGI

Another eCATT script is executed, where the number of newly created delivery is used to perform pickling and post goods issues.

6. Create invoice

After successful PGI, the newly created delivery can be used to create an invoice document. Thanks to SAP eCATT integration, this is again a step performed automatically by Int4 IFTT.

  • Validate invoice

The new invoice document is validated.

7. Send invoice

Outbound IDoc of type INVOIC.INVOIC02 is sent out to the customer and the entire message is, again, validated by Int4 IFTT.

All the above steps are performed automatically by Int4 IFTT and the test is available directly from the test cockpit. The tester only needs to select the scenario and execute it, and then wait for the results, which will be presented once the steps are finished. In the above example, the testing takes around 20-25 seconds.


Figure 4 Complete scenario results

We used IDocs as interfaces in this example for simplification. It could also be any other message format message, like EDIFACT, Enterprise Service, etc. There can be also many more steps in between, to match the business process in your company.

Key advantages

In this scenario you benefit from the following features:

  • Execution automation – all steps are performed automatically by Int4 IFTT, without the need for manual operations, which, in real life, usually involves different people from different teams,
  • Validation automation – all results are validated automatically by Int4 IFTT, and the validation is always very detailed, on a field level, by comparing fields in the message or fields in the database,
  • Virtualization – no need of involving other systems in the testing process, as they can be virtualized by Int4 IFTT.

All in all, this speeds up the testing process significantly. I have been to projects where manual testing of such scenarios would take days and would involve different teams and systems to execute and validate it. With Int4 IFTT you get it in seconds and at a very comprehensive level!

Krzysztof Łuka SAP Integration Architect, SAP Press Author
SAP integration consultant at Int4. He started his career in 2006 as an SAP Sales and Distribution module consultant and later shifted to the integration area. He gained his experience in several implementation projects as SAP AIF/PI/PO/CPI consultant and ABAP developer, making systems integration topics his specialty. Since 2015 he has worked on several SAP AIF projects and is an expert in that area. He co-authored 3 books on SAP AIF, published by SAP PRESS: Interface monitoring and Error Handling with SAP AIF, Serializing Interfaces in SAP AIF, BRFplus Output Type Management in SAP S/4HANA.

Contact us

If for any reason, the thought of reaching out to us has crossed your mind, then by all means do not hesitate to get in touch with us, as we are more than happy to put to rest all of your concerns.