Siebel Tools >  Testing and Deploying Siebel Workflows

Migrating Workflows to Production

Once the workflows are designed and tested, they are marked for deployment by clicking the Deploy button and then checked into the master repository. Deployment of workflow is a two-step process:

1. Using Siebel Tools, workflow definitions are marked for deployment. This is done by clicking the Deploy button in Siebel Tools. This action validates workflow definition.
   1. Siebel 7.7 implements several validation rules for process definition such that the developer will be able to correct them before moving it production.
   2. Validation rules also help weed out any flow errors before it has been run thus reducing the troubleshooting effort and time in production.
   3. After successful validation, this definition will be marked ready for production and will be made read-only. However, it will not be in production until you activate it as described below.
2. Using the Siebel Client, workflows are activated from the Business Process Administration view. The process of activation writes the definitions from the repository tables to the runtime tables for the workflow engine to execute.
   1. The Active Processes applet on this screen does not get refreshed automatically. You will have to query this applet to see the workflow that has been activated.
   2. Activation also registers runtime events, if any are defined in the process definition.
   3. Activation also outdates the previous version of the same workflow, if it is already active.
   4. Activate makes the current version as the Active Version, which means that all workflow instances that are created after this action will use the current active version of the workflow. Currently running or paused instances of the same workflow will continue to use the older version, which is outdated.

From siebel 8.0 onwards, Siebel tools has two buttons Publish button which is used to deploy workflows and Publish/Activate Button which is used to publish and activate the workflow at the same time.

Workflow definitions can be migrated across environments, from development to production for example, using one of the following migration utilities:

• Repository Migration Utility - this utility allows export/import of all repository objects. This utility is best used to migrate workflow definitions when the business is ready to rollout the release (for example, migrate all repository objects).
• Workflow export-import utility - this utility allows incremental migration of workflow definitions. Using Siebel Tools, one would export the workflow from one environment and import the workflow to another environment. Import of workflows can be done in one of the following ways:
  • Using Siebel Tools, you would import the definition into the repository of the target environment. Then the definitions are ready to be activated. This approach ensures that the version of the workflow definition that exists in the repository tables and the runtime tables are the same.
    
  • Using Siebel Client, you could import the definitions directly into the runtime tables. This approach bypasses the step of writing the definition into the repository tables of the target environment and activation from the Siebel Client. This would cause the latest version of the workflow definition in the runtime tables, used by the workflow engine, to be different from the version that resides in the repository tables. This approach is good for testing a workflow in a different environment but is not a best practice recommendation for migrating workflows across environments.
    
    

Testing Workflows

Most workflows can be tested using the simulator. However, there are different mechanisms such as event logging to test and debug workflows in production. Many developers during the early stage of development use Workflow Simulator to quickly verify function of the workflows. The following section describes the architecture of the Process Simulator, setting up the environment, and other mechanisms in testing workflows.

Process Simulator Architecture

Developers can use the workflow simulator hosted in Siebel Tools to debug workflows. To use the simulator, you need to have mobile client installed. The mobile client can connect to any database (for example, development or test) that has the test data needed to debug a workflow. Long running workflows and those workflows that invoke server components cannot be debugged using the Simulator. During debug, the process variables are displayed using the dynamic watch window.

During simulation, Siebel Tools and the Mobile Client communicate via an inter-process communication mechanism called Shared Memory. Control commands such as "run to next step" or "continue to the end" are sent from Siebel Tools to the Mobile Client. The Mobile client executes such commands and responds with the status of the workflow such as values of the process properties to Siebel Tools for display in the watch window.

Simulator has improved from its predecessor in the following areas:

• Simulation of interactive workflows, for example, workflow with the User Interactive step
• Simulation of workflow with runtime events

The following diagram illustrates the architecture from the end user point of view.

It is possible for Siebel Tools and the Mobile Client be connected to different databases such as local database and server database respectively. Latest definition of Workflow from the Siebel Tools repository will be transferred automatically across to the Mobile Client for simulation. Sub processes referenced within the main process will also be transferred on demand to the Mobile Client thus making it possible to simultaneously develop and simulate of main process and sub processes. However, Siebel highly recommends using a server/development database for Workflow development and simulation.

Environment Setup For Process Simulation

In order to run a successful process simulation, setting the respective environment is extremely important. This section describes various aspects of setting up the right environment.

Mobile Client Setup

1. Install Mobile Client on the same computer where you have installed Siebel Tools.
   1. Siebel Tools cannot use Mobile Client from a different computer.
   2. Siebel Tools cannot use thin client for simulation.
2. Install the same version of Mobile Client as that of Siebel Tools. Using the same version is important in order to be in sync with the schema and SRF file.
3. Make sure Siebel Tools and the Mobile Client connect to databases with the same schema and seed data. It is preferred to use single database for both Siebel Tools and Mobile Client.

Siebel Tools Setup

1. Install Siebel Tools on the same computer where you have installed Mobile Client.
2. Install the same version of Siebel Tools as that of Mobile Client.

Database Setup

1. Make sure Siebel Tools and Mobile Client connect to databases with the same schema and seed data.
2. It is preferred to use a single database for both Siebel Tools and Mobile Client.

Setting Up Debug Options in Siebel Tools

From Siebel Tools, click on the menu item View > Option. This will bring up the option dialog as shown. Click on the Debug tab. Specify the following parameters:

The following screenshot shows an example where the Siebel Client is installed at D:\7.7\18014\TWSiebel directory:

Starting a Workflow Simulation Session

1. Complete design of a workflow.
2. Validate it for any errors.
   • Siebel 7.7 implements several validation rules for process definition such that the developer will be able to correct them before moving it production.
   • Validation rules also help rule out any flow errors before it has been run thus reducing the troubleshooting effort and time during simulation.
3. Right-click on the designer canvas will show the Simulate context menu.
4. Selecting Simulate on the context menu will open up the workflow simulator.
5. The simulator will display the workflow you selected in read only mode. As shown in the following pictures, there are four buttons on the top of the simulator canvas for the four debug actions. These buttons should be enable/disable based on what actions are available in the current stage.
6. Start Step will be highlighted with a bright red color indicating that it is ready to start.
   
   

1. If the watch window is not enabled already, right-click on the simulator surface and choose watch window context menu item. This action will show the watch window.
2. Click on Start to start simulating the process. (Siebel 7.7 documentation mentions that the developer needs to go to Inbox screen on the Mobile Client to initiate a simulation session. However, this is no longer necessary.)
   1. Start button on the Simulator canvas will launch a new instance of the Siebel Client.
   2. If there exists a Mobile Client instance from a previous run of the workflow simulation, Siebel Tools will reconnect to the same instance, thus saving the time to bring up a new instance, which typically can be very time consuming.
   3. Expect Siebel Tools be in freeze mode waiting for feedback from Mobile Siebel. The following screenshot is an example:
      
      
   4. Once the connection is established between Siebel Tools and Mobile Client, Siebel Tools regains control and highlights a step on the process that is the next step to run.
   5. Next Step, Continue, and Stop buttons are enabled for the developer to take action on.
   6. Status bar at bottom will also display respective text prompting the developer for the next action.

Debugging Scripts Within a Process

Typically, workflows contain several business service steps referring to scripted business services. However, Siebel 7.7 workflow simulator does not allow debug scripts to run while simultaneously simulating workflows. Refer to How Can You Debug Scripts Invoked in a Workflow Process? (Doc ID 478059.1) on Metalink for steps on how to run debug scripts within a workflow process.

Basic steps for setting parameters in the business service simulator:

1. Navigate to Administration - Business Service > Simulator view.
2. Configure business service name and service method name in the top applet:

1. Configure the input property set to workflow process in the Input Arguments applet:

2. Property values will be used to initialize the corresponding process properties (for example, process properties with the same names as property names) at the beginning of workflow process execution.
3. One system property, ProcessName, is required for all workflow processes. Its value needs to be set to the name of the workflow process to be simulated.
4. Another system property, RowId, is required for all workflow processes with buscomp operations. Its value needs to be set to the row id of the primary buscomp of the business object of the workflow.
5. Inspect the output property set of workflow process at the end of process execution in the Output Arguments applet.

Using Event Logs for Troubleshooting

More detailed information on the execution can be viewed in log files by setting event logs. Events used for logging are as follows:

• Event:  Workflow Engine Invoked (EngInv)
  Description:  Trace methods invoked and arguments passed
• Event:  Workflow Definition Loading (DfnLoad)
  Description:  Trace process and step definitions loaded into memory
• Event:  Workflow Process Execution (PrcExec)
  Description:  Trace process instance creation/completion. Trace process property get/set
• Event:  Workflow Step Execution (StpExec)
  Description:  Trace step creation/completion, branch condtion evaluation, business service invocation, business component insert/update

To set the log settings on wfprocmgr:

• change evtloglvl WfPerf=5 for comp wfprocmgr
• change evtloglvl EngInv=4 for comp wfprocmgr
• change evtloglvl PrcExec=4 for comp wfprocmgr
• change evtloglvl StpExec=4 for comp wfprocmgr
• change evtloglvl ObjMgrSqlLog=4 for comp wfprocmgr

Changing WfProcMgr back to default (changes all types to 1) :

change evtloglvl %=1 for comp wfprocmgr

Refer to Siebel Bookshelf > System Monitoring and Diagnostics Guide for Siebel eBusiness Applications > Configuring Siebel Server and Component Logging > About Configuring Siebel Server and Component Logging for more information on event log levels.

Monitor Processes

Externalize Parameters

As best practice development guidelines, workflow definitions should have parameters that are externalized and not hard-coded. Workflows containing hard-coded parameters would require developers to change the definition when the workflows are migrated between environments and executed. For example, if the workflow is sending emails to a list of customers and the parameter is hard-coded with the customer list, the workflow would not work correctly in the production environment. Developers need to make sure that such input arguments are read in dynamically.

Refer to the Example 5: Externalize parameters to be used by workflow from Siebel Workflow Best Practices (Doc ID 477992.1) on Metallink for a detailed example.

Troubleshooting of Workflows in Production Environment

Workflows in production environment can be debugged in one of the following manners:

1. Turn on tracing on the corresponding component, Workflow Process Manager, Workflow Process Batch Manager, Application object Manager and view the event log files. For details on how to turn on tracing, refer to the Business Process Designer Administration Guide or How Can Tracing Be Increased for Workflow Process Manager and Workflow Process Batch Manager? (Doc ID 476283.1) on Metallink.
2. Turn on monitoring level to 3-Detail or 4-Debug. At this level, each execution of a process (whatever component it is run from) will record state and process properties' values for each step. The information is then available in the Site map > Administration - Business Process > Workflow Instance Monitor > Process Instances/ Step Instances. Such levels of monitoring affect performance of the workflow engine. Hence such settings should be used for troubleshooting purpose only.
3. You can run the workflow process from the business service simulator using the business service Workflow Process Manager. Complete the following steps:
   1. Navigate to the Site Map > Administration - Business Service > Simulator.
   2. In the top applet, create a new record and set the following fields:

1. In the Input Arguments applet, create a new record, and set the Test Case # field to 1. Open the Property Name field, which opens up a multi-value applet.
2. Click the New button and set the following fields and then click the Save button:

Property Name: ProcessName 
Value: <the name of the workflow process>

1. Repeat above step for any parameter that should be passed to the process, especially RowId if needed.
2. Click the OK button in the multi-value applet opened in step c.
3. Click the Run button in the top applet of the Simulator view.

You can for instance set the monitoring level to 4-Debug, launch the workflow, and look at the process execution information as described in step 2 above.

Communicating Workflow Errors to Siebel Technical Support

Workflow errors can be communicated to Siebel Support professionals in one of the following ways:

• Send the log files (as was done previously) generated by turning on tracing

• With the exception of service flows, when a workflow process encounters an error, the process state will be persisted with an In-Error status. If a workflow process encounters an error in one of its sub-processes, the sub-process state will also be persisted. Both the error code and the error message are saved in the process properties. Administrators can examine the error codes and error messages in the process properties applet of the Workflow Process Instance Admin view. When a record is selected from the All Workflow Process Instances applet, the related instance applet lists its parent and child processes. You can communicate the error code and the error message to Siebel Technical Support for further assistance.

Troubleshooting - Common Workflow Errors

The following lists some commonly encountered errors for Workflow Process Manager.

1. You activated your workflow process but it is not executing when the corresponding run-time event is triggered.

Verify that runtime events were reloaded. Navigate to Site Map > Administration - Runtime Events > Events. Choose applet menu Reload Runtime Events. In order to verify if a process has been triggered, turn workflow monitoring on. Refer to Siebel Bookshelf > Siebel Business Process Designer Administration Guide > For Administrators: Administering Workflow Processes > Administering Workflow Processes in the Run-Time Client > Monitoring Workflow Process Instances.

1. When workflow is triggered by runtime event Display Applet, the workflow is triggered the first time but not subsequently. Why?

Since the DisplayApplet event is a UI event, and the default web UI framework design is to use cache, the event only got fired when the first time no-cached view is accessed. The workflow got triggered whenever the event is fired and worked correctly. To make the field still work in this scenario, you could explicitly set EnableViewCache to FALSE in the .cfg file.

1. If a buscomp has code on WriteRecord and the runtime event fires on WriteRecord, which occurs first?

WriteRecord runtime event is in essence a Post-WriteRecord event and will be fired after the buscomp code is executed

1. After you triggered workflow from a runtime event,you do not get the row-id of the record on which the event occurred.

Runtime event passes the row-id of the object business object (for example, primary business component) and not the row-id of the business component. Retrieve the row-id of the active business component using search specs (for example, Active_row-id (process property) = [Id]  defined as Type = Expression and BC = BC name)

1. Encountered the error<Cannot resume Process <x-xxxxx> for Object-id <x-xxxxx>. Please verify that the process exists and has a waiting status.

This error typically occurs in the following scenario:

1. A workflow instance is started and paused, waiting for a runtime event.
2. The runtime event fires. The workflow instance is resumed and ran to completion.
3. The runtime event fires for a second time. Workflow engine tries to resume the workflow instance and fails, since the workflow instance is no longer in a Waiting state.

Deleting existing instances will not help. You should ignore the error message and proceed. Steps a - c need to occur, in that order, in the same user session for the error message to be reported. As a result, the error message would disappear when the application is re-started.

Also, Purge only works on stopped/completed instances. In order to delete persisted/incomplete instances, you will need to manually stop the instances first.

1. How do you access a different business object from a workflow process?

Workflow architecture restricts the use of 1 business object to a workflow. Use a sub-process step to access a different business object.

1. Cannot initiate process definition <process name>

Verify that the workflow process exists, process status is set to Active, and that the process has not expired.

1. When you simulate a workflow, upon start, workflow does not run.

If a Start step has out-going branches that have runtime events, the simulator will be waiting on the event and it will never get to next step. You could either remove the event for simulation, or add a default branch.

1. Simulator does not respond after completing the user interact step

Make sure all the branches out of User Interact Step have the respective runtime events associated with the actions performed on the user-interact step.

1. How do you change a version on the workflow?

You can change version from a numeral to zero. You can do that by launching Siebel Tools with the /editseeddata switch. Right-click on the process you want to reset the version to. Select Reset version. Make sure that you do not have a version 0 before you reset.

Do not reset the Siebel standard seed workflows. Customers will have to revise version 0 to version 1 and use it for production. Siebel standard version 0 will overwrite every time you upgrade to a newer version of Siebel.

1. Can a workflow of the same name exist in 2 separate projects?

Yes. Workflow Name and its version make it unique within a repository.

1. There are certain workflows where there are some standalone steps that are not connected with the main body of the workflow. But now the validation prevents deployment of the workflow with these steps. Is there an option to bypass this check?

Currently, there is no option to bypass the validations before you deploy a workflow. Workflow definitions are validated for a safe execution to avoid server crashes.

1. You receive the error message:

OMS-00107: (: 0) error code = 4300107, system error = 27869, msg1 = Could not find 'Class' named 'Test Order Part A' 
OMS-00107: (: 0) error code = 4300107, system error = 28078, msg1 = Unable to create the Business Service 'Test Order Part A'

Make sure at least one .srf file is copied to \\SIEBEL_ROOT\objects\<lang> directory.