Sending attachment as multipart in connect REST not working
Hi,
I need to transfer a document from Pega to an external system through Connect REST as multipart/form-data.
I have gone through all the threads on community that talk about this topic (there are quite a few already). I have followed all the steps mentioned in those threads and in the Help:
- Creating a page pyRequestAttachmentPage of class Data-ServiceMessage
- Set properties .pyAttachNames(1), .pyAttachValues(1), .pyAttachTypes(1) and .pyAttachFileNames(1)
- The POST Request part in my Connect REST is empty as I just need to send the document and nothing else.
Attached is the debug traces when invoking the connector created. We can clearly see that it found pyRequestAttachmentPage when preparing the request, but the file field is empty and as it is a mandatory field, the service is returning "Parameter 'file' required" error message.
Isn't Pega supposed to populate that field automatically with the multipart data or have I misunderstood the way it is supposed to work?
Anything wrong or missing in this approach?
Any known issue (and therefore any available fix) on this part?
*** this is urgent as we have to implement this as part of a PoC with a propsect next tuesday***
Thanks
Riadh
***Edited by Moderator Marissa to update SR Details***
Accepted Solution
IRIZ Consulting
FR
Thanks Paul, you were right. Using tcpmon helped viewing the exact content of the http request raw data. I could see there was no "file" parameter indeed but had to figure out on how to specify it using the pyRequestAttachmentPage page and its properties. The .pyAttachNames(1) property is actually the one which should contain the name of the param and not the name of the attachment. This is the one I had to set to "file" in my case for instance.
Here is how I set the different properties in pyRequestAttachmentPage:
.pyAttachNames(1) = "file"
.pyAttachValues(1) = property containing the binary file stream
.pyAttachTypes(1) = "pdf"
.pyAttachFileNames(1) = name of the file + extension
Another example was with Alfresco which was expecting the same integration to transfer documents but was expecting the document to come within a form data field called "filedata". So just had to do the same passing "filedata" in .pyAttachNames(1).
Pegasystems Inc.
US
I would not take the logging of ----HTTP REQUEST CONTENTS----- as a good representation of what the outgoing message looks like. Pega uses an underlying API to formulate the request and then fires it. This logging is a representation of what Pega can show from the level above the api.
A good approach here is to employ TCPMon - set the endpoint in Pega as the listening port of TCPMon and have this utility forward the request onto the actual endpoint (or just dump it). The point here is that TCPMon will show you the raw data of what the request looks like leaving Pega.
If the request contains the file - yet, the service endpoint is replying with Parameter 'file' required, you'll need to show them the message. It might be something like Transfer-Encoding needs to be set.
Something in your logs that is making me think the file is attached is the size of the outgoing message.
Request Message Data: 178175 bytes to be sent
Accepted Solution
IRIZ Consulting
FR
Thanks Paul, you were right. Using tcpmon helped viewing the exact content of the http request raw data. I could see there was no "file" parameter indeed but had to figure out on how to specify it using the pyRequestAttachmentPage page and its properties. The .pyAttachNames(1) property is actually the one which should contain the name of the param and not the name of the attachment. This is the one I had to set to "file" in my case for instance.
Here is how I set the different properties in pyRequestAttachmentPage:
.pyAttachNames(1) = "file"
.pyAttachValues(1) = property containing the binary file stream
.pyAttachTypes(1) = "pdf"
.pyAttachFileNames(1) = name of the file + extension
Another example was with Alfresco which was expecting the same integration to transfer documents but was expecting the document to come within a form data field called "filedata". So just had to do the same passing "filedata" in .pyAttachNames(1).