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:

ParameterTechnical nameDescriptionExample:
Flag for Flat File interfacesFLAT_FILEUsed 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 EncodingFILE_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

ParameterTechnical nameDescriptionExample
Number of attempts to wait for TC resultsTCRETRYNUM

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

ParameterTechnical nameDescriptionExample
HTTP HeaderHTTPHEADER

Add custom HTTP header sending to CPI/PI.

There are two methods to use this parameter:

  1. Directly filling the header name and header value in format "HeaderName=HeaderValue".
  2. 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

ParameterTechnical nameDescriptionExample
CSRF Token FetchCSRF_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 EndpointCSRF_URLOptional 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.  

ParameterTechnical nameDescriptionExample:

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 processingPIMSGVERSN

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 processingPIMSGVERADOptional 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 outputPIOUTPUT

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 resultPINONPHYS

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 interfacePISENREC

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 ReceiverPIVIRTUALR

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 listPIMSGLSTP

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 creationPIIGPARENT

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 IDPISUCREFIDCollect output messages from subsequent ICOs based on Reference ID instead of parent relationX
PI: Skip searching for Successor Message(s)PISUCMSGIDCollect 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.


ParameterTechnical nameDescriptionExample:
Receiver Channel Landscape to be stopped/startedCHANNEL_ZLLandscape 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

CHANNELName of the receiver channel to be stopped. 

Receiver Channel BC to be stopped/started

CHANNEL_BCBusiness Component of the receiver channel to be stopped. 
Receiver Channel Party to be stopped/started - PartyCHANNEL_PTParty of the receiver channel to be stopped. 
Stop Receiver ProcessingPITSTOPStops Receiver Processing when using PIT as a message injector.

Remarks

  1. 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).
  2. 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.

ParameterTechnical nameDescriptionExample:
Reference Sender Channel NameCC_NAMEName of the sender channel to be used as a reference. 
Reference Sender Channel BC BC_NAMEBusiness Component of the sender channel to be used as a reference. 
Reference Sender Channel PartyPARTY_NAMEParty 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.


ParameterTechnical nameDescriptionExample:
PI: Synchronous: Receiver Channel BC (obsolete)SYNC_BCBusiness Component of the receiver channel used to process a synchronous messageBC_WEBSHOP_SYNC_ED1
PI: Synchronous: Receiver channel Party (obsolete) SYNC_PTParty of the receiver channel used to process synchronous message
PI: Synchronous: Receiver channel Name (obsolete)SYNC_CCName of the receiver channel used to process synchronous messageCC_RCV_HTTP_SYNC_IFTT
Direct HTTP URLSYNC_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 operationSYNC_HOIf 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 operationASYNC_HOIf the direct endpoint is provided, here you can specify the HTTP operation (for asynchronous REST testing)POST
PI: Synchronous: Call service during TC creationSYNC_CSThe 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 ConnectionALT_RFCAlternative 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.

ParameterTechnical nameDescriptionExample:

Message Search - Interface Name

PISRCH_IFNUsed 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 – NamespacePISRCH_NSUsed 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) 

ParameterTechnical nameDescriptionExample:
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.

ParameterTechnical nameDescriptionExample:
PI: Landscape where interface exists on the ABAP stackPIABAPName of the PI ABAP Landscape. It is required to access the ABAP stack PI messages.
PI: ABAP stack: Read input message from Java persistancePIABAP_JINThis 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 persistancePIABAP_JOUThis 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.

ParameterTechnical nameDescriptionExample:
PI: ABAP stack: Send to Plain HTTP AdapterPIPLHTTPThis 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


ParameterTechnical nameDescriptionExample:
Interface NamespaceAIF_IFNAMEThe namespace of used Application Interface Framework Interface
Required parameter for all AIF interfaces.
Z_IFTT
Interface NameAIF_IFNAMEUsed Application Interface Framework Interface Name. Required parameter for all AIF interfaces.SORD_CR
Interface VersionAIF_IFVERThe 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: 

ParameterTechnical nameDescriptionExample:
SOAP ActionSOAP_ACTNThe SOAP action if the tested interface is a SOAP Webservicehttp://www.abc.org/po/NewOperation
Store Id used to persist messageCPI_STOREThe name of the store used to persistence the payloadBeforeMapping
Adapter typeCPI_ADAPTAdapter 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 payloadCPI_BLOCKBlock 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 payloadCPI_I_BLOCBlock to get payload before processingCallActivity_2
Variable name as application IDCPI_APPIDThe variable name to fetch the value from an application ID. In case not provided, the value will be generated automatically.BUKRS
HTTP MethodCPI_HTTPMTHTTP methodPUT, POST, DELETE, GET
HTTP QueryCPI_HTTPQRHTTP queryparam1={MYPARAM}&param2={MYPARAM2}
ProcessDirect endpointCPI_PDENDPName of endpoint/iftt_pdirect
Simulation Start PointCPI_SIM_SPoint in iflow where simulation should start. 
Parameter used in CPI Unit Test type.
SequenceFlow_1
Simulation End PointCPI_SIM_EPoint 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.

ParameterTechnical nameDescriptionExample:
Boomi: HTTP DestinationBOOMIDEST

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 payloadBOOMI_I_OPThe name of the operation to get the input payloadlistenWebService
Boomi: Operation in Process to get output payloadBOOMI_O_OPThe 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.

ParameterTechnical nameDescriptionExample:
eCATT object is on remote systemECATT_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


ParameterTechnical nameDescriptionExample:
Trigger the output from message control (NAST)OUTPUTNAST

Outbound test cases by triggering the Output Control

X


ABAP Proxies


ParameterTechnical nameDescriptionExample:
Proxy Message VersionPRX_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




























© 2017 - 2022 Int4 AG All rights reserved