Skip to main content

Hi experts,

We have outbound integrations that are triggered based on the ticking of a checkbox. 
 

 
One integration runs when the check box is ticked (Let’s say IntA). Another one (IntB) is run when unticked. Both are connected to synchronous transactional business rules. So if the integration succeeds, the ticking/unticking gets saved successfully.

IntB works fine. But IntA runs into the following error,
 


On the web client when the same is done, the error is a bit misleading,
 


Now, despite the error the integration actually works. If the user refreshes the screen and says ‘No’ to the “Do you want to save changes ?” message, the checkbox is ticked and the integration run log shows that it’s gone through.

Upon checking the time taken for both the integrations I observed the following,

IntA



IntB




As you can see, IntA takes signifacntly more time as opposed to IntB. So I feel like this long interval causes the database transaction to time out and hence the error? If this is indeed the case, is there anything that can be done to prevent the timeout (like an app param setting) ?

following are already set to 120 from the default 60 (may not be relevant to this),


 

Hi @Miraj ,

This might not be a straight forward answer but my suggestion would be to check the server log first by raising the exception log level to 9 and BR level to 6 with the activated BRs and integrations. If you are continuously observing the error “row(task) was changed after it was selected” , or in other words what we call this as an optimistic lock error in FSM in the log, then this is something which you need to look into with the implemented BRs. The optimistic lock errors may lead the application server into transactional concurrency issues with timeouts. Just validate whether you have the task table updated with XML BR to update the same record that is causing the rules to fire over and over again in which case you might need to convert the XML rules into value BR.

 


Reply