IDoc Outbound
IDoc Outbound is a test that will search for the Outbound IDoc message in SAP backend based on conditions specified in the Variables of Automation Object.
It can trigger message by itself by injecting outbound IDoc or via output control or check the outbound IDoc message triggered by other test case or manual action.
Top of the screen with Automation Object (AO) ID, description and test type.

Basic Information

Parameter name | Description | Example |
IDoc Type | SAP Outbound IDoc Type Details IDoc Message Type, Basic Type and Extension. All Separated by a “.”. | INVOIC.INVOIC02 |
---|
Parameters
Other
Parameter name | Description |
Inject the IDoc & start outbound processing | When it’s enabled, IDoc will be injected automatically during test case execution. |
Trigger the output from message control (NAST) | |
IDoc Validate status | With this option ticked, IDoc status will be validated and displayed in the Test Case Details report after test case execution |
Find IDoc with direction | By default outbound IDoc are searched by this test type (EDIDC-DIRECT = '2’) This parameter can be used to override this setting and search also for Inbound IDocs. |
Threshold for searching outbound messages (sec) | If the parameter is not filled, Int4 Suite searches for outbound messages starting from time equal to the beginning of the test run. This parameter extends the range by the values provided in seconds and separated with “,”. E.g., if the test run was started at 07:34:00 and the parameter value is set to “10,15”, it will search for messages from 07:33:50 to 07:34:15. |
Test Case Creation
Parameter name | Description | Example |
Child Test Case Automation Object | Automation Object(s) used to link and create child test cases. This parameter allows for automatic creation of linked outbound test cases during save. Following Automation Object types can be used as child: 5 PI E2E Outbound |
|
Execution Settings
In this section there are common execution settings for all test cases.

Debug Log
This feature enables additional debugging messages to be included in the test execution log. Typically, this option is disabled, as a log with debugging information can become cluttered with details unnecessary for standard test execution. However, it proves invaluable during the initial phases of working with Int4 Suite, as it provides insights into each unsuccessful run and aids in identifying and resolving connectivity and security issues.
Display Wait Popup Before Validation
In specific scenarios, there may be a need for manual intervention between the message injection by Int4 Suite and the readiness for test validation. For instance, when an XML message is injected into SAP CPI, mapped to an IDoc, and subsequently transferred to SAP S/4, the IDoc may be processed automatically by the backend. However, certain configurations could hinder this automatic processing. In such cases, the tester must log into S/4 to manually request IDoc processing. The wait popup feature facilitates this by allowing Int4 Suite to send the message and display a popup before commencing backend data validation. This gives the tester time to complete the IDoc processing, return to Int4 Suite, and confirm the popup. Only after this confirmation will Int4 Suite proceed with data validations.
Delay Between Execution and Validation
Similar to the wait popup feature, these options allow for a delay to be configured between the initiation of the test run and/or between the injection of test case data and the validation of results. If it is anticipated that backend processing or integration platform mapping may require a considerable amount of time, this section allows for the configuration of such delays. As a result, Int4 Suite will pause before attempting to validate the integration platform and/or the backend, depending on the type of test being executed.
Variables
Variables are the container for values that can be used during testing. Each variable contains two values, the one that is calculated based on the reference message/document and the one that is calculated ad-hoc during test case execution.
In outbound test types, variables play a crucial role in identifying the correct message leaving the system under test. The Find message type facilitates this process and consists of two steps:
Read: Specifies the value we are searching for.
Find: Indicates where the value should appear in the payload.
Apart from that there are various scenarios where variable processing can be beneficial:
Updating document/message content before test execution
Capturing data from document/message content after execution
Passing data between test cases
For more details on Variables and their processing, read here: Variables & Variable processing
Example variable definition:

Variable details:

Local Scripts
Local Scripts enable you to define custom scripts that are available within the context of the current Automation Object.
These scripts can be utilized in the following areas:
Variable Processing
Payload Processing
Custom Validations
Please consult the Int4 Aster Documentation for details on the scripting language.

Payload Validations
Output payloads after processing by integration platform are validated against previously stored references.
The basic test execution in Int4 Suite will compare the messages (reference and current execution) and report any differences as errors, causing the test to fail. While this may be acceptable for some migration scenarios, not all message differences are errors; some discrepancies are even expected.
This configuration enables adding rules with exceptions that will allow for differences like document numbers, current time and date and others.

Parameter name | Description | Example |
Description | Free text for the exception rule | Field1 |
---|---|---|
Expression Type | Expression type. Available options:
This field is optional for all interfaces where there is a single type of output. However, for interfaces that output might be both XML and flat file, it is mandatory to specify the expression type, then it would be only apply to specific file format (XML/JSON or flat file) | XPath |
Expression | Path pointing to the field/node where the exception should be applied. Available syntaxes: XPath, JSONPath, Int4 Flat File Syntax or REGEX JSONPath and XPath are well-known and popular standards for structured data manipulation. You can find a lot of references and educational material on-line. Worth noting are the testing tools that allow You to experiment with XPath or JSONPath definitions. See here: Please note that Int4 does not maintain these tools and can’t guarantee for their accuracy. | //ORDER/DATE/text() (XPATH expression) or START_TAG(BGM+220+)&&END_TAG(+)&& (Flat file expression) or |
Rule | Says how the difference should be marked
Change Request rule are active only when Test Case is run within Test Run type: Change Request Test |
|
Parameter | Additional parameter for rules |
|
Custom Validations
Custom Validations offer enhanced flexibility for evaluating test case results by allowing the implementation of custom logic using ASTER Scripts.

Within the script, you can access test execution data using built-in Int4 Suite functions such as:
GET_TC_VAR
– to retrieve test case variablesGET_VALIDATION_PAYLOADS
– to access payloads used during validation
For the test case to be marked as successful, the script must return a _TRUE_ value.
Backend Systems
Backend systems in an Automation Object specify the SAP backend system (S/4HANA, ECC, or other ABAP-based systems) where to read a new document created by interface processing during test case execution. It also defines where the reference document was posted, serving as the source. The two documents will be compared in the test case results.
The given system line and source and target environment will be translated to the RFC destination in the runtime. Int4 Suite uses this RFC connection to execute dedicated function modules and retrieve data from the system’s database for comparison.
Find out more at Int4 Suite Internal Organization | Environments-and-System-Lines.
Depending on your testing scenario, both the current and reference system lines can be the same or different. For regression testing, they are typically the same, such as S/4HANA. The testing landscapes, however, may differ, e.g. Test and Production, where the system reads the reference from Production and the current document from Test. For migration scenarios, such as ECC to S/4HANA, the reference would usually be ECC, and the current would be S/4HANA.

Parameter name | Description | Example |
Backend system line for current doc. | This parameter points out the system line where the test interface processing triggered by Int4 Suite will create test document during test case execution. | S/4HANA |
Backend system line for reference doc. | This parameter points out the system where the reference backend document is stored. The value should be a system line described in the landscape configuration. | ECC |
External Links
External Links enable linking from Test Results and from Process Flow chart to business and system objects in external systems.

To link to external documents, the document reference (e.g. a number) must be captured by a Variable. The Variable number may be then used in link title and URL Template to construct a link to the document view. Based on Your Configuration , System Line might be specified, to create a link in the context of a specific business system.
Possible document links:
Regular URL definition
SAP Web GUI - following the template:
/sap/bc/gui/sap/its/webgui?~transaction=*VA03 VBAK-VBELN={SO};DYNP_OKCODE=ENT2
SAP GUI link - generated by Int4 Suite service:
/sap/bc/int4/iftt/launcher/gui?~transaction=*VA03 VBAK-VBELN={SO};DYNP_OKCODE=ENT2
To generate SAP GUI/WebGUI links, the transaction code (e.g. VA03
), selection screen parameters (e.g. VBAK-VBELN
) and DynPro OK Code (e.g. ENT2
) must be know. They are dependent on the specific SAP transaction. This information can be obtained from a functional expert or directly from SAP GUI by analyzing the fields on transaction screen.
IDoc Status Validations

IDOC Status Validation parameters are used to override default status handling rules for Inbound and Outbound IDOC test types.
Default status handling is based on system settings configured in tables STACUST & STALIGHT:
Read Status Group (STATVA) from STACUST
Read Status traffic light (STALIGHT) from STALIGHT
STALIGHT | Int4 Suite Test Result |
---|---|
1 - Yellow | Waiting for IDOC to be processed. If maximum number of attempts exceeded Test is marked as Failed |
2 - Green | Test marked as Failed |
3 - Red | Test marked as Passed |
Individual statuses can be specified in Automation Object rules to override the above logic.
Parameter name | Description | Example |
IDoc Status | IDoc Status | 53 |
---|---|---|
Rule | Describes behavior of Int4 Suite for IDoc status | Success - Mark as Passed |
Data Scrambling
Data scrambling enables to reduce or remove GDPR, privacy and security concerns when it comes to testing. When Int4 Suite is extracting the test data from existing messages or reports testing results, the visibility and availability of sensitive data could be an issue. To avoid this issue, sensitive data can be scrambled. Scrambling can occur at test case creation time and during the test execution. Actual behaviour of the scrambling engine is configured by a set of rules.

Parameter name | Description | Example |
Rule Type | Rule type. Available options:
| Test Case Creation |
---|---|---|
Rule | Free text to specify scrambling rule name for identification. | NAME |
Method | Choose a scrambling method from a list. Available methods:
| HASH |
Expression Type | Expression type. Available options:
This field is optional for all interfaces where there is a single type of output. However, for interfaces that output might be both XML and flat file, it is mandatory to specify the expression type. | XPath |
Expression | Path pointing to the field/node where the exception should be applied. | //ORDER/DATE/text() (XPATH expression) or START_TAG(BGM+220+)&&END_TAG(+)&& (Flat file expression) or $.order.date (JSONPath expression) or REGEX(BGM\+220\+(.*)\+) (REGEX expression) |
Parameter | Specify Additional Parameter suitable for a chosen scrambling method like X (for Mask method), SHA1 (for HASH Method) |