Execution Limit 50 nodes

RE: Execution Limit 50 nodes

Stewart Burchell — Wed, 14 Oct 2020 16:09:31 GMT

If the tables are related you can do the heavy-lifting in the database itself by either:

creating a VIEW that covers all of the tables, so you'd end up with a single query from the process model OR
calling a Stored Procedure that makes all of the calls and returns the data in one hit

In essence you need to try to minimise the number of calls made from Appian to the database.

RE: Execution Limit 50 nodes

Mike Schmitt — Wed, 14 Oct 2020 15:50:33 GMT

[quote userid="33047" url="~/discussions/f/best-practices/19748/execution-limit-50-nodes/77242"]About the nodes , they are queries nodes, not write entity[/quote]

My fault, I didn't recognize the query DB node icon; are you querying data with these or writing data? Your original text said they're "updating a database" which is why I mistakenly thought they were WTDS nodes. If they're just querying, I'd suggest using a!queryEntity instead if possible.

RE: Execution Limit 50 nodes

rebecar369 — Wed, 14 Oct 2020 15:33:11 GMT

[quote userid="50400" url="~/discussions/f/best-practices/19748/execution-limit-50-nodes/77239"]I understand - I was asking why? This sort of setup should almost never be necessary.[/quote]

Because we need to save execution time.

About the nodes , they are queries nodes, not write entity, for that we needed put them in parallel.

RE: Execution Limit 50 nodes

Mike Schmitt — Wed, 14 Oct 2020 15:21:15 GMT

[quote userid="33047" url="~/discussions/f/best-practices/19748/execution-limit-50-nodes/77235"]each node calls a diferente table in oracle.[/quote]

That should still be doable with the Write to Multiple DSE node (which is NOT the same as using the regular Write to DSE node with "multiple" enabled, which seems to be what you're thinking of)

[quote userid="33047" url="~/discussions/f/best-practices/19748/execution-limit-50-nodes/77235"]They are in paralell [/quote]

I understand - I was asking why? This sort of setup should almost never be necessary.

[quote userid="33047" url="~/discussions/f/best-practices/19748/execution-limit-50-nodes/77235"]when we dont put activity chaining postman doesnt return all values[/quote]

I vaguely see what you mean here - but you might need to design around this, such as having Appian send an API call back to the source system after processing has been done. However, if you're lucky you might be able to get around this by implementing the Write to Multiple DSE node as I mentioned before.

RE: Execution Limit 50 nodes

Stewart Burchell — Wed, 14 Oct 2020 15:18:20 GMT

The Multiple Write to Datastore Entity node supports multiple tables, as Mike Schmitt pointed out in his reply. In fact, it's better than writing to the tables individually as the whole write is transactional - it all works or none of it works, which protects the integrity of your data.

RE: Execution Limit 50 nodes

rebecar369 — Wed, 14 Oct 2020 15:03:55 GMT

Hi, i response you:

1.We cant use multiple node because each node calls a diferente table in oracle.

2.They are in paralell (the image maybe doesnt show it correctly)

3.We need activity chaining cause we call this processes through a web api (with a starprocess function in a API object) . This WebApi is called by Postman, and when we dont put activity chaining postman doesnt return all values of the process variables when the process is ended, its like the flow breaks.

RE: Execution Limit 50 nodes

Mike Schmitt — Wed, 14 Oct 2020 14:40:57 GMT

That design looks problematic even without the activity chaining issue...

Why aren't you making use of the Write to Multiple DSE node?
Why do you have to execute all of these in parallel instead of in some sort of sequence?
Why do you need to have activity chaining try to go through that?

RE: Execution Limit 50 nodes

rebecar369 — Wed, 14 Oct 2020 14:38:30 GMT

Our problem basically is that we have a process modell with 35 nodes which update a database, these nodes are in parallel and they have activity chaining, but one way or another the flow breaks and it doesnt return all data correctly.

RE: Execution Limit 50 nodes

Mike Schmitt — Wed, 14 Oct 2020 14:21:43 GMT

The limit refers to the number of nodes (including all node types and nodes within chained, synchronous subprocesses) between two chained-together User Input Tasks.

Basically if you design a process model with Task A followed by Task B, and chain the flow between them, the user will step from A to B upon submission of A. If you add more than 50 nodes in between them (even something as benign as completely empty script task nodes), chaining would be expected to break and subsequently Task B would land in the assigned task queue of its assignee(s). The user submitting Task A would experience the same thing that they would at other times chaining breaks or a process ends, which would be they'd be returned to wherever they originally accessed the process/task from (their task list, related action, etc).