AEM DAM XMP handler OSGI service

Another post going into the workings of the default OSGI services that ship with Adobe AEM. This one is important to know for customers making heavy use of the DAM and and asset metadata, especially if those assets are used across other systems.

First, let’s talk about XMP
XMP stands for eXtensible Metadata Platform and is a filetype agnostic, universally applicable and extensible metadata system. Those familiar with imaging are probably aware of the metadata format known as EXIF. XMP is similar to EXIF in that it stores metadata for images but it has a number of advantages. EXIF has a lot of problems. EXIF simply isn’t reliable for serious multi-format, multi-system metadata tracking. For this reason, AEM uses XMP for metadata on assets. This is IN ADDITION to the metadata properties on nodes.

When an author adds metadata to an image and saves, two things happen. First, that data is saved to the JCR repository. Second, that save triggers a workflow process that adds the metadata to the original asset file. XMP metadata is stored in the file binary itself. This is important if the ORIGINAL file is later exported and used on other systems. In addition, the rewrite of the original file can trigger other processes/image handling workflows to run — be careful about workflow loops.

The XMP metadata workflow takes the metadata stored in the JCR, converts it to XMP, and then re-writes the original file inside to reflect the metadata added to the JCR, keeping the file and the JCR metadata nodes in sync.

The workflow only does this for files whose MIME-type is part of the list in this service. If you don’t need to track metadata at the file level, you can remove these items or restrict these re-writes to a smaller number of items. This can have a performance benefit if you are working with a large volume of digital assets where this metadata tracking is unimportant. You can also expand the list if you are working with certain custom datatypes or image formats.