Consuming Gateway OData service with OData adapter

Introduction

OData is everywhere these days in SAP’s plethora of products. In fact it is the key enabler for the Fiorification of SAP’s ecosystem backed by SAP NetWeaver Gateway.

From an integration perspective, inevitably OData-based integration will come be a common requirement. SAP released an OData Adapter few years back, however content around it is few and far in between compared to its more popular cousin, the REST adapter.

This blog post covers the use of the OData receiver adapter to consume a NetWeaver Gateway OData service. While one would have expected that such design to be straightforward, there are a few tweaks required (as usual, buried deep in some SAP Note) to get it working right.

This post assumes that the reader interested in reproducing such a scenario has solid fundamentals in PI development, and therefore some of the more basic steps/tasks are not included here. The focus will be on the additional effort required to make it work for a Gateway OData service.

Prerequisite

The Operations Modeler is required in order to generate the ESR definitions for the OData service. This will require an Eclipse installation with HCI plugins. Refer to the following for the installation details:-
SAP HANA Cloud Integration Tools

Design and Configuration Steps

Step 1 – Find a Gateway service
Before we begin, we will of course need an existing Gateway OData service. For the purpose of this example, I will use the existing UserService available in a Gateway system. Following is the screenshot of the corresponding ICF entry in the system.

This service can be tested in a REST client. In the following screenshot, this service is called from Postman, where it displays the 3 available collections of the service.

Step 2 – Generate the definition for ESR using HCI Operations Modeler
How to Model Successfactors SOAP and ODATA Entities using Eclipse Juno Tool provides more details on the usage of the Operations Modeler. In this post, I will zoom in directly on the relevant section.

After launching the Operations Modeler, provide connection details to the Gateway service.

Select the entity, in this case UserCollection.

For this example, the scenario will be configured to perform a dynamic query. As such, select the Query(GET) operation, and select all the available fields.

Proceed with the default options in the following screen until the end of the wizard. Then, the following window will be provided to indicate that the corresponding XSD for the GET operation has been generated. It can be found in the src.main.resources.wsdl folder as shown below.

Back in the channel configuration screen, the Operation Details will be populated. Of particular importance is the ResourcePath field which will be used in the later configuration step.

Step 3 – Develop the ESR content

We now proceed to develop the relevant design objects in ESR. In order to perform a dynamic query call, we need to use an SAP-provided XSD available in the CONNECTIVITY ADD ON SWCV. The details are further elaborated in the blog How to Use OData Adapter with Dynamic Query Calls as well as SAP Note 2052093.

First of all, import the XSD generated in the above step. This will act as the definition for the response message.

For the request, the provided XSD as mentioned above will be used.

Following is the definition for the Inbound Service Interface.

On the outbound side, we will expose the interface as a synchronous SOAP web service. Therefore on the outbound side, the following Data/Message Type are developed.

Definition for sender request – a single input field for the user ID.

Definition for sender response – all the similar fields as provided by the OData service.

For the mapping of the request message, the QueryStringOptions message will be mapped so that the filter field will dynamically filter the username based on the input ID. It uses the standard OData filter functionality (for more details, check OData URI conventions). The outcome of mapping for the field will be as follows:-
filter = username eq ‘<ID>’

The response mapping will be just a 1-1 mapping from the response of the OData service to the SOAP response definition.

Step 4 – Configure OData receiver channel

Lastly, we can configure the OData receiver channel referring to the following SAP Library link.

In the General tab, use the address to the UserService for the URL and provide basic authentication details.

For the Processing tab, we will select QUERY as the Operation. Now we will use the Resource Path that was generated in Step 2. However, the query parameters will be changed so that it uses the dynamic filter value populated during mapping. For the payload format, we can optionally switch to JSON in order to benefit from the smaller payload as compared to Atom-XML.

Now, for the final, and most important part of the configuration. We need to configure the following additional parameters in the Advanced settings tab.

Firstly, dynamicQuery = true is required to enable mapping based dynamic query as mentioned by SAP Note 2052093 above.

Secondly, ContentTypeEncoding = none is required when consuming Gateway OData service. This is mentioned in SAP Note 2317362. Without this setting, the OData generates additional charset details in the Accept HTTP Header (which by the way is incorrect IMHO when I read the HTTP 1.1 spec – Accept-Charset should be used instead). This additional charset details causes the Gateway service to fail when being called, resulting in an HTTP 406 error with the following error message:-

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request

Step 5 – Testing the interface
Ok, finally with all the design and configuration completed, we can proceed to test this out. After generating the WSDL for the scenario and importing it into SoapUI, we can test this out by sending a simple request message consisting of the user ID. The response from the OData service provides the details of the user ID.

Conclusion

As demonstrated above, with a few tweaks here and there (no thanks to cleverly hidden SAP Notes!), it is possible to configure PI’s OData adapter to consume a Gateway service. While it is also possible to Expose Gateway Services from SAP Process Orchestration, without the use of PI interfaces, there might be requirements they need to be configured/developed as PI interfaces.