View a markdown version of this page

Sequentieller Executor - AWS Elemental MediaTailor

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.

Sequentieller Executor

Wann sollte dies verwendet werden?

A SEQUENTIAL_EXECUTOR führt nacheinander eine Reihe von Funktionen aus. Jeder Schritt kann die Ergebnisse der vorherigen Schritte verwenden.

Verwenden Sie SEQUENTIAL_EXECUTOR es, wenn Ihre Logik mehrere Schritte erfordert, die von den Ergebnissen des jeweils anderen 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 Aufrufen verschiedener externer Dienste auf der Grundlage des Ergebnisses sowie das Erstellen komplexer Anzeigenanforderungs-URLs aus mehreren Datenquellen.

Felder zur Konfiguration

Eine SEQUENTIAL_EXECUTOR Funktion hat die folgenden Felder:

  • Runtime — Die Ausdruckssprache. Stellen Sie dies auf einJSONATA.

  • FunctionList— Eine geordnete Liste von 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 einen Ausgabeschlüssel (z. B.player_params.envelope) einem Ausdruck zu, der auf Daten verweisen kann, die durch einen beliebigen Schritt in der Sequenz erzeugt wurden. Wenn dieser Parameter weggelassen wird, wird die gesamte Ausgabe der einzelnen Funktionen in der Sequenz verwendet.

  • TimeoutMilliseconds(erforderlich) — Die maximale Zeit, in der die gesamte Sequenz abgeschlossen ist. Wenn die Sequenz diesen Timeout überschreitet, MediaTailor werden alle Ausgaben der Sequenz verworfen.

Geordnete Ausführung und Datenfluss

MediaTailor führt jeden Schritt in der Reihenfolge vom ersten bis zum letzten aus. Nach Abschluss jedes Schritts werden die von ihm erzeugten Werte 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 generiert wurden.

Temporäre Daten sind der primäre Mechanismus für die Weitergabe von Daten zwischen Schritten. Wenn eine Funktion in einen temp.* Schlüssel schreibt, kann der nächste Schritt diesen Wert lesen. Spielerparameter und Felder für Anzeigenanfragen, die in früheren Schritten geschrieben wurden, sind auch in späteren Schritten 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 Bedingungen ausführen

Jeder Schritt in der Sequenz hat ein optionales RunCondition Feld. Dieses Feld enthält einen Ausdruck, der true oder zurückgibtfalse. MediaTailor wertet den RunCondition Ausdruck unmittelbar vor der Ausführung dieses Schritts aus.

Wenn der RunCondition Ausdruck als ausgewertet wirdfalse, MediaTailor überspringt er den Schritt vollständig und geht zum nächsten über. 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. Beispielsweise können Sie in Schritt 1 einen Identitätsabruf ausführen und dann in Schritt 2 eine Segmentsuche nur dann bedingt ausführen, wenn Schritt 1 eine gültige Identität zurückgegeben hat.

So funktioniert der Ausgabeblock

Der Ausgangsblock auf einem SEQUENTIAL_EXECUTOR steuert, was die Sequenz nach Abschluss aller Schritte erzeugt:

  • Ausgangsblock vorhanden — MediaTailor wertet die Ausdrücke im Ausgangsblock anhand des endgültigen akkumulierten Zustands aus und speichert nur diese Ausgaben. Alle durch frühere Schritte erzeugten Ausgaben, auf die im sequentiellen Ausgabeblock nicht verwiesen wird, werden verworfen.

  • Ausgangsblock fehlt — MediaTailor speichert alle akkumulierten Ausgänge aus allen Schritten direkt.

Tipp

Lassen Sie den Ausgangsblock weg, wenn Sie möchten, dass die Ausgabe jeder Funktion durchgeht. 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. Dieser Timeout deckt alle Schritte ab, einschließlich aller HTTP-Aufrufe von Funktionen. Wenn die Sequenz den Timeout überschreitet, MediaTailor werden alle Ausgaben der Sequenz verworfen und es wird so verfahren, als ob keine Funktion angehängt wäre.

Einzelne HTTP_REQUEST Funktionen respektieren weiterhin 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

Dieses Beispiel ruft eine Identity-API auf und versucht es automatisch erneut, wenn der erste Aufruf einen Serverfehler zurückgibt. Es verwendet zwei HTTP_REQUEST-Funktionen, die von einem SEQUENTIAL_EXECUTOR orchestriert werden.

Schritt 1 — fetchIdentity Primäres Abrufen ():

{ "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%}" } } }

Sequenz (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. fetchIdentityruft die Identity-API auf und schreibt den Statuscode und den Umschlag intemp.*.

  2. Wenn der Statuscode 500 oder höher ist, wird RunCondition der erste Schritt 2 als ausgewertet true und retryIdentity ausgeführt. Die Antwort wird überschrieben temp.statusCode und temp.envelope mit der Wiederholungsantwort ausgeführt.

  3. Wenn der erste Anruf erfolgreich war, wird Schritt 2 übersprungen.

  4. Die Sequenz, in die Output Block schreibttemp.envelope. player_params.envelope