Thank you for the quick reply John, please see my comments inline: Hi Raphael, > > I had been expecting such a question for a long time. I don't know the > whole context of your processes, but I would suggest to let the > participant set a field indicating success or failure. > > There is already the field named "__result__" which is used by > expressions like <equals> to carry results. > > So why not use a field and then depending on the value of that field > branch the process in the "happy path" or the "fail path". It all > depends if you want fail paths to be part of your process definitions. > You could also leverage subprocesses to keep "main" process > definitions concise and have fail paths as subprocesses not > encumbering the happy path.
This indeed seems like the straightforward way of accomplishing this however it would result in a '_if' expression after each single participant. My simple prototype involves about 20 participants expressions (only 5 different participants but the same participants get called multiple times with different parameters). I can see more complex use cases potentially involving 50 or more such calls, that's why I'm looking for a more systematic solution. Another technique would be to wrap participants in subprocesses so > that you have participant + its exception handling stacked together. > > There are two kinds of subprocesses, the ones found in the main > process definition [document] and the external ones (usually called > via their URL or via their name (bound at the engine level), URL > accessed one are probably easier to manage). This would probably be better indeed but I'm still uncomfortable with the amount of duplication. > I'm glad to help, it's an essential subject. Best regards, > > -- > John Mettraux - http://jmettraux.wordpress.com I really appreciate your help, it's great to see you being so proactive. Another solution I was thinking about would be to have that __failed__ field like you suggested but have each participant check for it. If it's there the participant simply returns the workflow item right away without doing any work until it reaches an error handling participant. Thinking about it though it seems I would be just implementing a try/catch/finally expression. So is there a fundamental reason why we can't or shouldn't have such an expression? I have been toying with the idea of implementing it myself but I would like to get your opinion first. Merci, -- Raphael. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-users?hl=en -~----------~----~----~----~------~----~------~--~---
