Debugging Siebel Workflows
Though it seems improbable because of my questionable love for scripting, there is no love lost for workflows. I’m a big fan of workflows not only because they encourage modularity, are easy to configure and deploy, but also because - they’re really easy to debug.
Siebel offers a couple of ways to debug workflows -
1. The traditional way: go look at Siebel logs #
I have followed this method for a long time. You just turn on log levels to 4 (never to 5 - that is way too much information), and let the workflow rip.
Siebel logs each one of the steps in the workflow, the input/output arguments for the step, and all the operations that are carried in between (Including any BC calls, business service execution) and so forth.
It is quite easy to follow through the workflow steps and determine the exact cause of the error.
Typically I end up bumping the log levels of all the events, but you can opt to increase only workflow related log levels.
To increase log levels:
- Locate the Siebel component in Administration – Server Configuration >Servers. To debug workflows do this for the current OM, workflow process manager, other component that is executing workflow.
- In the Events subview tab, change log level to 4 for all options, or query for “Workflow*” and increase log levels for workflow related events
Take a look at all possible ways to increase log levels and debug errors .
Once you’re done that you will see a steady flow of information that gives more than enough details to debug the issue at hand.
While this method is useful, it is kind of a big bang approach for debugging. You will not be able to control which workflows need to long more details and which workflows shouldn’t. It is more suitable for development/testing environment debugging.
2. Monitor specific workflows #
For more granular control over the debugging process, bump up the log levels against the individual workflows. You will be able to view all the details of workflow execution through the application screens, and do not even require access to the server box.
To enable workflow for debugging:
- Navigate to Administration - Business Process > Workflow Deployment > Active Workflow Processes tab
- Query for the specific workflow process that you want to debug, and change “Monitoring Level” to “4-Debug”
To view the debugging information, navigate to Administration Business Process > Workflow Monitoring. You can query for the workflow in question, and see all the information logged during workflow execution.
The biggest advantage of this option: all this happens in runtime. You do not need to restart server, reconfigure anything, or even ask the user to log out and log back in.
But, if you’re debugging across components you may find the information here lacking.
So, which way do you prefer? Comment and let me know!