Max Number of work units allowed at a time?

We had an issue where a scheduled flow ran almost 12 hours later than it was scheduled for. Up until now it was running every day @ 9:40 a.m. EST. It ran and completely successfully just much later (8 p.m. EST). Infor has said our LPA node can only have a fixed number of workunits at a time. I'm slowly learning IPA on my own so I'm not an expert - but what the the limit to the # of workunits? Where can I see that? Can that be changed? They asked if I had any that ran a long time yesterday and all I see are many e-req approval flows that have a Start date but no Close Date yet and they are at upwards of 17 hours (there are several of them) - would these play into the max number of workunits? Thanks in advance. - Laura

Find more posts tagged with

Process Automation (IPA) - General Discussions

Accepted answers

All comments

unknown

We also learned about this limitation when we ran into issues. We are cloud so cannot see the setting and they have to make any changes to it. From our calls with them, they don't like you to have more than 2 or 3 because it will affect performance if you have too many. I think ours was originally 1 and they changed it. This is per data area. We have 2 in one and 3 in another. We stagger our flows to run at different times with the longest running ones in off hours. The req approval flows do not play into the number when they are in process but waiting for approvals, so that is the good news.

russel-cornelson

Good morning Laura,

The number of workunits that can process simultaneously is determined by a setting in the GEN tenant on the PfiConfigurationParameter business class. The setting is called "Core Pool Size" and is a per LPA Grid Node value. So if you have 2 LPA nodes; Core Pool Size=2 would allow you to process 4 workunits at the same time.

The total number of workunits that can process at the same time; as a general rule of thumb should be equal to the number of logical processors on your Landmark Server. This should always be your starting point when adjusting this value ... it might be able to be higher than this but it will depend on the type of flows you are running, and what those flows do. If they consume files; and spin through the records doing alot of work server side you probably can't increase it. If they make calls out to other systems and spend time waiting for responses it could be set higher.

If you are on-premise or ST-Cloud you have access to change this in the gen data area. NOTE: If you are ST cloud I would recommend engaging someone from our side before making the change. More flows = More CPU and More Memory being used; can the current configuration handle the extra cpu/memory? Someone should look at these things before changing this value

If you are MT-Cloud you would need to make a request probably through your CSM to ask if you can have the number of workunits increased.

------------------------------------------

If you have req approval flows that show as processing ... if they are waiting at a user action for an approver these do not count towards your max allowed workunits. Additionally the processing time of these flows is just math ... how much time has passed since it started.

So if I start a flow that goes to a user action and waits for 7 days for someone to approve the processing time is going to look very high but its not; it likely parked at the wait node within a few seconds.

I hope this helps with your questions, let me know if you have more.

russel-cornelson

ST Cloud or MT Cloud?

MT Cloud, depending on what farm you are on a setting of 2 could actually be 28 simultaneous workunits as one of our farms has 14 LPA nodes and the setting is per node.

unknown

Russel

how does number of workunits running at the same time play role when you have parent and children type of flow to improve performance? also do you see any impact on sql server ?

"If you are on-premise or ST-Cloud you have access to change this in the gen data area. NOTE: If you are ST cloud I would recommend engaging someone from our side before making the change. More flows = More CPU and More Memory being used; can the current configuration handle the extra cpu/memory? Someone should look at these things before changing this value"

laura-patenaude

Thanks for the info. We are on-premise - V10. We are not in the Cloud as yet. I don't see that we had any long running process that would have held up that flow for almost 12 hours. we had a boatload of approvals running - but all the flows all run in pretty much seconds. Most of them are triggered by File Receivers. I can't figure out why this would have been delayed for so long. Where can I see/change the # of flows? I wouldn't attempt to do it - I would ask my sys admin - but it doesn't seem like that would have fixed this issue anyways. This is the first time this has ever happened.

jocurrin

I believe we experienced an issue like this a few years ago and somehow it was tied to a job in waiting on the S3 side. I don't think it was that the flow ran anything on the S3 side, but there was a connection there. Just something to check on but may not be the culprit.

laura-patenaude

That's very interesting ... I'm still waiting for Infor support to respond... But I'm glad to know I'm not the only one who has been surprised by this at one time!

russel-cornelson

@vipul-modha

The number of workunits running at the same time will be impacted by child/parent flows. So if I design a flow to leverage multithreading ... parent flow queries all workassignments then creates a child flow to process 1000 records each child does count as a child process

Would you see an impact on SQL Server? I have seen a client that made every efficiency improvement they could find for process flow and when they were done they needed to tune their database to handle the increased load. So my answer is yes; you can make process flow fast enough to impact other systems.

Should someone look at CPU/Memory before increasing Core Pool Size? Simple. Yes they should. While looking at it, tuning it doesn't guarantee 100% safety because you are guessing how all the flows you have that could possibly run at the same time will interact. But failure to look at those values seems a bit reckless as it can cause a stability issue.

---------------------------------------

@jreese

Just to be on the safe side I am going to mention this ...

In Landmark v9: Async is responsible for creating PfiWorkunit records at a scheduled time, and for scanning for PfiWorkunit records in Ready Status every 10 seconds

In Landmark v10,v11: Async is responsible for creating PfiWorkunit records at a scheduled time.

In Landmark v10: LPA Node is responsible for scanning for PfiWorkunts in Ready Status every 10 seconds

In Landmark v11: LPA-Dispatcher node is responsible for scanning for PfiWorkunits in Ready Status every 10 sec

---------------------------------------

@Async

There is a concept of "Max Active Actions" which is the number of actions async can processes asynchronously. If you Define a Process Flow Queue; and add a mapping for "PfiTrigger" async requests to go through instead of the Default Queue ... then assign that Queue a Max Active of 1 there would ALWAYS be an available async action to start up your scheduled flows.

IMPORTANT

Default Queue is NOT where you want your async actions to be processed. What is important to your company? Important actions should get their OWN QUEUE to guarantee they have an available action to process them.

Leave unimportant things in Default Queue; pick out the important ones. Much easier to do it this way and you can guarantee processing cycles for important items.

Copyright © 2025 Infor. All rights reserved.