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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s