Automation Object

The automation (configuration) object stores all the rules for a single application interface that IFTT will test. The object should be configured when adding a new interface into int4 IFTT. It is a one-time process for each application interface.

Object definition is also called automation object. It represents a standard set of rules used during the testing of a particular middleware or backend interface. Usually, one object definition is created per each application interface. If the interface contains multiple service operations, then separate objects will be needed for each of them. However, if multiple senders and receivers use the same interface, one object definition will be enough.

Object definitions are created almost independently of the interface technology. Objects for testing SAP PO or SAP Cloud Platform Integration or backend interfaces like IDOC or Proxy are defined in the same place. The difference is a set of required or optional parameters. They are explained separately per technology and interface type in our  configuration guides.

The principle goal of object definition is to identify the tested interface and describe assertions to be performed during automated validation. Configuration object stores all standard settings for the tested interface. Thanks to that, the test cases themselves are light as they contain only the input and optionally output of the interface message.

Depending on the test type, different parts and parameters need to be provided. This chapter and the below ones discuss all the settings and parameters without particular application.

The configuration object consists of:

• Header: The object header contains technical fields needed for interface identification in the middleware platform. Additionally, it stores a reference to the backend system in which the validation is performed.
• Variables: There are multiple usages of variables. For instance, in inbound test cases, they substitute particular fields of original payload messages to avoid posting duplicates. They are also used to correlate interface messages with documents posted in the backend systems. In outbound test cases, they are used in searching the middleware platforms to find a proper message that would be validated as a part of the test. Variables contain a set of rules to identify value in reference messages and the way how the new value is generated. One of the methods of generation of new values is internal number ranges

• Database Rules: This part contains a definition of backend validation rules. Application interfaces create business documents in backend systems. The validation could be performed by comparing the database representation of those documents. Database rules contain a set of tables and fields and the selection criteria. First, using the variables, the rows containing the document are selected. Each defined field is compared between the value from the reference document and the value from the newly created one. To create such validation in Configuration Object, the user needs to know how the document is represented in the backend database.

• Payload Validation Ignore List: The other way to automatically determine test results is to compare middleware messages. This kind of validation might be used in all scenarios where the middleware or synchronous services are tested. It may also be combined with end-to-end database results. Contrary to database rules where all the tables and fields need to be specified individually here, only the definition of exceptions is required. The payload from the current processing will be compared with the reference stored during test case creation.

• Additional Parameters: Apart from standard sections reused by multiple test types, all others settings are defined as additional parameters.

The configuration objects are maintained in /INT4/IFTT_CONF tcode, which, technically, is an SAP standard cluster view. The first table contains all the configuration object headers. The tree on the left shows all underlying settings after selecting the row with the object.

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.

An example screen of /int4/iftt_conf: