This blog is a continuation of blog part-1 which focuses on making an Initial call to the Authorization server and retrieving the initial tokens and storing them in the HCI data store. Almost everything discussed in this blog part-2  refers to the objects discussed in part-1.

Here we will discuss on how, we check the validity of the existing token and making a request for the new token using a refresh token.

As soon as the request is received in HCI, data store operation “Get”  retrieves the tokens from HCI data store “code_hashmap” with entry ID as “” ( refer part-1 to see how to store the tokens in XML format ).

Condition //access_token != “” will be evaluated to true as we have the Initial tokens in the data store and the sub flow to check the validity of token is triggered.

Subflow: Validity of Existing Token and Calling Refresh Tokens
This subflow is used to compare the system time and the expiry time. When the validity of the existing token is not valid anymore, another subflow “Fetch new access token based on refresh token” is called.

Content modifier is used here to put all the elements of the message from the data store in to the Properties section of the subflow which are further used in script and following steps.

The following script evaluates whether the initial access token is still valid.

function processData(message) {	
	map = message.getProperties();
	var etime = map.get("expires_in");
	var edate = map.get("expiry_date");	
//Calucuate the expiry date and time 	
	var expiry = new Date(edate);
	var currentdate = new Date();
//set indicator to start new flow to fectch new token	
	if(currentdate > expiry){
		message.setProperty("refresh", "X");
	return message;

from the content modifier, we get the value of  following properties expires_in = 21917 and expiry_date = 2016/10/10 . The date is converted to seconds and the seconds from expires_in is added together. This is further evaluated with the current time and finally when the current time exceeds the expiry time, we set the property “refresh” with value “X”.

Route : Refresh token: Fetch New Access Token Based on Refresh Token.
This subflow to fetch refresh token is quite straight forward. Using content modifier
the content of body of the message is made empty and unwanted Properties are deleted.

Using HTTP receiver adapter, a call is made to the authorization server REST API with query parameter refresh_token=${property.refresh_token} which returns a JSON with new access_token , again a new refresh_token along with validity of the access_token.

In above flow the username and password is hardcoded for simplicity. As an alternate, we could deploy secure parameter artifacts for username & password. Then get them via JS script and set them to properties and finally refer them in the HTTP adapter query.

Using the response JSON from the above API call, subflow “Step1a: Get Products from Hybris based on Initial tokens”( refer part-1 of this blog to see how this is implemented) is called which converts the JSON into XML and stores it to the data store “code_hashmap” which is further retrieved in eventual calls.

Route: Valid Token ( default route)
When the access_token is still valid, the same access_token is put into the HTTP header key “Authorization” using the below JS script.

function processData(message) {
	var body = message.getBody();
	map = message.getProperties();
	var access_token = map.get("access_token");
	message.setHeader("Authorization", "Bearer "+access_token.toString());
	return message;

Finally the product search REST API in Hybris is called to get the products.

This ends the part-2 which is mainly focused on authorization tokens. In the next blog here, I will share how we could use variables in the Address URL (request path).

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply