RCR VS Long Running Workflow

Posted on January 21, 2011 by neel • 13 Comments

This is more of a discussion post than information post. I would like to discuss two approaches to same problem and take feedback what do you guys think is better.

Requirement:

Trigger a workflow process every 15 minutes asynchronously.

Solution Approach 1:

Create a Job in Administration Server Management – Jobs View for Workflow Process Manager component.
Set the Repeating flag to true and configure the repeat interval as 15 minutes.
Submit the job

Siebel will create a instance of this workflow every 15 minutes which will be executed by Workflow process manager component.

Pro’s

Simple and easy to deploy
Flexible as you can change the time interval any time
Siebel take cares of everything

Con’s

Can lead to problems in case Siebel services are abruptly stopped (for example submitting multiple requests instead of 1 every 15 minutes)
Overhead on Object Manager and Workflow Process Manager component as every time a new workflow instance needs to be created and submitted
Difficult to debug the problem

Solution Approach 2:

Make your workflow as Long Running workflow
Include a wait step and put wait time as 15 minutes
Change your workflow logic to execute your functionality and then wait for 15 minutes before starting again.
Create a Job in Administration Server Management – Jobs View for Workflow Process Manager component.
Submit the job

Pro’s

Less overhead on Siebel and Workflow process manager component (My assumption and reason for inclination toward this approach)
With proper error handling in place it is fairly easy to debug in case of problem

Con’s

A little less flexible in terms of interval changes. You have to modify and deploy the workflow

They both seem viable options for the requirement. For some unknown reason I am inclined towards approach two as it seems to be less overhead on the components. I don’t have any concrete data to base my decision upon that is why I am throwing this out there, may be somebody out there knows exactly what is better.

Visitors to this post, also read:

http://twitter.com/gokuro kw

an additional con to #2 is that you cannot get the workflow instance to pickup changes in case you revise the workflow process. You will have to cancel the instance (which is not easy) and then submit your job again to get it started.
http://siebel-essentials.blogspot.com @lex

Hi Neel, I would opt for #1 because keeping a workflow process “alive” (even if it waits) for so long doesn’t sound a good idea to me.

my 2c

@lex
- Anonymous
  
  @lex
  
  What about mixing the two approaches ???
  
  configure my RCR to execute once a day for example 1:00 in morning
  add a time check in my workflow and end at 12:45.
  
  Which means once instance per day ???
Nuson Fretz

I like the.rcr approach. less memory instance and u have better visibility to each task status
second I not sure long running will persist over wpm restart unlike rcr, u don’t have option to use wpbm because wpm sjd not be overloaded with too many asyc process as it can slow the processing other real time wfs. and there are few more. good question never thought abt z lrw as
alternative. to rcr,next time I will keep this also ain’t thoght process
Maksimch

Lrwf = Memory and db cursor drain
Sandeep Unnikrishnan

#2 you can add a get lov value(the wait time) step in long running flow to bring in more flexibility.
so seq will be like
1)get lov val(wait time)
2)call sub process(actual flow to be recursively called)
3)wait step(with val retrieved)
Jimit Parikh

Hi Neel,

Thanks for this post. This is really very usefull information. But this will not helpfull to replace the RCR based on Workflow Process Batch Manager.

Cheers,
Jim
Shiv Prateek

I wil still prefer teh first approach reason same as alex keeping a WF process alive for long is not preferable . Also The Long running WF also has some time lag i was last time trying to work with 5 min delay and the process were being repeated at 5+ min i am still not sure why it happened also if we are calling the WF in sync i.e a normal WF calls so once an instance of called WF error’s out the full loop logic will end .
Shiv Prateek

I wil still prefer teh first approach reason same as alex keeping a WF process alive for long is not preferable . Also The Long running WF also has some time lag i was last time trying to work with 5 min delay and the process were being repeated at 5+ min i am still not sure why it happened also if we are calling the WF in sync i.e a normal WF calls so once an instance of called WF error’s out the full loop logic will end .
Shiv Prateek

I wil still prefer teh first approach reason same as alex keeping a WF process alive for long is not preferable . Also The Long running WF also has some time lag i was last time trying to work with 5 min delay and the process were being repeated at 5+ min i am still not sure why it happened also if we are calling the WF in sync i.e a normal WF calls so once an instance of called WF error’s out the full loop logic will end .
http://profiles.google.com/ashishatnitk ashish tripathi

I wanted to ask a question not related to this topic. Its related to BIP Reports. I have a requirement to sort records in descending order based on a date column. Date Formate is like
4/13/2011 2:13 AM. So the record which is latest should be shown first. How to achieve this.

Thanks
Ashish
Email: ashishatnitk@gmail.com
Akarsh

Also if an Update step is included in the workflow for a bunch of records based on a search spec you would need to loop inside the workflow which is not recommended. Instead workflow batch process manager does a better job
Raj

Hi,

I think First one is better solution, becasue Long running workflow is not advisable by Oracle. We should avoid long running workflow.

Option 3 : We can create Workflow Policy and sent Duration as 15 Min. Which will excute Workflow for recordwise on every 15min.

Hope this will help.

Cheerss….

R Gupta

RCR VS Long Running Workflow

Visitors to this post, also read:

Share this:

Rate Post

Related Posts