Welcome to the Synergy Technical Blog and Technical Knowledge Base – a resource that shares intelligent and creative solutions that have been built and implemented on real-time projects on behalf of Velocity clients.
A typical K2 blackpearl workflow process design pattern is to associate a business object (for example a leave request) with a K2 process, and this process is typically a long running process that moves the object to its finite state. An example final state might be approved.
Updates made to data, or more specifically business objects, during this long running process sometimes require a K2 workflow processes to be started to react to this update. It could be that a change in one of the data objects’ properties requires an approval process to be initiated if its value is above a certain threshold. While the business logic in the approval process might have been called as part of the sequential long running K2 process, it is required to be executed again to evaluate and to ensure the appropriate K2 workflow actions are taken.
The K2 blackpearl IPC event is extremely powerful and provide the means to connect separate K2 Workflow processes. It is good practice to implement a process in K2 as a collection of sub-processes and connect them using the K2 Inter Process Communication (IPC) event. These K2 processes are generally in the same K2 for Visual Studio project, but bigger enterprise level Business Process Automation using K2 blackpearl generally results in K2 processes being spread amongst several K2 for Visual Studio projects.
K2 developers always ask themselves the question when to use K2 data fields, or what is the correct best practice when using data fields.
It is important to realise that K2 data fields are global to a K2 process, and like any global variable, it’s existence and usage should be carefully considered. The decision should generally not be a difficulty and time consuming one to make, but it can impact the future maintainability of a K2 process.
The K2 blackpearl Process Overview Report is a very useful report and provides a user a 360 degree insight into any K2 blackpearl Workflow instance. This report is widely used by users and K2 blackpearl developers and is available from the K2 blackpearl Workspace by drilling into a particular K2 blackpearl process instance.
There is an extremely useful way to integrate the K2 blackpearl Process Overview Report into your application and provide user a one click mechanism to access a particular K2 process instance’s report. This means you can provide a more convienient way for a user to view K2 Workflow state associated with a particular business record or object within a K2 Workflow application screen.
K2 blackpearl Process Overview integrated into Application
There is a lot of mileage in naming K2 blackpearl artefacts appropriately and correctly. One benefit is the ease of understanding what the role is of a K2 blackpearl process by looking at its underlying K2 blackpearl activities and K2 blackpearl events.
There seems to be several ways that are used by K2 blackpearl developers to name K2 blackpearl processes, activities and events. A few I’ve encountered since I stated in 2000 working with K2 blackpearl in ascending order of good practice are:
Throughout the years I have created hundreds of K2 blackpearl processes and although the design of most of these were unique, there are two particular design patterns that stands out when creating new processes in K2 blackpearl. These are waterfall or swimlane.
A waterfall tend to start at the top of the design canvas and moves downwards flaring outwards like a waterfall. A swimlane process starts from the left of the design canvas and stretch to the right and can continue on a new lane when desired. Each new line represents a new lane.