I've seen this guy in Mediachase.Search namespace (at least v7.6 still has this). Change notification infrastructure was used to process catalog entry change events and update the search index. Not sure that later Commenrce versions uses this. However I'm not able to locate any implementation in CMS area.

Generally speaking change notification infrastructure gives you event pumping mechanism to process event stream - it gives you extension points on both sides - listener and processor. Also giving you sort of queuing mechanism in between.

Heart beat interval for now is hard-coded to 5 seconds.

Hi,

As a commerce developer - I will try to explain in Commerce perspective :).

When you edit an entry, there's several ways to notify the system that there's a change. The most used way should be event, via EPiServer.Events. They are simple, lightweight, easy to raise..., but they in turn, are not persistent and it's not very easy if you want it work across several machines (firewall will be a problem).

Change Notificiation is a persistent queue of changes, which store changes in database for later processing. For Commerce, Change Notification will be used for indexing content. When an entry is updated its code is added to the persistent queue and our indexer will later get that information to index newly updated entries. If you have used Commerce R3a or prior, you'll need to build index whenever you update an entry. Now it's automatically (and magically) indexed.

For the latter questions - I don't know. I might dig into Framework code to see when I have time :)

Regards.

/Q

OK, so this is related to Commerce? Code-wise it seems to be defined in Episerver.Events... The sprocs are run against the CMS db. And I can confirm it is still there in the latest Commerce version (8.5.0).

What kind of indexer are you refering to? How does this compare with the incremental index scheduled job?

Since we already have remote events, it seems like "belt and suspenders" to have a db-driven notification too? Why do we need both?

Did I say it's Commerce only? Change Notification is a Framework concept/API, and Commerce is using it for it search indexer - I used entry so you can get the idea of how it works in Commerce.

- The indexer for Commerce works continously, so it is more responsive to changes. If you have daily scheduled job and you make changes right after the scheduled jobs run, you'll need to wait until next day for the entries to be indexed, while hourly schedule might be too much.

- As I said, even remote events are not persistent. If, for some reasons, the listeners can react to the events then they are lost, forever. Change Notification is persistent and you can set the number of try to process an item if the previous attemps fail.

Regards.

/Q

OK so it is a framwork thing, makes sense :)

But if Commerce is using it for search indexer I would assume I could hit a breakpoint in my custom indexing code. Which happens when I run the incremental index job. Just trying to understand the difference between the change notification indexing thing and the scheduled dito...

Talking about "belt and suspenders" - if I make a change to an entry, a remote event is kicked to invalidate the cache on the listening servers. Is there also a change notification picked up in the db which is executed on the listening servers? Won't it do the same thing twice then? O_o

Just don't like this idea with polling every 5 second... "Has anything happened?"... "Has anything happened?"... "Has anything happened?". At least I would like to be able to control the frequency of this behavior. Hmm....