Siebel Workflows Overview

When you use Siebel XML to integrate with Siebel Integration Objects, the interface uses a Siebel Workflow. You use Siebel to define a Siebel Workflow to emit or to receive Siebel XML using Siebel HTTP transport services. The topics in this section discuss how to create and use workflows that use the supported transport services.

Note
This section is intended as a supplement to the documentation for Microsoft BizTalk Adapter for Siebel eBusiness Applications and is not intended as a substitute for Siebel documentation. For complete and up-to-date information about Siebel Workflow and policy topics, see the Siebel Bookshelf documentation.

Siebel Workflows

A Siebel Workflow is a series of Siebel business services that are linked to accomplish a business task. You create workflows using the Siebel Client Workflow Administration screens. You can invoke workflows using one of the following methods:

• Using a workflow policy.
  
• Using a run-time event (Siebel Event).
  
• Using a script (eScript or Siebel VB).
  

The following topics briefly describe how to invoke the workflow through a policy condition. For more information about policy and other methods, see the Siebel Bookshelf documentation.

Invoking Siebel EAI Workflows Using Policies

This topic was last updated on: December 5, 2007

A workflow policy is defined by a set of conditions that executes a set of defined actions. A Siebel workflow policy consists of the following:

• Conditions that define circumstances, based on changes in the state of a Siebel database.
  
• Actions that define steps taken when conditions are fulfilled.
  

Creating a Workflow Policy

Creating a policy to invoke a workflow as an action involves the following steps:

1. Define an action to be executed after a policy is triggered. Use the Run Integration Process program.
   
2. Create a policy by setting conditions and selecting appropriate policy groups and actions.
   
3. Start the policy by selecting an activation date.
   
4. Run the Generate Triggers server task from Server Administration windows to set the conditions to be monitored.
   
5. Start the Workflow Monitor agent after editing with the appropriate policy group (to which your policy belongs) to evaluate whether to perform an action.
   
6. Start the Workflow Action Agent server task from Server Administration windows to perform the action.
   

For more information about the previous steps, see the Siebel Bookshelf documentation.

Siebel Workflow: Outbound

This topic was last updated on: December 5, 2007

When a Siebel Workflow is triggered based on a Siebel policy, run-time, or script (eScript or Siebel VB) event, the result is the generation of a Siebel XML document that is put on one of the Siebel transports.

For example, when you add a new account in the Siebel Call Center application, you can design and configure a workflow to be triggered on the account transaction. You can design the workflow to extract the data for the new record, convert it to Siebel XML, and then put it on an MQSeries message queue.

In this example, the Siebel Workflow process executes the following series of Siebel Business Services:

1. Calls the Siebel EAI (enterprise application integration) Siebel Adapter, which queries for the newly updated account record, and puts the data in its original internal structure into memory.
   
2. Calls the Siebel EAI XML Converter, which converts the data into an XML message.
   
3. Calls the Siebel EAI MQSeries Transport, which puts the newly created XML message into the appropriate MQSeries message queue.
   

After the message is put into the message queue, Microsoft Adapter for Siebel eBusiness Applications retrieves it. The following workflow sequence illustrates the previous steps.

Siebel Workflow: Inbound

This topic was last updated on: December 5, 2007

A Siebel Workflow that is triggered by an external event starts by receiving a Siebel XML document, which is put on one of its transports. The result might be the update of a Siebel record using the XML as input: for example, when a new account is added in another customer relationship management (CRM) system but must also be updated in the Siebel Call Center application. You can design and configure a workflow to receive or listen on an MQSeries message queue. Upon receipt of the XML message, the workflow processes the transaction into the Siebel system to update the record.

In this example, upon receipt of the Siebel XML message in the message queue, the Siebel MQSeries Receiver server task initiates a Siebel Workflow process, which in turn executes a series of Siebel Business Services as follows:

1. Calls the Siebel EAI (enterprise application integration) XML Converter, which converts the XML message into Siebel internal format.
   
2. Calls the Siebel EAI Siebel Adapter, which applies the newly updated account record based on the methods defined in its service.

Siebel CRM - How To Call a Workflow Asynchronously?

This Article is about Siebel CRM 7.X Workflows and Runtime Events. It tells you how can we use them to our advantange.
We all want the response time of our Application to be as fast as it can and we do everything that we can to achieve that. I am going to tell you about a way which can help you to reduce the response time without actually reducing any functionality. Siebel can execute workflows in two ways.

• Synchronous
• Asynchronous

Synchronous Execution : When workflows are executed Synchronously then user gets the control back only when the workflow has finished it execution.

Asynchronous Execution: When workflows are executed Asynchronously then user gets back the control immediately and the workflow is submitted to workflow process manager (WPM) as a job to be executed. WPM then executes the job later.

Often we have a functionality where large amount of processing needs to be done on an object which user is not going to use access right now. I can explain it with an example.

When user clicks copy button on a opportunity or quote we want certain custom entities to be copied over but which user will not access at that time but later.

So, we can reduce our response time by just copying the quote or opportunity synchronously and placing the code of copying of custom entities in workflow and executing that workflow asynchronously.

There are two way to execute a workflow asynchronously

• Workflow Policy
• Runtime Event and Business Service (BS) Combination

Workflow Policy is pretty traditional method of executing a workflow process.
You create a policy. Enter the conditions Specify the workflow to be executed Generate Triggers
I wouldn’t go into details of creating a policy but I will tell you some disadvantages of using Workflow Policy

1. Slow Execution
2. Difficult to setup
3. Not Reliable and Error Prone

But from siebel 7.7 onwards we have another more robust, efficient and quicker way to do that which is Runtime Events and Business Service.

Runtime Events Workflows - Part 2

This Article is about Siebel CRM 7.X Workflows and Runtime Events. It tells you how can we use them to our advantange.

In this article I will tell you about the actual process of Setting up Runtime Event and Business Service assuming you have working knowledge of both. If you want to know the basics of these please see other posts of my blog.

Just one important thing that you should know about runtime evetns is that they are executed even before the Business Component Events. To explain it better I am taking an example where our requirement is to execute a workflow when you click Submit Oppty button on Opportunity Form Applet.

1. Goto Administration ==>Runtime Events Screen
2. Goto Action Sets View
3. Create a New Record in the Action Set View of Runtime Events Administration Screen
4. Enter Any Name in the Name Field of the Action Set List Applet
5. Create New Record List Applet Below it
6. Enter

Name = “TestRuntimeEvent” ;
Action Type = “Business Service” ;
Sequence = “1″

1. In the Form Applet Below Enter the Following Details Business Service = “TestBS” ; Business Service Method = “TestMethod”8. Click Menu ==> Reload Runtime Events Make Sure that you have Active Flag checked in both List Applets.

You are done in Action Set View. Now Goto Events view and Follow the steps given below

Click New and Enter the Following Information
Sequence = 1 ;
Object Type = “Applet” ;
Object Name = “Opportnity Form Applet” ;
Event = “InvokeMethod” ;
Sub Event = “Submit Oppty” ;
Action Set = “TestRunTimeEvent”

Conditional Expression should be given if you want the restrict the execution of this Runtime Event to certain conditions and Action Set Name is always the name of the action set that we created.

Click Menu ==> Reload Runtime Events.

Now we are going to write the code in the busines service which will actually result in the execution of Workflow Process Asynchronously.

1. Go To Administration ==> Business Service
2. Create a Business Record with name “TestBS”
3. Create a Record in List Applet for Service_PreInvokeMethod and choose Programming Langauge as “eScript”

Write the Following code in Code Window inside the function Service_PreInvokeMethod

if(MethodName == “TestMethod”)
{
var svc;
var child;
var input;
var output;
var rowid;
var bo = TheApplication().ActiveBusObject();
var bc = bo.GetBusComp(”Opportunity”); // Change the BusComp name with the name of the BusComp you want to execute the workflow with
svc = TheApplication().GetService(”Asynchronous Server Requests”); // Don’t change this - Actual BS that is responsible for submitting a job to WPM
input = TheApplication().NewPropertySet();
child = TheApplication().NewPropertySet();
output = TheApplication().NewPropertySet();
input.SetProperty(”Component”, “WfProcMgr”);
rowid = bc.GetFieldValue(”Id”);
// We would like to pass the row id of the Current record on which the user is working - You can pass more than one arguments
child.SetProperty(”ProcessName”, “Service Agreement - Agreement Status”); // Workflow process you want to execute
child.SetProperty(”RowId”, rowid); // passing the values
input.AddChild(child);
svc.InvokeMethod(”SubmitRequest”, input, output); /// invoking the business service method
svc = null; // nullfiying the objects
child = null;
output = null;
input = null;
return(CancelOperation);
}

And you are done!!!!!!!!!

Siebel CRM - Workflow Debugging through Logs

When we talk about Siebel, I think Workflows are the most common term that we come across after Object Manager. We can achive really complex functionality through worklfows but what it means is that debugging them is equally complex. We generally test workflows through Simulation but if we were debug workflows in real time it can be quite painful and time consuming. A simple method to debug workflow is to increase the log level for Workflow Process Manager (WPM) component. But if somebody has ever tried that he can vouch that it can be quite a headache to go through that log (believe me it is a lot and it can go up in MB’s even if the workflow is of moderate complexity). And what’s more is that most of the information that is contained in that log is useless and not realted to workflow functionality. So here in this article I am going to present a pretty simple technique which can help you to get just the right amount of information that you need to debug a workflow.
Instead of increasing the log level of complete WPM component if you just increase the log level of just selective sub-components that should do the trick. I will list down the Sub-Components that you need to increase the log level to get just the appropirate information that you need.

• Workflow Definition Loading
• Workflow Engine Invoked
• Workflow Process Execution
• Workflow Step Execution
• SQL Tracing

Just increase the log level of the above said components from 1 to 4 and you are done !!!!!
To get logs from dedicated client you need set the Environmental Variable on your system. To understand the process of doing that Please go through my old post where I have explained about siebel logs.

How to invoke a Workflow Process?

Workflow is one of the most commonly used functionality in Siebel. They provide us the way to automate simple and complex business process without much trouble.

Workflows can be invoke in several ways in Siebel.

• Runtime Events
• Scripting
• User Property
• Workflow Policy

In this post I will be giving example of how to invoke workflow process in different ways.

>> Runtime Events

We can specify runtime event at

Workflow Process: To define a runtime event in the workflow process, follow the steps given below

Select the connecter after the start step as shown below

Siebel Workflow Connector

In the Workflow Step Branch: window below provide the details at which you want to this workflow to execute. For example If I want my workflow to be invoked at write record of Action buscomp then I will enter the following detail

Event Object Type: BusComp
Event Object: Action
Event: Write Record

Runtime Events

>> Administration Runtime

Runtime Events are available in Administration - Runtime Event Screen.

We have all the corresponding events which we find in BusComp, Applet and Application such as WriteRecord, PreWriteRecord, ChangeRecord, and PreQuery etc.

We need to remember one thing here is that Runtime events fire before the corresponding object event.

For example

WriteRecord runtime event for object type BusComp will fire before BusComp WriteRecord event

To call a workflow from Administration Runtime event define a Action Set and Enter the information as shown below

Business Service: Workflow Process Manager
Business Service Method: RunProcess
Business Service Context: “ProcessName”, “Name of workflow”

Even Spaces matter in Business Service Context value after there is a space after comma and then workflow name. Now you can define the event according to your requirement which will call this Action Set

Administration Runtime Events

>> Scripting.

To call a workflow process from scripting you can use the code given below

var svc = TheApplication().GetService(”Workflow Process Manager”);
var Input = TheApplication().NewPropertySet();
var Output = TheApplication().NewPropertySet();
var rowId = this.GetFieldValue(”Id”);
Input.SetProperty(”ProcessName”, “GEAE Activity Approved by SSD Notification”);
Input.SetProperty(”Object Id”, rowId);
Input.SetProperty(”Opportunity Id”, vOppId);
Input.SetProperty(”OwnerEmailAddress”,v_OwnerEmail);
svc.InvokeMethod(”RunProcess”, Input, Output);

Here any property that you set in input property set will be assigned to corresponding process property in the Workflow Process (WFP) as in the above example

Input.SetProperty(”Opportunity Id”, vOppId);

above line of code will result in process property called “Opportunity Id” in WFP to assigned the value of variable vOppId.
>>User Property:

You can use Named Method property on BC to invoke a workflow. Example

Name: Named Method 1
Value: “New Record”, “INVOKESVC”, “Example”, “Workflow Process Manager”, “RunProcess”, “‘ProcessName’”, “Example Wrokflow”, “‘RowId’”, “[Id]”

To see the detail explanation of user property read the following post

>>Workflow Policy:

Workflow Process can also be called from workflow policy. We can Define a workflow policy (WFP) in Administration – Business Process >> Policy.

Steps to create Workflow Policy are not in the scope of this post. We assume here that you have created a workflow policy record and specified appropriate conditions.

In the argument section choose

Argument: Process Name
Value: Workflow Process Name

Hope this helps

Siebel Workflow Process an Introduction

Siebel Workflow is a software tools that lets us automate business processes with help of workflow processes. Some characterises of workflow processes are

• They are created, edited and deployed in Siebel Tools.
• Their changes in workflows is SRF independent though they are created and deployed in Siebel Tools IDE.
• They are administered through Administration - Business Process Screen in Siebel Client.

Siebel Tools provides the design interface of Siebel Business Process Designer. The Mobile Web Client (the run-time client) provides the debugging interface of Siebel Business Process Designer. After workflow processes are designed and debugged, they are written to repository tables for deployment from the administrative interface in the run-time client.

Workflows can be accessed through Object Explorer in Siebel Tools as shownWorkflows can be in 3 types of status

• In Progress: When you create a new process this is the default state. In this state you can edit and make changes the workflow process.
• Completed: Workflow process goes into this status after we deploy the workflow
• Not in Use: Status after we expire the workflow.

There are 3 buttons available to use to change the status of the workflow as shown in below

• Deploy: Deploy the workflow and change the status to Completed
• Expire: Expires the workflow and change the status to Not In Use
• Revise: Creates a copy of the workflow with status of the New workflow as In Progress.

There are various types of workflow processes available

• 7.0 Flow: This type is to provide backward compatibility with existing Siebel 7.0
• Long Running Workflows: Workflows that can last for hours, days or months
• Interactive Flow: Workflow that takes user across Siebel views.
• Service Flow: Executes a set of operations upon even invocation. This is the most common type of workflow process we created.

In next posts about workflows we will create a simple workflow process to understand it better.

Workflow Processes Configuration Overview

Workflow Processes allows you to define your company’s business processes using the Process Designer in Siebel Tools. Using Workflow Processes, you can define a process that consists of process steps such as start steps, decision points, subprocesses, or business services steps to complete tasks. A task can be completed with either a predefined business service or a custom business service. Predefined tasks include updates to the Siebel database, notifications (such as an email or page), integration messages to external systems, and calls to invoke server tasks. Custom tasks can be defined by using Siebel VB or Siebel eScript.

Workflow Processes Administration Overview
Workflow Processes can vary from a simple process such as entering a product order to a complex process such as managing call center workflow. Complex processes can comprise multiple smaller processes. Workflow Processes are administered through the Administration - Business Process views in the Siebel Client.

Using Workflow Processes
Workflow processes can be invoked from events in the Siebel application or from external systems. Within the Siebel application, a process can be invoked from a workflow policy, an event (such as an insert of a record or a button click), or a server component. From an external system, processes can be invoked using COM or CORBA.

Workflow Process Types
Siebel Business Process Designer has four types of workflow processes that characterize run-time behavior. The processing type is set in the Workflow Processes list editor of Siebel Tools, using the Workflow Mode field. The workflow process types are as follows:
■ 7.0 Flow. A 7.0 workflow process provides backward compatibility for existing Siebel 7 (pre-7.7) workflows.
■ Long Running Flow. A long-running workflow process is a persistent workflow that can last for
hours, days, or months.
■ Interactive Flow. An interactive workflow process navigates the user across Siebel views.
■ Service Flow. A service workflow process executes a set of operations upon event invocation.

Workflow Management Server Components
The Workflow Management server component group includes the following server components:
■ Workflow Process Manager (WfProcMgr)
■ Workflow Process Batch Manager (WfProcBatchMgr)
■ Workflow Monitor Agent (WorkMon)
■ Workflow Action Agent (WorkActn)
■ Workflow Recovery Manager (WfRecvMgr)
■ Generate Triggers (GenTrig)

Workflow Process Manager and Workflow Process Batch Manager
The Workflow Process Manager server components act as the application object manager to run
workflows. The Workflow Process Manager server components are specialized server components configured and tuned to run workflow processes. Like all server components, the Workflow Process Manager server components provide a multi-threaded environment. The Workflow Process Manager uses the Siebel Object Manager framework and runs workflows as a
business service. The Workflow Process Manager hosts the Business Object layer and the Data Object layer. It is a scalable architecture with the ability to run multiple object managers and multiple tasks for each object manager.
NOTE: The name Workflow Process Manager refers to both the Workflow business service (referred to as the Workflow engine) and the workflow server components.

Workflow Monitor Agent
The Workflow Monitor Agent executes Workflow policies. Workflow Monitor Agent monitors policies, and executes actions once the policy conditions are met.

Workflow Action Agent
The Workflow Action Agent processes requests logged in the action request table (S_ESCL_ACTN_REQ) for a policy group and invokes all actions linked with the Workflow policy being processed.

Workflow Recovery Manager
The Workflow Recovery Manager polls the Workflow engine to check workflow instances running on the server. The Workflow Recovery Manager recovers crashed instances and resumes instances that have been waiting beyond a due date.

Generate Triggers
Generate Triggers allows you to create database triggers. The Workflow Policies module of Siebel Business Process Designer uses these database triggers to identify which records may match policy conditions. The Generate Triggers server component needs to be rerun whenever new policies are created or deleted. You can run the Generate Triggers server component from either the Server Manager graphical user interface, or command line mode.