EDIFACT-Partner einrichten

Dieser Quickstart führt Administratoren und Projektverantwortliche vom abgestimmten Partnervertrag bis zu einer abgenommenen ORDERS-/ORDRSP- Verbindung. Nach Abschluss kann der Partner eine Testbestellung über die gewählte Verbindung senden und die erwarteten Antworten eindeutig und nachweisbar empfangen.

Verwenden Sie den Quickstart nur für den nativen Vertrag: ORDERS, ORDRSP und optional CONTRL/APERAK in D.96A oder D.25A über Partner-API oder SFTP. Lesen Sie zuerst EDI/EDIFACT verstehen und einführen, wenn Verzeichnis, Syntaxversion oder Bestätigungstyp noch nicht feststehen.

Voraussetzungen prüfen

Sie benötigen:

• einen erreichbaren Workspace-Server und einen festgelegten Mandanten,
• Administratorrechte für B2B-Exchange-Partner, Identifier, Verbindungen, Profile, Commerce-Bindungen und Nachrichten,
• ein Unternehmen, einen Debitor, einen Vertriebskanal und ein Commerce-Profil für den Partner,
• freigegebene Käufer-, Verkäufer- und Artikelkennungen,
• mindestens eine gültige und eine erwartbar ungültige Testnachricht,
• bei API einen tenantfesten Partner-API-Key,
• bei SFTP einen dedizierten Eingangsspeicher sowie geprüfte Zugangsdaten und für den Ausgang den verifizierten Hostkey-Fingerprint des Partners.

Prüfen Sie Ihren Administrationskontext:

nucli --tenant <tenant> whoami
nucli --tenant <tenant> scopes
nucli --tenant <tenant> api GET /api/v1/b2b-exchange/partners --summary

Wenn diese Befehle noch nicht funktionieren, richten Sie den Client nach nucli ein. Sie benötigen dafür keinen besonderen „EDIFACT-Skill“: nucli bleibt der tenantgebundene HTTP-Client; der Server erzwingt Berechtigungen, Tenancy und Fachverträge.

1. Partnervereinbarung festhalten

Erstellen Sie vor jeder Konfiguration ein versioniertes Datenblatt. Tragen Sie nicht nur „EDIFACT“ ein, sondern den vollständigen Vertrag:

Speichern Sie freigegebene Beispieldateien unverändert. Berechnen Sie für jede Datei SHA-256 und dokumentieren Sie, zu welcher Version des Partnerprofils sie gehört.

2. Transport auswählen

Wählen Sie einen Transport als kanonischen Abnahmeweg. Ein zusätzlicher Transport benötigt eine eigene Connection und eine eigene Transportabnahme, ändert aber nicht automatisch das Mapping.

3. Stammdaten und Kennungen vorbereiten

Prüfen Sie vor der ersten Nachricht:

1. Der Käufer und Verkäufer sind über stabile Identifier unterscheidbar.
2. Jede erwartete Artikelreferenz löst genau einen aktiven Artikel im vereinbarten Commerce-Kontext auf.
3. Einheiten und Währung passen zum Commerce-Profil.
4. Liefer- und Rechnungsbezug sind fachlich geklärt.
5. Preise und Steuern werden nicht ungeprüft aus EDIFACT übernommen.

Nutzen Sie produktive Kennungen nicht in öffentlich geteilten Beispielen. Verwenden Sie für Tests ausdrücklich reservierte Demo-Kennungen, die in keinem anderen Partnervertrag aktiv sind.

4. Workspace-Vertrag als Entwurf anlegen

Legen Sie die Objekte in dieser Reihenfolge an und lassen Sie sie zunächst inaktiv beziehungsweise im Status draft:

Die vollständigen Feld-, Berechtigungs- und Verbindungsverträge stehen in B2B Exchange betreiben. Beachten Sie insbesondere:

• Das ORDERS-Profil ist inbound, das ORDRSP-Profil outbound.
• Die Commerce-Bindung verweist auf das eingehende ORDERS-Profil.
• D.96A verwendet im nativen Vertrag Syntaxversion 3, D.25A Syntaxversion 4.
• Aktivierte Revisionen sind unveränderlich. Änderungen erzeugen eine neue Revision.
• Eine aktive Verbindung bindet genau den vorgesehenen Partner und Transportkontext.

5. Mapping und Fixture-Nachweise prüfen

Erstellen Sie für jede Profilrevision reproduzierbare Nachweise:

Speichern Sie Eingabe und erwartetes Ergebnis als autorisierte Storage-Objekte. Geben Sie ihre tatsächlichen SHA-256-Hashes an. Starten Sie danach die Fixture-Prüfung über den Revisionsendpunkt. Ein gültiger Nachweis muss verificationStatus: "succeeded" erreichen. Ein erwarteter Ablehnungsfall ist nur erfolgreich, wenn der beobachtete stabile Fehlercode exakt dem erwarteten Code entspricht.

Eine Fixture-Prüfung beweist Mapping und Ausgabe für genau diese Revision. Sie beweist weder Transport, Produktstammdaten noch die Commerce-Anwendung.

6. Aktivieren und Pilot durchführen

Aktivieren Sie erst nach erfolgreicher Fixture-Prüfung:

1. Partner,
2. aktuelle ORDERS- und ORDRSP-Revisionen; damit werden die zugehörigen Profile aktiv,
3. genau passende Verbindung,
4. Commerce-Bindung.

Führen Sie anschließend mindestens diese Pilotfälle über den echten Abnahmetransport aus:

Nutzen Sie für API-Tests den Ablauf aus B2B-Exchange-Partner-API integrieren. Prüfen Sie für SFTP zusätzlich Hostkey, Zielpfad, atomare Veröffentlichung und die vereinbarte Verarbeitung eingehender Dateinamen.

7. Abnahme protokollieren

Dokumentieren Sie je Testfall:

• Partnerprofil- und Profilrevisionsnummer,
• Transport und Connection-ID,
• eigene Testfallreferenz,
• SHA-256 und Größe der gesendeten beziehungsweise empfangenen Bytes,
• Interchange- und Nachrichtenreferenz,
• Transport-, Syntax-, Mapping-, Anwendungs- und Bestätigungsstatus,
• fachliches Ergebnis und Freigabe durch beide Partner.

Schreiben Sie keine API-Keys, Passwörter, Claim-Tokens oder vollständigen Produktivnachrichten in das Abnahmeprotokoll.

Erfolg erkennen

Die Einrichtung ist abgeschlossen, wenn:

• alle aktiven Objekte zum richtigen Mandanten und Partner gehören,
• jede aktive Revision erfolgreiche positive und negative Fixture-Nachweise besitzt,
• der Pilot über den echten Transport durchgeführt wurde,
• ein Retry keine zweite Commerce-Wirkung erzeugt,
• CONTRL, APERAK und ORDRSP der vereinbarten Richtlinie folgen,
• beide Partner Bytes, Referenzen, Status und Eskalationsweg abgenommen haben, und
• Betrieb und Monitoring an eine verantwortliche Person übergeben sind.

Wechseln Sie danach zu B2B Exchange betreiben, um Status, Review, Retry und Fehlerbetrieb zu überwachen.