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 easiest approach to sole this using K2 blackpearl is to ensure the long running K2 business process makes a K2 IPC call at the particular stage when the initial business object’s value is evaluated.  The sub-process will so whatever it needs to do. This typically happens when the K2 process is initiated, but can also happen at any stage of the sequential K2 process.

K2 blackpearl Process Start from Long Running Sequential K2 process

K2 blackpearl sub-process executes k2 business rule and takes no action

If the business object is updated outside the context of the long running K2 blackpearl process, all K2 workflow processes as required by the business rules should be re-executed.  This business object update might have been as a result of an update made to data from a ASP.NET or K2 SmartForm.  The best practice is to keep any business logic as far as possible away from the interface that does the update, and to simply trigger a mechanism that starts all the K2 processes that are affected by the change in data.  If you are using purely SmartForms, the best place to set this up is using the K2 Custom Event Designer.

K2 blackpearl Process-Start from Object-Update in K2 Custom Event Designer

The example below uses an ASP.NET form for its user interface, and the K2 processes that subscribe to changes are simply called.

K2 blackpearl process start from business object update in code

It is important to design the processes in such a way that they are autonomous and decide if the change in data actually results in, for example, K2 workflow tasks being created.  They might also need to be aware of other existing obsolete K2 processes that needs to be completed to ensure the latest K2 workflow tasks correlating to the business object exists.

K2 blackpearl sub-process executes standalone and k2 business rule dictates new user registration is reguired

Every time an update is made to data, consider the impact on your K2 processes.  Use a separation of concerns pattern when designing K2 workflow processes, and use an K2 IPC event to string together K2 business processes.  Ensure K2 processes subscribe to updates to data via. the K2 Custom Event Designer, or in code if you prefer this approach.  Design K2 processes to be able to execute stand alone, and ensure they are aware of other K2 processes and terminate obsolete ones if the K2 business rules dictates this.

Need further technical advice or support?