Process Definition Reference

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.	Name ID Input Type Alert (default) Resource Add Custom Input (optional) Select or deselect the Add Custom Input toggle. Click + to add custom input fields.
	Timer Start Event	Process initial state. Transition to the next process step is triggered by a time event.	Name ID Start Date Ends Never AfternumberOfOccurrences On Recurrence Pattern Minute Hourly Daily Weekly Monthly Repeats Every
	Signal Start Event	Process initial state. Transition to the next process step is triggered by an alert, incident, or resource signal event.	Name ID Signal type: Alert Incident, Limitations Resource Signal event: Created Updated Filter Criteria Start event condition. Example: $attribute1Name =
	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.	Name ID Time Definition Type: Duration In - Enter the duration. Select Days Hours Minutes Seconds Time Select the time in 24 hour format.
	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.	Name ID Duration In - Enter the duration. Select Days Hours Minutes Seconds
	End Event	Process end state.	Name ID

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.	Name ID Input Message Recipient Notification Template Notification Priority VERY_LOW LOW NORMAL (default) HIGH URGENT
	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.	Name ID Platform Agent (default) Agentless Script Name Resource ID Run As Default user (default) Use the user of the agent service for execution. Other users Use the credential assigned to the resource.
	Service Task	Runs an external, REST API, local platform, and utility service.	Name ID Service REST Web Service Platform Service Utility Service See REST Web service task for descriptions of the available properties. See Platform service tasks for descriptions of the available tasks. See Utility service tasks for descriptions of the available tasks.
	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.	Name ID Subject Description Priority Low Normal High Urgent Very Low Due Date In Interval Days Hours Minutes Seconds Assignee Group Assignee

Type of Services under Service Tasks

There are three types of services under Service Task.

1. REST Web Service: Configure the REST API calls with integration setup.
2. Platform Service: The platform service tasks are available for the service task.
3. Utility Server: This service allows you to parse the server.

REST Web Service

The REST web service task calls an external API.

Input examples

Platform Service

The following platform service tasks are available for the task reference service task:

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:

1. Add a Service task, select Utility Service from the Service drop-down in the Configuration section.

2. Select Parser from the Task drop-down list.

3. 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.

4. 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.

5. Click Validate to verify the parsed output.

6. 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:

1. Create a new process definition by clicking +Add.
2. In the display canvas, enter a required Name for the process. You can enter an optional process Description.
3. Add a start event and append a task.
4. For the task, click the Change type and choose Call Activity.

   

5. 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

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.	Name ID
	Parallel gateway	Specifies concurrent task execution.	Name ID

Connector Reference

Process definition includes the following connector references.

Symbol	Name	Description	Properties
	Sequence Flow	Connects two components in a directed, sequential workflow.	Name ID
	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.	Name ID