Lawson: Mass Actions on Process Flow workunits

It finally happened. Thankfully, it was in test, but we let loose a process flow that generated over 1700 workunits that went to a user’s inbasket. Needless to say, we didn’t really expect (or want) all the workunits and we needed a way to “clean them out” quickly so it didn’t impede other testing that was going on.

I did some searching on Lawson support and some quick google searches looking for ways to mass cancel the workunits, but I didn’t find any process to do this that is delivered by Lawson. If you know of one, feel free to share, but in lieu of that this is what I came up with.

The basic idea is to have process flow execute one of the inbasket actions on each of the workunits via the WebRun node. I greatly prefer this approach to a direct database update or simply cancelling the workunits. Even though it’s in test, I don’t really want to run the chance of corrupting the data. If we can use the app to gracefully make the updates, why not use it? Thankfully, there is a specially crafted URL that we can build based on data in the LOGAN Workflow tables. Since we have Process Flow Integrator (PFI), I used the SQL node to gather the data, but you should also be able to use the DME nodes.

Here’s the SQL:

SELECT Q.WORKUNIT, Trim(TASK.TASK) AS TASK, Trim(WU.DATA_AREA) AS DATA_AREA, 
  Q.PROCESS_ID, Trim(WU.PROCESS_NAME) AS PROCESS_NAME, Trim(Q.ACTIVITY_ID) AS ACTIVITY_ID, 
  Trim(ACT.ACTIVITY_NAME) AS ACTIVITY_NAME
FROM LSF9_LOGAN.WFWUQUEUE Q
INNER JOIN LSF9_LOGAN.WFQUETASK TASK
  ON Q.WORKUNIT = TASK.WORKUNIT
    AND Q.PROCESS_ID = TASK.PROCESS_ID
    AND Q.ACTIVITY_ID = TASK.ACTIVITY_ID
INNER JOIN LSF9_LOGAN.WFWORKUNIT WU
  ON Q.WORKUNIT = WU.WORKUNIT
INNER JOIN LSF9_LOGAN.WFACTIVITY ACT
  ON Q.WORKUNIT = ACT.WORKUNIT
    AND Q.PROCESS_ID = ACT.PROCESS_ID
    AND Q.ACTIVITY_ID = ACT.ACTIVITY_ID
WHERE TASK.R_STATUS = 1
  AND Q.WORKUNIT >= 144342
  AND WU.SERVICE = 'MyProcess'
ORDER BY Q.WORKUNIT

This returns almost all the data we need to execute the actions. (Note: R_STATUS of 1 is open tasks.)

The data looks something like this:

WORKUNIT	TASK	DATA_AREA	PROCESS_ID	PROCESS_NAME	ACTIVITY_ID	ACTIVITY_NAME
146086	MyProcess	BMH	146086	MyProcessError_V02	UA2	UA4620
146165	MyProcess	BMH	146165	MyProcessError_V02	UA2	UA4620
146166	MyProcess	BMH	146166	MyProcessError_V02	UA2	UA4620
146167	MyProcess	BMH	146167	MyProcessError_V02	UA2	UA4620

Now we just need to take that data and build our URL, which looks like this:

bpm/inbasket?FUNCTION=dispatch&WORKUNIT=<!SQLWorkUnits_WORKUNIT>&TASK=<!SQLWorkUnits_TASK>&APPRODLINE=<!SQLWorkUnits_DATA_AREA>&RDUSER=username&PROCID=<!SQLWorkUnits_PROCESS_ID>&PROCNAME=<!SQLWorkUnits_PROCESS_NAME>&ACTID=<!SQLWorkUnits_ACTIVITY_ID>&ACTNAME=<!SQLWorkUnits_ACTIVITY_NAME>&ACTION=Complete

Note that earlier I said the SQL query returns almost all the data. The data that it does not return is related to the User and Action. The RDUSER value is the name that will be stored on the action. It must be a user that has this task assigned. The other value that is hard-coded here is Action. You can get a list of valid actions from the WFWUQUEUE table (ACTION_LIST field) or from the flow where you defined the list of valid actions. I’ve hard-coded it here because there’s no reason to look it up when I know what I want to set it to.

The basic Process flow I built is:

1. Run SQL Node
2. Execute WebRun
3. Trap/Log any errors
4. Loop on SQL node

In our system, it completed roughly 1700 workunits in about 5 minutes.

HTH

Advertisement