CODEWITHSUNDEEP
camunda
Srinivas
Srinivas

Reputation: 1413

Controlling Version of Deployed Camunda BPM

Everytime I modify and deploy a process, the version number is increasing.I understand why it is increasing. But is there a to force to a predefined version and the deployments will override only that version. The reason is even for small bug fixes, I don't want the version to change.

Upvotes: 3

Views: 3457

Answers (3)

Vinit Jordan
Vinit Jordan

Reputation: 343

Camunda REST will help you to deploy and delete the version of deployment. You just have to pass deployment id:

If you are using separated Camunda process engine(server) then your REST API to delete deployment will be:

http://localhost:8080/engine-rest/deployment/fa9af59a-382b-11ea-96d8-5edcd02b4f71

or if your Camunda process engine integrated with spring boot application then your URL will be:

http://localhost:8080/rest/deployment/fa9af59a-382b-11ea-96d8-5edcd02b4f71

Or

You would have a process.xml file in resource folder of your application. You can set isDeleteUponUndeploy to true. So on every Undeployment of workflow, your workflow file will get deleted.

<process-archive>
    <properties>
      <property name="isDeleteUponUndeploy">true</property>
    </properties>
</process-archive>

Or

You and delete from Camunda UI as well the link is: http://localhost:8080/app/cockpit/default/#/dashboard

Now goto deployment and select your deployed version and click on delete version.

Upvotes: 0

meyerdan
meyerdan

Reputation: 549

no this does not work. You can deploy a new version and delete the old one.

Upvotes: 1

Jan Galinski
Jan Galinski

Reputation: 12003

Are you talking about production or development?

In dev, you can configure the processes.xml so all instances and old version of the process are removed:

<process-archive>
    <properties>
      <property name="isDeleteUponUndeploy">true</property>
    </properties>
</process-archive>

On production, you would not want to delete running or completed instances. You might want to migrate running instances to the next version, but that is not generic, it depends on the process and the changes made. Make sure to read process-versioning-version-migration from the user guide.

A third approach would be to work with calls to services (expressions/delegates/listeners) instead of hard modelling inside the bpmn. If for example you write "${price > 500}" at an exclusice gateway flow, you will have a new process version when you deploy a "fix" with the value "1000". If you design your process application that it calls "${myPriceCalculator.limitExceeded(price)}", you can deploy a new war, but the process remains untouched.

Upvotes: 2

Related Questions