s_escl_req table – use with caution?

Just trying to dramatize title a little 🙂 , looks impressive isn’t it. Well, jokes apart just wanted to discuss what I have learnt while working with this table.

This table is related to a functionality in siebel known as Workflow Policy (WFP).As most of us know that workflow policy is frequently used functionality in Siebel. Those who are new to Siebel I will just give an overview of workflow policy (WFP) as covering WFP in this post is not possible. But will be having more about WFP in next few posts.

Workflow policy is a functionality provided by Siebel to us to execute workflow processes asynchronously based on certain conditions. It also allows us to send email asynchronously by retrieving values by means of query when certain condition is met.

So, what’s so different about WFP is that it works on database layer rather than Business Layer when compare to functionalities like workflows and business services but it doesn’t skip business layer altogether as you have to do fair bit of configuration in tools to make it work.

As soon as condition specified in WFP is met, it creates a record in s_escl_req.
That record picked up my Workflow Monitor Agent to execute the specified workflow. Now due to some unknown reasons (till now, but working towards root cause) there are duplicate records created in s_escl_req which can result in WFP to get stuck and results in creation of backlog in s_escl_req and other request that are put in that table cannot be executed until and unless the problem is resolved.

So, if anytime you see more than 1000 (number can vary depending on number of WFP in application) in s_escl_req it should be considered as a problem and should be attended immediately. The general way of resolving it

  • Delete the erroneous record from s_escl_req table
  • Commit the changes
  • Restart the associated Workflow Monitor Agent

Word of caution: The deleted request will not be processed again so think twice before deleting it in production.

Moral of the Post: Don’t depend on workflow policies too much as they are create a bottle neck and can hamper functionality of whole application if you have major functionalities working by way of WFP. Breakdown in one functionality would result in faliure of others as well. So, if you have anything that you would like to execute asynchronously then depend on Workflows to do it. You can read the following post to do it.

9 Responses to s_escl_req table – use with caution?

  1. Workflow Policies are a very useful tool, when used correctly. The problems you describe are usually avoidable with good error handling, and Workflow Policies are still the simplest robust way to handle the common integration task of translating many updates into a single action. WFPs also allow you to capture ALL data changes, including through EIM and cloned BCs. The big risk with WFPs, which you allude to, comes from not applying your business-layer configuration to these database-driven tasks.

  2. Workflow Policies are a very useful tool, when used correctly. The problems you describe are usually avoidable with good error handling, and Workflow Policies are still the simplest robust way to handle the common integration task of translating many updates into a single action. WFPs also allow you to capture ALL data changes, including through EIM and cloned BCs. The big risk with WFPs, which you allude to, comes from not applying your business-layer configuration to these database-driven tasks.

  3. Hi,

    Nice post ..I will appreciate to have more on this post …Can we have a squential draft of creating a workflow policy and then testing it ..with a proper exapmle…It will deginitely be gr8 help..
    Thanks for posting such articles..

    regards

  4. Hi,

    Nice post ..I will appreciate to have more on this post …Can we have a squential draft of creating a workflow policy and then testing it ..with a proper exapmle…It will deginitely be gr8 help..
    Thanks for posting such articles..\

    regards

  5. Hi,
    one more query here??
    why dupliate records are coming in s_esc_req table??is alwas truncating and bouncing is not a good practice if iam not wrong??
    in other scnaro order is completing but asset reflecting??why??

    Rgards,
    satya.

  6. The reason of multiple/duplicate records in s_escl_req table is bcoz of the way Siebel builds the trigger which gets created on executing Generate Trigger job. For example if you implement WP and wants to execute a WF if value of column xyz = “abc”. Now for this config Siebel create two triggers. One for Insert and one for Update. Trigger created for Insert is fine i.e. when new record gets inserted with value “abc” then a corresponding record is inserted in s_escl_req table. But the real issue is with trigger of update record. It is build like if a record gets updated and if new or old value of column xyz is “abc” then insert a record in s_escl_req. Now the consideration of new value as “abc” is ok. But if value of column changes for “abc” to any other value still record gets inserted in s_escl_req which is unwanted. Later such records are catered properly by Workflow Monitor Agent component but still insertion of extra unwanted records can’t be avoided unless you modify the trigger 🙂

Leave a Reply

Contribute