5 Replies Latest reply on Jul 22, 2021 7:00 AM by Chris Ingram

    CAI - Service Connector for REST - sending multipart form

    Chris Ingram New Member

      Hi all,


      I have taken over a process where we need to call a REST API with a 'mutlipart/form-data' payload, however I am not able to get this working in CAI. I think it is because of the very specific setup of the vendor API, but would like some help/guidance. Most likely misunderstanding how this should work so please feel free to correct!


      Due to the nature of the API, the authorisation is done via a number of headers which are taken care of by an authentication process we already have working. We pass these values to the current process as Input to be used in the 'Custom' Authentication. This works well, we have a number of other working API calls using this.


      The problem comes when we want to pass a payload to a specific API. We currently download a file from a different API and store it file (using CAI) before using a custom process to upload it to the API we are discussing here. We want to do this all in CAI. I am trying to develop a process that does the download, holds the file as an Attachment and passes it to this App/Service Connector. I am doing this by passing it as an Input with the type set as Attachment. The Content Type must be - 'multipart/form-data'.


      Now the problems:


      - When I use the Binding Type of 'Form', I get an HTTP/500 error back from the service. I've not yet looked into why that is. I have a feeling it is sending it as 'multipart/form-data' but perhaps sending the other Inputs as well as the attachment?


      - When I use the Binding Type as 'Custom' and try to send in the payload 'manually' (as bellow, $obj_Body being the downloaded attachement), and use the header 'Content-Type {'multipart/form-data; boundary=boundary1234'}', I now get an Unsupported Media type error. I think this is because its sending the actual request with a Content-Type of 'multipart/related' (did find an article suggesting this was the case with Custom binding). Should be noted that I've checked the attachment type via CAI process and it does say the content-type of the attachment is 'application/octet-stream'.


      {"--boundary1234 Content-Disposition: form-data; name='file'; filename='FileName' Content-Type: application/octet-stream "|| $obj_Body || " --boundary1234--"}


      Any ideas what combination of options would get this working. I need to be able to pass in the auth details for use on the custom authentication but not send them in the actual request to the API, just the Attachment as a 'multipart/form-data'


      Current config:


      Below we only want to send the obj_Body to the API as the payload. Other Inputs are used purely for auth headers.



      Service call (in process):


      Service connector: (ticking/unticking parameter seems to make no difference?)




        • 1. Re: CAI - Service Connector for REST - sending multipart form
          Mohammad Khan Seasoned Veteran

          Hi Chris,


          This issue is reminding of a use case I worked on sometime ago where I was able to upload a CSV to an endpoint. Here are the steps I used:


          -Set up a file connection to read the CSV as an attachment. Here is the process I used:



          -Assigned the incoming attachment to a temp field - MyCSVFile of type attachment.


          - Then, used the following expression in the assignment step and assigned it to a field - MyAttachment of type Attachment:


          sff:createAttachmentFromBase64('demo.csv', sff:getBase64FromAttachment($temp.MyCSVFile), 'text/csv')



          -Then passed it to the service call step:



          Here is my service connector looked like:




          Here the Binding Type = Form


          Hope this helps in your use case.




          • 2. Re: CAI - Service Connector for REST - sending multipart form
            Chris Ingram New Member

            Hi Mohammad,


            Thanks for the reply. I think our Service Connector is set up very similarly. The problem appears to come from the fact that we need to be able to pass in some authentication tokens that change each session (Cookie, X-CSRF and auth token) and when we add these Inputs to the Service Connector, it tries to send them as part of a multi-part body along with the file we actually want to attach.

            I have a call with a Principal Cloud Consultant from Infa today, so hopefully they will clear it up for us. I have a feeling at present there is no way to achieve what we want in CAI, so maybe they will add the features to give us more control in the future. I hope they have some kind of workaround though. We currently have a PowerShell script that can do the API call outside of CAI (and called by CAI) but this is not ideal.

            • 3. Re: CAI - Service Connector for REST - sending multipart form
              Mohammad Khan Seasoned Veteran

              Hi Chris,


              While uploading an attachment to an endpoint,  what I have seen is that the service connector request usually contains <rest:header name="Content-Type" value="multipart/form-data"/>. This header is currently not supported in a service connector and thence the request fails. The use case I described in my earlier post is kind of a workaround to resolve this issue.


              Since you are already in touch with an Informatica consultant, hopefully, you will find a solution for your use case.




              • 4. Re: CAI - Service Connector for REST - sending multipart form
                Prakash Jain Guru

                Hi Mohammad , Chris,


                This was resolved after comparing the request raw payload using request bin. We saw the file attachment attribute name the API was expecting was "file". Once we made that change the issue was resolved.




                Prakash Jain

                • 5. Re: CAI - Service Connector for REST - sending multipart form
                  Chris Ingram New Member

                  Prakash indeed managed to get it sorted with some investigation using Postman and request bin. Such a simple fix in the end. All working well now in the full process chain.

                  Perhaps should raise a feature request to get CAI to show us the raw payload/request in future