Creating the configuration object for REST/JSON interface

USE

Testing REST interfaces are based on the synchronous test type. Int4 IFTT uses the request XML or JSON message to trigger the interface. Then validates the XML or JSON response and the final document creation on the SAP backend side (if there is such a receiver and business need). Creating the configuration object allows linking the request message with the response and the business document.

Separate configuration objects will be required for each REST operation handled by the interface.

There are two ways of configuring REST configuration objects:

• A. Direct call of REST PO service by Int4 IFTT. This way can be used when the REST channel doesn't require additional authorizations and is accessible by HTTP.
• B. Dedicated receiver communication channel in SAP PO to call the sender channel. This way can be used when the REST sender channel requires an additional authentication method. 

PREREQUISITES: 

• receiver communication channel for sender  (Option B)

PROCEDURE

1. Create a new object definition with: object name, description, service interface name, and the namespace of the tested interface

2. Define Additional Parameters:

Since version 2.7.1 Int4 IFTT supports natively JSON comparison and JSONPath expressions.
In previous versions JSON payloads have to be treated as flat files and configured with following parameters;

Afterward, depending on the connection to REST adapter (Option A: direct or Option B: via receiver communication channel)

Option A:

Option B: This option is the same as any other synchronous interface. The receiver channel needs to be created only for int4 IFTT. This channel would be used to call the original interface.

As these three parameters are linked, the counter field should be filled with the same value, for example, A or 1.

3. In the Object Variables, tab define variables names and descriptions.  Then in the Variable Processing tab, define actions and variable processors that will process each of the variables data

In REST testing, there might be two purposes for using the variables. The first one is like described above to create a dynamic URL for the REST channel. In such a case, the variable contains Action 10 (Populate variable before execution) with procedure USER_DEF (Read user-defined value from the cockpit). This setting allows providing a dynamic value for each case directly in Testing Cockpit. Example:

The second use of the variables is enriching the request payload and replacing some document keys with new values. Here the instruction is the same as for any other inbound asynchronous interface. Additionally, if the REST interface creates a document in SAP Backend and IFTT will validate it and use the variable for the DB lookup.

If your variable uses a number range, please remember to maintain it in the Number Ranges tab. 

4. Define Database Comparison Rules define the Table Names of those tables that should be compared. 
Define Selection Criteria define how IFTT should locate those tables, e.g., by a reference to which value
Define Comparison Details define a set of fields to be compared and rules to be applied

This part is only necessary when the interface receiver is SAP Backend. You would like to configure automatic validation of documents created there. Please follow precisely the same rules as for inbound interface document validation as there are no differences.

5. Maintain the Payload Validation Ignore List tab to create any allowed exceptions for the REST response.

Depending on the response format (XML or JSON), use XPATH or Expression language for flat files.
as en example of JSON difference please see this one:

START_TAG("DocumentNumber":")&&END_TAG(")

It allows for the difference in the following response:

The configuration object is completed; please see the section on how to create REST test cases.