Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

There are three main pillars to the test execution and virtualization:

  1. Virtualization of external systems
    Int4 APITester can inject messages pretending to be an external system in the integration process. Also, it can capture messages submitted in the direction of external systems and validate them for content and structural correctness.

  2. Middleware platforms' behavior inspection
    Int4 APITester utilizes existing APIs of tested integration platforms to access message history/trace and inject messages into the platform. By capturing historical documents, injecting new messages, and analyzing how they were processed, Int4 APITester can technically and functionally validate the integration platform behavior by comparing current execution to historical data.

  3. Validation of business documents and operation with SAP backend
    Many tests can be done on the integration platform itself. However, validation of business documents requires accessing the backend system involved in the process. The main feature available in Int4 APITester is the ability to validate business documents by comparing values stored in the database. Additionally, Int4 APITester can work with fetching and injecting IDocs, Proxies and re-trigger outputs from SAP documents.

    1. Database validation is enabled by additional function modules that system administrators can install either separately or as part of the Int4 Suite Add-on on the tested systems.

    2. In case the database validation is not an option, API calls specific to the tested system may be used (if available) to validate business document data.

Panel
panelIconIdatlassian-info
panelIcon:info:
bgColor#FFFAE6

Validation of business documents is available in APITester only

Internal organization

Environments and System lines

Int4 APITester needs basic information on the system landscape. This information links the logical structure of the customer landscape with the existing systems under test through configured RFC connections.

  1. System Lines - represent the business system family (e.g., ERP, CAR, CRM, etc.) based on functional distinctions. For example, in a typical small-scale ECC to S/4HANA migration project, the "ECC" and "S/4HANA" would be the two separate System Lines in Int4 configurations. It's worth noting that System Lines do not cover the integration platforms.

  2. Environments - represent the various environments in the system landscape, typically "Development", "Test" and "Production". It's important to note that there could be only one integration platform instance in each technology assigned to an Environment. For example, in case of an upgrade project, e.g. PO 7.4 to PO 7.5, we would need typically twice as much environments: "Development74", "Test74" "Production74", "Development75", "Test75" and "Production75". It will not be the case if the integration platforms are based on different technologies.

...

Automation Objects

Int4 APITester is built around the concept of Automation Objects - entities that contain configuration for each test execution step. Automation Objects define the interface under test, test conditions, and necessary data manipulation employing a Variable concept. Automation Objects can also point to other objects (UI scripts, database validation definitions, and more - as documented).

Test cases

A test case is a basic entry representing data for single test execution. The test case execution happens in the context of the assigned Automation Object in a specific Environment. System Line information is read from the Automation Object and can drive additional validation steps, specifically the Database Validation.

Test creators can link test cases into scenarios. It enables testing of complex, multiple-step flows, for example, the Order-To-Cash process.