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 eine Reihe von Funktionen nacheinander aus, der Reihe nach. 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 für die Konfiguration

Eine SEQUENTIAL_EXECUTOR Funktion hat die folgenden Felder:

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.

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. 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.

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: