1 Reply Latest reply on Oct 11, 2013 1:48 AM by Maciej Swiderski

    How to commit session, even on Gateway split failure

    mvermand Newbie



      We are working with JBPM 5.2.


      In a process we have a XOR Split gateway.

      It might happen that none of the expressions used in the constraints are met, which will lead to:


      ERROR [org.drools.persistence.SingleSessionCommandService] (http-/ Could not commit session: java.lang.IllegalArgumentException: XOR split could not find at least one valid outgoing connection for split Gateway


      I know you can add an "always true" constraint, but sometimes a developer might forget this (and never notice in the unit tests) or building an alternative path might be time-expensive.


      I hoped that the session would have been committed, even with the error. Then we could build some logic (based on NodeInstanceLog) that retrieves these failed Gateways (or other workItems) and let a power user decide what needs to happen (by calling complete on the workItem with the appropriate parameters).


      So my questions are:


      1) Can we force committing the session, even if a Gateway (WorkItem) fails?

      2) Can we attach a general Error Event Listener to the processInstance or kSession to handle such exceptions and do some logging/alerting/decide upon commit/rollback?

      3) Is it possible to register a custom workItemHandler for the SplitInstance Node class?  (what is the current Handler class and what is the name used for registering?)





        • 1. Re: How to commit session, even on Gateway split failure
          Maciej Swiderski Master

          unfortunately this is not possible to commit transaction when engine reported error. What you could use instead is to mark a given outgoing sequence flow of a gateway as default one, for example when you don't want to move to any of the real process flows you can always move it to a catch event that allows you to signal it later one to resume the process instance.

          Gateways are not work items so don't have regular work item handlers that implements their behavior, they are covered by SplitNodeInstance.