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.
...
Flat File (Flat message) interfaces Anchorflat_file flat_file
flat_file | |
flat_file |
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) |
Info |
---|
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 |
...
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: |
...
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 |
...
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. |
Info | ||
---|---|---|
| ||
|
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.
...
Anchor | ||||
---|---|---|---|---|
|
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
Anchor | ||||
---|---|---|---|---|
|
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.
...
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 |
...
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.
...
Anchor | ||||
---|---|---|---|---|
|
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 |
Info |
---|
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)
Anchor | ||||
---|---|---|---|---|
|
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 |
...
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 |
...