edoras one Modeler Guide

An edoras one App contains a collection of different models that combine to define a specific workflow within edoras one.

An app can be created and then different models can be added and linked together as required. When the workflow is ready, it can be deployed to create the corresponding definitions which are used to execute the workflow, and it can then be tested.

Apps can be transferred between different edoras one installations using the Export and Import actions.

A form model defines a form that can be used by other workflow models to interact with the user. Each form contains a number of form fields arranged in a given layout. The fields in a form may contain predefined content, or may be bound to work object values at runtime, for example to allow the name and description of a document to be displayed and perhaps changed.

Typically two types of forms are used: init forms are used to initialize new work objects, and work forms are used to edit existing work objects.

Form models can be quickly checked by hovering over the form name, previewed within edoras one using the Preview action or edited in the edoras vis modeler using the Edit in modeler action. It is also possible to download the XML form definition using the Download action.

A task model is used to define a new type of user task. The init and work forms for a task are used to create and edit the task contents, and are set using the Edit Model action. The default candidate groups used for sharing can also be set, and the actions that will be allowed on this type of task can also be selected.

A document model is used to define a new type of document. As in the task model, the Edit Model action allows the init and work forms to be selected, as well as setting the candidate groups and allowed actions.

In addition a skeleton document can be set using the Upload skeleton action. If a skeleton document is provided then whenever a new document of this type is created it will be initialized with its own copy of the skeleton document. Placeholders can also be defined to insert dynamic text into the document copy.

A process model allows a full BPMN 2.0 process execution model to be defined. As for form models a process model can be previewed or edited in the modeler using the Edit in modeler action, and the process definition XML can also be downloaded.

A case model is used define a new type of case. A case serves as a container for other work objects and can be used to store shared context information for a given workflow.

When a new case is created, it is possible to start processes, create tasks or create documents and link these to the case automatically. This behaviour is defined using the Edit Model action.

A mail model provides a template for mails that can be sent by a given workflow. The mail model contains the templates for mail subject and header, both of which can use edoras one backend expressions to fill in the template with dynamic information at the time that the mail is sent.

All users that are part of the modeler group will be able to access the modeler dashboard.

An App can be imported into the system by creating a new App through the user interface, and then using the Import action within the app to upload and import a Zip file containing the models to be imported.

When models are imported, the model will be checked to see whether it is already present on the system. If it is not present, then it will be created in the current App. If it is already present within the current App then it will be updated from the import file. If it is already present but as part of a different App then an error will be shown.

If a new model is created from scratch it is assigned an unchangeable ID which is used to track the model across all systems where the model is installed, and it is this ID which is used to establish the relationship between the models on the system and the models in the import file.

If the Import as duplicate option is selected when an App is imported the models in the imported App will not be checked against the models already present. New models will be created that are unconnected with the originals. This can be useful for creating a completely new App, using an existing App as a starting point.

Both models and Apps have a state which changes as the models are edited and deployed. The available states are:

When an App is deployed, the models within that App will be checked for consistency. If a model has been deactivated but there are still references from other active models then it will not be possible to deploy the App. If the models are consistent then they will be deployed and corresponding definitions will be created. The users of the system will then be able to access the new workflow in the user dashboard.

Note that work objects and processes may already exist that were created using older versions of the model. These will not automatically be updated to use the new definitions: they will continue to use the definitions that were valid when they were created and will therefore not behave any differently after the new deployment.

All of the basic model types can be moved to another App as long as there are no outstanding references within the App that it is being moved from.

All basic model types can also be duplicated, making an exact copy with a new name. This can be very useful when several small variations of a complex model are required.

Models and apps may also be shared with different groups. By default all new models are shared with the modeler group, but in some circumstances it may be required for particular users to work on a particular set of models.

The administrator will also be able to see the System app in the modeler dashboard in addition to the Apps that can be seen by normal modeler users. This App contains a number of models that are required by the edoras one application and should normally not be changed.

A none start event technically means that the trigger for starting the process instance is unspecified. This means that the engine cannot anticipate when the process instance must be started.

Any sub-process has always to start with a none start event.

A message start event can be used to start a process instance using a named message. This effectively allows us to select the right start event from a set of alternative start events using the message name.

When deploying a process definition with one or more message start events, the following considerations apply:

A none end event means that the result thrown when the event is reached is unspecified. As such, the engine will not do anything extra besides ending the current path of execution.

A user task is used to model work that needs to be done by a human actor. When the process execution arrives at such a user task, a new task is created in the task list of the user(s) or group(s) assigned to that task.

A Manual task defines a task that is external to the BPM engine. It is used to model work that is done by somebody, which the engine does not need to know of, nor is there a system or UI interface. For the engine, a manual task is handled as a pass-through activity, automatically continuing the process from the moment process execution arrives into it.

The Create Case Service Task can be used to create a new case from within a process. Input data for the new case can be mapped and the newly created case can be referenced form the current case if needed.

The create case from subform service Task is an itemization of the create case service task. Here you can specify a variable (subform) of the current workitem hierarchy as the input values for the new case instead of binding all input parameters manually.

edoras one allows to enhance business processes with document creation service tasks. The create document service task creates a copy of the specified document template insid the current case. In case the document template is either a MS Word or Adobe PDF form, form fields will automatically be populated with execution data. Refer to Document Placeholders for more information.

edoras one allows to enhance business processes with automatic mail service tasks that send e-mails to one or more recipients, including support for cc, bcc, mail templates, … etc.

The Invoke REST endpoint service task provides a generic client to call arbitrary REST endpoints. The task supports all HTTP operations, Basic Authentication, custom headers and different mime-types.

Use the initialize variables service task to initialize arbitrary variables in the current workitem hierarchy. You can use Expressions or literals to set the values of the variables.

Use the comment service task to add a comment to an arbitrary workitem reachable by the expression resolver. You can use templates similar to the ones in the send mail service Task to add formatted, structured comments.

A sequence flow is the connector between two elements of a process. After an element is visited during process execution, all outgoing sequence flow will be followed. This means that the default nature of BPMN 2.0 is to be parallel: two outgoing sequence flow will create two separate, parallel paths of execution.

A sequence flow can have a condition defined on it. When a BPMN 2.0 activity is left, the default behavior is to evaluate the conditions on the outgoing sequence flow. When a condition evaluates to true, that outgoing sequence flow is selected. When multiple sequence flow are selected that way, multiple executions will be generated and the process will be continued in a parallel way.

Currently conditionalExpressions can only be used with Backend Expressions, detailed info about these can be found in section Expressions. The expression used should resolve to a boolean value, otherwise an exception is thrown while evaluating the condition.

All BPMN 2.0 tasks and gateways can have a default sequence flow. This sequence flow is only selected as the outgoing sequence flow for that activity if and only if none of the other sequence flow could be selected. Conditions on a default sequence flow are always ignored.

An exclusive gateway (also called the XOR gateway or more technical the exclusive data-based gateway), is used to model a decision in the process. When the execution arrives at this gateway, all outgoing sequence flow are evaluated in the order in which they are defined. The sequence flow which condition evaluates to true (or which doesn’t have a condition set, conceptually having a true defined on the sequence flow) is selected for continuing the process.

The inclusive gateway can be seen as a combination of an exclusive and a parallel gateway. Like an exclusive gateway you can define conditions on outgoing sequence flows and the inclusive gateway will evaluate them. But the main difference is that the inclusive gateway can take more than one sequence flow, like the parallel gateway. The functionality of the inclusive gateway is based on the incoming and outgoing sequence flow:

Note that an inclusive gateway can have both fork and join behavior, if there are multiple incoming and outgoing sequence flow for the same inclusive gateway. In that case, the gateway will first join all incoming sequence flows that have a process token, before splitting into multiple concurrent paths of executions for the outgoing sequence flows that have a condition that evaluates to true.

Gateways can also be used to model concurrency in a process. The most straightforward gateway to introduce concurrency in a process model, is the Parallel Gateway, which allows to fork into multiple paths of execution or join multiple incoming paths of execution. The functionality of the parallel gateway is based on the incoming and outgoing sequence flow:

Note that a parallel gateway can have both fork and join behavior, if there are multiple incoming and outgoing sequence flow for the same parallel gateway. In that case, the gateway will first join all incoming sequence flow, before splitting into multiple concurrent paths of executions.

BPMN 2.0 makes a distinction between a regular subprocess, often also called embedded subprocess, and the call activity, which looks very similar. From a conceptual point of view, both will call a subprocess when process execution arrives at the activity.

The difference is that the call activity references a process that is external to the process definition, whereas the subprocess is embedded within the original process definition. The main use case for the call activity is to have a reusable process definition that can be called from multiple other process definitions.

When process execution arrives in the call activity, a new execution is created that is a sub-execution of the execution that arrives in the call activity. This sub-execution is then used to execute the subprocess, potentially creating parallel child execution as within a regular process. The super-execution waits until the subprocess is completely ended, and continues the original process afterwards.

BPMN 2.0 makes a distinction between a regular subprocess, often also called embedded subprocess, and the call activity, which looks very similar. From a conceptual point of view, both will call a subprocess when process execution arrives at the activity.

The difference is that the call activity references a process that is external to the process definition, whereas the subprocess is embedded within the original process definition. The main use case for the call activity is to have a reusable process definition that can be called from multiple other process definitions.

A subprocess is executed within the scope of the parent process.

The Text Annotation is for documentation purpose only, it’s not evaluated by the engine. Use it to add textual explanations to an element of the process model. In contrast to the Documentation property of an element, the text annotation is also visible on the graphical representation of the process model.

An association is represented with a dotted line. It is used to associate an artifact or text to a flow object, and can indicate some directionality using an open arrowhead (toward the artifact to represent a result, from the artifact to represent an input, and both to indicate it is read and updated). No directionality is used when the artifact or text is associated with a sequence or message flow (as that flow already shows the direction).

Represents the organizational boundaries of a process, typically separating different organisations. A pool contains one or more lanes (like a real swimming pool). One process has to be executed within a pool. If the end-to-end process includes multiple pools, each pool has it’s own process flow. Communication between pools is handled by Message Flows. The pool in edoras one represents the system boundaries of edoras one.

A collapsed pool hides internal detail from the viewer. It’s used to visulaize communication between the mail pool and an external system / organization that is not in the scope of the current project. The collapsed pool has no impact at execution time.

Used to organise and categorise activities within a pool according to function or role, and depicted as a rectangle stretching the width or height of the pool. A lane contains the flow objects, connecting objects and artifacts.

A Message Flow is represented with a dashed line, an open circle at the start, and an open arrowhead at the end. It tells us what messages flow across organizational boundaries (i.e., between pools). A message flow can never be used to connect activities or events within the same pool.

Expressions can also be executed on the server, for example within the process models. Server-side expressions are called backend expressions. A much wider range of expressions is possible than in frontend expressions the expressions may also have side-effects within the system (for example causing an e-mail to be sent). As well as accessing data from the work object hierarchy, backend expressions support additional functionality such as accessing work objects outside of the immediate hierarchy, predefined function calls and bean method calls.

There are two basic expression types: