Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# SEQUENTIAL\_EXECUTOR
## Wann sollte dies verwendet werden?
A `SEQUENTIAL_EXECUTOR` führt nacheinander eine Reihe von Funktionen aus. Für jeden Schritt können die Ergebnisse der vorherigen Schritte verwendet werden.
Verwenden Sie diese Option`SEQUENTIAL_EXECUTOR`, wenn Ihre Logik mehrere Schritte erfordert, die von den Ergebnissen der jeweils anderen Schritte abhängen. Zu den häufigsten Anwendungsfällen gehören das Abrufen von Identitätsdaten und deren anschließende Verwendung zum Abrufen von Zielgruppensegmenten, das Ausführen eines Klassifizierungsschritts und das anschließende bedingte Aufrufen verschiedener externer Dienste auf der Grundlage des Ergebnisses sowie das Erstellen komplexer URLs für Anzeigenanfragen aus mehreren Datenquellen.
## Felder für die Konfiguration
Eine `SEQUENTIAL_EXECUTOR` Funktion hat die folgenden Felder:
+ **Runtime** — Die Ausdruckssprache. Stellen Sie dies auf ein`JSONATA`.
+ **FunctionList**— Eine geordnete Liste mit 1 bis 10 Schritten. Jeder Schritt gibt `FunctionId` an, welche Funktion ausgeführt werden soll. Optional können Sie einen `RunCondition` Ausdruck hinzufügen, um zu steuern, ob der Schritt ausgeführt oder übersprungen wird.
+ **Ausgabe** — Definiert die Werte, die nach Abschluss aller Schritte erzeugt werden sollen. Jeder Eintrag ordnet einem Ausdruck einen Ausgabeschlüssel (z. B.`player_params.envelope`) zu, der auf Daten verweisen kann, die durch einen beliebigen Schritt in der Sequenz erzeugt wurden. Wenn nicht angegeben, wird die gesamte Ausgabe der einzelnen Funktionen in der Sequenz verwendet.
+ **TimeoutMilliseconds**(erforderlich) — Die maximale Zeit, bis die gesamte Sequenz abgeschlossen ist. Wenn die Sequenz dieses Timeout überschreitet, MediaTailor werden alle Ausgaben der Sequenz verworfen.
## Geordnete Ausführung und Datenfluss
MediaTailor führt jeden Schritt der Sequenz vom ersten bis zum letzten aus. Nach Abschluss jedes Schritts werden die Werte, die er erzeugt, zu einer fortlaufenden Reihe von Ergebnissen zusammengeführt. Nachfolgende Schritte können auf die ursprünglichen Sitzungsdaten sowie auf alle Werte zugreifen, die in früheren Schritten erzeugt wurden.
Temporäre Daten sind der wichtigste Mechanismus für die Übertragung von Daten zwischen den Schritten. Wenn eine Funktion in einen `temp.*` Schlüssel schreibt, kann der nächste Schritt diesen Wert lesen. Player-Parameter und Felder für Anzeigenanfragen, die in früheren Schritten geschrieben wurden, sind auch für spätere Schritte sichtbar.
**Anmerkung**
Temporäre Daten akzeptieren jeden Datentyp, einschließlich Objekte und Arrays. Player-Parameter und Anzeigenanforderungsfelder akzeptieren nur Zeichenfolgen, Zahlen, boolesche Werte und Nullwerte.
## Per-step Betriebsbedingungen
Jeder Schritt in der Sequenz hat ein optionales `RunCondition` Feld. Dieses Feld enthält einen Ausdruck, der `true` oder zurückgibt`false`. MediaTailor wertet den `RunCondition` Ausdruck unmittelbar vor der Ausführung dieses Schritts aus.
Wenn der `RunCondition` Ausdruck als 0 ausgewertet wird`false`, MediaTailor überspringt er den Schritt vollständig und fährt mit dem nächsten fort. Wenn das `RunCondition` Feld weggelassen wird, wird der Schritt immer ausgeführt.
```
{ "FunctionId": "retryFetch", "RunCondition": "{%temp.statusCode = 500%}" }
```
Mit diesem Mechanismus können Sie bedingte Pipelines erstellen. Sie können beispielsweise in Schritt 1 einen Identitätsabruf und dann in Schritt 2 eine bedingte Segmentsuche nur dann ausführen, wenn Schritt 1 eine gültige Identität zurückgegeben hat.
## Wie funktioniert der Ausgabeblock
Der Ausgabeblock auf a `SEQUENTIAL_EXECUTOR` steuert, was die Sequenz erzeugt, nachdem alle Schritte abgeschlossen sind:
+ **Ausgangsblock vorhanden** — MediaTailor wertet die Ausdrücke im Ausgabeblock anhand des akkumulierten Endstatus aus und speichert nur diese Ausgaben. Alle Ausgaben, die in früheren Schritten erzeugt wurden und auf die im sequentiellen Ausgabeblock nicht verwiesen wird, werden verworfen.
+ **Ausgangsblock fehlt** — MediaTailor speichert alle gesammelten Ausgaben aller Schritte direkt.
**Tipp**
Lassen Sie den Ausgangsblock weg, wenn Sie möchten, dass der Ausgang jeder Funktion durchgelassen wird. Fügen Sie einen Ausgabeblock hinzu, wenn Sie die gesammelten Ergebnisse filtern, umbenennen oder transformieren müssen, bevor Sie sie speichern.
## Timeout-Konfiguration
Das `TimeoutMilliseconds` Feld legt eine Frist für die gesamte Sequenz fest. Dieses Timeout deckt alle Schritte ab, einschließlich aller HTTP-Aufrufe, die von Funktionen ausgeführt werden. Wenn die Sequenz das Timeout überschreitet, MediaTailor werden alle Ausgaben der Sequenz verworfen und der Vorgang wird fortgesetzt, als ob keine Funktion angehängt wäre.
Einzelne `HTTP_REQUEST` Funktionen respektieren immer noch ihre eigene Einstellung. `RequestTimeoutMilliseconds` Das Sequenz-Timeout dient als äußere Grenze, die die gesamte Ausführungszeit begrenzt.
## Beispiel: Bei einem HTTP-Fehler erneut versuchen
In diesem Beispiel wird eine Identity-API aufgerufen und es wird automatisch erneut versucht, wenn der erste Aufruf einen Serverfehler zurückgibt. Es verwendet zwei HTTP\_REQUEST-Funktionen, die von einem SEQUENTIAL\_EXECUTOR orchestriert werden.
**Schritt 1 — Primärer `fetchIdentity` Abruf ():**
```
{
"FunctionId": "fetchIdentity",
"FunctionType": "HTTP_REQUEST",
"HttpRequestConfiguration": {
"Runtime": "JSONATA",
"MethodType": "GET",
"Url": "{%'https://identity.example.com/v1/resolve?ip=' & session.client_ip%}",
"Headers": {
"Accept": "application/json"
},
"RequestTimeoutMilliseconds": 1000,
"Output": {
"temp.statusCode": "{%response.statusCode%}",
"temp.envelope": "{%response.statusCode = 200 ? response.body.envelope : null%}"
}
}
}
```
**Schritt 2 — Bei einem Fehler erneut versuchen ()`retryIdentity`:**
```
{
"FunctionId": "retryIdentity",
"FunctionType": "HTTP_REQUEST",
"HttpRequestConfiguration": {
"Runtime": "JSONATA",
"MethodType": "GET",
"Url": "{%'https://identity-fallback.example.com/v1/resolve?ip=' & session.client_ip%}",
"Headers": {
"Accept": "application/json"
},
"RequestTimeoutMilliseconds": 1000,
"Output": {
"temp.statusCode": "{%response.statusCode%}",
"temp.envelope": "{%response.statusCode = 200 ? response.body.envelope : null%}"
}
}
}
```
**Reihenfolge (`identityWithRetry`):**
```
{
"FunctionId": "identityWithRetry",
"FunctionType": "SEQUENTIAL_EXECUTOR",
"SequentialExecutorConfiguration": {
"Runtime": "JSONATA",
"TimeoutMilliseconds": 2000,
"FunctionList": [
{ "FunctionId": "fetchIdentity" },
{ "FunctionId": "retryIdentity", "RunCondition": "{%temp.statusCode >= 500%}" }
],
"Output": {
"player_params.envelope": "{%temp.envelope%}"
}
}
}
```
**So funktioniert es:**
1. `fetchIdentity`ruft die Identity-API auf und schreibt den Statuscode und den Umschlag in`temp.*`.
1. Wenn der Statuscode 500 oder höher ist, wird `RunCondition` der zweite Schritt ausgewertet `true` und `retryIdentity` ausgeführt. Es überschreibt `temp.statusCode` und `temp.envelope` mit der Wiederholungsantwort.
1. Wenn der erste Anruf erfolgreich war, wird Schritt 2 übersprungen.
1. Die Sequenz, in die der Output-Block schreibt`temp.envelope`. `player_params.envelope`