Test the CREATE Service
Exercise 3: Extend a Generated Gateway Service to Include Update Functionality
Exercise Objectives
After completing this exercise, you will be able to:
• Extend the Gateway service created in the previous exercise to include create and update functionality.
Business Example
You need to provide a Gateway service that provides not only Bank look up information, but allows users to create and edit Bank information.
Log on to the Gateway training system using the userid and password supplied to you by your trainer.
Whenever you need to create a new model or class, always append your group number to the name to ensure the name remains unique.
All ABAP development is being done using the package $TMP (Local Object) In order to complete this exercise, you must first have successfully completed Exercise 2 – Generating a Read-Only Gateway Service.
Testing the functionality added in this exercise will be performed using the RESTClient add-on installed in the Firefox browser.
Task:
1. Edit Your Existing Gateway Data Model 2. Get UPDATE XML using a READ Operation 3. Prepare the UPDATE Operation
4. Prepare the CREATE Operation
Solution 3: Extend a Generated Gateway Service to Include Update Functionality
Task:
1. Edit Your Existing Gateway Data Model
a) Run transaction SE80 (ABAP Development Workbench)
b) Select “GW Data Model” from the drop-down list and the name of your Data Model should appear in the input field.
If it does not, you can construct the name using the following pattern:
Z_GW100_RFM_BANK_<nn>_0001_PS where <nn> is your group number.
c) When the object hierarchy is displayed, double click on the root node (the GW Data Model name). This will display the Data Model’s properties on the right side of the screen. In addition to showing the object’s properties, a “gear wheel” icon will appear in the toolbar.
Clicking this will take you to the Gateway Mapping Service Tool.
Figure 160: Gear Wheel Icon d) Switch to change mode.
e) Press the binoculars icon and search for BAPI*BANK*.
f) First, select the BAPI_BANK_CHANGE function module and click the Create Mapping toolbar button on the right side of the screen.
Figure 161: Create Mapping
Continued on next page
g) The mapping tool pop-up window now opens.
Select “Update” from the drop down list.
Figure 162: Update
h) As soon as this selection is made, the mapping tool automatically exposes the RFM’s two key fields to the OData interface, but does so using their existing field names.
However, we have already nominated the BANK_CTRY and
BANK_KEY fields belonging to the QUERY and READ operations to be the Data Model’s key fields.
Therefore, you must correct the mapping of these two fields to point to the model’s key fields:
BANKCOUNTRY → BANK_CTRY BANKKEY → BANK_KEY
The field mapping should now look like this
Continued on next page
Figure 163: Mapping Route
Hint: Remember: right clicking on the field selects it without switching off the selection check box.
i) Deselect all non-mandatory parameter fields and structures.
The second check box column indicates whether a parameter is mandatory or not.
j) When we created the READ operation, we needed to map each field in the BANK_ADDRESS data structure to the Data Model’s root node.
Without this step, we would have had to make a second HTTP request in order to retrieve the data within this data structure.
The normal sequence of processing steps is that a user will first perform a READ operation, modify the data, and then perform an UPDATE operation.
In order to allow the data coming out of the READ operation to be passed into the UPDATE operation, we must ensure that the BANK_ADDRESS fields belonging to the input side of
BAPI_BANK_CHANGE are mapped to the same Data Model fields that the READ operation populates.
For each field in the BAPI_BANK_CHANGE’s input data BANK_ADDRESS do the following:
1. Right click on the field name to select it without switching off the selection checkbox.
2. Click “Change Mapping Route”
3. In the pop-up window, map the RFM field to the corresponding Data Model field name directly under the root node.
4. Press the green tick icon in the bottom right of the screen to complete the mapping.
Your mapping screen should now look like this:
Continued on next page
Figure 164: Mapping
k) From the list of function modules on the left of the screen, select BAPI_BANK_CREATE, press the Create Mapping button and map it to the Create operation.
l) Repeat the mapping process described above, being careful to check that:
1. The input fields BANK_CTRY and BANK_KEY are mapped to the model key fields of the same name.
2. All the fields in the BANK_ADDRESS input structure are mapped to the model fields below to the root node.
3. The output fields BANKCOUNTRY and BANKKEY are mapped to the data model directly under the root node. These fields are not used in our scenario, but since they contain the key values of the Bank we have just created, should be kept for the sake of completeness.
4. All other non-mandatory RFM interface fields are deselected.
Your mapping screen should now look like this:
Continued on next page
Figure 165: Mapping m) Generate the model.
2. Get UPDATE XML using a READ Operation
a) In the SE80 display of your GW Data Model, expand the “Related GW Consumption Models” branch and double click on the consumption model name.
b) In the properties view to the right, copy the service document URL to the clipboard.
Figure 166: Service Document URL
c) Start Firefox and paste your Gateway Service Document URL into the address line. Edit the URL to perform a QUERY request (i.e. display the collection of banks).
Continued on next page
d) Choose a bank from the collection and copy the URL in its
<atom:id>tab into the clipboard. This is the URL for a READ request of that particular bank.
e) Start the RESTClient from the Tools menu in Firefox. A new tab will open.
Figure 167: RESTClient
f) Paste the URL for the READ request into the RESTClient’s Address line and add the query string ?sap-ds-debug=true.
g) Press the “Add Request Header” button in the RESTClient toolbar.
h) Add the variable name X-CSRF-Token and a value of Fetch. Neither of these values are case sensitive.
Figure 168: X-CSRF-Token / Fetch
i) Check that the HTTP method is set to GET and press Send.
j) Copy the XML from the “Response Body” section at the bottom of the screen to the “Request Body” in the centre of the screen.
3. Prepare the UPDATE Operation
a) Since the previous READ request was issued with the query string parameter sap-ds-debug=true, we received detailed debugging information. This can be seen by selecting the “Rendered HTML”
section in the RESTClient and clicking on the SAP icon in the bottom right of the screen.
Continued on next page
Figure 169: Rendered HTML
b) Select the Response tab in the popup window.
Figure 170: Response Tab
Copy the x-csrf-token value to the clipboard.
c) Close the debug popup window and double click on the word Fetch in the Response Header section. Paste in the x-csrf-token value.
d) Add a new HTTP Header variable:
Name: Content-Type
Value: application/atom+xml;type=entry
Continued on next page
e) Make sure that the query string parameter sap-ds-debug=true has been deleted from the URL. If you leave this query string parameter in the PUT request, the UPDATE operation will not succeed, but you will still receive an HTTP 200 OK status code in return.
f) Change the HTTP Method to PUT.
g) The XML returned from the READ operation cannot immediately be used for the UPDATE operation; it needs to be edited.
The header line <?xml
version="1.0" encoding="UTF-8"?>should be kept (but the UPDATE operation will succeed without it).
h) The entire <atom:entry> element must be kept, including all the namespace parameters.
i) The <atom:category> tag can be deleted as it serves no purpose for an UPDATE operation. However, leaving in the XML will not cause any problems.
j) The <atom:content> and <m:properties> tags start the elements that will contain all the bank details. These must not be removed.
k) There now follows an element for each property belonging to a Bank.
<d:street>1060 West Addison St</d:street>
<d:bankcountry m:null="true"/>
<d:bank_name>Bank of the Blues Brothers</d:bank_name>
Continued on next page
You must ensure that:
• All empty elements are explicitly set to have a null value. See the values highlighted in red above. This requirement applies only to Gateway 2.0 SP3. In SP4 and later, the requirement to specify m:null=“true”will be relaxed.
• The values of bank_ctry and bank_key should not be altered, as these are the key fields.
• You change the values of those fields to be updated.
l) Then follows the two tags </m:properties> and
</atom:content>. These must not be deleted; otherwise the XML would no longer be well formed.
m) The tags <atom:id>, <atom:link>, <atom:title> and
<atom:updated>can be deleted as they serve no purpose for an UPDATE operation.
n) Send the request and look for an HTTP Status Code of “204 No Content” in the “Response Header” section.
Figure 171: Status Code: 204 No Content 4. Prepare the CREATE Operation
a) Remove the key predicate (highlighted) from the URL used for the UPDATE operation. The key predicate is used to identify and existing entry within a collection. Since we are creating a new bank entry, this part of the URL is no longer necessary
z_gw100_rfm_bank_01Collection(
bank_key='021800089', bank_ctry='US')
b) Change the HTTP Method to POST
c) The HTTP Header fields used for the UPDATE operation are also needed for a CREATE operation, so you do not need to touch these values.
The X-CSRF-Token will remain valid for as long as the browser session remains open.
d) The XML used for the UPDATE operation has the same structure as the XML needed for a CREATE operation.
Continued on next page
Therefore, we will use this XML as our starting point.
<?xml version="1.0" encoding="utf-8"?>
<atom:entry ... namespace parameters snipped ... >
<atom:content type="application/xml">
<m:properties>
<d:street>1060 West Addison St</d:street>
<d:bankcountry m:null="true"/>
<d:bank_name>Bank of the Blues Brothers</d:bank_name>
</m:properties>
</atom:content>
</atom:entry>
At the very least, the only values that need to change are the key values. In the example above, a new bank_key value has been supplied (highlighted in red).
e) Send the request and look for an HTTP Status Code of 201 Created.
Caution: Remember! If you get an HTTP Status Code of 200 OK, then the create operation was not successful.
Figure 172: HTTP Headers
The Location field in the HTTP Header gives the URL you can issue to perform a READ operation on the newly created bank.
Lesson Summary
You should now be able to:
• Extend an existing RFM or BOR based Gateway Service to include update functionality.
• Understand the danger posed by Cross-Site Request Forgery attacks and how the SAP NetWeaver Gateway Server prevents them.
• Test the new functionality of your Gateway Service from a browser.
Unit Summary
You should now be able to:
• Create a read-only Gateway Service based on a Remote Function Module or an Object in the Business Object Repository (BOR).
• Expose a Gateway Service for consumption.
• Test your Gateway Service from a browser.
• Extend an existing RFM or BOR based Gateway Service to include update functionality.
• Understand the danger posed by Cross-Site Request Forgery attacks and how the SAP NetWeaver Gateway Server prevents them.
• Test the new functionality of your Gateway Service from a browser.