Question about customizing indexes on Cloud environments | Community
Skip to main content
P
Preston-3
Level 4
August 10, 2024
Solved

Question about customizing indexes on Cloud environments

  • August 10, 2024
  • 1 reply
  • 1873 views

We are experiencing slowdown while performing Query Builder queries against content fragments. While digging into this, I believe I discovered that it has to do with a field in the content fragments not being indexed. I added a custom index locally and the query improved from 200 ms to 2 ms.

 

According to the documentation here (https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/operations/indexing) creating new custom indexes that work against assets is discouraged, but modifications can be made to out of the box indexes. Does this mean those modifications are performed by Adobe or is that documentation simply missing from this article?

 

Preston

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by narendiran_ravi

Hi @preston-3 , 

In AEMaaCS, if we want to modify the OOB index, we must copy the index definition from the Cloud environment CRX via packages. We need to include this as part of our code base by adding our custom index inside this. 

 

For the naming convention to be followed, please refer to the section - https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/operations/indexing#index-names in the same document.

Ex: /oak:index/damAssetLucene-11 is the index name in Cloud environment if you want to customize use /oak:index/damAssetLucene-11-custom-1. 

 

We need to do some updates in parent pom.xml and filter.xml of apps as well -https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/operations/indexing#project-configuration

 

Please check and let me know if you need more details

 

 

1 reply

narendiran_ravi
narendiran_raviAccepted solution
Level 6
August 10, 2024

Hi @preston-3 , 

In AEMaaCS, if we want to modify the OOB index, we must copy the index definition from the Cloud environment CRX via packages. We need to include this as part of our code base by adding our custom index inside this. 

 

For the naming convention to be followed, please refer to the section - https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/operations/indexing#index-names in the same document.

Ex: /oak:index/damAssetLucene-11 is the index name in Cloud environment if you want to customize use /oak:index/damAssetLucene-11-custom-1. 

 

We need to do some updates in parent pom.xml and filter.xml of apps as well -https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/operations/indexing#project-configuration

 

Please check and let me know if you need more details

 

 

    P
    Preston-3Author
    Level 4
    August 10, 2024

    I think the part that's throwing me is this from that documentation. 

     

    "Introducing new indexes on the dam:Asset nodetype (particularly fulltext indexes) is strongly discouraged as these can conflict with OOTB product features leading to functional and performance issues. In general, adding additional properties to the current damAssetLucene-* index version is the most appropriate way to index queries on the dam:Asset nodetype (these changes will automatically be merged into a new product version of the index if it is subseqently released). If in doubt, contact Adobe Support for advice."

     

    The wording that's throwing me is "adding additional properties to the current index version". So do they mean just creating a custom index based off of damAssetLucene-X and adding your own customizations? It's worded as if the index can be "edited". 

     

    EDIT: I should also clarify that part of what's throwing me is that the fields in question (fields that are part of Content Fragment models) are defined in damAssetLucene in the "aggregates" section. 

    <include8
            jcr:primaryType="nt:unstructured"
            path="jcr:content/data/master"/>

    I'm not entirely clear on what this does, but any fields located under jcr:content/data/master don't seem to be particularly fast to query. Whereas if I add a custom index that includes this.

     

    <jcrName
            jcr:primaryType="nt:unstructured"
            name="jcr:content/data/master/jcrName"
            propertyIndex="{Boolean}true"/>

    Querying on jcrName goes from 200ms down to 2ms. 

      narendiran_ravi
      narendiran_ravi
      Level 6
      August 10, 2024

      Yeah, the documentation could have been clear. Aggregates are useful when we want to combine the descendant properties of a node.  Refer to this link - https://www.aemcq5tutorials.com/tutorials/aem-oak-indexing-comprehensive-guide/. 

      Even though you added the path in aggregates you still need to create an index for a property under that path. The custom index needs to be added under /oak:index/damAssetLucene-11-custom-1/indexRules/dam:Asset/properties as part of your code and deployed in the cloud.

        Terms & ConditionsAccessibility statement

        Loading footer...