Element templates are a promising new feature that has a lot potential, especially for repetitive tasks like audit-writing and message sending (correlation). But …
The json template definition is part of my software development lifecycle. It is bound to certain classnames, it might get changed (extended) over time.
What I am missing before I feel safe to introduce this to my team is the ability to centrally develop, version and distribute the templates. So far, at least from what I got, my only option is to manually pass the file around and suggest to all my colleages that they put it in their modeller/resources. One more manual step in the “Ramp up” guide for new developers. And even then: When the file changes, we all must ensure that we are using the latest version, otherwise we get in trouble.
Do you already have ideas how to address this problem that we can discuss here? Reading the config from an url (which could be a “latest” redirect) might be a good first idea. But what if that url needs authorization (nexus/stash/…)?
We are currently investigating how to proceed with element templates. You feedback is highly appreciated and helps us a lot!
I personally have a few thoughts on the stuff you mentioned. The stuff I’d go for is marked with a .
Distribution
This is a crucial topic if we would like users to scale out element templates on a larger scale. It can be solved by:
storing templates in a remote repository (i.e. web modeler)
storing templates local to the diagrams (in a workspace the modeler needs to be aware of)
The second thing is probably much more convenient, because it allows element templates to be first-class citizens during development and to be checked in using the version control system of your choice.
Versioning
There is quite a spectrum of things we could implement or not implement here.
Most simple case: developers handle version upgrades themselves
Advanced case: the modeler has a notion of version, warns the user that a new version of the template is available, asks him to populate new / missing fields, …
I think both versioning and distribution are relatively simple if you use a “repository” of some kind (I gues sthats what you call “workspace”), so I could just load my templates from an url (that points to latest).
The more complex issue is how to keep code and templates in sync. Consider I provide a Mail-Send-Task as an extension (could be company wide, could be world-wide, why not have templates and delegates as community extensions (or enterprise-add-ons).
How do we make sure, that the template attributes match the delegate-implementation attributes? Imho thats only possible if we treat template and implementaion as one software artefact.
It would be great to have an option to specify which templates I want to use in the modeler. A first version could be to specify a file-path as startup parameter to the modeler.
I don’t think the modeler should integrate a “versioning” for templates or a “binding” of workflows or code with templates. This will quickly get too complicated IMHO.
Like the idea … maybe even better: have the modeler-zip in the maven repo, release the templates to the repo and use maven-assembly to build a team-specific modeler. Always a good idea to have something scripted instead of a manually created “byte-ball”.
But how should the upgrade path for these teams look like? Someone decides they get new templates, meaning everyone downloads the new version of the modeler?
I get your point … of course it would be best to connect to some kind of repo … but a distributed fully configured modeler is a “quick win” that we can start using now …
We implemented exactly that and now our JSONs are developed centrally and distributed via a GitLab project called “element-templates” that is mapped to the /resources folder of the Camunda Modeler. Now JSONs written by the developers are being pulled by analysts (via GitKraken) directly into the Modeler folder.
.