Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.enneo.ai/llms.txt

Use this file to discover all available pages before exploring further.

Enneo lässt sich an vielen Stellen mit kundeneigenem Code erweitern. Damit können Umsysteme angebunden, Geschäftslogik abgebildet und Automatisierungen umgesetzt werden, ohne die Plattform selbst zu verändern.

​
Wo eigener Code in Enneo eingesetzt wird

Eigener Code wird in Enneo immer als sogenannter Executor hinterlegt und an verschiedenen Stellen referenziert. Typische Einsatzgebiete:
  • Kundenerkennung — Suche nach Vertragsnummer, Kundennummer, Attributen oder Freitext greift auf eigene Funktionen zurück, die Daten aus dem ERP oder anderen Quellsystemen laden.
  • Regelbasierte KI-Agenten — Die Business-Logik eines Agenten (z. B. Zählerstand erfassen, Adressänderung schreiben, Vertrag kündigen) ruft eigenen Code auf, um die eigentliche Aktion im Umsystem auszuführen.
  • KI-Tools für smarte KI-Agenten — Smarte (LLM-basierte) Agenten entscheiden während eines Gesprächs eigenständig, welches Tool sie aufrufen. Jedes benutzerdefinierte Tool (verwaltet unter KI-Anpassung → KI-Tools) ist ein Executor, der eine konkrete Aktion im Umsystem ausführt — z. B. get_tariff_offer, send_offer_by_email oder do_tariff_change.
  • Webhooks — Synchrone Aufrufe an Umsysteme, z. B. der Versand einer E-Mail per API. Fehler werden direkt an den Nutzer zurückgemeldet, der Ablauf wartet auf die Antwort.
  • Event-Hooks — Asynchrone Reaktionen auf Enneo-interne Events (Ticket erstellt, beantwortet, geschlossen, …), etwa um Daten zu exportieren oder andere Systeme zu informieren. Fehler werden im Event-Trace protokolliert, aber nicht direkt an den Nutzer surfaced.
  • User Defined Functions (UDFs) — Wiederverwendbare Code-Bausteine, die zentral verwaltet und von beliebigen anderen Stellen aufgerufen werden können.

​
Die zwei Ausführungsarten

Enneo unterstützt zwei Wege, eigenen Code auszuführen. Der Unterschied liegt nicht in der Komplexität des Codes, sondern darin, wer den Code hostet und betreibt — Enneo oder das Umsystem auf eigener Infrastruktur. In beiden Fällen werden Eingabe- und Ausgabedaten als JSON übergeben.

​
Hosting durch Enneo: Sandbox-Ausführung (Typ code)

Der Code wird direkt in Enneo hinterlegt und in der Enneo-Sandbox ausgeführt. Unterstützte Sprachen sind PHP, Python und Node.js. Innerhalb der Sandbox stehen das volle Enneo-SDK, beliebige Pakete (per Composer, pip, npm) und Zugriff auf Eingabeparameter, Speicherobjekte und alle Enneo-APIs zur Verfügung. Eingabe und Ausgabe sind JSON. Vorteile:
  • Keine eigene Server-Infrastruktur, kein Deployment, keine Erreichbarkeit von außen nötig.
  • Änderungen sind sofort wirksam, ohne Release-Prozess.
  • Direkter Zugriff auf das Enneo-SDK und auf Enneo-APIs.
Einschränkungen:
  • Keine Versionskontrolle (Git) und nur eingeschränktes Debugging.
  • Tests laufen nicht im üblichen CI-Setup der eigenen Codebasis.
Daher in der Praxis am besten für einfache, überschaubare Logik geeignet.

​
Hosting durch das Umsystem: Direkter API-Aufruf (Typ apiCall)

Der Code wird auf eigener Infrastruktur als HTTP-Endpunkt betrieben. Enneo schickt einen Request an die konfigurierte URL und arbeitet mit der Antwort weiter. Angegeben werden:
  • HTTP-Methode (GET, POST, PUT, PATCH, DELETE)
  • URL
  • HTTP-Header (Authentifizierungs-Header können auf Secrets verweisen)
Auch hier sind Eingabe und Ausgabe JSON: Bei GET und DELETE werden die Eingabeparameter automatisch als Query-String an die URL angehängt, bei POST, PUT und PATCH als JSON-Body übergeben. Die Antwort wird als JSON geparst und zurückgegeben. Vorteile:
  • Voller Kontrollumfang über Quellcode, Versionierung, Tests, Deployment und Monitoring.
  • Integration in bestehende interne Systeme und Tooling.
Einschränkungen:
  • Erfordert eine eigene, von Enneo aus erreichbare Server-Komponente.
  • Jede Änderung läuft durch den eigenen Release-Prozess.