How does the deferred activity queue up and being processed?

[HYC]

Dear all,

Would anyone tell me how is the deferred activity being queue up and processed?

I saw the behaviour is like this:

1. Run a workflow which have a deferred process to run journal import.
2. Run the workflow again which have a deferred process to run journal import again.
3. I saw both jobs are queue up. But the workflow background engine pick up one by one, not pick up to process two at the same time although there are available standard manager.

Would anyone pls confirm how to config the workflow engine to run the deferred activities at the same time, not one by one. Otherwise, there will be a long queue for deferred process.


Thanks!
Regards,
HY

[pvjpkumar]

Hi,

I am not sure if you talking about any concurrent program here .. I mean to say if the workflow is launched and as a result if any concurrent program is submitted and is processed one by one, it means that the concurrent program is defined in such a way that it is incompatible to itself. So, unless one instance doesnt complete, other wouldnt run.

Login to sysadmin > concurrent > program > define > query your concurrent program and check if it is defined incompatible to itself. If it is, unless one is completed, other instance would not run. Dont change it, as Oracle Development would have done it because they wanted it that way as if two instances are running, they might corrput the data.

If you want the deferred activities to be processed faster, you can define a separate Workflow deferred process only for journal import so that that particular deferred process would process only journals and not other activities.

Hope that helps

Cheers
pavan

[HYC]

Sorry that I did not describe my question clearly.

The concurrent program itself are not incompatible. It can be run simultaneous if directly submitted from Submit Request form.

However, if  we write a program to submit this concurrent program and this program is called inside workflow and deferred to run by workflow background process, we found that the each deferred activity will only be run after the previous one is dequeued. This is not what we expected.

Would anyone pls kindly advise what setting should be set in order to allow dequeu the activities more faster and simultaneiously?

[Arun]

Ah..huh.. Not getting the issue clear !  Anyway, what usually we do is schedule the 'Workflow Background Process' to run in every 2 or 5 minutes so that it will pick up the deferred activities and will process. You can schedule this concurrent program for a particular item_type as well, so that only that item type will be picked up. For example, if you have a WF whcih has deferred activities and which is triggered quite often, you can schedule a 'Workflow Background Process' for this item type specifically. Now, schedule one more instance of this conc pgm without specifying the item type parameter so that all the other WFs will be picked up.

Cheers,
Arun

[HYC]

let me show the data extracted from wf_deferred_table_m to explain the issue:

We have schedule a workflow background process for item type GLBATCH to run every 2 minutes.

From the table wf_deferred_table_m, it shows:
GLBATCH 90869*3047 0 = Ready 1 2/12/2007 7:32:01 PM 2940BAE418A09076E0430AF0084A9076
GLBATCH 90866*3045 0 = Ready 1 2/12/2007 7:32:14 PM 2940BAE418A29076E0430AF0084A9076
GLBATCH 90868*3046 0 = Ready 1 2/12/2007 7:32:10 PM 2940BAE418A19076E0430AF0084A9076

This means there are three deferred activities are the queue.
Each activity will call a program to submit the journal import program

1. The first activity on the queue will submit the journal import program. After the journal import program was completed, the first activity will be removed from the queue (the table wf_deferred_table_m).
2. Then another journal import will be submitted and run. Again, after the journal import program was completed, the second activity will be removed from the queue.
3. Again another journal import will be submitted and run. After the third journal import program was completed, the last one in the queue will be removed and the queue will become empty now.

It seems that there will be always 'one' queue to process the deferred activities, and the deferred activities are processed one by one, waiting the previous to be completed first.

In this case, if the queue is long, and every time one one deferred activity is being processed, it will take a very long time to complete the whole queue.

We wonder whether this is a normal behaviour, and is there any way to speed up the dequeue process.

Please kindly help and advise. This affects the design of the workflow to run.

[Arun]

Hi,

I can see that this is a seeded WF, and I believe you haven't done customization over the seeded version. I believe the issue is with the concurrent program itself. There is an option in cocnurrent pgm definitions to set it as 'one at a time', to avoid conflicts. I think this conc pgm must be of this kind. Not very sure though !

Cheers,
Arun

[HYC]

Hi,

We customize the GLBATCH workflow by adding a process after the journal is being approved. After the journal is approved, it will call the new process to submit journal posting.

But regardless whether this is a customize workflow or not, I want to make it clear with the behaviour of the workflow dequeue process. Would anyone pls help?

[Arun]

Hi,

How do u submit the conc pgm for journel import ?  Is it a customized activity ? In that case, are u using the seeded WF activity to submit the conc pgm or are u calling the fnd_request.submit_request() ?

Cheers,
Arun

[HYC]

We write a stored proc and call  fnd_request.submit_request() to submit journal import.

Is there any diff using the WF submit request and the fnd_request.submit_request()?

Thank you for advise.

[Arun]

Hi,

The seeded WF activity 'Submit Concurrent program' is using the fnd_request.submit_request itself. So I am not sure whether this activity can help you or not ! There is another activity 'Execute Concurrent Program', which will submit and wait till it gets completed. I am bit confused here, and I believe it should be some properties with the concurrent program itself. For some concurrent programs, two instances of that program cannot be run simulataneously. I think this pgm must of that category. Maybe you can search in metalink for this.

Anyway I am just attaching the standard WF for the conc pgm submission.

Cheers,
Arun