3Architecture That Siebel Workflow Uses

Architecture That Siebel Workflow Uses

This chapter describes the architecture that Siebel Workflow uses. It includes the following topics:

• About the Architecture of a Workflow Process

About the Architecture of a Workflow Process

This topic describes the workflow process architecture. It includes the following topics:

• Architecture You Use to Develop a Workflow Process

• Architecture You Use to Simulate a Workflow Process

• Architecture You Use to Deploy a Workflow Process

• Run-Time Architecture That Siebel Workflow Uses

• Object Hierarchy That Workflow Processes Use

The following topics include more information of an architectural nature:

• Overview of Workflow Policy Objects

• Sequence That a Workflow Policy Uses

Architecture You Use to Develop a Workflow Process

The following figure describes a typical approach to developing a workflow process.

Explanation of Callouts

You do the following to develop a workflow process:

1. Define. You use Siebel Tools to define the workflow process. You create an object definition for the workflow process, define the process properties, add steps and connectors, and so on. For more information, see About Siebel Tools.

2. Save. You frequently save the workflow process to the local database. This database includes repository tables. When you edit a workflow process in Siebel Tools, Siebel CRM stores it in the repository tables. When you deploy this workflow process, Siebel CRM adds it to the run-time tables.

3. Test. You use the Siebel client to test the workflow process. You use the Administration-Business Process screen in the client to administer workflow processes and workflow policies. For more information, see Process of Testing a Workflow.

4. Debug. You use Siebel Tools, the Siebel client, test database to deliver and debug the workflow process. Create workspace and select the workflow where you can modify and debug it locally before you check it into the master repository. To access server components, such as the Server Request Broker, you must debug and test with a server database or test database. You can optionally do the following in Siebel Tools:

   • Check the workflow process into and from your master database.

   • Export the workflow process to an XML file to back it up.

   • Import the workflow process from an XML file to restore it.

5. Verify. To verify that the workflow process works correctly, you can use the Siebel client to run it with the local master or test database.

6. Migrate. You migrate the workflow process from the master database to the staging database or production database. You can use Application Deployment Manager (ADM) to migrate workflow processes from one Siebel environment to another environment.

You can use the following types of files to import or export a workflow process:

• XML file. You can export a workflow process as an XML file.

• SIF File. You can export a workflow process as a sif (Siebel archive) file.

About Siebel Tools

Siebel Tools is an integrated development environment (IDE) that you can use to develop and debug a workflow process. You use the Object List Editor to define the object definition of a workflow process. A workflow process references a project.

You use the Process Designer in Siebel Tools to develop a workflow process. You typically define process properties in the Process Designer but you can also enter configuration information through unbounded drop-down lists. Configuration data is available in the Process Designer but run-time data is not available.

You design and test the workflow process, and then save it to repository tables. Siebel Tools allows you to use a top down development framework to create business logic, beginning with creating a workflow process, and then providing plugable services and data objects that can run the workflow process.

For more information, see Using the Siebel Workflow Development Environment and Using Siebel Tools.

Architecture You Use to Simulate a Workflow Process

You can use the Process Simulator to test a workflow process. Testing your workflow process before you migrate it to the production environment makes sure that it works correctly and that the results meet your business requirements.

The following figure describes the architecture that you use to simulate a workflow process.

Explanation of Callouts

You use the following items to simulate a workflow process:

1. Repository data. The Process Simulator accesses object definitions from the repository that are part of the workflow process or that the workflow process references.

2. Run-time data. Siebel Tools accesses or modifies data during the simulation, depending on how you define the workflow process. It can access data in the run-time database, such as customer data that resides in various fields of an opportunity.

If you run a workflow process from the Process Simulator, then it runs in the Application Object Manager. You can start a workflow process in the Application Object Manager or in a server session of the Workflow Process Manager.

For more information, see About the Testing Tools.

Architecture You Use to Deploy a Workflow Process

It is not necessary to deploy changes to the Siebel runtime repository or to do a merge to deploy a workflow process. You define workspace objects in Siebel Tools and store them in the repository that Siebel Tools uses. You must deliver the workspace process in Siebel Tools and run it as a server task or from the Siebel client.

To deploy a workflow process, deliver the workspace. On delivery, the following happens:

1. Siebel CRM reads the object definitions that exist for this workflow process in the Siebel repository tables, and then writes them, along with deployment parameters, into the run-time tables. For more information, see Delivering a Workflow Process.

2. Siebel CRM makes the workflow process available for use in the Siebel client.

The following figure describes how you use Siebel Tools and the Siebel client to deploy a workflow process.

Explanation of Callouts

Siebel CRM does the following to deploy a workflow process:

1. Marks the workflow process Completed for deployment.

2. Reads the workflow process from the repository.

3. When delivered and thus activated, writes the workflow process to the run-time tables.

4. You can modify some parameters of the deployed workflow process in the Siebel client.

Run-Time Architecture That Siebel Workflow Uses

A workflow process can run as a business service or as a server component in the run-time environment. The Workflow Engine interacts with other server components through the Server Request Broker. The Workflow Engine works as a business service that calls a server component.

• To call a server component that Siebel CRM uses as a specialized service, the Workflow Engine calls the signature for this service. For example:

  • To send an email, the Workflow Engine calls the Communications Server as the Outbound Communications Manager business service.

  • To assign an object to a user, the Workflow Engine calls Assignment Manager as the Synchronous Assignment Manager Requests business service.

  A signature is the definition of a method, the name, the expected parameters, the return values, and any exceptions that exist.

• To call a server component that Siebel CRM does not use as a specialized service, the Workflow Engine uses the predefined Server Requests business service. This business service sends a generic request to the Server Request Broker. For more information, see Server Requests Business Service.

The following figure describes the run-time architecture that Siebel Workflow uses.

Explanation of Callouts

The run-time architecture that Siebel Workflow uses includes the following items:

1. Server Request Broker. For more information, see Server Request Broker Server Component.

2. Workflow Process Manager. For more information, see Workflow Process Manager Server Component.

Server Request Broker Server Component

The Workflow Engine sends a request to the Server Request Broker synchronously or asynchronously, and then the Server Request Broker brokers the request to the appropriate server component. It does the following work:

• Sends asynchronous messages from an interactive server component to the Workflow Engine

• Communicates, synchronously and asynchronously, between the Workflow Engine and batch components

• Schedules repeated server tasks that Siebel CRM runs periodically in the Workflow Engine

The Server Request Broker also does load balancing. If it receives a request, then it routes this request to a server component that resides in the current server. If this server component is not available in the current server, then the Server Request Broker sends it to other servers where the Workflow Process Manager is active. It does this on a round robin basis.

A workflow process also uses the Server Request Broker to resume a workflow process that is waiting. The Server Request Broker periodically queries a database table to identify server tasks that it must resume.

For more information, see Server Requests Business Service and Siebel System Administration Guide.

Workflow Process Manager Server Component

The Workflow Process Manager (WfProcMgr) is a server component that uses the Siebel Object Manager. It runs a workflow process as a business service. It hosts the business object layer and the data object layer that allows Siebel CRM to run multiple object managers and multiple server tasks for each object manager. The term Workflow Process Manager refers to the Workflow Engine and the workflow server components.

The Workflow Process Manager can be in one of the following states:

• Online. The Workflow Process Manager is active and can receive and process requests.

• Not online. For example, Inactive, Shutdown, or Offline. Siebel CRM cannot process requests to the Workflow Process Manager or Workflow Process Batch Manager (WfProcBatchMgr) server components. If Siebel CRM saves a request to the Siebel database, and if it sends this request in DirectDb, then it can resend the request later when the Workflow Process Manager comes back online. If Siebel CRM does not save this request, then the request is lost.

For more information, see Starting a Workflow Process from the Workflow Process Manager.

How the Business Service Determines Where the Workflow Process Runs

The Workflow Engine includes the Workflow Process Manager business service and the Workflow Process Manager (Server Request) business service. To run Siebel Workflow in an Application Object Manager, Siebel CRM starts the workflow process as a business service. The Workflow Engine uses output arguments to send information to this business service and it uses input arguments get information from this business service.

Business Service	Location Where the Workflow Process Run
Workflow Process Manager	The object manager of the Siebel application.
Workflow Process Manager (Server Request)	The Workflow Process Manager server component.

How Siebel Workflow Runs in the Workflow Process Manager Server Component

A Workflow Process Manager server component that Siebel CRM configures and optimizes to run the Workflow Process Manager business service can run a workflow process in the background. The Workflow Process Manager server component works as the object manager that runs the workflow process, including any application logic that the workflow process uses.

The Workflow Process Manager accepts the workflow process name in the following ways:

• Through the Process Name server component parameter. For example, if Siebel CRM starts a server task from the Server Manager or from a repeating server component request.

• Through the Encoded Args server component parameter. For example, if the Workflow Monitor Agent business service or the Server Requests business service sends the request.

If a workflow policy starts a workflow process, then the Workflow Monitor Agent typically uses the Encoded Input Arguments parameter to send input arguments to the Workflow Process Manager. However, setting Encoded Input Arguments in the Component Request Parameters applet fails because it is not in a format that the Workflow Process Manager server component can recognize.

Components of the Workflow Management Server Component Group

Server Component	Alias	Description
Workflow Process Manager	WfProcMgr	The Workflow Process Manager and Workflow Process Batch Manager server components do the following: Acts as the Application Object Manager that runs workflow processes. Are specialized server components configured and tuned to run workflow processes. Are similar to a server component that provides a multithreaded environment.
Workflow Process Batch Manager	WfProcBatchMgr
Workflow Monitor Agent	WorkMon	Runs and monitors workflow policies, and then runs actions when the conditions of a workflow policy are met.
Workflow Action Agent	WorkActn	Logs requests in the action request table (S_ESCL_ACTN_REQ) for a policy group and calls actions that the workflow policy uses.
Workflow Recovery Manager	WfRecvMgr	Polls the Workflow Engine to identify workflow process instances that are running on the Siebel Server. Recovers failed instances and resumes instances that are waiting beyond a due date. For more information, see Recovering a Workflow Process.
Generate Triggers	GenTrig	The Generate Triggers server component does the following: Allows you to define database triggers that Workflow Policies use to identify records that match workflow policy conditions Must be rerun if you create, update, or delete a policy Can be run from the Server Manager command line or through a command line interface. For more information, see Overview of Creating Database Triggers.

Object Hierarchy That Workflow Processes Use

You use Siebel Tools to modify predefined Siebel objects and to define new objects that meet a business requirement for your organization. Just as you use Siebel Tools to modify the data model, modify business logic, and to define the user interface, you can also use Siebel Tools to define a workflow process that Siebel CRM uses to automate a business process for your organization.

The following image includes the Object Explorer window and the Workflow Processes list in the Object List Editor window.

The Object Explorer allows you to navigate between each group of object definitions of a particular object type.

An object type is an entity that you can use as a template that Siebel Tools uses to create an object definition. Siebel Tools displays object types in the Object Explorer.

An object definition implements one piece of the software. It includes a predefined set of object properties, which are characteristics of that piece of the software. Siebel Tools displays object definitions in the Object List Editor.

If Siebel Tools does not display an object type in the Object Explorer, then you must display it. For more information, see Displaying Object Types You Use to Develop a Workflow Process.

Relationships Between Object Types of a Workflow Process

A parent and child relationship is a type of hierarchical relationship that exists between one object type and another object type. The following image illustrates how the Object Explorer displays this parent and child relationship as a hierarchical tree.

If you choose the Types tab in the Object Explorer, then Siebel Tools displays tree items as icons in a hierarchy. An object type that is beneath of another object type is the child of the parent and child relationship. The object type that is above the child object type is the parent object type for the child. A parent object type can contain multiple child object types. For example, WF Process Metric, WF Process Prop, and WF Step are child object types of the Workflow Process object type.

Object Properties

If you click Workflow Process in the Object Explorer, then the Workflow Processes list in the Object List Editor displays a list of workflow processes that the Siebel runtime repository contains. One row in the Workflow Processes list represents one object definition. For example, values in the properties in the Contact-New Order workflow process constitute one object definition.

Siebel Tools displays each object property in one column in the list. You can edit the value of a property. You cannot change the set of properties that constitute an object definition.

You can also use the Properties window to edit the properties of the object definition that is currently chosen in the Object List Editor. Changing a value in the Properties window also changes the corresponding value in the Object List Editor.

This guide assumes that you understand the basics of using Siebel Tools. You must possess the following skills:

• Use the Siebel Tools application, particularly the Object Explorer and Object List Editor

• Define object properties, applets, and applet controls

• Use the Siebel Tools menu bar

• Check out and check in projects

For more information, see Using Siebel Tools and Configuring Siebel Business Applications.