1. Modeler Overview
The modeler dashboard can be accessed by authorized users through the dashboard menu and is used to create and deploy workflow models for use within edoras one.
Before we look at the details of the modeler dashboard it will help to understand how models are related to the user dashboard.
Models are created edited in the modeler dashboard, and as long as they are only edited they are not visible in the user dashboard. When models are deployed, corresponding definitions are created. These definitions can be used in the user dashboard to create work objects of the new type.
1.1. App Models
An edoras one App model contains a collection of different models that combine to define a specific workflow within edoras one.
An app model 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.
App models can be transferred between different edoras one installations using the Export and Import actions.
1.2. edoras vis
edoras vis is a modeler with focus on modeling BPMN 2.0-compliant processes, edoras one compliant forms and CMMN 1.0-compliant case models.
2. Model types
2.1. Form model
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
view or edited in the edoras vis modeler using the Design action. It is also possible to download
the XML form definition using the Download action.
2.2. Task model
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 Browse view. 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.
2.3. Document model
A document model is used to define a new type of document. As in the task model, the Browse view allows the
init and work forms to be selected, as well as setting the candidate groups and allowed actions. Moreover, the placeholders can
also be defined in this view.
2.3.1. Skeleton documents
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.
2.3.2. Placeholder expressions
Document models can define placeholder expressions that can be used to insert dynamic values into documents.
A placeholder definition consists of a key (which will be referenced from the document) and an expression that will be evaluated to give the corresponding value:
The expression will be applied at the time that the placeholders are updated, i.e. either when the document is first
created from the document model or when the Update placeholders action is used subsequently.
2.3.3. Referencing placeholders from a Microsoft Word document
In a Microsoft word document, placeholders may be referenced by inserting a form field into the document with a Bookmark name that corresponds to the placeholder key:
2.3.4. Referencing placeholders from an Adobe PDF document
In a PDF document, placeholders may be referenced by inserting a form field into the document with a name that corresponds to the placeholder key:
|
Note
|
A suitable PDF editing tool is required to create PDF documents with form fields. |
2.4. Process model
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 Design action, and the process definition XML can also be downloaded.
2.5. Case model
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. It is also possible to define which processes, tasks and documents can be created.
This behaviour is defined using the Browse view. This view allows the init and work forms to be selected, as well as setting
the candidate groups and allowed actions.
2.6. Mail model
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.
3. Working with models
3.1. Accessing the modeler dashboard
All users that are part of the modeler group will be able to access the modeler dashboard.
3.2. Importing App models
An App model 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.
3.3. Models state
Models have a state which changes as the models are edited and deployed. The available states are:
| State | Applies to | Description |
|---|---|---|
active |
Models |
No pending changes. The model is currently deployed on the system. |
inactive |
Models except App model |
No pending changes. The model has been deactivated on the system. |
pending |
Models |
The model contains changes that have not yet been deployed. |
pending inactive |
Models except App model |
The model will be deactivated on the system when it it next deployed. |
3.4. Deploying an App model
When an App model is deployed, the models within that App model 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 model. 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.
3.5. Moving models between App models
All of the basic model types can be moved to another App as long as there are no outstanding references within the App model that it is being moved from.
3.6. Duplicating App models
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.
3.7. Sharing models
Models 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.
3.8. The System App
The administrator will also be able to see the System app in the modeler dashboard in addition to the App models that can be seen by normal modeler users. This App model contains a number of models that are required by the edoras one application and should normally not be changed.
4. Actions
Certain models are used to create user work items (e.g. Case, Task, Document). When created, the work item action toolbar (on the right hand side) will contain the actions that can be performed on the work item.
Which actions are available to the user depends on a number of factors:
-
the actions allowed by the model itself
-
the state of the work item
-
the user’s permissions
Some constraints are defined by edoras one itself and cannot be changed, but the model plays a large role in defining the available actions, and this should be considered carefully when designing a workflow.
To change the allowed actions, select the Browse view and add or remove actions as required in the
Allowed Actions field:
| Action | Case | Task | Document | Description |
|---|---|---|---|---|
|
Yes |
Yes |
Yes |
Re-activate an archived work item |
|
Yes |
Yes |
Yes |
Archived and active work item |
|
Yes |
Yes |
Yes |
Change the work item’s owner / responsible |
|
Yes |
Yes |
Yes |
Allow new variables to be created in the work item admin view |
|
No |
No |
Yes |
Download the work item content |
|
No |
No |
Yes |
Download the document in pdf format |
|
No |
No |
Yes |
Edit the document |
|
No |
No |
Yes |
Move the work item to another case |
|
No |
Yes |
No |
Show a work item preview |
|
Yes |
Yes |
Yes |
Share the work item with specific groups |
|
Yes |
No |
No |
Start a new process instance |
|
No |
No |
Yes |
Upload a new document |
|
No |
No |
Yes |
Upload a new document |
5. Form palette
This section describes the elements available in the form palette of edoras one. Each modeling element and it’s corresponding attributes are described in detail below.
5.1. Concepts
This section describes the form concepts in edoras one. It starts with a description of how the layout of forms and fields works in edoras one. Then it describes how a form and its fields are bound to the data model.
5.1.1. Form layout
A form is a graphical layout of fields that may be bound to a data model to allow this data model to be displayed to the user. The fields are arranged in rows.
Each row is made up of exactly twelve slots. All slots are equal in size, so the width of a slot is one twelfth the width of the whole form. A field can occupy exactly all slots or it can occupy only a part of the slots. With this it is possible to place more than one field in a row.
Not every slot needs to be occupied by a field. It is allowed that single slots of a row are empty. These empty slots can be at the beginning, in the middle, or at the end of a row.
5.1.2. Field layout
A field is made up of several parts (all but the control part are optional):
- Control
-
The control visualizes the data model. Most controls are interactive and let the user change the data model, however some controls are read-only. There are controls to manipulate strings, numbers, dates, rich text, selections, and many others. The control is located in the center of the field, all other parts are arranged around the control. The field configuration defines the concrete positioning of the field parts.
- Label
-
The label tells the user to which part of the data model the control is bound. The label is located on the left side or on top of the control (depends on the field configuration).
- Required indicator
-
The required indicator is displayed for required fields. Required means that the control cannot be empty. The required indicator is located on the right side of the control.
- Description
-
The description gives additional information to the user. This can be formatting instructions or further description about how the App uses the entered value. The description is located on the bottom of the control.
5.1.3. Field alignment
To enhance the readability of a form, the field parts of all fields are aligned among themselves: the labels are aligned, the controls and descriptions are aligned, the required indicators are aligned.
The alignment is performed per slot. All fields that start in the same slot build a field group. Inside such a field group edoras one looks for the widest label which becomes the dominating label for that slot. All labels in the field group are then enlarged to the same width of the dominating label. This is done by adding empty space between the label and the control. This ensures that all controls and descriptions of a field group start in one line and all.
The only exception is with fields that have top label position. For these fields the label, the control and the description all start at the beginning of the slot.
5.1.4. Binding
Binding is the process to connect the form fields to the data model. The binding in edoras one is always two-way. When the user changes the form fields then those changes are immediately propagated to the data model. On the other side changes in the data model are immediately propagated back to the form fields.
A binding expression defines to which part of the data model the form field is connected. The binding expression has to be a writable frontend expression, e.g. {{foo}}, {{case.bar}}.
5.2. Common attributes
There are several attributes that are available for all form components. These common attributes define the rendering and the layout of the form field, as well as the part of the data model to which the form field is bound.
| Attribute name | Description |
|---|---|
Label |
The label is a single word or term that describes the purpose of the form component. When the form is rendered, the label is located either on the left side or on top of the control (depends on the value of the Label position attribute). Typical labels are: First name, Last name, Sex, Address, ZIP code, City. Labels can be localized. See Localization to learn how to localize your Apps. |
Label position |
The label position relative to the control, can be either Left or Top. |
Value |
The value connects the form field to the data model. As such the value decides which part of the data model the form field visualizes and which part of the data model is updated when the user interacts with the control. See Binding to learn how binding in edoras one works. |
Default value |
The default value is the value that is applied when the data model is undefined, i.e. not yet initialized. The default value can be expressed as a static value or as a frontend expression. Typical default values are: Support (= string), false (= boolean), 42 (= number), Comment from {{role}} (= frontend expression). See Frontend expressions to learn the frontend expression syntax. |
Description |
The description is a whole sentence that describes the purpose of the form component in more detail. When the form is rendered, the description is located below the control. A typical description is: The ZIP file format is ##, e.g 4143. The ZIP is used to lookup the city. Descriptions can be localized. See Localization to learn how to localize your Apps. |
Visible |
The visible flag decides if the form field is shown or hidden. If true, the form field is shown, if false the form field is hidden. The visible flag is a runtime value which means you can configure a frontend expression for it. A typical frontend expression for the visible flag is: {{case.showDeliveryAddress}} See Frontend expressions to learn the frontend expression syntax. |
Editable |
The editable flag decides i the form control is editable or read-only. If true, the user can manipulate the form control to change the data model, if false the user is not able to change the data model. The editable flag is a runtime value which means you can configure a frontend expression for it. A typical frontend expression for the editable flag is: {{case.step1Completed}} See Frontend expressions to learn the frontend expression syntax. |
Style class |
The style class allows to add additional CSS styles to the form field. See [styling] to learn how to add custom styles to your form. |
5.3. Validation attributes
A validation method checks if a control contains valid data, if not edoras one displays an error message that instructs the user how to fix his input. edoras one supports many different validation methods, not all are available for all form components.
|
Note
|
Validation is only done if the user is able to fix a potential validation error. This is not the case for hidden and read-only form fields, so such fields are not validated. |
The following table lists the supported validation methods.
| Attribute name | Description |
|---|---|
Required |
The required flag defines if a form field can be empty or not. If true then the form field is not allowed to be empty, if false the form field might be empty. A typical sample where the required flag is set to true is a name field that is mandatory. The following form components support the required flag: text, text area, rich text area, password, number, date, checkbox, autocomplete, select, radio buttons. |
Minimum length |
The minimum length validation ensures that the text input is longer than a minimum length. A typical sample is a password that has to be at least 4 characters long. The following form components support the minimum length validation: text, text area, rich text area, password. The Minimum length error message attribute holds the error message that is displayed when the text input is less than the configured number of characters. |
Maximum length |
The maximum length validation ensures that the text input has a smaller than a maximum length. A typical sample is a password that has to be at most 8 characters long. The following form components support the minimum length validation: text, text area, rich text area, password. The Maximum length error message attribute holds the error message that is displayed when the text input is bigger than the configured number of characters. |
Regular expression |
The regular expression validation ensures that the text input matches a regular expression. See http://www.w3schools.com/jsref/jsref_obj_regexp.asp for more information on the supported regular expression syntax. Regular expression can be become quite complex and difficult to understand. http://www.regular-expressions.info/javascriptexample.html provides a good way to test your regular expressions. A typical sample is the number of a credit card which matches: ^4[0-9]{11,12}(?:[0-9]{3})?$. The following form components support the regular expression validation: text, text area, rich text area, password. The Regular expression error message attribute holds the error message that is displayed when the text input does not match the regular expression. |
Mask |
The mask validation ensures that the text input adhere to a certain pattern. The mask can contain the following special characters: * a - Represents an alpha character (A-Z,a-z) * 9 - Represents a numeric character (0-9) * * - Represents an alphanumeric character (A-Z,a-z,0-9) * all other characters are treated as fixed input A typical sample is the expiry date of a credit card which is the month followed by a dash followed by the year. The mask that adheres to this pattern is 99/9999. The text form component supports mask validation. The Mask error message attribute holds the error message that is displayed when the text input does not match the mask. |
Minimum |
The minimum validation ensures that the number input is equals to or bigger than a minimum. A typical sample is an order quantity field which has to be equals to or bigger than 1. The number form component supports the minimum validation. The Minimum error message attribute holds the error message that is displayed when the number input is less than the configured minimum. |
Maximum |
The maximum validation ensures that the number input is equals to or less than a maximum. A typical sample is an order quantity field which has to be equals to or lower than 100. The number form component supports the minimum validation. The Maximum error message attribute holds the error message that is displayed when the number input is bigger than the configured maximum. |
Minimum date |
The minimum date validation ensures that the date input is equals to or after a minimum date. The minimum date can be a fixed date, today, or a day relative to today. A typical sample is an delivery date field which has to be equals to or after today. The date form component supports the minimum date validation. The Minimum date error message attribute holds the error message that is displayed when the date input is before the configured minimum date. |
Maximum date |
The maximum date validation ensures that the date input is equals to or before a maximum date. The maximum date can be a fixed date, today, or a day relative to today. A typical sample is a birthday field which has to be equals to or before today. The date form component supports the maximum date validation. The Maximum date error message attribute holds the error message that is displayed when the date input is after the configured maximum. |
Invalid selection error message |
The displayed error message when the selection input is not available anymore. The autocomplete and the select form components support the invalid selection validation. Both form component lookup the selection in the available options to check if the selection is valid or not. |
Minimum number of children |
The minimum number of children validation ensures that the subform input contains at least a certain number of children. A typical sample is an order subform which has to contain at least one order position. The subform form component supports the minimum number of children validation. The Minimum number of children error message attribute holds the error message that is displayed when the subform input contains less than the configured number of children. |
Maximum number of children |
The maximum number of children validation ensures that the subform input contains at most a certain number of children. A typical sample is a wish list which can hold at most ten wishes. The subform component supports the maximum number of children validation. The Maximum number of children error message attribute holds the error message that is displayed when the subform input contains more than the configured number of children. |
Minimum files |
The minimum files validation ensures that not less than a certain number of files are attached. A typical sample is a support incident attachment field where at lease one screenshot has to be attached. The attachment form component supports the minimum files validation. The Minimum files error message attribute holds the error message that is displayed when the attachment input has less files attached than the configured number. |
Maximum files |
The maximum files validation ensures that at not more than a certain number of files are attached. A typical sample is a favourite images attachment field where not more than ten images can be attached. The attachment component supports the maximum files validation. The Maximum files error message attribute holds the error message that is displayed when the attachment input has more files attached than the configured number. |
Minimum number of rows |
The minimum number of rows validation ensures that not less than a certain number of rows are displayed. A typical sample is a list which has always the same name of rows even they are empty. The list form component supports the minimum number of rows validation. |
Maximum number of rows |
The maximum number of rows validation ensures that at not more than a certain number of rows are displayed. A typical sample is a wish list which can hold at most ten wishes. The list form component supports the maximum number of rows validation. |
5.4. Text form components
The text form components allow the user to input text. To support different text input requirements edoras one provides different text form component variants. The following list explains the different text form component variants:
| Form component | Description |
|---|---|
|
Used to input a single line of regular text. 
|
|
Used to input multiple lines of regular text. 
|
|
Used to input multiple lines of rich text. In contrast to regular text, rich text can be formatted in various ways: regular, bold, italic, ordered list, unordered list, headings, and much more. 
|
|
Used to input a password. The password form component is marked with a small key icon at the right border of the control. To hide the typed text from curious people all typed characters are visualized as dots. 
|
|
Used to input a number. The number form component is marked with a small hash icon at the right border of the control. All non number input is treated as invalid. 
|
|
Used to input a date. The date form component is marked with a small calendar icon at the right border of the control. All non date input is treated as invalid. The user can enter a date in two ways. First he can enter the date as date string, e.g. 1970-11-25. Second he can use a date picker to select a date with the mouse. The date picker pops up as soon as the date control receives focus. 
|
5.4.1. Text attributes
| Attribute | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The text form component supports the required, the minimum length, the maximum length, the regular expression, and the mask validation. See [validation-attributes] to learn more about validation. |
5.4.2. Text area attributes
| Attribute | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The text area form component supports the required, the minimum length, and the maximum length validation. See [validation-attributes] to learn more about validation. |
5.4.3. Rich text area attributes
| Attribute | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Default value attribute of a Rich text area form component is rich text which supports the following formatting options (see toolbar buttons on top of the default value editor):
|
Validation |
The rich text area form component supports the required, the minimum length, and the maximum length validation. See [validation-attributes] to learn more about validation. |
5.4.4. Password attributes
| Attribute | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The password form component supports the required, the minimum length, and the maximum length validation. See [validation-attributes] to learn more about validation. |
5.4.5. Number attributes
| Attribute | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The number form component supports the required, the minimum, and the maximum validation. See [validation-attributes] to learn more about validation. |
5.4.6. Date attributes
| Attribute | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The default value of a date field form field can be specified as absolute date, as relative date, or as frontend expression. 
|
Validation |
The date form component supports the required, the minimum date, and the maximum date validation. See [validation-attributes] to learn more about validation. |
Format |
Used to define the format in which the date is visualized to the user. If empty then the date is presented in the ISO 8601 format, e.g. 1970-11-25. See [formatting-dates-in-frontend-expressions] to learn more about the possible format strings. |
Number of visible years |
Used to define the range of years displayed in the year drop-down. 
|
5.5. Select form components
The select form components allow the user to select one or more options from a potential large set of options. The available options are presented in a list from which the user can select one or more options with help of the keyboard and the mouse.
Some select form component support the filtering of the available options. When the user starts typing then only the options that match the typed text are presented as available options. This makes it easy to locate a specific option in a large set of options.
The select form components are very powerful form components. To support different selection requirements edoras one provides different variants of select form components. The following list explains these variants:
| Form component | Selection | Options | Description |
|---|---|---|---|
|
Single |
Boolean true/false |
Used to select a simple yes/no option. When the checkbox is ticked then true is stored in the data model, otherwise false is stored in the data model. 
|
|
Single |
Static options |
Used to select a single option from a static list of options. At design time the modeler configures for each option a name and a value. The name is displayed to the user whereas the value is stored in the data model. In the radio button form component all options are always visible. With this the user can always see all possible option, on the other side this uses a lot of form real estate and is therefore suited only it there are few options. 
|
|
Single or multiple |
JSON options |
Used to select one or more options from a dynamic list of options. The dynamic list of options is build at runtime by calling a custom REST endpoint that the modeler has configured. Either a single attribute of the option or the complete option is stored in the data model. 
|
|
Single or multiple |
edoras one work items |
Used to select one or more work items from a dynamic list of work items. The dynamic list of work items is build at runtime by calling edoras one with a query that the modeler has configured. Either the work item id or the complete work item is stored in the data model. |
|
Single or multiple |
Static options |
Used to select one or more options from a static list of options. At design time the modeler configures for each option a name and a value. The name is displayed to the user whereas the value is stored in the data model. |
|
Single |
Static options |
Used to select a single option from a static list of options. At design time the modeler configures for each option a name and a value. The name is displayed to the user whereas the value is stored in the data model. The select static form component is not able to filter the possible options. To select an option the user first has to navigate to the desired option by scrolling in the option list. Therefore this form component is not a good choice if there is a large number of options. |
|
Note
|
The functionality of the Radio button group, the Autocomplete static and the Select static form components is similar. The only difference is the look and feel. The Radio button group form component always shows all options with the drawback that this requires a lot of form real estate. The Autocomplete static and the Select static form components need little form real estate with the drawback that the user first has to focus the field and open a popup to see the available options. |
|
Note
|
the functionality of the REST autocomplete select and the Autocomplete select form components is similar. The only difference is that the REST autocomplete select form component uses a custom REST endpoint to load the possible options (which can be of any format) whereas the Autocomplete select form component uses edoras one to load the possible work items. |
5.5.1. Checkbox attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The checkbox form component supports the required validation. See [validation-attributes] to learn more about validation. |
5.5.2. Radio button group attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The radio button group form component supports the required validation. See [validation-attributes] to learn more about validation. |
Options |
Defines the options from which the user can choose. Each option has a name and a value: the name is shown to the user whereas the value is stored in the data model. 
|
Orientation |
Defines if the single radio buttons in the group are Horizontal or Vertical aligned. 
|
5.5.3. REST autocomplete select attributes
| Attribute name | Description | ||
|---|---|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
||
Validation |
The REST autocomplete select form component supports the required and the invalid selection validation. See [validation-attributes] to learn more about validation. |
||
Query URL |
Used to load the available options that are presented to the user from a URL. The query URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. The autocomplete form component expects the options to be returned as list of JSON objects, e.g. [ {
"id" : "GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f",
"title" : "edoras one Modeler",
"value" : "GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f"
}, {
"id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
"title" : "edoras one User",
"value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
} ]
The user typed text is added as a URL parameter to the query URL. https://one.edorasware.com/rest/one-groups?typedText=edoras Usually the REST endpoint uses the typed text to filter the available options. This way the user sees only the options that match the already typed text and can easily locate single options in a large set of options.
|
||
Lookup URL |
Used for two things:
In both cases the serialized option is appended to the lookup URL, e.g. https://one.edorasware.com/rest/one-groups/GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f The option is serialized with help of the Serialization. So the Lookup URL and the Serialization attribute have to play together. |
||
Serialization |
Used to select the attribute in the JSON option that is stored in the data model. The prefix to select an attribute from the JSON option is item. So if the JSON option looks like {
"id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
"title" : "edoras one User",
"value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}
then a Serialization of item.id results in GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac being stored in the data model.
|
||
Format |
Used to compose a user friendly string from the JSON option. The prefix to select an attribute from the JSON option is item. Literals have to be enclosed in quotes, attributes and literals can be concatenated with +. So if the JSON option looks like {
"id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
"title" : "edoras one User",
"value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}
then a format of 'Group: ' + item.title results in Group: edoras one User being presented to the user for this JSON option. |
||
Navigation URL |
Used to set a link icon to the left of each option in the list and each selected option. The Navigation URL defines the URL to navigate to when the user clicks a link icon. The navigation URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. The prefix to select an attribute from the JSON option is $item. So if the JSON option looks like {
"id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
"title" : "edoras one User",
"value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}
then a navigation URL of /GRP/{{$item.id}}/browse results in /GRP/GEAR-3456061f-4892-4ef4-b234-69217201cd09/browse being invoked when the user clicks the link icon. 
|
||
Target |
Used to define the tab where the linked option is loaded. Possible values are:
|
||
Multi selection |
False if only one option can be selected, true if multiple options can be selected. If true then the selected options are stored as a list in the data model. 
|
5.5.4. Autocomplete select attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The autocomplete select form component supports the required and the invalid selection validation. See [validation-attributes] to learn more about validation. |
Query |
The edoras one query that is used to load the available work items that are presented to the user. The user typed text is added as additional filter to the configured query. Typical queries:
See section Searches in the User guide to learn more about the search syntax and about all possible search terms. |
Format |
Used to compose a user friendly string from the work item. The prefix to select an variable from the work item item. Literals have to be enclosed in quotes, attributes and literals can be concatenated with +. So if the format is 'Group: ' + item.name then the work item is shown to the user as Group: edoras one User. |
Navigation view |
Used to set the target view for the link. Possible values are:
|
Target |
Used to define the tab where the linked work item is loaded. Possible values are:
|
Multi selection |
False if only one option can be selected, true if multiple options can be selected. If true then the selected options are stored as a list in the data model.
|
5.5.5. Static autocomplete select attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The static autocomplete select form component supports the required and the invalid selection validation. See [validation-attributes] to learn more about validation. |
Options |
Defines the options from which the user can choose. Each option has a name and a value: the name is shown to the user whereas the value is stored in the data model.
|
Navigation URL |
Used to set a link icon to the left of each option in the list and each selected option. The Navigation URL defines the URL to navigate to when the user clicks a link icon. The navigation URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. The prefix to select an attribute from the option is $item. The following two option attributes are available:
So if the navigation URL is https://www.google.ch/search?q={{$item.value}} then the link URL results in https://www.google.ch/search?q=edorasware.
|
Multi selection |
False if only one option can be selected, true if multiple options can be selected. If true then the selected options are stored as a list in the data model.
|
5.5.6. Static select attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The static select form component supports the required and the invalid selection validation. See [validation-attributes] to learn more about validation. |
Options |
Defines the options from which the user can choose. Each option has a name and a value: the name is shown to the user whereas the value is stored in the data model.
|
5.6. Read only form components
The read only form components allow to present information, to add navigation functionality, and to split a form into section.
| Form component | Description |
|---|---|
|
Used to show static rich text. The rich text can be formatted in various ways: regular, bold, italic, ordered list, unordered list, headings, and much more. 
|
|
Used to show a list of options that are returned by a custom REST endpoint. The dynamic list of options is build at runtime by calling a custom REST endpoint that the modeler has configured. The rest list form component can be used to enable simple navigation inside your App. For this the modeler can configure the links that are followed when the user clicks one of the options in the list. 
|
|
Used to show a list of work items that are returned by edoras one. The dynamic list of work items is build at runtime by calling calling edoras one with a query that the modeler has configured. The rest list form component can be used to enable simple navigation inside your App. For this the modeler can configure the links that are followed when the user clicks one of the options in the list. |
|
Used to show an image. 
|
|
Used to show a generic link. 
|
|
Used to show a link that points to a configurable REST query. The link text can be configured to show the number of elements returned by the REST query. Clicking the link navigates to the result of the REST query. 
|
|
Used to show a link that points to a configurable query. The link text can be configured to show the number of elements returned by the query. Clicking the link navigates to the result of the query. |
|
Used to show a button that points to a generic URL. 
|
|
Used to show a button that points to a configurable query. The button text can be configured to show the number of elements returned by the query. Clicking the button navigates to the result of the query. |
|
Used to show a horizontal line. The Horizontal line form component is useful to structure large forms by splitting the form into sections, e.g. basic information, detail information, address, … 
|
|
Note
|
the functionality of the REST list and the List form components is similar. The only difference is that the REST list form component uses a custom REST endpoint to load the displayed items (which can be of any format) whereas the List form component uses edoras one to load the displayed work items. |
|
Note
|
the functionality of the REST query link and the Query link form component is similar. The only difference is that the REST query link form component uses a custom REST endpoint to load the number of found elements whereas the Query link form component uses edoras one to load the number of found elements. |
|
Note
|
the functionality of the Link and the Link button as well as the Query link and the Query link button is similar. The only difference is that the Link and the Query link form components are rendered as links whereas the Link button and the Query link button form components are rendered as buttons. |
5.6.1. Output text area attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Output text area form component does not support the Default value and the Editable attribute, as these do not make sense for read only components. The Value attribute of a Output text area form component is rich text which supports the following formatting options (see toolbar buttons in the image below): bold, italic, and underline text style, font size, foreground and background color, left, center, and right text alignment, headline, sub-headline, and section headline style, ordered and unordered list, text indentation, horizontal line, links. 
|
5.6.2. REST list attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The REST list form component does not support the Value, the Default value and the Editable attribute, as these do not make sense for read only components. |
Query URL |
Used to load the items that are presented to the user from a URL. The query URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. The list form component expects the items to be returned as list of JSON objects, e.g. ----
[ {
"id" : "GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f",
"title" : "edoras one Modeler",
"value" : "GEAR-a65c4a12-20b4-45d8-bb09-2105be7f0d1f"
}, {
"id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
"title" : "edoras one User",
"value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
} ]
----
|
List title |
Used to define the title that is shown in the header of the list. The list title attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
Format |
Used to compose a user friendly string from the JSON item. The prefix to select an attribute from the JSON item is item. Literals have to be enclosed in quotes, attributes and literals can be concatenated with +. So if the JSON item looks like {
"id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
"title" : "edoras one User",
"value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}
then a format of 'Group: ' + item.title results in Group: edoras one User being presented to the user for this JSON item. |
Minimum number of visible items |
Used to define the minimum height of the list. The list height is forced to a height that can show at least a certain number of items. If the concrete list has less items then the missing space is filled with empty items. For example if there are 5 items to show and the minimum height is 10 then the list height is forced to a height that can show 10 items. 
|
Maximum number of visible items |
Used to define the maximum height of the list. The list height is forced to a height that can show at most a certain number of items. If the concrete list has more items then the list shows a scroll with which the user can scroll in the list. For example if there are 15 items to show and the minimum height is 10 then the list height is forced to a height that can show 10 items.
|
Navigation URL |
Used to define the URL to navigate to when the user clicks an item in the list. The navigation URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. The prefix to select an attribute from the JSON option is $item. So if the JSON item looks like {
"id" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac",
"title" : "edoras one User",
"value" : "GEAR-c641f3bb-876e-45f4-9550-ef95ef5a2fac"
}
then a navigation URL of /GRP/{{$item.id}}/browse results in /GRP/GEAR-3456061f-4892-4ef4-b234-69217201cd09/browse being invoked when the user clicks the item in the list. |
Target |
Used to define the tab where the linked item is loaded. Possible values are:
|
5.6.3. List attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The List form component does not support the Value, the Default value and the Editable attribute, as these do not make sense for read only components. |
Query |
The edoras one query that is used to load the work items for the list. Typical queries:
See section Searches in the User guide to learn more about the search syntax and about all possible search terms. |
List title |
Used to define the title that is shown in the header of the list. The list title attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
Format |
Used to compose a user friendly string from the work item. The prefix to select an variable from the work item item. Literals have to be enclosed in quotes, attributes and literals can be concatenated with +. So if the format is 'Group: ' + item.name then the work item is shown to the user as Group: edoras one User. |
Minimum number of visible items |
Used to define the minimum height of the list. The list height is forced to a height that can show at least a certain number of items. If the concrete list has less items then the missing space is filled with empty items. For example if there are 5 items to show and the minimum height is 10 then the list height is forced to a height that can show 10 items.
|
Maximum number of visible items |
Used to define the maximum height of the list. The list height is forced to a height that can show at most a certain number of items. If the concrete list has more items then the list shows a scroll with which the user can scroll in the list. For example if there are 15 items to show and the minimum height is 10 then the list height is forced to a height that can show 10 items.
|
Navigation view |
Used to set the target view for the link. Possible values are:
|
Target |
Used to define the tab where the linked work item is loaded. Possible values are:
|
5.6.4. Image attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Image form component does not support the Value, Default value and the Editable attribute, as these do not make sense for read only components. |
Source URL |
Used to define the URL from which the image is loaded. The source URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. This can be an absolute URL like http://www.activiti.org/images/edorasware_logo.png or a relative URL that points to the content of a document work item, for example rest/workobjects/GEAR-faded1c0-a147-4fb1-9875-e13b185b0abe/content. |
Maximum height |
Used to define the maximum height of the image. If set then the height of the Image form component is forced to that height, which means the contained image is scaled down to that height. If not set then the height of the Image form component is equals to the height of the contained image. |
Refresh time (seconds) |
Used to define a refresh internal in seconds. The image is reloaded every x seconds, where x is the defined refresh time. This is useful if the Source URL attribute point to a dynamic image that can change over time. |
Navigation URL |
Used to define the URL to navigate to when the user clicks the image. The navigation URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
Target |
Used to define the tab where the linked item is loaded. Possible values are:
|
5.6.5. Link attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Link form component does not support the Default value and the Editable attribute, as these do not make sense for read only components. The Value attribute is used to define the link text. |
Navigation URL |
Used to define the URL to navigate to when the user clicks the link. The navigation URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
Target |
Used to define the tab where the linked item is loaded. Possible values are:
|
5.6.6. REST query link attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Link form component does not support the Default value and the Editable attribute, as these do not make sense for read only components. The Value attribute is used to define the link text. The value attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. The value attribute supports the special $count frontend expression which represents the result count of the REST query. The value attribute as well supports different texts for singular and plural depending on the result count. The syntax for this is [singular text|plural text]. So a value of $count user [|s] results in 1 user or 21 users depending on the result count. |
Count URL |
Used to define the URL that returns the result count of the REST query. The count URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
Navigation URL |
Used to define the URL to navigate to when the user clicks the link. The navigation URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
Target |
Used to define the tab where the linked item is loaded. Possible values are:
|
5.6.7. Query link attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Link form component does not support the Default value and the Editable attribute, as these do not make sense for read only components. The Value attribute is used to define the link text. The value attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. The value attribute supports the special $count frontend expression which represents the result count of the REST query. The value attribute as well supports different texts for singular and plural depending on the result counts. The syntax for this is [singular text|plural text]. So a value of $count user [|s] results in 1 user or 21 users depending on the result count. |
Query |
The edoras one query that is used to load the work items for the list. Typical queries:
See section Searches in the User guide to learn more about the search syntax and about all possible search terms. |
Target |
Used to define the tab where the linked item is loaded. Possible values are:
|
5.6.8. Link button attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Link form component does not support the Default value and the Editable attribute, as these do not make sense for read only components. The Value attribute is used to define the button text. |
Navigation URL |
Used to define the URL to navigate to when the user clicks the button. The navigation URL attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
Target |
Used to define the tab where the linked item is loaded. Possible values are:
|
Tooltip |
Used to define the tooltip for the button. The tooltip attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
5.6.9. Query link button attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Link form component does not support the Default value and the Editable attribute, as these do not make sense for read only components. The Value attribute is used to define the button text. The value attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
Query |
The edoras one query that is used to load the work items for the list. Typical queries:
See section Searches in the User guide to learn more about the search syntax and about all possible search terms. |
Target |
Used to define the tab where the linked item is loaded. Possible values are:
|
Tooltip |
Used to define the tooltip for the button. The tooltip attribute can be expressed as a static value or as a frontend expression. See [frontend-expressions] to learn the frontend expression syntax. |
5.6.10. Horizontal line attributes
| Attribute name | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Label attribute is used to define the title that is displayed inside the horizontal line. The Horizontal line form component does not support the Default value and the Editable attribute, as these do not make sense for read only components. |
5.7. Nesting form components
The nesting form components allow to nest components.
The data model of a nested form is usually stored in a nested data context. If configured that way the forms and the data model nest in a corresponding way: A field in a nested form then becomes a attribute in the nested data context.
Nested forms can be repeated. This way it is possible to define lists in the data model.
Usually nested forms are rendered in a way that the user can clearly see that the form fields belong to a nested form. But if desired nested forms can be rendered in a transparent way. The user can then not tell if a field comes from the main form or from a nested form.
| Form component | Description |
|---|---|
|
Used to nest forms of a single type. 
|
|
Used to nest forms of mutiple types. 
|
5.7.1. Single-type subform attributes
| Attribute | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Value attribute is used to define the nested data context. This means if the Value is set to foo then all data inside the subform is stored in the foo attribute of the data model. The Single-type subform form component does not support the Label position, the Default value, and the Description attribute, as these do not make sense for nesting components. |
Validation |
The single-type subform form component supports the minimum number of children and the maximum number of children validation. See [validation-attributes] to learn more about validation. |
Form reference |
Used to define the form that is rendered in place of the subform. The editor for this attribute allows to pick an existing form or to create a new one. 
|
Is dynamic |
Used to define if the user can repeat the form or not. If true, additional buttons are rendered to let the user add new forms and remove existing ones. 
|
Entity display name |
Used to define the text for the add button. |
Show as child entity |
Used to define if the form inside the subform form component is rendered nested or not. If true the form is rendered in a nested way and the user can clearly see that this is a nested form. If false the form is rendered in a transparent way and the user cannot distinguish if a field comes form the main form or from the nested form. 
|
5.7.2. Multi-type subform attributes
| Attribute | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. The Value attribute is used to define the nested data context. This means if the Value is set to foo then all data inside the subform is stored in the foo attribute of the data model. The Multi-type subform form component does not support the Label position, the Default value, and the Description attribute, as these do not make sense for nesting components. |
Validation |
The multi-type subform form component supports the minimum number of children and the maximum number of children validation. See [validation-attributes] to learn more about validation. |
Discriminator |
Used to define the discriminator attribute inside the sub data context. The value stored in the discriminator attribute decides which form is used to display the data in the sub data context. |
Form references |
Used to define the forms that are rendered in place of the subform. The editor to define the form references asks for pairs of discriminator value and form references. The discriminator value identifies the form reference and hence the form to be used inside the data model. 
|
Is dynamic |
Used to define if the user can repeat the forms or not. If true, additional buttons are rendered to let the user add new forms and remove existing ones. |
Entity display names |
Used to define the texts for the add button. The editor to define the entity display names asks for pairs of discriminator value and display names. The discriminator value identifies the entity name to be used in the add button. 
|
Show as child entity |
Used to define if the form inside the subform form component is rendered nested or not. If true the form is rendered in a nested way and the user can clearly see that this is a nested form. If false the form is rendered in a transparent way and the user cannot distinguish if a field comes form the main form or from the nested form.
|
5.8. Attachment form component
The attachment form component allows to attach files.
| Attribute | Description |
|---|---|
Common |
See [common-attributes] to learn more about the common attributes. |
Validation |
The attachment form component supports the minimum files and the maximum files validation. See [validation-attributes] to learn more about validation. |
Preview type |
Used to define the preview type. The following values are allowed:
|
Thumbnail maximum height |
Used to define the maximum height of the thumbnail. This attribute is only available when the preview type is Thumbnail. |
Select file message |
Used to define the message that is shown to the user inside the attachment form component. By default the attachment form component shows Please select file to the user. |
6. Process Palette
This section describes the elements available in the process modelling palette of edoras one. Each modeling element and it’s corresponding attributes are described in detail below. Since edoras one is based on BPMN 2.0 huge parts of the modelling capabilities come from there. Currently, edoras one does not support the full BPMN 2.0 standard for execution. The process palette contains only the BPMN2.0 elements that are currently supported by the engine. Besides the BPMN 2.0 standard elements, edoras one provides some dedicated process activities that can be used within the processes. These edoras one specific activities are dedicated implementations of BPMN 2.0s generic service task. They are implemented using the custom extensions hook of BPMN 2.0 so if you import a process model to another system that supports BPMN 2.0 these activities are considered as generic service tasks.
There are several attributes, that are available for all modelling elements:
| Attribute Name | Description |
|---|---|
Name |
The name of the element, displayed on the diagram. This attribute is not equal to the id of the element. |
Documentation |
Use this attribute to add any documentation / description to the element. The content of the element can not be displayed on the model graphics, but is exported to the BPMN 2.0 XML. |
Custom Properties |
Define arbitrary properties as key value pairs. The attribute is exported to the BPMN 2.0 XML and can be accessed at runtime. |
Background Color |
Specify the background color of the element in the diagram. |
6.1. Start Event
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.
| Attribute Name | Attribute Type |
|---|---|
Description |
none |
Any sub-process has always to start with a none start event.
6.2. Message 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:
-
The name of the message start event must be unique across a given process definition. A process definition must not have multiple message start events with the same name. edoras one throws an exception upon deployment of a process definition such that two or more message start events reference the same message of if two or more message start events reference messages with the same message name.
-
The name of the message start event must be unique across all deployed process definitions. edoras one throws an exception upon deployment of a process definition such that one or more message start events reference a message with the same name as a message start event already deployed by a different process definition.
-
Process versioning: Upon deployment of a new version of a process definition, the message subscriptions of the previous version are cancelled. This is also true for message events that are not present in the new version.
| Attribute Name | Description |
|---|---|
none |
6.3. Error start event
An error start event can be used to trigger an Event Sub-Process. An error start event cannot be used for starting a process instance.
An error start event is always interrupting.
| Attribute Name | Description |
|---|---|
Error code |
The error code associated to the event. |
6.4. Timer start event
A timer start event is used to create process instance at given time. It can be used both for processes which should start only once and for processes that should start in specific time intervals.
|
Note
|
A subprocess cannot have a timer start event. |
|
Note
|
Start timer event is scheduled as soon as process is deployed. There is no need to to start an instance explicitly, although starting a process is not restricted and will cause one more starting of the process at the time invocation. |
|
Note
|
When a new version of a process with a start timer event is deployed, the job corresponding with the previous timer will be removed. The reasoning is that normally it is not wanted to keep automatically starting new process instances of this old version of the process. |
| Attribute Name | Description |
|---|---|
Timer properties |
Opens a dialog to specify when the timer should fire. |
6.5. Message intermediate catching event
Message Intermediate Catching Events are used to model wait state for particular message event with a specified name. After message catching process instance continues in its execution.
Message Intermediate Catching Event style rules: * By convention, message intermediate catching events are named after the event they are waiting for. (e.g. "Additional data received")
| Attribute Name | Description |
|---|---|
Message name |
The name of the message that the event is waiting for |
Operation name |
6.6. Timer intermediate catching event
Timer Intermediate Catching Events are used to model wait state driven by a time.
Timer Intermediate Catching Event style rules: * By convention, timer intermediate catching events are named after the event they are waiting for. (e.g. "Delivery deadline reached")
| Attribute Name | Description |
|---|---|
Timer properties |
A wizard to configure the timer |
6.7. End event
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.
| Attribute Name | Description |
|---|---|
none |
6.8. Error end event
When process execution arrives in an error end event, the current path of execution is ended and an error is thrown. This error can caught by a matching intermediate boundary error event. In case no matching boundary error event is found, an exception will be thrown.
| Attribute Name | Description |
|---|---|
Error code |
The error code associated to the event. |
6.9. User Task
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.
| Attribute Name | Description |
|---|---|
Categories |
attribute not recognized |
LoopType |
not yet supported |
Owner |
Set the owner of the task by selecting an existing user statically |
Owner (RT) |
Use a backend expression to evaluate the owner dynamically at runtime |
Assignee |
Set the assignee of the task by selecting an existing user statically |
Assignee (RT) |
Use a backend expression to evaluate the assignee dynamically at runtime |
Candidate Users |
Set the candidate users of the task by selecting existing users statically |
Candidate Users (RT) |
Use a backend expression to evaluate the candidate users dynamically at runtime |
Candidate Groups |
Set the candidate users of the task by selecting existing groups statically |
Candidate Groups (RT) |
Use a backend expression to evaluate the candidate groups dynamically at runtime |
Priority |
Set the priority of the task by using a literal or a backend expression. The priority is not currently not supported at runtime |
Due Date |
Set the due date of the task. The due date is currently not supported at runtime |
FormRef |
Select a form to be attached to the current task. You can also directly create a new form from here |
Mail Attributes |
Refer to Send Mail Service Task for the usage of these attributes. By using this attribute section, you cause the engine to additionally send an email when the task is created |
6.10. Manual 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.
| Attribute Name | Description |
|---|---|
none |
6.11. Create Case Service Task
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.
| Attribute Name | Description |
|---|---|
Case Model |
Select a case model for the new case to be created |
Init Variables |
Specify additional variables that should be initialized during the creation of the new case |
Case Name |
Set the name of the new case using literals or backend expressions |
CaseId Variable |
specify a variable name where the id of the newly created case should be stored in the current case. This is optional |
Categories |
attribute not recognized |
LoopType |
not yet supported |
6.12. Create case from subform service task
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.
| Attribute Name | Description |
|---|---|
Case Model |
Select a case model for the new case to be created |
Init Variables |
Specify additional variables that should be initialized during the creation of the new case |
Case Name |
Set the name of the new case using literals or backend expressions |
CaseId Variable |
specify a variable name where the id of the newly created case should be stored in the current case. This is optional |
Subform Variable |
Specify the variable name where the subform to create the new case from is bound to |
Remove Subform Variable |
If set to true, the variable of the subform will be removed from the data model after creating the case |
Categories |
attribute not recognized |
LoopType |
not yet supported |
6.13. Create document service task
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.
| Attribute Name | Description |
|---|---|
Document Model |
Select a document model for the new document to be created |
Document Id Variable |
specify a variable name where the id of the newly created document should be stored in the current case. This is optional |
Categories |
attribute not recognized |
LoopType |
not yet supported |
6.14. Send Mail Service Task
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.
|
Note
|
See section Mail Server in the Operators Guide for information on configuring the mail server in an on-premise environment |
| Attribute Name | Description |
|---|---|
Categories |
attribute not recognized |
LoopType |
not yet supported |
Mail Model |
This is a reference to a mail model in the current App. This model defines rich-text templates for the mail subject and body. Backend expressions in the mail model templates will be replaced when the mail is sent |
Mail Recipient |
The mail recipient is a required expression or literal that defines the email recipient (or multiple recipients) |
Mail Reply-To |
The mail reply-to is an optional expression that specify an explicit reply address. If no reply address is defined then the global system default will be used (which will vary from installation to installation) |
Mail CC |
Specify one or multiple CC recipients using literals or backend expressions. This attribute is optional |
Mail Bcc |
Specify one or multiple BCC recipients using literals or backend expressions. This attribute is optional |
Mail Priority |
An optional expression or literal that specifies the mail priority (usually an integer in the range 1 - 5) |
Mail Headers |
Specify additional mail headers. They will be applied before the message is sent |
6.15. Invoke REST endpoint service task
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.
| Attribute Name | Description |
|---|---|
Categories |
attribute not recognized |
LoopType |
not yet supported |
Protocol |
Specify the protocol to use for the request. HTTP and HTTPS are supported |
Request Type |
Specify the type of the HTTP Request. GET, POST, PUT and DELETE are supported |
Headers |
Add additional HTTP message headers to your request |
Request Body |
Specify the message body that will be sent with the request. You can use backend expressions to include data from the data model within your message body structure. This can only be used with POST and PUT requests |
Content Type |
Define the content type header to be set within the request. This value will be overwritten if you have set a content type in the Header attribute |
Host Name |
The host name of the remote server (e.g. service.edorasware.com |
Port Number |
The port number of the remote server. If not specified, 80 is used |
Request Path |
Specify the path to the endpoint on the remote server. The path must start with a leading / You can use backend expressions to set the path dynamically at runtime based on values from the data model |
Request Parameters |
Specify the parameters that are passed as part of the request URL. Multiple parameters can be defined using the editor provided |
Username |
If the remote server requires basic authentication specify the username of the user you want to use for the request |
Password |
If the remote server requires basic authentication specify the password of the user you want to use for the request |
Response Type |
Select the format of the response of the REST call. Currently JSON and XML are supported |
Set Variables |
Map the response data to your data model. specify the variable name and use X-Path expressions to select the respecting value from the response |
Overwrite if existing |
Set to true if you want to overwrite the values of existing variables with the values from the REST calls response |
6.15.1. JSON to XML mapping
The JSON to XML mapping used to prepare data for the XPath expression evaluation is mainly intuitive, but for completeness here is a quick summary of how different JSON content is mapped:
| JSON | XML | XPath example | Result |
|---|---|---|---|
|
|
//node |
value |
|
|
//node[2] |
value2 |
|
|
//child |
cValue |
|
|
/root |
single value |
|
|
/json/root[2] |
two |
|
Note
|
Note that in the case where multiple values are in the top-level JSON content, an additional root node ( |
6.16. Initialize variables service task
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.
| Attribute Name | Description |
|---|---|
Init Variables |
Specify variable name and target workitem of the variable you want to initialize using literals. Use literals or backend expressions to specify the value of the variable |
Overwirte if existing |
If set to true, the values of already defined variables will be overwritten. Otherwise, already initialized variables are skipped |
Categories |
attribute not recognized |
LoopType |
not yet supported |
6.17. Comment service task
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.
| Attribute Name | Description |
|---|---|
Comment Target Object |
Use an expression that resolves to the workitem where the comment should be added to the comment-stream |
Comment User |
Specify a the user in whos name the comment is created using an expression |
Comment Template |
Select the template for the comment |
Categories |
attribute not recognized |
LoopType |
not yet supported |
6.18. Sequence Flow
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.
|
Note
|
The above holds for BPMN 2.0 activities (and events), but not for gateways. Gateways will handle sequence flow with conditions in specific ways, depending on the gateway type. |
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.
| Attribute Name | Description |
|---|---|
Condition Type |
Specify the condition type of the message flow. standard an conditional flow behave the same, but are displayed differently. Use a backend expression in the Condidtion Expression Attribute to specify the condition. If you set the condition type to Default, this flow is executed when no other flow condition evaluates to true |
Condition Expression |
A backend expression that must evaluate to a boolean value |
6.19. Exclusive Gateway
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.
|
Note
|
Note that the semantics of outgoing sequence flow is different to that of the general case in BPMN 2.0. While in general all sequence flow which condition evaluates to true are selected to continue in a parallel way, only one sequence flow is selected when using the exclusive gateway. In case multiple sequence flow have a condition that evaluates to true, the first one defined in the XML (and only that one!) is selected for continuing the process. If no sequence flow can be selected, an exception will be thrown. |
| Attribute Name | Description |
|---|---|
none |
6.20. Inclusive gateway
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:
-
fork: all outgoing sequence flow conditions are evaluated and for the sequence flow conditions that evaluate to true the flows are followed in parallel, creating one concurrent execution for each sequence flow.
-
join: all concurrent executions arriving at the inclusive gateway wait in the gateway until an execution has arrived for each of the incoming sequence flows that have a process token. This is an important difference with the parallel gateway. So in other words, the inclusive gateway will only wait for the incoming sequence flows that will be executed. After the join, the process continues past the joining inclusive gateway.
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.
| Attribute Name | Description |
|---|---|
none |
6.21. Parallel gateway
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:
-
fork: all outgoing sequence flow are followed in parallel, creating one concurrent execution for each sequence flow.
-
join: all concurrent executions arriving at the parallel gateway wait in the gateway until an execution has arrived for each of the incoming sequence flow. Then the process continues past the joining gateway.
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.
|
Note
|
An important difference with other gateway types is that the parallel gateway does not evaluate conditions. If conditions are defined on the sequence flow connected with the parallel gateway, they are simply neglected. |
| Attribute Name | Description |
|---|---|
none |
6.22. Call activity (subprocess)
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.
| Attribute Name | Description |
|---|---|
Categories |
attribute not recognized |
SubProcessRef |
Select the subprocess to be called within the call activity |
LoopType |
not yet supported |
In |
Map input data to be passed from the parent (current) process to the subprocess while starting the subprocess |
Out |
Map output data to be passed form the subprocess to the parent process after the subprocess has finished |
6.23. Subprocess
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.
| Attribute Name | Description |
|---|---|
Categories |
attribute not recognized |
LoopType |
not yet supported |
6.24. Text Annotation
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.
| Attribute Name | Description |
|---|---|
none |
6.25. Association
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).
|
Note
|
edoras one currently only supports undirected associations |
| Attribute Name | Description |
|---|---|
none |
6.26. Pool
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.
| Attribute Name | Description |
|---|---|
isExecutable |
Indicates if this pool is executable. |
6.27. Collapsed pool
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.
| Attribute Name | Attribute Type |
|---|---|
Description |
none |
6.28. Lane
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.
| Attribute Name | Description |
|---|---|
none |
6.29. Message Flow
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.
| Attribute Name | Description |
|---|---|
none |
6.30. Multi Instance
edoras one supports the creation of multiple instances of several BPMN 2.0 elements (Human Task, Call Activity, Embedded Subprocess and all Activities in the section Service Tasks of the edoras one palette). Multi-instancy is configured within the process model.
To specify multi-instancy select the correspondig type parallel or seqential.
If you chose parallel, all instances of the element are created at once, when the execution arrives at the activity. If you choose sequential, the next instance of the activity ist created, when the previous activity was completed.
| Attribute Name | Description |
|---|---|
Loop collection |
A varialbe from the variable hierarchy that holds a list of elements. All elements of the list are processed, that means, the platform will generate one instance per list element |
Loop element variable |
a copy of the current list element. If you want to modify the variable, write the new value to the original list element since the loop element variable is not merged with the original one, once the execution is terminated. |
Loop element index variable |
The name of the variable where the current list index is stored. |
Anzahl Schleifen |
An expression that evaluates to an integer which determines the number of instances to be created if you do not use a list for iteration. |
Beendigungsbedingung |
A boolean expression do define a condition, to terminate the multi-instancy. As long as the expression evaluates to true, a new instance will be created. |
7. Customizing palettes
edoras vis supports customizing of palette that is available in the editor view for designing processes and forms. Using this feature one or more customized palettes of form/process/case components can be developed by extending available generic form/process/case components supported by edoras vis. Each custom palette can then be associated with one or more forms/processes. Once a custom platte is associated with a form/process/case all the components of the custom form/process/case palette will then be available in the editor view.
A custom form palette has to be configured in an XML file that has .form.palette.xml file extension and should conform to the edoras-vis-form-palette XML schema definition.
A custom process palette has to be configured in an XML file that has .process.palette.xml file extension and should conform to the edoras-vis-process-palette XML schema definition.
A custom case palette has to be configured in an XML file that has .case.palette.xml file extension and should conform to the edoras-vis-case-palette XML schema definition.
The edoras vis supports configuring a folder that can contain all the custom palette definitions to be used in a workspace. All the custom palette XMLs located directly under the configured folder will be available for associating with a form/process/case. One form/process/case can only be associated with one custom palette configuration.
In case a custom palette XML is deleted or if any of its custom components are deleted, the components in the forms/processes/cases already associated with that custom palette will automatically fallback to their respective generic component parent(s) when the forms/processes/cases are subsequently opened for editing.
7.1. Configuring a custom palette
| Name | Mandatory | Description |
|---|---|---|
id |
true |
Id of the palette. |
title |
false |
The title of custom palette that is displayed in edoras vis editor view. |
parent-palette |
false |
The parent palette from which a custom palette is extended. edoras vis supports following parent process palettes:
edoras vis supports following parent form palette:
|
hide-parent-palette-elements |
false |
The boolean value to hide stencils of the parent palette. Defaults to true. |
resource-bundle |
false |
Resource Bundle File containing language specific translations. All resource bundle file should be placed under i18n directory, i18n directory should be with in the same directory of palette. Check [defining-resource-keys-for-language-specific-attributes-in-custom-palette] for more details. |
7.2. Defining component groups in a custom palette
edoras vis supports grouping of components with in custom palettes.
| Name | Mandatory | Description |
|---|---|---|
id |
true |
Unique Id of the group |
title |
false |
Title of the group |
description |
false |
Description of the group |
index |
false |
Index of the group, Sorted in ascending order |
Sample group element is shown below.
<group id="Events" title="Events" description="Events description" index="5" >
<component id="events_start" extends="StartNoneEvent" attribute-groups="commonAttributes, formControlAttributes" ></component>
<component id="events_end" extends="EndNoneEvent" description="End Event">
<attribute id="custom_event_attribute" title="Custom Event Attribute" value="custom"/>
</component>
</group>7.3. Defining components in a custom palette
edoras vis supports creating of custom components in a custom palette by extending/referencing available generic components.
To add a component to the custom palette, a component element has to be added to the group element.
The component element in turn may contain one or more attribute elements which define the component specific properties.
| Name | Mandatory | Description |
|---|---|---|
id |
true |
Unique Id of the component |
title |
false |
Title of the component |
description |
false |
Description of the component |
visible |
false |
Configure visibility of the component in editor. |
extends |
false |
Id of the component that is extended |
ref |
false |
Id of the component that is referenced |
roles |
false |
Comma separated list of roles supported by the component, Which are inturn used by rules. See Defining rules in a custom palette for more details. |
attribute-groups |
false |
Comma separated list of attribute group id that need to be added to the component. See Defining attribute groups in a custom palette for more details. |
presentation-id |
false |
Presentation reference required to render the component SVG/Image on the editor canvas. See Defining custom component presentation in a custom palette for more details. |
default-lane-id |
false |
Applicable only for Pool type.Configure default lane Id for a pool. |
shortcut-menu-index |
false |
Applicable only for Process palette. Configure index for short cut menus from process components. |
index |
false |
Index of the Component, Sorted in ascending order |
behaviour-type |
false |
Applicable only for Form palette. Describes the behaviour of the referred component. |
1. Component extending StartNoneEvent with attribute-groups:
<component id="events_start" extends="StartNoneEvent" attribute-groups="commonAttributes, formControlAttributes" ></component>
2. Component extending Task with custom component-presentation and short cut menu index:
<component id="formtask" extends="Task" presentation-id="presentation.task" shortcut-menu-index="1" ></component>
3. Component referencing EndNoneEvent with a custom attribute and index:
<component id="events_end" description="End Event" ref="EndNoneEvent" index="5">
<attribute id="custom_event_attribute" title="Custom Event Attribute" value="custom"/>
</component>
4. Component behaving like a password component:
<component id="base-password" extends="component" presentation-id="password.presentation" behaviour-type="Password" />7.4. Defining custom categories in a custom palette
edoras vis supports defining of custom categories for attributes. These categories can be used to display the attributes of a component under different headings in the property window of the editor view.
| Name | Mandatory | Description |
|---|---|---|
id |
true |
Unique Id of the category |
title |
false |
Title of the category |
index |
false |
Index of the category. It decides the position of category in property window |
visible |
false |
Boolean value to hide the attributes category in property window |
Sample custom-categories element is shown below.
<custom-categories>
<category id="custom_category_1" index = "101" title="custom category 1(en)" />
<category id="custom_category_2" title="custom category 2(en)"/>
<category id="custom_category_3" title="custom category 3(en)" visible="false"/>
</custom-categories>Sample application of custom categories to attributes is shown below.
<attribute id="namekey" value="" type="SimpleText" category= "custom_category_1" />
<attribute id="name" title="Name" description="Name" value="" type="SimpleText" category="custom_category_2"/>
<attribute id="behavior" type="ComboBox" category= "custom_category_1" index="3" title="behavior">
<items>
<item id="none" title="none" value="none" />
<item id="all" title="all" value="all" />
<item id="one" title="one" value="one" />
<item id="complex" title="complex" value="complex" />
</items>
</attribute>7.5. Defining attributes in a custom palette
edoras vis supports defining custom attributes in the custom palette configuration.
To add an attribute with in custom palette, an attribute element has to be used. This element can only exist with in any of the following parent elements:
-
attribute-group
-
custom-attributes-group
-
model-attributes
-
component
| Name | Mandatory | Description |
|---|---|---|
id |
true |
Unique identifier of the attribute |
title |
false |
Title of the attribute |
description |
false |
Description of the attribute |
value |
false |
Value of the attribute |
type |
false |
Type of the attribute. Check Attribute types supported in a custom palette for more details. |
category |
false |
Name of the category under which the attribute should be displayed in the property window of editor view. |
export |
false |
Boolean value to specify whether an attribute should be exported to the xml and json(only for forms). |
index |
false |
Integer value to define position of the attribute in the property window of the editor view. |
ref-to-view |
false |
Id of the SVG element to which attribute value is mapped. Know more ref-to-view |
<