Triggers

You can use triggers to create services, and to define whether the orchestration must be time-driven or event-driven

When controlling the processing of workflows and tasks in workflows using triggers, you can create services, and you can also define if the orchestration must be time-driven or event-driven. You can add triggers to workflows both from the Orchestration CLI and the UI.

Services

A service can be enabled when defining workflows. Users can log in to the Self-Service Catalog interface to start the services linked to the workflows. By simply launching a service, mobile users can submit the linked workflows. For information about this feature see Self-Service Catalog.

Time-driven orchestration

You can define a time-driven orchestration by adding run cycles and excluding run cycles to your workflows, which are mutually exclusive with event triggers. When defining run cycles and excluding run cycles from the UI, the run cycle preview appears and provides a graphical representation of the run instances generated by the run cycle rules. For more information, see Run cycle preview.
Run cycles
A run cycle specifies the days and times when a workflow is scheduled to run. Run cycles and event triggers are mutually exclusive.
When defining a run cycle, you need to define the following properties:
Rule
Run cycle rules are based on lists of ordinal numbers, types of days, and common calendar intervals. For example, the first Monday of every month. Rule-based run cycles are based on conventional periods, such as calendar months, weeks of the year, and days of the week. There are different types of rules:
Simple
By selecting a simple rule type, you can define the run cycle days directly from the calendar widget.
Calendar
By selecting a calendar rule type, you can reference an existing calendar that is saved in the database and the days that are defined on that calendar are used as a base for the run cycle.
iCalendar RRule
By selecting an iCalendar RRule type, you can enter an iCalendar Recurrence Rule expression and use it as base for the run cycle. From the UI, a RRule generator is available; for more information, see iCalendar RRule generation
Cron expression
By selecting a Cron expression rule type, you can enter a Cron expression and use it as base for the run cycle.
For more information, see Cron expression arguments.
Run cycle group
A run cycle group is a single, reusable item that contains one or more run cycles. For more information, see Run cycle group definition.
Time restrictions
You can use time restrictions to define the time properties of the run cycle and the actions to take if the latest start time defined for the workflow elapses.
Excluding run cycles
An excluding run cycle specifies the days and times when a workflow must not run. Excluding run cycles take precedence over run cycles.
Excluding run cycles and event triggers are mutually exclusive.
When defining an excluding run cycle, you need to define the following properties:
Rule
Excluding run cycle rules are based on lists of ordinal numbers, types of days, and common calendar intervals. For example, the first Monday of every month. Rule-based excluding run cycles are based on conventional periods, such as calendar months, weeks of the year, and days of the week. There are different types of rules:
Simple
By selecting a simple rule type, you can define the excluding run cycle days directly from the calendar widget.
Calendar
By selecting a calendar rule type, you can reference an existing calendar that is saved in the database and the days that are defined on that calendar are used as a base for the excluding run cycle.
iCalendar RRule
By selecting an iCalendar RRule type, you can enter an iCalendar Recurrence Rule (RRule) expression and use it as base for the excluding run cycle. From the UI, a RRule generator is available; for more information, see iCalendar RRule generation.
Cron expression
By selecting a Cron expression rule type, you can enter a Cron expression and use it as base for the excluding run cycle.
For more information, see Cron expression arguments.
Run cycle group
A run cycle group is a single, reusable item that contains one or more run cycles. For more information, see Run cycle group definition.
Time restrictions
You can use time restrictions to define the time properties of the excluding run cycle.
iCalendar RRule generation

In the Rule section of the trigger Properties panel, you can select the iCalendar RRule type and then enter an expression or generate one by clicking Generate RRule. The Create Recurring Event panel appears, and you can define the following parameters:

Basic parameters Meaning Description
FREQ Frequency Defines the core interval of time for the recurrence. The available frequency values are:
  • Secondly
  • Minutely
  • Hourly
  • Daily
  • Daily by freedays
  • Daily by working days
  • Weekly
  • Monthly
  • Yearly
Note: If you set the frequency to DAILY BY FREEDAYS or DAILY BY WORKING DAYS, the only other parameter that you can define for the recurring event is INTERVAL.
INTERVAL Interval Defines how often the FREQ repeats (from 0 to 2,147,483,647).
BYDAY Day of the week Specifies one or more days of the week, for example: MO, TU.
BYMONTH Month of the year Specifies one or more months of the year, for example: 1 for January.
BYMONTHDAY Day of the month Specifies the specific day of the month (from -31 to 31). For example: BYMONTHDAY=1 is the first day of the month.
WKST Week start Specifies the start day of the week. This parameter is supported only when the frequency is set to WEEKLY.
Advanced parameters Meaning Description
UNTIL End date Sets a specific date or time for the recurrence to stop.
COUNT Occurrences Sets the total number of times the event repeats (from 0 to 2,147,483,647).
BYSETPOS Set position Filters the complete set of occurrences generated by the other rules to keep only specific positions. For example, BYSETPOS=-1 restricts the schedule to only the last occurrence in the set; all other potential dates in that period are excluded.
BYWEEKNO Week number Specifies the week of the year:
  • Standard years: Values range from -52 to 52.
  • Leap years: Values range from -53 to 53.
BYYEARDAY Year day Specifies the day of the year:
  • Standard years: Values range from -365 to 365.
  • Leap years: Values range from -366 to 366.
BYHOUR Hour Specifies the hour of the day (from 0 to 23).
BYMINUTE Minute Specifies the minute of the hour (from 0 to 59).
BYSECOND Second Specifies the second of the minute (from 0 to 59).
The check marks (✓) in the following table outline the supported combinations for recurrence parameters:
Table 1.
Frequency (FREQ) SECONDLY MINUTELY HOURLY DAILY WEEKLY MONTHLY YEARLY
BYMONTH ✓ ✓ ✓ ✓ ✓ ✓ ✓
BYWEEKNO ✓
BYYEARDAY ✓ ✓ ✓ ✓
BYMONTHDAY ✓ ✓ ✓ ✓ ✓ ✓
BYDAY ✓ ✓ ✓ ✓ ✓ ✓ ✓
BYHOUR ✓ ✓ ✓ ✓ ✓ ✓ ✓
BYMINUTE ✓ ✓ ✓ ✓ ✓ ✓ ✓
BYSECOND ✓ ✓ ✓ ✓ ✓ ✓ ✓
BYSETPOS ✓ ✓ ✓ ✓ ✓ ✓ ✓
After having defined the necessary parameters, click Set rule to add the generated RRule to the Expression field.
Note: By default, the recurrence pattern starts on 01/01/2020. You can change this by defining a different Valid From date.
Cron expressions arguments

HCL Universal Orchestrator accepts both Crontab and CronTrigger expressions, but when you enter a Crontab expression, it is converted into a CronTrigger expression.

Crontab and CronTrigger expressions have different structures, and sometimes the differences might change the original meaning of the expression:
Specifying month and week days
In CronTrigger expressions, you cannot define both the day of the month and the day of the week, while in Crontab expressions you can define both.
Day of week
Both CronTrigger and Crontab expressions accept the 3 characters day name format and the number of the day format.
In Crontab expressions, you can define the day of the week using the 0-6 (Sunday to Saturday) or 1-7 (Sunday to Saturday) format, but in CronTrigger expression the only number of the day format that is accepted is 1-7 (Sunday to Saturday).

Event-driven orchestration

You can define an event-driven orchestration by using event triggers, that are mutually exclusive with run cycles and excluding run cycles.
Event triggers

Before you can add event triggers to your workflows, you need to define at least one event source.

Event triggers can contain either a single event or a collection of sequential or unordered events, for which can be specified correlations and timeouts. If you set a correlation among events in an event trigger, all the received events must have the same value in the specified common fields to satisfy the event trigger and trigger the launch of the workflow. An event trigger can contain events from different event sources. All the events within an event trigger contain the conditions that determine if a matching event is received or not. When an event trigger is satisfied, the workflow is submitted. Event triggers are mutually exclusive with run cycles and excluding run cycles.
Single event in event trigger
When an event trigger contains a single event, the reception of the event submits the workflow, which proceeds to READY status and it is launched.
Multiple events in event trigger
When an event trigger contains multiple events, the workflow is submitted upon the reception of the first event from the event source, and it is set to ADD status. If a timeout time is specified, a workflows in ADD changes status to SUPPR if all the events in the event trigger are not received by the timeout time. If all the events are received before the timeout, the workflows proceeds to READY status and is launched. If the trigger on timeout option is selected and the a timeout time is specified, the workflow is launched if the events in the event triggers are not satisfied within the specified timeout.
Note: When defining event conditions, all the relative fields are case insensitive.
Plug-in event types
These are types of plug-in events that can be defined in an event trigger: