You can see ESM as some kind of a prefilter that can keep state across multiple raw events for a customer and detect high level events, hence it will also deal with much higher volumes.

Examples: say ESM is listening to a stream of Call Detail Records (thousands of tens of thousands per second). It can detect for example whether for a given customer there are more than 7 CDRs of type x (say dropped calls) in the last 7 days. If so, it will emit a high level event, and this can trigger a Pega Marketing campaign. Typically the drop off rate between raw events and high level event could be several orders of magnitude (1% or 0.1% high level events). There are also other approaches, for example ESM could update an Offer Status, causing an inflight Offer Flow to continue to the next state.

A counter example would be some external trigger for which you dont need to look across events in the stream and simply fire of a Pega Marketing campaign. Say a credit card is flagged as fraudulent by some external system and you want to notify the customer. In this case you are directly triggering a Pega Marketing campaign.

As an aside ESM is an optionally licensable component.

Thanks Peter.

1. So as per your comment can we safely say that the second approach i.e " We will use Pega ESM to identify events directly from external customer DB and invoke this service"  will have much better performance than external BI system based on event detection making numerous direct service call to launch Pega campaign?

2. If you intend to use ESM then do we need any extra special server configuration additional processing power, extram RAM, dedicated nodes etc?

Regards

Abhi