Workflow Background Process not Processing DEFERRED records (Bad Design)

In this post I would like to highlight a common mistake that developer usually made while designing the workflow, some of so serious that it crash WBP (workflow background process).Context of my example is - Oracle Applications...

First -
Wrong flow – If you look into flow from Activity1, activit2,activity4 and END, everything looks look fine logically, but if we look closely into Activity1 has 2 outcomes.
1. Default and
2. Yes
If outcome is Yes then workflow will progress to Activity2 but at the same time we have default outcome from activity1 which will progress the flow to END activity and that’s it, workflow for this sub process (if it flow is part of big process) will come to end and it doesn’t matter whether activity 2 and activity 4 complete or not.

No doubt workflow will progress activity2 and 4 and execute their code but if their outcome has some impact on the activities after sub process in my example that this type of design will not work.

Second - 
RELATIVE WAIT TIME

Many a time I notice that people has included LOOPS in the workflow, as shown in Activity7 and Wait activity. We have to be very careful when we design the Loops, Wait is a Deferred activity and will be progress by Workflow Background Process (WBP). WBP will Pick WAIT as soon as it is in DEFERRED status, Pay additional attention when you design loop especially while define the RELATIVE_TIME attribute for Wait.

BAD Design Example –

Let’s say we have defined “RELATIVE TIME” = 5 minutes, in my example when Activity7 got processed with outcome as “Type”, workflow progress to WAIT and sit in DEFERRED status. As soon as WBP executed, it will pick/process it and the flow goes back to Activity7 (in my example) but if underlying logic in Activity7 still not satisfied and outcome (result) from this activity is again “Type” flow again progress to WAIT from where WBP will pick it again in next run.

Now Suppose the underlying logic for the Activity7 will not be satisfied for 2 days in that case Whenever WBP run, it will pick and process WAIT activity which in turns goes to Activity7 and again back to WAIT. Now suppose you have schedule to run workflow background process every 10 minute, in that case, WAIT activity is eligible (relative time = 5 minutes) to be picked up after every run and in 1 hours WBP will process the WAIT activity 6 times and also Insert 6 additional records in WF_ITEM_ACTIVITY_STATUSES_H table and in 1 hour just for 1 Order Line 6 records will be inserted (calculate if you have 5000 such order lines and your workflow execute for every 10 minutes, my simple guess many of you might like to kill the process).

As a Thumb rule when we design the LOOPING in Workflow, look at the Main activity for the LOOP and see how much time it will take to progress and then Design the WAIT activity with appropriate RELATIVE_TIME, in my example since I know ACTIVITY7 will not progress for 2 days, it is appropriate to put RELATIVE_TIME in wait activity = 2 days. In such case WAIT process will be in Deferred status for 2 days and will not be pick up by WBP after every 10 minutes.

I have seen numerous issues, when customer complaints that WBP is not progressing the activities in the Deferred status, but actually WBP is do processing these activities but as the WAIT activity is going back to DEFERRED status (because of loop) customer feels like WBP is not picking these records. Many a times customer has Wait activities records that are eligible to be processed by WBP are in millions and WBP runs for days and finally got terminated ( result – some of the lines are that in Deferred status ( but not Wait activities) also not processed by WBP and has serious business IMPACT

Another downfall of this bad design is over a short period of time your WF_ITEM_ACTIVITY_STATUSES_H table grow out of proportion and it result in serious performance issue for WBP.

So think logically carefully when ever you plan to add Loops.

Hope that Helps.