topic Re: Implementing new ContentStorage locations in Alfresco Archive

Implementing new ContentStorage locations

jonnyg — Wed, 28 Oct 2015 14:58:55 GMT

As best as we can tell, ContentStorage is used for 2 very different use cases – export of StencilSets files, and user attachments. The latter we will be using an ECM (which may be Alfresco One, or another system). The former we would like to move out of the filesystem.It looks easy enough provide a

Re: Implementing new ContentStorage locations

jbarrez — Wed, 28 Oct 2015 19:37:10 GMT

(moved post to Activiti Enterprise)

The Content storage is used for attachments, stencil scripts, generated documents (BPMN/Step editor document generation task) and for storing the LDAP sync logs.

No factory method is needed. You make the implementation implement the interface and add @Component to id. Then, put that class on the classpath in a component scanned package (eg com.activiti.extension.bean). Also add @Primary to override the default one. That's it.

Re: Implementing new ContentStorage locations

jonnyg — Wed, 28 Oct 2015 21:33:20 GMT

Thanks. One other thought – in our mind, stencils ought to go in a completely different repository (e.g., a table in the Activiti database) than user attachments. The latter, we want to hook into an ECM. Is there a way to distinguish that in the code?

I guess I'm also trying to better understand how Activiti integrates with ECM's. I understand we can update activiti-app.properties to point to an Activiti One installation, but I'm not sure how that happens at the code layer (e.g., what if we need to store in 3rd party ECM?)

Re: Implementing new ContentStorage locations

jbarrez — Thu, 29 Oct 2015 09:32:31 GMT

Stencils actually go into the database, it's only when defining custom scripts that these scripts are stored in the content store. The SCRIPT_FILE table has a foreign key to the STENCIL_SET, and a store_id, that is the id from the content store. The reason is performance: streaming a file from disk is quicker than via the database.

But no, there is no way to distinguish that in the code, the ContentStorage only takes in an Inputstream and has no knowledge about the calling method.

About the ECM integration: this is for
1) finding documents in Alfresco (or Google Drive/Box if you enable it) and attaching them to a task
2) publishing documents from task attachments / document generation tasks to Alfresco.

You enable Alfresco in the properties, but configure the Alfresco repository in the 'Tenant > Alfresco Repositories' tab

Re: Implementing new ContentStorage locations

jonnyg — Thu, 29 Oct 2015 10:46:26 GMT

…and memory is faster still. Does Activiti have a caching model for application artifacts, whereby (processes/forms/stencils) are generated to files and/or cached in memory by the server?

I see in 1.3.2 that the script files are generated – via createTenantMergedScriptFile() upon saveStencilSetForEditor() (coming from the editor), as well as from importStencilData() – coming from the import. It seems to me that the application startup could also do this: check that the scripts are there, and generate them if missing.

Re: Implementing new ContentStorage locations

jbarrez — Tue, 03 Nov 2015 12:36:25 GMT

Yes, scripts are cached. Forms definitions and process definitions are too.
Documents are not cached, as they can be changed on other nodes and are not static.

The application could do that on startup, but with lots and lots of tenants this might not be a good idea.

Re: Implementing new ContentStorage locations

jonnyg — Tue, 03 Nov 2015 18:11:59 GMT

Glad to hear the code pieces are cached. We don't need to cache documents.
What we would want to do on startup is check that the Stencil scripts are there, and generate them if missing.

Re: Implementing new ContentStorage locations

jonnyg — Mon, 21 Dec 2015 14:36:37 GMT

from last month: "What we would want to do on startup is check that the Stencil scripts are there, and generate them if missing."

Any comment on this? As said, our requirements are that there can be no shared drive.
Attachments will go into an ECM (e.g., Alfresco).
Helper files like stencils we expect will be generated as needed.
Is this possible today? What will it take to get there?

Re: Implementing new ContentStorage locations

jbarrez — Tue, 22 Dec 2015 11:30:21 GMT

Stencil scripts are stored in the SCRIPT_FILE table, with a store_id. So if you have plugged the content storage interface, this should work for stencil scripts too (they will be stored in the ECM system if that's the implementation for the ContentStorage interface)

Re: Implementing new ContentStorage locations

jonnyg — Tue, 22 Dec 2015 13:57:59 GMT

Joram - you are still not getting addressing our need as stated above:
"What we would want to do on startup is check that the Stencil scripts are there, and generate them if missing."

Is that how the system is currently designed? We want to be able to treat the generated stencil scripts as disposable, and also, regenerateable upon startup.

Re: Implementing new ContentStorage locations

jbarrez — Mon, 04 Jan 2016 19:31:10 GMT

I'll try to express myself better if my answer was inadequate: no, they are not generated on the fly by design.

Right now, stencil scripts are stored in the content store, and there is a link to the store using the store_id (see my comment above).
The stencil script is created when the stencil is saved. If there are existing scripts, they are merged and the merged result is stored again in the content store. When they are needed, they are fetched from the db and content store (and cached).

In theory, you could remove that, and on bootup walk through all your stencils, parse them and execute similar logic and put them in the cache. But that's theoretically and as far as I know, nobody has tried this path yet.