USE
Testing REST interfaces is are based on the synchronous the synchronous test type. The principle is also the same. int4 Int4 IFTT uses the request XML or JSON message to trigger the interface and then . 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 Creating the configuration object allows to link 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
- 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 authetification
- authentication method.
PREREQUISITES:
- receiver communication channel for sender (Option B)
...
1. Create a new object definition with: object name, description, service interface name, and the namespace of the tested interface
...
If the interface format is JSON set:
| Param name | Description | Value |
|---|---|---|
| FLAT_FILE | General: Flag for flat-file interfaces | X |
| FLAT_LS | General: Flag for flat-file Line Separator | { |
- Currently
- , Int4 IFTT is equipped with XML and a flat-file parser. JSON is treated as a flat file in such a case. The XML content doesn't require additional parameters.
- Afterwards
- Afterward, depending on the connection to REST adapter (Option A: direct or Option B: via receiver communication channel)
- Option A:
| Param name | Description | Value |
|---|---|---|
| SYNC_URL | PI: Synchronous: Direct HTTP URL | URL to call REST channel (without SAP PO hostname & port). Example: RESTAdapter/webshop/material/{MATNR} the URL might be dynamic and use |
Int4 IFTT Variables. |
TThe variable's name must be provided in uppercase and surrounded by {} brackets. |
creating a single interface configuration object for multiple test cases. | ||
| SYNC_HO | PI: Synchronous: Direct HTTP Operation | The REST operation |
| like GET, PUT, DELETE, |
| etc. |
Option B: This option is exactly 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.
| Param name | Description | Value |
|---|---|---|
| SYNC_CC | PI: Synchronous: Receiver Channel Name | Name of the channel created to test this particular interface |
| SYNC_BC | PI: Synchronous: Receiver Channel BC | Business Component of the above channel |
| SYNC_PT | PI: Synchronous: Receiver Party | Party of the above channel. |
| If a party is not used, then the parameter is still necessary, but with a blank value |
As these three parameters are linked with each other , the counter field should be filled with the same value. For , for example, A or 1.
3. In the Object Variables tab , 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 of 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 to provide 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 exactly the same as for any other inbound asynchronous interface. Additionally, if the REST interface creates a document in SAP Backend and IFTT will perform the validation of it, validate it and use the variable will be used for the DB lookup.
if 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 i, e.eg., 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 and you . You would like to configure automatic validation of document documents created there. Please follow exactly precisely the same rules as for for inbound interface document validation as there are no differences.
5. Maintain 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.
...