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.

3 Comments at "s_escl_req table – use with caution?"
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.
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
Comment Now!