siebel

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 erro

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 b

"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.

An excellent free book providing tips and tricks fro improving your Oracle CRM On Demand application. - by Mathieu Emanuelli and Joann Alejandro Bravo Cheers!

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 t