Hi Killian,

I am. O11 components can’t be installed in ODC. 

But I couldn’t find the forum section for that one.

When a discussion is opened on this forum it asks the version (ODC/O11) 

Regarding my actual issue, is the JSON format of the request the problem?

"400 Bad Request" is as vague an error code as you can get. However, judging the "OS-BERT-00000" error code, the error is OutSystems-generated? And if so, what REST service are you calling? If it a REST service that's also exposed by OutSystems software?

This is the format for error codes in ODC..I know..

I’m calling an external vendor API

Ok, I'll ask around as my ODC knowledge is limited.

Hey Killian,

Any leads/ideas? 

Best,

Lorena

Not quite, but I was googling the error message you have, and OS-BERT-00000 means that the REST API has sent the 400 error. E.g. here you can see that that may be because there are missing parameters, or the message is otherwise malformatted. So make sure you set the "id" and "uploadType" besides the "file" in the request you send.

Hey Killian,

Everything is setup and not empty: 

The file part has the attribute name set to "file" here in PartAdd:

I can't see what am I missing, but it's still 400.

I explicitly wrote "so make sure you set the "id" and "uploadType" besides the "file" in the request". So did you do that? Did you also add a part for the id, and a part for the uploadType?

Hi @Lorena Sabou ,

How big is the file you are trying to use with the multipart component?
The component in ODC is taking advantage of "custom code" that currently has a limit of 5.5MB of payload size.
https://success.outsystems.com/documentation/outsystems_developer_cloud/getting_started/outsystems_system_requirements_for_odc/#custom-code

Regards,

Hi Killian,

This is why I screenshotted the first part. ClaimItemId is a URL param and I was showing that it’s not empty. uploadType is written correctly in the json and not empty.

I only added PartAdd for the file type.

Hey Joao,

0.2 MB 

Joao,

One question about the limitation you exposed. Isn't custom code referring to C# code integrated in the platform? 

This is a REST API. How does this fall under the "custom code" area? 

Best,

Lorena

Hi @Lorena Sabou ,

My bad, you are correct. The custom code (C#) is used when creating the Parts that will then be sent to the external API.

I incorrectly thought the error could be there, but it seems you are able to generate it properly, so it has nothing to do with the custom code.

I saw on one of your screenshots that you are manually generating the boundary.
Could you try not setting any value so that a boundary is automatically generated instead?

Regards, 

Hi Joao,

I tried with the default GUID boundary as well, same result…

Best,

Lorena

Were you able to get this integration to work outside of the platform, for example, using Postman?

Looking at the documentation you provided, it says that it has the uploadType as mandatory. 

Do you happen to have an example payload that you can share?

Joao, 

Going back to the size limitation for one sec. I should expect a size limit of 5mb because of the usage of PartAdd?

Because I need a size limit of 20MB.

Thanks,

Lorena

Payload:

In ODC I can't see the integration logs anymore as in O11 to consult the exact json that was sent, but I'm thinking the format of the API (JSON) is the problem, or the fact that we don't have anymore the content-type in multi-part attribute. In O11 as far as I've seen (didn't work with that particularly), you were able to set the type of the request -  https://success.outsystems.com/documentation/11/integration_with_external_systems/rest/consume_rest_apis/consuming_a_rest_api_with_a_multipart_or_form_data_method/

In that article I also found this interesting:

That is the case. 
The "PartAdd" is behind the scenes doing a binary concat using custom code and has a limitation of 5.5MB of total payload.

Regards,

João,

If that's the problem here, then I wouldn't expect a 400 sent from the other system? Or is the 5.5MiB limit enforced, but no error generated? Regardless, a 5.5MiB limit is all but useless for modern implementations, is there something in the near future we can do to increase this?

Ah, I see. I didn't take a good look initially at your screen shots. If you want to send a multipart/form-data formatted message, you cannot use JSON like that. It's possible one part may contain JSON, but what you send to the REST API is just plain JSON, where you send a "file" attribute that contains a binary formatted as multipart/form-data. That's not how it works!

A multipart/form-data formatted message must contain a multipart/form-data formatted body only. It cannot contain anything else. So the uploadType must be a part, not part of some JSON.

EDIT: See e.g. here for an example of a request. As you can see, "username" has its own part, a part that only contains the data of that username. You need to do the same for uploadType. (Also note the attribute may be case-sensitive, in which case you shouldn't name it "UploadType", as you seemed to have done.)

Hi Killian,

That's exactly what I kept asking above: is the format of the request set to "JSON" as correct? Regarding "UploadType" I shared a screenshot where I explained that in JSON it's correctly set to camel case, but in the structure it's pascal case because that's how we setup the project.

Now, I have set the request like this:

Set the parts:

The result is still 400 bad request. What am I missing? 

Best,

Lorena

For a first test, since note is optional, I'd leave it out entirely. I'm also not sure whether you can send more than one note, it's not in the specification. Also, since uploadType is listed first in the specification, I'd add that part first. And I'd use "application/octet-stream" as MIME type instead of "image/png".

Hi Killian,

The note can be only one. I removed that part.

I updated the file content-type as application/octet-stream.

Same result...

*I tried uploading several file types - image, pdf, excel. All the same.

Kind regards,

Lorena Sabou

Damn, I'm running out of ideas here. Did you test with Postman or SoapUI or the like, to see if you can send anything valid outside of OutSystems?

I feel you.. 

Yeah of course.. with multipart I get 201:

With JSON 400:

As a reminder, the request in OS is now set to binary:

I keep thinking the issue might be here. But I can't put neither JSON, neither Form URL encoded, or plain text...

Yeah, Binary is the right format to set.

What's interesting is that in Postman, you can see an additional error code that is sent by the system. It would be interesting to get that in OutSystems as well. I'm just not too familiar with ODC. In O11 I would either look in the Integration Logging (with increased log level), or use On After Response to set the result code to 200 (to prevent an exception), and add a JSON output for those error field.

First option is not available in ODC. When I look in traces, all I see is the call made, without any details on params and response, as it was the case of full logging level in O11. Due to that, I moved the call to the frontend temporarily to see the actual API fail. 

I will do the OnAfterResponse trick, let's see. Thanks for the idea!

Ok, I did it. The error is the same as in the JSON case of postman 

Ok, that's weird, that would mean that the 'file' part is missing, even though you add it.

I noticed you do not use the Parts input for the PartAdd action. I would advise you to do that, as PartAdd addes the new part to the previous ones. That way you don't need the ListAppend(All)s. You can then use the last PartAdd's output as input to MultiPartFormDataCreate. Also debug to make sure all the parts are in the list that you supply to MultiPartFormDataCreate.

Hi Killian,

The result is very interesting. I get now: no parts present.

I basically assigned in PartAdd, in the Parts param, the PartsList local var that I created.

This is what you were referring to, right?

What do you think?

Best,

Lorena

The PartsList should chain through output and input of the Next. So if you have, say, PartAdd1, PartAdd2 and MultiPartFormDataCreate, PartAdd2 should receive PartAdd1.PartsAdded, and MultiPartFormDataCreate should receive PartAdd2.PartsAdded. As such, you don't need the local parts list.

Hello,

I am aware of everything you mentioned above. I know the options and I’m trying to make option 1 work because it would have been much faster than 2. 

What special characters are you referring to?

Thanks,

Lorena