Came across a great diagram (sorry, (c)), which explained a possible architecture that connects Event Driven Architecture, Rules and BPM.
The elements (in sequence):
1. A business event occurs, and is signaled from somewhere (say a CRM application)
2. It's given to a Event Processing Agent. This decouples the business event from a process event. Based on rules, it translates the business event to one or more process events.
3. Process events are given to the BPM layer which starts a process (or continues a waiting one)
I like this decoupling. It creates a clear component that has the responsibility to know what is needed in terms of processes. And manage it by a rule engine.
Suppose your customer reports being pregnant... (ok, it's my girlfriend :-))
Process events for the typical insurance company:
- Time to start up a advice on life insurance
- Time to trigger some gift to be sent
- Time to inform the health insurance dept. on coming claims and required reservations....
I do still wonder where to place the logic for knowing, based on a process event, if a new process needs to be started or a waiting one needs to continue. In my view, we need some type of component there as well... with knowledge about process events, rules and current process instances that are waiting or running. The CEP-unit.
1 comment:
I think there is a lot to be said for using rules (and analytics) as part of event processing. It often comes up (see this section on my blog) as a topic. I think event processing/BPM/SOA and rules/analytics all need to work together to build a modern infrastructure (check out this post).
JT
www.edmblog.com
Post a Comment