Eine Sandbox einrichten
Ordentlich gemacht kostet das einen Nachmittag und entfernt die gesamte Klasse von Integrationsvorfällen, die mit „wir haben doch nur getestet" beginnt.
1. Den Tenant anfordern
Eine Sandbox ist ein eigener Tenant mit eigenem Slug. Fordern Sie ihn über
Ihren üblichen Support-Kanal an, und bitten Sie um einen Slug, der um 02:00
Uhr im Log unverwechselbar ist: acme-eu-sandbox, nie acme-eu-2.
Bestätigen Sie drei Dinge, wenn er ankommt:
- Welche Apps installiert sind. Sie sollten die Produktion spiegeln — eine Sandbox ohne die Inventories-App kann keine Bestandsintegration testen.
- Dass ausgehendes Messaging aus oder umgeleitet ist. Nichts aus der Sandbox darf das Postfach eines echten Kunden erreichen.
- Ihre eigene Storefront-Adresse, damit der Integrator die Wirkung dessen sieht, was er hineinschiebt.
2. Befüllen
Eine leere Sandbox ist nicht testbar; eine Kopie der Produktion ist nicht zulässig. Bauen Sie stattdessen einen bewussten Seed, und behalten Sie die Datei, die ihn erzeugt hat — diese Datei ist Ihre Sandbox-Definition.
| Befüllen mit | Größenordnung | Gezielt aufnehmen |
|---|---|---|
| Katalogausschnitt | 2.000–5.000 Artikel | Eine Variantenfamilie, ein Maß-Attribut, ein Artikel im 12er-Gebinde, ein auslaufender, einer mit sehr langer Beschreibung |
| Preislisten | Die echte Struktur | Eine Standardliste, eine kundenspezifische Liste, ein Staffelpreis, ein abgelaufener befristeter Preis |
| Organisationen | 10–20, erfunden | Eine mit Freigabeschwelle, eine gesperrte, eine auf Punchout, eine in einer zweiten Währung |
| Kontakte | 2–3 je Organisation | Einer, der nur Bestellungen anfragen darf, einer, der freigeben darf |
| Bestellungen | Eine Handvoll je Status | pending, placed, in_fulfillment, completed, cancelled |
| Bestand | Über einige Standorte | Nullbestand, voll reservierter Bestand, und ein Fall mit negativer Verfügbarkeit |
Der praktische Weg für die meisten Unternehmen: die Struktur aus der Produktion exportieren (Attribute, Familien, Kategorien, Preislistenaufbau, Kanäle, Märkte, Steuerklassen), in die Sandbox importieren, und darauf einen erfundenen Kunden- und Bestellbestand laden. Beide Dateien wandern in die Versionsverwaltung, neben das Projekt.
3. Sandbox-Schlüssel ausstellen
Die Sandbox braucht eigene API-Schlüssel — Schlüssel sind an einen Tenant gebunden und erreichen keinen anderen.
Sandbox-Schlüssel sind eine andere Sorte als Produktionsschlüssel, und den Unterschied sollte man aussprechen:
| Produktionsschlüssel | Sandbox-Schlüssel | |
|---|---|---|
| Scopes | Exakt, was die Integration braucht | Breiter ist akzeptabel |
| Wer ihn hält | Sie, einmal übergeben, in einen Secret-Store | Der Integrator, in seinem eigenen Tooling |
| Name | erp-order-sync-prod | sandbox-integrator-mueller |
| Lebensdauer | Nach Plan rotiert | Widerrufen, wenn die Projektphase endet |
| Anzahl | So wenige wie möglich | Einer je Person oder je Team ist in Ordnung |
Zwei Dinge bleiben auch in der Sandbox nicht verhandelbar: Das Secret wird weiterhin nur einmal angezeigt, und es gehört weiterhin in keine E-Mail.
4. Das Übergabedokument schreiben
Eine Seite, dem Integrator zusammen mit dem Schlüssel gegeben. Sie beantwortet alles, was er Sie sonst dreimal fragen würde:
- Der Tenant-Slug und der Gateway-Endpoint,
https://api.revenexx.com. - Wo die API-Referenz je Tenant liegt:
https://api.revenexx.com/v1/openapi.json— sie ist die Autorität darüber, was existiert, keine Prosaseite. - Welche Apps installiert sind.
- Die Adresse der Sandbox-Storefront.
- Welche Fixture-Datensätze zu verwenden sind — die erfundene Organisation mit Freigabeschwelle, die gesperrte, der Artikel im 12er-Gebinde.
- Der Refresh- und Reset-Rhythmus, und wen man fragt.
- Wohin mit Entwicklerfragen: das Developer Portal auf revenexx.dev.
- Wer in Ihrem Unternehmen das verantwortet, und wie man ihn erreicht.
5. Den Refresh-Rhythmus vereinbaren
Sandbox-Daten driften binnen Wochen von der Produktion weg. Legen Sie vorab fest:
- Reset — zurück auf den Seed. Vereinbaren Sie ihn zwischen Testrunden, nie mitten in einer.
- Refresh — ein neuer Seed, der die aktuelle Produktionsstruktur abbildet. Einmal im Quartal, und immer vor einer Go-live-Runde.
- Freeze — keine Resets in der letzten Testwoche vor dem Go-live, damit Ergebnisse reproduzierbar sind.
Die Termine gehören in den Projektplan. Ein Reset, der jemanden überrascht, kostet einen Tag seiner Arbeit und eine Menge Goodwill.
Was Sie prüfen
Bevor Sie übergeben, führen Sie das selbst durch:
- Ein Aufruf mit dem Sandbox-Schlüssel liefert
200, und derselbe Schlüssel gegen den Produktions-Slug wird abgelehnt. - Die Storefront zeigt den Seed-Katalog, und die erfundenen Kunden können sich anmelden.
- Eine Testbestellung sendet keine E-Mail an irgendeine echte Adresse.
- In jedem Status, den der Integrator lesen muss, existiert eine Fixture-Bestellung.
- Die
openapi.jsonder Sandbox listet die erwarteten Ressourcen.
Wenn es nicht funktioniert
- Der Integrator sieht weniger Ressourcen als erwartet — eine App ist auf der Sandbox nicht installiert. Vergleichen Sie mit der Produktion; siehe Apps und der Marketplace.
- Die Sandbox verhält sich anders als die Produktion — meist ein Unterschied in den Einstellungen, keiner der Plattform. Freigabeschwellen, Reservierungsverhalten im Checkout und Kanal-Sichtbarkeit sind die üblichen drei.
- Test-E-Mails haben echte Menschen erreicht — anhalten, Messaging abschalten, als Vorfall behandeln. Genau deshalb prüft Schritt 1 das.
Weiter
- Eine Integration durchgängig testen — was Sie darin durchspielen, und die Go-live-Checkliste.
- Häufige API-Aufgaben nach Job — die Rezepte, die der Integrator abarbeitet.