Hi all,
When we remove the changes in workflow migration tools such as /var/workflow/models in filter.xml and delete the /var/workflow/models from the repo & deploy to cloud - the workflow models are no longer visible.
Getting the below error in logs -
13.08.2024 16:05:02.080 *ERROR* [[0:0:0:0:0:0:0:1] [1723458902061] POST /conf/global/settings/workflow/models/custom-model-test/jcr:content.generate.json HTTP/1.1] com.adobe.granite.workflow.console.servlet.ModelGenerateServlet Could not create workflow model
com.adobe.granite.workflow.WorkflowException: Unable to save workflow model
Caused by: javax.jcr.PathNotFoundException: /var/workflow/models
at org.apache.jackrabbit.oak.jcr.session.SessionImpl.getItem(SessionImpl.java:403) [org.apache.jackrabbit.oak-jcr:1.64.0]
at com.adobe.granite.repository.impl.CRX3SessionImpl.getItem(CRX3SessionImpl.java:180) [com.adobe.granite.repository:1.9.6]
13.08.2024 16:05:59.897 *ERROR* [[0:0:0:0:0:0:0:1] [1723458959895] POST /etc/workflow/instances HTTP/1.1]
com.adobe.granite.workflow.console.servlet.InstancesServlet Unable to start workflow /var/workflow/models/custom-model-test. Model not found.
any help on this?
thanks,
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Removing /var is also correct as if you check AEM Project Structure
The /apps
and /libs
areas of AEM are considered immutable because they cannot be changed (create, update, delete) after AEM starts (that is, at runtime). Any attempt to change an immutable area at runtime fails.
Everything else in the repository, /content
, /conf
, /var
, /etc
, /oak:index
, /system
, /tmp
, and so on, are all mutable areas, meaning they can be changed at runtime.
Furthermore, if you check the link at Debugging AEM as a Cloud Service build and deployments you will find reference to below-
/var
is mutable containing a variety of transient, runtime content. Including /var
in a content packages (ex. ui.content
) deployed via Cloud Manager may cause the Deploy to step to fail.
Cause: AEM’s replication service user used to deploy content packages to the AEM Publish service cannot write to /var
on AEM Publish. This results in the deployment of the content package to the AEM Publish service to fail.
Resolution: The following ways to resolve this issues are listed in the order of preference:
/var
resources are not necessary remove any resources under /var
from content packages that are deployed as part of your application./var
resources are necessary, define the node structures using repoinit. Repoinit scripts can be targeted to AEM Author, AEM Publish or both, via OSGi runmodes.
Hi @gallaghan6
You need workflow at /var as well for runtime, Please check repository restructure
@arunpatidar - I recall getting a build error when we had /var/workflows path configured in filter.xml w.r.t the immutability.
I assumed that when the workflow runs then /var/workflow/models and /var/workflow/instances are supposed to be created on the fly for each pod/container its deployed to.
is that not correct then?
Also, when we run the workflow migration tool it removes everything from /var/workflows in the repo.
Hi @gallaghan6
I think /var/workflows will be part of mutable content : https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/release-notes/ae...
I have not found any documentation around removal of /var/workflow. Found few adobe project that still deploy /var/workflow/model from package manager: https://github.com/adobe/AEM-Smart-Tag-Converter/blob/main/ui.content/src/main/content/META-INF/vaul...
/var/workflow/instances will be creating on run time when workflow would be triggered, so need to cover this path.
When running the asset workflow migration tool, the utility in stand-alone mode generates the below logs -
## Paths Deleted
Workflow nodes under /var paths are no longer required for deployment to AEM as a Cloud Service. These nodes will automatically be generated at system startup for any workflow models that have previously been synced. In order to prevent potential deployment issues, the following /var paths have been removed from your Maven projects and filter files:
| Action | Path |
| ------ | ------- |
| Deleted | C:Codebase\aem-cs-assets\aem-cs-assets\ui.content\src\main\content\jcr_root\var\workflow
If I check the git logs it shows the below-
Its removing the workflow launchers, workflow models at /var/workflow path
Is the utility then incorrect?
Hi @gallaghan6
Removing workflow launcher is correct because that would be replaced by processing profile with custom workflows.
However I am still not sure about /var folder.
Removing /var is also correct as if you check AEM Project Structure
The /apps
and /libs
areas of AEM are considered immutable because they cannot be changed (create, update, delete) after AEM starts (that is, at runtime). Any attempt to change an immutable area at runtime fails.
Everything else in the repository, /content
, /conf
, /var
, /etc
, /oak:index
, /system
, /tmp
, and so on, are all mutable areas, meaning they can be changed at runtime.
Furthermore, if you check the link at Debugging AEM as a Cloud Service build and deployments you will find reference to below-
/var
is mutable containing a variety of transient, runtime content. Including /var
in a content packages (ex. ui.content
) deployed via Cloud Manager may cause the Deploy to step to fail.
Cause: AEM’s replication service user used to deploy content packages to the AEM Publish service cannot write to /var
on AEM Publish. This results in the deployment of the content package to the AEM Publish service to fail.
Resolution: The following ways to resolve this issues are listed in the order of preference:
/var
resources are not necessary remove any resources under /var
from content packages that are deployed as part of your application./var
resources are necessary, define the node structures using repoinit. Repoinit scripts can be targeted to AEM Author, AEM Publish or both, via OSGi runmodes.
Hi @gallaghan6 ,
You may try to sinc workflow which should create the required node for model under /var if the corresponding model present (commit /conf/global/settings/workflow/models)
Please find below references-
https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-23531
Thanks
@gallaghan6 Did you find the suggestions from users helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies