The following tables describe and list the properties of the process definition objects.
Process Definition Events
Process definition includes the following event references.
Symbol | Name | Description | Properties |
---|---|---|---|
Generic Start Event | (default) Process initial state. |
| |
Timer Start Event | Process initial state. Transition to the next process step is triggered by a time event. |
| |
Signal Start Event | Process initial state. Transition to the next process step is triggered by an alert, incident, or resource signal event. |
| |
Timer Intermediate Catch Event | Puts the process on hold until the specified time or duration. Transition to the next process step is triggered with the elapse of time or duration. |
| |
Timer Boundary Event | Enables the task to complete within the specified duration. If the task is not completed within the duration, the process moves to the next step. |
| |
End Event | Process end state. |
|
Supported Task Types
You must define one of the following task types.
Symbol | Name | Description | Properties |
---|---|---|---|
Send Task | Sends an email notification to the specified users, user groups, or rosters. In the Message Recipient field, click Add/Modify to find the recipients. The recipient list is displayed based on the login authentication such as partner or client. |
| |
Script Task | Runs an agent-based script or agentless script using the Ansible control node. The agent-based task can be implemented using a Python, PowerShell, or shell script. See Ansible Integration to learn more about Agentless script tasks. |
| |
Service Task | Runs an external, REST API, local platform, and utility service. |
| |
User Task | A user task models work that requires human intervention. When the task runs, a new service desk entity task is created and is displayed in the assignee/assignee group task list. In the Assignee Group field, click Add/Modify to select the assignee group. In the Assignee field, click Add/Modify to select the assignee. The assignee/assignee group is displayed based on the login authentication such as partner or client. The workflow transitions out of the user task and to the next stage On receipt of a Closed or Resolved indication from the service desk entity. Any properties you define in Setup > Service Desk > Custom Forms are also displayed here as additional properties. |
|
Type of Services under Service Tasks
There are three types of services under Service Task.
- REST Web Service: Configure the REST API calls with integration setup.
- Platform Service: The platform service tasks are available for the service task.
- Utility Server: This service allows you to parse the server.
REST Web Service
The REST web service task calls an external API.
Option | Description |
---|---|
Name | Enter a name for the REST web service task. |
ID | The ID is populated automatically. |
Service | Select the REST Web Service task from the drop-down. |
Asynchronous Service Invocation (optional) | Select or deselect the toggle. An asynchronous service invocation follows the Request, Acknowledge, and Callback pattern. Once invoked, the process is put on hold on this task until the REST application calls back. |
Integration | Select - Choose a custom integration from a list of previously created integrations. Only the selected custom integration is triggered during the process workflow. To create a custom integration for Process Automation, see the How to Set up a Process Automation Integration section. |
Event | Select - Choose a custom event from a list of previously created events. Only the selected custom event integration is triggered during the process workflow.To create a custom event for Process Automation, see the Configuring the integration section. |
Input | Enter the input. To provide multiple inputs for different tasks, enter the multiple inputs separated by commas. For example, $StartEvent_1bedsev.alert, $Create_SR, $Create_INC Note: The input value provided must be the same as the option selected in the On field in the Configuring the event section in How to Set up a Process Automation Integration section. See the Input examples section for information about providing input values. - If the event type set is to "Alert" we can configure all properties related to alert and resource along with resource custom attributes from the tokens section to the payload. - If the event type is set to "Resource" we can configure all properties related to resource along with resource custom attributes from the tokens section to the payload. |
Input examples
On field Integration Event | REST Web service Input field | Input Example |
---|---|---|
Resource | Resource | $taskId.alert.resource, $taskId.resource |
Alert | Alert | $taskId.alert |
Task | Task | $taskId.task |
Incident | Incident | $taskId.alert.incident, $taskId.incident |
Json Object | Json Object | $taskId |
Platform Service
The following platform service tasks are available for the task reference service task:
Platform Service Task | Description |
---|---|
Close Alert | Closes an alert using the alert ID. |
Create/Update Alert | Creates and updates an alert. The Create/Update Alert lets you customize the alerts that are inbound through the integrations. By configuring a custom process definition for an integration, you can customize the incoming alerts according to the properties defined in the process definition. Enter the attribute values. The input text here is provided as an example:
This process definition is available for selection in the Enrich and Create Alert section while creating custom integrations. See the Configure the custom integration for webhook section to learn more about the Enrich and Create Alert option. |
Find Alerts | Finds a list of alerts that match a PromQL query string.NoteWhen using the PromQL query, it is important to note that there is a limitation of retrieving only 100 results at a time. |
Find Resources | Finds a list of resources that match a PromQL query string.NoteWhen using the PromQL query, it is important to note that there is a limitation of retrieving only 100 results at a time. |
Get Alert | Gets an alert using the alert ID. |
Get Incident | Gets an incident using the incident ID.
|
Heal Alert | Heals an alert using the alert ID. |
Post Alert Comment | Posts a comment using the alert ID. |
Set Alert Priority | Sets an alert priority using the alert ID. |
Update Incident | Updates the following incident attributes using the incident ID.
|
Note
To configure query in the “Find alerts” or “Find resources” task, please refer the Query Language Reference document for more details.An example of a Platform Service is provided below:
To Update Incident Task (see image below).
By default, the default flow was allowed under status change (see image below).
You can configure the status flow at the Partner/Client level if necessary.
Go to Setup » Service Desk » Status Flow to configure the custom status flow.
Utility Service
The Parser Utility Service task parses string text into key values. This helps you to extract information from voluminous data by using custom input fields. Using the parser task, you can define the keys, validate the input string to verify the parsed text, and provide the values as inputs for the next task in a process workflow.
With the Parser task, you can parse any plain text, and also dynamic token values at runtime such as:
- $.alert.uuid
- $.resource.hostName
The parser task parses and returns information such as percentage, descriptions, numbers, or path values that can be used in subsequent tasks in a process workflow.
To use the parser task, do the following:
Add a Service task, select Utility Service from the Service drop-down in the Configuration section.
Select Parser from the Task drop-down list.
Enter the value in the Input field.
Note
- Enter the dynamic values using the tokens from the previous tasks, plain text, or a combination of both.
- Input field supports Json, XML, and YAML formats.
- Click +Add to create multiple input fields. This is optional.
In the fields below the input field, define the key values and enter the text that needs to be parsed. Click + to create multiple key value fields. This is optional.
The following input fields are available:
- Enter Key - Enter a name for the parsed text. For example: Physical Memory % Ensure that each key name is unique.
- Select - Select a parsing operator from the drop-down options:
- After: Parses the text after a given input or word.
- Before: Parses the text before a given input or word.
- Between: Parses the text between the start and end word.
- Pre Pend: Adds the text before a given input or word.
- Post Pend: Adds the text after a given input or word.
Click Validate to verify the parsed output.
In the Validation pop-up that appears, enter the input in the field and click Validate. Validating the input allows you to verify the output, and also make any corrections, if required.
Example:
The following example demonstrates the validation of a plain text alert input using all the five available parsing operators.
The Physical Memory Usage on the device is 56%. The Virtual Memory Usage on the device is 43%.
The following is the parsed text result:
{ "physical memory": "The Physical Memory Usage on the device",
"virtual memory": "43%."}
Parsing dynamic values in run time
The following example demonstrates providing dynamic values as inputs, parsing dynamic values in run time, and using the parsed values in the next task in the process workflow.
For example, the first task in the workflow is the Parser utility task and the next task is the Post Alert Comment platform service task.
Parser task
The input query for the Parser task is as follows:
Alert created # $StartEvent_10g1j00.alert.uuid on device $StartEvent_10g1j00.alert.resource.hostName. Subject: $StartEvent_10g1j00.alert.subject.
The validation response for this input is:
{
"subject": "$StartEvent_10g1j00.alert.subject",
"alertId": "$StartEvent_10g1j00.alert.uuid",
"deviceName": "$StartEvent_10g1j00"
}
The subject, alertId, and deviceName parameters are the outputs of the Parser task. The actual values are replaced with tokens in the run time.
Note that the values are not yet assigned to these parameters. These are provided as inputs for the Post Alert Comment task.
Post Alert Comment task
The following parameters are provided as inputs after parsing the text:
- Alert Id - The alert id is generated from the parser task.
$Parser.alertId
- Subject - The name of the subject is appended from the parser task.
$Parser.subject
- Device - The name of the device is appended from the parser task.
$Parser.deviceName
The result of the Post Alert Comment task is as follows:
Alert Id: 24475 Subject: Testing the parser task. Device: Think-pad
Call Activity
A Call Activity is a set of tasks that is defined and executed independently from the main process definition workflow. It is a reusable process that can be called by multiple process definitions. A call activity performs the defined set of tasks by creating a new process instance, executes the task, and the main process definition continues afterwards.
Assign a call activity to a process definition
To assign a call activity to a process definition, do the following:
- Create a new process definition by clicking +Add.
- In the display canvas, enter a required Name for the process. You can enter an optional process Description.
- Add a start event and append a task.
- For the task, click the Change type and choose Call Activity.
- Click the task to view the task properties and enter the following:
- Name - Enter the name.
- ID - The ID is auto-generated.
- Process - Select the specific process definition created for the call activity from the available list.
- Input - Enter the input.
When the signal input is triggered, the call activity is also triggered and performs the tasks as defined in the process selected from the Process field and moves to the subsequent tasks in the process definition.
The following is a sample process definition with call activity. The call activity is indicated by a thicker border and a + sign.
Sub Process (expanded)
A Sub Process is a set of tasks that is defined and executed independently within the main process definition workflow. It can contain:
- Other activities
- Gateways
- Events
A sub process performs a set of related tasks on its own, and the workflow moves to the next task in the main process.
The following are some of the points to remember about the Sub Process:
- Runs only within the main process.
- Only None start event is available.
- Must have at least one end event.
- The outputs of the sub process cannot be used as the inputs of the subsequent tasks.
- Contains only the Name property. The ID is auto-populated.
- Additional properties such as Multi-instance is available when it is defined from the previous task.
The following is a sample sub process definition:
The sample sub process definition can be explained in the following way:
- The list_of_critical_alerts task contains a list of critical alerts.
- The subProcess is defined within the main process definition. The task of the subprocess is to comment and close the alerts coming from the previous list_of_critical_alerts task.
- The three vertical lines indicate that a multi-instance loop is added to the sub process. A multi-instance loop indicates that a particular task has to be performed multiple times.
The following additional properties are available for a sub process when a loop is added:- Parallel Multi instance: Indicated by three vertical lines. All tasks are executed concurrently and independently from each other.
- Sequential Multi instance: Indicated by three horizontal lines. All tasks are executed one after the other.
- Collection: Enter the array list from the list_of_critical_alerts task. For example:
$list_of_critical_alerts.alerts
- Element Variable: Enter the variable in which the alert will be stored. For example:
x
So, if five alerts come through the task, each alert will be repeated. For example, the first alert is mapped to the x variable, the action is performed, and then the second alert is mapped until all five alerts go through this process. - Loop Cardinality: The number of times a process is iterated. Select the Number of loops from the range. If you select 3, the tasks will be iterated three times either parallely or sequentially based on the multi-instance selection.
Multi-Instance Activities
A multi-instance activity is a process of defining repetition for a task in the sub process. All the following tasks can be used to define a multi-instance activity:
- Service Task
- Send Task
- User Task
- Business Rule Task
- Script Task
- Sub-Process
- Call Activity
Gateway Reference
Process definition includes the following gateway references.
Symbol | Name | Description | Properties |
---|---|---|---|
Exclusive gateway | (default) Specifies conditional task execution. Use the connector symbol to specify the branching condition. |
| |
Parallel gateway | Specifies concurrent task execution. |
|
Connector Reference
Process definition includes the following connector references.
Symbol | Name | Description | Properties |
---|---|---|---|
Sequence Flow | Connects two components in a directed, sequential workflow. |
| |
Default Flow | Connects two components in a conditional workflow. Default processing continues in the direction of this connector if the specified condition is not satisfied. |
|