IPA WorkUnits Prioritisation

Good Afternoon,

Hopefully someone will be able to help in a question we have around prioritisation of workunits in IPA. We have just promoted a new version of a flow but this is generating more flows than we expected and we are having a number of flows in ready status waiting to be processed. The flow runs off the back of a Event Analytics rule across OOLINE and currently I have around 7000 workunits waiting to process with a delay of just over an hour, this has been accumulated over the last 3-4 hours so over a full day could cause a problem. Checking my Grid status we are processing 5 flows at each time but need to understand if there is a way of reducing the priority of this new flow so it takes second process compared to everything else.

I have looked at the queues process and this seems to be designed around background jobs or scheduled jobs and not ones coming via Event Analytics as this go straight to the processing / ready stage.

Any help would be greatly appreciated for this as it looks we may have to cull the flow if this continues to run like this

Thanks

Alex

Find more posts tagged with

Process Automation (IPA) - General Discussions

Comments

russel-cornelson

Good morning Alex,

1. What version of Landmark Environment are you using?

2. Is the Landmark Server Windows or Unix?

3. How much CPU is the server currently consuming while processing 5 workunits at a time?

4. How much RAM is on the Landmark Server?

5. How much RAM is it currently using?

6. What is the Max Heap setting for the LPA Grid node, and how much is it currently using?

7. Do you have workunit logging levels set to "Workunit only" for all your flows?

8. Do you have Cancel Check Frequency set to Intermittent for all your flows?

The above information is needed to determine the best course of action for you. Some of the questions are geared to see if we can increase the speed with which each workunit processes and thereby increase your throughput. Other questions are geared to determine if we could start another node without jeopardizing the system stability.

russel-cornelson

P.S. There is no delivered process priority functionality delivered with the current Landmark Environment Version.

However, it may be possible to design such a thing into the flow. This would require using some logic and a wait node to achieve the priority queue'ing ... this would be tedious in 10.1.1.x as it would require manually changing all flows. However in Landmark 11 ... this would be easier as you could place the logic in a sub node, then add the sub node to all your flows.

But this does not help the immediate situation, which can be really bad depending on your version of Landmark and what those flows do.

unknown

Hi Russel,

Thanks for the above responses, we have decided to remove the process for the time being as we have been able to get the same results via another way but outside of IPA. Looking at the flow itself, it was only taking a max of 1-2 seconds to process but was the amount of data capture that was causing the slow response in processing them. I am currently in the process of upgrading to 10.1.1.57 and have been advised by Infor that this is version is able to process more Workunits but I'm assuming this could be on certain capabilities on the server.

In answer to your question, this is as we are now and obviously after we have stopped the process causing these issues. Hopefully it will give you some idea on what you require

1. What version of Landmark Environment are you using? 10.1.1.5.4028

2. Is the Landmark Server Windows or Unix? Windows

3. How much CPU is the server currently consuming while processing 5 workunits at a time? 40-60%

4. How much RAM is on the Landmark Server? 16gb

5. How much RAM is it currently using? roughly 15.3gb

6. What is the Max Heap setting for the LPA Grid node, and how much is it currently using? 2015mb and around 250mb

7. Do you have workunit logging levels set to "Workunit only" for all your flows? I have them set to Activity only now on advise of Infor. Most were set to Workunit Only

8. Do you have Cancel Check Frequency set to Intermittent for all your flows? Not sure where this is?

Hope this helps

Alex

russel-cornelson

Good morning Alex, here are my recommendations:

1. If you are going to upgrade Landmark, upgrade to 10.1.1.58. CU58 contains a fix to the S3 Connection Pools that allows the system to automatically recover if an LSF outage occurs and ends up invalidating your sessions

2. If you are already leveraging 15.3 of 16Gb RAM on the server I recommend trying to get more RAM added to the system or you may experience system instablity

3. In 10.1.1.5 there is a performance hit to all different types of logging. After you upgrade this system set ALL processes to log with "Workunit Only". The logging in 10.1.1.58 will provide you with all the information you see in Activity logging without the performance impact that Activity logging has.

4. Cancel Check Frequency is a performance enhancing feature available in 10.1.1.33 or higher. It is set on the process flow itself, after your upgrade it will appear below the log level on the process definition.

The performance gains of the newer versions are fairly well documented at this point, however, to get the benefits out of it you definitely need the CPU. If we are currently 40-60% ... I don't know how much we will gain, depends how much of that CPU is being used for erroneous things in that older version.

I have a bunch of KB articles out there on the Infor Xtreme Support site regarding performance, etc. I won't look at a system's performance below 10.1.1.48 at this point, but if you upgrade and wish to review the performance, you can always open a ticket with Infor Support and I will do my once over recommendation for you.

Copyright © 2025 Infor. All rights reserved.