How to handle a binary file in a webmethods REST resource?

[reamon]

For others that come upon this thread, this is one way to support a file POST to wM IS. Using a multi-part form is common but is not the only way. Other content types are possible and often use different variable names in the pipeline.

[v.migot (Vincent Migot)]

Thanks for all your help,

According to the webMethods Integration Server Administrator’s Guide 10.11, there is only some native handler defined on the platform mapped to content types.
Most of them handle structured data files type, I didn’t see any other which can handled a binary stream/file as input.

Here is a short description of each native ContentHandler for others (but Integration_Server_Administrators_Guide is the way to go) :

ContentHandler_Default → contentStream → for text/html content type
ContentHandler_FlatFile → ffdata → for application/x-wmflatfile content type
ContentHandler_IDAT → no idea of the variable name → get an Idata object for application/x-wmidatabin
ContentHandler_JSON → jsonStream → JSON object for application/json
ContentHandler_Multipart → contentStream → Multi Part form which can contain both binary file and data for multipart/**
ContentHandler_RPC → no idea of the variable name → Don’t really know usage application/x-wmrpc
ContentHandler_RPC2 → no idea of the variable name → Don’t really know usage application/x-wmrpc2
ContentHandler_SOAP → soapRequestData → XML SOAP structure for application/soap
ContentHandler_XML → no idea of the variable name → XML object for application/xml

So it seems to me that there is no native way except multipart to handle a binary file which was the subject of this thread.

Apparently you can define/register your own Content Handler and that could be an option but I have no idea how and it’s another subject.

Best regards

[reamon]

The docs about this have historically been a bit sparse. It used to be the FF guide had the best info but that’s no longer the case.

application/octet-stream is a common Content-Type that is used for data that is not one of the others, or for the cases where the specific data type is immaterial. I think that gets placed in the pipeline as contentStream too but I’m not sure.

A technique to see what is done with each Content-Type is to create a service that just saves the pipeline (not to disk), call it, then see what it captured to determine the variable produced. Here are a few:

application/x-www-form-urlencoded → (HTML form - form fields placed directly in pipeline)
application/json → jsonStream
multipart/related → contentStream
multipart/form-data → contentStream - HTML form using MIME
text/html → contentStream
text/xml → xmlStream - I think this is the same for application/xml

[Edit]: Keep in mind that service properties, along with extended settings, will impact how data is passed to the service for some content types.

For any of these, it is sometimes desired to have a “filename”. Hence the typical multipart/** types where one field is the filename and the other is the content. Other fields might be defined too.

As the previous posts in this thread emphasize, be cautious about how “big” data is handled to not load all the data of a big stream into memory all at once.