Das Modul verwaltet die gesamte Menge externer Verbindungen, von denen ein modernes Unternehmen abhängt. Es bietet vollständige Lebenszyklussteuerung über API-Connectors hinweg, die REST, SOAP und GraphQL umfassen, jeweils mit eigenem Authentifizierungsschema, Basis-Endpunkten, Headern, Wiederholungsrichtlinie und Ratenbegrenzungen. Es konfiguriert Model-Context-Protocol-Server, die Tools und Ressourcen für die KI-Schicht der Suite bereitstellen, und es hält die aus- und eingehende E-Mail-Konfiguration vor, sowohl SMTP für die Zustellung als auch IMAP für den Abruf, die Benachrichtigungen, Berichte und Kampagnenverkehr transportiert.

Über einzelne Connectors hinaus betreibt es die Bewegung von Daten in großem Umfang. ETL- und ELT-Pipelines extrahieren aus Quellsystemen, wenden deklarative Transformationsregeln an und laden in die Suite, oder sie legen Rohdaten zunächst ab und transformieren an Ort und Stelle, wenn der Zielspeicher für diese Aufgabe besser geeignet ist. Es betreibt EDI mit Handelspartnern, unterhält Connectors zu Content-Plattformen wie WordPress, Sitecore, Adobe AEM, Drupal und Umbraco und integriert Kunden- und Identitätssysteme. Geplante Synchronisation, Delta-Erkennung, Dead-Letter-Fehlerwarteschlangen und Replay vervollständigen das Bild, sodass Verbindungen nicht nur definiert, sondern kontinuierlich und beobachtbar betrieben werden.

Im Zentrum der Domäne steht die Idee einer Verbindung: eine dauerhafte, benannte Beziehung zu einem externen System. Eine Verbindung trägt alles, was nötig ist, um dieses System zu erreichen und ihm zu vertrauen, ihre Endpunkte, ihr Authentifizierungsmaterial und ihre Verhaltenseinstellungen, gehalten als strukturierte Konfiguration und typisiert nach der Art des Systems, das sie repräsentiert, sei es eine API, eine Content-Plattform, ein Identity Provider, ein Mailserver oder ein Banking-Kanal. Geheimnisse, die zu einer Verbindung gehören, werden getrennt von der gewöhnlichen Konfiguration gehalten und im Ruhezustand verschlüsselt, sodass Zugangsdaten niemals mit den beschreibenden Feldern reisen, die Administratoren routinemäßig bearbeiten.

Eine Verbindung erhält ihre Bedeutung durch eine Pipeline, die Definition, wie sich Daten über sie bewegen: welche Ressource gelesen oder geschrieben wird, in welche Richtung, nach welchem Zeitplan und unter welchem Mapping. Eine Pipeline verweist auf eine oder mehrere Transformationsregeln, die deklarative Logik, die fremde Datensätze in das Vokabular der Suite und wieder zurück umformt und dabei Feldnamen, Formate, Codelisten und Einheiten auflöst. Jedes Mal, wenn eine Pipeline läuft, erzeugt sie einen Laufdatensatz, der festhält, was versucht wurde, was gelang und was nicht, und jeder Datensatz, der nicht verarbeitet werden kann, wird in einer Fehlerwarteschlange beiseitegelegt, mit vollständig erhaltenem Kontext für Prüfung, Korrektur und Replay. Zusammen erlauben diese Konzepte einem Administrator, über Integrationen in geschäftlichen Begriffen nachzudenken: was verbunden ist, was fließt, wie es übersetzt wird und was beim letzten Lauf geschah.

Die Registrierung einer Verbindung ist der erste Workflow. Ein Administrator wählt den Typ des Systems, gibt dessen Endpunkte und Zugangsdaten an, wählt ein Authentifizierungsschema und validiert die Verbindung mit einem Live-Test, der Erreichbarkeit und Autorisierung bestätigt, bevor die Verbindung gespeichert wird. Von dort aus bindet der Aufbau einer Pipeline diese Verbindung an eine konkrete Datenbewegung: Auswahl der Ressource, der Richtung, des Mappings und des Zeitplans, gefolgt von einem Probelauf gegen ein Beispiel, um zu bestätigen, dass die Transformation die erwartete Form erzeugt.

Sobald sie live sind, laufen Pipelines nach ihrem Zeitplan oder auf Abruf. Jede Ausführung wird in Echtzeit überwacht, wobei Durchsatz, Latenz und Erfolgsraten auf dem Hub sichtbar werden. Wenn Datensätze die Validierung nicht bestehen oder ein nachgelagertes System sie ablehnt, sammeln sie sich in der Fehlerwarteschlange an, wo ein Operator die betreffende Payload untersuchen, ein Mapping oder die Quelldaten anpassen und die betroffenen Datensätze erneut abspielen kann, ohne den gesamten Batch neu auszuführen. Das Rotieren von Zugangsdaten, das Überarbeiten einer Transformationsregel oder das Pausieren eines Partner-Feeds sind allesamt gleichrangige Operationen, und jede einzelne von ihnen wird protokolliert, sodass der Zustand jeder Integration zu jedem vergangenen Zeitpunkt rekonstruiert werden kann.

Die Authentifizierungsabdeckung des Moduls ist bewusst breit angelegt, denn Integration scheitert am häufigsten an der Vertrauensgrenze. Es verarbeitet API-Schlüssel, Bearer-Token, HTTP-Basic-Zugangsdaten und den vollständigen Satz an OAuth-2.0-Grants, einschließlich Client Credentials für Service-zu-Service-Aufrufe und Authorization-Code-Flows für delegierten Zugriff, mit automatischer Token-Erneuerung und Ablaufbehandlung. Für die Identitätsföderation konfiguriert es SAML 2.0 mit Entity-Identifiern, Sign-on- und Single-Logout-Endpunkten, Name-Identifier-Formaten und X.509-Signaturzertifikaten; OpenID Connect und generisches OAuth 2.0 mit Discovery, Scopes und Redirect-Handling; sowie Verzeichnisanbindung über LDAP und Active Directory mit Base Distinguished Names, Benutzer- und Gruppenfiltern und TLS. Just-in-Time-Provisioning und Account-Verknüpfung übersetzen einen föderierten Login in einen geregelten Benutzer innerhalb der Suite, und föderiertes Logout schließt die Sitzung sauber beim Provider.

Die Tiefe der Datenbewegung ist ebenso durchdacht. Content-Connectors sprechen den nativen Vertrag jeder Plattform, die WordPress REST API, die Item- und GraphQL-Dienste von Sitecore, die Adobe AEM Content Fragment API, Drupal JSON:API und die Umbraco Delivery API, jeweils mit dem korrekten Authentifizierungsidiom. Die Banking-Konnektivität deckt PSD2-, EBICS- und SWIFT-Kanäle ab, ruft Kontoauszüge ab und steuert das Parsing zum Standard CAMT.053, sodass die vorgelagerte Abstimmung saubere, strukturierte Transaktionen erhält. EDI wendet Standard-Dokumentformate und partnerspezifische Umschläge an. Durchgängig erzwingen Transformationsregeln Datentyp-Konvertierung, Codelisten-Übersetzung, Währungs- und Einheitennormalisierung sowie referenzielle Validierung, und die Steuerungen für Retry, Back-off und Dead-Letter stellen sicher, dass ein vorübergehender Ausfall kontrolliert abgefangen wird, statt Daten zu verlieren.

Connector & API Management ist der Rand der gesamten Plattform, und nahezu jedes andere Modul erreicht die Außenwelt darüber. Es arbeitet am engsten mit der Systemadministration zusammen, deren Teil es ist, und stützt sich auf das Rollen- und Berechtigungsmodell der Suite, sodass nur autorisierte Administratoren eine Verbindung und ihre Geheimnisse einsehen oder ändern können. Es übergibt Model-Context-Protocol-Serverdefinitionen an das AI Management, das steuert, wie die AI Workers der Suite externe Tools entdecken und nutzen. Es versorgt das Content Management mit den Live-Connectors, die zu externen Content-Plattformen veröffentlichen und aus ihnen abrufen, und es liefert strukturierte Auszugsdaten an Accounting & Control, wo der CAMT.053-Parser und die Abstimmungsroutinen die von diesem Modul geplanten Banking-Feeds verarbeiten.

Kunden- und Identitätsintegrationen speisen die CRM- und Zugriffsschichten der Suite, sodass Kontakte, Accounts und authentifizierte Benutzer aus Systems of Record stammen und mit ihnen im Gleichschritt bleiben. Die Mail-Konfiguration untermauert die Benachrichtigungs- und Berichtsdienste, auf die sich viele Module verlassen, um Menschen zu erreichen. Weil jede Verbindung zentral registriert ist, konsumiert der Rest der Suite Integrationen per Referenz, statt eigene Zugangsdaten einzubetten, was die gesamte externe Fläche des Unternehmens von einer Stelle aus inventarisiert, berechtigt und beobachtbar hält.

AI Workers sind in diesem Modul gleichrangige Operatoren, keine Zuschauer. Ein Administrator kann in natürlicher Sprache fragen, welche Connectors über Nacht ausgefallen sind, wie sich eine bestimmte Pipeline entwickelt hat oder welcher Partner-Feed hinter dem Zeitplan liegt, und der Worker antwortet direkt aus Laufdatensätzen und dem Warteschlangenzustand. Workers führen Aktionen im Rahmen ihrer erteilten Berechtigungen aus: das Auslösen einer Synchronisation, das erneute Abspielen eines Batches fehlgeschlagener Datensätze nach einer Mapping-Korrektur, das planmäßige Rotieren von Zugangsdaten oder das Pausieren einer sich fehlerhaft verhaltenden Verbindung.

Sie achten kontinuierlich auf Anomalien und Ausnahmen, melden einen Anstieg der Fehlerwarteschlangentiefe, einen plötzlichen Rückgang des Durchsatzes, ein Authentifizierungs-Token kurz vor Ablauf oder einen Partner, dessen Zustellungstakt ins Rutschen geraten ist, und sie heben diese als Warnungen hervor, bevor ein Mensch sie bemerken würde. Wenn eine fremde Payload in unbekannter Form eintrifft, extrahiert und strukturiert ein Worker deren Felder und schlägt ein Transformations-Mapping vor, was aus einer Prüfaufgabe eine Durchsicht macht. Workers bieten Entscheidungsunterstützung, indem sie erklären, warum Datensätze abgelehnt wurden, und die korrigierende Regeländerung empfehlen. Wo die Governance es erfordert, nimmt ein Worker als Genehmigungs- oder Prüfknoten an den eigenen Workflows des Moduls teil, gibt eine neue Verbindung zu einem sensiblen System oder eine Änderung an einer Produktions-Pipeline frei, bevor sie wirksam wird, wobei sein Urteil im selben Audit-Trail wie jede menschliche Handlung festgehalten wird.