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,

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

Use the Preparser:
Multi Part For NHTTP in your Inlet
Use XDAttachmentToDocAgent Agent in your pFlow to get the Attachment.

-
Srii

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" ?>
<eda>
<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
IG5hbWU9ImZpbGUiOyBmaWxlbmFtZT0iVE8tMDAwMDAwMDM0OTk1MDI1ODIxODMwNzg2NDE2LnppcCINCkNvbnRlbnQtVHlwZTogYXBwbGljYX
Rpb24vb2N0ZXQtc3RyZWFtOyBjaGFyc2V0PUlTTy04ODU5LTENCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJpbmFyeQ0KDQpQSwMEFAAI
CAgACxI5RQAAAAAAAAAAAAAAAAkAAABhZ2lsZS54bWzlVU1v2zAMvfdXGD5twBJZTlo0hqoiS1qsQNoajYcNu6kynQiz5UyS6/bfj3bcfDXADt
1pO5ki36P5SFpml89F7j2BsarUFz7tB74HWpap0osL/2ty3Tv3LzkbL1QOU+GEh3BtL/ylc6uIkLqu+6URMoe+LAtSw2NW5ikY4kAuNbi6ND8J
UsgqL0gYUEqCEfHXSaJnq/YS1QPMtUBYQMn329lcLqEQPaWtE1rClpX+mYVgqyLb2rNSCteqe0/R3nvIAgvrY+E+P2GTpdALuDfIsV6l1a8Kbl
DRWRAE0RkdhmEw8jmblDiTWCyAs7uqeATDJwgIB4x0RzZ3wlWWP0AOwkLKSOfoXpC8rIBfTe4Z2Tmzb1hdlpc1n0Imqtx566C3LoeRTZzdG7VQ
WrjS8HFaKK2sM83pk9fugvdBNN6PjOwAGW4IvJ4h5Sh/2AtGPUqTMIwGpxENfjByAGpJryo2lPA0CWg0PI9Ow46ygaCibXPGWQYS09w4KFD7F2
E/A+gHSHOl0Vs0oEzkFhg5GmMNsWtpTLHFwWDIyI6TjZ0TclmAdnYv3Rs/uxW6yoR0lQGzB30bYDHo5hNbt38/8bFQIyy25lDPxtXKmIKVRq2a
XefJ1TxZ69j1srlygG0i3fMO6gd44hS3am2xmcJ+vuB2x0tsNo8N5ArnLMwLIwcxxFpHKb8rm1BrstgoCftqtp5X0VOQuTDtN3lU+ds464bWlL
5jHgz/7+/CP7EK4/n0+n9bheZySOoSA1tr9+LFe5hs/mn85DdQSwcIVZ86RUYCAAAGBwAAUEsBAhQAFAAICAgACxI5RVWfOkVGAgAABgcAAAkA
AAAAAAAAAAAAAAAAAAAAAGFnaWxlLnhtbFBLBQYAAAAAAQABADcAAAB9AgAAAAANCi0tLS0tLS0tLS0tLS0tLS0tLTMxNDE1OTI2NTM1ODk3OT
MyMzg0Ng0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSJBZ2lsZVJlY29yZExvY2F0b3IiDQpDb250ZW50LVR5cGU6IHRl
eHQvcGxhaW47IGNoYXJzZXQ9VVMtQVNDSUkNCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDhiaXQNCg0KQUFBdDhRQmR2Y1VBQUM2VEFDVz
M1UUFnUlRKRFJVVkNORGMwTWpBeU5EbEJPRUkxTWtZd1JrVXdRakpHT1VGRVFVVT0NCi0tLS0tLS0tLS0tLS0tLS0tLTMxNDE1OTI2NTM1ODk3
OTMyMzg0Ni0tDQo=</data>
</error>
</eda>

This is what it translates to:

  
------------------314159265358979323846
Content-Disposition: form-data; name="file"; filename="TO-000000034995025821830786416.zip"
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
ת{O{c>?a7ȱ^կ
nPYa098X,x'tG6wU?@BH^_M9oX]5B&y렷.MPZqZ(3A4ޏn!(F=J0
~0rjI*64	h4<NÎmsY8(Pa?Hs[4L9c
kiL`ȎrYvv/?ʄt}`1[?P#,PʘF]<Yrm"xjm~vKl6
,#1ZG)+Pk(	jWS07yT8֔c?
[rH[k{li7PKU:EFPK9EU:EF	agile.xmlPK7}
------------------314159265358979323846
Content-Disposition: form-data; name="AgileRecordLocator"
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit

AAAt8QBdvcUAAC6TACW35QAgRTJDRUVCNDc0MjAyNDlBOEI1MkYwRkUwQjJGOUFEQUU=
------------------314159265358979323846--

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

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.

-
Srii

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

quote:

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.

-
Srii

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

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.

-
Srii

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