Run microflows subsequently (or other solution to not roll back full microflow)
What is the best practice for running a microflow after another? The situation is as follows: We have webshop A Middleware B (Which is mendix/us) ERP system C Webshop A shoots an order into the middleware (B) via a webservice call, this order should then be ''forwarded'' to the ERP system (C) (also via a webservice) as soon as possible. So A sends order to B B sends order to C If I put all these actions in 1 microflow (so the WS call from webshop A also puts the order into the ERP via the webservice). This however would cause problems if webservice C for whatever reason would not function and the order would not be entered into the middleware. I think I can handle this in multiple ways but I'm not sure which is the ''best'': Just poll every x time (30s/1m) for ''new'' orders and sent these to the ERP and mark them ''handled'' or something like that Handle A-B and B-C in one microflow and set error handling to ''no rollback'' and manage it accordingly Somehow start a new microflow. So when A-B is finished B-C should kick in (and if B-C fails then A-B should not be rolled back).
Niels van de Sande
It all depends on your requirements and how much effort you want to put in it.
do you want to be able to resend requests from your middleware?
do you have timeouts that you have to deal with concering the response to Webshop A?
how much parallel calls do you expect to happen?
how fast is fast enough to send your orders through?
what are reasons for the communication to fail?
All that taken apart, combining option 3 with a polling mechanism that resends any left overs seems like a good idea.
So in your webserivce request start a microflow asynchronously so that it does not delay your webservice response to webshop A. In that asynchronous microflow call the webservice of ERP C to push the order to it. If that somehow fails due to network issues or something else. You will still have your backup scheduled event that will try to resend it. Alternatively you can build in a process that handles orders that were unable to be send to the backoffice and set them to a status error sending to backoffice. I can imagine that these may have to be reviewed by someone before they are actually resend.
Pieter van de Braak
Maybe the process queue module from the appstore can be of use. It allows you to add a next job (B-C) in the queue at the end of the first microflow (A-B).