Additional Parameters

USE:

Additional Parameters are additional settings options available in particular interface test types or required by specific Int4 IFTT usage. Here you will find the list and meaning of all parameters. The detailed appliance is also explained in the guides for particular test types like synchronous, AIF, CPI, and FLAT FILE interface configuration.

General

Flat File (Flat message) interfaces

If the tested interface exchange flat file or text messages instead of XML, then the below parameters need to be set:

Parameter

Technical name

Description

Example:

Flag for Flat File interfaces

FLAT_FILE

Used to mark interface input as Flat File
This is a required parameter for all interfaces, in which the input message is a flat-file.

X

Flat File Line Separator

FLAT_LS

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)

There is no default value, so the parameter is obligatory for CSV files

To split file on fixed length specify the parameter as LEN(n) e.g. LEN(128)

CRLF

File Encoding

FILE_ENC

Code page of the file.

The parameter is used to provide code page information to expression handlers and parses in case code page cannot be determined e.g. from metadata or file header.

SAP Code page number is expected as a value. Possible values can are available in the table TCP00.

1100

(1100 corresponds to ISO 8859-1)

Suppose the tested flat file interface is inbound and implemented in SAP PO, and adapter modules perform the conversion between flat file and XML. In that case, the reference communication channel has to be also defined.

Test case attempts

Parameter

Technical name

Description

Example

Number of attempts to wait for TC results

TCRETRYNUM

Int4 IFTT continuously checks for results a given number of attempts (global parameter), delayed by the number of seconds (global parameter). The total waiting time is a multiplication of the number of attempts and the delay.

For the test cases that require more time, we can overwrite the global setting and increase the number of attempts.

For example, outbound IDOCs are sent our from an SAP backend not immediately but by the batch job executed every 5 minutes.

15

HTTP Processing

Parameter

Technical name

Description

Example

HTTP Header

HTTPHEADER

Add custom HTTP header sending to CPI/PI.

There are two methods to use this parameter:

Directly filling the header name and header value in format "HeaderName=HeaderValue".
Indirectly by filling the header value using a value from Variable d
1. defined for this purpose (e.g., named Variable1) in the format
"HeaderName={Variable1}":
1. please remember to use curly braces ( {} ) while using this method
2. we recommend using this method for header values containing such characters as: {, =, }.

To use multiple HTTP headers, a unique identifier in the Group column should be defined for each of them.

Header1=123 (Method 1)

or

Header2={Variable2} (Method 2)

Multiple HTTP headers usage:

CSRF Token handling

Parameter	Technical name	Description	Example
CSRF Token Fetch	CSRF_FETCH	Enables CSRF token handling for tested endpoint. Before actual call there is a separate request sent with HTTP header x-csrf-token = 'fetch'. Obtained CSRF token is added to subsequent requests.	'X'
CSRF Token Endpoint	CSRF_URL	Optional parameter used to specify url to the token endpoint. Used for servers where CSRF tokens are fetched from different url than the actual tested endpoint.	/api/v1/root

SAP Process Orchestration

It may be necessary to specify individually, for a particular interface, which version of the message stored in PI persistence should be used in the test case.

Parameter	Technical name	Description	Example:
Message version before processing	PIMSGVERBI	A version of the message to be fetched from the PI persistence. Here we specify the version which contains the original message - before being processed by PI. If empty, Global Parameter is used.	Depending on the SAP PI version can be either: numeric: 0 caption: EDI
Message Version after processing	PIMSGVERSN	A version of the message to be fetched from the PI persistence. Here we specify the version which contains after mapping version of the message - already processed by PI. If empty, Global Parameter is used.	Depending on the SAP PI version can be either: numeric: -1 caption: AM
Additional Message Version(s) after processing	PIMSGVERAD	Optional parameter used to specify additional versions to be checked. IFTT will store these versions in the test case definition and compare all of them during execution.	edi
Validate message output	PIOUTPUT	This flag allows activating output payload validation for SAP PO inbound end-to-end test type (PI GUID Inbound & PI IDOC inbound) and Boomi end-to-end test type (Boomi Inbound). The PO validation and Boomi 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.	X
Validate message status	PIVALSTAT	For all test cases where the validation is based on the SAP PO message, the middleware 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.	X
Keep transited messages in the result	PINONPHYS	In 1 to many mappings, SAP PO makes splitting before mapping execution. The message that was split receives status 'delivered' and remains in monitoring (with content before mapping). By default, such messages are not taken into test results. However, they can be included by setting this parameter with the value 'X'. In PI/PO monitoring, such messages are called 'transisted.'	X
Allows Receiver interface be same as Sender interface	PISENREC	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
Sender uses Virtual Receiver	PIVIRTUALR	The parameter needed for interfaces that Sender uses Virtual Receivers. In this case, the receiver cannot be removed during Test Case execution, and this option will block the removal. Otherwise, the HTTP 500 error will be returned by SAP PI/PO with an error message that the routing is missing.	X
Package size for bulk read of message successor list	PIMSGLSTP	To improve the performance of test runs and reduce the number of PI/PO API calls, reading of the message successor list is done in batches. This parameter determines how many messages are checked in a single call. Depending on PI/PO underlying database system settings, this parameter can be adjusted to avoid exceeding of maximum SQL statement length.	250
PI: Ignore parent message during TC creation	PIIGPARENT	This parameter 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 Int4 IFTT 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 set this parameter to X	X
PI: Read Successor Message(s) based on Reference ID	PISUCREFID	Collect output messages from subsequent ICOs based on Reference ID instead of parent relation	X
PI: Skip searching for Successor Message(s)	PISUCMSGID	Collect output message based on the same message key as input. This parameter can be used to improve performance of saving test cases for 1:1 scenario as additional API calls to search for message successors are not required.	X

Stopping channels before test execution

This feature is obsolete and replaced by SAP PIT Injector.
Int4 IFTT allows to automatically stop & start particular PI/PO communication channels preventing messages from being sent to receiver systems. The messages after validation are automatically canceled.
The communication channel must be set to an external mode to be able to control them from an external application (see remarks below).
It is possible to use this functionality on all or only in chosen landscapes.

Parameter	Technical name	Description
Receiver Channel Landscape to be stopped/started	CHANNEL_ZL	Landscape on which below channel should be stopped/started. This parameter is optional, but when it is provided, the channel Name, BC, Party must be grouped with Landscape by the same grouping ID
Receiver Channel Name to be stopped/started	CHANNEL	Name of the receiver channel to be stopped.
Receiver Channel BC to be stopped/started	CHANNEL_BC	Business Component of the receiver channel to be stopped.
Receiver Channel Party to be stopped/started - Party	CHANNEL_PT	Party of the receiver channel to be stopped.
Stop Receiver Processing	PITSTOP	Stops Receiver Processing when using PIT as a message injector.

Remarks

Suppose any of those values is empty in the Communication Channel configuration on the Configuration Builder side. In that case, it still needs to be set up in Additional Parameters but left blank (like Party).
To let Int4 IFTT control SAP PO channels, the channel control must be set to External:

As the outbound interface can have multiple receivers and corresponding channels, it may be necessary to stop more than one Communication Channel.

To do that, add a new multiple values field counter/group is used. Each combination of part/business component and the party should be grouped with its counter/group ID (like ST1 and ST2 in the example). In general, for parameters that are considered as a group, it is a good practice to add the same identifier in the Counter/Group field.

This way, we can add an unlimited number of Communication Channels to stop during the outbound test case execution.

Testing sender channel's adapter modules

For the interfaces that are required to test the processing of sender adapter modules. (i.e., EDI flows where the conversion of EDIFACT to XML is in adapter modules) it is necessary to add to the configuration object the name of the original sender channel used by the interface.

Parameter	Technical name	Description
Reference Sender Channel Name	CC_NAME	Name of the sender channel to be used as a reference.
Reference Sender Channel BC	BC_NAME	Business Component of the sender channel to be used as a reference.
Reference Sender Channel Party	PARTY_NAME	Party of the sender channel to be used as a reference.

These three parameters work as a group, so it is a good practice to provide the same identifier in the counter/group field. Example:

Suppose any of those values remain empty in the Communication Channel configuration on the Integration Builder side. In that case, they need to be left blank inside of the Additional Parameters configuration.

Synchronous and asynchronous REST/JSON Interface

To complete the synchronous interface configuration, we need to provide the name of the testing receiver communication channel by the first three parameters.

Alternatively, the PI endpoint might be provided as a fourth parameter if the interface call is HTTP or SOAP.

Parameter	Technical name	Description	Example:
PI: Synchronous: Receiver Channel BC (obsolete)	SYNC_BC	Business Component of the receiver channel used to process a synchronous message	BC_WEBSHOP_SYNC_ED1
PI: Synchronous: Receiver channel Party (obsolete)	SYNC_PT	Party of the receiver channel used to process synchronous message
PI: Synchronous: Receiver channel Name (obsolete)	SYNC_CC	Name of the receiver channel used to process synchronous message	CC_RCV_HTTP_SYNC_IFTT
Direct HTTP URL	SYNC_URL	Direct endpoint to tested interface (synchronous). It should be provided without PI endpoint & port. Additionally, if the URL is dynamic (like JSON queries), it is possible to enter the variable name in {} brackets. The value will be substituted before calling the final URL	/RESTAdapter/webshop/salesOrder/ create/1/{PONUMBER}/1
PI: Synchronous: Direct HTTP operation	SYNC_HO	If the direct endpoint is provided, here you can specify the HTTP operation (for synchronous REST testing)	PUT
PI: Asynchronous: Direct HTTP	URLASYNC_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: Asynchronous: Direct HTTP operation	ASYNC_HO	If the direct endpoint is provided, here you can specify the HTTP operation (for asynchronous REST testing)	POST
PI: Synchronous: Call service during TC creation	SYNC_CS	The default approach uses the XI30 service for execution and source for messages in SAP PO persistence. This parameter forces to call service during TC creation instead of taking the response from persistence. It should be used only if necessary.	X
PI: Alternative RFC Connection	ALT_RFC	Alternative RFC Connection where the REST message should be sent. If this parameter is populated, then the message will be sent there (ALT_RFC). If not, then the message will be sent by default to SYNC_URL or ASYNC_URL (depending on the type of interface).	SAPSYS1_RFC

Specific Message Search by PI Message Selector

Depending on the interface type and SAP PI/PO logging and staging settings, it might be necessary to provide the receiver interface name & namespace. This situation happens when staging is set in the system after message mapping (AM). This causes that in PI/PO message monitoring, all messages are displayed only with the receiver interface name and namespace in the interface field. The exception would be an interface with multiple receivers where the version before receiver determination might also be stored.

In providing the corresponding receiver interface name and namespace for the receiver interface, the message selector will use these parameters to retrieve the correct message version. The configuration objects in Int4 IFTT always need to be set up based on the sender interface. But in the specific case, as described above with different staging settings as we often see on production systems, these two parameters will help point to the message selector's correct message. A common mistake is setting up the configuration object based on the receiver interface, but this will cause issues for sender interfaces with multiple receivers and if IFTT needs to determine the correct configuration/automation object when only the message ID is provided to generate the test case.

The only way to support an environment without staging activated, as described in the SAP PI/PO logging and staging section, is to provide the sender interface with the two parameters. Parameters will be used to point to the correct version of the message via the receiver interface name and namespace.

You will use these two parameters for automation objects defined in Int4 IFTT that will not have messages visible on the sender interface in SAP PI message monitoring. It is essential to check that messages are available in the PI/PO message monitor for the corresponding receiver interface for these ICO. Suppose this is the case, and additional parameters are provided. In that case, the message selector will return the message, and the test case will be generated from the correct message version.

In case there is set a dynamic receiver in the interface, Int4 IFTT can add more than one receiver interface name & namespace. This setting can be done using the field counter/grouping.

Parameter	Technical name	Description	Example:
Message Search - Interface Name	PISRCH_IFN	Used to specify the Interface Name within which the PI Message Selector should search for the version of the message. This parameter is only to be entered if Interface Name visible in the PI Message Monitor main screen differs from the Interface Name used to create the object definition.	If we only have receiver interfaces visible in the PI message monitor, then use the receiver name specified in the ICO of the sender interface specified in the automation object used.
Message Search – Namespace	PISRCH_NS	Used to specify the Interface Namespace within which the PI Message Selector should search for the version of the message. This parameter is only to be entered if Interface Namespace visible in the PI 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

Manual test cases (without XI 3.0 header)

Parameter

Technical name

Description

Example:

Reference PI Test Case ID (headers)

REF_TC

This parameter will replace the XI 3.0 header of the input test message with the reference header stored in another test case. I.a. Sender Party/Sender Component/Interface name/ Interface namespace will be read from the reference test cases.

The value is an existing test case number. The same header would be applied for all test cases using this automation object definition.

It is used for SAP PI/PO manual test cases, and if there is a project need that the interface signature should be changed.

122

ABAP Stack SAP PI Integration

To test the integration of the ABAP PI stack, it is mandatory to provide some additional information in the additional parameters of the object definitions.

Parameter	Technical name	Description
PI: Landscape where interface exists on the ABAP stack	PIABAP	Name of the PI ABAP Landscape. It is required to access the ABAP stack PI messages.
PI: ABAP stack: Read input message from Java persistance	PIABAP_JIN	This parameter must be filled with an 'X' in the case when the ABAP stack PI read a message from the JAVA adapter
PI: ABAP stack: Read output message from Java persistance	PIABAP_JOU	This parameter must be filled with an 'X' in the case when the ABAP stack PI sends a message to the JAVA adapter

It is also possible to test ABAP stack PI plain HTTP Adapter (/sap/xi/adapter_plain endpoint). It allows testing integration configurations with Sender Agreement.

Parameter	Technical name	Description	Example:
PI: ABAP stack: Send to Plain HTTP Adapter	PIPLHTTP	This parameter must be filled with 'X' if test messages have to be sent to plain HTTP Adapter.	X

Application Interface Framework (AIF)

To complete the AIF interface configuration, we need to provide AIF Interface Name, Interface Version, and Namespace.

Parameter	Technical name	Description	Example:
Interface Namespace	AIF_IFNAME	The namespace of used Application Interface Framework Interface Required parameter for all AIF interfaces.	Z_IFTT
Interface Name	AIF_IFNAME	Used Application Interface Framework Interface Name. Required parameter for all AIF interfaces.	SORD_CR
Interface Version	AIF_IFVER	The version of used Application Interface Framework Interface Required parameter for all AIF interfaces.	00001

You can find proper values for each parameter in AIF Configuration using TCODE: /n/aif/cust in branch SAP AIF → Interface Development → Define Interfaces

Cloud Platform Integration (CPI)

To complete the CPI interface configuration, we need to provide the: SOAP Action and Store Id used to persist message parameters:

Parameter	Technical name	Description	Example:
SOAP Action	SOAP_ACTN	The SOAP action if the tested interface is a SOAP Webservice	http://www.abc.org/po/NewOperation
Store Id used to persist message	CPI_STORE	The name of the store used to persistence the payload	BeforeMapping
Adapter type	CPI_ADAPT	Adapter type of tested iFlow. Take a look at the router block in IFTT Dispatcher.	AMQP, HTTP, IDOC, JMS, PROCESSDIRECT, SFTP, SOAP
Block in iFlow to get output payload	CPI_BLOCK	Block to get payload after processing. This parameter can be specified multiple times to capture different output payloads in e.g. splitter scenarios.	EndEvent_2
Block in iFlow to get input payload	CPI_I_BLOC	Block to get payload before processing	CallActivity_2
Variable name as application ID	CPI_APPID	The variable name to fetch the value from an application ID. In case not provided, the value will be generated automatically.	BUKRS
HTTP Method	CPI_HTTPMT	HTTP method	PUT, POST, DELETE, GET
HTTP Query	CPI_HTTPQR	HTTP query	param1={MYPARAM}&param2={MYPARAM2}
ProcessDirect endpoint	CPI_PDENDP	Name of endpoint	/iftt_pdirect
Simulation Start Point	CPI_SIM_S	Point in iflow where simulation should start. Parameter used in CPI Unit Test type.	SequenceFlow_1
Simulation End Point	CPI_SIM_E	Point in iflow where simulation should end. Parameter used in CPI Unit Test type.	SequenceFlow_5

Boomi

Depending on the Boomi process the corresponding additional parameters can be populated accordingly.

Parameter	Technical name	Description	Example:
Boomi: HTTP Destination	BOOMIDEST	This is an optional parameter in case there are more than one Atoms per Environment. The RFCs to the specific Atom on which the test case should be executed have to be configured. The parameter can be environment specific by using the following pattern: LANDSCAPE:DEST	BOOMI_QA_ATOM environment specific: DEV:BOOMI_DEV_ATOM QA:BOOMI_QA_ATOM
Boomi: Operation in Process to get input payload	BOOMI_I_OP	The name of the operation to get the input payload	listenWebService
Boomi: Operation in Process to get output payload	BOOMI_O_OP	The name of the operation to get the output payload. It is possible to provide multiple output operations, then only for the specified once the payloads will be stored and compared during test case execution.	sendIDoc

SAP eCATT Integration

To test the integration of ABAP stack PI, it is mandatory to provide additional information in the additional parameters of the object definitions.

Parameter

Technical name

Description

Example:

eCATT object is on remote system

ECATT_RMT

By default, Int4 IFTT assumes that the eCATT scripts and the test configurations are on the same local machine that Int4 IFTT is installed. This assumption allows to dynamically control the execution on the different environments thanks to a landscape system conversion.

However, if the eCATT is on a different machine, then this parameter needs to be marked.
In such a case, the eCATT script/configuration will be executed based on the RFC name found thanks to the execution landscape.
In this scenario, it is possible to have two different recordings (but with the same name)in, for example, the ECC and S/4HANA systems.

X

SAP Output Control

Parameter	Technical name	Description	Example:
Trigger the output from message control (NAST)	OUTPUTNAST	Outbound test cases by triggering the Output Control	X

ABAP Proxies

Parameter	Technical name	Description	Example:
Proxy Message Version	PRX_MSGVER	Version of message from SXMB_MONI which is used to read payload during test case creation When this parameter is not specified IFTT reads last available version.	000