Business process models can be imported from various tools, and may apply different processing to create the BPM format.
Some general guidelines are:
- Models should support tasks (steps), start events and end events and swimlanes to identify roles. Optionally they can include choices (exclusive gateways), intermediate events and other entities (such as data).
- Inclusive gateways (parallel processing) should not be used because the execution engine does not support them. If they are required, they can be simulated by a series of call steps to the different branches of an inclusive gateway.
- The model, swimlanes, tasks, flows, events and entities should all support properties. If only string-based name/value pairs are available, the following are recommended:
- Use the name portion to identify the property, but using a dot-delimited form for objects. For example, set the config property "foo" by using the name "config.foo".
- In the value portion, write values as if they were JSON values (and can be read with a JSON parse), so that numbers, booleans and objects are supported. Anything that does not parse can be assumed to be a string. Where a string is required rather than a parsed value, it can be surrounded by quotes, for example passing "false" in place of false.
Setting properties in a tool can be cumbersome. To simplify setting properties, import routines can use the applyProperties() method of Process Model Compiler Script to merge properties from an external source into the model generated from the tool's output. See Apply properties for a suitable field to hold these properties and details of the format.
Apply properties elaborates an imported model. It is different from setting properties on a model during model compilation, which only applies to top-level process properties. This is deliberate: all parameterisation of the process should be through the process-level properties.
Camunda Process Model imports process models from the Camunda process modelling tool.