One of the interesting aspects of “complex event processing” is that “processing” typically encompasses MORE than just event pattern detection (in many use cases). For example:
- in algorithmic trading, you can detect a trade opportunity, but must decide whether to act on it immediately or refer to some risk management rules or process
- in airline operations, you can detect a solution to some passenger delay events, but you must decide whether to simply notify the gate manager or initiate some solution process
- in customer management / CRM, you can detect a customer “change in state” event pattern, but must decide whether to respond with an appropriate offer or simply update the customer record
- in smart grid systems, on detecting a potential transformer outage indicator event pattern, you must decide whether and how to reduce load on the system versus prioritising the maintenance team
- etc etc.
Of course, the process of detecting patterns, making decisions, and instigating appropriate reactions is rarely expressible in a simple orchestration or sequence diagram – event processing is continuous and decisions can simply affect the types of patterns we are looking for. This is why CEP tools often use declarative constructs for defining pattern and decision knowledge, and multiple paradigms / event processing element types or languages for event detection and event-based decisions.
