Parameter includeChildren not working in Publish Content Tree Workflow (preview agent)
This article addresses the Adobe Experience Manager issue where a customer-created workflow for publishing content fragments (CFs) to a preview server has stopped replicating nested fragments and unpublished assets, despite the inclusion of the includeChildren
option. A log analysis revealed that the workflow must be executed from the workflow console on the folder containing the CF rather than directly on the content fragment.
Description description
Environment
Adobe Experience Manager
Issue/Symptoms
You have created a workflow to publish content to the preview agent by adding the process step as Publish Content Tree and the required arguments as described in [
1]
:
agentId=preview,includeChildren=true
This workflow is used to replicate content fragments (CF) to the preview server.
The workflow used to publish the payload provided as well as any nested fragments and used to replicate any unpublished assets as well to preview. The workflow has, however, recently ceased publishing the references to the content fragment that was sent as payload. In contrast to how it used to function [
3]
, it is just publishing the supplied path in the payload, even though the includeChildren
option is still present, as shown in the logs [
2]
.
[
1]
Publish Content Tree Workflow in AEM as a Cloud Service user guide
[
2]
INFO - Request accepted with distribution package PackageMessage(pubSlingId=88708d75-d25d-4386-bcaa-f9fec074d9e0, reqType=ADD, pkgId=dstrpck-1730188059805-67b1f056-b213-45e8-a507-26f60904114e, pkgType=journal_filevault, pkgLength=9676, pubAgentName=preview, userId=replication-service, paths=[ /content/dam/campaign-content-fragments/Folder/content-models/fragment-campaign] , deepPaths=[ ] , metadata={}) at offset=48863761, queueSize=1, queueSizeDelay=0
INFO - Successfully applied package with id dstrpck-1730188059805-67b1f056-b213-45e8-a507-26f60904114e, type ADD, paths [ /content/dam/campaign-content-fragments/Folder/content-models/fragment-campaign]
[
3]
*INFO* [ JobHandler: /var/workflow/instances/server4381/2024-10-07/replicate-preview_11:/content/dam/campaign-content-fragments/Folder/content-models] org.apache.sling.distribution.journal.impl.publisher.DistributionPublisher [ preview] Request accepted with distribution package PackageMessage(pubSlingId=9c3ac3a6-dc6f-4a36-9cd8-b0d0771bdfd8, reqType=ADD, pkgId=dstrpck-1728314679148-77dbec4f-144f-4d9c-a1c0-c5bfeaa4c028, pkgType=journal_filevault, pkgLength=326438, pubAgentName=preview, userId=replication-service, paths=[ /content/dam/campaign-content-fragments/Folder/content-models/fragment-campaign/folder2/folder3/folder4/content_fragment_1, ... 99 more] , deepPaths=[ ] , metadata={}) at offset=118000316, queueSize=5, queueSizeDelay=0
Resolution resolution
Prior to reported issues with the workflow, it was discovered through log analysis that the workflow was typically initiated against CF folders rather than content fragments.
Additionally, when started against content fragments, the logs show exactly as they do currently, with only the content fragment in the replication path, indicating that the behavior has not changed.
The workflow must be executed from the workflow console on the folder containing the CF rather than directly on the content fragment in order to replicate the CFs together with all of their references.