PI Unit Test
PI Unit Test is a test that will inject the message to the SAP PI or SAP PO middleware platform and it will perform validation of the middleware platform outbound message.
Top of the screen with Automation Object (AO) ID, description and test type.
Basic Information
Read more about Import Basic Information from SAP PI/PO Directory
Parameter name | Description | Example |
Interface | SAP PI/PO interface name. In SAP PO, the best information to see interface service name is an ICO definition. | SI_O_PurchaseOrder - SAP PO interface name |
|---|---|---|
Namespace | Namespace from ICO. The name and namespace will allow to automatically build test cases just based on providing message GUID/number from middleware. Based on content, the interface name/namespace will be checked, and automatically configuration object proposed. | http://webshop.com |
Test Case Creation
Parameter name | Description | Example |
PI: Ignore parent message during TC creation | This flag is used for scenarios with multiple receivers. If you create a test case based on the message that is part of the bigger scenario, then engine will search for the initial message that SAP PI/PO received. | |
|---|---|---|
Message version before processing | A version of the message to be fetched from the SAP PI/PO persistence. Here we specify the version which contains the original message - before being processed by SAP PI/PO. If empty, Global Parameter is used. | Depending on the SAP PI version can be either: numeric: 0 |
Message version after processing | A version of the message to be fetched from the SAP PI/PO persistence. Here we specify the version which contains after mapping version of the message - already processed by SAP PI/PO. If empty, Global Parameter is used. | Depending on the SAP PI version can be either: numeric: -1 |
Read Successor Message(s) based on Reference ID | Collect output messages from subsequent ICOs based on Reference ID instead of parent relation | |
PI: Allows Receiver interface be same as Sender interface | For pass-through interfaces In particular scenarios, sender and receiver interfaces may be the same, for instance, in the EDIFACT scenario. If this parameter is not provided and the sender is the same as the receiver interface, no test case would be created for such messages, or during execution, an error may occur. | X |
Ignore messages from interfaces | Used when ‘Read Successor Message(s) based on Reference ID’ parameter is set to exclude messages from specified interfaces from saving | |
Output Automation Object | Automation Object(s) used to read the output payloads. This parameter allows for testing scenarios where message is injected into one ICO and results are compared on a different one. | |
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 |
ABAP Stack SAP PI Integration
Parameter name | Description | Example |
PI: Landscape where interface exists on the ABAP stack | Name of the PI ABAP Landscape. It is required to access the ABAP stack PI messages. | |
|---|---|---|
PI: ABAP stack: Read input message from Java persistence | This flag needs to be checked in the case when the ABAP stack PI read a message from the JAVA adapter | |
PI: ABAP stack: Read output message from Java persistence | This flag needs to be checked in the case when the ABAP stack PI sends a message to the JAVA adapter |
Test Case Execution
Parameter name | Description | Example |
Inject using PIT | This flag will use SAP PIT WS as a message injector (SAP PO > 7.5 SP14) for this automation object. This flag can be set up also globally for whole environment. | |
|---|---|---|
HTTP RFC Destination | Alternative RFC Connection where the REST message should be sent. If this parameter is populated, then the message will be sent there alternative RFC. | SAPSYS1_RFC |
PI: Asynchronous: Direct HTTP operation | If the Direct HTTP URL is provided, here you can specify the HTTP operation (for asynchronous REST testing). | POST |
PI: Asynchronous: Direct HTTP URL | Direct endpoint to tested interface (asynchronous). Fulfillment of this parameter is a mandatory condition for testing asynchronous REST/JSON interfaces. | /RESTAdapter/webshop/material_async |
PI: Reference Sender Channel Name | Name of the sender channel to be used as a reference. | CC_SOAP_SENDER |
PI: Reference Sender Channel BC | Business Component of the sender channel to be used as a reference. | BC_SENDER |
PI: Reference Sender Channel Party | Party of the sender channel to be used as a reference. | SENDER_PARTY |
Flag for Flat File interfaces | Used to mark interface input as Flat File | |
Flat File Line Separator | The character used for end-of-line determination in Flat File messages: for example, CLRF - Unix. The parameter is used to display the comparison report better and display the reference and new message line by line. "Carriage Return and New line" character should be stored as CRLF "Line Feed" should be stored as LF (Unix based files) Separator can be also specified using hexadecimal representation of Numeric Character Reference (NCR). There is no default value, so the parameter is obligatory for CSV files Use || to enter multiple alternative separators e.g. CLRF||' | CLRF NCR Example: |
Line Separator Escape Character | Escape character for line separator. Used to avoid line breaks in case separator is used in the file content. Source: Split: | |
Flat Files Compare with payload validations applied | If this checkbox is checked, Payload Validation rules are applied before files comparison and the match content is replaced by the placeholders. This can in some cases result in better flat file comparison results, especially in case of many missing lines. | |
Stop Receiver Processing | Stops Receiver Processing when using PIT as a message injector. | |
Stop channels | Used to stop specific channels before test case execution. This parameter should be used only in case when messages are not injected using PIT and still have to be stopped from being sent to receivers. Configuration of channels is Environment specific. |
Test Case Validation
Parameter name | Description | Example |
Validate message output | This flag allows activating output payload validation for SAP PI/PO The validation is performed before the final backend validation, and the results are combined. | |
|---|---|---|
Ignore Receiver Validation | By default receiver name and party are compared with reference message as part of the test. This flag disables receiver validation. | |
PI: Validate message status | SAP PI/PO message processing status will be taken as a part of the test case result. By default, the processing status is not part of the test as such, for example, the communication channel may be deactivated not to send test messages. This option is helpful when performing validation of receiver communication channels. It would not validate the results of processing in the channel but at least collect SAP PO status. | |
PI: Validate message attachments | This flag allow to check SAP PI/PO message attachments as a part of the test. | |
Show XML in the original order (unsorted) | This flag determines if the lines of the file in the XML Comparison Report should be displayed in the original order or should be sorted alphabetically for a specific nodes. | Checked or 'X' - payload will not be sorted on the report Unchecked or '' - payload will be sorted alphabetically (default value) |
Message Selector
Parameter name | Description | Example |
PI: Message Search - Interface Name | Used to specify the Interface Name within which the Message Selector should search for the version of the message. This parameter is only to be entered if Interface Name visible in the Message Monitor main screen differs from the Interface Name used to create the object definition. | If we only have receiver interfaces visible in the message monitor, then use the receiver name specified in the ICO of the sender interface specified in the automation object used. |
|---|---|---|
PI: Message Search - Namespace | Used to specify the Interface Namespace within which the Message Selector should search for the version of the message. This parameter is only to be entered if Interface Namespace visible in the Message Monitor main screen differs from the Interface Namespace we have used to create the object definition. | The same condition as the previous parameter but then for the namespace of the receiver interface |
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.
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
Matching documents based on variable content
Passing data between test cases
For more details on Variables and their processing, read here: Variables & Variable processing
Create button allows variable creation.
Parameter name | Description | Example |
Name | Variable technical name | VARIABLE_1 |
|---|---|---|
Description | Free text for variable description | Variable One |
Type | Type of variable processing | Read & Replace Find message Custom |
Scope | Variable scope
| Test Case |
Private | Specifies that the variable is not accessible to child test cases |
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.
Number Ranges
Int4 Suite uses own number ranges for data processing needs. Quite often, when sending test data to test systems again and again, the message can’t be exactly the same. For example, sending the same purchase order to generate sales order in S/4 could result in an error, if the system is configured to treat such situations as duplicates. Also, having a specific data field in the document might be mandatory to find another document - e.g. by generating an unique PO number for the Sales Order, we can find the newly created Sales Order in the database. The actual mechanics for such replacements of original document numbers or other values is described in the section Variables & Variable processing.
Below you will find information how to create a new number range.
The number range used to replace the source system document number should always be configured to not overwrite the original numbers. It means that documents generated by Int4 Suite should have their own subset of the original document number. Usually, it might be a subset of the upper limit of the original number range.
It is essential that automated testing with Int4 Suite doesn’t consume numbers that the source system will generate during manual testing. Additionally, if testing environment data is refreshed from the production system, more documents would be created in the testing environment. If the Int4 Suite number were configured in the same range, it would start creating duplicates.
For example, the original number range for document numbers from the source system is 560000 - 590000. It would be wise to set the Int4 Suite number range from 590000 to 600000. However, suppose the SAP backend system uses an external number range. It is essential to stay in the original range. In that case, the Int4 Suite number range may be set as 585000-590000, which gives space for 5000 testing documents. Using range from upper interval reduces the risk that the number will be overwritten.
Additionally, the good practice is to use prefixes or suffixes that will quickly separate source system documents and the ones created by Int4 Suite. It should always be used when there is no document number validation by the SAP backend.
Each Object Definition can contain an unlimited number of number ranges. This way, each variable declared in an object can use its specific number range.
Parameter name | Description | Example |
Number range | Provide a name for the number range. This name would be passed as a parameter in variable processing for actions that will generate values from it. | NUM_RAN |
|---|---|---|
Prefix | The alphanumeric characters to be appended at the beginning of the document number to separate original documents from source systems and the one created during Int4 Suite testing (optional). | INT4_ |
Low value | The first number of our range. | 1 |
High value | The last number of our range. | 999999 |
Current value | When the number range is used during testing, it would increment per each use. | 23 |
Suffix | The alphanumeric characters to be appended at the end of the document number to separate original documents from source systems and the one created during Int4 Suite testing (optional). | _TEST |
Add zeros | If this box is checked, zeros will be automatically appended to the beginning of the document number, such as 000500. |
|
Incr. per Test Run | If this indicator is selected, the number range is incrementing once per test run. If multiple test cases with the same Automation Object exist in the test run, they will receive the same value. |
|
Payload Matching
Some integration scenarios permit one-to-many mappings. In such cases, there might be no guarantee that the integration platform will prepare messages in the same order as the historical flow. Payload matching allows for comparing the payloads in the same order. The solution is to sort the messages before comparison.
Parameter name | Description | Example |
Rule | Free text for rule name | Rule1 |
|---|---|---|
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) REGEX(BGM\+220\+(.*)\+) (REGEX expression) |
Rule Type | Rule type. Available options:
|
|
Parameter | Additional parameter for Rule Type like Variable or Mapping Object name |
|
Group | Free text grouping field. |
|
Payload Processing
This capability is particularly useful in migration projects and the Test Driven Development approach, where the payload structures of new solution interfaces may differ but contain similar content.
Following processing methods are available:
XSLT Transformation
ASTER Script
Payload processing can be applied on both Input and Output payloads.
XSLT Transformation is stored in a reference test case of type XSLT Transformation. To call XSLT Transformation during Test Case execution, Test Case number that is of type XSLT Transformation needs to be provided as an input to one of the below parameters.
Example usage of XSLT transformations can be found here XSLT transformation examples | Different-order-of-XML-nodes-in-a-new-solution.
ASTER Script for Payload Processing can read current payload using GET_CONTEXT_PAYLOAD function and should return updated payload as a result of evaluation
Parameter name | Description |
Processing Type |
|
|---|---|
Method |
|
Parameter |
|
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) |