Workflow performance case study: Dont Repeat History, Learn from it
By gaurav.verma on Jun 11, 2007
A Sanskrit Shlok underlying the importance of careful planning
PrefaceThey say: "Those who do not know history are condemned to repeat it."
But why repeat history if you dont have to?
Many questions come to light on this topic of discussion:
- Is there a better way of designing conditional implementation in workflow?
are the merits/demerits of repeated checking of a particular condition
as opposed to executing something when the actual condition happens?
What are the performance implications?
- Are there workflow APIs available which simulate event based subscription model?
- What are the performance advantages of using the basic Workflow APIs that simulate this event based subscription model?
case study discusses the performance benefits of keeping unnecessary
looping execution in workflow design a a bare minimum and if possible,
eliminate it. If there are several short timed loops in the workflow
design, that get executed very often, the bad news is that the System
spends valuable resources spinning the wheels in vain.
intended audience is workflow designers, support personnel and Oracle
Apps DBA alike. This case study can potentially help users to design
their workflow more optimally and succintly, which would have a minimal
impact on the execution. The I/O profile and time taken for Workflow
Background Process bears out all this information. As far as possible,
trends have been depicted from the customer's Production system.
Summary of Learnings
- It pays to know the published
Workflow APIs. The Workflow Developer Guide is a good place to start.
Spend time reading the fine manual. More information can never hurt.
pays to spend time and effort in evaluating re-design of loops in
workflow design early, especially since once initiated, a specific
version of workflow runtime data does not automatically get updated
after a newer version of workflow design is uploaded (through WFLOAD)
- Poor design involving WAIT and poll activities in a loop can cause infinitely running Workflow Background Process (FNDWFBG)
activities in loops should be replaced with
OE_STANDARD_WF.STANDARD_BLOCK or WF_STANDARD.BLOCK APIs and
- Simple design changes can bring HUGE performance benefits, especially when a lot of volume is involved