When to Write Custom Code in K2

I had two K2 colleagues contact me at the same time roughly about the same thing. Neither are new to K2 however everyone at one time or another runs across this. At what point do I just put up a custom event and just write some .Net code?

Yes – the wizards of K2 are tremendously helpful however configuring activities and line rules can become annoying to a developer. Especially if you have complex logic and the diagram you would end up drawing is more trouble than what is worth. I really do not suggest trying to model every "if statement" in your process as a line rule. It really does work well. For instance you may have a point in your workflow where you need to send an email. You may have business logic that based on the state of the process instance you may have to insert different text into the body of the email. When using the email template, you will quickly find out that you cannot create a single email event. What you will have to do is create multiple email events with line rules that take you down to each one. The moment you have more than four or five email activities, with relatively the same content other than some small deviations, you will really start to hate K2. All I can say is forget using the email template and start writing some custom code. Dan (colleague at RDA) wrote this blog. Here he shows how to create a utility class, create a reference to the library and a start using. In K2.net 2003 we had code modules, but they are no more. So this is how to do it with K2 blackpearl.

When I have heavy InfoPath processes with lots InfoPath events, I really start hating life when configuring all of the activities. In those cases, I really cannot do the approach above. However, it is better than the alternative of custom coding it in WF. I rather be clicking for two days than building for two weeks.

Still somehow I never get away without writing custom code. Even when I work with SmartObjects, I prefer to work with the API directly. I really love K2 and WF because they allow me to model the major steps of the process visually and just click into the code where all the real work is. It gets the core business logic out of the User Interface Layer. I really start like workflow technologies when I have the ability to take snapshots of the workflow and send them to the business user so they can see how the core logic of the application is built.

Simple K2 Requirement Gathering Questions

Here is a list of questions that you would ask business users when gathering requirements to estimate the level of effort to build a K2 process. My first thought is that I like to craft questions that are somewhat technology agnostic such that we can capture the business requirements. We want to avoid boxing the questions specifically to what a tool can so a Use Case can be captured. I do admit it can be difficult to follow every rule for writing effective Use Cases, but just make your best attempt at letting the requirements drive the solution and not letting the technology drive the requirements. Remember K2 processes can to automate more than just SharePoint.

Luckily many of the abstractions within K2 align themselves well with defining a standard business flow definitions. Here is a quick list of questions I would ask to the business users?

• Can a business flow diagram be constructed?
  
  • What are the steps in the business process?
  • What are the decisions a user can make for each step of the process?
  • What role must the user have to make that decision?
  • What stakeholders are there for each decision?
  • What must occur when a decision is made?
  • What should occur when a step is not completed?
  • What are the success criteria for a process to complete? How should a process complete if success criteria cannot be met?
  • What data must be available for a user to make a decision? Are there rules for the visibility of displayed or captured in the business process?
  • Are there rules that affect the routing of the business process?
• What views/dashboards are required to assess that status of the business process?
• What reporting is required for business processes (in flight, completed, user performance, etc.)?
• What is the user experience desired? Where do users go to complete tasks? How should users be notified when a task has been assigned?

Note that:

• Process = K2 Process
  
• Steps = activities/events
  
• Decisions = actions
  
• Roles = K2 roles/groups/destination users
  
• Stakeholders = users or systems that are affected by a decision
  
• Success Criteria/Rules = succeeding or line rules
  
• Data = SmartObjects :-)
  
• Views/Dashboards = task lists (K2, SharePoint, custom), reports (reporting services, etc.), web pages, web parts, etc.

As you can see activities, events, destination users, roles/groups, external systems, SmartObjects, data integration points, escalations, etc. are all captured. Asking questions about reporting will answer questions about whether the data can be stored in K2 or whether it needs to be stored externally.

Some of the questions asked at the end violate the technology agnostic theme I suggested above but it just cannot be avoided. This is not all encompassing but should start you in the right direction.

One thing to take away is how closely K2 is when building your business processes. You can see how the implementation is directly mapped to the business process and less information is lost and not up to as much interpretation.

An Overview of K2.net Workflow

Are you looking for a quick overview of what K2.net is. Here is an article I wrote some time ago that will give you some basic background on it - An Overview of K2.net Workflow Technology