Zum Inhalt springen
OTOBO Community Guide

Plugin-Entwicklung mit OPM-Paketen

In diesem Abschnitt lernst du, wie du eigene Plugins als OPM-Pakete für OTOBO erstellst, installierst und verteilst.

1. Aufbau einer .sopm

Abschnitt betitelt „1. Aufbau einer .sopm“

Die SOPM-Datei (*.sopm) enthält alle Metadaten deines Pakets:

<?xml version="1.0" encoding="utf-8"?>
<otobo_package version="1.0">
  <Name>MyExtension</Name>
  <Version>1.0.0</Version>
  <Framework>10.0.x</Framework>   <!-- Mindestversion OTOBO -->
  <Vendor>DeinName GmbH</Vendor>
  <URL>https://github.com/dein-user/otobo-mypackage</URL>
  <License>GPL-3.0</License>
  <Description Lang="de">Erweiterung für spezielle Funktionen</Description>
  <ChangeLog Version="1.0.0" Date="13.06.2025 12:00:00">Erstveröffentlichung</ChangeLog>
  <Filelist>
    <File Location="Kernel/Config/Files/XML/MyExtension.xml" Permission="644"></File>
    <File Location="Kernel/System/MyExtension.pm"            Permission="644"></File>
    <File Location="Kernel/Modules/AgentMyPage.pm"           Permission="644"></File>
    <File Location="Kernel/Output/HTML/Standard/AgentMyPage.tt" Permission="644"></File>
    <File Location="Kernel/Language/de_MyExtension.pm"       Permission="644"></File>
  </Filelist>
</otobo_package>
  • Name/Version/Framework: Eindeutige Paketkennung und kompatible OTOBO-Version.
  • Filelist: Alle Dateien, die beim Installieren kopiert werden.

2. Dateien & Verzeichnisstruktur

Abschnitt betitelt „2. Dateien & Verzeichnisstruktur“

Lege dein Paket in einem eigenen Verzeichnis an, z.B. MyExtension/:

MyExtension/
├─ MyExtension.sopm
├─ Kernel/
│  ├─ Config/Files/XML/MyExtension.xml
│  ├─ System/MyExtension.pm
│  ├─ Modules/AgentMyPage.pm
│  ├─ Output/HTML/Standard/AgentMyPage.tt
│  └─ Language/de_MyExtension.pm
└─ sql/
   └─ create_tables.sql      # optional, für DB-Migrationen
  • Kernel/Config/Files/XML/: Registriert Module, Menüs oder Dynamic Fields.
  • Kernel/System/: Geschäftslogik-Klasse.
  • Kernel/Modules/: Frontend-Controller.
  • Templates & Sprache: TT-Dateien + Übersetzungs-.pm.

3. Paket bauen & installieren

Abschnitt betitelt „3. Paket bauen & installieren“

3.1 OPM erzeugen

Abschnitt betitelt „3.1 OPM erzeugen“

Nutze das CLI-Tool, um aus deiner SOPM ein OPM zu bauen:

Terminal-Fenster
cd /pfad/zu/MyExtension
bin/otobo.Console.pl Dev::Package::Build \
  --sopm-file MyExtension.sopm \
  --output /tmp/MyExtension.opm

3.2 Installation

Abschnitt betitelt „3.2 Installation“

Admin-UI: Paket hochladen unter Admin → Einstellungen → Paketverwaltung. Konsole:

Terminal-Fenster
bin/otobo.Console.pl Admin::Package::Install /tmp/MyExtension.opm

Zum Deinstallieren bzw. Aktualisieren:

Terminal-Fenster
bin/otobo.Console.pl Admin::Package::Uninstall /tmp/MyExtension.opm
bin/otobo.Console.pl Admin::Package::Upgrade   /tmp/MyExtension.opm

4. Erweiterungspunkte

Abschnitt betitelt „4. Erweiterungspunkte“

4.1 Dynamic Fields

Abschnitt betitelt „4.1 Dynamic Fields“

In Kernel/Config/Files/XML/MyExtension.xml registrierst du einen neuen Dynamic Field Driver:

<Setting Name="DynamicFields::Driver###MyCustomField" Required="0" Valid="1">
  <Navigation>DynamicFields::Driver</Navigation>
  <Value>
    <Array>
      <Item><Hash>
        <Item Key="DriverName">MyCustomField</Item>
        <Item Key="Module">Kernel::System::DynamicField::Driver::MyCustomField</Item>
      </Hash></Item>
    </Array>
  </Value>
</Setting>

Implementiere den Driver in Kernel/System/DynamicField/Driver/MyCustomField.pm.

4.2 Event-Handler

Abschnitt betitelt „4.2 Event-Handler“

Melde deinen Event-Handler an:

<Setting Name="Event::EventHandler###MyHandler" Required="0" Valid="1">
  <Navigation>Event::EventHandler</Navigation>
  <Value>
    <Array>
      <Item><Hash>
        <Item Key="Module">Kernel::System::Event::Handler::MyHandler</Item>
      </Hash></Item>
    </Array>
  </Value>
</Setting>

Handler in Kernel/System/Event/Handler/MyHandler.pm implementieren (Run()-Methode).

4.3 Output-Filter

Abschnitt betitelt „4.3 Output-Filter“
<Setting Name="Output::Filter###MyFilter" Required="0" Valid="1">
  <Navigation>Output::Filter</Navigation>
  <Value>
    <Array>
      <Item><Hash>
        <Item Key="Module">Kernel::System::Output::Filter::MyFilter</Item>
      </Hash></Item>
    </Array>
  </Value>
</Setting>

Filter in Kernel/System/Output/Filter/MyFilter.pm.

5. Deployment & OTOpar

Abschnitt betitelt „5. Deployment & OTOpar“

  • Repository-Index: Erzeuge Packages.xml für eigenes Repo:

    Terminal-Fenster
    bin/otobo.Console.pl Dev::Package::RepositoryIndex \
      --directory /var/www/otobo-packages

  • Füge unter SysConfig Package::RepositoryList deine Repo-URL ein.

  • OTOpar: Lade dein OPM bei https://otopar.perl-services.de hoch, damit andere es direkt installieren können.

6. Beispiel: MyCalendar-Paket

Abschnitt betitelt „6. Beispiel: MyCalendar-Paket“
  1. SOPM anlegen mit Name MyCalendar.
  2. DB-Skript sql/create_calendar.sql für Tabelle calendar_events.
  3. Konfig-XML definiert neues Ticket-Feld „Termin“.
  4. Core-Modul Kernel/System/CalendarEvent.pm mit CRUD-Methoden.
  5. Frontend-Module Kernel/Modules/AgentCalendar.pm, Template AgentCalendar.tt.
  6. Paket bauen und in OTOpar upladen.

7. Tipps & Best Practices

Abschnitt betitelt „7. Tipps & Best Practices“
  • Versionsnummer im sopm anpassen (SemVer).
  • DB-Migrationen in sql/ sauber versionieren.
  • Unit-Tests für System- und Module-Klassen anlegen.
  • Dokumentation im README plus POD in Perl-Modulen.
  • Translations in Language/de_*.pm und en_*.pm.

Damit hast du eine solide Basis, um eigene OTOBO-Plugins zu entwickeln, zu verteilen und in Kundenprojekten wartbar einzusetzen. Viel Spaß!

Individuelle OTOBO Modul- & Plugin-Entwicklung

Benötigen Sie maßgeschneiderte Funktionen oder Paket-Upgrades? Softoft entwickelt release-sichere Perl- & Frontend-Erweiterungen.

Entwicklung besprechen

Häufig gestellte Fragen

Was ist eine SOPM-Datei und welche Rolle spielt sie bei der OTOBO-Plugin-Entwicklung?

Die SOPM-Datei (*.sopm) ist das Herzstück jedes OTOBO-Plugins. Sie ist eine XML-Datei, die alle Metadaten und die Dateiliste des Pakets definiert. Wichtige Elemente sind Name, Version (für Kompatibilität mit OTOBO-Framework-Versionen), Vendor, License und eine Description. Besonders kritisch ist die Filelist, die genau auflistet, welche Dateien bei der Installation wohin kopiert und mit welchen Berechtigungen versehen werden. Ohne eine korrekt definierte SOPM-Datei kann kein OPM-Paket gebaut oder installiert werden, da sie dem Paketmanager alle notwendigen Informationen über das Plugin liefert. Sie stellt sicher, dass das Plugin korrekt in das OTOBO-System integriert wird und alle seine Komponenten an den richtigen Stellen landen.

Quellen:

Wie ist die empfohlene Verzeichnisstruktur für ein OTOBO-Plugin und welche Dateitypen gehören wohin?

Eine gut organisierte Verzeichnisstruktur ist entscheidend für die Wartbarkeit und den Build-Prozess eines OTOBO-Plugins. Das Hauptverzeichnis des Plugins, z.B. MyExtension/, sollte die .sopm-Datei direkt enthalten. Innerhalb dieses Verzeichnisses spiegelt die Struktur weitgehend die des OTOBO-Kerns wider. So finden sich unter Kernel/Config/Files/XML/ XML-Dateien zur Registrierung von Einstellungen, Modulen oder Dynamic Fields. Die Geschäftslogik wird in Kernel/System/ abgelegt, während Frontend-Controller in Kernel/Modules/ und zugehörige Templates in Kernel/Output/HTML/Standard/ (oder anderen Themes) ihren Platz finden. Sprachdateien gehören nach Kernel/Language/. Optionale SQL-Skripte für Datenbankmigrationen werden typischerweise in einem sql/-Unterverzeichnis verwaltet. Diese Struktur erleichtert das Auffinden von Komponenten und die Integration in den OPM-Build-Prozess.

Quellen:

Wie erstelle ich ein OPM-Paket aus meinen Plugin-Dateien und der SOPM-Definition?

Um ein installierbares OPM-Paket (.opm) aus Ihren Plugin-Dateien und der SOPM-Definition zu erstellen, verwenden Sie das OTOBO-Kommandozeilen-Tool bin/otobo.Console.pl Dev::Package::Build. Dieser Befehl ist der zentrale Schritt im Build-Prozess. Sie müssen ihm den Pfad zu Ihrer .sopm-Datei über den Parameter --sopm-file mitteilen und den gewünschten Ausgabepfad sowie Dateinamen für das fertige OPM-Paket mit --output angeben. Der Befehl sammelt alle in der Filelist der SOPM-Datei definierten Dateien aus Ihrer Projektstruktur, komprimiert sie zusammen mit den Metadaten in eine einzige .opm-Datei. Diese .opm-Datei ist dann bereit für die Verteilung und Installation über den OTOBO-Paketmanager.

Quellen:

Welche Methoden gibt es, um ein OPM-Paket in OTOBO zu installieren, zu deinstallieren oder zu aktualisieren?

OTOBO bietet flexible Möglichkeiten zur Verwaltung von OPM-Paketen. Die Installation kann entweder über die grafische Benutzeroberfläche erfolgen, indem Sie unter Admin → Einstellungen → Paketverwaltung die .opm-Datei hochladen. Alternativ können Sie die Konsole nutzen, was besonders für automatisierte Prozesse oder Server ohne GUI praktisch ist. Der Befehl bin/otobo.Console.pl Admin::Package::Install /pfad/zum/paket.opm installiert das Paket. Für die Deinstallation verwenden Sie bin/otobo.Console.pl Admin::Package::Uninstall /pfad/zum/paket.opm. Zum Aktualisieren eines bereits installierten Pakets dient bin/otobo.Console.pl Admin::Package::Upgrade /pfad/zum/paket.opm. Diese Konsolenbefehle bieten eine effiziente Methode zur Paketverwaltung und sind für Entwickler und Administratoren gleichermaßen nützlich.

Quellen:

Welche wichtigen Erweiterungspunkte bietet OTOBO für die Plugin-Entwicklung und wie werden sie genutzt?

OTOBO bietet verschiedene Erweiterungspunkte, um die Funktionalität von Plugins tief in das System zu integrieren. Dazu gehören Dynamic Fields, die es ermöglichen, neue, benutzerdefinierte Felder für Tickets oder andere Objekte zu definieren. Diese werden in Kernel/Config/Files/XML/MyExtension.xml registriert und der eigentliche Treiber in Kernel/System/DynamicField/Driver/ implementiert. Event-Handler erlauben es, auf Systemereignisse (z.B. Ticket-Erstellung, Artikel-Update) zu reagieren. Sie werden ebenfalls per XML-Einstellung registriert und die Logik in Kernel/System/Event/Handler/ implementiert. Output-Filter können verwendet werden, um die Ausgabe von OTOBO (z.B. E-Mails, HTML-Seiten) vor der Anzeige oder dem Versand zu manipulieren. Auch diese werden über XML angemeldet und die Filter-Logik in Kernel/System/Output/Filter/ bereitgestellt. Diese Mechanismen ermöglichen eine mächtige und flexible Erweiterung des OTOBO-Kerns, ohne diesen direkt modifizieren zu müssen.

Quellen:

Wie kann ich mein OTOBO-Plugin nach der Entwicklung verteilen und anderen Nutzern zugänglich machen?

Nach der Entwicklung können OTOBO-Plugins auf verschiedene Weisen verteilt werden. Für die Verteilung innerhalb einer Organisation oder an einen begrenzten Kundenkreis können Sie ein eigenes Paket-Repository aufsetzen. Dies geschieht, indem Sie alle Ihre .opm-Dateien in einem Verzeichnis ablegen und dann mit bin/otobo.Console.pl Dev::Package::RepositoryIndex --directory /pfad/zum/repo eine Packages.xml-Datei generieren. Diese Repository-URL kann dann in der OTOBO-SysConfig unter Package::RepositoryList hinterlegt werden, sodass OTOBO-Instanzen direkt von dort Pakete beziehen können. Für eine breitere öffentliche Verteilung ist die Plattform OTOpar eine hervorragende Option. Dort können Sie Ihr .opm-Paket hochladen, um es der gesamten OTOBO-Community zugänglich zu machen, was die Installation für andere Nutzer erheblich vereinfacht.

Quellen:

Welche Best Practices sollte ich bei der Entwicklung von OTOBO-Plugins beachten?

Für die Entwicklung robuster und wartbarer OTOBO-Plugins sollten einige Best Practices beachtet werden. Es ist entscheidend, die Versionsnummer in der .sopm-Datei gemäß Semantic Versioning anzupassen, um Kompatibilität und Änderungen klar zu kommunizieren. Bei Datenbankintegrationen sind DB-Migrationen in sql/-Skripten sauber zu versionieren, um Updates reibungslos zu gestalten. Das Schreiben von Unit-Tests für Ihre Kernel::System::- und Kernel::Modules::-Klassen sichert die Code-Qualität und erleichtert Refactorings. Eine umfassende Dokumentation im README.md des Projekts sowie im POD-Format innerhalb der Perl-Module ist unerlässlich für andere Entwickler und zukünftige Wartung. Nicht zuletzt sollten Übersetzungen in Language/de_*.pm und en_*.pm von Anfang an berücksichtigt werden, um die internationale Nutzbarkeit des Plugins zu gewährleisten.

Quellen: