Solved

REST Call Task Request Body Size Limitation


Userlevel 1
Badge +4

Hello,

 

We are working on an integration with one of our business partners using the BPA workflows offered by IFS Cloud (We are on 23R1). All the logic is in place and is working as intended, but the BPA fails for “large” datasets.

 

We are using the REST Call Task to send a web request to our partner’s API. The request body/payload cannot be stored as a string because when there are many items, the requestBody would quickly exceed the 2000 character limit to be stored in the Oracle database as a string. If it were to be stored as a string, we would receive a persistence layer exception at the end of the workflow.

Instead, we are storing it in a process variable called ‘requestBody’ as an object.

The request body field of the REST Call Task requires a string, so we must convert the JSON object to a string using Camunda Spin: JSON(requestBody).toString() in the task.

This works perfectly for “small“ payloads. However, even though I am not storing the “large” string, it still throws the same persistence layer error at the end of the workflow when a larger payload is sent.

 

Am I doing something wrong? Is there any way around this?

 

I’ve referred to 2000 characters or less as “small” and over 2000 characters as “large” here, but really 2000 is quite small in terms of payload size and, to me, REST tasks lose most of their appeal if there is no way around this limit.

icon

Best answer by kamnlk 10 May 2024, 09:44

View original

3 replies

Userlevel 4
Badge +5

As a workaround there is a way to avoid this character limitation in REST tasks. you need to update the REST task configuration as below 

 

Explanation:

The request body is internally logged in to ifsBpaHttpConnectionBody variable in REST task. this could cause the 2000 character limit for larger payloads. with the workaround we tell to avoid logging this variable thus avoiding this limitation. 

Userlevel 4
Badge +9

@kamnlk  you are a goldmine regarding workflows :-)
Hope all of this can end up in some thorough documentation! 

Thanks for sharing all this knowledge

Userlevel 1
Badge +4

@kamnlk Amazing. Thank you so much! This workaround will save days figuring out and implementing an alternate solution.

Reply