USE:
As explained in the automation object introduction, it consists of different levels starting from the object header. The header contains mainly the description and identification of the tested interface.
...
| Info |
|---|
Object definitions are managed by /n/INT4/IFTT_CONF transaction. In the system, object definition is stored as central header node and sub-nodes: IFTT configuration is created based on a standard SAP cluster view, which means that only one person at the time can edit it. That fact helps in assuring data consistency.
|
...
| Parameter name | Description | Example | ||||||
|---|---|---|---|---|---|---|---|---|
IFTT Automation Object ID Object
| This name needs to identify the interface for which the configuration is created. It may also contain a test type if we create two separate objects, one for SAP PO unit testing and another for end-to-end testing. Each IFTT implementation should start from building a naming convention. One of the critical definitions would be configuration object names. An example of such convention: {XX}{T}_{YYYY}_{DIR}_{BUS_OBJ} where XX is a middleware like PO, or CPI or ECC T is a test type like U as Unit Test, E as End to End YYYY is a common interface number from the interface master list DIR is a direction like I_nbound to SAP, O_utbound or S_ynchronous BUS_OBJ is affected business object and action The maximum length is 30 characters | POU_0100_I_EDI_SALES_ORD_C Unit test of SAP PO interface for EDI sales order creation to SAP, identified in the master list under number 0100 | ||||||
| Automation Object Description | Extended description of the tested interface. Both: object name and object description will be displayed for each test case. They need in an easy way explain what each test case is. | SAP PO unit test: EDI Sales order creation in Ex1 | ||||||
| Service Interface Name | The middleware service interface name. For SAP PO and CPI or ABAP Proxy, it would be the interface name. For IDocs, it would be full IDoc type. If the object is used by inbound/unit/synchronous test types (to SAP), you must specify the sender interface name. For outbound interfaces, in most cases, the receiver interface name. The details are explained in each test type guide. In SAP PO, the best information to see interface service name is an ICO definition. | SI_O_PurchaseOrder - SAP PO interface name ORDRSP.ORDERS05 - IDoc name for IDOC test type | ||||||
| Service Interface Namespace | The middleware service interface namespace. For SAP PO, it would be a namespace from ICO. In the IDoc test type, the namespace is empty (IDoc doesn't have namespaces) The name and namespace will allow to automatically build test cases just based on providing message GUID/number from middleware. Based on content, the interface name/namespace will be checked, and automatically configuration object proposed. | http://webshop.comRef. | ||||||
| Default Test Type | Test Type that will be used as a default while creating test cases. | 20 (PI Unit Test) | ||||||
Reference Object for DB Rules | Reference Business object name. Suppose we have multiple interfaces that create the same business documents in the receiver system. In that case, we don't need to specify numerous times backend validation rules (DB comparison rules). Database comparision Database comparison rules defined directly in the automation object take precedence over this setting. | GENERIC_SALES_ORDER | ||||||
| Wait | Wait Flag indicating if test case execution should be stopped after sending test case message to middleware. IFTT will show the confirmation box, and the user will decide to continue. This setting can execute manual follow-up actions before running the next test case or checking the validations. |
| ||||||
| Wait (sec) | Delay (in seconds) between test case execution ( sending message) and checking of the results. Useful, e.g., in scenarios when inbound messages are processed with delay using batch jobs. | 60 | ||||||
Backend system line for current doc.
| The system in which the reference backend document is stored. The value is This parameter points out the system line where IFTT should create test documents during test case execution. In most cases, reference documents and documents created during current test execution are stored in the same system line. However, suppose IFTT is used in a migration scenario (for example, migration from ECC to S4/HANA). In that case, the documents might be created in the new system and then compared with the references from the old system. The value should be a system line described in the landscape configuration. Note: If Backend system line for the current doc. has the same name value as the Backend system line for the current reference doc. (for instance, both are S4/HANA) then the RFC for connection between the systems will be maintained both in: a) in the original environment of the reference document (for instance, production system like production) b) in the environment of where the current test case execution takes place (for instance, development system like development) If Backend system line for the current doc. does not have the same name in is different than the Backend system line for the current reference doc. then, the RFC for systems connection will be maintained only in the environment of the current execution (for instance, development system like development), but for both systems system lines (like ECC and S4HANA) ECC | S4HANA | ||||||
Backend system line for reference doc.
| The system in which the newly created backend document should be (after test case execution). In most cases, reference documents and documents created during current test execution are stored in the same system. However, suppose IFTT is used in a migration scenario (for example, migration from ECC to S4/HANA). In that case, temporarily, the interface may point to another system. The documents might be created in the new system and compared with the old one referencesThis parameter points out the system where the reference backend document is stored. The value should be a system line described in the landscape configuration. Note: If Backend system line for the current doc. has the same name value as the Backend system line for the current reference doc. (for instance, both are S4/HANA) then the RFC for connection between the systems will be maintained both in: a) in the original environment of the reference document (for instance, production system like production) b) in the environment of where the current test case execution takes place (for instance, development system like development) If Backend system line for the current doc. does not have the same name in is different than the Backend system line for the current reference doc. then, the RFC for systems connection will be maintained only in the environment of the current execution (for instance, development system like development), but for both systems system lines (like ECC and S4HANA) S4HANA | ECC | ||||||
| Debug info | This parameter is helpful while creating and testing the configuration object. AdditionalIFTT will provide additional, more technical information is provided in Test Execution Report during the running of the first test cases . It if this parameter is set. Therefore, it is recommended to set this option initially and deactivate it when object definition is confirmed after executing the first test cases. |  | ||||||
| Display wait popup before validation | Wait Flag indicating if IFTT should stop test case execution after sending test case message to middleware. IFTT will show the confirmation box, and the user will decide to continue. This setting can execute manual follow-up actions before running the next test case or checking the validations. |
| ||||||
| Delay between exec. and validation (sec) | Delay (in seconds) between test case execution ( sending message) and checking the results. Useful, e.g., in scenarios when inbound messages are processed with delay using batch jobs. | 60 |
In subchapters, the other aspects of configuration objects are described.
...