Support for process definition development version

Hello fellows,

Please excuse my ignorance if the topic is already discussed, but I didn’t managed to find and answer to it.

We are using Activiti 5.14 (rather old) and we need to deploy the same process definition to different servers (engine databases) in different paces (customer’s request) and the engine defines (stores) some kind of a “definition deployment version”, specific for each engine database.

When we receive a request for support, we need to know which development version of the process definition is “hiding” behind a certain “deployment” version on the corresponding server. Currently we abuse the “Documentation” field of the process definition (XML) but this somehow prevents us to use it as intended.

Please advise if there is more appropriate way to handle the process definition development version (probably in later engine versions)? Or share how you cope with the problem, if the engine (process definition XML) does not support such information.

We would like the process definition development version to be programmatically accessible through the engine API. Otherwise the only other option would be to read the definition from the engine’s DB BLOBs. Unfortunately customer’s DBs are not accessible for the developers (at least in our company) and the process of requesting such an information is too complex and slow. We have developed a console-based (for security reasons) application for managing the process definitions (deploy,update, etc.) and it retrieves the development version stored in the (abused) “Documentation” field of the XML.

Hi,

A way to do this would be to use an extension element in the BPMN XML on the process level for example. Then you can use the console-based application read this extension element value.
Another way would be too use the process definition category value for this purpose.

Best regards,

Tijs

Hello Tijs,

I just browsed the 6.0 User Guide and I consider you are referring the “process definition category”, which is defined in the targetNamespace attribute of the definitions field. I’m still not familiar with the latest version of the engine but I suppose it could not handle/provide/access this information, right?

I think the “deployment category” is not an option in our case because it should be provided manually during the process definition upload/deployment, which is not reliable.

Finally, I think that an XML extension would be the cleanest approach, but its implementation depends on the required efforts.

In any case it would be very nice this option to have support in the BPMN editor :slight_smile:

Regards,
Monique

Hi Monique,

I’m not sure if I understand your comment about the process definition category. In the BPMN XML there’s a targetNamespace attribute that we also expose in the Eclipse Designer and web based modeler. The value of this targetNamespace is automatically used to fill the category attribute of the process definition object and you can access it by retrieving the ProcessDefinition instance.

I also think the XML extension is the cleanest approach and yes we should expose it in the Eclipse and web based editor. That would be good to have anyway. I’ll add it to the list of things to implement.

Best regards,

Tijs

Hello Tijs,

I’m working for a long time with Activiti but, to be honest, I didn’t knew about the “category”. That is why I browsed the 6.0 documentation and found what you refer. Then I checked the 5.14 documentation and found that it contains the same definition and I realized that I forgot about the “category” and the reason is that back in Activiti 5.14 (and its predecessors) only the process’ “name”, “key”, and “description” attributes were available in the engine API (org.activiti.engine.impl.pvm.ReadOnlyProcessDefinition), i.e. back then the “category” was useless from our point of view.

It is very probable something to be overlooked, of course. Nevertheless we never used the “category”, although we considered it handy, just because we didn’t found a way to reach it programmatically.

Cheers,
Monique

Hello Tijs,

Based on your statement

I also think the XML extension is the cleanest approach and yes we should expose it in the Eclipse and web based editor. That would be good to have anyway. I’ll add it to the list of things to implement.

I browsed again the engine issues but did not found similar task. That is why I registered https://github.com/flowable/flowable-engine/issues/473

Cheers,
Monique