Concurrent workunit "status = processing" limit?

Lyle,
Workunits (WU) are the instance of work...whether it's a requisition, termination, etc; a thread is what enables the instance to actively process. if you only have 1 IPA grid node (the installed default) and 2 threads running within that grid node (again, the installed default)...then only 2 WUs can actively process at any one time. When a WU gets to a User Action or Completes the WU releases the thread. When this happens the next queued WU grabs the open thread and takes off. This is why you can dump 50 WUs into your system, 2 will process and the other 48 go to Ready. Watch them long enough and you'll see them eventually go to Processing/Complete.

Additionally - WUs that contain User Actions will have an impact also. if while you're dumping 50 WUs in the system...and 50 from yesterday get approved by approvers at the same time...those 50 will get inter-queued with your 50. So depending on one of the 100 WUs gets queued up first...THAT is the order of processing.

You can add additional IPA grid nodes and up the thread count within the grid nodes, but unless you’re processing a large amount of WUs daily…and by large I’m talking more than 1 WU/second…I wouldn’t change settings unless you consult with an experienced Sys Admin. I’ve worked clients that generate 12,000+ WUs/business day, and we HAD to super-size out install…otherwise we could kill the system.

Thanks, Tim, for your explanation of how WUs relate to grid nodes and threads.

What should I do when I have a few WU processing a batch files that results in thousands LawsonTxns being executed, taking sometimes over a day to process a single WU? In the meantime, any other WU cannot process. Is there a way to limit the threads used by a IPA process flow? So my batch processing could be limited to only one thread, leaving another open for things that need to process "real time".

Thanks again!

NP Lyle,
IPA is good for many things, bad for other things...like processing thousands of records in one WU. I would seriously look at other options...COBOL (if an S3 app), perl script...ANYTHING other than a flow.

Using a flow creates other potential issues:
1. how are you going to handle restarts if the WU dies midstream or the server crashes. You're 5 hours into an 11 hour run and the grid crashes or the WU dies. if you restart, now a 11 hour run becomes a 16 hour run.
2. Is this WU resumable from within the WU??

I thought I remembered an option within the grid to steer a flow (by Service or Process) to another IPA grid node, but I must have dreamt it since I can't find any documentation on that.

I think these are your only options:
1. don't use IPA
2. only run one of these beast flows at a time...freeing up the remaining thread for other actions to use
3. don't use IPA, if at all possible
4. run the beast flow on a specific day, freeing the remaining days for other flows.
5. create a separate data area where the beast flow can run, which would be the worst option

Seriously though, I would consider something other than IPA...Sorry