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.<\/p>\n
As you know, with Int4 IFTT<\/strong> 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\u00a0Case Study<\/strong><\/a>\u00a0that is also available on our website.<\/p>\n Reading time: 5 minutes<\/em><\/span><\/p>\n \n<\/div>\n 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.<\/p>\n 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<\/a><\/strong><\/span> test scenario.<\/p>\n These testing capabilities are ensured by three Int4 IFTT functionalities:<\/p>\n The following example will present these features and explain how this is achieved.<\/p>\n 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.<\/p>\n The entire scenario is presented in Figure 1.<\/p>\n <\/a><\/p>\n Figure 1 End-to-end sales process configured in Int4 IFTT<\/em><\/p>\n During the execution of this scenario in Int4 IFTT, the following steps are performed.<\/p>\n 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.<\/p>\n The newly created document is validated by Int4 IFTT.<\/p>\n 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.<\/p>\n <\/a><\/p>\n Figure 2 Sales order document validation in Int4 IFTT<\/em><\/p>\n 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).<\/p>\nThe challenge<\/h3>\n
\n
\n<\/div><\/li>\n<\/ul>\nTesting sales process end-to-end<\/h3>\n
\n1. Sales order inbound<\/strong><\/span><\/h5>\n
\n2.<\/strong> Sales Order confirmation<\/strong><\/span><\/h5>\n