Flatfile over HTTPS - using args for filename

, ,
1

In one of our integration our partner wants to send the Flat File data over HTTPS. To know the message type (possible of different message type sent in FF format), we have requested them to send the File Name over arguments & the data over the body of the http post. With file name we will be able to differentiate the message type and post to TN accordingly.

Before proceeding further, thought of verifying this flow by simulating at webMethods and faced some issues.

Using pub.client:http, we tried sending the file name in HTTP service under “data/args/FileName” and the actual data under “data/string”. On receiving service side, we are getting the file name under proper variable ‘FileName’ but data was not received in “ffdata” Inputstream; We even have the “headers/Content-Type” specified as “application/x-wmflatfile”. Is it something we have to do differently in receiving the data sent over the body of the http post instead of using “ffdata”?

Just to verify we have removed the “data/args/FileName” on http service and sent only the data over “data/string”. Now on receiving side service, we were getting the data properly over the “ffdata” stream. Is it something where the receiving side behavior should be different when the http post happens with arguments on the URL?

FF to be sent from source system will be around 20 MB. Will there be any limitation if we ask them to send this over another argument like “data/args/messageData” instead of body of the http post?

2

You’re mixing GET (URL parameters) and POST (body) techniques which is probably not a good way to go. You won’t be able to send the file contents via URL argument as URLs have a length limit.

You might consider following RFC 1867 which is a common way to transmit file data using an HTML form. In this approach, the content-disposition header of the file content will contain the filename. Or you can explicitly define a form field to have the name. You could also define other form fields to assist with processing.

The downside is I’m not sure how large document handling might impacted by this approach.

Another possibility is to pass the filename in the content-disposition header.