You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
Overview
The picture below gives an example of an adhoc action node in the process editor. In this case "SendReminderToCustomer" is an adhoc task that is required, has a precondition and can be performed more than once.
The table below explains the meaning of the icons within the node:
| Icon | Description |
|---|---|
| Represents a process task |
| Represents whether the node is ad hoc |
| The ad hoc task's precondition is either FALSE or Conditional |
| The ad hoc task requiredness is either TRUE or Conditional |
| The ad hoc task is repeatable |
Adhoc task
Is a process task which is used outside a sequential process. The availability of these tasks are based on pre conditions.
An adhoc Task:
Can have a precondition: a precondition is used to infer if a task must become active. An expression can be used to create the precondition. It is needed to model a precondition on each adhoc task (if there is no need for a precondition, use TRUE).
Can be required: an adhoc task can be made required by a condition which can be TRUE or an expression. If an adhoc task is required it must be finished before finishing a case (A case will not be finished when there is an open required task when reaching an end node). The pre-condition has a higher priority, so an adhoc task will only be required when the precondition is TRUE.
Can be made repeatable: an adhoc task can be made repeatable so the task can be executed more than one time within a case. After finishing this task a new instance of this task will be opened. Only one instance of each task type can be active (status open)
Can not be automated
Case locking can be applied: when case locking is TRUE, the case will be locked and all other tasks within the case can not be executed when this task is executed.
Can have privileges: privileges can be used to restrict users to perform tasks.
Has events: process events are used for the mapping of processes to an implementation flow.
At runtime, it is possible to trace task actions: Process Traceability.
Adhoc process
It is possible to include an adhoc sub-process in a process. This sub-process acts as a collection of process components, so a sub-process will be used to organize process drawing more clearly.
No new process instance will be generated for a sub process.
An adhoc process:
Can have a pre-condition: a pre-condition is used to infer if a task must become active. An expression can be used to create the pre-condition. It is needed to model a pre-condition on each adhoc task (if there is no need for a pre-condition, use TRUE).
Can be required: an adhoc task can be made required by a condition which can be TRUE or an expression. If an adhoc task is required it must be finished before finishing a case (A case will not be finished when there is an open required task when reaching an end node). The pre-condition has a higher priority, so an adhoc task will only be required when the pre-condition is TRUE.
Can be made repeatable: an adhoc task can be made repeatable so the task can be executed more than one time within a case. After finishing this task a new instance of this task will be opened. Only one instance of each task type can be active (status open)
An adhoc process functions equally as the the sub-process
When the pre-condition of an adhoc process becomes FALSE, the process and all its contents will be cleared before process flowing is evaluated. This will cause tasks that would lead to an exit node to not trigger that exit node.
Adhoc Message event
An adhoc message event functions as a start message within the context of a process/case. The adhoc message event node can be connected to these nodes: Task, Process, Split, conditional event, Message event, Timer event using a connector.
The adhoc message does not have an incoming sequence flow to start the node.
An Adhoc message event:
Name: Autogenerated ID for the node. It can be edited but must be unique within the process module to function.
Message Event: Using a dropdown the name of one of the available Message Events can be selected. This way the message event is connected to this node and will respond as modeled when this message event is received by the process engine. The corresponding fields which are available for the selected message event will appear on the screen.
Catching condition: A condition which can be inserted to assure that only the message node for which the condition is TRUE. The catching condition is modeled by selecting the name of one of the datafields available in the message. The condition will become TRUE if the value in the message equals the value in the profile of the case.
Field name: A list of names of the datafields which are available in the message. These name are modeled at the Message event.
Target attribute: The entity and attribute can be selected in which the data which is carried with the message event will be inserted in the profile. The process engine will retain this data in the process engine database.
Datatype: Information on type of data received in the message
Multivalued: Indicates if the data in the field can be multivalued.
Required: Indicates if the a value is required at filling the message. This field must be mapped to a target attribute.
Adhoc Conditional event
An adhoc conditional event functions as a start within the context of a process/case. The adhoc conditional event node can be connected to these nodes: Task, Process, Split, conditional event, Message event, Timer event using a connector.
The adhoc conditional event does not have an incoming sequence flow to start the node.
An Adhoc Conditional event:
Name: Autogenerated ID for the node. It can be edited but must be unique within the process module to function.
Condition: A condition which has to evaluate to a boolean value. If the Value is TRUE the event is caught and it will start flowing from that point. The profile of the process/case will be used for the evaluation. The node will be evaluated at each change of the profile of the process/case.
Adhoc Timer Event
An adhoc timer event functions as a start within the context of a process/case. The adhoc timer event node can be connected to these nodes: Task, Process, Split, conditional event, Message event, Timer event using a connector.
The adhoc timer event does not have an incoming sequence flow to start the node.
An Adhoc timer event
Name: Autogenerated ID for the node. It can be edited but must be unique within the process module to function.
Condition: A condition which has to evaluate to a Date or Date/Time value. If the Date is TRUE the event is caught and it will start flowing from that point. The profile of the process/case will be used for the evaluation. The node will be (re)evaluated at each change of the profile of the process/case. At evaluation a date or Date/time will be set and the event will start flowing when the moment arrives
- Repeatable: An Adhoc Timer event can be made repeatable, after evaluating the date or Date/time value to TRUE a new Date/DateTime will be set.
If the timer is repeatable and the expression results in a time stamp seconds or minutes from now, the timer will be caught multiple times simultaneously (the engine evaluates a timer either every minute or every hour, depending on the timer setting).
Overview
Content Tools