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