AEM asset events need a cross-view contract test

A DAM integration often begins with a simple promise: every meaningful asset change creates a usable downstream signal. A community question about AEM Eventing and Runtime Actions asks whether changes made in Assets View and Classic Admin View produce the notifications a third party needs. That is a contract to verify, not to assume.

Define the events the consumer actually needs

List create, metadata update, binary replacement, move, publish, unpublish, and delete separately. Map each to the downstream action and idempotency key. An event named “changed” may not contain enough context to decide whether a customer-facing copy should be refreshed.

Exercise both authoring paths

Run the same controlled asset changes in Assets View and Classic Admin View. Capture event type, asset identifier, timestamps, delivery latency, and retries in a nonproduction integration. Include API-originated changes if those are part of the real workflow.

Prove recovery as well as delivery

Build a reconciliation job that compares source asset state with consumer state. Event delivery alone does not protect against missed subscriptions, malformed payloads, or consumer outages. Define the maximum acceptable divergence and an owner for replay.

Adovo’s view

Events are hints until the receiver can reconcile state. The business value is a trustworthy asset everywhere it is used. Test every authoring path, then design for a missed event as an ordinary operating condition.