

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# EXÉCUTEUR\_SÉQUENTIEL
<a name="monetization-functions-types-sequential-executor"></a>

## Quand l’utiliser
<a name="monetization-functions-types-sequential-executor-when"></a>

A `SEQUENTIAL_EXECUTOR` exécute une série de fonctions une par une, dans l'ordre. Chaque étape peut utiliser les résultats des étapes précédentes.

`SEQUENTIAL_EXECUTOR`À utiliser lorsque votre logique nécessite plusieurs étapes qui dépendent des résultats des uns et des autres. Les cas d'utilisation courants incluent la récupération de données d'identité, puis leur utilisation pour récupérer des segments d'audience, l'exécution d'une étape de classification, puis l'appel conditionnel à différents services externes en fonction du résultat, et la création d'URL de demandes publicitaires complexes à partir de plusieurs sources de données.

## Champs de configuration
<a name="monetization-functions-types-sequential-executor-fields"></a>

Une `SEQUENTIAL_EXECUTOR` fonction comporte les champs suivants :
+ **Runtime** — Langage d'expression. Réglez ce paramètre sur`JSONATA`.
+ **FunctionList**— Une liste ordonnée de 1 à 10 étapes. Chaque étape indique `FunctionId` la fonction à exécuter. Vous pouvez éventuellement ajouter une `RunCondition` expression pour contrôler si l'étape est exécutée ou ignorée.
+ **Sortie** : définit les valeurs à produire une fois toutes les étapes terminées. Chaque entrée fait correspondre une clé de sortie (telle que`player_params.envelope`) à une expression qui peut référencer des données produites par n'importe quelle étape de la séquence. En cas d'omission, toutes les sorties des différentes fonctions de la séquence sont utilisées.
+ **TimeoutMilliseconds**(obligatoire) — Durée maximale pendant laquelle la séquence complète doit être terminée. Si la séquence dépasse ce délai, toutes les sorties MediaTailor de la séquence sont supprimées.

## Exécution ordonnée et flux de données
<a name="monetization-functions-types-sequential-executor-data-flow"></a>

MediaTailor exécute chaque étape de la séquence de la première à la dernière. Une fois chaque étape terminée, les valeurs produites sont fusionnées dans un ensemble de résultats. Les étapes suivantes peuvent accéder aux données de session d'origine ainsi qu'à toutes les valeurs produites par les étapes précédentes.

Les données temporaires constituent le principal mécanisme de transmission des données entre les étapes. Lorsqu'une fonction écrit sur une `temp.*` touche, l'étape suivante peut lire cette valeur. Les paramètres du joueur et les champs de demande d'annonces écrits lors des étapes précédentes sont également visibles lors des étapes ultérieures.

**Note**  
Les données temporaires acceptent tous les types de données, y compris les objets et les tableaux. Les paramètres du joueur et les champs de demande d'annonce n'acceptent que les chaînes, les nombres, les booléens et les valeurs nulles).

## Per-step conditions de course
<a name="monetization-functions-types-sequential-executor-run-conditions"></a>

Chaque étape de la séquence comporte un `RunCondition` champ facultatif. Ce champ contient une expression qui renvoie `true` ou`false`. MediaTailor évalue l'`RunCondition`expression immédiatement avant d'exécuter cette étape.

Si l'`RunCondition`expression est évaluée à`false`, MediaTailor ignore complètement l'étape et passe à la suivante. Si le `RunCondition` champ est omis, l'étape est toujours exécutée.

```
{ "FunctionId": "retryFetch", "RunCondition": "{%temp.statusCode = 500%}" }
```

Ce mécanisme vous permet de créer des pipelines conditionnels. Par exemple, vous pouvez exécuter une recherche d'identité à l'étape 1, puis exécuter une recherche de segment de manière conditionnelle à l'étape 2 uniquement si l'étape 1 a renvoyé une identité valide.

## Fonctionnement du bloc de sortie
<a name="monetization-functions-types-sequential-executor-output"></a>

Le bloc de sortie d'un `SEQUENTIAL_EXECUTOR` contrôle ce que la séquence produit une fois toutes les étapes terminées :
+ **Bloc de sortie présent** : MediaTailor évalue les expressions du bloc de sortie par rapport à l'état cumulé final et enregistre uniquement ces sorties. Toutes les sorties produites par les étapes précédentes qui ne sont pas référencées dans le bloc de sortie séquentiel sont supprimées.
+ **Bloc de sortie absent** : MediaTailor enregistre directement toutes les sorties cumulées de toutes les étapes.

**Astuce**  
Omettez le bloc de sortie lorsque vous souhaitez que la sortie de chaque fonction soit transmise. Ajoutez un bloc de sortie lorsque vous devez filtrer, renommer ou transformer les résultats accumulés avant de les enregistrer.

## Configuration du délai d’attente
<a name="monetization-functions-types-sequential-executor-timeout"></a>

Le `TimeoutMilliseconds` champ définit une date limite pour l'ensemble de la séquence. Ce délai couvre toutes les étapes, y compris les appels HTTP effectués par les fonctions. Si la séquence dépasse le délai imparti, MediaTailor supprime toutes les sorties de la séquence et procède comme si aucune fonction n'était attachée.

Les `HTTP_REQUEST` fonctions individuelles respectent toujours leur propre `RequestTimeoutMilliseconds` réglage. Le délai d'expiration de la séquence agit comme une limite extérieure qui limite le temps d'exécution total.

## Exemple : Réessayer en cas d'échec du protocole HTTP
<a name="monetization-functions-types-sequential-executor-example"></a>

Cet exemple appelle une API d'identité et réessaie automatiquement si le premier appel renvoie une erreur de serveur. Il utilise deux fonctions HTTP\_REQUEST orchestrées par un SEQUENTIAL\_EXECUTOR.

**Étape 1 — Primary fetch (`fetchIdentity`) :**

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

**Étape 2 — Réessayer en cas d'échec (`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%}"
        }
    }
}
```

**Séquence (`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%}"
        }
    }
}
```

**Comment cela fonctionne :**

1. `fetchIdentity`appelle l'API d'identité et y écrit le code d'état et l'enveloppe`temp.*`.

1. Si le code d'état est supérieur ou égal à 500, `RunCondition` l'étape 2 est évaluée `true` et `retryIdentity` exécutée. Il remplace `temp.statusCode` et par la `temp.envelope` réponse de nouvelle tentative.

1. Si le premier appel a réussi, l'étape 2 est ignorée.

1. La séquence dans laquelle le bloc `temp.envelope` de sortie écrit`player_params.envelope`.