6. YAML Definition

In Ops I, operational requirements are defined in a manifest file (YAML format).
This is based on the “Operations as Code” philosophy; by registering the manifest file with Ops I, it is automatically converted into operational functions.
The following table lists the operational functions that can be specified in the manifest file.

(Table) Operational functions that can be added in YAML files

Name Description
Workflow Define workflows required for operation.
UI Define the UI, including data to be displayed and window layout.
Uipath Define the UI URL.
Datamodel Define a datamodel for storing various types of data.
Catalog Define the service catalog, which is where users make various types of applications.
Script Define actions that are triggered by a particular event, such as when a certain window is displayed or a button is clicked.
Library Define a shared container accessible to multiple users.
Attachment Define naming rules for attachments to be handled during operations.
Distribution Define the rules by which the various types of documents are generated during operations and where those documents should be saved.
ACL Define which users and groups will be authorized as defined in the Statement.
Statement Define authorization settings for various resources, such as URI and table records.
Notification Define notification recipients and content for notifications triggered by events on Ops I and for notifications sent at any point in a workflow.
Notifier Define the method by which the contents of the notification defined in Notification are delivered.
Application Define Ops I applications.
Skill Define how to visualize the experiences, qualifications, and other skills that each user possesses.
Skillset Define a set of skills required to execute each step in a workflow.
Calendar Define calendar templates for schedules.
Import Define mappings between the CSV file to be uploaded and the columns of the custom table when importing records into a custom table.

If coding operational functions in Ops I, it is necessary to write YAML files following a specified format. Detailed descriptions of YAML files for each of the operational functions are provided in “Workflow” through “Import”.

As an example, the relationship between operational functions when executing a workflow from the service catalog is shown below.

(Figure) Relationship between YAML files and operational functions

(Figure) Relationship between YAML files and operational functions (Figure) Relationship between YAML files and operational functions

[Notes on creating YAML files]

  1. The YAML file name must be "manifest.yaml".
  2. You must save the YAML file under a directory with the same name as specified in the top-level "name" label.
  3. The combination of the "kind" label and the "name" label must be unique in Ops I.
  4. The "name" label in the YAML file and the table names in the datamodel contain reserved words used by the system. Do not use reserved words.
    If you must use a reserved word, take measures such as adding a prefix to avoid conflicts. An error might occur if there is a conflict with a reserved word. For details about reserved words, see "Actions to take when a YAML file cannot be registered due to an error with the "name" label or datamodel table name".
  5. If the "name" label in an included YAML file conflicts with another "name" label, unintended behavior will occur. For details, see "Actions to take when no error message appears but unintended behaviors occur".

YAML files can be loaded from Ops I by registering them in a repository within a user-defined group. As a result, Ops I automatically generates the corresponding operations functions. For information on how to register YAML files, see “Register YAML files with GitLab (GUI)” and “Register YAML files with GitLab (CUI)”.

(Figure) How to register YAML files

(Figure) How to register YAML files (Figure) How to register YAML files

The template function can also be used to define YAML files.
The template function is a document function that enables terms defined as environmental parameters in YAML files to be replaced with user-defined or system-defined parameters. This is useful for supporting multiple languages, etc.


[User-defined parameters]

“YAML files” that use the template function and “template files” that contain reference values must meet the following conditions.

  • The YAML file and template file must be placed in the same folder.
  • The name of the template file must be “values.yaml”.
  • The chapter structure used in the YAML file must be the following format.

"{{.Values.the path specified in the template file}}"

or

'{{.Values.the path specified in the template file}}'


<YAML files that can use parameters>
  • application
  • ui
  • library
  • catalog
  • skill
  • skillset
  • workflow

(Figure) Template function

(Figure) Template function (Figure) Template function


[System-defined parameters]

System-defined parameters that can be used with Ops I are as follows.

(Table) System-defined parameters that can be used with the template function

System-defined parameter Description
.System.domain Ops I environment domain

Ensure that the chapter structure used in the YAML file is in the following format.

"{{.System.domain}}"

or

'{{.System.domain}}'


<YAML files that can use parameters>
  • application
  • ui
  • library
  • catalog
  • statement (only when authzType is "uri")
  • notification
  • skill
  • skillset
  • workflow


Chapter structure

6.1 Workflow
6.2 UI
6.3 Datamodel
6.4 Catalog
6.5 Script
6.6 Library
6.7 Attachment
6.8 Distribution
6.9 ACL, Statement
6.10 Notification, Notifier
6.11 Application
6.12 Skill, Skillset
6.13 Calendar
6.14 Import