Manipulate content header attributes via config (without Java Mapping)?

[george_credland]

I'm trying to send a "multi-part" message using the Advanced http adapter. Its actually a simple single part message but the receiver forces multi-part message structure.

The output is very close to what's required, but the sample code from the supplier shows filename with ".xml" extension, and instead PI

is hard coding "MainDocument" in "Content-Disposition" and suppling header attributes "Content-Type" and "content-id"

Is it possible to dynamically remove these use dynamic config rather than having to write a java mapping for the entire message. They're being set via the communication channel rather than coming from the payload.

Also to remove the "encoding" attribute on the XML declaration line?

I'm using PI 7.4 SP13. Whilst the PI message is technically correct with these, the receiving system doesn't recognise the content, failing with "Internal Server Error". I'm also in touch with the third party support, but it'd be great if its possible to close/narrow the gap in what I'm sending.

[george_credland]

Sorry I didn't get any help with the original problem and ended up re-writing the data distribution as I couldn't get the adapter to adequately format the mime header such that the target API would accept it. That was six years ago.

[laxman_molugu]

Hello,

From the above example : CONTENT-DISPOSITION: form-data; name="hrfeed"; filename="feed.xml"

Is there any way I can pass a XPATH or payload data for filename attribute? instead of a static "feed.xml" how to pass a data from the payload using XPATH or Dynamic Config etc?

[george_credland]

Apparently "Content-Disposition" can be re-written by deselecting the "Set Form" tick box on the HTTP_AAE channel, and adding the "MessageTransformBean".

Module Parameter=Transform.ContentDisposition

Module Value=form-data; name="hrfeed"; filename="feed.xml"

produces CONTENT-DISPOSITION: form-data; name="hrfeed"; filename="feed.xml"

Its forcing the attribute to upper case, but http headers are case insensitive according to the specifications.

Just need to find a way to remove "Content-Type" and "content-id" from the MIME header.