Introduction
A few days ago I had a very interesting conversation with a developer colleague who told me what it was like to implement his product at several customer sites. He has developed a Document Process Engine (name changed) for the WAS ABAP that manages cross-system, cross application document processes. It passes documents to one attached subsystem after another according to a linear process model, manages the status and return codes reported by the subsystems, and controls the overall document process.
Using his Document Process Engine, his customers are able to integrate their non-SAP output management, groupware, and archiving systems into the ERP processes.
What can go wrong, will go wrong
Transferring messages across system boundaries, especially asynchronously, all kinds of things can happen: Messages fall into the cracks between systems, they get lost, and processes are aborted and forgotten. Nobody will hear their screams. Errors may occur on the transport layer, a system may be unreachable, a subsystem may be unable to import an incoming message due to formatting errors, or an error within the attached subsystem may cause the processing of the message to halt.
We have all seen those empty exception handling blocks:
TRY.
...
CATCH CX_ROOT.
* TODO: Handle exception (the day hell freezes over).
ENDTRY.
The Eye in the Sky
Whatever goes wrong, and wherever it happens, it’s likely to go unnoticed and be forgotten when processes that span system boundaries are not centrally monitored.
A centrally located, seamless, end-to-end process control and monitoring, an “Eye in the Sky”, is the easiest way to guarantee process definition and run-time consistency and to establish a single source of truth in the system landscape for process status information.
For every cross-system process, there should be exactly one source of truth for process definition, as well as process control and monitoring at run-time. This is equally true for the simplest processes and for the most complicated ones with several hops across system boundaries.
Process Control as a Whistleblower
Now what happens when you introduce a process controller (be it the Document Process Engine mentioned above, or SAP NetWeaver Process Integration, or a third-party Enterprise Service Bus)?
- It’s going to report many errors and reveal bugs that have been around for a long time but went undetected due to a lack of monitoring.
- It will cause a lot of work to the people responsible for the applications involved and cast doubts on the quality of their work.
- It will not make you many new friends among them.
- It is a chance to greatly improve the overall process and integration quality
This is simply because in many integration scenarios, process instances can fall into the cracks without being detected, and nobody is especially unhappy about this. I call this anti-pattern for process integration“Where there’s no claimant, there’s no judge”*.
* "Wo kein Kläger, da kein Richter."
