cancel
Showing results for 
Search instead for 
Did you mean: 

HTTP POST Query string part of URL and not in Body

ankur_agarwal
Explorer
0 Kudos

Hello experts,

Here are few details.

PI system : 7.4 single stack PI

Scenario  : Idoc - PI - Http (OAG for order acknowledgement)

If you have a closer look at the OAG requirements above, especially at the link

The important point to note is the header fields are part of the body.

This is where i am facing the issue when using the HTTP_AAE adapter. The adapter configuration are as below.

And then the encoding type is specified as : application/x-www-form-urlencoded

On advanced tab, Header details are emplty

For query parameter, message id is there and then quiet a few additional query parameters

like

TRANSPORT_PROTOCOL=OXTA

TRANSPORT_PROTOCOL_VERSION=1.0

REQUEST_TYPE=SEND

MESSAGE_ID=XXXXXXXXXXXXXXXX

MESSAGE_TYPE=XML

MESSAGE_STANDARD=OAG

TRANSACTION_TYPE=POACKPO

TRANSACTION_SUBTYPE=POACKPO

DOCUMENT_NUMBER=

PARTYID=XXXXX

PARTY_SITE_ID=XXXX

PROTOCOL_TYPE=HTTPS-OXTA

PROTOCOL_ADDRESS=

USERNAME=userID

PASSWORD=password

PAYLOAD=ACKNOWLEDGE_PO_008

Idoc is converted to xml using xslt transformation.

Now with all this, the http out has all the query parameter as part of URL and not in body.

Due to this I am getting error as Payload Null.

One of the solution is have the query parameters in body, in which case there is not place holder for the payload like ACKNOWLEDGE_PO_008 in this case. See the file image below.

The file looks like this

Read SHOW_SHIPMENT_005 as ACKNOWLEDGE_PO_008 in pic below

My query is how to achieve this in HTTP_AAE adapter to move the query parameter into body.

thanks

ankur.

Accepted Solutions (1)

Accepted Solutions (1)

markangelo_dihiansan
Active Contributor
0 Kudos

Hi Ankur,

Technically speaking, this part of the format


TRANSPORT_PROTOCOL=OXTA&TRANSPORT_PROTOCOL_VERSION=1.0&REQUEST_TYPE=SEND&MESSAGE_ID=0ahd6a007nvji90r00004igq&MESSAGE_TYPE=XML&MESSAGE_STANDARD=OAG&TRANSACTION_TYPE=PO&TRANSACTION_SUBTYPE=ACK&DOCUMENT_NUMBER=PO_1234&PARTYID=1619&PARTY_SITE_ID=1619&PROTOCOL_TYPE=HTTPS-OXTA&PROTOCOL_ADDRESS=&USERNAME=&PASSWORD=&PAYLOAD

is called the prolog. It would still be a part of the HTTP Body and not HTTP header field . I think your entry for the main payload name should be the screenshot above (sorry I don't have 7.3/7.4 to test). But if the value is too long, you could always use a Java/XSLT mapping to build the HTTP Body.

Regards,

Mark

ankur_agarwal
Explorer
0 Kudos

Hi Mark,

Thanks for your reply,

The method had good potential but unfortunately, the whole body part undergoes encoding (application/x-www-form-urlencoded) after that and all & and = in query part are replaced by %26 and %3D lead to response "Bad request". No escape sequence in the encoding format to prevent this.

In general, post method sends query parameters in body (securely), I wonder why the adapter not doing that by itself or has a option to make that happen.

thanks,

ankur

markangelo_dihiansan
Active Contributor
0 Kudos

Hi Ankur,

I see what you mean now, the content-type escapes the query into percent encoded characters. The older HTTP adapter on the Abap stack has the option to disable URL escaping but I do not see that option on the HTTP Java adapter.

Configuring the Plain HTTP Receiver Adapter - Integration Engine - SAP Library

You could try raising your issue to SAP

Regards,

Mark

ankur_agarwal
Explorer
0 Kudos

Hi Mark,

Thanks for your reply again,

well even if that was in place, it wouldn't be preventing the escaping of whole document, while here is only want it on the part i have put in the field "Main Payload Paramenter Name".

Currently the file looks like this.

Seem no matter how i build the body, the encoding will change the query parameter in any case, since masking is not enabled. even if java mapping is used. What's your opinion.

thanks,

ankur

markangelo_dihiansan
Active Contributor
0 Kudos

Hi Ankur,

I guess you have no other choice than to use an adapter module to re-encode the escaped characters.

Regards,

Mark

markangelo_dihiansan
Active Contributor
0 Kudos

Hi Ankur,

Perhaps it would be better for you to just use the SOAP Adapter. The reason for this is that in the Java HTTP Adapter, the content-type (http adapter bean) will be applied after your custom module. With the SOAP Receiver adapter running in no-soap mode, there is no option to manipulate content-type unless you use MessageTransformBean. Ideally, you want the HTTP Body to be escaped and then re-escape the query using the adapter module So the ordering of the modules will be MessageTransformBean -> Customized Adapter Module -> SOAP Adapter Bean.

Regards,

Mark

Answers (0)