cancel
Showing results for 
Search instead for 
Did you mean: 

Versioning bpmn file independently of VCS

zze_one
Champ on-the-rise
Champ on-the-rise
Hi,

I would like to share with you guys part of a proof of concept I implemented, in order to have your point of view.

The final goal :
Pairing a set of rules to a workflow while being able to modify the workflow without redeploying the application.

I have been focusing on the versioning of the bpmn file so far (so I'm not talking about the deployed version).
I know that the normal way of managing the version of the file is to rely on the Version Control System, but one of the requirement is for the bpmn file to know about its version number. Meaning that the file should contain the manually added version.

So this is my implementation :
In the bpmn file I added a textAnnotation element identified by "versionNumber", that contains our customized value :

   
   <textAnnotation id="versionNumber">
       <text>1.2</text>
   </textAnnotation>


Before each deployment I'm parsing the file in order to make sure that the value is there and is correct.   
The deployment won't happen if it's not the case.

This value is easily stored and can be retrieved thanks to the following method.



   @RequestMapping(value = "/artifactVersion", method = RequestMethod.GET, produces = "application/json")
   public ResponseEntity<Object> getArtifactVersion(String key){
      StringBuilder response = new StringBuilder();
      try {
         
         ProcessEngine processEngine = getProcessEngine(); //private method
         RepositoryService repositoryService = processEngine.getRepositoryService();
         
         String lastDeployedId = getLatestDeployedProcessId(key);
         BpmnModel model = repositoryService.getBpmnModel(lastDeployedId);
         
         TextAnnotation versionArtifact = (TextAnnotation) model.getArtifact("versionNumber");
         response.append("Artifact version of bpmn file: " + versionArtifact.getText());
         
         return new ResponseEntity<Object>(response.toString(), HttpStatus.OK);
         
      } catch (Exception t) {
         response.append(t);
         return new ResponseEntity<Object>(response.toString(), HttpStatus.BAD_REQUEST);
      
      } catch (Throwable t) {
         response.append(t);
         return new ResponseEntity<Object>(response.toString(), HttpStatus.INTERNAL_SERVER_ERROR);
      }
   }



I don't think this is a practice that you recommend but it's in my mind a good enough solution.
I would like to hear from more experienced developers about the limits of this solution and of course about any alternatives to this implementation.

Thanks a lot in advance,

Yohann


4 REPLIES 4

jbarrez
Star Contributor
Star Contributor
Looks good to me. The only downside is that you cannot forget to update the version tag manually of course.

zze_one
Champ on-the-rise
Champ on-the-rise
Indeed. I'm controlling this aspect before deploying the file. Thanks Joram.

zze_one
Champ on-the-rise
Champ on-the-rise
Hello gents,

We would like to reuse some code you created in BpmnParse.execute().

This is what we would have:

<code>
private String getProcessKey(String contentBPMN) {

        BpmnXMLConverter converter = new BpmnXMLConverter();
        BpmnModel bpmnModel = converter.convertToBpmnModel(new StringStreamSource(contentBPMN), true, true);
        return bpmnModel.getMainProcess().getId();

}
</code>

But a copy / paste will remove all dependencies on the next evolutions you guys are gonna make.
So I do have a quick question for you.

Do you know if the current implementation of the parser will stay the same in the next versions of Activiti ?
My concern is really about the usability of the code in a near future. It may not be a good fit anymore depending on the direction Activiti is taking.

Thanks in advance,

jbarrez
Star Contributor
Star Contributor
That bit of code won't change any time soon. We've settled on the BpmnModel approach, took us a lot of time and we're not planning on changing it.