Version tag for decision tables

Hi,

will there be version tag support for decision tables in future.

We have following situation.

We use spring auto deployment to deploy processes and cases and decision tables.
Customer changed a decision table in production.
Next deploy in production will lead to old decision table because we have not take all changes of customer in our git.

When version tag would be supported we would modify auto deployment based on version tags . So in our scenario our git version could be 1.0.0 and customer version could be 1.1.0.
Because our version is lower we would not auto deploy it.
What do you think about this idea?

Best regards,

Markus

1 Like

A couple of crude ways to do that would be:

  • Dedicate the first row of the table to a version number, though I’ve not thought through how you would access/validate that prior to usage.
  • You could put the version number in the first input column and then require the client application to supply the version it wants to use as part of the evaluation payload.

Unfortunately, after checking the Camunda docs, it doesn’t appear that you can dictate which version is used in the evaluation call itself, at least in the REST API. The Java API might support that.

Hi,

I am not talking about default versioning but about version tag.

I think it would be nice to manage a version tag on dmn like already possible on bpmn process.
This could have a defined semantic and auto deployment based on this could be possible.

BPMN does already support this in camunda. Would be a nice feature for dmn and cmmn too.

Best regards,

Markus

I agree. Feel free to raise feature requests in JIRA and/or to contribute this.

1 Like

I think the problem here is how DMN operates (at least my superficial understanding). It executes from a cache that I assume contains only the latest version of the DMN, whereas I’ll be the BPMN is read from the database each time.

In other words, the manner of persistence and use is dictating the how versioning is controlled. BPMN is persisted and read from the database on each activity, while DMN depends upon a cached instance, backed by a database record. The cache provides exceptional performance.

I suppose they could persist different versions and instantiate the cache with those versions, but that’s way beyond my knowledge. I really think if you want to do this, you’ll need make a column with the version number and then insist that the client pass that version as part of the evaluation payload. It’ll be ugly to manage, though.

Hi @thorben

I created a first pull request for camunda-dmn-model project.

See https://github.com/camunda/camunda-dmn-model/pull/3

In my opinion this should be completed first to have versionTag as attribute in Decision instances.
Afterwards it is possible to add changes to camunda-bpm-platform.

Best regards,

Markus

Hi Markus,

Thank you. I think we should do both in parallel, extend the model API and bpm-platform. A new camunda attribute is only justified in my opinion if it has semantics in the engine. For other purposes, regular extension elements should be sufficient.

Cheers,
Thorben

Hi Thorben,

ok than I will make in parallel efforts to extend the bpm-platform.
Hopefully I will be able within the next time to make a pull request.

Best regards,

Markus

1 Like

Hi @thorben,

I forked the camunda-bpm-platform and added semantic for versionTag to DecisionDefinition.
It is now able to save the versionTag in database, get them from DecisionDefinition and query and order it with DecisionDefinitionQuery.

I added a few tests for these features equal to tests for versionTag in ProcessDefinition.
Do you think this is enough semantic in engine to make a pull request on camunda-bpm-platform?

I think more features aren’t implemented for ProcessDefinition. So it would be equal.

Best regards,

Markus

Hi Markus,

Sounds good. Just go ahead and raise the pull request and we will give you feedback on the implementation.

Cheers,
Thorben

Hi Thorben,

I made a pull request: https://github.com/camunda/camunda-bpm-platform/pull/272 .

Waiting for your feedback :slight_smile:

Best regards,

Markus

Has this functionality been included?

The latest Camunda modeler (version 3.7.2) does have a “Version Tag” field on the UI, but when you enter a value it doesn’t appear in the model on the XML tab, and not surprisingly on that basis gets lost when the model is saved and reloaded.

We were looking to use versionTag to perform a consolidation across our BPMNs and DMNs but it looks like the “versionTag” support hasn’t been included across the board - or am I wrong?

Thanks