We are often presented with troubleshooting opportunities revolving around a client’s workflow process.
“Why isn’t package X flowing to work queue Y?”. The problem (or solution) may be found within their I/PM Process map. If the map looks like that below, there is probably room for improvement…
On top of the difficulty of just following the map, any user is allowed to ad-hoc route packages to any location. And not just this map but to any of the other map’s queues, scripts or rule events. This ability negates having a “business process” at all! Also, depending on the package’s meta-data values, a package may get put into an infinite loop bouncing between rules. Of course this condition puts a strain on the database, messes up threshold processing and kills the Process Broker. Oh yes… inserts thousands of records into the WF_AUDITLOG table until the issue is resolved.
This type of map arises when the I/PM team says “yes” to every request from the business. IT is frequently afraid to say “no” or to at least take the time to gather proper requirements. This particular case is begging for re-engineering (assuming it was “engineered” to begin with). In the interim, a little clean-up may help make a difference (at least in the troubleshooting effort).
- Prevent regular users from ad-hoc routing or only allow them to route to certain locations
- Review the package template’s fields and remove any that are not needed
- Review the rule events and remove those that conflict
- Re-draw the map with:
- Start (inbound) events that the top / left
- Stop (outbound) events at the bottom / right
- Put events in logical order (or alphabetical if there are too many of them)
- Limit crossing the lines (“Don’t cross the streams” –Dr. Egon Spengler, Ghostbusters)
- Color coded lines indicating direction or normal vs. abnormal paths
- Different line styles indicating direction or normal vs. abnormal paths
Although FAR from ideal, the following updated map includes some the changes listed (it is still in need of re-engineering). The color of the lines correspond to an event to which they are related and the events are in alphabetical order (relatively) with inbound at the top and outbound at the bottom. This makes “following the bouncing ball” behind the scenes a little bit easier.
Note that although these examples are from a Stellent IBPM 7.6 system, the concepts also apply to Oracle I/PM 10g and to WebCenter Imaging BPEL (to a certain extent).
If you need assistance untangling your process “webs”, please contact us today.