X

It's All About the Platform.

Caching REST Service Data in Oracle Sales Cloud

Guest Author

Introduction

This blog article is about how the ETag value can be used in conjunction with the If-None-Match HTTP header parameter to cache web content between a client application and Fusion Applications RESTful web services.

When developing integration code between a client application and the Fusion Applications RESTful interface it's important to keep the data on the client updated as much as possible without unnecessarily using network bandwidth resources

Fusion Applications REST services can be utilized by different types of devices including mobile where data , battery and CPU usage are at a premium and efficient use of all three is important. The ETag value and If-None-Match HTTP header parameter provide a mechanism by which only new or updated content is downloaded to the client application.

ETag HTTP Header

The Entity Tag, also known as the ETag, is a unique id that represents a version of a resource. When a client application makes a request for a resource the first time the ETag is sent in the header as a response.

To keep the client application updated with the latest data, the client application would need to periodically resubmit a HTTP request for each of the resources, that without caching, would then re-download the latest version of each resource whether it's different or not. Clearly an inefficient waste of resources on both the client and server applications.

However, by using the same polling mechanism and by sending the ETag in the header, only content that has changed will be returned in the response. If the content has not changed then a HTTP status code of 304 Not Modified will be returned instead. The ETag is the id that is used by the web application to verify what version of the resource is held by the client and whether it is old or not.

In a custom object in Oracle Sales Cloud it is generated from the Last Modified date. When a custom object data record is updated, the last modified date will also be updated which would mean a new ETag for that row of data. If the custom object is updated using REST then the ETag would also be returned in the body of the response after the update to the custom object has been submitted.

If-None-Match HTTP Header

The If-None-Match header field is described in rfc7234 as:

A request containing an If-None-Match header field (Section 3.2 of [RFC7232]) indicates that the client wants to validate one or more of its own stored responses in comparison to whichever stored response is selected by the cache. If the field-value is "*", or if the field-value is a list of entity-tags and at least one of them matches the entity-tag of the selected stored response, a cache recipient SHOULD generate a 304 (Not Modified) response (using the metadata of the selected stored response) instead of sending that stored response.

In other words the If-None-Match parameter makes the HTTP response conditional based on it's value which in this case is the unique ETag. It's requesting that the application only return the http body content if the content has changed. Otherwise send back a HTTP status 304. Not Modified response.

Oracle Sales Cloud example

The following example shows how the ETag has been implemented in Fusion Applications. Here are the HTTP headers for a GET request for a custom object in Sales Cloud.

GET /crmCommonApi/resources/latest/contacts/35063 HTTP/1.1
Host: crm-<FA_ENVIRONMENT>.oracleoutsourcing.com
Content-Type: application/vnd.oracle.adf.action+json
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1dC
  I6ImctdnBaYjZTb2lKS1lubER1NUd2SEYwYWFTayJ9.eyJleHAiOjE0NzU2OTE
  wMzgsImlzcyI6Ind3dy5vcmFjbGUuY29tIiwicHJuIjoicGV0ZXIubWFub2hhc
  mFuQG9yYWNsZS5jb20iLCJpYXQiOjE0NzU2NzY2Mzh9.BY4LBdAdz7rD5b0RBk
  3ZB5E4Vd_LP2p9iFBlHJlz8ehE5f6TdWvRxvPWKPX4oFpD56yCa4s-KqYXjCKM
  2N6Utb9shq9TUdrYqfawl_WUjBmATf93Sq72O31aMRf70NOT9-w-JkSGbILdJ6
  CSCIRGbwI6GFhTAu3Irg2u5ba3rYo

The above headers show how we retrieve a contact object with id - 35063. It's a GET request and therefore has no body in the request. The response headers are below with the ETag in bold:

Cache-Control →no-cache, no-store, must-revalidate
Connection →keep-alive
Content-Encoding →gzip
Content-Language →en
Content-Length →1715
Content-Type →application/json
Date →Tue, 04 Oct 2016 13:07:31 GMT
ETag →"ACED0005737200136A6176612E7574696C2E41727261794C697374788
1D21D99C7619D03000149000473697A6578700000000877040000000A73720011
6A6176612E6C616E672E496E746567657212E2A0A4F7818738020001490005766
16C7565787200106A6176612E6C616E672E4E756D62657286AC951D0B94E08B02
00007870000000077371007E0002000000057371007E0002000000027372001B6
F7261636C652E6A626F2E646F6D61696E2E4E756C6C56616C75655899C1C58DAA
BEEB02000149000A6D53514C54797065496478700000000C71007E000871007E0
0087371007E00020000000171007E000878"
Link →;rel="self";kind="item";name="contacts"
Location →
Server →Oracle-Application-Server-11g
Vary →Accept-Encoding
X-ORACLE-DMS-ECID →005FWayCfGh3r273VJnJB80001VE000Sx1

As you can see from the header the ETag is returned in the response. The HTTP status code is 200.

To check if the content has been changed by another user before downloading it again, the ETag is placed in the request header in the If-None-Match parameter. Here are the headers that would be used when checking for a new version of the contact:

GET /crmCommonApi/resources/latest/contacts/35063 HTTP/1.1
Host: crm-<FA_ENVIRONMENT>.oracleoutsourcing.com
Content-Type: application/vnd.oracle.adf.action+json
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsIng1dC
  I6ImctdnBaYjZTb2lKS1lubER1NUd2SEYwYWFTayJ9.eyJleHAiOjE0NzU2OTE
  wMzgsImlzcyI6Ind3dy5vcmFjbGUuY29tIiwicHJuIjoicGV0ZXIubWFub2hhc
  mFuQG9yYWNsZS5jb20iLCJpYXQiOjE0NzU2NzY2Mzh9.BY4LBdAdz7rD5b0RBk
  3ZB5E4Vd_LP2p9iFBlHJlz8ehE5f6TdWvRxvPWKPX4oFpD56yCa4s-KqYXjCKM
  2N6Utb9shq9TUdrYqfawl_WUjBmATf93Sq72O31aMRf70NOT9-w-JkSGbILdJ6
  CSCIRGbwI6GFhTAu3Irg2u5ba3rYo
If-None-Match: "ACED0005737200136A6176612E7574696C2E41727261794C
  6973747881D21D99C7619D03000149000473697A6578700000000877040000
  000A737200116A6176612E6C616E672E496E746567657212E2A0A4F7818738
  02000149000576616C7565787200106A6176612E6C616E672E4E756D626572
  86AC951D0B94E08B0200007870000000077371007E0002000000057371007E
  0002000000027372001B6F7261636C652E6A626F2E646F6D61696E2E4E756C
  6C56616C75655899C1C58DAABEEB02000149000A6D53514C54797065496478
  700000000C71007E000871007E00087371007E00020000000171007E000878"
Cache-Control: no-cache

The HTTP response code to the above request is HTTP status 304 Not Modified as the ETag has been validated by Oracle Sales Cloud to be the same as the latest version. Since only headers are sent back and forth in this request the CPU, data and power use are more efficient compared with unnecessarily downloading the unchanged resource again.

The functionality described in this article should be useful to anyone integrating between a client application and Oracle Fusion Applications to optimize performance of both the client application and Oracle Fusion Applications pod by reducing the overhead of unnecessary requests for data from Oracle Fusion Applications.

Further Information

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha