3 Replies Latest reply on Sep 3, 2009 8:13 AM by kukeltje

    Handling failure of automated activities

    emp.tyres Sep 2, 2009 5:37 PM

      Hello -
      I am very, very happy with Jbpm4, and I am currently looking for a hint on best practices for handling failures of automatic activities invoking retries or failovers - for example, a whose class connects to an external server (which may be down at the time of calling)

      I understand I can signal the failure in the return variable and model the retry / failover process explicitly with a switch, but that seems rather cumbersome.

      My preference would be to have the possibility to implicitly choose from the activity the outgoing transition, pointing to a "retry" state which periodically re-enters the automatic activity with a timer. I am not sure if it is possible to define that an exception in the java class with exception-handlers, because the docs seem incomplete.

      Also, about exception handling, I could not find any hints on these two points:
      1- what possibilities are there to "recover" a process that has encountered an unhandled exception?
      2- will other process instances running in the same PVM keep going in such a case?

      Any pointers woud be really appreciated.

      Bye and thanks.

      • 2273 Views
      • Tags:
        • 1. Re: Handling failure of automated activities
          kukeltje
          kukeltje Sep 3, 2009 4:50 AM (in response to emp.tyres)

          1: Exception handling like in jBPM 3 is still on the todo list (look in Jira). 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.

          2: Yes (at least tin 4.1, afaik, in 4.0 there was a small issue, that error jobs could block the rest)


            • Actions
          • 2. Re: Handling failure of automated activities
            emp.tyres Sep 3, 2009 6:51 AM (in response to emp.tyres)

            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?]

              • Actions
            • 3. Re: Handling failure of automated activities
              kukeltje
              kukeltje Sep 3, 2009 8:13 AM (in response to emp.tyres)

               

              "emp.tyres" wrote:
              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.

              That is precisely what the jBPM 3 exceptionhandler was (partly) for. Doing 'some things', restarting the activity not being one of them, but if you use async for this, the job is rolled back and retried. Normally, 'changing the offending variable' would /could be done in an adition actionhandler e.g. on the transition that is taken in case of an error. The error has to be caught then in the actionhandler and the 'error transition' name has to be returned.

              "emp.tyres" wrote:

              "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?

              Yes as it can result in thread starvation

              "emp.tyres" wrote:

              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]
              Not fullly, because it might be in a transaction and you could have had multiple retries already that get lost.

              "emp.tyres" wrote:

              [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?]


              In 4? I myself not, but I've seen posts in the forum of people that have successfully used it.

                • Actions