Integration Gateway: How to access external headers from script

[CarlosRoggan]

This blog is about Integration Gateway (IGW) in SAP Mobile Platform 3.0 (SMP).

Setting a header is a simple way of sending a piece of information together with the HTTP request to the backend. It can be used e.g. in order to  influence the data that is requested.

In the present document, we'll learn how to access these headers.

Overview

Internal headers

External headers

Create sample service

Test the sample service

Summary

Links

Internal headers

When implementing a custom script in Integration Gateway, you know that you can access the list of headers from the message object:

var headersMap = message.getHeaders();

To access a specific header:

var uriInfo = message.getHeaders().get("uriinfo");

Or the short way:

var destinationName = message.getHeader("destinationname", java.lang.String);

Note that the headers that can be accessed via this way is only a predefined set of headers, not customizable.

Which are these headers?

Let's check it out.

A simple code example:

importPackage (com.sap.gateway.ip.core.customdev.logging);

var headers = message.getHeaders();

var it = headers.keySet().iterator();

while (it.hasNext()) {

     var headerKey = it.next();

     var headerValue = headers.get(headerKey);

     log.logErrors(LogMessage.TechnicalError, "===> Header: " + headerKey + "===> Value: " + headerValue);

}

An example for the result output:

===> Header: uriinfo===> Value: com.sap.gateway.core.ip.odata.OGWUriInfo@13219024 |

===> Header: destinationname===> Value: null |

===> Header: odatamethod===> Value: GET_FEED |

===> Header: odatacontext===> Value: org.apache.olingo.odata2.core.ODataContextImpl@b93e696 |

===> Header: contenttype===> Value: application/atom+xml;charset=utf-8;type=feed |

===> Header: scriptfiletype===> Value: javascript |

===> Header: destinationconfiguration===> Value: null |

===> Header: breadcrumbid===> Value: ID-WDFN32187496A-53657-1451915633531-31-3 |

===> Header: functionname===> Value: getFeed |

===> Header: camelredeliverycounter===> Value: -1 |

===> Header: scriptfile===> Value: HelloSet_SCRIPT.js |

Note:

In the above example, the headers “destinationname” and “destinationconfiguration” don't have values.

But they do have, if a destination has been assigned to the service (in the Admin frontend of the SMP server).

For example:

===> Header: destinationname===> Value: MYRESTSERVICE

===> Header: destinationconfiguration===> Value: com.sap.gateway.core.api.destination.configuration.HttpDestinationConfiguration@15e5ef03 |

Note:

The header “contenttype” defines the format how the data is interchanged between Integration Gateway framework and the script.

It has nothing to do with the “external” contenttype-header, which can be set when executing a request to our OData service.

With other words: you can invoke your OData service and specify that you want the payload to be presented in e.g. json format. But nevertheless, the data that is exchanged between Integration Gateway and your script can be passed as xml.

External headers

We have to distinguish 2 communication steps:

1. Consumer calls OData service
   The consumer can be a mobile application, a web page, or a REST client (which we use while testing).
   The consumer communicates with the SMP server and the call is handled by the OData library (Olingo) which is part of SMP
2. OData service connects to a backend
   This part is handled by Integration Gateway, which acts as integration component.
   Depending on the specified binding (designtime) and destination (SMP), it connects to the backend to retrieve the data.
   For us service-implementors, it is possible to extend the automatic capabilities by writing custom script.
   All information we need is encapsulated in the message object which is passed to us as method parameter

The headers that are part of the message object contain objects that allow access to the “external” world (as explained in 1. above), via API provided by Olingo: These objects can be trtrieved via the headers uriinfo and odatacontext.

The interface UriInfo allows access to the URI of the ODataService, as it has been invoked by the consumer.

The interface ODataContext provides access to context information of the invoked OData service.

So the detailed steps to access the external headers are:

1. Retrieve the ODataContext object

2. Use it to retrieve the external header

// the internal headers (sent by the framework)

var headersMap = message.getHeaders();

var odataContext = headersMap.get("odatacontext");

// the external headers (sent by consumption application, e.g. mobile phone)

var outsideHeadersMap = odataContext.getRequestHeaders();

// this (custom) header is defined by us and has to be passed by application or in REST client

var valueList = outsideHeadersMap.get("<myCustomHeader>"); // this method returns a java.util.List<String>

var value = valueList.get(0);

The same can be achieved in one line:

var value = message.getHeader("odatacontext", org.apache.olingo.odata2.api.processor.ODataContext).getRequestHeader("<myCustomHeader>");

Create sample service

I’ve prepared a little dummy service to try out what I’ve explained above.

The simple OData model:

The entity set is bound to the “Custom Code” data source.

The getFeed() method is implemented as follows:

function getFeed(message){

    importPackage(java.util);

    // first get the self-defined external header

    var value = message.getHeader("odatacontext", org.apache.olingo.odata2.api.processor.ODataContext).getRequestHeader("operatingsystem");

    // do some dummy reaction to the value of our custom header

    var response = "";

    if (! value){

        response = "Operating system info must be set!"

    }else if(value == "iOS"){

        response = "Hello iPhone!"

    }else if (value == "Android"){

        response = "Hello Android Phone!"

    }else {

        response = "Unknown operating system."

    }

    // build the usual message stuff

    var responseMap = new HashMap();

    responseMap.put("ID", "1");

    responseMap.put("Response", response);

    var responseList = new ArrayList();

    responseList.add(responseMap);

    message.setBody(responseList);

    return message;

}

This little piece of code does the following:

It checks the header that is passed to the service and depending on the value, the service returns a different text in the feed response.

Test the sample service

When testing the OData service, we use a REST client, execute a GET request to the entity set and pass the self-defined header with name operatingsystem and different values.

As the code above shows, the values can be either "iOS" or "Android".

The value can be invalid, it can even be missing.

The following screenshot shows how to test our sample service using a REST client:

Summary

Use the following line in your custom script, to access the value of a header that is passed to your OData service by the user

var value = message.getHeader("odatacontext", org.apache.olingo.odata2.api.processor.ODataContext).getRequestHeader("<myCustomHeader>");

Links

Installing SMP toolkit

Tutorial for Integration Gateway

Tutorial for Understanding CUSTOM CODE data source Part 1: implementing read operations

The series of tutorials about the REST data source. Contain lot of scripting examples