Following on from my previous post , I show how to post multipart form data . This is the last in a series that compares BizTalk and Azure integration solutions with a restaurant API.
Multipart form data
To begin with, posting purchase order acknowledgements (POA’s) and invoices to the API requires a “multipart/format data” payload. See this link for technical information about this encoding. A typical request looks like the example shown below.
Nick Hauenstein describes how to use the BizTalk WCF-WebHttp Adapter to post form data here. Unfortunately this only covers the case where the Content-Type header has a value of “application/x-www-form-urlencoded”.
Moreover, we require a “multipart/form-data” Content-Type header and this contains a series of parts. Each part has a content-disposition header where the disposition type is “form-data”. Furthermore the disposition contains an additional parameter of “name”. Finally the XML payload is appears just before the boundary is closed.
My BizTalk Solution
Firstly a FTP receive adapter retrieves a generic order from an ERP system. Subsequently context based routes and maps the message to a GS1 order on a WCF-WebHTTP send port. Notably this send port sends the form data to the restaurant API.
Next let’s consider options to create the form-data HTTP request. Three options that spring to mind are;
- Create a flat file schema and use a flat file assembler in a pipeline. This is an extension of Nick’s approach above. I rejected this because but requires a bit more work to set unique boundaries for the part and add the XML message. Later on I will show that this pattern appears to be the only option if you want to do this in a logic app.
- Create a WCF custom behaviour that does the same thing as pipeline. I rejected this for similar reasons.
- Use a MIME encoder in a custom pipeline to create the multipart message. Not withstanding my biggest question was would the API accept a MIME annotation.
In my first attempt, configuring a MIME pipeline encoder with 8bit ContentTransferEncoding on WCF-WebHTTP send adapter generates a request that looks like this;
Consequently this request returned a 400 bad request error because the Content-Disposition header was not correct. Adding the BREPipeline Component to the pipeline , as shown below, yields enough effectivity to manipulate the message to stop this error occurring.
Executing the following rule in the BRE pipeline component gives the desired multipart/format-data body as shown.
Lastly after setting the correct Content-Type and boundary header properties the request is accepted by the API invoice endpoint for validation.
In summary the BizTalk solution to post form data to the restaurant API uses a custom pipeline to create the custom encoding. In particular the MIME encoder pipeline component creates the base multipart message and the BRE Pipeline component make sure the correct content-disposition header is set.
Logic App solution
Surprizingly, I could not find the equivalent of a MIME encoder in the Logic App actions. The accepted solution is to construct the body in code as shown here. Indeed I tested this in a simple logic app shown below and the desired HTTP request can be generated.
Notwithstanding this is very simple and there is a lot of work still to do, for example creating unique boundary id’s in each request. Nevertheless it can be seen how we could construct a logic app alternative solution to our BizTalk solution. I think it would look like this;
Unfortunately I have not been able to get the FTP trigger action to work yet and therefore have not been able to finish this example. Furthermore there is more work to do to map the flat file XML to a GS1 order.
I think I have finally found a case where the a Logic App solution is harder to do than a BizTalk solution.
Conclusion
BizTalk server can post a form data using the MIME pipeline component and the BRE pipeline component. At first sight this is much more difficult to do using Azure Logic Apps.
