Focal Point
[CLOSED] How to work with multi-part form post data

This topic can be found at:

September 05, 2014, 10:22 AM
[CLOSED] How to work with multi-part form post data
For various reasons we are using an HTTP post to send data, including an attachment, to our iSM channel. We can see the file is being sent in the message body, as expected, but as the message is a multi-part form request we're struggling with how to properly isolate just the attachment to work with it. Are there any guides on how to do this or anyone who can point us in the right direction? Thanks!

This message has been edited. Last edited by: Tamra,

iWay 7.0.0, Linux
September 08, 2014, 08:05 AM
Hi Keith

Welcome to Focal Point.

We will wait to see if anyone responds to your request from the Focal Point Forum members and then determine what action to take. Usually within 3 days if there has been no response we will request that you open a case with IBI at InfoResponse Online Information Builders Techsupport

Thank you for participating in the Focal Point Forum.

Kindest regards,
Tamra Colangelo
iWay Focal Point Moderator

WebFOCUS 8x - BI Portal, Developer Studio, App Studio, Excel, PDF, Active Formats and HTML5
September 15, 2014, 04:38 AM
Use the Preparser:
Multi Part For NHTTP in your Inlet
Use XDAttachmentToDocAgent Agent in your pFlow to get the Attachment.

September 24, 2014, 09:20 PM
The XDMultiPartForNHTTP preparser is not recognizing the attachments in the POST body. The example in the documentation has the Content-Disposition listed as attachment, but in our POST request it's form-data. We have our XDAttachmentToDocAgent setup and tested using the attachment number, which didn't work as it didn't think the message had an attachment, and we tried using the Content-ID, but our POST request doesn't have a Content-ID so we used the name of the parameter containing the zip file.

Our attachment is being treated as a String and writing the output to a file is an XML file and not as a zip file. We have Keep Message Flat set to true, so why is it converting our zip file into an XML of a large string? Is there something we need to do to get the XDAttachmentToDocAgent to identify the attachment? FYI, there will only ever be one attachment in the request. If the Content-ID is not in the request are we up the creek? We do not have control over the request.

Here's some raw output showing an error during the attachment capture:

<?xml version="1.0" encoding="UTF-8" ?>
<error timestamp="2014-09-25T02:16:22Z" code="6" stage="AGENT" source="com.ibi.agents.XDAttachmentToDocAgent">
Attachment number too large: 0<data type="base64">LS0tLS0tLS0tLS0tLS0tLS0tMzE0MTU5MjY1MzU4OTc5MzIzODQ2DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7

This is what it translates to:

Content-Disposition: form-data; name="file"; filename=""
Content-Type: application/octet-stream; charset=ISO-8859-1
Content-Transfer-Encoding: binary

PK9E	agile.xmlUMo0W>mYNZ4"KZ@
2Lߏv|5i;"ߣHZfE=>Zҋkr;/9/TSᄇpm/s2,RcV)@.54?	R*/HPJIg̵@X@\.=Z`"ڳR
~0rjI*64	h4<NÎmsY8(Pa?Hs[4L9c
,#1ZG)+Pk(	jWS07yT8֔c?
[rH[k{li7PKU:EFPK9EU:EF	agile.xmlPK7}
Content-Disposition: form-data; name="AgileRecordLocator"
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit


This message has been edited. Last edited by: keithrust,

iWay 7.0.0, Linux
September 25, 2014, 09:30 AM
I do hope you are nHTTP as your listener type. The preparser "Multi Part For NHTTP" is configured with all its preoprties left as default. The XDAttachmentToDocAgent should be configured for the following properties:

Attachment number: 0
Keep document Flat: true [if XML is your in-line content, use XDToXML later to XMLise]
Delete Attachment: true [if not needed any further]

If you are facing problems at multi part stage, then paste the error relevantly.

September 25, 2014, 10:28 AM
Yes, we are using nHTTP as the listener and the error message is in my previous post:

Attachment number too large: 0

iWay 7.0.0, Linux
September 26, 2014, 03:48 AM
stage="AGENT" source="com.ibi.agents.XDAttachmentToDocAgent">

The error is reported at XDAttachmentToDocAgent not at Multi-Part separation failure. If the multi-part separatoin fails you should find a separate entry in logs.

September 26, 2014, 11:51 AM
The preparser didn't fail, but it didn't find the attachment either, which is the problem.

1 09:43:45.846 W.aXMLTestHttp.1 adding preparsers 'com.ibi.preparsers.XDMultiPartForNHTTP' at index 1
2 09:43:45.846 W.aXMLTestHttp.1 loading preparser com.ibi.preparsers.XDMultiPartForNHTTP input form 3
3 09:43:45.847 W.aXMLTestHttp.1 Run NHTTP Worker
4 09:44:39.722 W.aXMLTestHttp.1 ***left in buffer? 1241
5 09:44:39.723 W.aXMLTestHttp.1 storing bytes in orgdata-- length is: 1241
6 09:44:39.725 W.aXMLTestHttp.1 POST method invoked
7 09:44:39.727 W.aXMLTestHttp.1 TID not found, so creating it as 823ef3e5-49ee-4128-bae8-045913a490e6
8 09:44:39.727 W.aXMLTestHttp.1 setupWorkerState: initializing timers and XA log entry; not streaming.
9 09:44:39.731 W.aXMLTestHttp.1 hasContent found empty XML document
10 09:44:39.760 W.aXMLTestHttp.1 Router selected default for in_reviewer
11 09:44:39.760 W.aXMLTestHttp.1 Router selected default for eda:control
12 09:44:39.760 W.aXMLTestHttp.1 Router selected default for *
13 09:44:39.761 W.aXMLTestHttp.1 Router selected default for in_transforms
14 09:44:39.761 W.aXMLTestHttp.1 Router selected default for eda:control
15 09:44:39.761 W.aXMLTestHttp.1 After analysis: bytes: length 1241
16 09:44:39.762 W.aXMLTestHttp.1 now: 2014-09-26T15:44:39Z expires: 2014-09-27T15:44:39Z
17 09:44:39.762 W.aXMLTestHttp.1 Router selected default for pflowloc

iWay 7.0.0, Linux
September 26, 2014, 12:09 PM
It appears that the preparser fails in this case. Try raising a case in tech support for this case.

Update: I think the reason it is failing is due to the missing 'multipart' in the Content-Disposition. I would suggest that try & handle the Content Disposition header at the client side.


This message has been edited. Last edited by: Srii,