If you have spent several years
developing custom SharePoint workflows and then started working with K2
blackpearl, you would notice some big differences in developing workflows using
these two technologies.
One key thing to remember here is
that k2 blackpearl is an enterprise workflow engine. SharePoint is not a
pre-requisite for K2 blackpearl. K2 can be deployed in environments without
SharePoint. However, K2 provides first class support for SharePoint. That being
said let’s look at some key differences between these two technologies.
#1: Worklist items Vs
SharePoint Tasks
We all know that in SharePoint
world Workflow task is the corner stone of any SharePoint workflow. When we
need to get end user’s input, say an approval, we create a task and assign the
task to the user. In K2, this concept is achieved by using Client events. A
client event creates a Worklist item for the user. This worklist item is
similar to SharePoint task. But unlike SharePoint task, a worklist item is
created within K2’s database.
In a normal K2 process, K2 does not
create tasks in any SharePoint tasks lists. However, we can design a workflow
that is centered on SharePoint tasks. But we will miss on some of the nice
features of K2. They are Escalations, reporting, working hours etc. K2 has a powerful reporting engine. In fact
SSRS is a pre-requisite for K2 installation. Since the K2 worklist items are
created within K2 database you can create very complex reports on how much time
a person is taking to finish a task. If the workflow is mission critical one,
then you can derive several business metrics from the worklist item execution
patterns.
However there are some drawbacks
when you compare a worklist item to a SharePoint task. In SharePoint, we can
easily extend the metadata of the task. All you have to do is create new
columns in the SharePoint task list. We cannot easily extend the metadata of
the worklist item in K2.
In regular workflows, you may not
need custom properties on a worklist item. But consider this scenario:
You designed a workflow to automate
the invoice process for sales. A sales person is assigned 14 customers. Each
customer is in a different region. Now you want a count of all the pending
invoice approval tasks in say North East region. If you don’t have metadata on
the worklist item, then it is not possible to build such reports.
As far as I know, the only property
of worklist item available for customization is “Folio”. Rest of the
properties/fields cannot be modified. K2 worklist item Folio is a text property
which is like Title property of the SharePoint list item. You can use this field to embed some metadata
to the worklist item. For the above example, we can set Folio as
Region_CustomerName_CurrentDate.
K2 has a standard web part that
displays the pending or open worklist items. While this web part is enough for
most scenarios and does its main job – which is to display the pending tasks,
this web part may not be suited for all your business scenarios and you may
have to develop custom web part using K2 API.
In my scenario, business wanted a
count of all pending tasks grouped by region. I developed a custom web part
that parses the folio field and displayed the counts.
#2: InfoPath form submission
In a normal SharePoint workflow, a
user fills an InfoPath form. Upon submission, using InfoPath form’s data
connections, you would save InfoPath form to the form library. Workflow will be
triggered because a new item is added to the library or modified.
In K2, after the end user fills in
the form, the form has to be submitted to K2 workflow engine. Not to a form
library. This is done by K2 web service. When you use InfoPath Process
integration wizard, K2 adds a data connection to this web service. The job of
this web service is to take the xml of the InfoPath and give to workflow
engine.
If you want to save the xml in a
form library, what you can do is, in the workflow you can extract the
InfoPath’s xml and then save that as a file using SharePoint Document or List
item event. You don’t need to write any custom code to do that.
#3: Use smartobjects
where ever you can
Normally in a SharePoint workflow,
when you have to reference data from a line of business system, you would
develop a web service and then call that web service in the workflow. In K2,
this can be achieved using smartobjects. Smartobject technology is a very
powerful integration technology. In simple terms, smartobjects surface out data
from various data sources. The technology is similar to BDC/BCS but not same.
With BDC/BCS, you have to create an external list to bring the data from
external system into SharePoint’s context. Then you can reference this data in
workflows. With smartobjects, you can use Smartobject events within workflow
and then call any method on the smartobject directly within workflow.
So, before you jump into Visual
Studio to develop a custom web service, see how you can use smartobjects. Using smartobjects will reduce the amount of
custom code to maintain.