Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
kammaje_cis
Active Contributor

In this document I explain beginners on how to use the SAP provided Gateway Client to test your OData services.

You access the Gateway Client using Tcode /IWFND/GW_CLIENT

We consider the SAP delivered demo service /IWFND/RMTSAMPLEFLIGHT for our use cases.

1. Testing Your OData Service


It is very easy to test ‘GET’ requests using any http browser, but when it comes to test the ‘POST’/’PUT’ requests, there comes the challenge of composing the request body which most beginners get it wrong most of the times. The worst part is that the response you get for a wrongly composed request body rarely tells you what is wrong. Even the error logs don’t get you anywhere. SAP’s gateway Client can make your life so easy and let’s find out how!


1.1 Testing a CREATE

Request Body:  For forming the request body, we will first run a READ request. When I run a query for Travelagency Collection, in the response body, I get URI for each entry.  So I pick up one of the URI and run as below.

Step 1. Do a GET for /sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/TravelagencyCollection('00000055')

Step 2. Once I get the response, I click on “Use as Request” button, which will populate the request body same as the current response.

Step 3.  Now change the values in the request body as required.  You need to change the key value as there cannot be more than one record for a particular combination of a key. In applications where keys are populated by the application, you may leave them as blank. I changed the key value as ‘90000055’ and NAME as ‘Sunshine Travel  New’


Step 4. Change the URI as /sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/TravelagencyCollection

In the above screenshot you can also notice that ‘XCSRF-Token’ header is auto populated so making it easy for you.


Step 5. Change the HTTP method as ‘POST’ and hit F8. You are done! You should get a return HTTP response as “201: Created” indicating a successful Create and also returning the created entity in the response body.


1.2 Testing an UPDATE

Step 1. Same as Step 1 that in the CREATE.


Step 2. Same as Step 2 that in the CREATE. Here you read an entry that you want to Update


Step 3. Here keep the URI as it is. URI should be containing the keys of the record to be updated.


Step 4. Change the request body that got populated, changing non-key properties.


Step 5. Change the HTTP Method as ‘PUT’ Hit F8; you are done. You should get a return HTTP response as “204: No Content” indicating a successful Update. Note: In the sample service above you can update a record which you created. Not the one which already exists.

1.3 Testing a Deep Insert

Hand coding a Deep Insert body is a very tedious job.  Here first you need to execute a $expand query.  I take a different example this time. Now I want to create a Carrier with Flights for that Carrier.  I see that Navigation ‘carrierFlights’ navigates from Carrier to Flights

Step 1.  Run a query with below URI: /sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/CarrierCollection('AA')?$expand=carrierFlights  This will give me Carrier AA, along with all its flight.


Step 2. Hit ‘Use as Request’ button as we did previously.


Step 3. Notice that we have Carrier as well as Flights in the request body. Flights are within the node <inline> and at last you have the Carrier record. Change the keys as required. For example inside the Carrier entry I put a new non-existing ‘carrid’ say ‘ZZ’ and change some other non-key fields. Inside the flight entries, I change the carrid as ZZ as well. You may remove many flight entries and keep one or two as required.


Step 4. Change the HTTP method as ‘POST’ Hit F8, you are done.


Note:  The above example may not run successfully because of Virus scan settings of ES1 (Virus Scan comes into play since CarrierCollection is marked as hasStream=True; Deep insert itself does not need any Virus scan setting). In your system this has to run fine.

2. Gateway Client as a Debugging Tool


Gateway Client can be a very good debugging tool. Go to Tcode ‘/IWFND/ERROR_LOG’ to see all the errors that occurred in your Gateway system. Click on a particular error. In the below pane you see a button called Replay, and select ‘Gateway Client’ there.

This will open the corresponding request in Gateway Client thus allowing you to see the request as well as the response.

3. Gateway Tool as your regression testing tool

Each request you execute on gateway Client can be stored as well. This is similar to a variant in any SAP transaction but with more features.

Step 1. Once you run an operation, you can store the request as below by clicking on the ‘Save’ button as below.

Step 2. Once saved, you can click on the ‘Select’ button (next to ‘Save’) and retrieve your test case.

Step 3. You can store multiple test cases under a Test Group as below. You can set expected status by clicking on the button as shown below.

Step 4. You can run them any point of time in future and ensure that they are running as expected. You can also look at the Request Data and change them as well. After setting the Expected Status, select all requests as click on “Execute” as below.

Note that I have purposefully given a wrong Expected status for demo purpose.


Below is the output after executing

I tried here to highlight the most useful features of Gateway client. Hope it helps in your  development of Gateway services.

12 Comments
Labels in this area