> ## Documentation Index > Fetch the complete documentation index at: https://docs.m9tz.de/llms.txt > Use this file to discover all available pages before exploring further. # ERP- und Legacy-Systemintegration > Wie Abteilungsagenten über eine stabile Adapterschnittstelle mit Ihrem ERP oder anderen etablierten Back-Office-Systemen verbunden werden – ohne den Agenten an ein bestimmtes Produkt zu koppeln. Abteilungsagenten im M9TZ Agent Blueprint müssen mit Ihren zentralen Geschäftsdaten interagieren – Lagerbestände, Aufträge, Finanzdaten, Dokumente – ohne zu wissen, in welchem spezifischen System diese Daten vorgehalten werden. Das auf dieser Seite beschriebene Adaptermuster erklärt, wie diese Trennung erreicht wird. Diese Seite enthält keine Implementierungsdetails für einen bestimmten ERP- oder Back-Office-Konnektor. Die Konzeption und Entwicklung eines Konnektors für Ihr konkretes System ist Bestandteil eines kostenpflichtigen Beratungsmandats. Unter [Beratungsprozess](/de/consulting/engagement-model) erfahren Sie, wie diese Arbeit kalkuliert und durchgeführt wird. ## Das Problem: Kopplung von Agenten an Systeme Wenn ein Abteilungsagent Ihr ERP-System direkt aufruft – unter Verwendung der proprietären API, des Abfrageformats oder des Datenmodells dieses Systems – entsteht eine enge Kopplung zwischen dem Agenten und einem bestimmten Produkt. Wenn dieses Produkt aktualisiert wird, abgelöst wird oder in frühen Build-Phasen noch nicht verfügbar ist, funktioniert der Agent nicht mehr oder kann nicht getestet werden. Das Adaptermuster löst dieses Problem, indem es eine stabile, generische Schnittstelle zwischen dem Agenten und dem dahinterliegenden System platziert. ## Das Adaptermuster Die Schnittstelle definiert einen festen Satz von Operationen, die der Agent aufrufen darf. Der Adapter ist die Komponente, die diese generischen Aufrufe in das übersetzt, was Ihr tatsächliches Back-Office-System benötigt. ``` Abteilungsagent │ │ ruft eine generische Operation auf ▼ ┌─────────────────────────┐ │ Back-Office-Schnittstelle │ ← stabil, ändert sich nicht │ (abstrakter Vertrag) │ └─────────────────────────┘ │ │ erfüllt durch ▼ ┌─────────────────────────┐ │ Adapter │ ← austauschbar je Zielsystem │ (Implementierung) │ └─────────────────────────┘ │ │ kommuniziert mit ▼ Ihr ERP oder anderes etabliertes System ``` Der Agent kommuniziert ausschließlich mit der Schnittstelle. Wenn das Zielsystem wechselt, wird der Adapter ausgetauscht. Die SOPs und Nachrichtenverträge des Agenten bleiben davon unberührt. ## Generische Operationen der Schnittstelle Die Schnittstelle deckt die Operationen ab, die Abteilungsagenten typischerweise von einem Back-Office- oder ERP-System benötigen. Der genaue Operationssatz wird in der Designphase für Ihre spezifischen Workflows festgelegt; häufige Beispiele sind: | Operation | Funktion | | ---------------------------- | ---------------------------------------------------------------------------------------------------------- | | Bestand prüfen | Gibt die aktuelle Verfügbarkeit für einen bestimmten Artikel oder eine Artikelnummer zurück | | Bestand reservieren | Legt eine vorläufige Reservierung einer Menge für einen ausstehenden Auftrag an | | Reservierung aufheben | Storniert eine Reservierung, die nicht mehr benötigt wird | | Auftrag erstellen | Registriert einen neuen Auftragsdatensatz mit den zugehörigen Positionen | | Auftragsstatus aktualisieren | Bewegt einen Auftrag durch definierte Statusübergänge | | Dokument generieren | Erstellt einen strukturierten Beleg – Rechnung, Lieferschein oder ähnliches – zu einem bestehenden Auftrag | | Datensatz nachschlagen | Ruft einen benannten Datensatz (Kundenkonto, Artikel, Preisebene) anhand eines Bezeichners ab | Jede Operation empfängt einen JSON-Payload und gibt eine JSON-Antwort zurück. Der Agent erstellt die Anfrage, ruft die Schnittstelle auf und handelt auf Basis der Antwort – ohne zu wissen, ob der Adapter hinter der Schnittstelle mit einem etablierten ERP-Produkt, einem proprietären internen System oder einem lokalen Referenzdatenspeicher kommuniziert. ## Stufenweise Vorgehensweise: Mit einer Referenzimplementierung beginnen Der Blueprint folgt dem evolutionären Build-Grundsatz: So früh wie möglich ein funktionierendes System in den Test überführen und Platzhalterkomponenten erst dann durch Produktivkomponenten ersetzen, wenn der Workflow validiert und die Integration tatsächlich benötigt wird. Für die Back-Office-Integration bedeutet dies: In frühen Build- und Testphasen wird der Adapter durch einen einfachen internen Datenspeicher unterstützt – eine strukturierte Datei oder eine schlanke Datenbank unter Ihrer Kontrolle. Er antwortet auf jede Schnittstellenoperation und ermöglicht es, den vollständigen Agenten-Workflow end-to-end zu testen, ohne vom Zugang zu Ihrem Produktivsystem abhängig zu sein. Diese Referenzimplementierung ist weder ein Mock noch ein Stub – sie ist ein echter, funktionsfähiger Adapter, der denselben Schnittstellenvertrag erfüllt, den der Produktions-Adapter später ebenfalls erfüllen wird. Agenten in der Entwicklung interagieren damit genauso wie mit dem Produktivsystem. Führen Sie den vollständigen Abteilungsworkflow – Auftragsverarbeitung, Bestandsprüfungen, Dokumentgenerierung oder den jeweiligen Zielprozess – gegen die Referenzimplementierung durch. Stellen Sie sicher, dass die SOPs, Entscheidungsverzweigungen, Eskalationspfade und Nachrichtenausgaben des Agenten korrekt funktionieren, bevor ein Produktivsystem eingebunden wird. Sobald der Workflow validiert ist und das Unternehmen bereit ist, das Produktivsystem anzubinden, wird ein Produktions-Adapter für Ihr spezifisches ERP- oder Back-Office-System entwickelt. Dieser Adapter implementiert denselben Schnittstellenvertrag, den die Referenzimplementierung bereits erfüllt. Der Agentencode ändert sich dabei nicht. Nur der Adapter wird ausgetauscht. Die Referenzimplementierung wird in der Konfiguration des Agenten durch den Produktions-Adapter ersetzt. Der Agent ruft weiterhin dieselben Schnittstellenoperationen mit denselben JSON-Payloads auf. Der Adapter übernimmt die gesamte Übersetzung zum und vom Format des Zielsystems. Diese stufenweise Vorgehensweise entspricht dem übergeordneten Gestaltungsprinzip, das in der Einleitung beschrieben wird: inkrementell entwickeln, jede Stufe validieren und nicht in Produktivintegrationen investieren, bevor der davon abhängige Workflow belegt ist. ## Aufgaben des Adapters Der Adapter ist verantwortlich für alles, was für das Zielsystem spezifisch ist: * Authentifizierung und Sitzungsmanagement für das Zielsystem * Übersetzung generischer Schnittstellenoperationen in API-Aufrufe, Abfrageformate oder Dateiprotokolle des Zielsystems * Rückmapping des Antwortformats des Zielsystems in das standardisierte JSON-Antwortformat der Schnittstelle * Behandlung von Fehlern und Nichtverfügbarkeit des Zielsystems sowie deren Übermittlung als strukturierte Fehlerantworten, auf die der Agent reagieren kann (Wiederholung, Eskalation oder Protokollierung) Der Agent bekommt davon nichts mit. Aus seiner Perspektive ruft er eine Schnittstellenoperation auf und erhält eine strukturierte JSON-Antwort zurück. Ob diese Antwort von einem lokalen Referenzdatenspeicher oder einem Produktivsystem stammt, ist ein Implementierungsdetail, das vollständig im Verantwortungsbereich des Adapters liegt. ## Adapter für unterschiedliche Systeme austauschen Da die Schnittstelle stabil und generisch ist, kann derselbe Agent in verschiedenen Deployments mit unterschiedlichen Back-Office-Systemen arbeiten, indem er einen anderen Adapter verwendet. Abteilungsagent A in einer Organisation verweist seinen Adapter auf ein System. Dasselbe Agenten-Design, das für eine andere Organisation deployiert wird, verweist seinen Adapter auf ein anderes System. Die SOPs des Agenten ändern sich dabei nicht. Das bedeutet auch: Wenn Ihre Organisation ihr Back-Office-System künftig ablöst, wird ein neuer Adapter für das Nachfolgesystem entwickelt. Die Agenten, die auf Back-Office-Daten angewiesen sind, funktionieren ohne Neugestaltung weiter. ## Was diese Seite nicht abdeckt Diese Seite beschreibt ausschließlich das architektonische Muster. Sie enthält keine: * Verbindungsdetails, Zugangsdaten oder API-Spezifikationen für ein bestimmtes ERP- oder Back-Office-Produkt * Feld-Mapping-Schemata für das Datenmodell eines bestimmten Systems * Implementierungscode für einen Produktions-Adapter Diese Arbeiten sind individuell auf Ihre Umgebung zugeschnitten und werden im Rahmen des kostenpflichtigen Beratungsmandats erbracht. Unter [Beratungsprozess](/de/consulting/engagement-model) erfahren Sie, wie die Integrationsarbeit kalkuliert wird. Derselbe Adapteransatz angewendet auf Kundenstammdaten – Kontakte, Fälle und Historie – als separate, klar abgegrenzte Datendomäne. Wie das Beratungsmandat strukturiert ist, einschließlich der Kalkulation und Durchführung individueller Integrationsarbeiten.