I'm trying to implement a custom ActionExecutor and am having a hell of a time trying to figure out exactly how to communicate back to oozie.
Specifically, I need to be able to force the action to require human intervention before continuing. In other words, not traversing down the error path, nor retrying the action. I also need some way of sending back some text output to the user via the oozie console. Between the 4 different ErrorType enums and the 12 different WorkflowAction.Status enums and the plethora of undocumented Context and WorkflowAction methods to convey state back to ozzie, I'm at a loss as to how any of this is supposed to work. And yes, I have read the one doc page on this topic ( http://oozie.apache.org/docs/3.3.2/DG_CustomActionExecutor.html). It didn't help. It also suggests a distinction between synchronous and asynchronous actions but says nothing about how that distinction is implemented. So far I've tried various combinations of the following: 1. context.setEndData: Takes a Status enum, but will only accept OK, ERROR or KILLED. (Aside: the associated javadocs omit FAILED as an option). 2. context.setExecutionData: it accepts an external status, thus just moves the problem to end(...). Also, if setting my text output into the Properties object, I see nothing about it in the oozie web console. 3. throwing an ActionExecutorException with ErrorType.NON_TRANSIENT. This seems work when it is thrown from inside start(...), but not when thrown from inside check(...). By "work", I mean that the workflow status is SUSPENDED, and the action status is START_MANUAL. 4. calling registerError with a custom exception and ErrorType.NON_TRANSIENT, and throwing that from inside check(...); same result as above. So, how exactly are we to communicate the custom state of an action back to oozie, particularly from the check(...) method? - Alex
