Backend anlegen
Ein Backend ist eine bereitgestellte Simulation, die die Anbieter bedient, die du auswählst. Diese Seite bringt es von nichts bis zu einer URL, die deine Integration aufrufen kann.
Bevor du anfängst
Du brauchst einen Anbieter. Ein Backend muss etwas bedienen, und es kann nur Marken bedienen, die deine Organisation bereits hält.
Siehe Anbieter hinzufügen.
Dein Tarif muss ein Backend zulassen, und die App sagt es dir auf der Seite Backends, wenn er das nicht tut. Ein Backend ist eine Simulation wie jede andere und zählt daher auch auf dasselbe Simulationskontingent wie deine übrige Arbeit.
Anlegen kann es jeder ab der Rolle Editor. Anbieter kaufen dürfen nur Inhaber, ein Backend aus dem zu bauen, was die Organisation schon hat, dagegen nicht.
Anlegen
Öffne Backends und nutze Neues Backend in der Zeile des Typs, den du willst. Du kannst auch bei Simulationen anfangen, wo Backends neben allem anderen stehen.
Drei Felder:
- Typ ist Zahlungen oder Identität. Er lässt sich später nicht ändern, weil er entscheidet, welche Engine läuft.
- Name ist für dich, und damit listet die App sie. Ändere ihn, wann du willst.
- URL-Segment ist Teil der Adresse. Kleinbuchstaben, höchstens 15 Zeichen.
Das Segment bleibt bis zum ersten Deploy änderbar und liegt danach fest. Das ist Absicht: Es steht mitten in der URL, die dein Code aufruft, und es steht vor allem, was das Backend aufzeichnet. Eine Umbenennung danach würde also laufende Integrationen brechen und gleichzeitig die Aufzeichnungen abhängen.
Ein frisch angelegtes Backend bedient noch nichts. Es hat keine Anbieter, bis du welche auswählst, und ein Backend ohne Anbieter wird beim Deploy abgelehnt.
Auswählen, was sie bedient
Öffne das Backend und geh auf Anbieter. Dort steht alles, was die Organisation hält, und du hakst an, was dieses eine bedient.
Wähle auf der Ebene, die passt:
- Die Marke, etwa Adyen, die jede API und jede Version darunter abdeckt.
- Eine API dieser Marke.
- Eine genaue Version, etwa
adyen/checkout/v71.
Die Marke anzuhaken deckt alles darunter ab, und die engeren Zeilen sagen das auch, statt dich dasselbe zweimal anhaken zu lassen. Alle auswählen nimmt jede Marke, die du hältst.
Hier stehen nur Marken, die deine Organisation hält. Liefert der Build, auf dem das Backend läuft, eine davon nicht mehr aus, ist sie gekennzeichnet und nicht auswählbar.
Mehrere Backends mit unterschiedlicher Auswahl zu betreiben ist normal. Bedient ein Backend nur eine Marke, erreicht jeder Request daran genau diesen Anbieter und keinen anderen. Genau das willst du, wenn ein Test um eine Integration geht.
Bereitstellen
Bereitstellen stellt das Backend bereit. Vorher wird nichts bedient, und Änderungen an den Anbietern erreichen ein laufendes Backend auf demselben Weg: speichern, dann deployen.
Die Statusplakette wandert zu Aktiv, und die URL beginnt zu antworten. Der erste Deploy dauert länger als spätere, weil die Laufzeit dabei platziert wird.
Die Adresse folgt dem Muster jeder Simulation, mit jedem Anbieter unter einem eigenen Präfix:
https://<domain>/pay/<deine-org>/<name>/adyen/checkout/v71/payments
https://<domain>/kyx/<deine-org>/<name>/onfido/v3.6/applicantsAlles nach dem Präfix ist der Pfad des Anbieters. Deine Integration auf das Backend zu richten ist also eine geänderte Basis-URL und sonst nichts.
Einstellungen, die du kennen solltest
Unter Allgemein stehen der Name, das URL-Segment und Verhalten. Verhalten steuert, was das Backend außer dem Antworten tut:
- API-Explorer zeigt eine bedienbare Oberfläche unter der URL des Backends. Schalte ihn aus, dann antwortet nur die API.
- Verkehr aufzeichnen hält jeden Request und jede Antwort fest, und das füllt den Verlauf. Aufbewahren legt fest, wie lange sie leben.
- Replay zeichnet eine Antwort einmal auf und beantwortet passende Requests danach damit.
Bereitstellung ist, wo sie läuft, und Zugriff ist, wer sie erreichen darf. Beides verhält sich wie bei jeder Simulation.
Siehe Zugriffskontrolle.
Wenn sie läuft
Das Backend hält fest, was es getan hat, durchsuchbar je Anbieter.
Siehe Aktivität eines Backends.
Standardmäßig folgt sie dem neuesten veröffentlichten Build. Lege sie auf einen Build fest, wenn eine Testsuite über längere Zeit dieselben Antworten braucht.
Siehe Build-Version festlegen.