BPMS are very good managing structured processes. But what happends once there is an exception? usually the BPMS sends out an email to the person in charge. But how do you track this ad hoc process to its completion?

Today I’d like to discuss how HPMS can be of help in these situtations

A:  An HPMS should support  both loose integration via email, and tight integration via web services.

Loose email Based Integration

Most BPMS and structured process engines (e.g. CRM) already have a mechanism to invoked an external human process via email. An HPMS should be able to intercept these emails (e.g. via a designated inbox) and use it in order to invoke an HPMS. The human process can then be monitored and managed via the HPMS. Once the invoked human process is complete an email response is sent back to system that initiated the human process. This mechanism requires no programming and should work for any structured process.

Web Services Integration

A tighter way to integrate and HPMS with a BPMS is via BPEL (Business Process Execution Language), which is a standard way to express business process behavior for web services. Most BPM systems support BPEL as an execution language. 

The easiest way to invoke (or kick-off) an HPMS process from BPEL is as a web service. An HPMS process can be invoked by the BPEL flow to handle long running human centric tasks as part of a business process, or as a mechanism for handling application (or service) faults in the flow. I am including a more technical overview in the next couple paragraphs for those interested.

An application fault happens when a service invoked by a BPEL flow is unable to complete its task. This can happen for a variety of reasons, but one common reason is that the content associated with the service invocation is inappropriate or wrong. The BPEL service then returns an error with one of the messages defined in the service WSDL (Web Services Definition Langauge). It is up to the BPEL flow to decide what to do with that. One way to handle these faults is by invoking an appropriate HPMS service for the long running process used to handle the exception. When invoking the service the BPEL should provide the fault message provided by the service that failed, and the input information that generated the fault. The BPEL flow will need to wait for a (timed) response from the HPMS service. The BPEL flow can then resume its normal flow with the new content obtained, or rethrow a fault for a catastrophic failure (or time-out).

An HPMS can also be invoked as a standard web service for handling long running human processes from BPEL. The BPEL flow can invoke the HPMS service as it would any web service. The invocation should(at a minimum) provide the HPMS services with a way to find the intended recipient (e.g. email address) that will handle the process and a priority, a start date, and a planned end date.