Automation The automation (configuration) object stores all the rules for a single application interface to be testedthat 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 common standard set of rules that are 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 the same interface is used by 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 and the . 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 common 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 of on the test type, different parts and parameters need to be provided. This chapter and the below chapters ones discuss all the settings and parameters without particular application.
The configuration object consists of:
- Header: The The object header contains set of technical fields needed for interface identification in the middleware platform. Additionally, it stores a reference to the backend system in which the validation are is performed.
- Variables: There are multiple usages of variables. For instance, in inbound test cases, they are used to 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 to search 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 are is generated. One of the method methods of generation of new values are internal number ranges.is internal number ranges
- Database Rules: This part contain contains a definition of backend validation rules. Application interfaces create business documents in backend systems. The most accurate validation could be performed by comparing the database representation of those documents. Database rules contains contain a set of tables and fields and the selection criteria. First, using the variables, the rows containing the document are selected and each of the defined fields . Each defined field is compared between the value from the reference document and the value from the newly created one. In order to 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 result is a comparison of results is to compare middleware messages. This kind of validation might be used in all scenarios where the middleware or synchronous services are tested or it . It may also be also combined together with end-to-end database results. In opposite 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 common standard sections reused by multiple test types, all others settings others settings are defined as additional parameters.
The configuration objects are maintained in /INT4/IFTT_CONF tcode. This , which, technically, is an SAP standard cluster view. The first table contain contains all the configuration object headers and the . The tree on the left shows all underlying settings after selecting the row with the the object.
IFTT configuration is created based on a standard SAP cluster view. This , which means that only one person at the time can edit it. This is due to keep consistenceThat fact helps in assuring data consistency.
An example screen of /int4/iftt_conf:
