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:
Now we just need to take that data and build our URL, which looks like this:
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:
- Run SQL Node
- Execute WebRun
- Trap/Log any errors
- Loop on SQL node
In our system, it completed roughly 1700 workunits in about 5 minutes.