cancel
Showing results for 
Search instead for 
Did you mean: 

What's the best way to track metadata (property) changes on a node?

afielden
Confirmed Champ
Confirmed Champ

I have a requirement to show a history of changes to a certain property of site. This is for a custom node type (derived from 'st:site'.

I've read about the MetadataTracker in this interesting post by Andrea Gazzarini, which looks to be relevant

https://community.alfresco.com/community/ecm/blog/2019/04/10/the-alfresco-content-tracker 

But I'm unsure how to use this, as there is no practical example of how to apply it.

All I want to do, is show the user the history of what changes were made to the property (and possibly who made them). If there is some out-of-the-box way of doing this, that would be ideal.

Otherwise, any guidance to resources which explain how to do this would be most appreciated.

1 ACCEPTED ANSWER

afaust
Legendary Innovator
Legendary Innovator

The MetadataTracker is relevant ONLY for SOLR indexing, and NOT for maintaining a full history of changes.

 What you are looking for is more in line with Behaviours / Policies. With these you can react to a multitude of events, e.g. OnPropertiesUpdate, and record the relevant information in any form of history / log you want. In Alfresco 6.1 there is even a way to use a messaging queue to process these events asynchronously and out-of-process, though there doesn't seem to be any documentation on how to use that yet, despite it being one of the key features in the latest release. The only mention I could find of it is from a DevCon 2019 talk on archtiectural changes (2-3 slides only).

Alternatively, there is Auditing, which is a meant to record arbitrary custom data originating from node changes and/or API invocations and allow for the recorded data entries to be queried / retrieved, but it can be quite complex. Also, it is expected that auditing will also shift more to an out-of-process approach at some point similar to the event-related queue. Additionally, unless you are already quite familiar with Auditing, it can be easy to fall into various performance / scalability traps due to naiive implementation approaches.

View answer in original post

3 REPLIES 3

afaust
Legendary Innovator
Legendary Innovator

The MetadataTracker is relevant ONLY for SOLR indexing, and NOT for maintaining a full history of changes.

 What you are looking for is more in line with Behaviours / Policies. With these you can react to a multitude of events, e.g. OnPropertiesUpdate, and record the relevant information in any form of history / log you want. In Alfresco 6.1 there is even a way to use a messaging queue to process these events asynchronously and out-of-process, though there doesn't seem to be any documentation on how to use that yet, despite it being one of the key features in the latest release. The only mention I could find of it is from a DevCon 2019 talk on archtiectural changes (2-3 slides only).

Alternatively, there is Auditing, which is a meant to record arbitrary custom data originating from node changes and/or API invocations and allow for the recorded data entries to be queried / retrieved, but it can be quite complex. Also, it is expected that auditing will also shift more to an out-of-process approach at some point similar to the event-related queue. Additionally, unless you are already quite familiar with Auditing, it can be easy to fall into various performance / scalability traps due to naiive implementation approaches.

Thanks Axel for your helpful response. Yes I'm familiar with attaching Behaviours to respond to document updates. That was the approach I had in mind, but was wondering if Alfresco provided some ready solution, in a similar way to the tracking of document content history/changes.

The Auditing strategy doesn't sound like a road we want to go down, as we do lack familiarity with that feature.

a_gazzarini
Champ on-the-rise
Champ on-the-rise

Hi Andrew Fielden, thanks for the referencing my post. 

Just to add my 2 cents: I can confirm the current design of the tracking subsystem is not thought for fitting your needs.

It is an internal component of SearchServices (that's the reason why you don't find any practical example in my post), so that means it's valid only when you have Solr as part of your search infrastructure. 

In addition, trackers don't provide any callback mechanism for sending notifications about events.

Although everything is possible, implementing such feature would require some custom code and a relevant change in an internal component. So briefly, that's not a ready solution: definitely better to go with the approach described by Axel Faust  

Cheers, 

Andrea