TLDR; I need some good literature about when to use case file items over variables and vice versa.
I’m currently playing around with camunda and its implementation of the CMMN specification. When it comes to holding the execution state of a case, the specification defines the case file and the case file items as the way to go. Given the examples, that I found for camunda it looks like the prefered way in camunda is to use variables instead of defining the case state with a complete case file model.
My question here is the following: is there any other reason than “We had variables already, and there was no time/budget/interest in using the case file item terminology to represent them” or is there another reason for using a custom extension of the cmmn specification over the possibilities already provided by the spec? And if so, where can I find more about the reasons behind this decission?
I’m curios about this, because I’m currently trying to build a system that provides suggestions of what actions to do next in a given case state of a defined cmmn model. And as far as I can see it from what I already understood, the whole case state is defined by the lifecycle states of the plan items, and the content of the case file, when looking at the cmmn spec. But when I look in the implementation used in camunda, variables seem to be the prefered way to go, even though they are not part of the specs and not visible in the cases visual representation, even if they are at a level, where a business architect could understand what he is dealing with.
What do you all think about this? Would it be better to understand process variables more like case file items when we are in a case instance? When should a variable be used over a case file item and vice versa? Isn’t it problematic, that variables tend to hide state information from the business architect, or is it a good thing?
I’m interested in your opinion and references to literature if you know any. I already have read the german 5th version of “Real-Life BPMN” by Jakob Freund and Bernd Rücker, but this topic isn’t realy addressed there.
I’m afraid I cannot give an exhaustive answer and am also not aware of any literature on this topic. However, I can give a couple of aspects that lead to the current implementation in Camunda:
We had variables already: This is a major point. Not only for resource reasons as you suggest, but also because people who use Camunda for automating BPMN are familiar with this concept.
Managing risk is another aspect. From our experience, BPMN’s execution semantics for data objects, data transformations, etc. are way too complex and therefore not practically useful, neither for users applying the specification, nor for vendors implementing it. We were skeptic for the same reasons with CMMN’s handling of data. Implementing case file items properly is not a simple task and we did not want to take the risk of putting significant effort into something that ultimately noone uses.
Not sure I understand this quesion.
I believe there is not much choice here. You can use case file items for documentation purposes, but Camunda won’t interpret them at runtime. So if you need any runtime data, you have to use case case variables.
It is true that there is no direct relationship between variables and case file items. I am not able to say if this a real problem. If you need this, you can consider building a custom solution on top of case variables that would make the relationship visible, for example by using variable naming conventions.
As said, this is far from exhaustive, but I hope it helps.
Lets describe it in another way: wouldn’t it be beneficial to understand variables as case file items, so when you call a case model process, the arguments/variables are accessible through corresponding case file items in the case instance. This would allow for modelling input and output variables using the cmmn spec and would imho avoid the currently necessary custom cmmn extensions provided by camunda to set variables. Or to say it in one more way: hiding the additional features for variables behind the cmmn elements that are ment to be the cases state memory, looks much more elegant to me then adding a knew way to manage state memory and ignoring the specs completly.
I’m ignoring the needed effort here to implement this, because it is more a theoretical question for me, then a practicle one. The reason for this is, that I’m working on a master thesis related to cmmn and I will need to look into the “state memory” of the case instance, but when it comes to camunda there is no such thing other then camundas own variables, which aren’t part of cmmn. Some literature or insights of why it was implemented this way would have resulted in a good paragraph or two in my thesis.