I wonder how to use custom objects in user task the right way.
The user should select a point on a map as a user task. The point should be send to Camunda as an object with it’s coordinates (x and y).
So this example tells you to create a java class for something like that and send it as a variable. But how do you care of it in the bpmn file? If you look into the bpmn of the example there is nothing about the custom object. It is not a form field. Can you document that there is a variable needed containing your information?
I also found another post suggesting to use AbstractFormFieldType to create custom form fields.
I don’t get when to use which method.
- Version 1 seems to be more straight forward because you can use a simple java object, but the variable doesn’t appear in the bpmn model.
- Version 2 needs inheritance and you have to register the custom type in the engine (somehow …). Then you can use it in the bpmn form section as a custom type.
So I wonder when to use which version and how to always document needed variables in bpmn?
You may use the data symbol in the modeler for documentation purposes, but Camunda does not required a variable “declaration” in the BPMN. It will simply accept the variables you are submitting with the IDs specified by your field ID and store it as process variable.
A json serialization for strucutured data objects is preferable.
I understand, but as far as I know it is recommended to use rather less data objects in the BPMN? Because they are programmatically “useless” in Camunda and can easily disturb the readibilty? So it seems to me that there are potentially many “invisible process variables” the process depends on. So you probably need external documentation on BPMN tasks and their necessary I/O parameters? I mean one doesn’t want a single data object for every variable needed, do you? Or maybe I could use the Properties tab of a data object or even of the task itself to document all variables at that task?
Could you explain what’s the use case for custom form types then?
You are right. It does not make sense to clutter your process model by modelling all data as model elements. This should be used only when it helps clarity e.g. to emphasize the data usage at a certain point. Documentation of all data used and their data structure is not part of the BPMN standard.
Your custom form can simply pass a JSON containing the two points (or other form fields) to Camunda. Usage of Java classes is no longer recommended.