Thursday, December 11, 2008

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 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.

No comments: