Oracle BPEL process: how to ask an administrator for a little attention

Well, I have never thought I would be writing anything longer than couple of words about BPEL. I mean I know it, I have to use it (more like: I am forced to use it), but this is a technology so cumbersome to use that I can't imagine anyone besides BPEL software vendors would promote it.

Anyway here we go. Recently I needed to do something uncommon in one of processes I have to maintain. The systems runs under Oracle BPEL Process Manager v. 10.1.3.5 and this software has a module called BPEL Console where an administrator can keep an eye on the running processes. One of the things the BPEL Console allows administrators to perform is recovery of process instances. Depending on a lot of configuration (fault policies) and a process definition the server can mark a running process instance as pending manual recovery and then let administrators inspect the instance's variables, modify them if needed and "recover" the instance, for example, retry the failed operation or just skip it and continue the execution.

Under particular circumstances I wanted to report an error in the process execution that an administrator can fix by changing a variable and let the execution continue. While the Oracle BPEL software has also support for human interaction (and the maintained application is using this as well) I did not want to use it. I really wanted that the problem is reported to BPEL administrators and not business users. There is already a nice place for that in the BPEL Console, I just needed the BPEL process instance to do something so that the server marks the process instance for manual recovery.

Sounds easy. After all, BPEL has that nice <throw> activity to report an error. Except that this does not work the way I need it to work. The only thing I can do with a fault thrown explicitly by a process (using <throw> activity) or generated by the BPEL server due to an error in the process execution is catch it with <catch> or <catchAll>.

Well, I can also do nothing but then the process instance dies with "unhandled fault" error. The fault is then rethrown by the BPEL Server in the parent process instance. Or not: this is actually the place where Oracle BPEL software looks at the configuration and decides what to do with the fault: rethrow it or may be let administrators do something about it.

It looks like I have to create a new process B just to throw a fault and invoke process B from process A so that I can configure Oracle BPEL software to pause process A when process B throws a fault?! Nice. The system has already 70 processes which is actually 70 more than needed.

After reading some Oracle documentation and a bit of experimenting I found a better way. The fault policies mechanism works on <invoke> boundaries. It does not matter what triggers an <invoke> failure: a fault message from the invoked service or just failure to find that service in the first place. The solution I implemented ended up being really simple: I defined a WSDL file with some request/response messages, a port type and a <service> pointing to a non-existing URL. I fill in a request message with error details and try to invoke the service. The BPEL server gets 404 HTTP response and happily fails with {http://schemas.oracle.com/bpel/extension}remoteFault. The only thing left is configure the fault policies so that the process is marked for manual recovery.

This solution has an additional advantage over "2 processes" implementation: it does not produce faulted process instances in the BPEL Console. One thing less for administrators to worry about.