Handling HOST HTTP header parameters in REST Adapter

[former_member607207]

Handling HOST HTTP header parameters in REST Adapter. 

We had a unique requirement handled in our client recently which is to pass the hostname in HOST HTTP header parameters in Receiver REST adapter and it is based on our third-party system application design that the hostname is expected in HTTP header in the incoming call.

This document provides the configuration required to post JSON message to RESTFUL webservice that requires HOST HTTP header as mandatory parameter and a solution to fix HTTP Error 415 unsupported media type error from server for Content-Encoding HTTP header.

The document covers 2 sections.

1. HOST HTTP header configuration

 

The third-party system uses Amazon’s API gateway service in private mode, which only allows connections from known interfaces. Here we are trying to communicate to non-publicly exposed endpoint and the HOST header determines how to internally route the request within the service. Rest Adapter by default uses an internal HTTP library which cannot be configured to make call to one host but state in the request HOST header value different host.

 

Hence though HOST value is maintained under HTTP headers tab of the channel the message fails in PI

 

Solution:

SAP has provided feature of changing the used HTTP library to Apache Http Client with SAP Note 2483432-“New Feature: Integration of Apache HTTP Client library”. With the Apache library it is possible to change the HOST header value by using the HTTP Headers tab.

 

Maintain the below module parameter to use new implementation based on Apache HTTP client

 

Parameter: useSAPHttpLibrary

 

Value:  apache

 

 



With above configuration HOST HTTP header was working as expected.

2. Configuration to fix 415 HTTP error code from server

After fixing the above error, we encountered another issue where the target server is responding with 415 unsupported media type error. This is due to the data format which is not supported by the server for the HTTP method used. This can be caused by what is configured in the resource’s Content-Type or Content-Encoding headers in the target server side.

So, ensure proper Content-Type header value is sent. In our scenario, we are posting JSON message hence the value is application/json.

Regarding Content-Encoding, PO by default sends the value as UTF-8 which can be refused by the server (based on target server settings) and the messages will fail in PI/PO server.

To resolve this, use “identity” for Content-Encoding HTTP header which specifies no encoding is preferred.

 



With this additional configuration , we can post JSON message to RESTFUL web service that requires HOST HTTP header as mandatory parameter.