Content Model Sync: d:category Field Builder


The scope of this task is to extend the component that takes in input a single Alfresco property from the content model, with all its details, and returns in output the mapping for the Elasticsearch field.

Properties of type “d:category” are mapped to a org.alfresco.service.cmr.repository.NodeRef object containing the reference to the category node. This means that in the event we will have, inside the properties list, something like:

Solution 1

We can store the category name inside the cm:taggable array, storing something like below:

This will make the search easier, but we need to add this information to the produced event, and we have to make some consideration about the update.

Instead of adding the information to the event, we can retrieve the name from the index getting the category document by id, and storing it in the target document.

About Tags, we don’t have to mind about the node update because when we change a tag all nodes will be updated because of a TAG update, internally, is a creation followed by a deletion of the old tag and a massive update.

For other properties, like cm:categories, there isn’t any mechanism like the one described above, so we have to perform an update by query. This solution can be applied to every field of type d:category.

This solution will require more work on the event module and in Alfresco Elasticsearch Connector, while the code required to run a query is minimal.

Solution 2

In order to index the properties without too much elaboration, we can define the mapping as below:

Implementing the mapping in this way will not require any change in the Alfresco Elasticsearch Connector and in the event model, but only in the Query mechanism in Alfresco Repository in order to translate the query from a string to a noderef list.

Solution 2B

We can elaborate the cm:taggable array in the Alfresco Elasticsearch Connector transforming it from an object array to a string array. In this way, we will simplify the index structure by removing useless information. The choice between this solution and the previous one really depends on how we decide to store nodeRefs in our index.


The main difference between the two solutions above is where we decide to spend more time. The first solution will be faster in search, while the second will stress less the index, and the indexing phase will be faster.

Acceptance Criteria

  • When Alfresco Repository starts fields of type d:category are successfully mapped (e.g. cm%3Ataggable)

  • Integration tests

  • Update documentation on




Davide Cerbo

Delivery Team