FAQ

Integrationen und Daten

Syncs, die leise scheitern, Bestellungen, die nie im ERP ankommen, Webhooks, API-Keys und Scopes, und Punchout.

Integrationen scheitern nicht laut. Sie scheitern an einem Dienstag, und Sie erfahren es am Donnerstag, wenn ein Käufer fragt, warum ein ausgelaufener Artikel noch im Verkauf ist. Die meisten Fragen unten drehen sich darum, es früher zu merken, und darum, die Quelle zu korrigieren statt die Kopie.

Der nächtliche Sync meldet Erfolg, aber nichts hat sich geändert.

Der Lauf, der mit nichts darin erfolgreich ist, ist der Fehler, der am meisten wehtut. Ein Quellsystem hat den Exportpfad geändert, der Feed hat eine leere Datei gelesen, null Datensätze gemeldet und ist grün durchgelaufen. Öffnen Sie Integration Studio › Ausführungen, lesen Sie die Datensatzzahl gegen die Vortage und schalten Sie am Workflow notify on empty result (bei leerem Ergebnis benachrichtigen) ein, damit das nie wieder ein Käufer entdeckt. Überwachen Sie erwartete Aktivität ebenso wie Fehler. Siehe Syncs überwachen.

Wo sehe ich nach, wenn das ERP eine Bestellung nicht bekommen hat?

Unter Integration Studio › Ausführungen, nach Zeit sortiert. Zeigt der Tab History der Bestellung das Platzierungs-Event und danach nichts, wurde die Bestellung korrekt aufgegeben, und das Problem liegt dahinter, in einem Lauf, der gescheitert ist oder nie begonnen hat. Eine tagealte Bestellung mit leerem acknowledged_at ist ein Integrationsalarm; bauen Sie eine tägliche Prüfung dafür. Siehe Syncs überwachen.

Der Sync scheitert mit 401 oder 403.

Die Zugangsdaten wurden rotiert, sind abgelaufen, oder das technische Konto auf der Gegenseite wurde deaktiviert, oft durch eine Passwortrotation, die es nicht ausgenommen hat. Erneuern Sie die Zugangsdaten an der Verbindung unter Integrations › Zugangsdaten und bitten Sie die Gegenseite, technische Konten von der Rotation auszunehmen. Eine abgelehnte Verbindung oder ein Timeout ist ihr Wartungsfenster oder Ihre Adressen, die nicht freigeschaltet sind. Siehe Häufige Sync-Fehler.

Jeder Lauf legt Datensätze neu an, und nichts wird aktualisiert.

Das Identifier-Format unterscheidet sich: eine führende Null, ein Präfix oder Groß- und Kleinschreibung. Jede Zeile sieht neu aus, also wird jede Zeile angelegt. Stoppen Sie den Lauf, statt ihn durchlaufen zu lassen, denn Dubletten mit Preisen und Bestellpositionen sind eine mühsame manuelle Zusammenführung. Normalisieren Sie den Identifier im Mapping und führen Sie dann zusammen oder entfernen Sie, was bereits angelegt wurde. Siehe Häufige Sync-Fehler.

Welches System soll welches Feld besitzen?

Genau eines, je Feld, schriftlich. Üblicherweise gehören dem ERP Artikelnummer, Gewicht, Steuerklasse, Bestand und fakturierte Preise; der Plattform alles, was ein Käufer liest, etwa Beschreibungen, Bilder und technische Attribute. Besitzt das ERP ein Feld und jemand bearbeitet es im Cockpit, überschreibt der nächste Sync die Änderung, und die Änderung sieht nach einem Fehler aus, obwohl die Regel arbeitet. Entscheiden Sie das, bevor Sie ein einziges Feld mappen. Siehe Das führende System festlegen.

Wie werde ich benachrichtigt, wenn ein Sync scheitert?

Am Workflow unter Integrations › Workflows schalten Sie notify on failure (bei Fehler benachrichtigen) an eine Gruppenadresse statt an eine persönliche ein, dazu notify on empty result und eine Warnung bei Stillstand, wenn im erwarteten Intervall kein erfolgreicher Lauf abgeschlossen wurde. Schicken Sie dann einen absichtlich fehlschlagenden Lauf durch die Kette und prüfen Sie, dass ein Mensch die Mail bekommt. Die Glocke in der Cockpit-Topbar ist ein Feed, kein Alarmsystem, und hat keine Einstellungen. Siehe Syncs überwachen.

Ein Webhook kommt bei unserem System nie an.

In der Reihenfolge, die am schnellsten auflöst: Ist das Event überhaupt passiert, sichtbar unter Events › Event-Stream; abonniert etwas dieses Topic, was der Abschnitt Routed to des Events beantwortet; ist das Ziel noch aktiv, denn ein dauerhaft scheiterndes Ziel wird automatisch deaktiviert; was sagen die Zustellversuche, wobei dauerhaftes 4xx Ihre Nutzlast und 5xx ihr System ist; und ist der Empfänger aus dem öffentlichen Internet überhaupt erreichbar. Siehe Häufige API-Probleme.

Die Webhook-Signatur passt nie.

Der Body wurde neu serialisiert, die mit Abstand häufigste Ursache: Die Signatur deckt die rohen Request-Bytes genau so ab, wie sie ankommen, und ein Framework, das das JSON parst und neu kodiert, verändert Leerzeichen oder Schlüsselreihenfolge. Sichern Sie den rohen Body vor jedem Parsen. Prüfen Sie dann, dass das Secret vom richtigen Ziel stammt, dass der Empfänger während einer Rotation jede von mehreren kommagetrennten Signaturen akzeptiert, und dass er hexadezimal vergleicht; Base64 passt nie. Siehe Webhooks einrichten.

Wie lege ich einen API-Key für unseren Integrator an, und mit welchen Scopes?

Einstellungen › API-Keys › Create API key. Benennen Sie ihn nach dem System, etwa erp-order-sync-prod, nie nach einer Person. Vergeben Sie Custom-Scopes in der Form resource.action, etwa orders.read oder inventories.write, und nur diese; ein ERP, das Bestellungen abholt und nie ändert, braucht orders.read. Setzen Sie kein Häkchen bei *. Das Secret erscheint einmal; fügen Sie es direkt in den Secret-Store des Integrators ein, nie in E-Mail oder Ticket. Testen Sie es dann mit einem GET, bevor jemand dagegen baut. Siehe API-Key anlegen.

Der Key liefert direkt nach dem Anlegen 401.

Die Kopie, nicht der Key. Lange Secrets werden von Chat-Clients, Tabellenzellen und Terminal-Umbrüchen abgeschnitten. Widerrufen und neu ausstellen statt debuggen; das dauert zwei Minuten. Die andere Ursache sind zwei Zugangsdaten auf einmal: Senden Sie entweder X-Revenexx-Api-Key oder Authorization: Bearer, nie beides. Ein 403 bei manchen Aufrufen und nicht bei anderen ist ein fehlender Scope, und die Meldung nennt ihn. Siehe Häufige API-Probleme.

Wir werden ständig gedrosselt.

Einzelne 429 heißen, dass das Backoff arbeitet. Ein stetiger Strom heißt, dass etwas falsch gebaut ist: ein Job, der eine Anfrage pro Artikel stellt statt eines Bulk-Aufrufs, zwei Integrationen, die um dasselbe Limit je Tenant konkurrieren, oder parallele Worker, die im Gleichschritt ohne Jitter wiederholen. Beachten Sie Retry-After, und verlegen Sie die Schleife pro Artikel in einen Bulk-Export. Siehe Rate-Limits, Kontingente und Fair Use.

Gibt es im Cockpit einen Punchout-Bildschirm?

Nein. Ein Punchout wird aus drei Teilen zusammengesetzt: einem Kanal vom Typ PunchOut unter Configuration › Kanäle mit Unassigned rows (nicht zugeordnete Zeilen) auf Hidden until assigned, Zugangsdaten unter Integrations › Zugangsdaten, und einem Connector oder Workflow, der den Rundlauf abwickelt und den Standard (OCI 4, OCI 5 oder cXML), den Kanal und die Kundenorganisation kennt. Die Bestellübermittlung ist eine eigene Nachricht neben dem Punchout und wird getrennt konfiguriert. Siehe Punchout einrichten.

Der Punchout-Käufer sieht unseren ganzen Katalog oder Listenpreise.

Die Einstellung für nicht zugeordnete Zeilen des Kanals blieb auf Inherit, während der Mandantenstandard offen ist, also zeigt der Kanal jeden Artikel und jeden Preis. Stellen Sie sie auf Hidden until assigned, bevor Sie Zugangsdaten herausgeben, und filtern Sie dann das Produktraster nach dem Kanal und zählen Sie gegen den Vertrag. Listenpreise heißen, dass die Konditionen des Kunden für diesen Kanal nicht auflösen; prüfen Sie den Geltungsbereich der Vertragsliste. Siehe Punchout einrichten.

Kann unser Integrator testen, ohne Livedaten anzufassen?

Ja, in einer Sandbox: ein eigener Tenant mit eigenen Keys und eigenen Daten, in dem ein gescheiterter Import nichts kostet. Richten Sie sie am ersten Tag des Integrationsprojekts ein, benennen Sie ihre Keys mit der Umgebung, damit erp-sync in zwei Tenants nicht verwechselt wird, und denken Sie daran, dass eine in der Sandbox nicht installierte App auf Pfaden mit 404 antwortet, die es in Produktion gibt. Siehe Die Sandbox.