Geschäftspartner tauschen EDI-Dokumente aus? Integration Account und B2B-Workflow erstellen

EDI (Electronic Data Interchange) ermöglicht Unternehmen den Austausch strukturierter Geschäftsdokumente, die ihre Systeme automatisch verarbeiten können. Ein Käufer sendet eine Bestellung in einem vereinbarten Format. Das System des Lieferanten liest sie ein, ohne dass jemand Daten aus einer E-Mail oder PDF-Datei übertragen muss. X12 und EDIFACT sind verbreitete EDI-Standards.

In diesem Lab sendet CTBuyer eine X12-850-Bestellung an CloudTrips. Der Workflow wandelt den EDI-Text in XML um. Zum Testen verwenden wir direkt HTTPS; AS2-Transport, Zertifikate und ein echtes Partnersystem sind nicht erforderlich.

Bestandteil	Aufgabe im Lab
Integration Account	Speichert wiederverwendbare B2B-Definitionen
Partner	Identifizieren Käufer und Lieferanten
Vereinbarung	Definiert den Austausch und die Validierung von X12-Nachrichten zwischen den Partnern
Schema	Beschreibt Struktur und Felder der Bestellung
Logic App	Empfängt das Dokument und führt den Decoder aus

Der Integration Account speichert die Konfiguration; die Logic App führt den Workflow aus. Wir verwenden eine neue Consumption-App. Der kostenpflichtige Standard-Hostingplan aus dem vorherigen Trip wird nicht benötigt.

Integration Account erstellen

Suche im Azure-Portal nach Integration accounts → Create:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-b2b-test-weu
Integration account name: ia-ctb2b-weu
Region: West Europe
Pricing tier: Free

Der Free-Tarif ist für Entwicklung und Tests gedacht, hat begrenzte Artefaktzahlen und bietet kein Produktions-SLA. Für diese zwei Partner, eine Vereinbarung und ein Schema reicht er aus. Workflowoperationen werden weiterhin separat abgerechnet. Falls Free nicht verfügbar ist, weil du in dieser Region bereits ein kostenloses Konto hast, verwende dieses für das Lab, statt unbeabsichtigt einen kostenpflichtigen Tarif anzulegen.

Schema und Partner hinzufügen

Lade Microsofts EDI-Schemaarchiv herunter und entpacke es. Das große ZIP enthält viele Dokumentdefinitionen; du benötigst nur:

MicrosoftEdiXSDTemplates/X12/00401/X12_00401_850.xsd

Du musst weder ein SDK noch Visual Studio oder BizTalk installieren. Öffne im Integration Account Settings → Schemas → Add. Verwende den Namen X12_00401_850, wähle Small file und lade diese XSD-Datei hoch. Der Name steht für X12, Version 4010, Dokumenttyp 850 (Bestellung).

Öffne Settings → Partners → Add und erstelle diese beiden Einträge. Wähle für beide den X12-Qualifier ZZ – Mutually Defined, teilweise als Mutually Defined (X12) angezeigt:

Partnername	Qualifier	Wert der Geschäftsidentität
CloudTrips	ZZ	CLOUDTRIPS
CTBuyer	ZZ	CTBUYER

Übernimm die Identitätswerte genau so, ohne auffüllende Leerzeichen. Dies sind vereinbarte Geschäftskennungen, keine Azure-Anmeldekonten oder Passwörter.

X12-Vereinbarung erstellen

Öffne Settings → Agreements → Add:

Name: agr-ctbuyer-cloudtrips-x12
Agreement type: X12
Host partner: CloudTrips
Host identity: ZZ / CLOUDTRIPS
Guest partner: CTBuyer
Guest identity: ZZ / CTBUYER

Der Host ist unsere Organisation. Konfiguriere Receive settings, also die Richtung CTBuyer → CloudTrips. Füge unter Schemas hinzu:

Version: 00401
Transaction Type (ST01): 850
Sender Application (GS02): CTBUYER
Schema: X12_00401_850

Die Schemaversion lautet 00401; der Gruppenheader der Beispieldatei verwendet 004010. Übernimm beide Werte wie angegeben.

Prüfe beziehungsweise setze für diese Empfangsrichtung:

Einstellung	Wert im Lab
Authorization qualifier (ISA1) / Security qualifier (ISA3)	00 / 00
ISA11 usage	Standard Identifier
TA1 Expected / FA Expected	Off / Off
Disallow interchange, group, and transaction-set control number duplicates	Off für wiederholbare Tests
Default EDI Validation	On
Trailing Separator Policy	Optional
Interchange processing	Split Interchange as transaction sets – suspend transaction sets on error

Behalte die übrigen Standardeinstellungen bei und speichere. Da wir in diesem Lab nur empfangen, sind keine angepassten Send settings erforderlich. Die Duplikatprüfung ist ausgeschaltet, damit du dieselbe Beispieldatei erneut senden kannst. In einer Produktionsvereinbarung sollte der Umgang mit Duplikaten bewusst festgelegt werden. Dieser erste Workflow erzeugt auch noch keine EDI-Empfangsbestätigungen.

Logic App erstellen und verknüpfen

Erstelle eine Logic App → Consumption:

Resource group: rg-cloudtrips-b2b-test-weu
Logic App name: la-ctb2b-receive-weu
Region: West Europe
Plan type: Consumption

Verwende dieselbe Subscription und Region wie beim Integration Account. Die optionale Log-Analytics-Anbindung wird für dieses Lab nicht benötigt.

Öffne die Logic App → Settings → Workflow settings → Integration account. Wähle ia-ctb2b-weu und speichere. Öffne den Designer nach der Verknüpfung erneut.

Request → Decode → Response aufbauen

Beginne im Logic app designer mit einem leeren Workflow. Füge Request → When an HTTP request is received hinzu, setze Method: POST und lasse Request Body JSON Schema leer: Der eingehende Inhalt ist EDI-Text, kein JSON.

Decode X12 message ist eine Aktion. Wähle unter dem Request-Trigger + → Add an action, suche nach X12 und wähle Decode X12 message. Erstelle bei entsprechender Aufforderung eine Verbindung:

Connection name: x12-ctb2b
Integration Account ID: die Ressourcen-ID von ia-ctb2b-weu
Integration Account SAS URL: die generierte Callback-URL dieses Kontos

Die ID findest du im Integration Account unter Overview → JSON View. Die SAS-URL findest du unter Settings → Callback URL. Kopiere die vollständigen Werte in das Verbindungsformular. Die SAS-URL gewährt Zugriff auf das Konto; halte sie aus Screenshots heraus.

Wähle bei X12 flat file message to decode den dynamischen Inhalt Body des Request-Triggers. Der Decoder ermittelt die Vereinbarung anhand von Absender und Empfänger in der Nachricht.

Füge nach Decode Request → Response hinzu:

Status Code: 200
Headers:
  Content-Type: application/json
Body: Body aus Decode X12 message als dynamischen Inhalt auswählen

Wähle den gesamten Body des Decoders, nicht den Triggerinhalt oder das GoodMessages-Array. Lasse die asynchrone Antwort deaktiviert und behalte das standardmäßige Run-after-Verhalten bei: Die Antwort folgt auf einen erfolgreichen Decode-Schritt. Speichere und kopiere die generierte HTTP POST URL des Request-Triggers. Auch diese signierte URL ist geheim; klappe ihre Einstellungen vor der Aufnahme des Designers zu.

Beispielbestellung senden

Lade cloudtrips-order-850.edi herunter. Die Datei enthält die Bestellung CT-11001 über zwei NOTEBOOK-Artikel zu jeweils 12,50.

Der ISA-Header identifiziert CTBUYER und CLOUDTRIPS. ST*850 kennzeichnet eine Bestellung, BEG enthält die Bestellnummer und PO1 die Bestellposition. * trennt Felder und ~ beendet Segmente. Verändere die Datei nicht: Die Leerzeichen im ISA-Header sind wichtig.

Öffne Azure Cloud Shell → Bash und lade die heruntergeladene Datei über Manage files → Upload hoch. Führe anschließend aus:

read -r -s -p 'Paste the HTTP POST URL, then press Enter: ' ct_edi_url
printf '\n'

curl --include --max-time 90 \
  --request POST "$ct_edi_url" \
  --header 'Content-Type: text/plain' \
  --data-binary @cloudtrips-order-850.edi

unset ct_edi_url

Die Antwort enthält das Decoderergebnis. HTTP 200 bestätigt lediglich, dass die Response-Aktion ausgeführt wurde. Prüfe, dass GoodMessages genau eine Nachricht enthält und BadMessages leer ist. Als Vereinbarung sollte agr-ctbuyer-cloudtrips-x12 angegeben sein.

Decodiertes Dokument prüfen

Öffne in der Logic App unter Overview → Runs history die neueste Ausführung. Erweitere Decode X12 message → Outputs und prüfe die akzeptierte Nachricht unter GoodMessages. Prüfe Absender, Empfänger, Vereinbarungsname und die Transaktionskontrollnummer 0001. Ihr Payload enthält das decodierte XML, das der Connector in der JSON-Ausgabe als Base64-Text darstellen kann. Diese Darstellung ist weder ein Fehler noch eine Verschlüsselung. Entscheidend sind hier ein Eintrag in GoodMessages und keine Einträge in BadMessages.

Wird keine Vereinbarung gefunden, vergleiche die Identitäten ZZ / CTBUYER → ZZ / CLOUDTRIPS und prüfe die Empfangsrichtung. Bei unbekanntem Dokumenttyp kontrolliere das hochgeladene Schema und die Schemazeile 00401 / 850 / CTBUYER. Enthält BadMessages einen Eintrag, prüfe dessen Exception, bevor du den Lauf als erfolgreich betrachtest. Schlägt der Decoder selbst fehl und läuft die HTTP-Anfrage in einen Timeout, öffne die fehlgeschlagene Aktion im Ausführungsverlauf.

Du hast eine EDI-Bestellung empfangen und decodiert. Eine echte Integration würde das XML anschließend in ein internes Bestellformat überführen, speichern und die vereinbarten Bestätigungs- und Transportverfahren umsetzen.

Abschluss

Lösche rg-cloudtrips-b2b-test-weu, wenn du fertig bist. Die Gruppe enthält Labkonto, Logic App und API-Verbindung. Falls du einen bestehenden Integration Account außerhalb dieser Gruppe wiederverwendet hast, behalte das gemeinsame Konto und entferne nur die nicht mehr benötigte Vereinbarung, Partner und das Schema dieses Labs.