Thanks for the replies -
"kukeltje" wrote : 1: Exception handling like in jBPM 3 is still on the todo
list (look in Jira).
Actually, I was more trying to understand what options are there to recover the process
after an UNhandled exception - assuming a job fails due to an automatic action throwing an
exception, what state will it end in, and how can we recover it (change the offending
variable, restart the failed activity, etc.)? I understand this is not trivial, but it is
still very important for us as we are orchestrating a large number of systems on a
critical process.
"kukeltje" wrote : For technical retries to external systems etc, I do not think
jBPM should reinvent (reimplement) the wheel (like they are doing in drools with
reinventing workflow) but leverage what is already there, JBoss ESB or JMS or your custom
code/custom node. For business level retries, what you describe is an option. Might
require a custom node though.
Agreed - I am a bit worried at implementing a wait / loop / wait / loop custom node,
though (e.g: is now after given date? if so, proceed, alse thread.sleep(10000) and then
re-enter activity through self-looping transaction) - I tried it and it technically works,
but does it risk hanging the whole PVM? And would it behave correctly with persistence
assuming e.g. JBoss is restarted? [I can provide the code if you think it could be useful
for a test case]
[BTW, this was triggered by "duedatetime" in timers throwing a
org.jbpm.api.JbpmException: no 'jbpm.duedatetime.format' in current environment,
adding the string to the jbpm.cfg.xml does not solve it - I could not find any JIRA for it
- anyone had any success in using duedatetime?]
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253281#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...