Zum Hauptinhalt springen

ERP- und API-Integrationen

ERP-Verbindungen brauchen einen vereinbarten Vertrag: Quellsystem, Kennungen, Felder, Einheiten, Statuszuordnung, Datenverantwortung, Aktionen und Wiederherstellung. Eine generische ERP-Karte beweist keine Kompatibilität mit deiner ERP-Version.

PostgreSQL-Auftragsbuch​

Der kuratierte Connector unterstützt das geprüfte Auftragsbuchschema mit Erstellungsauslöser, Abschlussfunktion und Ergebnistabellen. Er liest nicht beliebige PostgreSQL-Datenbanken.

  1. Lass den Quellsystemverantwortlichen das geprüfte Schema und einen begrenzten Datenbankbenutzer bereitstellen.
  2. Konfiguriere Host, Port, Datenbank, Benutzername und Passwort im Studio. Der verwaltete Worker muss die Quelldatenbank erreichen können.
  3. Teste die Verbindung. Der Test prüft das Schema ohne Änderungen.
  4. Prüfe Objektfelder, Ereigniszuordnungen, Arbeitsplatzcodes und Rechte und veröffentliche.
  5. Erstelle danach einen erlaubten Testauftrag. Historische Aufträge werden nicht automatisch importiert.
  6. Prüfe den empfangenen Auftragsbuchdatensatz und nutze den Auftragseingang, um Fertigung vorzubereiten.
  7. Prüfe die Fertigmeldung, ihren Beleg und den Quellsystemzustand.

Optionale Fertigungsdetails verwenden die geprüften Zusatzfelder und Arbeitsplanstrukturen. Der Arbeitsplan ist eine geordnete Folge von Arbeitsgängen. Arbeitsplatzcodes müssen im Ziel auflösbar sein. Kläre fehlende Konfiguration vor der Umwandlung in Produktion.

Andere HTTPS-Aktionen​

Ein Verbindungsersteller definiert festes Ziel, Zugangsdaten, typisierte Aktionen, Anfragezuordnung, Ergebnisfelder und Belegabgleich. Speichere, teste, prüfe und veröffentliche die passende Version. Apps, Abläufe und Konnie nutzen dieselben Aktionen mit aktuellen Rechten.

Prüfe zuerst mit einer Leseaktion Identität und Quellfelder. Prüfe vor einer Änderung Objekt, Ziel, Eingaben und externe Wirkung. Eine Genehmigung ist an diesen Auftrag gebunden. Geänderte Eingaben erfordern eine neue geeignete Prüfung. Der Belegabruf klärt verlorene Antworten. Ein unklarer Ausgang darf keine automatische zweite Änderung auslösen.

Der gemeinsame Aktionstransport nutzt begrenzte öffentliche HTTPS-JSON-Endpunkte. Beliebige Adressen, Weiterleitungen, private Netze über diesen Transport und unbegrenzte Daten sind nicht unterstützt. Verwaltete Connector-Worker haben eigene geprüfte Verbindungsanforderungen.

Authentifizierung und Datenverantwortung​

Nutze die konfigurierte Dienst- oder Integrationsidentität. Browsersitzungen, Edge-Zugangsdaten, Worker-Zugangsdaten und externe Agentenfreigaben unterscheiden sich. Verwende kein Browser-Token dauerhaft für ein ERP.

Eine externe Kennung ist keine Ennea-Datensatzkennung. Bewahre beide auf, definiere die Zuordnung und lege die maßgebliche Quelle je Feld fest. Beobachtungen zeigen, was ein externes System gemeldet hat. Sie überschreiben nicht automatisch Stammdaten.

Fehler abgleichen​

  • Validierung: Schema, Einheiten, Referenzen und Statuszuordnung korrigieren.
  • Berechtigungsfehler: Identität und genauen Bereich prüfen.
  • Offene Genehmigung: passende Prüfung vor Folgeaktionen abschließen.
  • Unklare Änderung: ursprünglichen Beleg und Ziel prüfen; Ausführungsidentität bewahren.
  • Teilimport: erfolgreiche Datensätze vor erneuter Ausführung abgleichen.

Interne REST-Routen sind keine Zusage eines universellen öffentlichen API-Schemas oder einer Versionsrichtlinie. Vereinbare einen unterstützten Vertrag mit deinem Implementierungskontakt. Siehe Externe Agenten und Importe.

Nutze den PostgreSQL-Auftragsbuch-Vertrag für herunterladbares DDL, genaue Felder, fiktiven Quellauftrag und erwartete Belege.