Is there any way in Assets to know if the metadata was updated or the binary was uploaded?
The current use case is we are integrating with third parties with Adobe assets. This is the second or third time for this ask by a client. One other use case was for approval workflows where a curtain approver was only needed to approve on a binary change not a metadata changes.
Within the Asset node structure there does not seem to be a way to identify if the metadata or original rendition changes because an entire new node structure is create as the old structure is versioned away. I have checked the version history structure as well which did not have anything I found useful.
There is nothing OOTB that can do this. Gaurav provided the best response here. And yes - your idea of using a custom workflow step and workflow is a great way to proceed here. Once of the reasons why AEM allows you to build custom workflow steps - you can introduce Java logic to meet specific business requirements like this one and build a workflow.
This is a solution but as you stated would not be 100% accurate. I am looking for anything OOTB that would do this before I go down a customization path. If I was going down the customization path I would add a workflow step to the asset processing flow that sets property with a date of a new asset binary. That would give me a date to compare the modified date to. if they match then I know a new binary was added.
A solution could be generate a hash/checksum of the binary and store it as a property/node either on the asset itself or somewhere else in a centralized location that would've a restricted access so that nobody can modify it (Obviously this would require to think-through the existing business use-cases).
For existing assets, you'd have to implement it in batches based on size/number of assets and for new assets, this solution/service could be a part of DAM Asset Update workflow.
Now, based on whatever existing process is to modify an asset each time, you'd calculate the hash again and compare it against the previously stored value and perform some action based on it, either notify or trigger emails or something. This approach can work for both 'original' or 'renditions' or it could be customized for certain renditions only or with some business logic.
This idea may not be 100% foolproof but yes you can build on top of it and combine it with governance and access permissions to plug the gaps per business requirements.
If you want to read binary for any reason, here are a couple of examples -
Thanks for the response. All node modified dates are updated no matter what the change. The entire node tree is copied and updated on version so all dates match. There is no created date on the revision nodes to key off either.