Eigene Szenarien schreiben
Die eingebauten Auslöser decken die Fälle ab, die jedes Team braucht. Eigene Szenarien decken die ab, die nur dein Produkt hat: die Erstattung, über die deine Buchhaltung streitet, den Antragsteller, den eure Risikoregeln anders behandeln, die genaue Antwort aus einem Fehlerbericht.
Ein Szenario ist ein Wenn und ein Dann: Wenn eine Anfrage auf das passt, was du beschreibst, antwortet die Sandbox so, wie du es festgelegt hast.
Wo sie liegen
Öffne die Sandbox, geh auf Szenarien, wähle einen Anbieter und nutze den Tab Diese Sandbox.
Jede Zeile ist ein Szenario: ein Name, eine oder mehrere Bedingungen und das Ergebnis. Der Name ist ein Etikett. Er wird mit dem Ergebnis gemeldet, damit du siehst, welche Regel gegriffen hat, und er wird nie abgeglichen.
Bedingungen in derselben Zeile sind Alternativen. Eine Zeile mit zwei Namen greift, wenn einer davon ankommt, nicht wenn beide ankommen.
Welches greift
Drei Ebenen, in dieser Reihenfolge geprüft:
- Deine
- Was der Anbieter mitbringt
- Der gemeinsame Satz, auf den jeder Anbieter antwortet
Der erste Treffer gewinnt. Ein eigenes Szenario für insufficient_funds ersetzt also das eingebaute Verhalten für diesen Auslöser und lässt alles andere unberührt.
Innerhalb einer Ebene entscheidet eine feste Reihenfolge der Bedingungen, nicht die Reihenfolge der Zeilen auf dem Bildschirm. Diese Reihenfolge steht auf den Seiten zu Zahlungen und Identität.
Um beide eingebauten Ebenen fallen zu lassen und nur aus deiner Liste zu antworten, setze replace: true.
Stattdessen YAML schreiben
Der Editor und das YAML sind dasselbe Dokument. Wechsle auf YAML für alles, was die Tabelle nicht ausdrücken kann, oder um ein Szenario einzufügen, das dir jemand geschickt hat.
Beim Zurückwechseln zum Editor wird das Dokument neu geschrieben, und Kommentare gehen dabei verloren. Die App sagt es dir vorher.
Die Tabs Mitgeliefert und Gemeinsam sind der naheliegende Anfang: Kopiere einen Eintrag, der schon funktioniert, und ändere daran, was du brauchst.
Was vor dem Speichern geprüft wird
Dein Dokument wird gegen den Build geprüft, auf dem die Sandbox tatsächlich läuft, nicht gegen den neuesten. Eine Sandbox, die auf einem älteren Build festliegt, wird an dem gemessen, was dieser Build annimmt.
Geprüft werden die Form des Dokuments, die Namen der Ergebnisse, die Gründe, die dazugehören, und die Felder, auf die du abgleichen kannst. Was nicht angenommen wird, wird je Zeile gemeldet, mit dem Namen der Zeile, und das Speichern wird abgelehnt.
Geltungsbereich
Jeder Override gehört zu einem Anbieter-Geltungsbereich, auf denselben drei Ebenen, auf denen eine Sandbox Anbieter auswählt: eine Marke, eine ihrer APIs oder eine genaue Version. Der engere gewinnt.
Auf die Marke zu schreiben ist meistens richtig. Greif zur Version, wenn zwei Versionen derselben API wirklich unterschiedliche Antworten brauchen.
Live schalten
Speichern legt das Dokument ab. Bereitstellen bringt es auf die laufende Sandbox, wie jede andere Änderung auch.
Einen Override zu entfernen setzt diesen Anbieter auf das zurück, was er mitbringt.