6. YAML Definition

Ops I allows you to add definitions required for operations, such as workflows and datamodels, in YAML files, making it possible to realize Operations as Code (OC). Registering coded operations with Ops I automatically converts them to their respective operational functions.

A list of operational functions that can be added in YAML files is provided 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

(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.
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.
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 who to notify and what to notify when there is an event on Ops I.
Notifier Define the method by which the contents of the notification defined in Notification are delivered.
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.

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 “Calendar”. The common format for all operational functions is as follows.

(Table) YAML file common format

Label Required* Description
apiVersion: Yes API version
kind: Yes YAML file type
type: No Select a YAML file type from the options below
  • resource: Expand Ops I functions
  • container: Create a container for storing documents
name: Yes YAML file internal name. The directory name of this YAML file must be specified.
The name must be in accordance with the following rules.
  • The characters that can be input are as follows.
    • Space
    • Single-byte alphanumeric character:
      a-z A-Z 0-9
    • Single-byte symbol:
      _ . ( ) -
  • The first character is a single-byte alphanumeric character or an underscore (_)
*Some operational functions have additional restrictions. Be sure to check the description of the YAML definition for each operational function.
label: Yes YAML file display name
includes: No List the related YAML files for use in this YAML file.
*YAML files to be added must be registered with Ops I before that YAML file is registered.
- kind: Yes Type of YAML file to be loaded
  name: Yes Internal name of YAML file to be loaded
description: No Detailed description
*No definition is required if "No" is selected for the requirement on non-nested labels. In the case of nested labels, the lower-level label requirement applies if “Yes” is selected for the upper-level label requirement.

If created YAML files are committed to GitLab in Ops I, Ops I will automatically generate the corresponding operational functions. YAML files must be named “manifest.yaml” and saved under the same directory as the name specified in the “name” label.
Also, the combination of the “kind” and “name” labels must be unique within Ops I.

The “name” label for the YAML files and the datamodel table name must be prefixed to avoid conflicts with reserved words. In the event of a conflict with a reserved word, an error is generated. For details, see “Actions to take when a YAML file cannot be registered due to an error with the “name” label or datamodel table name”.
Conflict with another “name” label in a YAML file specified for inclusion may cause unintended behavior. 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. 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
  • 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