We are designing a number of custom Java Tasks that will implement ActivityBehavior interface in order to execute external asynchronous tasks. The external agents will call the processEngine.signal(executionId, objectPayload) method to signal to the Java task at which time it will mark itself complete and allow the engine to proceed to the next task.
For our exception handling scenarios, we know that any of these services (remote calls) could encounter System or Business failures. When that happens, a resolution action will be taken externally after which it is desirable to 're-invoke' the service call that failed (and NOT the whole Orchestration).
By going through the documentation, and reading the ActivitiInAction Book, it appears that the only way to do this would be to have each of these Service Tasks define two transitions (success and failure) within the process definition, and in the ActivityBehavior implementation class, take the appropriate transition. The failure transition could then be routed back to the same service again through gateways. But as you can imagine, doing this for each one of the nodes in the Orchestration is cumbersome, error prone, and makes the visual diagram extremely busy.
Does anyone have a suggestion of a good way to implement this behavior, such that:
(i) At a time when appropriate external resolution has been taken place for a long running asynchronous java Task, we can have the engine re-execute the same task with the original payload, but without having to graphically draw this for each Java Task/Custom Task node in our process?
I have had some exposure to Oracle BPMN and ESB products and I remember that they had a feature where a task could mark itself as failed, after which it goes into a recovery console, and a user can signal it for 'reinvocation' at a later time when offending conditions have been fixed. The engine would resume the process and retry that task (instead of having to start over from scratch).
