cancel
Showing results for 
Search instead for 
Did you mean: 

How to separate model from workflow

pnature
Star Contributor
Star Contributor

Hi,

I have created workflow which contains model. But I think that model have to be separated from workflow because of reusing. Model then could be deployed separately and used by different workflows on different environments.

So I have created new project and I have moved model from workflow. But there are forms connected to model. So I have created new share project for forms.

Then I deploy these JAR projects

Deploy a model | Alfresco Documentation 

tomcat/shared/lib for model

tomcat/webapps/share/WEB-INF/lib for share forms

It seems that everything works fine. I can see types, aspects and forms in share aplication.

But when I use Model and Messages Console (http://localhost:8080/alfresco/s/admin/admin-repoconsole) show messages, show models I get "No additional models/messages resource have been deployed to the Alfresco Repository".

Is it OK?

Thanks in advance.

1 ACCEPTED ANSWER

afaust
Legendary Innovator
Legendary Innovator

"Why is this folder mentioned in official Alfresco documentation?" - Because that is a very old part of the documentation and usually is only carried over from version to version. Also, it is meant for purely static resources on the Share tier, e.g. web scripts and client resources. For this it works just fine. It is not meant for Java-based extensions. And lastly, it is not the only non-optimal info given in the documentation. The docs are there to make it easy to start / work with Alfresco, not burden you with too much information - so they may leave out some details that may not be relevant to 60-80% of the audience.

Ideally, deploy your model and workflow using the corresponding Spring beans (as documented e.g. in Jeff Potts' tutorial on workflows). And forget about the consoles for this. In a production environment, those should never be used anyway - they are mostly practical for development environments.

View answer in original post

5 REPLIES 5

afaust
Legendary Innovator
Legendary Innovator

Any model deployed via a JAR or other classpath means will never show up in the model & messages console. Only models / messages deployed at runtime (e.g. via the Data Dictionary) show up that way. So what you see is ok.

Though, I would advise you to not use tomcat/shared/lib or tomcat/lib for any more complex customisations. There are a lot of restrictions / limitations that come from classloading mechanics when you put JARs into those directories, and as soon as you have some Java-based customisations chances are high it is going to fail. If you use the default Alfresco installer (of a recent / current version) then you should have folders for modules/platform and modules/share where you can safely place customisation JARs.

pnature
Star Contributor
Star Contributor

Thank you for your response. So how to deploy model to be visible for console and workflows? Because I struggle with problem that my workflow doesn't see separated model.

Should I deploy model using Model and Messages Console?

Thank you for your advice but why this folder is mentioned in official Alfresco documentation?

afaust
Legendary Innovator
Legendary Innovator

"Why is this folder mentioned in official Alfresco documentation?" - Because that is a very old part of the documentation and usually is only carried over from version to version. Also, it is meant for purely static resources on the Share tier, e.g. web scripts and client resources. For this it works just fine. It is not meant for Java-based extensions. And lastly, it is not the only non-optimal info given in the documentation. The docs are there to make it easy to start / work with Alfresco, not burden you with too much information - so they may leave out some details that may not be relevant to 60-80% of the audience.

Ideally, deploy your model and workflow using the corresponding Spring beans (as documented e.g. in Jeff Potts' tutorial on workflows). And forget about the consoles for this. In a production environment, those should never be used anyway - they are mostly practical for development environments.