Things to Consider While Activating Siebel Workflows

Siebel workflows are indispensable for implementing business rules within the Siebel application.

They provide a powerful, declarative framework for diagrammatically representing the logic that is easily maintainable, scalable across releases and less prone to errors and memory leaks. So, people do get the message about how workflows play a vital role.

Once you have designed and developed your workflow, getting them to production is pretty simple:

• Hit the ‘Activate’ button in the web client

So far, so good. But not immediately visible are a few interesting things about Siebel workflow activation. Given below are the top 3 things to consider while activating Siebel workflows:

1. Check the repository workflow version.

Sneaky developers to have the practice of directly importing the workflow and runtime tables.
This is a bigger headache than it appears since any production issues cannot be debugged in lower environments. Unless the development team knows what it’s doing, they may end up losing their particular version altogether.

2. Check for rogue runtime events.

When workflow is activated it also goes and creates corresponding runtime events if they are defined in the workflow. Although this is quite handy since you have both the workflow and runtime events at the same place, and you do not need to do anything else, this has led to some interesting problems.

Sometimes (for reasons I don’t understand), the older runtime events are left as is. The older runtime event continues referring to the older workflow ID (id in  runtime tables). This displays errors when the transaction is attempted, and some of these errors stop the subsequent steps from executing.

You can create custom SQL statements to find for any orphaned runtime events, and inactivate them.

3. Check the workflow for dependent workflows/business services.

One of the common ways of deployments for minor releases is to pick and choose components that have been modified, and deploy them in the higher environments. Though this works most of the time, it may lead to failure dependencies are not taken care of.

Consider a workflow that refers a sub process or calls a custom business service. If those components were not imported before the workflow, the imported workflow definition can become corrupted. It will lose the reference to the particular external business service/workflow.

The positive of this whole thing - you can catch this error at the time of workflow activation.