K2 improving performance

The K2 worklist is used to expose tasks to users that participate in workflows.  There is one K2 worklist, but it is exposed in several ways.  In essence, it is exposed as a user interface that calls the System.Workflow.Client object to retrieve worklist items from the K2 server.

The out-of-the-box worklist items are workflow centric only – ie. it only displays data relating to the process instance.  It is typically required to merge this data with business data.  This makes the worklist more meaningful and provide good context to the user i.e. if an order amount is displayed and a customer account name, users might prioritise work based on this rather than the age of the item.

The easiest way to implement such a worklist is to create a custom service broker.  This does 3 things in essence –

1. Load the worklist data
2. Load the business data
3. Join the data together

The implementation of this service object is beyond the scope of this article, but what I want to show is to implement caching.

The pattern for the implementation of the worklist custom service broker I had to provide caching for is a follows –

1. Use the SourceCode.Worklow.Client object and load the users worklist
2. Loop through each item and add the worklist data to the dataset that the service object returns
3. For each iteration of the loop, load the business data and add it to the dataset
4. Return the dataset

The call in item 3 needs to be cached and the subject of this post.

The first thing is to call the metadata lookup in the loop.  This actually has 3 methods that loads data from separate sources.  I will run through the DueDate caching

1 – Worklist Item loading with metadata

The results of the methods are saved in a new list.  The calling code unpacks this and adds it to the returning data table.  Notice the DudeDateLookup method is called.

2 – Defining a metadata list to return to Worklist Item

This will happen for each worklist item, but the 2nd time round the items will be cached.

The code below implements the caching

3 – Lookup with caching mechanism

The concept of a due data is wrapped up in a due date class with a DueDate data class (1)

The cached list of due dates are kept in a static class (2) and is instantiated in (3) when the method is first called.  This is where new ones are added to the cache, or existing ones retrieved but only if they haven’t expired.

(4) is where we actually retrieve data from the cache, providing it hasn’t expired.  If data is not found in the cache, we load it again (8).  (6) just removes the expired version to avoid duplication.

(7) actually implements the cache expiration window.  This is how long the item will be valid for in the cache before it is flushed from the cache.

As mentioned, this method was to fix a performance issue in an existing custom worklist.  An alternative is to cache the business data and “join” this to the worklist data.]

Need further technical advice or support?