As an IT architect I want to define process variables if they cannot be detected automatically

[TamaraGunkel]

The vPAV cannot find all definitions and usages of process variables. Although we try to support more ways of finding process variables, there will be always some use cases that we cannot cover. Thus it would be useful to have a fall-back solution where users can manually define process variables. They should be able to define when and how a variable is used e.g. in a JSON file. This file should be read by the validator and the definitions should be integrated in the process variables graph. Thus the variables are known by the vPAV and do not raise an issue if a read/write access is found.
Manual variable definitions could be highlighted in the report so that users can clearly see the difference.

[TamaraGunkel]

@cl-a-us Does that summarize your idea correctly?

[fkoehne]

Should we define those within the model file? If we had a representation for data flow there, that would be a convenient interface for other use cases as well (let's say a "write to model" button along with a confluence modeler plugin that displays the dataflow).

[sdibernardo]

I am against defining those in the model file, as this might corrupt the file (in the sense, that Camunda might not parse the file anymore). If this can be achieved within the Camunda Modeler this would be a great way to enhance the analysis. But if this can not be done, the JSON file seems to be the most convenient way to pass the information

[fkoehne]

Maybe @TamaraGunkel could clarify this with some quick experiments?

[mschulte]

The BPMN2.0-Standard explicitly allows defining your own extension within the model-file. so there shouldn't be any issue with that:

I would also prefer a integrated solution within the XML-file and even with our confluence modeler.
However, i would doubt that an IT architect is concerned about data-flow within a process application that - to my mind - is an issue of developers. The idea of manually adding missed variables is smart though, but might be cumbersome in real world applications depending on the amount of variables that couldn't be detected automatically. Anyway to my mind it is better to define missed variables within the process model rather than adding false positives to the exclusions of vPAV.

[sdibernardo]

Generally I like the idea as well, but only if its implementation is feasible.
@mschulte Does this model run properly within Camunda? IMO, adding those tags should be done using the GUI of the modeler, as adding those tags in the XML is prone for errors.

[mschulte]

Of course it should be modeled within the GUI, manipulating the XML was only for testing purposes, you could also facilitate camunda properties (lines 9 - 12 in the above screenshot) as they can already be manipulated within camunda modeler. If we would use our own extension we also would have to implement a modeler plugin for management of that data flow elements. What about doing that in vPAV GUI and not the modeler? You just have to update the model file.

I like the idea of an own namespace because we would be independent from anyone else and could also facilitate that in confluence modeler for example.

What do you mean with "does this model run properly within camunda?" You are referring to the engine itself? I didn't tested that but wouldn't assume any errors as e.g. Signavio extension elements also do not influence engine behaviour.

[fkoehne]

This is also a question of perspectives. You could repurpose the vpav results as an auto-generated part of the documentation.
Further: If we have the model and the checker results in separate files, we will need some logic for out-of-sync scenarios. I would like to avoid that.

[fkoehne]

Update: I chatted with @cl-a-us and Markus and we are unsure about a modeler integration. Let's try to find a minimal implementation and then generate some feedback regarding "vPAV as a documentation tool".

[cl-a-us]

@mschulte: Depending on the usage scenario, this feature could be relevant for developers (debugging) and architects (documentation) as well.
I like the idea of a bpmn.io plugin, if the implementation is not to complex.
Nevertheless, we can start with own attributes in the bpmn xml file and add a representation (i.e. a bpmn.io plugin) in future.
As a result of a vpav run a new bpmn file can be exported and can be used to replace the bpmn file in the process application.

A plugin, that we might provide in future, can replace the view ´process variables´ in the vpav validationResult.html.
In that case, I propose a plugin, which displays read, write, and delete access of process variables similar to the turquoise bubbles/badges (class=¨badge-variable-operations ¨) we display right now. A click on a badge would open the properties panel and show which variables are accessed, the type of access (read, write or delete), and the time of access (start listener, end listener, (delegate) implementation …). We could also distinguish between manual and automatic recognition of variables. Manual defined entries could be added, edited, and removed, whereas variables discovered by vpav could only be disabled.
The advantage of the plugin would be, that it could be installed e.g. in camunda standalone modeler, in online modeler, (like the confluence modeler), or even in camunda cockpit.

Having a plugin in mind, own attributes in the bpmn xml file should define the following information (please extend the list, if I miss something):

• Variable name
• Time/point of access (start listener, end listener, (delegate) implementation …)
• Discovery(?) type: vpav (automatic) vs. manual
• Disabled: true/false (to mark false positives)
• Timestamp
• Entry ID: (to match false positives)
  A new vpav run should replace all ´old´ automatic discovered entries (except for disabled entries).

[TamaraGunkel]

Variables can now be defined in a variables.xml file (see the development branch). Currently it is possible to provide the name, process id, creation point and scope for a variable. All variables will be included as WRITE Operation at the beginning of the defined creation point. Is there anything else that should be included?

@cl-a-us , should it also be possible to define read or delete operations?