Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

Removing /var/workflow/models from repo leads to "Workflow Model Not Found"

Avatar

Level 3

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,

 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Removing /var is also correct as if you check AEM Project Structure

Mutable versus Immutable Areas of the Repository

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-

Including /var in content package

/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:

    1. If the /var resources are not necessary remove any resources under /var from content packages that are deployed as part of your application.
    2. If the /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.

View solution in original post

8 Replies

Avatar

Level 3

@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.

Avatar

Community Advisor

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.

 



Arun Patidar

Avatar

Level 3

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-
PraveenKumarG_0-1724143463168.png

Its removing the workflow launchers, workflow models at /var/workflow path
Is the utility then incorrect?

Avatar

Community Advisor

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.

 

 

 



Arun Patidar

Avatar

Correct answer by
Community Advisor

Removing /var is also correct as if you check AEM Project Structure

Mutable versus Immutable Areas of the Repository

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-

Including /var in content package

/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:

    1. If the /var resources are not necessary remove any resources under /var from content packages that are deployed as part of your application.
    2. If the /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.

Avatar

Administrator

@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!



Kautuk Sahni