Handling failures in osworkflow actions

David Hauver <[email protected]>
Newsgroups gmane.comp.java.open-symphony.devel
Organization Vecna Technologies, Inc.
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.