K2 Best Practice, Part 1: Blackpearl Workflow

by | Apr 21, 2015 | BlogPosts, Tech Tips | 0 comments

The great thing about K2 software is that there are many different ways of doing things and a negative thing about K2 is that there are many different ways doing of things!

Poorly designed workflows and SmartForms can have a major effect on solutions’ performance and this can seriously impact the business motivation to adopt K2. Also, debugging complex forms can quickly become nightmarish when handing over to other developers of working backward through someone else’s implementation. Although some of the planned features in 4.6.9 (comments at last!) go some way to addressing this, following best practice will allows for a consistent approach to designing forms and workflows, thus making it easier for someone else to logically pick it apart.

There is plenty of good documentation out there in the help files, forums and blogs but how do you find it if you’re not sure what to look for? So, we’ve complied some of the best tips available and added a fair few of our own to help budding developers get the most out of K2. In the first part of this two part series, we will be looking at K2 Blackpearl and in the second part, we will focus on SmartForms.

 

Process Sizing

It is recommended to limit the number of activities in a process as much as possible. If a process has many (generally more than 20) activities, it is usually a good indication that the process should be subdivided into smaller processes with IPC calls between the sub-processes.

Blog - K2 Blackpearl - Image 1

Also pay attention to the actual size of your process, in particular the process (.kprx) file. Especially if you are using a source control solution, when this project file grows beyond approximately 20MB in size, it may become unwieldy and benefit from being split into multiple parts. This number should not be thought of as a rule but rather a guideline.  Some processes over 10MB in size may also benefit.

 

Data Fields vs. SmartObject Queries

When designing your workflow there are two main approaches you can take when it comes to access data sources.  Both approaches can work equally well depending on your project requirements.

Pros

Cons

Scalable

Business Object

Easier reporting

No automatic auditing

(fewer data fields, more SMO queries)

Access data outside of the process

Data may not be validated

Process Centric

Potential scalability issues

(more data fields, fewer SMO queries)

Enables granular auditing

Difficulty in reporting

Data locked up in process

It is important to consider the type of service the smart object is connecting to; a smart object that connects to a database will perform better than one that connects to a web service. Generally speaking, it is best practice to use SmartObjects to store data.

 

Data Fields

Blog - K2 Blackpearl - Image 2

Process Data Fields

Process data fields exist for the entire lifetime and their scope is global to the process. Data fields should only contain data that is tightly related to the particular business process or activity that they are defined for. Ideally data fields will only contain pointers or ID values to the business entities and data that is stored in the application databases.

Activity Data Fields

Activity data fields exist for the lifetime of the activity instance and have a scope of the activity instance. In K2 activity, data fields are duplicated for each destination user assigned to the activity. Therefore, these data fields have the tendency to easily grow to enormous proportions, consuming large amounts of server memory, network bandwidth, and possibly also disk storage. Irresponsible use of activity data fields with large amounts of data assigned to many users is strongly discouraged. The default setting for activity destination rules in K2 Blackpearl are to Plan just Once, and by default the data fields will not be duplicated in the same way.

 

On Demand

“Data on Demand” is a feature that minimises the load placed on server resources when a large volume of data from the K2 database is requested by the K2 Server and Worklist.

When a process instance is loaded by the K2 Server, all process data associated with the process instance would be loaded at the same time. This creates a resource drain as not all the data fields are required at the same time to perform a step within the process. However, since all the data has been loaded, the system must manage the data contained within memory even though only a small portion of the data may be affected at that time.

When a process which has data fields with “Data on Demand” enabled is loaded into memory, these data fields aren’t loaded with it, but rather only pointers to the data are created. Once the data is requested, the server will make a call to the K2 Database and return the data.

This feature then economises bandwidth usage because only the data required is requested and loaded by the client application into local system memory, rather than loading unnecessary data from the server to the client application.

Good design considers each data field individually to determine if “Data On Demand” is necessary. Certain data fields that are accessed often might make the process perform faster if “Data On Demand” is switched off so that the data field operates almost in a cached manner.

Blog - K2 Blackpearl - Image 3

Keep Audit Trail

Checking the “keep audit trail” checkbox will save every value every time the data field changes. Remember, if the data field is big (i.e. xml), this will fill up the K2 database very quickly.

 

Multi Destination Activities

Take care when adding events to activities where there are multiple destination slots, especially server events. Each event will be executed per slot which can flood external applications with simultaneous calls or insert duplicate records into a database.

 

SmartBox

With regards to storing your line of business data, it is not recommended not to use SmartBox. Changes made at the database level to tables, indexes, views and stored procedures are not supported as it is a K2-managed database. SmartBox is recommended for storing temporary data.

It is best practice to create a custom SQL database and use the K2 SQL Service Object to build SmartObjects around the stored procedures, views and tables so that you can then easily access your Smartforms and K2 processes.

 

And that’s it for Part 1, check the help files included below for more best practice tips from K2.

 

References

K2 Best Practices – http://help.k2.com/kb000352

Data on Demand – http://help.k2.com/kb000102

SmartBox Best Practices – http://community.k2.com/t5/K2-blackpearl/SmartBox-Best-Practices/td-p/58895

 

 

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *