SAP PI/PO REST/JSON

USE:

Int4 IFTT allows testing the SAP PO REST/JSON interfaces for both synchronous and asynchronous scenarios. The procedures for these types of interfaces are described in the relevant sections below.

1 PI/PO Synchronous testing
2 PI/PO Asynchronous testing

PI/PO Synchronous testing

Synchronous REST/JSON scenarios can be tested using the PI E2E Synchronous test type. The principle is also the same, Int4 IFTT uses the request XML or JSON message to trigger the interface. Then, it validates the XML or JSON response and the final document creation on the SAP backend (if there is such receiver and such a business need).

PREREQUISITES:
You have completed the steps described in the General rules for a test case creation.

PROCEDURE:

Creating synchronous REST/JSON test case:

Select "PI Synchronous" Interface Type.
Leave “Document Number” empty
Save the test case.

Now the procedure differs depending on the type of REST operation/action and how the interface works is different.

A) Operations create a new resource or document like PUT or POST (the operation is defined in the configuration object). For such operation interface requires a payload (body) with a request:

Click the Content button of the created test case.
In the Content Selection pop-up window, select the content type to be displayed. To make a new test case, request XML has to be added.
Select xml editor.
past the request JSON or XML request payload:
...or upload it from file
Press the Save icon still in the message editor after placing the content and press back.
On the following popup, confirm that the payload should be stored:
Now the Int4 IFTT will place a call to the tested service to collect a response. This response payload will be a reference for further test case executions.
If the call was successful user should receive confirmation status:

Otherwise, the popup with errors will be displayed.
[Optionally] you can review the response payload by clicking the 'Content' button.

Please note that the service's response is collected automatically during test case creation by calling the service. If the sample request payload was already used and the interface requires unique values, then you need to enrich them manually and provide unique identification numbers (like, for example, Purchase Order Number)

B) Operations that retrieve or delete records like GET or DELETE (the function is part of the used configuration object). If the request payload(body) is not needed, the parameters are passed in the URL when calling the service.

Example screenshots are from our sample JSON interface that returns material descriptions based on the material number provided in the URL.

The URL template is stored in the configuration object. Int4 IFTT variables will modify the endpoint and call service with proper parameters. One of the ways of assigning values to variables is the test case container.

Select created test case and click the 'container' button.
Provide values that you will modify the URL:
Now the Tnt4 IFTT will place a call to the tested service to collect a response. This response payload will be a reference for further test case executions.
If the call was successful user should receive confirmation status:

Otherwise, the popup with errors will be displayed.

5. [Optionally] you can review the response payload by clicking the 'Content' button.

The example of execution of the above interface:

As you can see, the service was called based on the parameter value set in the cockpit.

PI/PO Asynchronous testing

Asynchronous REST/JSON scenarios can be tested using PI GUID E2E Inbound test type. The procedure is similar to the standard one described in the PI E2E GUID section. However, to test properly asynchronous scenarios, some additional steps described below need to be followed.

PROCEDURE:

A. Automation Object creation

When creating Automation Object for an asynchronous interface, the following parameters (apart from the other settings that should be specified for a given scenario) in the additional parameters of Automation Object should be defined:

PI: Asynchronous: Direct HTTP URL - it is mandatory to select this parameter to test the asynchronous scenario using the PI GUID E2E Inbound IFTT interface type. Example definition below:

PI: Asynchronous: Direct HTTP operation - this parameter defines HTTP operation to be performed. If this parameter is empty, then by default IFTT will perform POST operation. Example definition below:

Please refer to the section Automation Object - Additional Parameters to read more about these and other parameters.

B. Test case creation

Select "PI GUID E2E Inbound" Interface Type.
Select Automation Object created according to the procedure described in section A above.
Select the reference document number.
Save the test case and then execute it.