Parallel evaluation

Question

I am running some processing in parallel that includes api calls.The result with then populate an interface attended by a user. 
 I have tried both a!forEach and MNI but for both the performance is not as expected. 
 By looking at the performance tab in the expression rule, it is clear that the items in the array are running sequentially and not in parallel, 
 as the total time for the expression rule is the sum of every iteration. As a test I tried to put only a GET api call in the foreach loop and the result is the same. 
 This is not what I was expecting, is there anything that can be done to enforce the threads to run in parallel to optimize the performance?

Harsha Sharma · Answer

If foreach and MNI both are not helping, you can creating process model using parallel paths for each api call - basically call each api call independent of each other using AND node and a separate path per API. After the calls you can use complex node to ensure process returns to UI only after all the API executions are complete.

Mike Schmitt · Answer

Pretty sure with the a!forEach() function, it is an expectation that iterations run sequentially. For MNI, you would only expect parallel processing when specifying the correct node options, i.e. "launch all at once". If you're trying to chain across this, though, I would use caution as at best your users will experience pretty severe lag, and at worst, you'll hit the chaining limit due to internal node counts and the user will be dumped back to the site they were working on. I can only guess at your particular implemention aims, however. 
 If the aim is to create a seamless user experience across 2 tasks (one of which falls after the API calls / etc), as always my best suggestion is to design an intermediary task with a "refresh" button which checks for the value of an arbitrary PV you set to an arbitrary "complete" value after the separate thread is complete. This way you can stage the thread in your process in such a way that best allows for performance and processing, rather than trying to squeeze it into such a configuration that allows user chaining across it. I've done this here and there and honestly, the users don't mind waiting around for a few extra moments, especially when they're given a button they can spam-click with no negative consequences.

Shubham Aware · Answer

It looks like you mostly tried various approaches, but my recommendation is,
Parallel gateways with subprocess nodes means using a process model where an AND gateway splits the process flow into multiple parallel paths, each containing a subprocess node that calls a separate process model to handle one API call. All subprocess nodes execute concurrently, then an AND gateway converges the paths back together when all subprocesses complete.

Mike Schmitt · Answer

Are any of your API calls possible to run in an expression rule? It sounds like (but i can't tell exactly because you haven't included too much context / screenshots / etc) you're running multiple subsequent / branching / looping calls that could potentially be run sequentially with grouping and conditionality (for increased efficiency) within one or more expression rules... 
 For instance, one call that determines whether some subsequent ones even need to be run, instead of being put in multiple process nodes, could potentially be loaded as local variables in a single expression rule, which could potentially simplify your process structure by quite a bit, and at least decrease your chaining burden, even if the total time consumed for the actual calls to run stays about the same.

Shubham Aware · Answer

You&rsquo;re right - In this case parallel gateways won&rsquo;t work because you&rsquo;d need to pre-design 70 paths with bounds checking and it breaks result chaining. Your multiple if statement approach is better for this case.​​​​​​​​​​​​​​​​