Konfiguration & Template Rendering

Verstehen Sie den Konfigurationslebenszyklus von Open Ticket AI, Template Rendering mit Jinja2, Dependency Injection und wie YAML in Runtime-Objekte transformiert wird.

Konfiguration & Template Rendering

Open Ticket AI ermöglicht Ihnen die Erstellung dynamischer Konfigurationen mit YAML plus Jinja2 Template Expressions wie

Dies ermöglicht Ihnen die Wiederverwendung von Werte, das Lesen von Environment-Variablen und die Referenzierung von Ergebnisse aus anderen Pipes — alles während die Konfiguration sauber und deklarativ bleibt.

Key Concepts

Injectable Configuration Structure

Sowohl Services als auch Pipes in Open Ticket AI verwenden die gleiche Konfigurationsstruktur genannt InjectableConfig. Das Verständnis dieser drei Kernattribute hilft Ihnen, jede Komponente im System zu konfigurieren.

Configuration Attributes

Key Differences: Services vs. Pipes

Obwohl beide InjectableConfig verwenden, unterscheiden sie sich in der Nutzung:

Services

• Einmal definiert im services Abschnitt
• Wiederverwendbar über mehrere Pipes
• Muss ein id Feld für Referenzierung haben
• Repräsentieren meist externe Systeme

Example:

services:
  otobo_znuny:
    use: 'otobo-znuny:OTOBOZnunyTicketSystemService'
    injects: {}
    params:
      base_url: 'https://helpdesk.example.com'
      password: "{{ get_env('OTOBO_PASSWORD') }}"

Pipes

• Definiert innerhalb Pipeline steps
• Führen Aktionen in Sequenz aus
• Haben ebenfalls ein id Feld um Ergebnisse zu referenzieren
• Nutzen Services via injects um Arbeit zu erledigen

Example:

steps:
  - id: fetch_tickets
    use: 'base:FetchTicketsPipe'
    injects:
      ticket_system: 'otobo_znuny'
    params:
      ticket_search_criteria:
        limit: 25

Template Rendering

Alle params und injects Werte unterstützen Jinja2 Templating für dynamische Konfiguration:

params:
  api_key: "{{ get_env('API_KEY') }}"
  queue: "{{ get_pipe_result('classify', 'label') }}"

Related: Template Rendering · Dependency Injection

Config Reference

Hier ist die Markdown-Tabelle, die die vollständige Konfigurationsstruktur beschreibt, sauber und bereit für Ihre Docs.

Tiny example

otai:
  api_version: '1'
  plugins: []
  infrastructure:
    logging:
      level: 'INFO'
  services:
    ticket-db:
      use: 'plugin_name:Database'
      params:
        url: "{{ get_env('DB_URL') }}"
  orchestrator:
    id: 'root'
    use: 'base:CompositePipe'
    injects:
      step1: 'ticket-db'
    params: {}

Available helper functions (for config.yml templates)

Usage examples in config.yml

Read an environment variable

api:
  token: "{{ get_env('API_TOKEN') }}"
  baseUrl: 'https://api.example.com'

Consume a previous pipe’s result

classification:
  label: "{{ get_pipe_result('classify_ticket', 'label') }}"
  confidence: "{{ get_pipe_result('classify_ticket', 'score') }}"
  isLowConfidence: "{{ get_pipe_result('classify_ticket', 'score') < 0.6 }}"

Check if a pipe failed

shouldRetry: "{{ has_failed('fetch_customer') }}"

Read a parent parameter

timeoutMs: "{{ get_parent_param('timeoutMs') }}"

Emit an explicit failure marker

result: '{{ fail() }}'

Access nested data (dict or Pydantic model)

userCity: "{{ at_path(user, 'address.city') }}"

Full Examples / Templates

See full working examples of config.yml

Config Examples.