Good question - I think this is a bug in our side. I'll file a report for it and we will look into it. 

Thanks Quan.

Quan,

This appears to be working properly in 11.2.5. Can you confirm? I didn't see a bug on http://world.episerver.com/support/Bug-list/ for it, but my listener seems to be working correctly since updating to 11.2.5 today.

Which version were you on before? We did tweak the events in 11.2.3 (though with focus on reducing events but we aimed for correctness). We just started looking into the bug Quan registered so there is no fix specificially targeting that problem yet. I'm happy if your issue is already resolved but we will put some more effort into finding issues in this area anyway.

Magnus,

We were behind a few versions, 10.8. We have recentlly updated all of our Epi packages to prepare for this bug fix. I haven't had time to test it thorougly, but appears to work as it should now. 

Magnus and Quan,

This issue appears to have started again. I'm not positive what changed, but I sustpect it is data related. It started to happen after I restored a database from another server.

Thanks for getting back with that information. I've looked into this issue and what I've seen so far is that it seems to always raise the event when updating through IContentRepository. What API are you using to update the data?

Magnus,

This is when updating the product variation through Episerver/Commerce/Catalog.

Thanks! And you publish the change?

Magnus,

Yes, the change is published. I did a little more digging and found the following while editing variations in Episerver/Commerce/Catalog:

1. Change the custom property + Publish -> does not raise the event
2. Change the Display Name + Publish -> does not raise the event
3. Change the Name + Publish -> raises the event

From then on, both edits to Display Name and custom property + publishung would raise the event properly.

If I restart the site, it works fine as well. The custom property raises the event as it should.

If I switch to editing another variation for another product, the events follow the same behavior as they did before.

1. Change the custom property + Publish -> does not raise the event
2. Change the Display Name + Publish -> does not raise the event
3. Change the Name + Publish -> raises the event

This must be why I thought it had been fixed. I was testing a variation I had already edited. Any ideas as to why this is happening?

Thanks for the detailed information! That a custom property and the display name property work the same is expected - they are both stored in the meta object for the catalog entry. The name is stored in the main entry table.

The initial behavior you had is actually what I would expect, because the event in question is not raised for a meta object change. But when I started digging into this I actually found a bug that caused the event to be raised even though there are no base entry data. This is consistent with the behavior you see after the first edit.

If possible, it would be interesting to get a copy of the database to see how it behaves in the code path where this event is raised even though it shouldn't be.

In the short term, for you to solve your immediate issues, maybe you should look into IContentEvents.PublishedContent. This event should be raised for any change done through the Content APIs, including the Catalog UI. The drawback however, is that these events will not be raised for updates that are not done through the Content APIs (Catalog import, Service API, Commerce Manager...). So if IContentEvents will be sufficient or if you should use it in combination with CatalogEventBroadCaster (or CatalogEventHandler) depends on how you get content updates.

For us, it looks like we have a gap in the event information for when meta object data is updated. We're not yet decided on a solution to close this gap so a (possibly) unified solution could be some time away.

Magnus,

They use the Service API and a custom API to import/update products. I think as time goes on, they should rely on the admin area less and less. I think we will just look at lowering the time between indexes and make sure they understand how to manually trigger a reindex.

I would love to know when/if this is handled. Is there any documented bug I can check on?

I can ask the client regarding the database if it would help.

That is great news Magnus! Thanks for the update.

I realize now that I might have promised too much. CatalogEventBroadcaster should not be on the list above.

I'm not sure I follow. Is there any other way to listen for these events?

TL;DR: Prefer using the CatalogEventHandler.ContentUpdated event unless you need to react to changes done in Commerce Manager.

There are three ways to react to catalog events:

Using the EventContext class, e.g. the EntryUpdated event. This is kind of a low level event in which much of the data was traditionally carried only in the sender object (which is the saved DTO). From Commerce 11.2.3 the EventArgs contains more pre-processed information that is easier to use than digging through the DTO (which also lacks information about deleted items).

The event data is then propagated from EventContext to the CatalogEventBroadcaster class. Like the name suggests its main purpose is to broadcast the events through the episerver remote event channel, making it possible (using the EPiServer Event class) to react to changes that were actually performed on another server. It also has normal .NET events that are raised on the same machine, basically just forwarding the event from EventContext.

The event data is also propagated through the CatalogEventHandler class, e.g. through the ContentUpdated event. This further pre-processes the event data, so that its event args contains the ContentReference of the updated node/entry, which is often what you want when working with IContent-centric implementations. It also differs in the way that the event is raised for each updated cotnent, while the EventContext EventArgs can reference multiple nodes/entries that were saved together in a batch.

Then you have MetaData. Before 11.4.1 (COM-5489 fix), no event was raised when the MetaObject for some catalog entity was changed. But you would often get an event anyway because the corresponding DTO data was changed. With progressively more efficient dirty-checks (to avoid re-saving unchanged data) the likelyhood of having both a MetaObject and DTO change has decreased. So from 11.4.1 the same events are raised for MetaData changes (this also means they may be raised twice when saving content with both meta data and base data (DTO) changes) from EventContext and CatalogEventHandler but they are not propagated to remote machines by CatalogEventBroadcaster. This was an oversight, and it was fixed in 11.5.0 (COM-5901).

So to use the remote events and be able to react to MetaObject changes, you have to have 11.5.0 or later (which means moving to CMS 11). 11.4.1 is sufficient if you can work with EventContext or CatalogEventHandler, i.e. handle events locally. This is if you want to react to any changes done through the Catalog UI, API calls from your site implementation, Service Api operations etc. What you won't get is events for changes done in Commerce Manager, this requires the remote events since you can't (or at least normally shouldn't) deploy custom code to the Commerce Manager application.