Re: Handling failures in osworkflow actions

Hmm, this should be fairly doable.

How about a post/pre-function which sends the email, if it fails, then 
the whole thing gets rolled back. The calling code then handles the 
rollback appropriately.

Try it and see, in theory it should all work!

On Monday, April 28, 2003, at 06:45 PM, David Hauver wrote:

> I'm trying to integrate osworkflow into a queue-based processing 
> approach.  The general idea is that a message gets placed into a 
> queue, a processor picks it up from the queue and performs the 
> appropriate action, and then moves the message on to the next queue.  
> At a high level, this is very similar to osworkflow (queue == step).
>
> Are there any recommended approaches for integrating 
> application-specific code into a workflow, especially if there is a 
> chance of failure?  The specific scenario I am looking at is sending 
> an email out to the appropriate party whenever a message enters a 
> queue, and then moving the message on to the next queue.  I'm 
> wondering where the code that sends the email should be placed, 
> considering that I do not want the message to get moved out of the 
> queue if sending the email fails, possibly due to the mail server 
> being down.  Moving from step A to step B is dependent on the e-mail 
> being successfully sent.
>
> I was wondering if anyone had a recommendation for how best to do 
> this, based on their own experiences with osworkflow. I see a few 
> possibilities:
>
> 1) The code that sends the e-mail out is part of the queue processor, 
> and external to the workflow.  Only after the e-mail gets succesfully 
> sent does the queue processor call doAction() for the appropriate 
> action.
>
> Pros: easy to tell if email fails.
> Cons: action can be performed without email being sent.
>
> 2) The email gets sent in code that is registered as a pre-function.  
> If successful, it sets a variable. A conditional result to move to the 
> next step checks the variable's status, and an unconditional result 
> sets the workflow entry back to its original step and status.
>
> Pros: action is integrated into workflow. Email always gets sent on a 
> state transition.
> Cons: harder to tell if email fails - the action failure is hidden 
> from the workflow.doAction() caller unless they check the workflow 
> entry's step/status after calling doAction(). Even then, it might be 
> tough to tell the reason for failure. Much messier workflow 
> configuration.
>
> Any recommendations on an approach to take would be highly appreciated.
>
> Thanks,
>
> Dave Hauver
> [email protected]
> Vecna Technologies
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf