Long running process flows
Hi, I have a proces flow (A) which process about 1000 orders and calls the process flow (B) below. Process flow (B) runs roughly 6 seconds to process an order (check, payment, send email, create log, etc).
I would like to understand a couple of things regarding "Execution Mode" (all my process flows are sync, not sure what the benefit of async is).
- If A and B are set to Sync: Then process A processes one order and waits for process B to finish before moving on to the next order. Process A does not finish until all 1000 orders are done. The interface is locked/unresponsive until both process A and 1000xB are complete which is roughly 6000 seconds (6x1000) or 1:40hr.
- If A is set to SYNC, B set to ASYNC: Then process A can loop through each of the order and runs process B async meaning it doesnt wait for process B to finish before moving on to the next order. The interface is locked/unresponsive only until process A is complete which say roughly 30 seconds to loop through 1000 orders.
- If A is set to ASYNC, B set to SYNC: When running process A, the interface is locked/unresponsive only for a second.
- If both A and B are ASYNC. same as 3 above? no difference?
Regarding server or local resources: how does this affect resources (memory and proc) and how does the Aptify/code handle resource limitations? would it crash or does it handle this graciously?
0
Comments
ASYNC = App Server execution. So you don't tie up any ones client instance.
Now as well, Execution Mode on the process flow is for when an Event Handler is executing the process flow. So if Execution Mode is Async the event handler will create the Process Flow Run record for the App Server to run the process flow.
If you've got the process already on a Schedule Task or are manually creating the Process Flow Run record, your already all good with Async processing.
For resources, I don't know the actual memory usage limit number but if it hits them it just fails and you get the "System.OutOfMemory" exception error in your even logs.
This is where the App Server can be helpful as well with the newer configuration setup. Because you can setup multiple service instances one server they (to my knowledge and I could be totally wrong about this) don't have a shared memory pool and they are not running a UI so you have more memory available to your process. For example I have a couple of large excel exports that work on through the async server but I get "System.OutOfMemory" exception if I run them from my Desktop client.
The way I would have this setup is process flow A would be a Scheduled Task or something admin user action to trigger it and process it on the Async Server. It still loops through and generates the orders but Process Flow A does not initiate Process Flow B. I would have a Event Definition/Event Handler that can pick up that the order was created and then have Process Flow B have the Order ID as an input value and execution mode as Async. This means that you can have multiple Process Flow B's running at once depending on the number as Async Processors you have configured.
I currently have 2 servers, one with 6 async processors that all under untargeted runs and one that has 3 processors on it that only process ones targeted runs to them (These are mostly for schedule long processes like exports and auto-renewals, etc).
Happy to jump on a call anytime to dive more into it: chunter@aapa.org
Please sign in to leave a comment.