system variables

[tom.baeyens]

i'm thinking of introducing system variables.

the idea is that node behaviour implementations could use system variables just like normal variables. but these would not be visible to the user.

examples could be: a sequence could store the current index in such a system variable. or a fork could use such a variable to know which concurrent paths already have finished.

[jbarrez]

Tom, could you elaborate this a bit further please?

Is it some kind of 'global process variable'?

[tom.baeyens]

it's not a global variable.


sometimes activities want to use process variables. e.g. the index of the current activity in a sequence. or which concurrent paths of execution have ended.

activities could use the normal process variables. but then they are also visible to the user. also name clashes could occur as the user doesn't know what process variables the activities will use to store their information.

[jbarrez]

Now I understand.

This functionality is indeed something that could be useful to have. I have already had 1 use case which had to know whether path A or B was taken, so in that case I set a custom variable on the process. But isn't this very complicated to implement?


About the name clash: add a prefix (eg "jbpm.") to the process and document that this prefix is taken... That's what I would do

[jorgemoralespou_2]

We have done something similar to these with JBPM with nested scopes/contexts.

We had something like:

ExecutionScope
-- InputVariablesScope (read only)
-- OutputVariablesScope (r/w)
-- Global variables
-- Normal variables
-- Transients (not persistable to DB)

This last 3 had a searching (if not explicitly defined) first in transients, second in normal, third in globals.

Also, every Context had methods to access (get/set) its subcontexts, or its variables. All of them were defined as maps, so it could be easily used from EL.

[tom.baeyens]

Makes sense. I'm trying to get this into the environment. To a large extend this is done. But we'll need to implement more use cases to see if it's designed properly and can handle these kinds of use cases.