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	Nachrichtenart, Partnerprofil, Übertragungsweg und Mapping 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.

Workspace dokumentiert EDI/EDIFACT hier als projektbezogene Integrationsanforderung. Das bedeutet: Die Nachrichtenart, das Partnerprofil, der Übertragungsweg, das Mapping und das Fehlerverhalten müssen vor der Umsetzung geklärt werden. Diese Seite ist keine Zusage für einen fertigen nativen EDIFACT-Connector.

Typische EDIFACT-Nachrichten:

Nachricht	Typischer Zweck	Relevante Workspace-Bereiche
`PRICAT`	Preis- und Produktkatalog	PIM, Preislisten, Lieferantenpreislisten, Katalogpflege
`ORDERS`	Bestellung	Beschaffung, Verkauf, Aufträge
`ORDRSP`	Bestellantwort	Beschaffung, Lieferantenkommunikation, Auftragsstatus
`ORDCHG`	Bestelländerung	Beschaffung, Auftragsänderungen, Nacharbeit
`DESADV`	Lieferavis oder Versandavis	Wareneingang, Warenausgang, Versand, Lager
`RECADV`	Wareneingangs- oder Empfangsbestätigung	Wareneingang, Lieferprüfung, Abgleich
`INVOIC`	Rechnung	Eingangsrechnung, Ausgangsrechnung, Buchhaltungskontext
`INVRPT`	Bestandsbericht	Lager, Bestand, Verfügbarkeit
`SLSRPT`	Verkaufsbericht	Verkauf, Reporting, Commerce-Auswertung
`DELFOR`	Lieferabruf oder Lieferprognose	Beschaffung, Lieferplanung, Produktion
`DELJIT`	Feinabruf oder Just-in-Time-Lieferabruf	Beschaffung, Logistik, Produktion
`REMADV`	Zahlungsavis	Zahlungsabgleich, Buchhaltungskontext
`APERAK`	Anwendungsfehler- oder Empfangsmeldung	Fehlernacharbeit, Monitoring
`CONTRL`	Syntax- und Empfangsbestätigung	Technische Verarbeitung, Fehlerprüfung

Wenn Sie DESADB meinen, prüfen Sie bitte die konkrete Partnerdokumentation. Für Lieferavise ist in EDIFACT typischerweise DESADV gebräuchlich.

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?
Welcher Übertragungsweg gilt, zum Beispiel SFTP, AS2, API-Gateway oder Middleware?
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 EDIFACT-Nachrichten.	Sammeln Sie Nachrichtentyp, Version, Partnerprofil, Übertragungsweg und Beispieldateien.
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.