Parallel evaluation

RE: Parallel evaluation

Shubham Aware — Thu, 14 Aug 2025 14:54:09 GMT

You’re right - In this case parallel gateways won’t work because you’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.

RE: Parallel evaluation

Stefan Helzle — Thu, 14 Aug 2025 14:15:57 GMT

Peter Lewis , can you help us to better understand how to decouple looping code aiding in automatic parallel execution?

RE: Parallel evaluation

davidea — Thu, 14 Aug 2025 14:12:27 GMT

Yes, I can run all the apis in this critical part in an expression rule. The input to the rule is an array, Each item can run in parallel. For each item in the array, 1,2 or 3 different threads can be spawned, these need to run sequentially. Each of these sub threads run 2 or 3 apis. All of this is handled pretty much, an api call is made only when necessary.

RE: Parallel evaluation

Mike Schmitt — Thu, 14 Aug 2025 13:59:03 GMT

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.

RE: Parallel evaluation

davidea — Thu, 14 Aug 2025 13:52:04 GMT

Thank you Shubham,

I have not tried that yet. The problems I have with that approach though is that:

1) I do not know beforehand exactly how many items are in the initial array (could be 20, could be 70). I think this would mean designing 70 parallel processes and have them test whether there is an occurrence in the array that matches that?

2) That would definitely break chaining, I would like to preserve it.

RE: Parallel evaluation

Shubham Aware — Thu, 14 Aug 2025 13:25:20 GMT

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.

RE: Parallel evaluation

davidea — Thu, 14 Aug 2025 13:21:31 GMT

Yes, it appears to state that a!foreach should do the trick but I have evidence to refute it.

I can set an upper limit just below 100 items, while it looks ugly it works and whatever wizardry Appian is doing behind the scenes I will not be able to change it. There are probably nicer ways to "convince" the Appian engine but I cannot keep experimenting forever due to deadlines.

RE: Parallel evaluation

Stefan Helzle — Thu, 14 Aug 2025 10:39:03 GMT

I hope your list does not have more than a billion items ;-)

Did you read this?

https://docs.appian.com/suite/help/25.2/expressions-parallel-evaluation.html

RE: Parallel evaluation

davidea — Thu, 14 Aug 2025 08:45:02 GMT

Thank you Mike, we have used such a solution in the past but here it would not have sufficed as the waiting time was too long at least in some scenarios. Looks like I stumbled on a solution though as per answer above

RE: Parallel evaluation

davidea — Thu, 14 Aug 2025 08:35:12 GMT

I somehow stumbled on a solution.

The original code was:

a!forEach(
  items: ri!ofscSlots,
  expression: rule!FF_processOFSCSlotsBridge(
    ofscSlot: fv!item,
    activityType: ri!activityType,
    postcode: ri!postcode,
    duration: ri!duration,
    products: ri!products
  )
)

Bizarrely the (ugly) code below trigger the parallel evaluation

a!localVariables(
  local!numberSlots: length( ri!ofscSlots),
  {
    if(1<=local!numberSlots,
       rule!FF_processOFSCSlotsBridge(
         ofscSlot: ri!ofscSlots[1],
         activityType: ri!activityType,
         postcode: ri!postcode,
         duration: ri!duration,
         products: ri!products
       ),
       {}
       ),
       if(2<=local!numberSlots,
       rule!FF_processOFSCSlotsBridge(
         ofscSlot: ri!ofscSlots[2],
         activityType: ri!activityType,
         postcode: ri!postcode,
         duration: ri!duration,
         products: ri!products
       ),
       {}
       ),
      ---- And so on ------

The expression rule has multiple api calls and some relatively simple data transformation.

Really strange

RE: Parallel evaluation

Mike Schmitt — Wed, 13 Aug 2025 15:03:18 GMT

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.

RE: Parallel evaluation

Stefan Helzle — Wed, 13 Aug 2025 15:02:17 GMT

Can you share the code of your expression?

RE: Parallel evaluation

davidea — Wed, 13 Aug 2025 09:17:34 GMT

The problem is that I do not know how many paths I need, the content of the array depends of a previous api call.

RE: Parallel evaluation

Harsha Sharma — Wed, 13 Aug 2025 09:05:25 GMT

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.