Testing scenarios and flows

Int4 APITester allows for execution of single test cases and also testing scenarios with varying complexity, consisting of multiple test cases. Test cases to be executed as scenario should be contained in single folder in APITester.

Testing scenarios requires good understanding of the basic concepts, Automation Objects, Variables and various test types. Please familiarize Yourself with the relevant sections of the manual

Simple testing scenario - mass regression execution

In simple scenarios, multiple test cases are executed in series, based on single Automation Object.

API Management testing folder - example of a simple test scenario

In such a scenario, selecting a folder and running all test cases (using Execute All button) will produce a test report with execution details and pass/fail information for each test case. There are no dependencies between the test cases, and each one will be triggered.

To create such a scenario You need to create an Automation Object and create test cases, either using Message Selector or Robotic Crawler.

These simple scenarios are good for mass testing of messages, usually to execute regression testing or to generate data in the test system.

Complex testing scenario - linking test cases to enable business process flow testing

Such complex scenarios, as the one in this example, are only supported in the Int4 APITester

Int4 Suite allows for complex scenarios, with test cases linked, passing data from one test case to another, resulting in ability to test multiple step business processes. Such a test usually requires mixing different testing types (Inbound, Outbound and UI test cases) and requires multiple Automation Objects to run.

Example of a scenario with multiple linked test cases

This scenario contains six test cases representing test for a sales order business flow.

This example is based on a popular Sales Order process, with delivery and invoicing. This is a well recognized process that is easy to relate to. Int4 APITester is data, format and process agnostic and can be configured to support any ECC or S/4HANA integrated scenario.

Scenario example explaination

First test case simulates external EDI customer sending a purchase order. In the Automation Object a variable is defined, using a number range, to ensure that the newly injected EDI message will have a new, unique document number, used to identify the documents in the business transaction.
1. Int4 APITester will send a captured message to the Integration platform (PI/PO in this particular scenario)
2. Integration Platform maps the message to IDOC format and sends to ERP (ECC or S/4HANA)
3. Int4 APITester validates the IDOC message
4. Int4 APITester uses database comparison for validating the generated document in the backend ERP
Second test case is an Outbound test, that is expecting for a message to appear on the integration platform. Please note that this test points to the previous on, as a parent. This is needed, so that Variable containing the document number, configured in the First test case, can be passed forward to be read by the second test case.
1. ERP is configured to send a IDOC response, confirming the sales order creation
2. PI/PO receives the IDOC and maps it to customer EDI format
3. Int4 monitors PI/PO for messages to appear on specific interface, using the Variables configured in Automation Object to identify the specific message, based on it’s content (e.g. Purchase Order number)
4. Int4 captures the relevant message and compares it to captured reference, to validate the message
Third test case is of the eCATT type. Once the sales order is created, next step in the process is to ship the goods and invoice. For that, Delivery document has to be created in SAP, picked and goods issue must follow. Such step could be driven in automated ways. In our demo process this step is manual. To enable automated testing, eCATT script was recorded, that executes the necessary transaction and completes it with data. Again, test case is linked so that the document number can be passed down to the eCATT script using Variables. Also, database validation could be enabled at this stage to check the delivery document in the backend for consistency with reference.
Fourth test case works similarly to the second one, validating the dispatch advice sent to the customer.
1. ERP is configured to send a IDOC message with Dispatch Advice, confirming the picking and goods issue to the customer
2. PI/PO receives the IDOC and maps it to customer EDI format
3. Int4 monitors PI/PO for messages to appear on specific interface, using the Variables configured in Automation Object to identify the specific message, based on it’s content (e.g. Purchase Order number)
4. Int4 captures the relevant message and compares it to captured reference, to validate the message
Fifth test case is analogous to the third one. This time UI script is needed to process the Invoice. Again, test case is linked so that the delivery number captured in step three can be used to invoice the actual documents in the specific process execution
Sixth test case is again similar to second and fourth, this time validating the EDI Invoice
1. ERP is configured to send a IDOC message with EDI Invoice, confirming the picking and goods issue to the customer
2. PI/PO receives the IDOC and maps it to customer EDI format
3. Int4 monitors PI/PO for messages to appear on specific interface, using the Variables configured in Automation Object to identify the specific message, based on it’s content (e.g. Purchase Order number)
4. Int4 captures the relevant message and compares it to captured reference, to validate the message