Introduction
A task refers to a single unit of work to be performed in a process.
The following tasks are supported:
- Send task
- Script task
- Service task
Send task properties
A send task sends a notification to one or more users at a specific point in the process.
The send task is represented as a rectangle with rounded corners with a small notification icon at the corner:
A send task has the following properties:
| Property | Description |
|---|---|
| Name | The name of the task. |
| Id | A unique identifier of the task generated by the system. An ID cannot be modified. |
| Input | The object from the previous element's object. |
| Notification Template | The user who is sent a notification. |
| Notification Priority | The priority that determines the channel (email) to deliver notifications. |
Script task properties
A script task is used to run a script in the process. A script can be agent-based or agentless via the Ansible control node. Agent-based scripts can be created in the following languages:
- POWERSHELL
- Python
- SHELL
The script task is represented with a rectangle with rounded corners and a script icon:
To run an agentless script, integrate Ansible must be integrated with the system.
To configure Ansible integration:
- From All Clients, select the client.
- Go to Setup > Integrations> Integrations.
- From Available Integrations > Configuration Automation > Ansible Integration, click Install.
- Enter a name for the integration and select the controller host name.
- Click Install.
A script task has the following properties:
| Property | Description |
|---|---|
| Name | The name of the task. |
| Id | A unique identifier of the task generated by the system. An ID cannot be modified. |
| Configuration |
|
| Script Name (applicable for an agent) | The script name to execute. |
| Resource Id (applicable for agent) | The resource ID used to execute the script. |
| Run As (applicable for agent) | The execution of the script with proper authorization.
|
| Integration (applicable for agentless) | A created Ansible integration name. |
| Playbook (applicable for agentless) | A Playbook created as part of the integration. |
| Input (applicable for agentless) | Commands for executing the script. |
| Preview (applicable for agentless) | The fully-qualified path entered in a selected playbook. |
Service task properties
A service task is used to perform a service. The service can either be a service provided by OpsRamp or an external service. The service task is represented as a rectangle with rounded corners with a settings icon:
Service tasks have the following properties:
| Property | Description |
|---|---|
| Name | The name of the task. |
| Id | A unique identifier for the task generated by the system. An ID cannot be modified. |
| Service | The mode of service for completing a task:
|
REST web services
REST web services have the following properties:
| Property | Description |
|---|---|
| Asynchronous Service Invocation | An asynchronous service invocation follows the Request, Acknowledge, and Callback pattern. Once invoked, the process is blocked for this task until the REST application performs a callback. |
| Integration | The integration of external web service API endpoints that are configured. |
| Event | An integration event. |
| Input | The input for the service task that can be an output of the previously configured elements (like the start event). Example: $startevent.alert or $updatealert.alert. |
| Output | The mappings of response fields configured for the selected event. |
This is an example of the REST web services properties dialog box:
Service Task Properties - REST Web Service
Platform services
The platform services have the following properties:
| Property | Description |
|---|---|
| Task | Refers to one of the OpsRamp’s native services. The sub-fields vary for each task that you select. For example, if Update Incident is selected, the Incident Unique Id needs to provided. Select Priority and Status. Enter the comments to add to the incident as part of the response. |
Note
Either static or dynamic values provided for the fields. If the Incident Unique Id is INC0000260733, then that incident is updated. However, if the incident ID is not known or the incident of an alert related to the start event needs to be updated, enter a dynamic value as$StartEvent_1vu43p8.alert.incident.This is an example of the platform service properties dialog box:
Service Task Properties - Platform Service
User task properties
A user task is a non-recurring work assigned to a user/user group for a certain stipulated time. Example: Clearing log files.
When a user task in the process definition is executed, a new service desk entity Task is created and appears in the task list of the assignee/assignee group.
A user task is represented as a rectangle with rounded corners user icon on the top-left corner:
Based on the types of properties, the user tasks are divided into the following categories:
- Static (predefined): Refers to the default properties in the platform.
- Dynamic (custom): Refers to the custom properties added by a user.
See Creating custom forms for more information.
Static properties of the user task:
| Property | Description |
|---|---|
| Name | The name of the task. |
| Id | A unique identifier of the task generated by the system. Note: The ID is in read-only mode. |
| Subject | Title or short summary of the user task. |
| Description | Information required to describe the user task. |
| Priority | Select one of the following options according to the urgency to execute a task. |
| Due Date | The estimated time duration for completion of the task. Provide a numeric value for the In field and select the time period from the drop-down. |
| Assignee Group | A user group that is responsible for working on the task. Multiple user groups can be selected. |
| Assigned To | A user(s) who is responsible for working on the task. Multiple users can be selected. |
Multi-instance loop
A multi-instance loop is a process of defining the repetition of a certain task in a process definition. The multi-instance allows the execution of a task sequentially.
A multi-instance is a regular task that has extra properties which cause the task to be executed multiple times/concurrently at runtime.
The following are the tasks that can become multi-instance loops:
- Send Task
- Service Task
- Script Task
- User Task
Note
A gateway or event cannot become a multi-instance loop.The following are the extra properties of multi-instance that are common for all the above tasks:
- Collection
- Element Variable
The multi-instance loop is indicated by three lines at the bottom of the task.
Sequential execution is indicated by three horizontal lines:
Multi-instance loop properties
The following are the properties of a multi-instance loop:
| Property | Description |
|---|---|
| Collection | A collection is an array of data (for example, list of resources) and refers to the name of a previous task that returns you a list. For each item in the collection, an instance of this task will be created. |
| Element Variable | Element variable is set for each record stored in a collection of data. The loop overwrites the element variable with each new record processed and is referenced by the Resource ID field. |