Implementing new ContentStorage locations

[jonnyg]

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 new implementation of com.activiti.content.storage.api.ContentObject and com.activiti.content.storage.api.ContentStorage. What I can't find yet is the factory method which sets the storage class. Is there one? Where is it?

[jbarrez]

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

[jonnyg]

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?)

[jbarrez]

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

[jonnyg]

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

[jbarrez]

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.

[jonnyg]

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.

[jonnyg]

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?

[jbarrez]

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)

[jonnyg]

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.