Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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
Anchor
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:

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

Anchor
FFlinesep
FFlinesep

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)


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

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

...

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:

...

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

...

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.


Info
titleRemarks
  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.

...

Anchor
setting bc and cc
setting bc and cc

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
Anchor
PIMesgSel
PIMesgSel

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.

...

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

...

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
aif_ns_version
aif_ns_version

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


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
CPI
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

...

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

...