if the value of a warranty claim is greater than $1,000 then set manager approval to mandatory

if the number of warranty claims of the customer within the last month is greater than 4 then send a request to the call center to contact the customer

From a business user’s perspective, both of the above are rules. They reflect a business policy that the warranty system needs to implement. But there is a fundamental difference. The first example is a business rule and the second is an event rule. The distinguishing difference between the two is that the first has no reference to time, while the second does (for example “within the last month”).

From a technical perspective, this small difference will impact how each rule functions from an architectural perspective. A business rule application module:

Receives data synchronously.

Responds synchronously.

Is stateless.

An event rule application module:

Is called asynchronously.

May trigger an asynchronous response.

Is stateful if the rule correlates the current event with any previous events.

The way we use business rules and event rules in the context of a business process is fundamentally different too. Business rules are typically called from a process in the same way any external, stateless service would be called: the process sends data to a Decision Service and receives a synchronous response.

Conversely, we can use business events to trigger a business process. The business event detects a certain situation that requires prompt action, and invokes the appropriate business process. This is an example of a sense-and-response pattern.

By combining both business rules and business events we are able to use rules to trigger business processes, and to incorporate rules that determine how a business processes should run. A powerful combination indeed.

Martin Keen is an IBM Redbooks Project Leader. He leads publications on many areas of IBM middleware. Follow Martin on Twitter at @MartinRTP.