Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.


Focal Point    Focal Point Forums  Hop To Forum Categories  iWay Software Product Forum on Focal Point    [CLOSED] How to work with multi-part form post data

Read-Only Read-Only Topic
Go
Search
Notify
Tools
[CLOSED] How to work with multi-part form post data
 Login/Join
 
Member
posted
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
 
Posts: 5 | Registered: September 04, 2014Report This Post
Guru
posted Hide Post
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
 
Posts: 487 | Location: Toronto | Registered: June 23, 2009Report This Post
Silver Member
posted Hide Post
Use the Preparser:
Multi Part For NHTTP in your Inlet
Use XDAttachmentToDocAgent Agent in your pFlow to get the Attachment.

-
Srii
 
Posts: 38 | Registered: April 13, 2012Report This Post
Member
posted Hide Post
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,


iWay 7.0.0, Linux
 
Posts: 5 | Registered: September 04, 2014Report This Post
Silver Member
posted Hide Post
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
 
Posts: 38 | Registered: April 13, 2012Report This Post
Member
posted Hide Post
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
 
Posts: 5 | Registered: September 04, 2014Report This Post
Silver Member
posted Hide Post
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
 
Posts: 38 | Registered: April 13, 2012Report This Post
Member
posted Hide Post
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
 
Posts: 5 | Registered: September 04, 2014Report This Post
Silver Member
posted Hide Post
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,
 
Posts: 38 | Registered: April 13, 2012Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  iWay Software Product Forum on Focal Point    [CLOSED] How to work with multi-part form post data

Copyright © 1996-2020 Information Builders