Ihre Systeme anbinden
Ein System anbinden
Zugangsdaten, Endpunkte und der erste Handshake, und die Prüfungen, die verhindern, dass eine Verbindung in Woche drei statt am ersten Tag scheitert.
Ein ERP, PIM, CRM oder Lagersystem anzubinden ist vor allem Vorbereitung. Der Handshake selbst dauert Minuten; Zeit kostet die Entscheidung, was über die Grenze läuft, und Zugangsdaten zu bekommen, die in einem Jahr noch funktionieren.
Bevor Sie beginnen. Klären Sie,
welches System welches Feld besitzt und
welches Muster jeder Fluss nutzt.
Von der Person, die das andere System betreibt, brauchen Sie außerdem: einen
Endpunkt, ein technisches Konto und einen namentlich bekannten Menschen, der
antwortet, wenn um 03:00 Uhr etwas kaputtgeht.
Zusammentragen, was Sie brauchen
Fragen Sie das in einer Nachricht ab statt in vier:
| Was | Warum es zählt |
|---|---|
| Endpunkt-URL, je Umgebung | Test und Produktion sind verschiedene Systeme. Verbinden Sie nie zuerst die Produktion |
| Protokoll und Format | REST/JSON, SOAP mit WSDL, SFTP mit CSV oder BMEcat, oder eine Datenbanksicht |
| Zugangsdaten | Ein technisches Konto, kein persönliches. Persönliche Konten verlassen das Unternehmen |
| Authentifizierungsmethode | API-Key, OAuth Client Credentials, Basic Auth, oder ein SSH-Schlüssel für SFTP |
| Rate Limits und Wartungsfenster | Damit Ihr Nachtlauf nicht mit deren Backup kollidiert |
| Eine Beispiel-Nutzlast mit echten Daten | Zehn echte Artikel, kein sauberes Beispiel. In echten Daten stecken die Überraschungen |
| Ansprechpartner und Eskalationsweg | Die Person, nicht die Ticket-Warteschlange |
Anbinden
- Prüfen Sie zuerst Extend and Develop › Marketplace. Gibt es für das System einen vorbereiteten Connector, installieren Sie ihn; er bringt eigene Bildschirme und ein eigenes Formular für Zugangsdaten mit, und Workflows nutzen ihn als Knoten, statt dass Sie rohe HTTP-Aufrufe zusammensetzen. Installierte Connectoren stehen unter Extend and Develop › Installierte Integrationen.
- Öffnen Sie Integrations › Zugangsdaten und wählen Sie Neue Zugangsdaten.
- Tragen Sie den Endpunkt Ihrer Test-Umgebung ein und benennen Sie die
Zugangsdaten nach System und Umgebung:
erp-test,erp-prod. Diese Namen lesen Sie später in den Ausführungsprotokollen. - Tragen Sie die Authentifizierungsdaten ein. Alles, was in einer Workflow-Definition nicht sichtbar sein soll (ein Passwort, ein Shared Secret, ein privater Schlüssel), gehört unter Integrations › Secrets und wird aus den Zugangsdaten referenziert. Zugangsdaten und Secrets aus dem Workflow herauszuhalten ist das, was denselben Workflow erst gegen das Test-ERP und dann gegen die Produktion laufen lässt, ohne ihn zu bearbeiten.
- Legen Sie Timeout und Wiederholungen fest. Für einen Batch-Feed großzügige Timeouts und mehrere Wiederholungen. Für einen Live-Aufruf, auf den eine Seite wartet, ein kurzer Timeout und ein Fallback; eine Seite, die 30 Sekunden hängt, ist schlimmer als eine Seite, die einen zwischengespeicherten Wert zeigt.
- Führen Sie den Verbindungstest aus. Er authentifiziert und liest, und ändert nichts.
- Speichern.
Was Sie prüfen
Ein grüner Test beweist nur, dass die Zugangsdaten funktionieren. Bevor Sie darauf etwas aufbauen:
- Zehn echte Datensätze abrufen und lesen. Lesen Sie die Werte statt der
Anzahl. Schauen Sie auf Mengeneinheit, Dezimaltrennzeichen, Datumsformat und
Encoding. Umlaute, die als
Ma�ankommen, bedeuten einen Encoding-Konflikt, den sonst ein Kunde entdeckt. - Die Formate von Kundennummer und SKU prüfen. Führende Nullen sind der
Klassiker: Das ERP hat
0004711, der Shop hat4711, und nichts passt zusammen. Entscheiden Sie jetzt, welche Form die kanonische ist. - Bestätigen, dass das Konto dort nur lesen darf, wo es nur lesen soll. Ein technisches Konto, das aus Versehen ins ERP schreiben kann, ist ein schlechter Nachmittag.
- Fragen, was passiert, wenn deren System in Wartung ist. Ein sauberer Fehler ist handhabbar. Eine Login-Seite mit HTTP 200 ist es nicht, und das wollen Sie wissen, bevor Ihr Parser sie als Produktdaten zu lesen versucht.
Dann in die Produktion
Legen Sie eigene Zugangsdaten für die Produktion an. Biegen Sie nicht die Test-Zugangsdaten auf die Produktion um. Sie werden die Test-Zugangsdaten wieder brauchen, und wer beides vermischt, riskiert, dass ein Testlauf in Live-Daten schreibt. Weil Workflows Zugangsdaten über den Namen referenzieren, statt sie einzubetten, ist der Wechsel eines Workflows von Test auf Produktion die Änderung eines einzigen Feldes.
Fahren Sie den ersten Produktionslauf mit kleinem, eingegrenztem Umfang: eine Produktgruppe, ein Kunde, ein Tag. Vergleichen Sie das Ergebnis von Hand mit der Quelle. Erst dann weiten Sie aus.
Richten Sie eine Testumgebung nie auf produktive Schreib-Endpunkte. Ein
Testlauf, der 400 Bestellungen in ein Live-ERP überträgt, ist ein echter
Vorfall, er passiert häufiger, als irgendjemand berichtet, und er ist
vollständig vermeidbar, wenn die beiden Verbindungen von Anfang an getrennt
bleiben.
Wenn es nicht funktioniert
| Symptom | Übliche Ursache |
|---|---|
| 401 / 403 auf einer Verbindung, die gestern funktionierte | Passwort rotiert, oder das technische Konto ist abgelaufen |
| Verbindung läuft von hier in den Timeout, funktioniert aber aus deren Büro | Ihre ausgehenden Adressen stehen nicht auf deren Firewall-Allowlist |
| TLS- oder Zertifikatsfehler | Ein abgelaufenes Zertifikat auf deren Seite, oder eine interne CA, der Ihre Seite nicht vertraut |
| Test erfolgreich, erster echter Lauf liefert nichts | Das Konto authentifiziert sich, hat aber kein Leserecht auf die Daten |
| Alles funktioniert, Werte sehen falsch aus | Encoding oder Locale: zuerst Dezimaltrennzeichen und Datumsformate prüfen |
Weiter
- Feld-Mapping: deren Feldnamen in Ihre übersetzen.
- Einen Workflow bauen: die Verbindung nach Zeitplan arbeiten lassen.