A workflow process often needs information about its environment when executing service tasks. For instance, the ServiceTask that invokes a web service may need host, port, and username/passwords details to invoke an external service successfully. Configuring these values inside the workflow definition is problematic when promoting a definition change between dev/test/prod environments. Having a client supply these values as a process variable improves things in many respects, but it still requires the variables to be updated in every instance that references them when the environment changes.
We have been thinking about putting variables into a VariableService that would allow you to not only create variables for a process instance or task, but also system wide environment variables or process definition specific variables. This is something we would like to work on after the 6.0 is released. Let us know if you have specific ideas about this as well, itâs still something that needs quite a bit of thinking.
Hi, my 2 cents on this:
system-wide variables or process-definition variables are definitely something very useful.
The question could be even made more generic into âhow could I create some custom âgetterâ methods that can be used in JUEL expressions; where these âgetterâ methods return data from a datasource which is not the flowable process variables?â
So for example, applied to system global variables, that would mean
You have to create your own datasource to store the system settings (use file, any relational DB, or Mongo, whatever)
You have to create a library with static getter functions . Under the hood, the getter functions do the calls to the datasource. For example, create a method that retrieves a String Value given a Key as string .
Then, one would create a JUEL expression, for example setting the property with value ${MyOwnSystemsettingsLibrary.getStringValue(âfunkyWebserviceURLâ)}
Though not being a developer myself, my little toe feels that addressing other datasources could be quite tricky. Limiting the scope to getters would definitely reduce headaches of multi-datasource transactions. The user guide talks about using Beans in chapter 4.6 (${myBean.doSomething(myVar, execution)}) ; but I guess it wouldnât be that simple ?
My preference would be that Flowableâs default variable resolution would work with variables scoped at the engine level. For instance, if the variable was not found at the process instance execution scope, Flowable would then attempt to resolve the variable at the engine level scope (if engine level variable support was enabled). Support for engine level variables also needs to take into account multi-tenancy as one tenant may have a need to define different environment variables than another tenant.
@pieterclaeys You can already use Spring beans or standard Java beans in JUEL expressions in Flowable. So itâs easy to expose a bean that retrieves values from a database or another resource in that way. We could expose an engine variable bean that allows you to directly get a variable value. That would improve the performance because you donât have to look first on the execution scope level etc.
@robert.hafner Yes, I agree as well. And yes, this needs multi-tenancy support built-in.
What about interfacing associations (rules starting with =) of variables from different scopes (including engine, environment, execution or more importantly to me, previous tasks). Or is the task variable association already available there at the definition or the process instance level.
since it âneeds quite a bit of thinkingâ, I am stretching thin with my limited understanding here for you:-), my 2 cents -since Flowable next is to allow change state of a running process instance to a previous activity (is it allow looping?) or future activity or concurrency if applied to variables next. Perhaps a guard for variables or limiting such support to only transient variables may help?
+1 for setting up a way to do this without java coding.
Regarding java, would anyone mind sharing an example of how I could get an instanceâs executionid value inside a variable? Iâd like to use it inside an http task inside a process. Iâm not a java coder.
Was there a follow up of this subject? Is it possible to manipulate variables related to a process Definition? In my use case I want to manipulate variables, before the process is activated and a new instance generatedâŚ