PI GUID E2E Inbound

PI GUID E2E Inbound is a test that will inject the message to the SAP PI or SAP PO middleware platform. It can also perform validation of the middleware platform outbound message as well as validate database entries created by the message processing in the backend ABAP based system.

Top of the screen with Automation Object (AO) ID, description and test type.

Basic Information

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. This requires at least logging the BI processing step (as SAP does not recommend staging). If you would like to create the test case for a single receiver or the BI logging is not available, then you need to check this checkbox
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 caption: EDI
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 caption: AM
Read Successor Message(s) based on Reference ID	Collect output messages from subsequent ICOs based on Reference ID instead of parent relation
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. Automation Objects(s) of type 5 ( PI Outbound) and 20 (PI Unit Test) are allowed to be used.
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 7 IDoc Outbound 13 SAP CPI E2E Outbound
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

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. Value of this parameter should be aligned with specific format used by tested interface. Example: If line separator is set to ' and escape character is ? following split is applied: Source: NAD+SU+8720121000874::3++Test?'file'NAD+SU+8236459000874 Split: NAD+SU+8720121000874::3++Test?'file' NAD+SU+8236459000874
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.
Do not fail TC if DB reference not found	This flag determines if in the situation when DB validation for reference messages have not been found whether it should be treated as Error or Successful message.	Checked or 'X' - if reference document is not found test case will not be failed Unchecked or '' - if reference document is not found test case will be failed (default setting)

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. It is the same validation as used by default by PI Unit Test type.
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.

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

Backend Systems

Parameter name

Description

Example

Backend system line for current 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.

Note:

If Backend system line for the current doc. has the same value as the Backend system line for the reference doc. (for instance, both are S4/HANA) then the RFC connection between the systems will be maintained both in:

a) the original environment of the reference document (for instance, production system)

b) the environment where the current test case execution takes place (for instance, development system)

If Backend system line for the current doc. is different than the Backend system line for the reference doc. then, the RFC connection will be maintained only in the environment of the current execution (for instance, development system), but for both system lines (like ECC and S4HANA)

ECC

SAP_ERP

Backend system line for reference doc.

This parameter points out the system line where Int4 Suite should create test documents during test case execution. In most cases, reference documents and documents created during current test execution are stored in the same system line. However, suppose Int4 Suite is used in a migration scenario (for example, migration from ECC to S4/HANA). In that case, the documents might be created in the new system and then compared with the references from the old system.

The value should be a system line described in the landscape configuration.

Note:

If Backend system line for the current doc. has the same value as the Backend system line for the reference doc. (for instance, both are S4/HANA) then the RFC connection between the systems will be maintained both in:

a) the original environment of the reference document (for instance, production system)

b) the environment where the current test case execution takes place (for instance, development system)

If Backend system line for the current doc. is different than the Backend system line for the reference doc. then, the RFC connection will be maintained only in the environment of the current execution (for instance, development system), but for both system lines (like ECC and S4HANA)

S4HANA

Database Validations

Parameter name

Description

Example

Database validation ruleset

Reference database validation ruleset object name.

Database validation ruleset specify how related backend validation should be performed. Specify tables, fields and join conditions for the backend validation.

Buttons allow navigation to the chosen database validation ruleset and creation of a new database validation ruleset
DB Validation Rulesets

GENERIC_SO

Persist reference DB Data

When switched on, DB reference data will be fetched from backend system during test case creation. Otherwise, it will be fetched during test case execution.

Automation Objects | Database Validations

Dynamic Columns

Dynamic Column Set field allows to assign previously defined set to an Automation Object. A dynamic column set defines additional, custom columns in the result list of message selector.

Payload Validations

Output payloads after processing by SAP PI/PO are validated against previously stored references. This configuration enables adding rules with exceptions that will allow for differences.

File Type	Processing
XML	XPath
JSON	JSONPath
Flat Files, X12, EDIFACT	Int4 Flat File Syntax or REGEX

Parameter name	Description	Example
Description	Free text for the exception rule	Field1
Expression Type	Expression type. Available options: unspecified XPath Flat expression 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	Rule to be applied to the field.
Warning	Marks the compared fields with yellow color as a "warning".
Warning when different based on variable replacement	In case compared values are different Int4 Suite compares them with specified variable. If reference/current value pair from comparison matches variable values result is marked as "warning". Variable name used for checking the values has to be specified in the Processing Parameter column.
Warning when different based on value mapping object	In case compared values are different Int4 Suite compares them with specified values in the Mapping Object. If reference/current value pair from comparison matches mapping values result is marked as "warning". Mapping Object name used for checking the values has to be specified in the Processing Parameter column.
Ignore	Even if it is different in the content, it is not highlighted.
Parameter	Used in correlation with Warning Rules.

Payload Matching

In scenarios with multiple outputs for the same receiver, there is a need to compare them based on the same order as reference documents used for test case creation.
Integration Platforms don’t guarantee that outputs will always be sent in the same order control; therefore, 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: unspecified XPath Flat expression 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: Exact match - value from reference and current payload has to be the same Variable - value from reference and current payload is compared based on variable values and variable replacement Mapping object - value from reference and current payload is compared based on mapping object value replacement
Parameter	Depending on Rule type: variable name or mapping object name
Group	Free text grouping field. All rules with from the same group have to be fulfilled to match payloads. At least one group has to be fulfilled to match payloads. Rules within group are linked with AND operator. Groups are linked with OR operator.

Execution Settings

Parameter name

Description

Example

Debug Log

Int4 Suite will provide additional, more technical information in Test Execution Report during the running of the test cases if this parameter is set. Therefore, it is recommended to set this option initially and deactivate it when object definition is confirmed after executing the first test cases

Display wait popup before validation

Wait Flag indicating if Int4 Suite should stop test case execution after sending test case message to middleware. Int4 Suite will show the confirmation box, and the user will decide to continue. This setting can execute manual follow-up actions before running the next test case or checking the validations.

This setup works only with Execute via SAP GUI option of execution

Delay between execution and validation

Parameter name	Description	Example
For each test case	Delay (in seconds) between test case execution ( sending message) and checking the results.	10
Once per test run	Delay (in seconds) between test run execution ( sending messages) and checking the results.	60

Number Ranges

The number ranges allow generating new values for variables. Those values are used to substitute original document numbers or other values in reference messages.

The number range used to replace the source system document number should always be configured to not overwrite the original number. 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 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.

Data Scrambling

A scramble list is a part of an automation object. For compliance purposes, for example, GDPR purposes, it's required to hide some of the test case fields. Thanks to the anonymizer feature, it's possible to select fields that hold sensitive values and decide what action should be taken to prevent them from being compromised.

Parameter name	Description	Example
Rule Type	Rule type. Available options: Test Case Creation - in case you want to scramble data during the creation of a test case Runtime - in case you want to scramble data during runtime - when the interface is executed, and additional data is loaded to test case data.	Test Case Creation
Rule	Specify scrambling rule name for identification.	NAME
Method	Choose a scrambling method from a list. Available methods: CONSTANT Replace value with constant The current value will contain the constant passed in the parameter. The constant should be provided as is without any brackets. GUID Generate GUID Generate random value in a GUID format. RANDOM Generate a random value Generates a random value. The value of the parameter defines the upper limit of the range. It is also possible to generate negative numbers. For example, passing -100 in parameter will generate random numbers from -1 to -100 HASH create a hash based on value Calculates a hash based on the given value using algorithm passed in parameter (default 'SHA1'). MASK - replace each character with constant Replace each character with a constant passed in parameter. For example, passing X in the parameter will replace scrambled data with X signs. CUSTOM - create custom method create a CUSTOM method (implementing an interface /INT4/IFTT_IF_DATA_SCRMBL_METH).	HASH
Expression Type	Expression type. Available options: unspecified XPath Flat expression 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)*
Parameter	Specify Processing Parameter suitable for a chosen scrambling method.	X (for Mask method), SHA1 (for HASH Method)

XSLT Transformations

XSLT Transformation can be applied on both Input and Output payloads and it 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.

Parameter name	Description
Execute XSLT on input payload	Run XSLT Transformation on input payload before any other execution steps
Execute XSLT on input payload after variable replacement	Run XSLT Transformation on input payload after variables are replaced with new values
Execute XSLT on ref. output payload	Run XSLT Transformation on output reference message (output stored in Test Case as reference)
Execute XSLT on cur. output payload	Run XSLT Transformation on current output message (output generated during Test Case execution)

Example usage of XSLT transformations can be found here XSLT transformation examples | Different order of XML nodes in a new solution.