Error Workflow Process

The biggest difference between time and space is that time can't be resued. So better reuse the existing one in order to earn some time. Reusability is one the fundamental block of siebel. Be it configuration or scripting, siebel always advocate usage of existing ones. One to enrich this feature is "Error Process Name" property at the workflow level.

This property is used to specify the workflow process which should be executed whenever error occurs in the base workflow. One can create a generic workflow for error logging mechanism and can specify that workflow in the "Error Process Name" property. This workflow can act as universal exception handler for logging error across the multiple workflows.


One of the interesting features here is the passing process properties from the base workflow to the error workflow. It should be kept in mind in order to pass user defined process properties to the error workflow, we must redefine those process properties in the error workflow, giving the same name and type.
For eg, if one has to pass the name of the base workflow to error workflow, one has to define common process property in the original workflow and in the error workflow and then this user property in the base workflow should be populated with the name of base workflow.

so don't reinvent the wheel, just realign it....

Happy Configuration!!!

Hidden Methods - UpdateRecord

Siebel is mysterious. Along with those magical user properties there exists hidden methods that can do wonders for you. It is a real Archimedes-Eureka-Feeling when we encounter any of these hidden methods in siebel.

Recently i was struggling with Update Siebel Operation Step in Workflow with some context issue till i found "UpdateRecord" hidden method for "Inbound E-mail Database Operations" business service. This method is not displayed in the available list of methods for this business service but however can be comprehensively used in the workflow (we can verify with Business service simulator).

Usage:

Business Service: Inbound E-mail Database Operations

Business Service Method: UpdateRecord

Method Argument:

BusComp - Name of the Business Component

BusObj - Name of the Business Object

Id - Row ID of the record to be updated

Field: FieldName1 - Value to be updated

Field: FieldName2 - Value to be updated

Field: FieldName3 - Value to be updated

The only curse with usage of these methods is if Id is not valid it throws error in processing.

Happy Configuration!!

Old Value - New Value

The requirement of auditing the value changes in key fields is one of the common requirements. One can use audit trail or resort to activities for maintaining log. We also faced the same requirement of capturing the Old Value-New value pair in activities, whenever status of Service Request is changed.

There are multiple script less solution available for this. But the one which excited us was the introduction of "GetOldFieldValue" method of buscomp. As per bookshelf

"This method can be called by using a script in the PreWriteRecord event to retrieve an old field value if needed. This method takes an input parameter, which must be a valid field name, and returns a string containing the old field value."

Primarily this method is used for EBC's but one can use this method for any buscomp with effective use. We created a workflow which is used to read older value and new value and then create activity.

1 - Fetch Old Value

Business Service Name: SIS OM PMT Service

Business Service Method:Invoke BC Method

Input Argument

BC Name : Servcie Request

MethodName: GetOldFieldValue

Param 0: Status

OutPut Argument

Type: Output Argument

Output Argument : Return Property Name

Property Name: OldStatus (input property set created for storing Older Value)

2 - Fetch New Value

Business Service Name: Workflow Utilities

Business Service Method: Echo

Input Argument

OutPut Argument

Type: Business component

Business component Name: Service Request

Business Component Field: Status

Property Name: NewStatus

3 - Create Activity

Business Service Name: Inbound E-mail Database Operations

Business Service Method: InsertRecord

Input Argument

BusComp : Action

BusObj: Service Request

Field: SR Id : Object Id

Field: Description: "Status has been Changed from" + [&OldStatus] + "to" + [&NewStatus]

Echo still remains one of the most mysterious yet powerful method. This workflow can be invoked via runtime event on Service Request buscomp.

Happy Auditing!!

50 Up!!

“Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital.” - Aaron

As i write my 50th post, it feels good to be quantum of blogosphere. Here we will discuss one of my favorite topic "Workflows". A lot has been suggested about activating multiple workflows but vital thing in this post is importing/exporting multiple workflows from one repository to another and deploying and activating them in one go.

I have posted two workflows here. One is for multiple export of workflows and other is to import and activate the exported workflows. One can download from below links.

1 - Multiple Workflow Export

2 - Multiple Workflow Deploy and Activate

Usage:

Multiple Workflow Export -

Import this workflow in your tools. Modify following input process properties as per your need.

ExportFolder: This is the name of the directory where you want to keep the export of XML files.For eg, "D:\Workflow_Export"

Repository: Name of the repository from where Workflow should be exported.For eg, "Siebel Repository"

SearchSpec: Search criteria to identify what all workflows should be exported.For eg, [Process Name] LIKE 'SR*' AND [Status] = 'Completed'

Once these parameters are modified simulate the workflow and check the export directory. This directory will house all the XML export files of the Workflows given in the searchspec. Once simulation is over check the "NumOffWF" parameter which will give us the count of workflows exported. The only glitch here is it doesn't list the name of workflow which has failed during export operation.

Multiple Workflow Deploy and Activate -

Import this workflow in your tools where you want to import the extracted files. Modify following input process properties as per your need.

ImportFolder: This is the name of the directory where input files are housed.For eg, "D:\Workflow_Export"

Repository: Name of the repository where workflows should be created.For eg, "Siebel Repository"

ProjectName: Name of the project to which all workflows will be associated.For eg, "Service Request Workflow"

SearchSpec: This searchpsec is used to filter out workflows we want to deploy.For eg, "[Process Name] Like 'SR*' AND [Status] = 'In Progress'"

ActivateSearchSpec: This searchspec is used to activate workflows.For eg, [Process Name] Like 'SR *' AND [Status] = 'Completed'

Once these parameters are modified simulate the workflow. "NumOffWF" parameter after each step will give the number of workflows which are processed. The only issue is it doesn't list name of workflows which has failed during the operation.

If you are looking only for multiple workflow activation and comprehensive error logging then one can visit vinay's World. Once again thanking all for your support and comments.

Happy Deployment!!

"IS UPDATED" in Workflow Policy

Statuary Warning: This is not for the old horses.

My romantics with siebel goes on and so Siebel mysteries. Newbies better be careful while using "IS UPDATED" condition in the workflow policies. It can lead to undesirable/wrong results. Lets consider below problem statement.

"Any service request which is not worked within 2 hours of assignment, i.e. Assigned status , should be escalated."

The obvious solution which comes in mind is to configure workflow policy with duration and Owner Id update condition.

Unfortunately it didn't work for me. The issue when using "IS UPDATED" criteria in combination with Workflow duration is that criteria is considered only at the time of the first update by the user. Until the configured policy duration has completed, all subsequent updates to the record are discarded by Workflow Policy Manager. As a result at any point of time only one record is available in "S_ESCL_STATE" table for this policy. At the end of the configured duration, Workflow Policy Manager looks at the other configured criteria on the policy. If they evaluate to true policy Action is fired. If they do not evaluate as configured, then the record is discarded and the next time the record is updated a new record will is inserted into S_ESCL_REQ and subsequently, S_ESCL_STATE for the duration. At times, this may result in undesirable behavior as follow.

Lets consider we assign a SR to user A at 7:00 AM. As per our configured policy it should be escalated at 9:00 AM if status is "Assigned". User A works on this request and again re-assigns request to user B at 7:30. Now ideally escalation should happen at 9:30 AM and not at 9:00 AM. But if we check "S_ESCL_STATE" table there will be only one record for this policy with END_TM set to 9:00 AM. If user B doesn't work on this request till 9:00 then this request will be escalated resulting in unwanted escalation.

There are multiple workarounds for the above mentioned issue.

a) Workflow Batch processing

b) Batch workflow policies

One potential solution could be to maintain "Last Assigned" date field and set this to current timestamp whenever assignment/re-assignment is happening. Use this date in the searchspec to find records which are in assigned status for more than 2 hours. Create workflow Process Batch Manager RCR with following parameters:

SearchSpec: [Last Assigned] < (Timestamp() - 0.084)

WorkFlow: SR Escalation Workflow

This will process all records which are in Assigned status for more than 2 hours.

ORA-03135: connection lost contact

November started with blues. I recently encountered very strange issue with the custom workflow components. I am not underrating the term strange here but i am in habit of landing into these troubles frequently. My workflows were failing on server intermittently with error log suggesting

ObjMgrLog Error 1 000000044ccc6f90:0 2010-10-31 11:27:23 (oracon.cpp (3255)) SBL-DBC-00108: An error has occurred preparing a Sql statement.

SQLParseAndExecute Execute 5 000000044ccc6f90:0 2010-10-31 11:27:23 ORA-03135: connection lost contact

I was not sure what was causing this failure as there was no issue in the workflow as it was working fine in other environment. The more concerning factor was that there was no specific pattern for the failure of this workflow. But the best part with siebel is regardless of issue your luck never runs out. I found similar post on the siebel support[ID 762888.1] and resolution was to set the below parameter on the custom workflow process manager component level:

Name:OM-Model Cache Maximum parameter

Value: 0

We monitored our workflows for some time and bingo they started running again in good shape. But the change in this parameter comes with disclaimer regarding performance check.

FINS Data Transfer Utilities

The best thing while working on siebel is you are never short of options. Recently we had requirement of updating a Service request from contact. Finally we did that using "EAI Siebel Adapter" business service. However during that time i came across another business service "FINS Data Transfer Utilities" popularly known as DTU business service. As i was not having prior knowledge of it going by the rule of not learning swimming lessons while drowning i decided not to go for it. Lately i have tried to explore this service and trust me it can do wonders.

Here is a sample example update of Service Request from contact. We need to follow below steps in order to understand strength of this business service.

1 - Navigate to Site Map. Go to Administration - Application -> Data Map Administration tab. Create a new Record with following options:

Name: Service Request Test

Source Business Object: Contact

Destination Business Object: Service Request

Here the source business object specifies where data should come and Destination busobject specifies where data should go.

2 -In Data Map Component we specify mapping of the child business component. There needs to be one root business component and other child business component in the map. This is really handy while creating quotes and quote line items from Opportunity. Or any other instance where multiple BC's are under scanner.

Name: SR Update

Source Business Component: Contact

Destination Business Component: Service Request

3 - In Data Map field we specify field to field mapping, data from which source field should go to which destination field. However source/destination field could be of following types based

on our requirement:

Field: BC field

Parameter: Input argument to business service

Expression: combination of BC field or Parameters

The most important thing here is the Key field, which helps in matching source record with destination record during update operation. More of this is given in "siebel finance bookshelf".

4 - Once data map is done, our job is very simple. We need to write a workflow which can call this business service and invoke that workflow on contact write

record. Sample workflow should look like.

Method Invoked is: DataTransfer

Parameters which we have passed are:

Operation - Update : It specifies which operation we need to perform. Values are Insert,Update,Delete and Upsert

InitBO - Contact : Initiator BO

InitBC - Contact : Initiator BC

DataMapObj - Service Request Test : Name of the Data Map

&Status - Closed : Status value we need to set for SR

&SRId - '288-70710' : SR Number for which we need to set status. This could be process property. I have hard coded for testing purpose.

5 - Create a runtime event which invokes this workflow on writerecord of Contact BC. Once reload is done try to see the magic.

This business service is of immense help if used efficiently and can be of real help in scenarios involving update/insert of multiple business components.

Learning Swimming and Siebel.

Batch Processing

Batch processing is integral part of any development and is must in cases involving escalations,auto-assignments or bulk emailing. Siebel provides multiple ways to do batch processing but one to choose depends on the requirment at hand. Lets consider an escalation scenario which involves SR reassignment to Manager when commit time is reached if it is not closed. The two possible approaches to achieve this are:

1 - Workflow Policies with Batch Mode set to True

2 -Workflow Process Batch Manager component

It can be real dilemma which one to use as they say "you always have choice of selecting action but not the consequence". Both approaches have its own advantages. Lets discuss each of them.

Workflow Policy with Batch Mode

1 - Create a Workflow Policy as following based on "Service Request" object with condition

Status <> Closed

Commit time >= Current

Set the batch mode to True. Specify the action which will run the workflow to reassign SR.

2 - We need to schedule a task on server to execute a batch file or script which executes server manager command lines to execute workmon to run in batch

mode.

Workflow Process Batch Manager

1- Create a Repeating Job for component WorkflowProcess Batch Manager.

2 - Set the SearSpec parameter to "[Status] <> Closed AND [Commit Time] >= Today()"

3 - Set the Workflow Process name to the desired workflow which is used to reassign SR

Technically either of them could be used to perform the desired escalation but me inherently being an follower of KISS(Keep it Short and Simple) principle will go for second option as it is easy to manage Workflow Process batch manager Job as compared to the batch Policies. However, if we have to execute a sequence of action apart from run process then batch workflow policies should be considered. Batch workflow policies are also quite handy in sending consolidated email for multiple requests.

Please feel free to put your thoughts across which one should be used for the cause.