cancel
Showing results for 
Search instead for 
Did you mean: 

Is it possible to pass a custom version number to process

arunpjohny
Champ in-the-making
Champ in-the-making
I'm developing a app where the kind of actions that can be done can vary from one version of the process definition to another.

I want to check whether a particular action can be taken based on the version of the process definition in question, here I'll not be able to depend on the automatic version number of the process definition since I may have to do some checks based on a predefined version number.

So is it possible to pass some additional information to a process definition like a process-version to a process definition, which I can access at runtime.

Thank you
6 REPLIES 6

mmaker1234
Champ in-the-making
Champ in-the-making
Hello,

When you are going to check the process definition version?

If it is on process start, you could use the business_process_key to distinguish. Note that this value is set at deployment time (as far as I remember) and in must be unique (amongst all deployed process definitions);

If you are going to check it in a JavaDelegate, then you could define a (process instance) variable in the definition and access it in the JavaDelegate.execute() method.

Otherwise, about half an year ago I also insisted on adding a field for "external" process version but my ask was refused: http://forums.activiti.org/en/viewtopic.php?f=6&t=4121

Best Regards,
Monique

arunpjohny
Champ in-the-making
Champ in-the-making
@Monique thank your for taking time to reply

I was also looking for the same, a way to specify an external version number at the definition time.

I don't think it is practically possible for me to use a process instance variable since it will require me to have another metadata stored some where else with the active external version number.

I'm looking at your previous post and the solution you've suggested.

mmaker1234
Champ in-the-making
Champ in-the-making
Hello Arun,

One particular workaround could be definition of a field - either a form one or a ServiceTask one. To be honest I didn't succeed with the form one, but for my purposes a ServiceTask field did the job:

…
    <serviceTask id="callMyBusinessLogic" name="BLcaller" activiti:async="true" activiti:class="bar.foo.RequestBusinessLogicAction">
      <extensionElements>
        <activiti:field name="operation">
          <activiti:string>DoSmthng</activiti:string>
        </activiti:field>
        <activiti:field name="processVersion">
          <activiti:string>2.3.x</activiti:string>
        </activiti:field>
      </extensionElements>
    </serviceTask>
…
This  way "operation" and "processVersion" are still accessible as process instance variables in a JavaDelegate but are defined at design time.

Hope this could help in your case,
Monique

frederikherema1
Star Contributor
Star Contributor
@mmaker1234 nice,that's a good way of making this available at runtime when defined at design time. Another alternative is to use the category for this (this is also query able in the deploymentQuery) and can hold any arbitrary field… (see root tag of bpmn xml)

mmaker1234
Champ in-the-making
Champ in-the-making
Hello Frederik,

Unfortunately "query able" is not enough in some situations. For example I would like to know (log) the "external" version of my process on each event. I think that querying the deployment table and parsing the XML on each event is too much unnecessary load on the DB - most of the time it will serve my logs instead the (business) logic and, of course, slow down the work of the Activiti engine.

Or, may be, I missed something?

Best Regards,
Moniqe

frederikherema1
Star Contributor
Star Contributor
parsing the XML on each event is too much unnecessary load on the DB

Process-definition category is now (5.11) stored in the PROC_DEF_ table itself, so no XML-parsing is needed. On top of that, process-definition cache is in place, so XML is pares only once (or again, if evicted from LRU). But if you don't want to query inside your service-task (which is something you want to avoid, indeed) your solution with the filed-injected is way better. Was just proposing alternative way Smiley Wink