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!!!

Read Only Field N: Applet Version

Implementing C.R.U.D. can be cruel...


Read only syndrome was bugging me for quite a while as we had a requirement of making multiple columns to be readonly on certain applets depending on multiple conditions. First thought that burst into mind was using dynamic toggles but conditions were complex and number of applets to address was huge. The worst part was underneath field should remain editable for update by interface workflows. Once again situation demanded to dive into mysterious siebel to have a simpler solution and boy, siebel seldom disappoints.

I was able to achieve this by using Applet Level user property "Read Only Field N". This user property allows to make field read only on UI, by allowing field updates from workflow or scripting. The syntax goes like



Name: Read Only Field 1
Value: 'FieldName', 'ConditionFieldName'

where

FieldName = Name of the field which we want to be readonly
ConditionFieldName = Name of the field which specifies condition to be read only


However the siebel catch here is, the applet class should be "CSSFrameListQuoteItem". It may work for other classes but for me it did the trick with this class. So , please test thoroughly that it is not impacting your other functionality when you change class.


Happy Configuration!!

The Lost Functions

"Wide acceptance of an idea is not proof of its validity" - Unknown


Despite No-to-script being the motto of every project its usage is inevitable. Sometimes a two line code is easy to implement rather complex configuration. There are lots of methods and events exposed by siebel for developer's ease. In fix-run situations it is tough to remember all the methods/events available. Bookshelf definitely possess the entire wealth but here i will post a cheat sheet which has juiced up all the methods and events exposed by the siebel except special ones.

Siebel eScript cheat Sheet

This sheet can help someone to decide for which event to go who rarely use scripting or can help to better prepare for an interview.

Happy Scripting!!

PS: If you are not able to d/l this file let me know preferrable email id. you will have personalized copy of this.

Email Manager

Policy programs are like cheat codes. If a requirement permit asynchronous nature then policy program is gold. The key feature of policy program is it doesn't need compilation after changes and can be modified run time. Anybody good at SQL can toy around with the powers of policy program.

Recently we were asked to implement email functionality for SR status update changes. As obesessed with PP, i thought of writing new policies for it instead of modiying existing workflows. Things were smooth, life was cool and eveything was deployed successfully. However to my horror emails were not getting triggered. Policy conditions were configured correctly as record was getting created in S_ESCL_REQ table on violation. Situation worsened when email was going via F9 functionality. After some debugging it was observed that Email Manager Task was not running because of which emails were not flowing out of the system.

Email Manager component in conjuction with Communications Outbound Manager is the trump while using policy program of type "Send Message" for sending emails. Both are part of the Communications Management component group. Email Manager uses profiles set up in Communications Manager. The Communications Outbound
Manager does verification of the profile. Below is the snapshot of how Email Manager sends email message.

1 - Workflow monitor agent reads record from the S_ESCL_REQ and inserts a record into the S_APSRVR_REQ table for workflow actions that invokes the Send Email workflow policy programs.

2 - Email Manager picks up records from the S_APSRVR_REQ table, setting their status from QUEUED to ACTIVE then to SUCCEEDED during the course of the execution.

3 - Outbound Communications Manager is invoked to log onto the SMTP/POP3 profile and send the outbound message.

So in order for smooth email bombarding Email Manager should be up and task should be running.

Happy e-Mailing!!