Datenaustausch für Integrationen

Nutzen Sie diese Seite, wenn Sie klären möchten, über welche Formate, Schnittstellen oder Dateien Workspace mit bestehenden Systemen Daten austauschen soll. Starten Sie fachlich: Welche Daten sollen fließen, welches System ist führend und wie sollen Fehler sichtbar werden?

Nicht jeder Eintrag auf dieser Seite ist ein fertiger Standardconnector. Einige Wege sind veröffentlichte Workspace-Verträge, andere sind projektbezogene Integrationsanforderungen, die vor der Umsetzung geprüft werden.

Geeigneten Weg wählen

Weg	Geeignet für	Einordnung
REST/JSON über Workspace-APIs	Eigene Clients, Middleware, Agenturen, laufende Synchronisation	Veröffentlichten API-, Discovery- und Ressourcen-Meta-Vertrag nutzen.
Import-Jobs	Einmalige oder wiederholte Datenübernahmen mit Prüfung	Dokumentierter Workspace-Vertrag für asynchrone Dateiimporte.
CSV oder andere Dateien	Systeme mit Exportfunktion, Altdaten, einfache Listen	Projektbezogenes Mapping, Prüfung und Fehlerreport festlegen.
XML	E-Rechnungen, Branchenformate, Lieferanten- oder ERP-Exporte	Schema, Profil, Pflichtfelder und Validierung pro Fall prüfen.
Storefront-Verträge	Öffentliche Shops, Portale, Produktkataloge, Checkout	Öffentliche Storefront-Endpunkte verwenden, keine internen Admin-Pfade.
OpenAPI-Analyse	Contract-Checks, DTO-Generierung, Privacy-Prüfung, Tests	Hilft bei technischer Analyse; ersetzt keine Runtime-Discovery.
Ereignisbasierte projektbezogene Anbindung	Folgeprozesse nach Statusänderungen, neuen Vorgängen oder Beständen	Idempotenz, Wiederholung, Fehlerreport und Drittanbietergrenzen im Projekt klären.
EDI/EDIFACT	Handel, Großhandel, Lieferanten, Logistik, ERP- und Warenwirtschaftsprozesse	Für `ORDERS`, `ORDRSP` und `APERAK` in D.96A oder D.25A sowie `CONTRL` als Syntax-Service-Nachricht den nativen B2B-Exchange-Vertrag nutzen; andere Nachrichten und Transporte projektbezogen prüfen.

REST, JSON und Workspace-APIs

Verwenden Sie REST/JSON, wenn ein Client oder eine Middleware Workspace regelmäßig lesen oder schreiben soll. Lesen Sie vor der Umsetzung zuerst die Discovery- und Ressourcen-Meta-Verträge. Dadurch erkennen Integrationen, welche Ressourcen, Felder, Aktionen und Fehlerantworten für den aktuellen Workspace veröffentlicht sind.

Startpunkte:

Dateien, CSV und Import-Jobs

Dateibasierter Datenaustausch passt, wenn ein System Daten exportieren kann oder wenn ein Bestand kontrolliert übernommen werden soll. Import-Jobs prüfen Dateien asynchron, liefern Zähler und verweisen auf strukturierte Reports.

Nutzen Sie diesen Weg für geplante Datenpakete, nicht für ungeprüfte Direktänderungen an Stammdaten. Legen Sie vor dem Import fest:

welche Quelle führend ist,
welche Spalten oder Felder auf Workspace-Felder gemappt werden,
welche Konfliktstrategie gilt,
wer Fehlerlisten prüft,
ob der Lauf nur prüft oder Daten schreibt.

Details stehen in Import-Jobs.

XML und strukturierte Branchenformate

XML ist sinnvoll, wenn ein Quellsystem strukturierte Belege, Kataloge, Bestellungen oder Branchenformate liefert. XML allein reicht nicht als Integrationsvertrag. Entscheidend sind Profil, Schema, Pflichtfelder, Validierung, Zeichensatz, Nummernkreise, Einheiten und fachliche Bedeutung der Felder.

Beispiele:

E-Rechnungen oder buchhaltungsnahe Belege,
Lieferanten- oder Produktdaten,
ERP-Exporte,
Branchenformate mit eigenem XML-Schema.

Prüfen Sie bei XML immer, ob das Dokument nur archiviert, validiert, importiert oder in fachliche Workspace-Datensätze übersetzt werden soll.

EDI und EDIFACT

EDI beschreibt den strukturierten elektronischen Austausch zwischen Geschäftspartnern. EDIFACT ist eine verbreitete EDI-Standardfamilie für Handel, Logistik, Beschaffung, Lieferanten- und ERP-Prozesse.

Lesen Sie EDI/EDIFACT verstehen und einführen, wenn Sie Syntax, Verzeichnis, Partnerprofil, Mapping, Transport und Bestätigungen zuerst sauber voneinander abgrenzen möchten. Diese Seite ordnet EDI nur in die verfügbaren Integrationswege ein.

Workspace bietet einen nativen, bewusst begrenzten B2B-Exchange-Vertrag:

Richtung	Nachricht	Verzeichnisse	Transport
Eingehend	`ORDERS`	D.96A und D.25A	Partner-API oder SFTP
Ausgehend	`ORDRSP`	D.96A und D.25A	Partner-API-Mailbox oder SFTP
Anwendungsbestätigung	`APERAK` gemäß Profilrichtlinie	D.96A und D.25A	Partner-API-Mailbox oder SFTP
Syntax-Service-Bestätigung	`CONTRL` 2.2 bei Syntaxversion 3 oder `CONTRL` 4.1 bei Syntaxversion 4	keine Verzeichniszuordnung	Partner-API-Mailbox oder SFTP

Partner, Identifier, Verbindung, Commerce-Bindung und versioniertes Nachrichtenprofil legen die Zuordnung fest. Die Partner-API arbeitet idempotent und tenantgebunden; der SFTP-Ausgang prüft Hostkey, Zieladresse, Größe und Hash.

Für SFTP gilt ein eigener, fester Anmeldevertrag aus Store-UUID und tenantgebundenem API-Key. Konfigurieren Sie Benutzername, Passwort, Store, Scope und ACL ausschließlich nach SFTP-Eingang konfigurieren.

Lesen Sie B2B Exchange betreiben, wenn Sie den Vertrag einrichten oder überwachen. Implementieren Sie einen API-Partner gegen B2B-Exchange-Partner-API integrieren.

Weitere Nachrichten wie PRICAT, ORDCHG, DESADV, RECADV, INVOIC, INVRPT, SLSRPT, DELFOR, DELJIT oder REMADV gehören nicht zum aktuellen nativen Vertrag. Dasselbe gilt für AS2. Behandeln Sie solche Anforderungen als getrennten Integrationsscope und prüfen Sie Nachricht, Verzeichnis, Mapping, Übertragungsweg und Fehlerverhalten, bevor Sie eine Umsetzung zusagen.

Was vor EDI/EDIFACT geklärt werden muss

Klären Sie diese Punkte, bevor ein EDI-Projekt startet:

Welche Nachrichtentypen sollen verarbeitet werden?
Welche Version oder Branchendialekt gilt, zum Beispiel EANCOM oder ein partnerbezogenes EDIFACT-Profil?
Wer ist Sender, Empfänger und fachlich führendes System?
Ist Partner-API oder SFTP geeignet, oder verlangt der Partner einen noch nicht unterstützten Übertragungsweg wie AS2?
Werden Nachrichten nur importiert, auch erzeugt oder bidirektional abgeglichen?
Welche Identitäten verbinden Datensätze: GLN, EAN/GTIN, SKU, Lieferantenartikelnummer, Bestellnummer oder Belegnummer?
Welche Pflichtfelder, Einheiten, Währungen, Steuersätze und Nummernkreise gelten?
Wie werden Syntaxfehler, fachliche Fehler, Dubletten und Teilverarbeitungen sichtbar?
Wer prüft Testnachrichten und gibt das Mapping fachlich frei?

Entscheidungshilfe

Situation	Empfehlung
Sie bauen einen eigenen Client oder eine Middleware.	Starten Sie mit REST/JSON, Discovery und Ressourcen-Meta.
Sie übernehmen Datenpakete aus einem vorhandenen System.	Prüfen Sie Import-Jobs, CSV oder dateibasiertes Mapping.
Ein Partner liefert XML-Belege oder Branchenformate.	Klären Sie Profil, Schema, Validierung und fachliches Zielmodell.
Ein Handelspartner fordert `ORDERS`/`ORDRSP` in D.96A oder D.25A über API oder SFTP.	Nutzen Sie B2B Exchange und prüfen Sie Partnerprofil, Mapping und Beispieldateien.
Ein Handelspartner fordert andere EDIFACT-Nachrichten oder AS2.	Behandeln Sie die Anforderung als getrennten Integrationsscope ohne Zusage eines nativen Vertrags.
Sie brauchen öffentliche Shop- oder Portal-Daten.	Nutzen Sie Storefront-Verträge statt interner Admin- oder PIM-Pfade.
Sie kennen nur das Ziel, aber nicht den technischen Weg.	Starten Sie mit dem Connector-Katalog und halten Sie Datenrichtung, führendes System und Fehlerbearbeitung fest.

Nächste Schritte

Lesen Sie Integratoren, wenn Sie zuerst zwischen Integration, Migration und technischer Umsetzung unterscheiden möchten.
Prüfen Sie den Connector-Katalog, wenn ein konkretes System oder Format im Raum steht.
Nutzen Sie Import-Jobs, wenn eine Datei kontrolliert übernommen werden soll.
Lesen Sie Integration, wenn Sie eine technische API-Integration bauen.
Nutzen Sie B2B Exchange betreiben und B2B-Exchange-Partner-API integrieren für den nativen ORDERS/ORDRSP-Vertrag.
Beginnen Sie ein neues Partnerprojekt mit EDI/EDIFACT verstehen und einführen und EDIFACT-Partner einrichten.