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:
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. | '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 |
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 |
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. | 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. | 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. | 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 | Example: |
---|---|---|---|
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 | Example: |
---|---|---|---|
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). 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 | Example: |
---|---|---|---|
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}¶m2={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. | 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. | X |
SAP Output Control
Parameter | Technical name | Description | Example: |
---|---|---|---|
Trigger the output from message control (NAST) | OUTPUTNAST | 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 |
© 2017 - 2022 Int4 AG All rights reserved