HTTP AAE adapter payload character conversion

[former_member198060]

Hello everybody,

I am using the HTTP AAE adapter in order to send application/x-www-form-urlencoded data. The scenario is file to HTTP.

The file contains XML content, but the receiver expects the content form encoded. This means it should be like key=value&key2=value2&...

How can this be achieved?

I first tried to use the "additional parameters" in the HTTP AAE adapter. But it seems those cannot be filled using dynamic configuration. Is this possible at all or can the additional parameters only be static fields?

Then I did a java mapping which maps the XML into the flat structure. When I do so, the HTTP AAE adapter transforms the "=" and "&" chars into ascii codes in the call adapter step. How can this be avoided so that no conversion of the payload takes place?

Additionally I always have to provide a "main payload field name" as mandatory in the HTTP AAE receiver adapter. This is not wanted as I have all the payload data prepared in the mapping already. Is there a way around? If I uncheck "send form data" then the body is not filled at all.

Any help how to build the form-urlencoded payload dynamically in the HTTP AAE adapter would be appreciated.

[markangelo_dihiansan · Accepted solution]

Hi Peter,

The file contains XML content, but the receiver expects the content form encoded. This means it should be like key=value&key2=value2&...

When using url form encoded, the values = and & get translated to %3D and %26. The set form option should be checked and the content-type should be application/x-www-form-urlencoded. For the main payload parameter, input there the prolog.

By the way, have you tried to do an external http request to the target system and sniff it via an http tool like fiddler? It would be easier if you first execute an successful request externally and then figure out in PI how to replicate the request.

Regards,

Mark

[former_member198060 · Accepted solution]

Hi Mark,

Thank you for the response. Does this mean that the encoding of "=" and "&" when viewing the payload in the message monitor is the correct behaviour?

Actually I have used the Chrome developer tools to check how the payload looks like when actually sending from a form in the browser, there these chars are not replaced.

So we would always need to checkmark the "set form" option and the "main payload field option? What can we do if the prolog and epilog should be empty? My current solution would be to set a dummy key in the prolog and then close it with a dummy value which would be the first part of the payload that I generate in the java mapping before the actual payload begins.

[markangelo_dihiansan · Accepted solution]

Hi Peter,

Thank you for the response. Does this mean that the encoding of "=" and "&" when viewing the payload in the message monitor is the correct behaviour?

Well the actual encoding would be after the call adapter step, I believe you can only see this by using XPI inspector.

So we would always need to checkmark the "set form" option and the "main payload field option? 

Yes, the set form should be checked and there should be an entry in the main payload option.

What can we do if the prolog and epilog should be empty? My current solution would be to set a dummy key in the prolog and then close it with a dummy value which would be the first part of the payload that I generate in the java mapping before the actual payload begins.

I think form values come in name/value pairs, in this case a dummy should work e.g &payload= . Just don't close it, better yet, copy the prolog from the request you see in XPI inspector.

Regards,

Mark

[former_member198060 · Accepted solution]

Hi Mark,

Thank you again for your response.

I have tested the encoding using TCPGW and while the parameters that are added under "additional parameters" appear with "=" and "&", these characters are still escaped into ascii codes for the payload part that was generated in the java mapping. So it seems that the call adapter step actually escapes these characters.

Is there anything that can be done to surpress the escaping or to correct it after the callAdapter step?

[markangelo_dihiansan · Accepted solution]

Hi Peter,

You mean percent encoding? Can you give a screenshot of the final payload?

Is there anything that can be done to surpress the escaping or to correct it after the callAdapter step?

You can try using SOAP Receiver Adapter, just check Do Not Use SOAP Envelope.

Regards,

Mark