This chapter provides an alphabetized glossary for specialized expressions and terms that are employed in this book.
On the Axon.ivy Engine one or more Applications can exist. The Application defines the container wherein the Process Models can be deployed.
See also section Application.
A Case is one concrete instance of a Process. It must not necessarily run through all Steps of a Process. A Process may define a different handling for different Cases depending on the information of a Case. For example by using the Alternative Element.
A Case holds the information used to carry out the Process. This is on the one hand information about the Case like the current position in the Process. On the other hand this is information collected during the Case, which is passed from one Step to the next in the form of the Process Data
- Form Field
A Form Field is a JSF code snippet which serves content for a specific data class field type (e.g. a Label and a Datepicker for a Date). The New User Dialog Wizard create forms with Form Fields.
- Html Dialog
A Layout contains the main structure of a Html page (e.g. a header, content and footer section). For Web Pages the layouts are defined in the CMS. For Html Dialogs the layouts are defined in the webContent folder.
- Process Data
The Process Data is the data passed from one Step to the next. Its represented by a data class used for the whole process. Even though every Step can create a new instance of this data class to be passed to the next Step it will always be an instance of the same data class.
- Process Element
There are 3 groups of process elements.
Activities do something. Like running a script or let somebody else do something for example by showing a User Dialogs.
Events are notifications of things that happen outside the process.
The chapter Process Elements Reference describes all the Process Elements available.
- Process Model
A Process Model on the Engine corresponds to an Axon.ivy project on the Designer. The difference is that a Process Model may hold multiple different versions of the same Axon.ivy project. These are called Process Model Version.
See also section Process Model in chapter Deployment.
- Process Model Version
A Process Model can have multiple versions called Process Model Versions. These versions allow to change an Axon.ivy project without worrying about the compatibility of currently running Cases on the Engine.
See also section Process Model Version in chapter Deployment.
A User has one or multiple Roles which define what the user is allowed to do.
In computer programming, especially object-oriented programming, a method is commonly identified by its unique method signature. This usually includes the method name, and the number, types and order of its parameters, but usually excludes the return type(s) of the method.
Within Axon.ivy, signatures act as unique identifiers for specific start elements (e.g. method starts, request starts, trigger starts, call sub starts), within the same process, only one element with the same signature may exist. The same holds true for signatures of start methods and events on a User Dialog interface.
A Task is a unit of work which is indivisible. It has to be carried out by one user in one piece. If anything goes wrong during the execution of a task, we must return to the beginning of the task.
It’s not possible to work on a Case without a Task. Every time a new Case is started a Task will be created. While working on a Case / Task new Tasks can be created. This allows to interrupt the work on a Case and to hand it over to another user if necessary.
Task can be assigned to a specific User, a Role or to Everybody.
A User is a person interacting with a Case. The user is identified by a unique user name.
If a User is not identified, we speak of an anonymous User.
- User Dialog
A User Dialogs is a concept of an User Interface. User Dialogs can be implemented as Html Dialog (HTML/JSF).
- View Type
A View Type defines the default content of a User Dialogs View. Axon.ivy has predefined View Types, i.e. Page and Component.