Zum Inhalt springen
OTOBO Community Guide

CI-Modellierung mit YAML im OTOBO-Ticketsystem

Dieses Kapitel zeigt, wie Sie Ihre Configuration Items (CIs) im OTOBO-Ticketsystem per YAML definieren und erweitern – von der Seiten- und Layout-Struktur bis zu dynamischen Feldern und Feldtypen.

1. Aufbau von CI-Definitionen

Abschnitt betitelt „1. Aufbau von CI-Definitionen“

Jede CI-Definition in OTOBO besteht aus mehreren Hauptbestandteilen:

- Class:
    Name: <CI-Klasse>
    Categories:
      - All
      - <Weitere Kategorien>
    NumberModule: AutoIncrement
    PermissionGroup: itsm-configitem
    VersionStringModule: Incremental
  Definition: |
    Pages:
      - Name: Summary
        Layout:
          Columns: 3
          ColumnWidth: 1fr 1fr 1fr
        Interfaces:
          - Agent
          - Customer
        Content:
          - Section: General Fields::General Information
            RowStart: 1
            ColumnStart: 1
          - Section: ITSM Model::Model
            RowStart: 1
            ColumnStart: 2
          - Section: CMDB Description::Description
            RowStart: 2
            ColumnStart: 1
            ColumnSpan: 2
  DynamicFields: { … }

1.1 Pages

Abschnitt betitelt „1.1 Pages“
  • Name: Bezeichnung des Tabs im Agent-Zoom.
  • Interfaces: Steuerung, wer den Tab sieht (Agent, Customer, …).
  • Content: Liste von Sektionen, mit Position (RowStart, ColumnStart, ggf. Span).

1.2 Layout

Abschnitt betitelt „1.2 Layout“
  • Columns: Anzahl der Spalten im Tab.
  • ColumnWidth: Proportionale Breitenangaben (z. B. 1fr 2fr 1fr).

1.3 Rollen (Roles)

Abschnitt betitelt „1.3 Rollen (Roles)“

Rollen definieren wiederverwendbare Sektionen und Feldlisten:

- Definition: |
    Sections:
      General Information:
        Content:
          - Header: Allgemeine Informationen
          - DF: System-Name
          - DF: System-Version
      Relations:
        Type: ConfigItemLinks
        Header: Beziehungen
  RoleName: CMDB General Fields
  • RoleName: Eindeutiger Name der Rolle.
  • Sections: Enthält eine oder mehrere Sektionen mit Feldreferenzen (DF:).

2. Dynamische Felder (DynamicFields) und Feldtypen

Abschnitt betitelt „2. Dynamische Felder (DynamicFields) und Feldtypen“

Mit DynamicFields erweitern Sie Ihre CI-Klassen um individuelle Attribute. Jedes Feld erhält Name, Typ und Konfiguration:

DynamicFields:
  DynamicFieldName:
    FieldType: Text
    Label: My Label
    Name: System-Name
    ObjectType: ITSMConfigItem
    Config:
      DefaultValue: 'demo'
      MultiValue: '0'
      PossibleNone: '1'
      Tooltip: ''


  System-LifecycleStatus:
    FieldType: Dropdown
    Label: Lifecycle status of system
    Name: System-LifecycleStatus
    ObjectType: ITSMConfigItem
    Config:
      DefaultValue: ''
      MultiValue: '0'
      PossibleNone: '1'
      PossibleValues:
        demo: demo
        productive: productive
      Tooltip: ''

2.1 Wichtige Feldtypen

Abschnitt betitelt „2.1 Wichtige Feldtypen“
FieldTypeBeschreibung
TextEinfaches Einzeilig-Feld
TextAreaMehrzeiliges Freitextfeld
DateDatumsfeld (mit Einschränkungen via YearsInPast/...)
DropdownAuswahlfeld (Single/Multi via MultiValue)
AgentLDAP-User/Agent Lookup
ConfigItemVerknüpfung zu anderem CI (Relationstyp definierbar)
ScriptTemplateToolkitBerechnetes Feld via Template (z. B. Summen)

2.2 Konfigurationsoptionen

Abschnitt betitelt „2.2 Konfigurationsoptionen“
  • DefaultValue: Vorgabewert bei Neuanlage.
  • MultiValue: '0' (einzelne Auswahl) oder '1' (mehrfach).
  • PossibleNone: '1', um leere Auswahl zu erlauben.
  • PossibleValues: Key-Value-Paare für Dropdown-Felder.
  • EditFieldMode: z. B. Dropdown, AutoComplete.
  • ReferenceFilterList, ReferencedObjectType: Für Lookup-Felder.

3. Beispiel

Abschnitt betitelt „3. Beispiel“
- Class:
    Name: CIName
    Categories:
      - All
      - IT
    NumberModule: AutoIncrement
    PermissionGroup: itsm-configitem
    VersionStringModule: Incremental
  Definition: |
    Pages:
      - Name: Intro
        Layout:
          Columns: 2
          ColumnWidth: 1fr 1fr
        Interfaces:
          - Agent
        Content:
          - Section: CMDB General Fields::Information
            RowStart: 1
            ColumnStart: 1
          - Section: CMDB General Fields::Risks
            RowStart: 2
            ColumnStart: 1
      - Name: Details
        Layout:
          Columns: 1
          ColumnWidth: 1fr
        Interfaces:
          - Agent
        Content:
          - Section: CMDB General Fields::Software
            RowStart: 1
            ColumnStart: 1
  DynamicFields:
    System-Name: { … }
    System-Version: { … }
    System-LifecycleStatus: { … }

4. Tipps und Best Practices

Abschnitt betitelt „4. Tipps und Best Practices“
  • Modularität: Nutzen Sie Rollen für wiederkehrende Sektionen.
  • Übersichtlichkeit: Gruppieren Sie verwandte Felder in eigene Pages.
  • Dokumentation: Kommentieren Sie Ihre YAML-Dateien und pflegen Sie Versions­trigger.
  • Testing: Validieren Sie neue Felder zuerst in einer Testinstanz.

Mit diesem Aufbau können Sie die OTOBO-CMDB flexibel an Ihre Organisationsanforderungen anpassen und stets transparent halten.

Häufig gestellte Fragen

Wie werden Configuration Items (CIs) in OTOBO mit YAML definiert?

Configuration Items (CIs) in OTOBO werden durch YAML-Dateien modelliert, die eine umfassende Definition der CI-Klassen ermöglichen. Diese Definitionen umfassen die Struktur der Benutzeroberfläche durch Seiten (Pages) und deren Layout, die Festlegung von wiederverwendbaren Rollen (Roles) sowie die Konfiguration von dynamischen Feldern (DynamicFields) für spezifische Attribute. Jede CI-Klasse erhält dabei einen Namen, Kategorien, ein Nummernmodul, eine Berechtigungsgruppe und ein Versionsmodul. Der YAML-Ansatz bietet eine flexible und transparente Methode, um die CMDB an die individuellen Anforderungen einer Organisation anzupassen und die Verwaltung von Assets zu optimieren.

Quellen:

Welche Hauptbestandteile hat eine CI-YAML-Definition in OTOBO?

Eine typische CI-YAML-Definition in OTOBO gliedert sich in drei Hauptbereiche: die Class-Definition, die Definition der Benutzeroberfläche und die DynamicFields. Im Class-Abschnitt werden grundlegende Eigenschaften wie der Name der CI-Klasse, Categories, das NumberModule (z.B. AutoIncrement), die PermissionGroup und das VersionStringModule festgelegt. Der Definition-Teil beschreibt, wie das CI im Agent-Zoom dargestellt wird, insbesondere durch Pages mit deren Name, Layout (Spaltenanzahl, -breite) und Interfaces (Agent, Customer) sowie den Content (Sektionen mit Positionierung). Schließlich werden im DynamicFields-Bereich alle individuellen Attribute des CIs mit ihren spezifischen Feldtypen und Konfigurationsoptionen definiert.

Quellen:

Wie strukturiert man die Benutzeroberfläche für CIs mithilfe von Pages und Layout in YAML?

Die Benutzeroberfläche für Configuration Items in OTOBO wird über die Pages- und Layout-Definitionen in der YAML-Datei strukturiert. Jede Page repräsentiert einen Tab im Agent-Zoom und benötigt einen Name. Über Interfaces wird gesteuert, welche Benutzergruppen (z.B. Agent, Customer) diesen Tab sehen können. Der Content einer Seite besteht aus einer Liste von Sektionen, die jeweils eine RowStart, ColumnStart und optional eine ColumnSpan erhalten, um ihre Positionierung festzulegen. Das Layout innerhalb einer Seite definiert die Anzahl der Columns und deren ColumnWidth (z.B. 1fr 1fr 1fr für drei gleich breite Spalten), wodurch eine flexible Anordnung der Inhalte ermöglicht wird.

Quellen:

Wozu dienen Rollen (`Roles`) in der CI-YAML-Definition und wie werden sie eingesetzt?

Rollen (Roles) in der CI-YAML-Definition dienen dazu, wiederverwendbare Sektionen und Feldlisten zu definieren, was die Modularität und Wartbarkeit der CI-Modelle erheblich verbessert. Anstatt dieselben Feldgruppen in mehreren CI-Klassen redundant zu definieren, können sie einmal als Rolle angelegt und dann referenziert werden. Jede Rolle erhält einen eindeutigen RoleName und enthält eine oder mehrere Sections. Innerhalb dieser Sektionen werden die tatsächlichen Felder über DF: (DynamicField-Referenzen) oder Header für Überschriften definiert. Dies fördert Best Practices, indem es die Konsistenz über verschiedene CI-Typen hinweg sicherstellt und den Pflegeaufwand bei Änderungen reduziert.

Quellen:

Wie konfiguriert man dynamische Felder (DynamicFields) und deren Optionen in OTOBO CI-Definitionen?

Dynamische Felder (DynamicFields) erweitern CI-Klassen um individuelle Attribute und werden mit einem Namen, einem FieldType, einem Label und einem ObjectType konfiguriert. Der Config-Abschnitt innerhalb jedes DynamicFields ermöglicht eine detaillierte Anpassung. Wichtige Optionen sind DefaultValue für einen Vorgabewert bei Neuanlage, MultiValue ('0' für Einzelauswahl, '1' für Mehrfachauswahl) und PossibleNone ('1', um eine leere Auswahl zu erlauben). Für Dropdown-Felder werden PossibleValues als Key-Value-Paare definiert. EditFieldMode steuert die Darstellung (z.B. Dropdown, AutoComplete), während ReferenceFilterList und ReferencedObjectType für Lookup-Felder verwendet werden, um Beziehungen zu anderen Objekten zu filtern. Diese Flexibilität stellt sicher, dass Formulare exakt zu den Anforderungen Ihrer Asset- und CMDB-Verwaltung passen.

Quellen:

Welche wichtigen Feldtypen stehen für DynamicFields in OTOBO zur Verfügung?

Für die Definition von DynamicFields in OTOBO stehen verschiedene Feldtypen zur Verfügung, die unterschiedliche Datentypen und Interaktionsmöglichkeiten bieten. Zu den häufig verwendeten Typen gehören:

  • Text: Für einfache, einzeilige Texteingaben.
  • TextArea: Für mehrzeilige Freitextfelder.
  • Date: Für die Auswahl von Datumsangaben, oft mit Einschränkungen wie YearsInPast.
  • Dropdown: Für Auswahlfelder, die entweder eine Einzel- oder Mehrfachauswahl (gesteuert durch MultiValue) ermöglichen.
  • Agent: Für die Verknüpfung mit LDAP-Benutzern oder OTOBO-Agenten.
  • ConfigItem: Ermöglicht die Verknüpfung zu anderen Configuration Items, wobei der Relationstyp definierbar ist.
  • ScriptTemplateToolkit: Für berechnete Felder, die über ein Template (z.B. zur Anzeige von Summen) generiert werden.
    Diese Vielfalt ermöglicht es, die CI-Attribute präzise abzubilden und die Datenerfassung zu optimieren.

Quellen: