Creating a rest service that accepts uploaded image as multipart/form-data

I am using WM v10.5.

I want to create a rest service that accepts the image uploaded as form-data/multipart. I went through the MIME services that helps us create and use MIME-DATA object and use it further for extracting the body content and process on it. However I am not able to get anything as an input which I can pass as contentStream into the MIME services.

I am trying to upload an image “sampleImage.jpg” with key as image as a formdata-multipart file.

I am using createMimeData service to create a mimeData document object, this service expects an input object and i am not getting anything (stream or bytes or any kind of data) in pipeline which I can map with the input of createMimeData flow service and when further I use getBodyPartContent to extract the details of uploaded image I am getting value as null in content object.

So how to get the image uploaded as form-data/mulitpart in esb as stream/bytes or any other kind of data ?

Hi @Jay_Bhanushali ,

There is no support for multipart/form-data file upload for rest invocations in WebM 10.5. We have introduced this in 10.11. Would suggest you give it a try?

Thanks,
Sree

Hello @Sreekanth_Siddapur_Channakeshava ,

I am afraid we cannot upgrade to 10.11 as of now, is there any alternative how can we recieve the data and in what form(tsream, bytes) in pipeline for multipart/form-data for image upload ?

Hi @Jay_Bhanushali,

When you send any input parameters of unsupported types, you will find them in the service pipeline as a content stream because IS will create a stream object for that. You can trace your pipeline and check that the stream object is coming. You will have to write custom logic to get this stream converted back to the required type. Please give it a try and let me know if it worked.

Thanks,
Sree

Something like this
[698]2022-05-31 15:49:31 IST [ISP.0090.0002C] (tid=95) — END tracePipeline —
[697]2022-05-31 15:49:31 IST [ISP.0090.0008C] (tid=95) 0 contentStream {com.wm.net.HttpInputStream} = ‘com.wm.net.HttpInputStream@30d0fd0f’
[696]2022-05-31 15:49:31 IST [ISP.0090.0008C] (tid=95) 0 output {java.lang.String} = ‘Sucecss’

Hey @Sreekanth_Siddapur_Channakeshava below are the trace logs :

Also one more things I can observe is I think when I am hitting the service via postman the data comes in pipleine in stream however I am not able to get anything if try to debug the flow service.

Hi @Jay_Bhanushali ,
Invocation from Postman is different and invocation from Designer is different. When you invoke from Postman you wouldn’t be able to debug anything in Designer as the request from postman would go directly to Integration Server. If you are invoking the service from the Designer, then you would get it.

Thanks,
Sree

Hi @Jay_Bhanushali - if you are still looking for sample, let me know. I have a sample I can share.

Hello @Sreekanth_SC So my assumption earlier was correct, while I hit the request from postman my code is working fine where the data is coming into pipeline as stream whereas when I try to debug the same I am not getting any data in peipeline which is making the development difficult for me. Do you have any solution how can we get the multipart/formdata file sent through postman in Designer in DEBUG mode ?

Hello @srikanth.prathipati1803 Currently I am able to use the MIME inbuilt flow services for manipulating the incoming multipart/formdata request based on assumption of mapping the input stream to MIME flow services, I am not able to debug the incoming request(in the form of multipart/formdata as stream) as I want to place some validations on the incoming data, so if you have any such example/way on how to debug the multipart/formdata request in Designer then please do share it.

Hi @Jay_Bhanushali - contentStreams are hard to debug from designer. One work around could be design the API to accept base64encoded string instead of image stream. This is a common approach lot of consultants use to manage attachments within the APIs.

I respectfully disagree with using base64 Strings, you are introducing a lot of overhead and potentially compromising the platform if you do this. Streams are more efficient and ensure that you don’t use too much memory. Obviously, You cannot debug them using the save/restore pipeline. However, you can do something similar, write the stream to a file in the first line of your service. The disable the line and add add a readFile to get back the stream. Then you can run through the debugger as you wish.
regards,
John.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.