

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.

# Orchestration dans AWS Glue
<a name="etl-jobs"></a>

Les sections suivantes vous renseignent sur l'orchestration d'applications dans AWS Glue.

**Topics**
+ [Démarrage des tâches et des crawlers à l'aide de déclencheurs](trigger-job.md)
+ [Exécution d'activités ETL complexes à l'aide de plans et de flux de travail dans AWS Glue](orchestrate-using-workflows.md)
+ [Développement des plans dans AWS Glue](orchestrate-using-blueprints.md)

# Démarrage des tâches et des crawlers à l'aide de déclencheurs
<a name="trigger-job"></a>

Dans AWS Glue, vous pouvez créer des objets de catalogue de données appelés déclencheurs, que vous pouvez utiliser pour démarrer manuellement ou automatiquement un ou plusieurs crawlers, ou des tâches ETL (extraction, transformation et chargement). À l'aide de déclencheurs, vous pouvez concevoir une chaîne de tâches et d’crawlers dépendants.

**Note**  
Vous pouvez accomplir la même chose en définissant des *flux de travail*. Les flux de travail sont préférables pour créer des opérations ETL multitâches complexes. Pour de plus amples informations, veuillez consulter [Exécution d'activités ETL complexes à l'aide de plans et de flux de travail dans AWS Glue](orchestrate-using-workflows.md).

**Topics**
+ [Déclencheurs AWS Glue](about-triggers.md)
+ [Ajout de déclencheurs](console-triggers.md)
+ [Activation et désactivation des déclencheurs](activate-triggers.md)

# Déclencheurs AWS Glue
<a name="about-triggers"></a>

Lorsqu'il est *lancé*, un déclencheur peut démarrer des tâches et des crawlers spécifiés. Il se déclenche à la demande en fonction d'une planification ou d'une combinaison d'événements.

**Note**  
Seuls deux crawlers peuvent être activés par un même déclencheur. Si vous souhaitez analyser plusieurs magasins de données, utilisez plusieurs sources pour chaque crawler au lieu d'exécuter plusieurs crawlers simultanément.

Un déclencheur peut exister dans différents états : `CREATED`, `ACTIVATED` ou `DEACTIVATED`. Il peut aussi passer par des états transitoires, comme `ACTIVATING`. Pour arrêter temporairement le lancement d'un déclencheur, vous pouvez le désactiver. Vous pourrez le réactiver ultérieurement.

Il existe trois types de tâches :

**Planifié**  
Déclencheur temporel basé sur `cron`.  
Vous pouvez créer un déclencheur pour un ensemble de tâches ou de crawlers en fonction d'une planification. Vous pouvez spécifier des contraintes, telles que la fréquence d'exécution des tâches ou des crawlers, les jours de la semaine qu'ils s'exécutent et à quelle heure. Ces contraintes sont basées sur `cron`. Lorsque vous configurez la planification d'un déclencheur, prenez en compte les fonctions et limitations de cron. Par exemple, si vous choisissez d'exécuter votre crawler le 31 de chaque mois, n'oubliez pas que certains mois ne comportent pas 31 jours. Pour plus d'informations sur cron, consultez [Planifications temporelles pour les tâches et les crawlers](monitor-data-warehouse-schedule.md). 

**Conditionnel**  
Déclencheur qui se lance lorsqu'une ou plusieurs tâches précédentes, ou encore un ou plusieurs crawlers précédents satisfont à une liste de conditions.  
 Lorsque vous créez un déclencheur conditionnel, vous spécifiez une liste de tâches et une liste de crawlers à surveiller. Pour chaque tâche surveillée ou crawler, vous spécifiez un état à surveiller, tel que réussite, échec, expiré, etc. Le déclencheur se lance si les tâches ou les crawlers surveillés se finalisent par les statuts spécifiés. Vous pouvez configurer le déclencheur pour qu'il se lance lorsque tout ou partie des événements surveillés se produisent.  
Par exemple, vous pouvez configurer un déclencheur T1 pour démarrer la tâche J3 lorsque la tâche J1 et la tâche J2 sont terminées avec succès, et un autre déclencheur T2 pour démarrer la tâche J4 si la tâche J1 ou la tâche J2 échoue.  
Le tableau suivant répertorie les états de fin de tâche et de crawler qui déclenchent la surveillance.      
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/about-triggers.html)

**À la demande**  
Déclencheur qui se lance lorsque vous l'activez. Les déclencheurs à la demande ne peuvent pas comporter l'état `DEACTIVATED` ou `ACTIVATED`. Ils restent toujours à l'état `CREATED`.

Afin qu'ils soient prêts à se déclencher dès qu'ils existent, vous pouvez définir un indicateur pour activer les déclencheurs planifiés et conditionnels lors de leur création.

**Important**  
Les tâches ou les crawlers qui s'exécutent à la suite de l'exécution d'autres tâches ou crawlers sont considérés comme *dépendants*. Les tâches ou les crawlers dépendants ne sont lancés que si la tâche ou le crawler qui se finalise a été démarré par un déclencheur. Toutes les tâches d'une chaîne de dépendance doivent descendre d'un seul **calendrier** ou d'un déclencheur **à la demande**.

**Transmission de paramètres de tâches avec des déclencheurs**  
Un déclencheur permet de transmettre des paramètres aux tâches qu'il démarre. Ceux-ci incluent les arguments des tâches, la valeur de délai d'attente, la configuration de sécurité, etc. Si le déclencheur démarre plusieurs tâches, les paramètres sont transmis à chacune d'elles.

Voici les règles pour les arguments de tâche transmis par un déclencheur :
+ Si la clé de la paire clé-valeur correspond à un argument de tâche par défaut, l'argument transmis remplace l'argument par défaut. Si la clé ne correspond pas à un argument par défaut, l'argument est transmis en tant qu'argument supplémentaire pour la tâche.
+ Si la clé de la paire clé-valeur correspond à un argument non remplaçable, l'argument transmis est ignoré.

Pour plus d'informations, consultez [Triggers](aws-glue-api-jobs-trigger.md) dans l'API AWS Glue.

# Ajout de déclencheurs
<a name="console-triggers"></a>

Vous pouvez ajouter un déclencheur à l'aide de la AWS Glue console, du AWS Command Line Interface (AWS CLI) ou de l'AWS GlueAPI.

**Pour ajouter un déclencheur (console)**

1. Connectez-vous à la AWS Glue console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 

1. Dans le panneau de navigation, sous **ETL**, choisissez **Triggers (Déclencheurs)**. Choisissez **Add trigger (Ajouter un déclencheur)**.

1. Fournissez les propriétés suivantes :  
**Name**  
Attribuez un nom unique à votre déclencheur.  
**Type de déclencheur**  
Spécifiez l’un des éléments suivants :  
   + **Schedule (Planification) :** le déclencheur se lance à une fréquence et à une heure spécifiques.
   + **Job Events (Événements de tâche) :** déclencheur conditionnel. Le déclencheur est exécuté lorsqu'une ou plusieurs tâches de la liste correspondent à l'événement de tâche sélectionné. Pour que le déclencheur s'exécute, les tâches surveillées doivent avoir été lancées par des déclencheurs. Pour chaque tâche que vous choisissez, vous ne pouvez surveiller qu'un événement de tâche (état d'achèvement).
   + **On-demand (À la demande) :** le déclencheur se lance lorsqu'il est activé.

1. Terminez l'assistant de déclenchement. Sur la page **Review (Vérifier)**, vous pouvez activer immédiatement les déclencheurs **Schedule (Planification)** et **Job events (Événements de tâche)** (conditionnels) en sélectionnant **Enable trigger on creation (Activer le déclencheur lors de la création)**.

**Pour ajouter un déclencheur (AWS CLI)**
+ Utilisez une commande similaire à la suivante.

  ```
  aws glue create-trigger --name MyTrigger --type SCHEDULED --schedule  "cron(0 12 * * ? *)" --actions CrawlerName=MyCrawler --start-on-creation  
  ```

  Cette commande crée un déclencheur de planification nommé `MyTrigger`, qui s'exécute tous les jours à 12h00 UTC et démarre un crawler nommé `MyCrawler`. Le déclencheur est créé dans l'état activé.

Pour de plus amples informations, veuillez consulter [Déclencheurs AWS Glue](about-triggers.md).

# Planifications temporelles pour les tâches et les crawlers
<a name="monitor-data-warehouse-schedule"></a>

Vous pouvez définir une planification temporelle pour vos crawlers et vos tâches dans AWS Glue. La définition de ces planifications utilise la syntaxe de type Unix [cron](http://en.wikipedia.org/wiki/Cron). Vous spécifiez l'heure en [heure UTC](http://en.wikipedia.org/wiki/Coordinated_Universal_Time), et la précision minimale d'une planification est de 5 minutes.

Pour en savoir plus sur la configuration des tâches et des crawlers à exécuter à l'aide d'une planification, veuillez consulter [Démarrage des tâches et des crawlers à l'aide de déclencheurs](trigger-job.md).

## Expressions Cron
<a name="CronExpressions"></a>

Ces expressions se composent de six champs obligatoires qui sont séparés par des espaces. 

**Syntaxe**

```
cron(Minutes Hours Day-of-month Month Day-of-week Year)
```


| **Champs** | **Valeurs** | **Caractères génériques** | 
| --- | --- | --- | 
|  Minutes  |  0–59  |  , - \$1 /  | 
|  Heures  |  0 – 23  |  , - \$1 /  | 
|  D ay-of-month  |  1–31  |  , - \$1 ? / L W  | 
|  Mois  |  1–12 ou JAN–DEC  |  , - \$1 /  | 
|  D ay-of-week  |  1–7 ou dim.–sam.  |  , - \$1 ? / L  | 
|  Année  |  1970-2199  |  , - \$1 /  | 

**Caractères génériques**
+ Le caractère générique **,** (virgule) inclut des valeurs supplémentaires. Dans le champ `Month`, `JAN,FEB,MAR` contiendrait janvier, février et mars.
+ Le caractère générique **-** (tiret) spécifie des plages. Dans le champ `Day`, 1–15 inclurait les jours 1 à 15 du mois spécifié.
+ Le caractère générique **\$1** (astérisque) inclut toutes les valeurs du champ. Dans le champ `Hours`, **\$1** inclut chaque heure.
+ Le caractère générique **/** (barre oblique) spécifie les incréments. Dans le champ `Minutes`, vous pouvez saisir **1/10** pour spécifier un dixième de minute, en démarrant de la première minute de l'heure (par exemple, les 11e, 21e et 31e minutes).
+ Le caractère générique **?** (point d’interrogation) indique l’un ou l’autre. Dans le `Day-of-month` champ, tu pouvais saisir **7**, et si tu ne te souciais pas du jour de la semaine le septième, tu pourrais entrer **?** sur le Day-of-week terrain.
+ Le caractère générique **L** dans les champs ou spécifie le dernier jour du mois ou de la semaine.`Day-of-month``Day-of-week`
+ Le caractère générique **W** dans le champ spécifie un jour de la semaine. `Day-of-month` Dans le champ `Day-of-month`, `3W` spécifie le jour le plus proche du troisième jour de semaine du mois.

**Restrictions**
+ Vous ne pouvez pas spécifier les champs `Day-of-month` et `Day-of-week` de la même expression cron. Si vous spécifiez une valeur dans l’un de ces champs, vous devez utiliser un signe **?** (point d’interrogation) dans l’autre.
+ Les expressions cron qui entraînent des fréquences d'une rapidité supérieure à 5 minutes ne sont pas prises en charge. 

**Exemples**  
Lors de la création d’une planification, vous pouvez utiliser les exemples de chaînes cron suivants.


| Minutes | Heures | Jour du mois | Mois | Jour de la semaine | Année | Signification | 
| --- | --- | --- | --- | --- | --- | --- | 
|  0 USD  |  10  |  \$1  |  \$1  |  ?  |  \$1  |  Exécuter à 10 h 00 (UTC) chaque jour  | 
|  15  |  12  |  \$1  |  \$1  |  ?  |  \$1  |  Exécuter à 12 h 15 (UTC) chaque jour  | 
|  0  |  18  |  ?  |  \$1  |  MON-FRI  |  \$1  |  Exécuter à 18 h 00 (UTC) du lundi au vendredi  | 
|  0  |  8  |  1  |  \$1  |  ?  |  \$1  |  Exécuter à 8 h 00 (UTC) chaque 1er jour du mois  | 
|  0/15  |  \$1  |  \$1  |  \$1  |  ?  |  \$1  |  Exécuter toutes les 15 minutes  | 
|  0/10  |  \$1  |  ?  |  \$1  |  MON-FRI  |  \$1  |  Exécuter toutes les 10 minutes du lundi au vendredi  | 
|  0/5  |  8–17  |  ?  |  \$1  |  MON-FRI  |  \$1  |  Exécuter toutes les 5 minutes du lundi au vendredi entre 8 h 00 et 17 h 55 (UTC)  | 

Par exemple, pour une exécution quotidienne à 12 h 15 UTC, spécifiez :

```
cron(15 12 * * ? *)   
```

# Activation et désactivation des déclencheurs
<a name="activate-triggers"></a>

Vous pouvez activer ou désactiver un déclencheur à l'aide de la AWS Glue console, du AWS Command Line Interface (AWS CLI) ou de l'AWS GlueAPI.

**Pour activer ou désactiver un déclencheur (console)**

1. Connectez-vous à la AWS Glue console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 

1. Dans le panneau de navigation, sous **ETL**, choisissez **Triggers (Déclencheurs)**.

1. Activez la case à cocher en regard du déclencheur souhaité et, dans le menu **Action**, choisissez **Enable trigger (Activer le déclencheur)** pour activer le déclencheur ou **Disable trigger (Désactiver le déclencheur)** pour désactiver le déclencheur.

**Pour activer ou désactiver un déclencheur (AWS CLI)**
+ Entrez l'une des commandes suivantes.

  ```
  aws glue start-trigger --name MyTrigger  
  
  aws glue stop-trigger --name MyTrigger
  ```

  Le démarrage d'un déclencheur l'active, tandis que l'arrêt d'un déclencheur le désactive. Lorsque vous activez un déclencheur à la demande, il s'exécute immédiatement.

Pour de plus amples informations, veuillez consulter [Déclencheurs AWS Glue](about-triggers.md).

# Exécution d'activités ETL complexes à l'aide de plans et de flux de travail dans AWS Glue
<a name="orchestrate-using-workflows"></a>

Certains des processus d'extraction, transformation et chargement (ETL) complexes de votre organisation peuvent être mieux mis en œuvre en utilisant plusieurs tâches et crawlers qui dépendent de AWS Glue. Grâce aux *flux de travail AWS Glue*, vous pouvez concevoir un processus ETL complexe multi-tâches et à crawlers multiples que AWS Glue peut exécuter et suivre en tant qu'entité unique. Une fois que vous avez créé un flux de travail et spécifié les tâches, les crawlers et les déclencheurs dans le flux de travail, vous pouvez exécuter le flux de travail à la demande ou selon un planning.

**Topics**
+ [Présentation des flux de travail dans AWS Glue](workflows_overview.md)
+ [Création et développement d'un flux de travail manuellement dans AWS Glue](creating_running_workflows.md)
+ [Démarrer un AWS Glue flux de travail avec un EventBridge événement Amazon](starting-workflow-eventbridge.md)
+ [Afficher les EventBridge événements qui ont lancé un flux de travail](viewing-start-event-info.md)
+ [Exécution et surveillance d'un flux de travail dans AWS Glue](running_monitoring_workflow.md)
+ [Arrêt d'une exécution de flux de travail](workflow-stopping.md)
+ [Réparation et reprise de l'exécution d'un flux de travail](resuming-workflow.md)
+ [Obtention et définition des propriétés d'exécution du flux de travail dans AWS Glue](workflow-run-properties-code.md)
+ [Interrogation des flux de travail à l'aide du AWS Glue API](workflows_api_concepts.md)
+ [Restrictions du plan et du flux de travail dans AWS Glue](blueprint_workflow_restrictions.md)
+ [Résolution des erreurs de plans dans AWS Glue](blueprint_workflow_troubleshoot.md)
+ [Autorisations de personas et de rôles pour les plans AWS Glue](blueprints-personas-permissions.md)

# Présentation des flux de travail dans AWS Glue
<a name="workflows_overview"></a>

Dans AWS Glue, vous pouvez utiliser les flux de travail pour créer et visualiser les activités complexes d'extraction, de transformation et de chargement (ETL) impliquant plusieurs crawlers, tâches et déclencheurs. Chaque flux de travail gère l'exécution et la surveillance de l'ensemble de ses tâches et crawlers. Tandis qu'un flux de travail exécute chaque composant, il enregistre le statut et la progression de l'exécution. Vous trouverez ainsi une présentation de la tâche la plus volumineuses et les détails de chaque étape. La console AWS Glue fournit une représentation visuelle d'un flux de travail sous forme de graphique.

Vous pouvez créer un flux de travail à partir d'un AWS Glue plan, ou vous pouvez créer manuellement un flux de travail composant par composant à l'aide du AWS Management Console ou du AWS Glue API. Pour plus d'informations sur les modèles de présentation, consultez [Présentation des plans dans AWS Glue](blueprints-overview.md).

Les *déclencheurs* dans les flux de travail peuvent démarrer les tâches ou les crawlers, et peuvent être déclenchés lorsque les tâches et les crawlers ont terminé leurs opérations. En utilisant des déclencheurs, vous pouvez créer de grandes chaînes de tâches et d'crawlers interdépendants. En plus des déclencheurs au sein d'un flux de travail qui définissent les dépendances des tâches et de l'crawler, chaque flux de travail a un *déclencheur de démarrage*. Il existe trois types de déclencheurs :
+ **Schedule** (Planification) - le flux de travail est démarré selon un planificateur que vous définissez. La planification peut être quotidienne, hebdomadaire, mensuelle, etc., ou peut être une planification personnalisée basée sur une expression `cron`.
+ **À la demande** : le flux de travail est démarré manuellement depuis la AWS Glue console, l'API ou AWS CLI.
+ **EventBridge événement** — Le flux de travail est lancé lors de la survenance d'un seul EventBridge événement Amazon ou d'un lot d' EventBridge événements Amazon. Avec ce type de déclencheur, AWS Glue peut être un consommateur d'événements dans une architecture événementielle. Tout type EventBridge d'événement peut démarrer un flux de travail. L'arrivée d'un nouvel objet dans un compartiment Amazon S3 (l'opération `PutObject` S3) fait partie des cas d'utilisation les plus courants. 

  Démarrer un flux de travail avec un lot d'événements signifie attendre qu'un nombre spécifié d'événements ait été reçu ou qu'un laps de temps spécifié se soit écoulé. Lorsque vous créez le déclencheur EventBridge d'événement, vous pouvez éventuellement spécifier les conditions du lot. Si vous spécifiez des conditions de lot, vous devez spécifier la taille du lot (nombre d'événements) et pouvez éventuellement spécifier une fenêtre de lot (nombre de secondes). La fenêtre de lot par défaut et maximale est de 900 secondes (15 minutes). La condition de lot qui est remplie démarre en premier le flux de travail. La fenêtre de traitement par lots démarre lorsque le premier événement arrive. Si vous ne spécifiez pas de conditions de lot lors de la création d'un déclencheur, la taille du lot par défaut est 1.

  Lorsque le flux de travail démarre, les conditions du lot sont réinitialisées et le déclencheur d'événement commence à surveiller la prochaine condition de lot à remplir pour redémarrer le flux de travail.

  Le tableau suivant montre comment la taille du lot et la fenêtre de lot fonctionnent ensemble pour déclencher un flux de travail.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/workflows_overview.html)

  L'opération d'API `GetWorkflowRun` renvoie la condition de lot qui a déclenché le flux de travail.

Quel que soit le mode de démarrage d'un flux de travail, vous pouvez spécifier le nombre maximal d'exécutions simultanées de flux de travail lorsque vous créez le flux de travail.

Si un événement ou un lot d'événements démarre une exécution de flux de travail qui échoue finalement, cet événement ou lot d'événements n'est plus pris en compte pour démarrer une exécution de flux de travail. Une nouvelle exécution de flux de travail est démarrée uniquement lorsque le prochain événement ou lot d'événements se présente.

**Important**  
Limitez le nombre total de tâches, de crawlers et de déclencheurs au sein d'un flux de travail à 100 ou moins. Si vous en incluez plus de 100, vous risquez de rencontrer des erreurs lorsque vous tentez de reprendre ou d'arrêter les exécutions du flux de travail.

Une exécution de flux de travail ne démarrera pas si elle dépasse la limite de simultanéité définie pour le flux de travail, même si la condition d'événement est remplie. Il est conseillé d'ajuster les limites de simultanéité du flux de travail en fonction du volume d'événements attendu. AWS Glue ne retente pas les exécutions de flux de travail qui échouent en raison du dépassement des limites de simultanéité. De même, il est conseillé d'ajuster les limites de simultanéité pour les tâches et les crawlers dans les flux de travail en fonction du volume d'événements attendu.

**Propriétés de l'exécution du flux de travail**  
Pour partager et gérer l'état tout au long de l'exécution d'un flux de travail, vous pouvez définir des propriétés d'exécution de flux de travail par défaut. Ces propriétés, qui sont des name/value paires, sont disponibles pour toutes les tâches du flux de travail. À l'aide de AWS Glue API, les tâches peuvent récupérer les propriétés d'exécution du flux de travail et les modifier pour les tâches qui seront ajoutées ultérieurement dans le flux de travail.

**Graphique de flux de travail**  
L'image suivante illustre le graphique d'un flux de travail vraiment de base sur la console AWS Glue. Votre flux de travail peut avoir des douzaines de composants.

![\[Capture d'écran de la console affichant l'onglet Graph (Graphique) d'un flux de travail. Le graphique contient 5 icônes représentant un déclencheur de calendrier, 2 tâches, un déclencheur de réussite d'un événement et un crawler qui met à jour le schéma.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/graph-complete-with-tabs.png)


Ce flux de travail est démarré par un déclencheur de calendrier, `Month-close1`, qui lance deux tâches, `De-duplicate` et `Fix phone numbers`. Lorsque vous avez validé les deux tâches, un déclencheur d'événement, `Fix/De-dupe succeeded`, lance un crawler, `Update schema`.

**Affichages de flux de travail statiques et dynamiques**  
Pour chaque flux de travail, il existe la notion de *vue statique* et *de vue dynamique*. La conception statique indique la conception du flux de travail. L'affichage dynamique est une vue de l'exécution qui inclut les dernières informations d'exécution pour chacune des tâches et chacun des crawlers. Les informations d'exécution inclut le statut de succès et les informations détaillées d'erreur. 

Lorsqu'un flux de travail est en cours d'exécution, la console affiche la vue dynamique, indiquant graphiquement les tâches qui se sont terminées et celles qu'il reste à exécuter. Vous pouvez également extraire la vue dynamique d'un flux de travail en cours d'exécution avec AWS Glue API. Pour de plus amples informations, veuillez consulter [Interrogation des flux de travail à l'aide du AWS Glue API](workflows_api_concepts.md).

**Consultez aussi**  
[Création d'un flux de travail à partir d'un plan dans AWS Glue](creating_workflow_blueprint.md)
[Création et développement d'un flux de travail manuellement dans AWS Glue](creating_running_workflows.md)
[Flux de travail](aws-glue-api-workflow.md) (pour l'API de flux de travail)

# Création et développement d'un flux de travail manuellement dans AWS Glue
<a name="creating_running_workflows"></a>

Vous pouvez utiliser la console AWS Glue pour créer et développer manuellement un flux de travail un nœud à la fois.

Un flux de travail contient des tâches, des crawlers et des déclencheurs. Avant de créer un flux de travail manuellement, créez les tâches et les crawlers que le flux de travail doit inclure. Il est préférable de spécifier des robots d' run-on-demandexploration pour les flux de travail. Vous pouvez créer de nouveaux déclencheurs lors du développement de de votre flux de travail ou vous pouvez *cloner* des déclencheurs existants dans le flux de travail. Lorsque vous clonez un déclencheur, tous les objets du catalogue associés au déclencheur (les tâches ou les crawlers qui le déclenchent et les tâches ou les crawlers qu'il démarre) sont ajoutés au flux de travail.

**Important**  
Limitez le nombre total de tâches, de crawlers et de déclencheurs au sein d'un flux de travail à 100 ou moins. Si vous en incluez plus de 100, vous risquez de rencontrer des erreurs lorsque vous tentez de reprendre ou d'arrêter les exécutions du flux de travail.

Vous développez votre flux de travail en ajoutant des déclencheurs au graphique du flux de travail et en définissant les événements et les actions observés pour chaque déclencheur. Vous commencez par un *déclencheur de début*, qui peut être un déclencheur à la demande ou un déclencheur de planification, et complétez le graphique en ajoutant des déclencheurs d'événements (conditionnels).

## Étape 1 : Créer le flux de travail
<a name="workflow-step1"></a>

1. Connectez-vous à la AWS Glue console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

1. Dans le panneau de navigation, sous **ETL**, sélectionnez **Workflows (Flux de travail)**.

1. Sélectionnez **Add workflow (Ajouter un flux de travail)** et remplissez le formulaire **Add a new ETL workflow (Ajouter un nouveau flux de travail ETL)**.

   Toutes les propriétés d'exécution par défaut facultatives que vous ajoutez sont rendues disponibles en tant qu'arguments à toutes les tâches du flux de travail. Pour de plus amples informations, veuillez consulter [Obtention et définition des propriétés d'exécution du flux de travail dans AWS Glue](workflow-run-properties-code.md).

1. Sélectionnez **Add workflow (Ajouter un flux de travail)**.

   Le nouveau flux de travail s'affiche dans la liste sur la page **Workflows (Flux de travail)**.

## Étape 2 : Ajouter un déclencheur de début
<a name="workflow-step2"></a>

1. Sur la page **Workflows (Flux de travail)**, sélectionnez votre nouveau flux de travail. Ensuite, en bas de la page, assurez-vous que l'onglet **Graph (Graphique)** est sélectionné.

1. Choisissez **Add trigger (Ajouter un déclencheur)**, puis, dans la boîte dedialogue **Add trigger (Ajouter un déclencheur)**, effectuez l'une des actions suivantes :
   + Choisissez **Clone existing (Clone existant)**, puis choisissez un déclencheur à cloner. Choisissez ensuite **Ajouter**.

     Le déclencheur s'affiche sur le graphique, ainsi que les tâches et les crawlers qu'il surveille, et les tâches et les crawlers qu'il démarre.

     Si vous avez sélectionné par erreur le mauvais déclencheur, sélectionnez le déclencheur sur le graphique, puis choisissez **Remove (Supprimer)**.
   + Choisissez **Add new (Ajouter un nouveau)** et complétez le formulaire **Add trigger (Ajouter un déclencheur)**.

     1. Pour le **type de déclencheur**, sélectionnez **Planification**, **À la demande** ou **EventBridgeévénement**.

        Pour le type de déclencheur **Schedule (Planification)**, sélectionnez l'une des options **Frequency (Fréquence)**. Sélectionnez **Custom (Personnalisée)** pour saisir une expression `cron`.

        Pour un **EventBridge événement** de type déclencheur, entrez **Nombre d'événements** (taille du lot) et entrez éventuellement **Délai** (fenêtre de lot). Si vous omettez **Time delay (Délai)**, la fenêtre de lot est définie par défaut sur 15 minutes. Pour de plus amples informations, veuillez consulter [Présentation des flux de travail dans AWS Glue](workflows_overview.md).

     1. Choisissez **Ajouter**.

     Le déclencheur s'affiche sur le graphique, ainsi qu'un nœud d'espace réservé (nommé **Add node (Ajouter un nœud)**). Dans l'exemple ci-dessous, le déclencheur de démarrage est un déclencheur de planification nommé `Month-close1`. 

     À ce stade, le déclencheur n'est pas encore enregistré.  
![\[Un graphique avec deux nœuds rectangulaires : un déclencheur et un nœud d'espace réservé. Une flèche pointe du nœud du déclencheur vers le nœud de l'espace réservé.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/graph-start-trigger.png)

1. Si vous avez ajouté un nouveau déclencheur, procédez comme suit :

   1. Effectuez l'une des actions suivantes :
      + Choisissez le nœud d'espace réservé (**Add node (Ajouter un nœud)**).
      + Assurez-vous que le déclencheur de démarrage est sélectionné, puis dans le menu **Action** au-dessus du graphique, choisissez **Ajouter jobs/crawlers au déclencheur**.

   1. Dans la boîte de dialogue **Add jobs(s) and crawler(s) to trigger (Ajouter des tâches et des crawlers au déclencheur)**, sélectionnez une ou plusieurs tâches ou crawlers, puis sélectionnez **Add (Ajouter)**.

      Le déclencheur est enregistré, et les tâches ou crawlers sélectionnés apparaissent sur le graphique avec les connecteurs du déclencheur.

      Si vous avez ajouté par erreur les mauvaises tâches ou les mauvais crawlers, vous pouvez sélectionner le déclencheur ou un connecteur et choisir **Remove (Supprimer)**.

## Étape 3 : Ajouter d'autres déclencheurs
<a name="workflow-step3"></a>

Continuez de développer votre flux de travail en ajoutant d'autres déclencheurs de type **Event (Événement)**. Pour faire un zoom avant ou arrière ou pour agrandir le canevas du graphique, utilisez les icônes à la droite du graphique. Pour chaque déclencheur à ajouter, effectuez les opérations suivantes :

**Note**  
Il n'existe aucune action pour enregistrer le flux de travail. Après avoir ajouté votre dernier déclencheur et affecté des actions au déclencheur, le flux de travail est terminé et enregistré. Vous pouvez toujours revenir plus tard et ajouter plus de nœuds.

1. Effectuez l'une des actions suivantes :
   + Pour cloner un déclencheur existant, assurez-vous qu'aucun nœud sur le graphique ne soit sélectionné, et sur le menu **Action**, choisissez **Add trigger (Ajouter un déclencheur)**.
   + Pour ajouter un nouveau déclencheur qui surveille une tâche particulière ou un crawler particulier sur le graphique, sélectionnez le nœud de la tâche ou de l'crawler, puis choisissez le nœud d'espace réservé **Add trigger (Ajouter un déclencheur)**.

     Vous pouvez ajouter d'autres tâches ou crawlers à surveiller pour ce déclencheur dans une étape ultérieure.

1.  Dans la boîte de dialogue **Add trigger (Ajouter un déclencheur)**, exécutez l'une des actions suivantes :
   + Choisissez **Add new (Ajouter un nouveau)** et complétez le formulaire **Add trigger (Ajouter un déclencheur)**. Choisissez ensuite **Ajouter**.

     Le déclencheur s'affiche sur le graphique. Vous complèterez le déclencheur lors d'une étape ultérieure.
   + Choisissez **Clone existing (Clone existant)**, puis choisissez un déclencheur à cloner. Choisissez ensuite **Ajouter**.

     Le déclencheur s'affiche sur le graphique, ainsi que les tâches et les crawlers qu'il surveille, et les tâches et les crawlers qu'il démarre.

     Si vous avez choisi par erreur le mauvais déclencheur, sélectionnez le déclencheur sur le graphique, puis choisissez **Remove (Supprimer)**.

1. Si vous avez ajouté un nouveau déclencheur, procédez comme suit :

   1. Sélectionnez le nouveau déclencheur.

      Comme l'illustre le graphique suivant, le déclencheur `De-dupe/fix succeeded` est sélectionné et les nœuds d'espace réservé apparaissent pour (1) les événements à surveiller et pour (2) les actions.  
![\[Un graphique avec plusieurs nœuds, dont deux sont des nœuds d'espace réservé qui sont indiqués en tant que nombres 1 et 2.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/graph-dual-placeholders.png)

   1. (Facultatif si le déclencheur surveille déjà un événement et que vous souhaitez ajouter davantage de tâches ou d'crawlers à surveiller.) Choisissez le nœud events-to-watch réservé, puis dans la boîte de dialogue **Ajouter des tâches et des robots à surveiller**, sélectionnez un ou plusieurs travaux ou robots d'exploration. Choisissez un événement à surveiller (SUCCEEDED, FAILED, etc.), puis choisissez **Add (Ajouter)**.

   1. Assurez-vous que le déclencheur est sélectionné, puis choisissez le nœud d'espace réservé des actions.

   1. Dans la boîte de dialogue **Add job(s) and crawler(s) to watch (Ajouter des tâches et des crawlers à surveiller)** sélectionnez une ou plusieurs tâches ou un ou plusieurs crawlers, et choisissez **Add (Ajouter)**.

      Les tâches et les crawlers sélectionnés apparaissent sur le graphique, avec les connecteurs du déclencheur.

Pour en savoir plus sur les flux de travail et les plans, consultez les rubriques suivantes.
+ [Présentation des flux de travail dans AWS Glue](workflows_overview.md)
+ [Exécution et surveillance d'un flux de travail dans AWS Glue](running_monitoring_workflow.md)
+ [Création d'un flux de travail à partir d'un plan dans AWS Glue](creating_workflow_blueprint.md)

# Démarrer un AWS Glue flux de travail avec un EventBridge événement Amazon
<a name="starting-workflow-eventbridge"></a>

Amazon EventBridge, également connu sous le nom d' CloudWatch Events, vous permet d'automatiser vos AWS services et de répondre automatiquement aux événements du système tels que les problèmes de disponibilité des applications ou les modifications des ressources. Les événements AWS liés aux services sont diffusés EventBridge en temps quasi réel. Vous pouvez écrire des règles simples pour indiquer quels événements vous intéressent et les actions automatisées à effectuer quand un événement correspond à une règle.

Avec du EventBridge support, il AWS Glue peut servir de producteur et de consommateur d'événements dans une architecture axée sur les événements. Pour les flux de travail, AWS Glue prend en charge tout type d' EventBridge événement en tant que consommateur. Le cas d'utilisation le plus courant est l'arrivée d'un nouvel objet dans un compartiment Amazon S3. Si vous avez des données arrivant à des intervalles irréguliers ou indéfinis, vous pouvez traiter ces données aussi près que possible de leur arrivée.

**Note**  
AWS Gluene garantit pas la livraison des EventBridge messages. AWS Gluen'effectue aucune déduplication s'il EventBridge délivre des messages dupliqués. Vous devez gérer l'idempotence en fonction de votre cas d'utilisation.  
Assurez-vous de configurer correctement EventBridge les règles pour éviter d'envoyer des événements indésirables.

**Avant de commencer**  
Si vous souhaitez démarrer un flux de travail avec des événements de données Amazon S3, vous devez vous assurer que les événements du compartiment S3 qui vous intéresse sont enregistrés dans AWS CloudTrail et EventBridge. Pour ce faire, vous devez créer un CloudTrail parcours. Pour plus d'informations, consultez [la section Création d'un historique pour votre AWS compte](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html).

**Pour démarrer un flux de travail avec un EventBridge événement**
**Note**  
Dans les commandes suivantes, remplacez :  
*<workflow-name>*avec le nom à attribuer au flux de travail.
*<trigger-name>*avec le nom à attribuer au déclencheur.
*<bucket-name>*avec le nom du compartiment Amazon S3.
*<account-id>*avec un identifiant de AWS compte valide.
*<region>*avec le nom de la région (par exemple,`us-east-1`).
*<rule-name>*avec le nom à attribuer à la EventBridge règle.

1. Assurez-vous que vous disposez des autorisations Gestion des identités et des accès AWS (IAM) nécessaires pour créer et afficher les EventBridge règles et les cibles. Voici un modèle de politique de clé que vous pouvez attacher. Vous voudrez peut-être restreindre sa portée afin d'imposer des limites aux opérations et aux ressources.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "events:PutRule",
           "events:DisableRule",
           "events:DeleteRule",
           "events:PutTargets",
           "events:RemoveTargets",
           "events:EnableRule",
           "events:List*",
           "events:Describe*"
         ],
         "Resource": "*"
       }
     ]
   }
   ```

------

1. Créez un rôle IAM que le EventBridge service peut assumer lorsqu'il transmet un événement àAWS Glue.

   1. Sur la page **Création d'un rôle** de la console IAM, sélectionnez **Service AWS **. Choisissez ensuite le service **CloudWatch Events**.

   1. Suivez intégralement l'assistant de **Création d'un rôle**. L'Assistant attache automatiquement les politiques `CloudWatchEventsBuiltInTargetExecutionAccess` et `CloudWatchEventsInvocationAccess`.

   1. Attachez la politique en ligne suivante au rôle. Cette politique permet au EventBridge service de diriger les événements versAWS Glue.

------
#### [ JSON ]

****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "glue:notifyEvent"
            ],
            "Resource": [
              "arn:aws:glue:us-east-1:111122223333:workflow/workflow-name"
            ]
          }
        ]
      }
      ```

------

1. Saisissez la commande suivante pour créer le flux de travail.

   Veuillez consulter la rubrique [create-workflow](https://docs.aws.amazon.com/cli/latest/reference/glue/create-workflow.html) dans la *Référence des commandes AWS CLI * pour plus d'informations sur les paramètres de ligne de commande facultatifs supplémentaires.

   ```
   aws glue create-workflow --name <workflow-name>
   ```

1. Entrez la commande suivante pour créer un déclencheur d' EventBridge événement pour le flux de travail. Ce sera le déclencheur de démarrage du flux de travail. Remplacez *<actions>* par les actions à effectuer (les tâches et les robots d'exploration pour démarrer).

   Veuillez consulter la rubrique [create-trigger](https://docs.aws.amazon.com/cli/latest/reference/glue/create-trigger.html)dans la *Référence des commandes AWS CLI * pour obtenir des informations sur la manière de coder les arguments `actions`.

   ```
   aws glue create-trigger --workflow-name <workflow-name> --type EVENT --name <trigger-name> --actions <actions>
   ```

   Si vous souhaitez que le flux de travail soit déclenché par un lot d'événements plutôt que par un seul EventBridge événement, entrez plutôt la commande suivante.

   ```
   aws glue create-trigger --workflow-name <workflow-name> --type EVENT --name <trigger-name> --event-batching-condition BatchSize=<number-of-events>,BatchWindow=<seconds> --actions <actions>
   ```

   En ce qui concerne les arguments `event-batching-condition`, `BatchSize` est obligatoire et `BatchWindow` est facultatif. Si `BatchWindow` est omis, la fenêtre est définie par défaut à 900 secondes, ce qui correspond à la taille maximale de la fenêtre.  
**Example**  

   L'exemple suivant crée un déclencheur qui démarre le `eventtest` flux de travail après l'arrivée de trois EventBridge événements, ou cinq minutes après l'arrivée du premier événement, selon la première éventualité.

   ```
   aws glue create-trigger --workflow-name eventtest --type EVENT --name objectArrival --event-batching-condition BatchSize=3,BatchWindow=300 --actions JobName=test1
   ```

1. Créez une règle sur Amazon EventBridge. 

   1. Créer l'objet JSON définissant les détails de la règle dans votre éditeur de texte préféré. 

      L'exemple suivant spécifie Amazon S3 comme source d'événement, `PutObject` comme nom de l'événement, et le nom du compartiment en tant que paramètre de requête. Cette règle démarre un flux de travail lorsqu'un nouvel objet arrive dans le compartiment.

      ```
      {
        "source": [
          "aws.s3"
        ],
        "detail-type": [
          "AWS API Call via CloudTrail"
        ],
        "detail": {
          "eventSource": [
            "s3.amazonaws.com"
          ],
          "eventName": [
            "PutObject"
          ],
          "requestParameters": {
            "bucketName": [
              "<bucket-name>"
            ]
          }
        }
      }
      ```

      Pour démarrer le flux de travail lorsqu'un nouvel objet arrive dans un dossier du compartiment, vous pouvez introduire le code suivant dans `requestParameters`.

      ```
          "requestParameters": {
            "bucketName": [
              "<bucket-name>"
            ]
            "key" : [{ "prefix" : "<folder1>/<folder2>/*"}}]
        }
      ```

   1. Utilisez votre outil préféré pour convertir l'objet JSON de définition de règle en une chaîne échappée.

      ```
      {\n  \"source\": [\n    \"aws.s3\"\n  ],\n  \"detail-type\": [\n    \"AWS API Call via CloudTrail\"\n  ],\n  \"detail\": {\n    \"eventSource\": [\n      \"s3.amazonaws.com\"\n    ],\n    \"eventName\": [\n      \"PutObject\"\n    ],\n    \"requestParameters\": {\n      \"bucketName\": [\n        \"<bucket-name>\"\n      ]\n    }\n  }\n}
      ```

   1. Exécutez la commande suivante pour créer un modèle de paramètre JSON que vous pouvez modifier afin de spécifier les paramètres d'entrée d'une commande `put-rule` ultérieure. Enregistrez le résultat dans un fichier. Dans cet exemple, le fichier est nommé `ruleCommand`.

      ```
      aws events put-rule --name <rule-name> --generate-cli-skeleton >ruleCommand
      ```

      Pour de plus amples informations sur le paramètre `--generate-cli-skeleton`, veuillez consulter la rubrique [Génération du squelette AWS CLI et des paramètres d'entrée à partir d'un fichier d'entrée JSON ou YAML](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-skeleton.html) dans le *Guide de l'utilisateur de l'interface de ligne de commande AWS *.

      Le fichier de sortie devrait ressembler à ce qui suit.

      ```
      {
          "Name": "",
          "ScheduleExpression": "",
          "EventPattern": "",
          "State": "ENABLED",
          "Description": "",
          "RoleArn": "",
          "Tags": [
              {
                  "Key": "",
                  "Value": ""
              }
          ],
          "EventBusName": ""
      }
      ```

   1. Modifiez le fichier pour supprimer éventuellement des paramètres et pour spécifier au minimum les paramètres `Name`, `EventPattern` et `State`. Pour le paramètre `EventPattern`, fournissez la chaîne d'échappement des détails de règle que vous avez créé à l'étape précédente. 

      ```
      {
          "Name": "<rule-name>",
          "EventPattern": "{\n  \"source\": [\n    \"aws.s3\"\n  ],\n  \"detail-type\": [\n    \"AWS API Call via CloudTrail\"\n  ],\n  \"detail\": {\n    \"eventSource\": [\n      \"s3.amazonaws.com\"\n    ],\n    \"eventName\": [\n      \"PutObject\"\n    ],\n    \"requestParameters\": {\n      \"bucketName\": [\n        \"<bucket-name>\"\n      ]\n    }\n  }\n}",
          "State": "DISABLED",
          "Description": "Start an AWS Glue workflow upon new file arrival in an Amazon S3 bucket"
      }
      ```
**Note**  
Il est préférable de laisser la règle désactivée jusqu'à ce que vous ayez terminé la création du flux de travail.

   1. Saisissez la commande `put-rule` suivante, qui lit les paramètres d'entrée dans le fichier `ruleCommand`.

      ```
      aws events put-rule --name <rule-name> --cli-input-json file://ruleCommand
      ```

      La sortie suivante indique que l'opération a réussi.

      ```
      {
          "RuleArn": "<rule-arn>"
      }
      ```

1. Saisissez la commande suivante pour attacher la règle à une cible. La cible est le flux de travail dans AWS Glue. *<role-name>*Remplacez-le par le rôle que vous avez créé au début de cette procédure.

   ```
   aws events put-targets --rule <rule-name> --targets "Id"="1","Arn"="arn:aws:glue:<region>:<account-id>:workflow/<workflow-name>","RoleArn"="arn:aws:iam::<account-id>:role/<role-name>" --region <region>
   ```

   La sortie suivante indique que l’opération a réussi.

   ```
   {
       "FailedEntryCount": 0,
       "FailedEntries": []
   }
   ```

1. Confirmez la connexion réussie de la règle et de la cible en saisissant la commande suivante.

   ```
   aws events list-rule-names-by-target --target-arn arn:aws:glue:<region>:<account-id>:workflow/<workflow-name>
   ```

   Le résultat suivant indique un succès, où *<rule-name>* est le nom de la règle que vous avez créée.

   ```
   {
       "RuleNames": [
           "<rule-name>"
       ]
   }
   ```

1. Connectez-vous à la AWS Glue console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

1. Sélectionnez le flux de travail et vérifiez que le déclencheur de démarrage et ses actions (les tâches ou les crawlers qu'il démarre) apparaissent sur le graphique du flux de travail. Procédez ensuite comme indiqué dans [Étape 3 : Ajouter d'autres déclencheurs](creating_running_workflows.md#workflow-step3). Vous pouvez également ajouter d'autres composants au flux de travail en utilisant l'API AWS Glue ou AWS Command Line Interface.

1. Lorsque le flux de travail est entièrement défini, activez la règle.

   ```
   aws events enable-rule --name <rule-name>
   ```

   Le flux de travail est maintenant prêt à être lancé par un EventBridge événement ou un lot d'événements.

**Consultez aussi**  
[https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
[Présentation des flux de travail dans AWS Glue](workflows_overview.md)
[Création et développement d'un flux de travail manuellement dans AWS Glue](creating_running_workflows.md)

# Afficher les EventBridge événements qui ont lancé un flux de travail
<a name="viewing-start-event-info"></a>

Vous pouvez consulter l'ID de l' EventBridge événement Amazon qui a lancé votre flux de travail. Si votre flux de travail a été lancé par un lot d'événements, vous pouvez afficher l'événement IDs de tous les événements du lot.

Pour les flux de travail dont la taille de lot est supérieure à un, vous pouvez également voir quelle condition de lot a démarré le flux de travail : l'arrivée du nombre d'événements dans la taille du lot ou l'expiration de la fenêtre de lot.

**Pour afficher les EventBridge événements qui ont lancé un flux de travail (console)**

1. Connectez-vous à la AWS Glue console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

1. Dans le panneau de navigation, sous ETL, sélectionnez **Workflows (Flux de travail)**.

1. Sélectionnez un flux de travail. Puis, en bas, sélectionnez l'onglet **History (Historique)**.

1. Sélectionnez un flux de travail, puis sélectionnez **View run details (Afficher les détails de l'exécution)**.

1. Sur la page de détails de l'exécution, repérez le champ **Run properties (Propriétés d'exécution)**, et recherchez la clé **aws:eventIds**.

   La valeur de cette clé est une liste d' EventBridge événements IDs.

**Pour afficher les EventBridge événements qui ont démarré un flux de travail (AWS API)**
+ Incluez le code suivant dans votre script Python.

  ```
  workflow_params = glue_client.get_workflow_run_properties(Name=workflow_name,RunId=workflow_run_id)
  batched_events = workflow_params['aws:eventIds']
  ```

  `batched_events` sera une liste de chaînes, chaque chaîne étant un ID d'événement.

**Consultez aussi**  
[https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
[Présentation des flux de travail dans AWS Glue](workflows_overview.md)

# Exécution et surveillance d'un flux de travail dans AWS Glue
<a name="running_monitoring_workflow"></a>

Si le déclencheur de début d'un flux de travail est un déclencheur à la demande, vous pouvez démarrer le flux de travail à partir de la console AWS Glue. Procédez comme suit pour exécuter et surveiller un flux de travail. Si le flux de travail échoue, vous pouvez afficher le graphique d'exécution pour déterminer le nœud qui a échoué. Pour faciliter le dépannage, si le flux de travail a été créé à partir d'un modèle, vous pouvez afficher l'exécution ce dernier pour voir les valeurs des paramètres de modèle qui ont été utilisées pour créer le flux de travail. Pour de plus amples informations, veuillez consulter [Affichage des exécutions du plan dans AWS Glue](viewing_blueprint_runs.md).

Vous pouvez exécuter et surveiller un flux de travail à l'aide de la console AWS Glue, l'API ou AWS Command Line Interface (AWS CLI).

**Pour exécuter et surveiller un flux de travail (console)**

1. Ouvrez la AWS Glue console à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

1. Dans le panneau de navigation, sous **ETL**, sélectionnez **Workflows (Flux de travail)**.

1. Sélectionnez un flux de travail. Dans le menu **Actions**, choisissez **Run (Exécuter)**.

1. Vérifiez la colonne **Last run status** (Statut de la dernière exécution) dans la liste des flux de travail. Cliquez sur le bouton Refresh (Actualiser) pour afficher le statut du flux de travail en cours.

1. Pendant l'exécution du flux de travail ou une fois qu'il est terminé (ou a échoué), affichez les détails de l'exécution en effectuant les étapes suivantes.

   1. Assurez-vous que le flux de travail est sélectionné, puis sélectionnez l'onglet **History (Historique)**.

   1. Choisissez l'exécution de flux de travail actuelle ou la plus récente, puis sélectionnez **View run details** (Afficher les détails de l'exécution).

      Le graphique d'exécution du flux de travail affiche l'état d'exécution actuel.

   1. Choisissez n'importe quel nœud dans le graphique pour afficher ses détails et son état.  
![\[Le graphique d'exécution montre un déclencheur de démarrage, qui démarre une tâche. Un autre déclencheur surveille la fin de la tâche. Le nœud de tâche (un rectangle qui entoure une icône de presse-papiers et un nom de tâche) est sélectionné et les détails de la tâche sont affichés dans un volet à droite. Les détails de la tâche incluent l'ID d'exécution et le statut de la tâche.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/workflow-pre-select-resume.png)

**Pour exécuter et surveiller un flux de travail (AWS CLI)**

1. Entrez la commande suivante. Remplacez *<workflow-name>* par le flux de travail à exécuter.

   ```
   aws glue start-workflow-run --name <workflow-name>
   ```

   Si le flux de travail est démarré avec succès, la commande renvoie l'ID d'exécution.

1. Affichez le statut d'exécution du flux de travail à l'aide de la commande `get-workflow-run`. Indiquez le nom et l'ID d'exécution du flux de travail.

   ```
   aws glue get-workflow-run --name myWorkflow --run-id wr_d2af14217e8eae775ba7b1fc6fc7a42c795aed3cbcd8763f9415452e2dbc8705
   ```

   Voici un exemple de sortie de commande.

   ```
   {
       "Run": {
           "Name": "myWorkflow",
           "WorkflowRunId": "wr_d2af14217e8eae775ba7b1fc6fc7a42c795aed3cbcd8763f9415452e2dbc8705",
           "WorkflowRunProperties": {
               "run_state": "COMPLETED",
               "unique_id": "fee63f30-c512-4742-a9b1-7c8183bdaae2"
           },
           "StartedOn": 1578556843.049,
           "CompletedOn": 1578558649.928,
           "Status": "COMPLETED",
           "Statistics": {
               "TotalActions": 11,
               "TimeoutActions": 0,
               "FailedActions": 0,
               "StoppedActions": 0,
               "SucceededActions": 9,
               "RunningActions": 0,
               "ErroredActions": 0
           }
       }
   }
   ```

**Voir aussi :**  
[Présentation des flux de travail dans AWS Glue](workflows_overview.md)
[Présentation des plans dans AWS Glue](blueprints-overview.md)

# Arrêt d'une exécution de flux de travail
<a name="workflow-stopping"></a>

Vous pouvez utiliser la AWS Glue console AWS Command Line Interface (AWS CLI) ou l'AWS GlueAPI pour arrêter l'exécution d'un flux de travail. Lorsque vous arrêtez un cycle de flux de travail, toutes les tâches et tous les crawlers en cours d'exécution sont immédiatement arrêtés, tandis que ceux qui n'ont pas encore été lancés ne démarreront jamais. Cela peut prendre jusqu'à une minute pour que toutes les tâches et tous les crawlers en cours d'exécution s'arrêtent. L'état du cycle de flux de travail passe de **Running (Exécution en cours)** à **Stopping (Arrêt en cours)**, puis lorsque le cycle de flux de travail est complètement arrêté, l'état passe à **Stopped (Arrêté)**.

Une fois le cycle de flux de travail arrêté, vous pouvez afficher le graphique d'exécution pour voir les tâches et les crawlers abandonnés, ainsi que ceux qui n'ont jamais démarré. Vous pouvez ensuite déterminer si vous devez prendre des mesures spécifiques pour garantir l'intégrité des données. L'arrêt d'un cycle de flux de travail n'entraîne aucune opération de restauration automatique.

**Pour arrêter l'exécution d'un flux de travail (console)**

1. Ouvrez la AWS Glue console à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

1. Dans le panneau de navigation, sous **ETL**, sélectionnez **Workflows (Flux de travail)**.

1. Choisissez un flux de travail en cours d'exécution, puis choisissez l'onglet **History (Historique)**.

1. Choisissez le cycle de flux de travail, puis choisissez **Stop run (Arrêter ce cycle)**.

   L'état d'exécution passe à **Stopping (Arrêt en cours)**.

1. (Facultatif) Choisissez le cycle de flux de travail, puis **(Optional) Choose the workflow run, choose (Afficher les détails de l'exécution)** et consultez le graphique d'exécution.

**Pour arrêter un cycle de flux de travail (AWS CLI)**
+ Entrez la commande suivante. Remplacez *<workflow-name>* par le nom du flux de travail et *<run-id>* par l'ID d'exécution du flux de travail à arrêter.

  ```
  aws glue stop-workflow-run --name <workflow-name> --run-id <run-id>
  ```

  Voici un exemple de la commande **stop-workflow-run**.

  ```
  aws glue stop-workflow-run --name my-workflow --run-id wr_137b88917411d128081069901e4a80595d97f719282094b7f271d09576770354
  ```

# Réparation et reprise de l'exécution d'un flux de travail
<a name="resuming-workflow"></a>

 Si un ou plusieurs nœuds (tâches ou crawlers) d'un flux de travail ne se terminent pas correctement, cela signifie que le flux de travail n'a été exécuté que partiellement. Après avoir trouvé les causes premières et apporté des corrections, vous pouvez sélectionner un ou plusieurs nœuds à partir desquels reprendre l'exécution du flux de travail, puis reprendre celle-ci. Les nœuds sélectionnés et tous les nœuds en aval de ces nœuds sont ensuite exécutés.

**Topics**
+ [Reprise d'une exécution de flux de travail : comment ça marche](#resume-workflow-howitworks)
+ [Reprise de l'exécution d'un flux de travail](#how-to-resume-workflow)
+ [Remarques et limitations pour la reprise des exécutions de flux de travail](#resume-workflow-notes)

## Reprise d'une exécution de flux de travail : comment ça marche
<a name="resume-workflow-howitworks"></a>

Examinez le flux de travail W1 dans le diagramme suivant.

![\[Les déclencheurs sont affichés dans des rectangles et les tâches dans des cercles. Le déclencheur T1 à gauche démarre le flux de travail en exécutant la tâche J1. Les déclencheurs et les tâches suivants existent, mais les tâches J2 et J3 échouent, de sorte que les déclencheurs et les tâches en aval sont affichés comme non exécutés.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/workflow_W1.png)


L'exécution de flux de travail se déroule comme suit :

1. Le déclencheur T1 démarre la tâche J1.

1. La réussite de la tâche J1 déclenche T2 et T3, qui exécutent les tâches J2 et J3, respectivement.

1. Les tâches J2 et J3 échouent.

1. Les déclencheurs T4 et T5 dépendent de la réussite de J2 et J3, ils ne se déclenchent donc pas et les tâches J4 et J5 ne s'exécutent pas. Le flux de travail W1 n'est exécuté que partiellement.

À présent, supposons que les problèmes qui ont causé l'échec de J2 et J3 sont corrigés. J2 et J3 sont sélectionnés comme points de départ à partir desquels reprendre l'exécution du flux de travail.

![\[Les travaux J2 et J3 sont signalés comme des nœuds qui doivent être repris. Les déclencheurs et les tâches en aval sont affichés comme exécutés avec succès.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/workflow_W1_resumed.png)


L'exécution de flux de travail reprend comme suit :

1. Les tâches J2 et J3 sont exécutées avec succès.

1. Déclenche T4 et T5.

1. Les tâches J4 et J5 sont exécutées avec succès.

La reprise de l'exécution du flux de travail est suivie en tant qu'exécution de flux de travail distincte avec un nouvel ID d'exécution. Lorsque vous affichez l'historique du flux de travail, vous pouvez afficher l'ID d'exécution précédente pour toute exécution de flux de travail. Dans l'exemple de la capture d'écran suivante, le flux de travail exécuté avec l'ID d'exécution `wr_c7a22...` (la deuxième ligne) avait un nœud qui ne s'est pas terminé. L'utilisateur a résolu le problème et a repris l'exécution du flux de travail, ce qui a entraîné l'ID d'exécution `wr_a07e55...` (la première ligne).

![\[Un tableau sous l'onglet History (Historique) d'un flux de travail contient deux lignes, une pour chaque exécution de flux de travail. La première ligne possède à la fois un ID d'exécution et un ID d'exécution précédente. La deuxième ligne n'a qu'un ID d'exécution. L'ID d'exécution précédent dans la première ligne est le même que l'ID d'exécution dans la 2e ligne.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/previous-run-id.png)


**Note**  
Pour le reste de cette discussion, le terme « reprise de l'exécution du flux de travail » fait référence à l'exécution du flux de travail qui a été créée lors de la reprise de l'exécution du flux de travail précédente. L'« exécution du flux de travail d'origine » fait référence à l'exécution du flux de travail qui n'a été exécutée que partiellement et qui devait être reprise.

**Graphique de la reprise d’une l'exécution du flux de travail**  
Dans une exécution de flux de travail reprise, bien que seul un sous-ensemble de nœuds soit exécuté, le graphique d'exécution est un graphique complet. Autrement dit, les nœuds qui ne se sont pas exécutés dans le flux de travail repris sont copiés à partir du graphique d'exécution de l'exécution du flux de travail d'origine. Les nœuds de tâche et d'crawler copiés qui ont été exécutés dans l'exécution du flux de travail d'origine incluent les détails de l'exécution.

Considérez à nouveau le flux de travail W1 dans le diagramme précédent. Lorsque l'exécution du flux de travail reprend en commençant par J2 et J3, le graphique d'exécution de l'exécution de flux de travail reprise affiche tous les travaux, J1 à J5, et tous les déclencheurs, T1 à T5. Les détails de l'exécution pour J1 sont copiés à partir de l'exécution du flux de travail d'origine.

**Instantanés d'exécution de flux de travail**  
Lorsqu'une exécution de flux de travail est démarrée, AWS Glue prend un instantané du graphique de conception de flux de travail à ce moment-là. Cet instantané est utilisé pendant toute la durée de l'exécution du flux de travail. Si vous apportez des modifications à des déclencheurs après le démarrage de l'exécution, ces modifications n'affectent pas l'exécution du flux de travail en cours. Les instantanés garantissent que les exécutions du flux de travail se déroulent de manière cohérente.

Les instantanés rendent les déclencheurs inaltérables uniquement. Les modifications que vous apportez aux tâches en aval et aux crawlers pendant l'exécution du flux de travail prennent effet pour l'exécution en cours.

## Reprise de l'exécution d'un flux de travail
<a name="how-to-resume-workflow"></a>

Procédez comme suit pour reprendre l'exécution d'un flux de travail. Vous pouvez reprendre l'exécution d'un flux de travail à l'aide de la AWS Glue console, de l'API ou AWS Command Line Interface (AWS CLI).

**Pour reprendre l'exécution d'un flux de travail (console)**

1. Ouvrez la AWS Glue console à l'adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

   Connectez-vous en tant qu'utilisateur autorisé à afficher les flux de travail et à reprendre les exécutions de flux de travail.
**Note**  
Pour reprendre les exécutions de flux de travail, vous devez disposer de l'autorisation `glue:ResumeWorkflowRun` Gestion des identités et des accès AWS (IAM).

1. Dans le panneau de navigation, sous ETL, sélectionnez **Workflows** (Flux de travail).

1. Sélectionnez un flux de travail, puis l'onglet **History** (Historique).

1. Sélectionnez l'exécution du flux de travail qui n'a été exécutée que partiellement, puis sélectionnez **View run details** (Afficher les détails de l'exécution).

1. Dans le graphique d'exécution, sélectionnez le premier (ou le seul) nœud que vous souhaitez redémarrer et à partir duquel vous souhaitez reprendre l'exécution du flux de travail.

1. Dans le volet de détails à droite du graphique, cochez la case **Resume** (Reprendre).  
![\[Le graphique d'exécution montre trois nœuds, y compris un nœud de tâche ayant échoué. Le volet des détails de la tâche à droite comprend une case à cocher Resume (Reprendre).\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/workflow-pre-select-resume.png)

   Le nœud change de couleur et affiche une petite icône de CV en haut à droite.  
![\[La modification du graphique d'exécution est décrite dans le texte. La case Resume (Reprendre) est cochée.\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/workflow-post-select-resume.png)

1. Effectuez les deux étapes précédentes pour redémarrer tous les nœuds supplémentaires.

1. Sélectionnez **Resume** (Reprendre l'exécution).

**Pour reprendre l'exécution d'un flux de travail (AWS CLI)**

1. Assurez-vous de disposer de l'autorisation IAM `glue:ResumeWorkflowRun`.

1. Récupérez le nœud IDs pour les nœuds que vous souhaitez redémarrer.

   1.  Exécutez la commande `get-workflow-run` pour l'exécution du flux de travail d'origine. Fournissez le nom du flux de travail et l'ID d'exécution, puis ajoutez l'option `--include-graph`, comme illustré dans l'exemple suivant. Obtenez l'ID d'exécution dans l'onglet **History** (Historique) de la console ou en exécutant la commande `get-workflow`.

      ```
      aws glue get-workflow-run --name cloudtrailtest1 --run-id wr_a07e55f2087afdd415a404403f644a4265278f68b13ba3da08c71924ebe3c3a8 --include-graph
      ```

      La commande renvoie les nœuds et les bords du graphique sous la forme d'un objet JSON volumineux.

   1. Localisez les nœuds qui vous intéressent avec les propriétés `Type` et `Name` des objets de nœud.

      Ce qui suit est un exemple d'objet nœud de la sortie.

      ```
      {
          "Type": "JOB",
          "Name": "test1_post_failure_4592978",
          "UniqueId": "wnode_d1b2563c503078b153142ee76ce545fe5ceef66e053628a786ddd74a05da86fd",
          "JobDetails": {
              "JobRuns": [
                  {
                      "Id": "jr_690b9f7fc5cb399204bc542c6c956f39934496a5d665a42de891e5b01f59e613",
                      "Attempt": 0,
                      "TriggerName": "test1_aggregate_failure_649b2432",
                      "JobName": "test1_post_failure_4592978",
                      "StartedOn": 1595358275.375,
                      "LastModifiedOn": 1595358298.785,
                      "CompletedOn": 1595358298.785,
                      "JobRunState": "FAILED",
                      "PredecessorRuns": [],
                      "AllocatedCapacity": 0,
                      "ExecutionTime": 16,
                      "Timeout": 2880,
                      "MaxCapacity": 0.0625,
                      "LogGroupName": "/aws-glue/python-jobs"
                  }
              ]
          }
      }
      ```

   1. Obtenez l'ID de nœud à partir de la propriété `UniqueId` de l'objet nœud.

1. Exécutez la commande `resume-workflow-run`. Indiquez le nom du flux de travail, l'ID d'exécution et la liste des nœuds IDs séparés par des espaces, comme indiqué dans l'exemple suivant.

   ```
   aws glue resume-workflow-run --name cloudtrailtest1 --run-id wr_a07e55f2087afdd415a404403f644a4265278f68b13ba3da08c71924ebe3c3a8 --node-ids wnode_ca1f63e918fb855e063aed2f42ec5762ccf71b80082ae2eb5daeb8052442f2f3  wnode_d1b2563c503078b153142ee76ce545fe5ceef66e053628a786ddd74a05da86fd
   ```

   La commande génère l'ID d'exécution de la (nouvelle) exécution de flux de travail reprise et une liste de nœuds qui seront démarrés.

   ```
   {
       "RunId": "wr_2ada0d3209a262fc1156e4291134b3bd643491bcfb0ceead30bd3e4efac24de9",
       "NodeIds": [
           "wnode_ca1f63e918fb855e063aed2f42ec5762ccf71b80082ae2eb5daeb8052442f2f3"
       ]
   }
   ```

   Notez que bien que l'exemple de commande `resume-workflow-run` répertorie deux nœuds à redémarrer, l'exemple de sortie indiquait qu'un seul nœud serait redémarré. C'est parce qu'un nœud était en aval de l'autre nœud, et le nœud en aval serait redémarré de toute façon par le flux normal du flux de travail.

## Remarques et limitations pour la reprise des exécutions de flux de travail
<a name="resume-workflow-notes"></a>

Gardez les notes et limitations suivantes à l'esprit lors de la reprise des exécutions du flux de travail.
+ Vous pouvez reprendre l'exécution d'un flux de travail uniquement s'il est dans l'état `COMPLETED`.
**Note**  
Même si un ou plusieurs nœuds d'une exécution de flux de travail ne se terminent pas, l'état d'exécution du flux de travail est affiché sous la forme `COMPLETED`. Assurez-vous de vérifier le graphique d'exécution pour découvrir tous les nœuds qui ne se sont pas terminés avec succès.
+ Vous pouvez reprendre une exécution de flux de travail à partir de n'importe quel tâche ou nœud d'crawler que l'exécution de flux de travail d'origine a tenté d'exécuter. Vous ne pouvez pas reprendre un flux de travail exécuté à partir d'un nœud déclencheur.
+ Le redémarrage d'un nœud ne réinitialise pas son état. Toutes les données partiellement traitées ne sont pas annulées.
+ Vous pouvez reprendre plusieurs fois l'exécution d'un flux de travail ayant échoué. Toutefois, une reprise ne peut être reprise qu'une seule fois. Pour des tentatives supplémentaires, reprenez plutôt l'exécution initiale qui a échoué
+ Si vous sélectionnez deux nœuds à redémarrer et qu'ils dépendent l'un de l'autre, le nœud en amont est exécuté avant le nœud en aval. En fait, la sélection du nœud en aval est redondante, car elle sera exécutée selon le flux normal du flux de travail.

# Obtention et définition des propriétés d'exécution du flux de travail dans AWS Glue
<a name="workflow-run-properties-code"></a>

Utilisez les propriétés d'exécution de flux de travail pour partager et gérer l'état entre les tâches de votre flux de travail AWS Glue. Vous pouvez définir les propriétés d'exécution par défaut lorsque vous créez le flux de travail. Ensuite, tandis que vos tâches s'exécutent, elles peuvent récupérer les valeurs des propriétés d'exécution et, le cas échéant, les modifier pour les entrées de tâches qui sont plus loin dans le flux de travail. Lorsqu'une tâche modifie une propriété d'exécution, la nouvelle valeur existe uniquement pour l'exécution du flux de travail. Les propriétés d'exécution par défaut ne sont pas affectées.

Si votre tâche AWS Glue ne fait pas partie d'un flux de travail, ces propriétés ne seront pas définies.

L'exemple de code Python suivant à partir d'une tâche d'extraction, de transformation et de chargement (ETL) montre comment obtenir les propriétés d'exécution des flux de travail.

```
import sys
import boto3
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glue_client = boto3.client("glue")
args = getResolvedOptions(sys.argv, ['JOB_NAME','WORKFLOW_NAME', 'WORKFLOW_RUN_ID'])
workflow_name = args['WORKFLOW_NAME']
workflow_run_id = args['WORKFLOW_RUN_ID']
workflow_params = glue_client.get_workflow_run_properties(Name=workflow_name,
                                        RunId=workflow_run_id)["RunProperties"]

target_database = workflow_params['target_database']
target_s3_location = workflow_params['target_s3_location']
```

Le code suivant continue en définissant la propriété d'exécution `target_format` sur `'csv'`.

```
workflow_params['target_format'] = 'csv'
glue_client.put_workflow_run_properties(Name=workflow_name, RunId=workflow_run_id, RunProperties=workflow_params)
```

Pour plus d'informations, consultez les ressources suivantes : 
+ [GetWorkflowRunProperties action (Python : get\$1workflow\$1run\$1properties)](aws-glue-api-workflow.md#aws-glue-api-workflow-GetWorkflowRunProperties)
+ [PutWorkflowRunProperties action (Python : put\$1workflow\$1run\$1properties)](aws-glue-api-workflow.md#aws-glue-api-workflow-PutWorkflowRunProperties)

# Interrogation des flux de travail à l'aide du AWS Glue API
<a name="workflows_api_concepts"></a>

AWS Glue fournit un riche API de gestion des flux de travail. Vous pouvez récupérer la vue statique ou dynamique d'un flux de travail en cours d'exécution à l'aide de l' AWS Glue API. Pour de plus amples informations, veuillez consulter [Flux de travail](aws-glue-api-workflow.md).

**Topics**
+ [Interrogation des vues statiques](#workflows_api_concepts_static)
+ [Interrogation des vues dynamiques](#workflows_api_concepts_dynamic)

## Interrogation des vues statiques
<a name="workflows_api_concepts_static"></a>

Utilisez l'opération d'API `GetWorkflow` pour obtenir une vue statique qui indique la conception d'un flux de travail. Cette opération renvoie un graphe orienté composé de nœuds et d'arcs, où un nœud représente un déclencheur, une tâche ou un crawler. Les arcs définissent les relations entre les nœuds. Ils sont représentés par des connecteurs (flèches) sur le graphique dans la console AWS Glue. 

Vous pouvez également utiliser cette opération avec des bibliothèques de traitement graphique populaires telles que NetworkX, igraph, JGraph T et le Java Universal Network/Graph (JUNG) Framework. Étant donné que toutes ces bibliothèques représentent les graphiques de la même manière, des transformations minimes sont nécessaires.

La vue statique renvoyée par cette API est la plus grande up-to-date vue selon la dernière définition des déclencheurs associés au flux de travail.

### Définition du graphique
<a name="workflows_api_concepts_static_graph"></a>

Un graphe G de flux de travail est une paire ordonnée (N, E), où N est un ensemble de nœuds et E un ensemble d'arcs. Un *nœud* est un sommet du graphique identifié par un numéro unique. Un nœud peut être de type déclencheur, tâche ou crawler. Par exemple : `{name:T1, type:Trigger, uniqueId:1}, {name:J1, type:Job, uniqueId:2}`.

Un *arc* est un 2-tuplet de la forme (`src, dest`), où `src` et `dest` sont les nœuds et il y a un arc dirigé de `src` vers `dest`. 

### Exemple d'interrogation d'une vue statique
<a name="workflows_api_concepts_static_example"></a>

Envisagez un déclencheur conditionnel T, qui déclenche la tâche J2 après la fin de la tâche J1. 

```
J1 ---> T ---> J2
```

Nœuds : J1, T, J2 

Arcs : (J1, T), (T, J2)

## Interrogation des vues dynamiques
<a name="workflows_api_concepts_dynamic"></a>

Utilisez l'opération d'API`GetWorkflowRun` pour obtenir une vue dynamique d'un flux de travail en cours d'exécution. Cette opération renvoie la même vue statique du graphe en même temps que les métadonnées relatives à l'exécution du flux de travail.

Pour l'exécution, les nœuds représentent les tâches dans l'appel `GetWorkflowRun` ont une liste d'exécutions de tâches lancées dans le cadre de la dernière exécution du flux de travail. Vous pouvez utiliser cette liste pour afficher le statut d'exécution de chaque tâche dans le graphique lui-même. Pour les dépendances en aval qui ne sont pas encore exécutées, ce champ est défini sur `null`. Le graphique d'informations vous permet de connaître l'état actuel d'un flux de travail à tout moment.

La vue dynamique renvoyée par cette API est basée sur la vue statique qui était présente lorsque l'exécution du flux de travail a été démarrée.

*Exemple de nœuds d'exécution :* `{name:T1, type: Trigger, uniqueId:1}`, `{name:J1, type:Job, uniqueId:2, jobDetails:{jobRuns}}`, `{name:C1, type:Crawler, uniqueId:3, crawlerDetails:{crawls}}` 

### Exemple 1 : Vue dynamique
<a name="workflows_api_concepts_dynamic_examples"></a>

L'exemple suivant illustre un simple flux de travail à deux déclencheurs. 
+ Nœuds : t1, j1, t2, j2 
+ Arcs : (t1, j1), (j1, t2), (t2, j2)

La réponse `GetWorkflow` contient les éléments suivants.

```
{
    Nodes : [
        {
            "type" : Trigger,
            "name" : "t1",
            "uniqueId" : 1
        },
        {
            "type" : Job,
            "name" : "j1",
            "uniqueId" : 2
        },
        {
            "type" : Trigger,
            "name" : "t2",
            "uniqueId" : 3
        },
        {
            "type" : Job,
            "name" : "j2",
            "uniqueId" : 4
        }
    ],
    Edges : [
        {
            "sourceId" : 1,
            "destinationId" : 2
        },
        {
            "sourceId" : 2,
            "destinationId" : 3
        },
        {
            "sourceId" : 3,
            "destinationId" : 4
        }
}
```

La réponse `GetWorkflowRun` contient les éléments suivants.

```
{
    Nodes : [
        {
            "type" : Trigger,
            "name" : "t1",
            "uniqueId" : 1,
            "jobDetails" : null,
            "crawlerDetails" : null
        },
        {
            "type" : Job,
            "name" : "j1",
            "uniqueId" : 2,
            "jobDetails" : [
                {
                    "id" : "jr_12334",
                    "jobRunState" : "SUCCEEDED",
                    "errorMessage" : "error string"
                }
            ],
            "crawlerDetails" : null
        },
        {
            "type" : Trigger,
            "name" : "t2",
            "uniqueId" : 3,
            "jobDetails" : null,
            "crawlerDetails" : null
        },
        {
            "type" : Job,
            "name" : "j2",
            "uniqueId" : 4,
            "jobDetails" : [
                {
                    "id" : "jr_1233sdf4",
                    "jobRunState" : "SUCCEEDED",
                    "errorMessage" : "error string"
                }
            ],
            "crawlerDetails" : null
        }
    ],
    Edges : [
        {
            "sourceId" : 1,
            "destinationId" : 2
        },
        {
            "sourceId" : 2,
            "destinationId" : 3
        },
        {
            "sourceId" : 3,
            "destinationId" : 4
        }
}
```

### Exemple 2 : Tâches multiples avec un déclencheur conditionnel
<a name="workflows_api_concepts_dynamic_example_2"></a>

L'exemple suivant illustre un flux de travail avec plusieurs tâches et un déclencheur conditionnel (t3).

```
Consider Flow:
T(t1) ---> J(j1) ---> T(t2) ---> J(j2)
             |                    |
             |                    |
             >+------> T(t3) <-----+
                        |
                        |
                      J(j3)

Graph generated:
Nodes: t1, t2, t3, j1, j2, j3
Edges: (t1, j1), (j1, t2), (t2, j2), (j1, t3), (j2, t3), (t3, j3)
```

# Restrictions du plan et du flux de travail dans AWS Glue
<a name="blueprint_workflow_restrictions"></a>

Les restrictions suivantes s'appliquent aux modèles et aux flux de travail.

## Restrictions du plan
<a name="bluprint-restrictions"></a>

Gardez à l'esprit les restrictions de modèle suivantes :
+ Le plan doit être enregistré dans la même AWS région que celle où réside le compartiment Amazon S3.
+ Pour partager des plans entre AWS comptes, vous devez accorder les autorisations de lecture sur l'archive ZIP des plans dans Amazon S3. Les clients qui ont une autorisation de lecture sur une archive ZIP de plan peuvent enregistrer le plan dans leur AWS compte et l'utiliser. 
+ L'ensemble des paramètres de modèle est stocké en tant qu'objet JSON unique. La longueur maximale de cet objet est de 128 Ko.
+ La taille maximale non compressée de l'archive ZIP du modèle est de 5 Mo. La taille maximale compressée est de 1 Mo.
+ Limitez le nombre total de tâches, de crawlers et de déclencheurs au sein d'un flux de travail à 100 ou moins. Si vous en incluez plus de 100, vous risquez de rencontrer des erreurs lorsque vous tentez de reprendre ou d'arrêter les exécutions du flux de travail.

## Restrictions du flux de travail
<a name="workflow-restrictions"></a>

Gardez à l'esprit les restrictions de flux de travail suivantes. Certains de ces commentaires s'adressent davantage à un utilisateur qui crée des flux de travail manuellement.
+ La taille de lot maximale pour un déclencheur d' EventBridge événement Amazon est de 100. La taille maximale de la fenêtre temporelle est de 900 secondes (15 minutes).
+ Un déclencheur peut être associé à un seul flux de travail.
+ Seul un déclencheur de départ (à la demande ou planifié) est autorisé.
+ Si une tâche ou un crawler dans un flux de travail est démarré par un déclencheur qui se trouve en dehors du flux de travail, les déclencheurs intégrés au flux de travail et dépendant de l'achèvement (réussi ou non) de la tâche ou de l'crawler ne se déclenchent pas.
+ De même, si une tâche ou un crawler dans un flux de travail comporte des déclencheurs qui dépendent de l'achèvement (avec succès ou non) d'une tâche ou d'un crawler à la fois dans et en dehors du flux de travail, si la tâche ou l'crawler est démarré à partir d'un flux de travail, seuls les déclencheurs à l'intérieur du flux de travail se déclenchent à l'achèvement de la tâche ou de l'crawler.

# Résolution des erreurs de plans dans AWS Glue
<a name="blueprint_workflow_troubleshoot"></a>

Si vous rencontrez des erreurs lorsque vous utilisez des modèles AWS Glue, utilisez les solutions suivantes afin de trouver la source des problèmes et de corriger ceux-ci.

**Topics**
+ [Erreur : PySpark module manquant](#blueprint-workflow-error-1)
+ [Error: missing blueprint config file (Erreur : fichier de configuration de modèle manquant)](#blueprint-workflow-error-2)
+ [Error: missing imported file (Erreur : fichier importé manquant)](#blueprint-workflow-error-3)
+ [Erreur : non autorisé à effectuer une exécution iamPassRole sur la ressource](#blueprint-workflow-error-4)
+ [Error: invalid cron schedule (Erreur : calendrier cron non valide)](#blueprint-workflow-error-5)
+ [Error: a trigger with the same name already exists (Erreur : un déclencheur du même nom existe déjà)](#blueprint-workflow-error-6)
+ [Erreur : un flux de travail du même nom : foo existe déjà.](#blueprint-workflow-error-7)
+ [Error: module not found in specified layoutGenerator path (Erreur : module introuvable dans le chemin LayoutGenerator spécifié)](#blueprint-workflow-error-8)
+ [Error: validation error in Connections field (Erreur : erreur de validation dans le champ Connections [Connexions])](#blueprint-workflow-error-9)

## Erreur : PySpark module manquant
<a name="blueprint-workflow-error-1"></a>

AWS Gluerenvoie l'erreur « Erreur inconnue lors de l'exécution de la fonction de génération de mise en page ModuleNotFoundError : aucun module nommé 'pyspark' ».

Lorsque vous décompressez l'archive du modèle, cela peut ressembler à l'un des éléments suivants :

```
$ unzip compaction.zip 
Archive:  compaction.zip
   creating: compaction/
  inflating: compaction/blueprint.cfg  
  inflating: compaction/layout.py    
  inflating: compaction/README.md    
  inflating: compaction/compaction.py   
  
$ unzip compaction.zip
Archive:  compaction.zip
  inflating: blueprint.cfg           
  inflating: compaction.py           
  inflating: layout.py               
  inflating: README.md
```

Dans le premier cas, tous les fichiers liés au modèle ont été placés dans un dossier nommé compactage et il a ensuite été converti en un fichier zip nommé *compaction.zip*.

Dans le second cas, tous les fichiers requis pour le modèle n'étaient pas inclus dans un dossier et ont été ajoutés en tant que fichiers racine sous le fichier zip *compaction.zip*.

La création d'un fichier dans l'un des formats ci-dessus est autorisée. Assurez-vous toutefois que `blueprint.cfg` a le chemin d'accès approprié au nom de la fonction dans le script qui génère la mise en page.

**Exemples**  
Dans le cas 1 : `blueprint.cfg` doit disposer de `layoutGenerator` comme suit :

```
layoutGenerator": "compaction.layout.generate_layout"
```

Dans le cas 2 : `blueprint.cfg` doit disposer de `layoutGenerator` comme suit :

```
layoutGenerator": "layout.generate_layout" 
```

Si ce chemin n'est pas inclus correctement, vous pourriez voir une erreur comme indiqué. Par exemple, si vous avez la structure de dossiers mentionnée dans le cas 2 et que vous avez `layoutGenerator` comme indiquée dans le cas 1, vous pouvez voir l'erreur ci-dessus.

## Error: missing blueprint config file (Erreur : fichier de configuration de modèle manquant)
<a name="blueprint-workflow-error-2"></a>

AWS Gluerenvoie l'erreur « Erreur inconnue lors de l'exécution de la fonction de génération de mise en page FileNotFoundError : [Errno 2] Aucun fichier ou répertoire de ce type : '/ tmp/compaction/blueprint .cfg' ».

Le blueprint.cfg doit être placé au niveau racine de l'archive ZIP ou dans un dossier portant le même nom que l'archive ZIP.

Lorsque nous extrayons l'archive ZIP de modèle, blueprint.cfg devrait se trouver dans l'un des chemins suivants. S'il ne se trouve pas dans l'un des chemins suivants, vous pouvez voir l'erreur ci-dessus.

```
$ unzip compaction.zip 
Archive:  compaction.zip
   creating: compaction/
  inflating: compaction/blueprint.cfg  
  
$ unzip compaction.zip
Archive:  compaction.zip
  inflating: blueprint.cfg
```

## Error: missing imported file (Erreur : fichier importé manquant)
<a name="blueprint-workflow-error-3"></a>

AWS Gluerenvoie l'erreur « Erreur inconnue lors de l'exécution de la fonction de génération de mise en page FileNotFoundError : [Errno 2] Aucun fichier ou répertoire de ce type :\$1 \$1'demo-project/foo.py' ».

Si votre script de génération de mise en page a une fonctionnalité pour lire d'autres fichiers, assurez-vous de donner un chemin complet pour le fichier à importer. Par exemple, le script Conversion.py peut être référencé dans Layout.py. Pour en savoir plus, veuillez consulter la rubrique [Exemple de projet de plan](https://docs.aws.amazon.com/glue/latest/dg/developing-blueprints-sample.html).

## Erreur : non autorisé à effectuer une exécution iamPassRole sur la ressource
<a name="blueprint-workflow-error-4"></a>

AWS Gluerenvoie l'erreur « User : arn:aws:sts : :123456789012:assumed- » role/AWSGlueServiceRole/GlueSession is not authorized to perform: iam:PassRole on resource: arn:aws:iam::123456789012:role/AWSGlueServiceRole

Si les travaux et les crawlers du flux de travail assument le même rôle que le rôle transmis pour créer le flux de travail à partir du modèle, alors le rôle du modèle doit inclure l'autorisation `iam:PassRole` pour lui-même.

Si les travaux et les crawlers du flux de travail assument un rôle autre que celui transmis pour créer les entités du flux de travail à partir du modèle, le rôle de ce dernier doit inclure l'autorisation `iam:PassRole` sur cet autre rôle plutôt que sur le rôle du modèle.

Pour plus d’informations, veuillez consulter [Autorisations pour les rôles de plans](https://docs.aws.amazon.com/glue/latest/dg/blueprints-personas-permissions.html#blueprints-role-permissions).

## Error: invalid cron schedule (Erreur : calendrier cron non valide)
<a name="blueprint-workflow-error-5"></a>

AWS Glue renvoie l'erreur « The schedule cron(0 0 \$1 \$1 \$1 \$1) is invalid » (Le cron horaire [0 0 \$1 \$1 \$1 \$1] n'est pas valide).

Fournissez une expression [cron](https://en.wikipedia.org/wiki/Cron) valide. Pour plus d'informations, consultez [Planifications temporelles pour les tâches et les crawlers](https://docs.aws.amazon.com/glue/latest/dg/monitor-data-warehouse-schedule.html).

## Error: a trigger with the same name already exists (Erreur : un déclencheur du même nom existe déjà)
<a name="blueprint-workflow-error-6"></a>

AWS Glue renvoie l'erreur « Trigger with name 'foo\$1starting\$1trigger' already submitted with different configuration » (Trigger avec le nom 'foo\$1starting\$1trigger' déjà soumis avec une configuration différente).

Un modèle ne nécessite pas que vous définissiez des déclencheurs dans le script de mise en page pour la création de flux de travail. La création de déclencheur est gérée par la bibliothèque de modèles en fonction des dépendances définies entre deux actions. 

La dénomination des déclencheurs est la suivante :
+ Pour le déclencheur de démarrage dans le flux de travail, le nom est <workflow\$1name>\$1starting\$1trigger.
+ Pour un nœud (tâche/crawler) dans le flux de travail qui dépend de l'achèvement d'un ou de plusieurs nœuds en amont ; AWS Glue définit un déclencheur avec le nom <workflow\$1name>\$1<node\$1name>\$1trigger.

Cette erreur signifie qu'un déclencheur du même nom existe déjà. Vous pouvez supprimer le déclencheur existant et relancer la création du flux de travail.

**Note**  
La suppression d'un flux de travail ne supprime pas les nœuds du flux de travail. Bien que le flux de travail soit supprimé, il est possible que des déclencheurs soient laissés pour compte. Pour cette raison, vous ne pouvez pas recevoir une erreur « workflow already exists » (le flux de travail existe déjà), mais vous pouvez recevoir une erreur « trigger already exists » (le déclencheur existe déjà) dans le cas où vous créez un flux de travail, le supprimez, puis essayez de le recréer avec le même nom du même modèle.

## Erreur : un flux de travail du même nom : foo existe déjà.
<a name="blueprint-workflow-error-7"></a>

Le nom du flux de travail doit être unique. Veuillez essayer avec un nom différent.

## Error: module not found in specified layoutGenerator path (Erreur : module introuvable dans le chemin LayoutGenerator spécifié)
<a name="blueprint-workflow-error-8"></a>

AWS Gluerenvoie l'erreur « Erreur inconnue lors de l'exécution de la fonction de génération de mise en page ModuleNotFoundError : aucun module nommé 'crawl\$1s3\$1locations' ».

```
layoutGenerator": "crawl_s3_locations.layout.generate_layout"
```

Par exemple, si vous avez le chemin layoutGenerator ci-dessus, lorsque vous décompressez l'archive de modèle, il doit ressembler à ce qui suit :

```
$ unzip crawl_s3_locations.zip 
Archive:  crawl_s3_locations.zip
   creating: crawl_s3_locations/
  inflating: crawl_s3_locations/blueprint.cfg  
  inflating: crawl_s3_locations/layout.py    
  inflating: crawl_s3_locations/README.md
```

Lorsque vous décompressez l'archive, si l'archive du modèle ressemble à ce qui suit, vous pouvez obtenir l'erreur ci-dessus.

```
$ unzip crawl_s3_locations.zip
Archive:  crawl_s3_locations.zip
  inflating: blueprint.cfg           
  inflating: layout.py               
  inflating: README.md
```

Vous pouvez voir qu'il n'y a pas de dossier nommé `crawl_s3_locations` et lorsque le chemin `layoutGenerator` fait référence au fichier de mise en page via le module `crawl_s3_locations`, vous pouvez obtenir l'erreur ci-dessus.

## Error: validation error in Connections field (Erreur : erreur de validation dans le champ Connections [Connexions])
<a name="blueprint-workflow-error-9"></a>

AWS Gluerenvoie l'erreur « Erreur inconnue lors de l'exécution de la fonction de génération de mise en page TypeError : la valeur ['foo'] pour les connexions clés doit être de type <class 'dict'> \$1 ».

Il s'agit d'une erreur de validation. Le champs `Connections` dans le champ `Job` attend un dictionnaire et à la place une liste de valeurs sont fournies, ce qui provoque l'erreur.

```
User input was list of values
Connections= ['string']

Should be a dict like the following
Connections*=*{'Connections': ['string']}
```

Pour éviter ces erreurs d'exécution lors de la création d'un flux de travail à partir d'un plan, vous pouvez valider les définitions du flux de travail, de la tâche et du crawler comme indiqué dans [Tester un plan](https://docs.aws.amazon.com/glue/latest/dg/developing-blueprints-testing.html).

Référez-vous à la syntaxe dans la [Référence des classes de plans AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/developing-blueprints-code-classes.html) pour définir la tâche AWS Glue, le crawler et le flux de travail dans le script de mise en page.

# Autorisations de personas et de rôles pour les plans AWS Glue
<a name="blueprints-personas-permissions"></a>

Vous trouverez ci-dessous les personas typiques et les politiques d'autorisation suggérées Gestion des identités et des accès AWS (IAM) pour les personas et les rôles pour les blueprints. AWS Glue

**Topics**
+ [Personas du plan](#blueprints-personas)
+ [Autorisations pour les personas du plan](#blueprints-permssions)
+ [Autorisations des rôles de plans](#blueprints-role-permissions)

## Personas du plan
<a name="blueprints-personas"></a>

Voici les personas généralement impliquées dans le cycle de vie des plans AWS Glue.


| Persona | Description | 
| --- | --- | 
| Développeur AWS Glue | Développe, teste et publie des modèles. | 
| administrateur AWS Glue | Inscrit, gère et accorde des autorisations pour les modèles. | 
| Analyste des données | Exécute des modèles pour créer des flux de travail. | 

Pour de plus amples informations, veuillez consulter [Présentation des plans dans AWS Glue](blueprints-overview.md).

## Autorisations pour les personas du plan
<a name="blueprints-permssions"></a>

Voici les autorisations suggérées pour chaque persona du modèle.



### Autorisations de développeur AWS Glue pour les plans
<a name="bp-persona-dev"></a>

Le développeur AWS Glue doit disposer des autorisations d'écriture sur le compartiment Amazon S3 utilisé pour publier le plan. Souvent, le développeur enregistre le modèle après l'avoir téléchargé. Dans ce cas, le développeur a besoin des autorisations répertoriées dans [Autorisations d'administrateur AWS Glue pour les plans](#bp-persona-admin). De plus, si le développeur souhaite tester le modèle après son enregistrement, il a également besoin des autorisations répertoriées dans [Autorisations d'analyste des données pour les plans](#bp-persona-analyst). 

### Autorisations d'administrateur AWS Glue pour les plans
<a name="bp-persona-admin"></a>

La politique suivante accorde des autorisations pour l'enregistrement, l'affichage et la gestion des plans AWS Glue.

**Important**  
Dans la politique suivante, remplacez *<s3-bucket-name>* et *<prefix>* par le chemin Amazon S3 vers les archives ZIP du plan chargées pour vous enregistrer.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "glue:CreateBlueprint",
        "glue:UpdateBlueprint",
        "glue:DeleteBlueprint",
        "glue:GetBlueprint",
        "glue:ListBlueprints",
        "glue:BatchGetBlueprints"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix/*"
    }
  ]
}
```

------

### Autorisations d'analyste des données pour les plans
<a name="bp-persona-analyst"></a>

La politique suivante accorde des autorisations pour exécuter les modèles et afficher le flux de travail et ses composants résultants. Elle accorde également à `PassRole` le rôle que AWS Glue endosse pour créer le flux de travail et ses composants.

La politique accorde des autorisations pour n'importe quelle ressource. Si vous souhaitez configurer un accès détaillé à des plans individuels, utilisez le format suivant pour le plan : ARNs

```
arn:aws:glue:<region>:<account-id>:blueprint/<blueprint-name>
```

**Important**  
Dans la politique suivante, remplacez *<account-id>* par un AWS compte valide et remplacez *<role-name>* par le nom du rôle utilisé pour exécuter un plan. Veuillez consulter [Autorisations des rôles de plans](#blueprints-role-permissions) pour connaître les autorisations requises par ce rôle.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "glue:ListBlueprints",
        "glue:GetBlueprint",
        "glue:StartBlueprintRun",
        "glue:GetBlueprintRun",
        "glue:GetBlueprintRuns",
        "glue:GetCrawler",
        "glue:ListTriggers",
        "glue:ListJobs",
        "glue:BatchGetCrawlers",
        "glue:GetTrigger",
        "glue:BatchGetWorkflows",
        "glue:BatchGetTriggers",
        "glue:BatchGetJobs",
        "glue:BatchGetBlueprints",
        "glue:GetWorkflowRun",
        "glue:GetWorkflowRuns",
        "glue:ListCrawlers",
        "glue:ListWorkflows",
        "glue:GetJob",
        "glue:GetWorkflow",
        "glue:StartWorkflowRun"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::111122223333:role/role-name"
    }
  ]
}
```

------

## Autorisations des rôles de plans
<a name="blueprints-role-permissions"></a>

Voici les autorisations suggérées pour le rôle IAM utilisé pour créer un flux de travail à partir d'un modèle. Le rôle doit avoir une relation d'approbation avec `glue.amazonaws.com`.

**Important**  
Dans la politique suivante, remplacez *<account-id>* par un AWS compte valide et remplacez *<role-name>* par le nom du rôle.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "glue:CreateJob",
        "glue:GetCrawler",
        "glue:GetTrigger",
        "glue:DeleteCrawler",
        "glue:CreateTrigger",
        "glue:DeleteTrigger",
        "glue:DeleteJob",
        "glue:CreateWorkflow",
        "glue:DeleteWorkflow",
        "glue:GetJob",
        "glue:GetWorkflow",
        "glue:CreateCrawler"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::111122223333:role/role-name"
    }
  ]
}
```

------

**Note**  
Si les tâches et les crawlers du flux de travail endossent un rôle autre que celui-ci, cette politique doit inclure l'autorisation `iam:PassRole` pour cet autre rôle plutôt que pour le rôle du modèle.

# Développement des plans dans AWS Glue
<a name="orchestrate-using-blueprints"></a>

Votre organisation peut avoir un jeu de cas d'utilisation ETL similaires qui pourraient bénéficier de la capacité de paramétrage d'un flux de travail unique pour les gérer tous. Pour répondre à ce besoin, AWS Glue vous permet de définir des *plans* que vous pouvez utiliser pour générer des flux de travail. Un modèle accepte des paramètres, de sorte qu'à partir d'un modèle unique, un analyste de données peut créer différents flux de travail pour gérer des cas d'utilisation ETL similaires. Après avoir créé un modèle, vous pouvez le réutiliser pour différents services, équipes et projets.

**Topics**
+ [Présentation des plans dans AWS Glue](blueprints-overview.md)
+ [Développement des plans dans AWS Glue](developing-blueprints.md)
+ [Enregistrement d'un plan dans AWS Glue](registering-blueprints.md)
+ [Affichage des plans dans AWS Glue](viewing_blueprints.md)
+ [Mise à jour d'un plan dans AWS Glue](updating_blueprints.md)
+ [Création d'un flux de travail à partir d'un plan dans AWS Glue](creating_workflow_blueprint.md)
+ [Affichage des exécutions du plan dans AWS Glue](viewing_blueprint_runs.md)

# Présentation des plans dans AWS Glue
<a name="blueprints-overview"></a>

**Note**  
La fonctionnalité Blueprints n'est actuellement pas disponible dans les régions suivantes de la console AWS Glue : Asie-Pacifique (Jakarta) et Moyen-Orient (Émirats arabes unis).

Les plans AWS Glue offrent un moyen de créer et de partager des flux de travail AWS Glue. Lorsqu'il existe un processus ETL complexe qui pourrait être utilisé pour des cas d'utilisation similaires, plutôt que de créer un flux de travail AWS Glue pour chaque cas d'utilisation, vous pouvez créer un seul plan. 

Le modèle spécifie les tâches et les crawlers à inclure dans un flux de travail, et spécifie les paramètres que l'utilisateur du flux de travail fournit lorsqu'il exécute le modèle pour créer un flux de travail. L'utilisation de paramètres permet à un seul modèle de générer des flux de travail pour les différents cas d'utilisation similaires. Pour de plus amples informations sur les flux de travail, veuillez consulter [Présentation des flux de travail dans AWS Glue](workflows_overview.md).

Voici quelques exemples de cas d'utilisation pour les modèles :
+ Vous souhaitez partitionner un jeu de données existant. Les paramètres d'entrée du modèle sont Amazon Simple Storage Service (Amazon S3) et une liste pour les colonnes de partition.
+ Vous souhaitez créer un instantané d'une table Amazon DynamoDB dans un magasin de données SQL comme Amazon Redshift. Les paramètres d'entrée du plan sont le nom de la table DynamoDB et une connexion AWS Glue, qui désigne un cluster Amazon Redshift et une base de données de destination.
+ Vous souhaitez convertir les données CSV dans plusieurs chemins Amazon S3 en Parquet. Vous souhaitez que le flux de travail AWS Glue inclue un crawler et une tâche distincts pour chaque chemin. Les paramètres d'entrée sont la base de données de destination dans le catalogue de données AWS Glue et une liste délimitée par des virgules de chemins Amazon S3. Notez que dans ce cas, le nombre d'crawlers et de tâches créés par le flux de travail est variable.

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/s3Bm8ay53Ms/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/s3Bm8ay53Ms)


**Composants du plan**  
Un modèle est une archive ZIP qui contient les composants suivants :
+ Un script de générateur de mise en page Python

  Contient une fonction qui spécifie la *disposition* du flux de travail : les crawlers et les tâches à créer pour le flux de travail, les propriétés de la tâche et de l'crawler et les dépendances entre les tâches et les crawlers. La fonction accepte les paramètres de plan et renvoie une structure de flux de travail (objet JSON) que AWS Glue utilise pour générer le flux de travail. Étant donné que vous utilisez un script Python pour générer le flux de travail, vous pouvez ajouter votre propre logique adaptée à vos cas d'utilisation.
+ Un fichier de configuration

  Spécifie le nom complet de la fonction Python qui génère la disposition du flux de travail. Spécifie également les noms, types de données et autres propriétés de tous les paramètres de modèle utilisés par le script.
+ (Facultatif) scripts ETL et fichiers de support

  En tant que cas d'utilisation avancé, vous pouvez paramétrer l'emplacement des scripts ETL que vos tâches utilisent. Vous pouvez inclure des fichiers de script de tâche dans l'archive ZIP et spécifier un paramètre de modèle pour un emplacement Amazon S3 vers lequel les scripts doivent être copiés. Le script du générateur de mise en page peut copier les scripts ETL à l'emplacement désigné et spécifier cet emplacement en tant que propriété d'emplacement du script de tâche. Vous pouvez également inclure des bibliothèques ou d'autres fichiers de support, à condition que votre script les gère.

![\[L'encadré intitulé Blueprint (Modèle) contient deux encadrés plus petits, l'un intitulé Python Script (Script Python) et l'autre intitulé Config File (Fichier de configuration).\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/blueprint.png)


**Exécutions de modèle**  
Lorsque vous créez un flux de travail à partir d'un plan, AWS Glue exécute le plan, qui démarre un processus asynchrone pour créer le flux de travail et les tâches, les moteurs d'exploration et les déclencheurs que le flux de travail encapsule. AWS Glue utilise l'exécution du plan pour orchestrer la création du flux de travail et de ses composantes. Vous affichez le statut du processus de création en affichant le statut d'exécution du modèle. L'exécution du modèle stocke également les valeurs que vous avez fournies pour les paramètres du modèle.

![\[L'encadré intitulé Blueprint run (Exécution de modèle) contient des icônes intitulées Workflow (Flux de travail) et Parameter Values (Valeurs de paramètre).\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/images/blueprint-run.png)


Vous pouvez afficher les exécutions du plan à l'aide de la AWS Glue console ou AWS Command Line Interface (AWS CLI). Lors de l'affichage ou du dépannage d'un flux de travail, vous pouvez toujours revenir à l'exécution du modèle pour afficher les valeurs des paramètres de modèle qui ont été utilisées pour créer le flux de travail.

**Cycle de vie d'un plan**  
Les plans sont développés, testés, enregistrés auprès de AWS Glue et exécutés pour créer des flux de travail. Il existe généralement trois personas impliquées dans le cycle de vie du modèle.


| Persona | Tâches | 
| --- | --- | 
| Développeur AWS Glue |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/blueprints-overview.html)  | 
| administrateur AWS Glue |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/blueprints-overview.html)  | 
| Analyste des données |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/blueprints-overview.html)  | 

**Consultez aussi**  
[Développement des plans dans AWS Glue](developing-blueprints.md)
[Création d'un flux de travail à partir d'un plan dans AWS Glue](creating_workflow_blueprint.md)
[Autorisations de personas et de rôles pour les plans AWS Glue](blueprints-personas-permissions.md)

# Développement des plans dans AWS Glue
<a name="developing-blueprints"></a>

En tant que développeur AWS Glue, vous pouvez créer et publier des plans que les analystes de données peuvent utiliser pour générer des flux de travail.

**Topics**
+ [Présentation de l'élaboration de plans](developing-blueprints-overview.md)
+ [Prérequis pour l’élaboration des plans](developing-blueprints-prereq.md)
+ [Rédiger le code du plan](developing-blueprints-code.md)
+ [Exemple de projet de plan](developing-blueprints-sample.md)
+ [Test d'un plan](developing-blueprints-testing.md)
+ [Publication d'un plan](developing-blueprints-publishing.md)
+ [Référence des classes de plan AWS Glue](developing-blueprints-code-classes.md)
+ [Exemples de plans](developing-blueprints-samples.md)

**Consultez aussi**  
[Présentation des plans dans AWS Glue](blueprints-overview.md)

# Présentation de l'élaboration de plans
<a name="developing-blueprints-overview"></a>

La première étape de votre processus de développement consiste à identifier un cas d'utilisation commun pour lequel un modèle serait utile. Un cas d'utilisation typique implique un problème ETL récurrent qui, selon vous, devrait être résolu de manière générale. Ensuite, concevez un modèle qui implémente le cas d'utilisation généralisé et définissez les paramètres d'entrée du modèle qui ensemble, peuvent définir un cas d'utilisation spécifique à partir du cas d'utilisation généralisé.

Un modèle se compose d'un projet, qui contient un fichier de configuration de paramètres du modèle, de même qu'un script qui définit la *structure* du flux de travail à générer. La structure définit les tâches et les crawlers (ou *entities* dans la terminologie du script de modèle) à créer.

Vous ne spécifiez pas directement de déclencheurs dans le script de structure. Au lieu de cela, vous écrivez du code pour spécifier les dépendances entre les tâches et les crawlers que le script crée. AWS Glue génère les déclencheurs en fonction de vos spécifications de dépendances. La sortie du script de structure est un objet de flux de travail, qui contient des spécifications pour toutes les entités de flux de travail.

Vous créez votre objet de flux de travail à l'aide des bibliothèques de plans AWS Glue :
+ `awsglue.blueprint.base_resource` - Bibliothèque de ressources de base utilisées par les bibliothèques.
+ `awsglue.blueprint.workflow` - Bibliothèque permettant de définir une classe `Workflow`.
+ `awsglue.blueprint.job` - Bibliothèque permettant de définir une classe `Job`.
+ `awsglue.blueprint.crawler` - Bibliothèque permettant de définir une classe `Crawler`.

Les seules autres bibliothèques qui sont prises en charge pour la génération de structure sont les bibliothèques qui sont disponibles pour le shell Python.

Avant de publier votre modèle, vous pouvez utiliser les méthodes définies dans les bibliothèques de modèles pour le tester localement.

Lorsque vous êtes prêt à mettre le modèle à la disposition des analystes de données, packagez le script, le fichier de configuration des paramètres et tous les fichiers de support, tels que les scripts et les bibliothèques supplémentaires, en une seule ressource déployable. Chargez ensuite la ressource sur Amazon S3 et demandez à un administrateur de l'enregistrer dans AWS Glue.

Pour plus d'informations sur d'autres projets de modèle, veuillez consulter les rubriques [Exemple de projet de plan](developing-blueprints-sample.md) et [Exemples de plans](developing-blueprints-samples.md).

# Prérequis pour l’élaboration des plans
<a name="developing-blueprints-prereq"></a>

Pour développer des plans, vous devez être familiarisé avec l'utilisation de AWS Glue et l'écriture de scripts pour les tâches ETL Apache Spark ou les tâches shell Python. Vous devez également effectuer les tâches de configuration suivantes.
+ Téléchargez quatre bibliothèques AWS Python à utiliser dans vos scripts de mise en page de plan.
+ Configurez le AWS SDKs.
+ Configurez le AWS CLI.

## Télécharger les bibliothèques Python
<a name="prereqs-get-libes"></a>

Téléchargez les bibliothèques suivantes depuis GitHub et installez-les dans votre projet :
+ [https://github.com/awslabs/aws-glue-blueprint-libs/tree/master/awsglue/blueprint/base\$1resource.py](https://github.com/awslabs/aws-glue-blueprint-libs/tree/master/awsglue/blueprint/base_resource.py)
+ [https://github.com/awslabs/aws-glue-blueprint-libs/tree/master/awsglue/blueprint/workflow.py](https://github.com/awslabs/aws-glue-blueprint-libs/tree/master/awsglue/blueprint/workflow.py)
+ [https://github.com/awslabs/aws-glue-blueprint-libs/tree/master/awsglue/blueprint/crawler.py](https://github.com/awslabs/aws-glue-blueprint-libs/tree/master/awsglue/blueprint/crawler.py)
+ [https://github.com/awslabs/aws-glue-blueprint-libs/tree/master/awsglue/blueprint/job.py](https://github.com/awslabs/aws-glue-blueprint-libs/tree/master/awsglue/blueprint/job.py)

## Configuration du SDK AWS Java
<a name="prereqs-java-preview-sdk"></a>

Pour le SDK AWS Java, vous devez ajouter un `jar` fichier qui inclut l'API pour les plans.

1. Si ce n'est pas déjà fait, configurez le AWS SDK pour Java.
   + Pour Java 1.x, suivez les instructions de la rubrique [Configuration de AWS SDK pour Java](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-install.html) dans le *Guide du développeur AWS SDK pour Java *.
   + Pour Java 2.x, suivez les instructions de la rubrique [Configuration de AWS SDK for Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/setup.html) dans le *Guide du développeur AWS SDK for Java 2.x *.

1. Téléchargez le `jar` fichier client qui a accès aux plans APIs pour les plans.
   + Pour Java 1.x : s3 ://awsglue-custom-blueprints-preview- artifacts/awsglue-java-sdk-preview/AWSGlueJavaClient -1.11.x.jar
   + Pour Java 2.x : s3 ://awsglue-custom-blueprints-preview- artifacts/awsglue-java-sdk-v2-preview/AwsJavaSdk -Glue-2.0.jar

1. Ajoutez le client `jar` au début du chemin de classe Java pour remplacer le client AWS Glue fourni par le AWS SDK Java.

   ```
   export CLASSPATH=<path-to-preview-client-jar>:$CLASSPATH
   ```

1. (Facultatif) Testez le SDK avec l'application Java suivante. L'application doit afficher une liste vide.

   Remplacez `accessKey` et `secretKey` par vos informations d'identification et remplacez `us-east-1` par votre région.

   ```
   import com.amazonaws.auth.AWSCredentials;
   import com.amazonaws.auth.AWSCredentialsProvider;
   import com.amazonaws.auth.AWSStaticCredentialsProvider;
   import com.amazonaws.auth.BasicAWSCredentials;
   import com.amazonaws.services.glue.AWSGlue;
   import com.amazonaws.services.glue.AWSGlueClientBuilder;
   import com.amazonaws.services.glue.model.ListBlueprintsRequest;
   
   public class App{
       public static void main(String[] args) {
           AWSCredentials credentials = new BasicAWSCredentials("accessKey", "secretKey");
           AWSCredentialsProvider provider = new AWSStaticCredentialsProvider(credentials);
           AWSGlue glue = AWSGlueClientBuilder.standard().withCredentials(provider)
                   .withRegion("us-east-1").build();
           ListBlueprintsRequest request = new ListBlueprintsRequest().withMaxResults(2);
           System.out.println(glue.listBlueprints(request));
       }
   }
   ```

## Configuration du SDK AWS Python
<a name="prereqs-python-preview-sdk"></a>

Les étapes suivantes supposent que la version 2.7 ou ultérieure de Python, ou la version 3.9 ou ultérieure, est installée sur votre ordinateur.

1. Téléchargez le fichier Wheel boto3 suivant. Si vous êtes invité à ouvrir ou à enregistrer, enregistrez le fichier. s3 ://awsglue-custom-blueprints-preview- artifacts/aws-python-sdk-preview/boto 3-1.17.31-py2.py3-none-any.whl

1. Téléchargez le fichier botocore wheel suivant : s3 ://awsglue-custom-blueprints-preview- -1.20.31-py2.py3-none-any.whl artifacts/aws-python-sdk-preview/botocore

1. Vérifiez votre version Python.

   ```
   python --version
   ```

1. Selon votre version Python, saisissez les commandes suivantes (pour Linux) :
   + Pour Python 2.7 ou supérieur.

     ```
     python3 -m pip install --user virtualenv
     source env/bin/activate
     ```
   + Pour Python 3.9 ou version ultérieure.

     ```
     python3 -m venv python-sdk-test
     source python-sdk-test/bin/activate
     ```

1. Installez le fichier Wheel botocore.

   ```
   python3 -m pip install <download-directory>/botocore-1.20.31-py2.py3-none-any.whl
   ```

1. Installez le fichier Wheel boto3.

   ```
   python3 -m pip install <download-directory>/boto3-1.17.31-py2.py3-none-any.whl
   ```

1. Configurez vos informations d'identification et région par défaut dans les fichiers `~/.aws/credentials` et `~/.aws/config` suivants. Pour plus d'informations, veuillez consulter la rubrique [Configuration de l' AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) dans le *Guide de l'utilisateur de l'AWS Command Line Interface *.

1. Testez votre configuration (facultatif). Les commandes suivantes doivent renvoyer une liste vide.

   Remplacez `us-east-1` par votre région.

   ```
   $ python
   >>> import boto3
   >>> glue = boto3.client('glue', 'us-east-1')
   >>> glue.list_blueprints()
   ```

## Configuration de l'aperçu AWS CLI
<a name="prereqs-setup-cli"></a>

1. Si ce n'est pas déjà fait, installez and/or update the AWS Command Line Interface (AWS CLI) sur votre ordinateur. La façon la plus simple de procéder est d'utiliser `pip`, l'utilitaire d'installation de Python :

   ```
   pip install awscli --upgrade --user
   ```

   Vous pouvez trouver des instructions d'installation complètes pour l'installation de AWS CLI ici : [Installation de AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html).

1. Téléchargez le fichier de AWS CLI roue depuis : s3 ://awsglue-custom-blueprints-preview- artifacts/awscli-preview-build/awscli -1.19.31-py2.py3-none-any.whl

1. Installez le fichier AWS CLI Wheel.

   ```
   python3 -m pip install awscli-1.19.31-py2.py3-none-any.whl
   ```

1. Exécutez la commande `aws configure`. Configurez vos AWS informations d'identification (y compris la clé d'accès et la clé secrète) et votre AWS région. Vous trouverez des informations sur la configuration du AWS CLI ici : [Configuration du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html).

1. Testez le AWS CLI. La commande suivante doit renvoyer une liste vide.

   Remplacez `us-east-1` par votre région.

   ```
   aws glue list-blueprints --region us-east-1
   ```

# Rédiger le code du plan
<a name="developing-blueprints-code"></a>

Chaque projet de modèle que vous créez doit contenir au minimum les fichiers suivants :
+ Un script de structure Python qui définit le flux de travail. Le script contient une fonction qui définit les entités (tâches et crawlers) dans un flux de travail, ainsi que les dépendances entre elles.
+ Fichier de configuration `blueprint.cfg`, qui définit :
  + Le chemin d'accès complet de la fonction de définition de structure du flux de travail.
  + Les paramètres acceptés par le modèle.

**Topics**
+ [Création du script de structure du plan](developing-blueprints-code-layout.md)
+ [Créez le fichier de configuration](developing-blueprints-code-config.md)
+ [Spécifier les paramètres du plan](developing-blueprints-code-parameters.md)

# Création du script de structure du plan
<a name="developing-blueprints-code-layout"></a>

Le script de structure de modèle doit inclure une fonction qui génère les entités dans votre flux de travail. Vous pouvez nommer cette fonction comme vous le souhaitez. AWS Glue utilise le fichier de configuration pour déterminer le nom complet de la fonction.

Votre fonction de structure effectue les opérations suivantes :
+ (Facultatif) Instancie la classe `Job` pour créer des objets `Job`, et passe des arguments tels que `Command` et `Role`. Ce sont des propriétés de tâche que vous spécifieriez si vous créiez la tâche à l'aide de la console AWS Glue ou de l'API.
+ (Facultatif) Instancie la classe `Crawler` pour créer des objets `Crawler`, et passe les arguments nom, rôle et cible.
+ Pour indiquer les dépendances entre les objets (entités de flux de travail), transmet les arguments supplémentaires `DependsOn` et `WaitForDependencies` à `Job()` et `Crawler()`. Ces arguments sont expliqués plus loin dans cette section.
+ Instancie la classe `Workflow` pour créer l'objet de flux de travail qui est retourné à AWS Glue, en passant un argument `Name`, un argument `Entities`, et un argument facultatif `OnSchedule`. L'argument `Entities` spécifie tous les tâches et les crawlers à inclure dans le flux de travail. Pour voir comment construire un objet `Entities`, vous trouverez l'exemple de projet plus loin dans cette section.
+ Renvoie un objet `Workflow`.

Pour les définitions de classes `Job`, `Crawler` et `Workflow`, veuillez consulter [Référence des classes de plan AWS Glue](developing-blueprints-code-classes.md).

La fonction de structure doit accepter les arguments d'entrée suivants.


| Argument | Description | 
| --- | --- | 
| user\$1params | Dictionnaire Python des noms et valeurs de paramètres de modèle. Pour de plus amples informations, veuillez consulter [Spécifier les paramètres du plan](developing-blueprints-code-parameters.md). | 
| system\$1params | Dictionnaire Python contenant deux propriétés : region et accountId. | 

Voici un exemple de script générateur de structure dans un fichier nommé `Layout.py` :

```
import argparse
import sys
import os
import json
from awsglue.blueprint.workflow import *
from awsglue.blueprint.job import *
from awsglue.blueprint.crawler import *


def generate_layout(user_params, system_params):

    etl_job = Job(Name="{}_etl_job".format(user_params['WorkflowName']),
                  Command={
                      "Name": "glueetl",
                      "ScriptLocation": user_params['ScriptLocation'],
                      "PythonVersion": "2"
                  },
                  Role=user_params['PassRole'])
    post_process_job = Job(Name="{}_post_process".format(user_params['WorkflowName']),
                            Command={
                                "Name": "pythonshell",
                                "ScriptLocation": user_params['ScriptLocation'],
                                "PythonVersion": "2"
                            },
                            Role=user_params['PassRole'],
                            DependsOn={
                                etl_job: "SUCCEEDED"
                            },
                            WaitForDependencies="AND")
    sample_workflow = Workflow(Name=user_params['WorkflowName'],
                            Entities=Entities(Jobs=[etl_job, post_process_job]))
    return sample_workflow
```

L'exemple de script importe les bibliothèques de modèles requises et inclut une fonction `generate_layout` qui génère un flux de travail avec deux tâches. Ceci est un script très simple. Un script plus complexe pourrait utiliser une logique et des paramètres supplémentaires pour générer un flux de travail avec de nombreux crawlers et tâches, ou même un nombre variable de tâches et d'crawlers.

## Utilisation de l' DependsOn argument
<a name="developing-blueprints-code-layout-depends-on"></a>

L'argument `DependsOn` est une représentation sous forme de dictionnaire d'une dépendance que cette entité a sur d'autres entités dans le flux de travail. Elle se présente sous la forme suivante. 

```
DependsOn = {dependency1 : state, dependency2 : state, ...}
```

Les clés de ce dictionnaire représentent la référence d'objet, et non le nom, de l'entité, tandis que les valeurs sont des chaînes qui correspondent à l'état à surveiller. AWS Glue déduit les déclencheurs appropriés. Pour connaître les états valides, veuillez consulter [Condition Structure (Structure des conditions)](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-jobs-trigger.html#aws-glue-api-jobs-trigger-Condition).

Par exemple, une tâche peut dépendre de la réussite d'un crawler. Si vous définissez un objet crawler nommé `crawler2` comme suit :

```
crawler2 = Crawler(Name="my_crawler", ...)
```

Ensuite, un objet dépendant de `crawler2` comprendrait un argument de constructeur tel que : 

```
DependsOn = {crawler2 : "SUCCEEDED"}
```

Par exemple :

```
job1 = Job(Name="Job1", ..., DependsOn = {crawler2 : "SUCCEEDED", ...})
```

Si `DependsOn` est omis pour une entité, cette entité dépend du déclencheur de démarrage du flux de travail.

## Utilisation de l' WaitForDependencies argument
<a name="developing-blueprints-code-layout-wait-for-dependencies"></a>

L'argument `WaitForDependencies` définit si une entité de tâche ou d'crawler doit attendre jusqu'à ce que *toutes* les entités dont elle dépend se terminent ou qu'*une seule d'entre elles* se termine.

Les valeurs autorisées sont « `AND` » ou « `ANY` ».

## Utilisation de l' OnSchedule argument
<a name="developing-blueprints-code-layout-on-schedule"></a>

L'argument `OnSchedule` pour le constructeur de classe `Workflow` est une expression `cron` qui définit la définition de déclenchement de démarrage d'un flux de travail.

Si cet argument est spécifié, AWS Glue crée un déclencheur de planification avec la planification correspondante. Si elle n'est pas spécifiée, le déclencheur de démarrage du flux de travail est un déclencheur à la demande.

# Créez le fichier de configuration
<a name="developing-blueprints-code-config"></a>

Le fichier de configuration de modèle est un fichier obligatoire qui définit le point d'entrée de script pour la génération du flux de travail et les paramètres que le modèle accepte. Le fichier doit être nommé `blueprint.cfg`.

Voici un exemple de fichier de configuration.

```
{
    "layoutGenerator": "DemoBlueprintProject.Layout.generate_layout",
    "parameterSpec" : {
           "WorkflowName" : {
                "type": "String",
                "collection": false
           },
           "WorkerType" : {
                "type": "String",
                "collection": false,
                "allowedValues": ["G1.X", "G2.X"],
                "defaultValue": "G1.X"
           },
           "Dpu" : {
                "type" : "Integer",
                "allowedValues" : [2, 4, 6],
                "defaultValue" : 2
           },
           "DynamoDBTableName": {
                "type": "String",
                "collection" : false
           },
           "ScriptLocation" : {
                "type": "String",
                "collection": false
    	}
    }
}
```

La propriété `layoutGenerator` spécifie le nom complet de la fonction dans le script qui génère la structure.

La propriété `parameterSpec` spécifie les paramètres que ce modèle accepte. Pour de plus amples informations, veuillez consulter [Spécifier les paramètres du plan](developing-blueprints-code-parameters.md).

**Important**  
Votre fichier de configuration doit inclure le nom du flux de travail en tant que paramètre de modèle, ou vous devez générer un nom de flux de travail unique dans votre script de structure.

# Spécifier les paramètres du plan
<a name="developing-blueprints-code-parameters"></a>

Le fichier de configuration contient les spécifications des paramètres de modèle dans un objet JSON `parameterSpec`. `parameterSpec` contient un ou plusieurs objets paramètres.

```
"parameterSpec": {
    "<parameter_name>": {
      "type": "<parameter-type>",
      "collection": true|false, 
      "description": "<parameter-description>",
      "defaultValue": "<default value for the parameter if value not specified>"
      "allowedValues": "<list of allowed values>" 
    },
    "<parameter_name>": {    
       ...
    }
  }
```

Voici les règles de codage de chaque objet paramètre :
+ Le nom du paramètre et `type` sont obligatoires. Toutes les autres propriétés sont facultatives.
+ Si vous spécifiez la propriété `defaultValue`, le paramètre est facultatif. Sinon, le paramètre est obligatoire et l'analyste de données qui crée un flux de travail à partir du modèle doit lui fournir une valeur.
+ Si vous définissez la propriété `collection` à `true`, le paramètre peut prendre une collection de valeurs. Les collections peuvent être de n'importe quel type de données.
+ Si vous spécifiez `allowedValues`, la console AWS Glue affiche une liste déroulante de valeurs que l'analyste de données doit choisir lors de la création d'un flux de travail à partir du plan.

Les valeurs suivantes sont autorisées pour `type` :


| Types de données de paramètre | Remarques | 
| --- | --- | 
| String | - | 
| Integer | - | 
| Double | - | 
| Boolean | Les valeurs possibles sont true et false. Génère une case à vérifier sur la page Create a workflow from <blueprint> (Créer un flux de travail à partir du <blueprint>) sur la console AWS Glue. | 
| S3Uri | Chemin d'accès Amazon S3, en commençant par s3://. Génère un champ de texte et un bouton Browse (Parcourir)sur la page Create a workflow from <blueprint> (Créer un flux de travail à partir du <blueprint>). | 
| S3Bucket | Noms du compartiment Amazon S3 uniquement. Génère un sélecteur de compartiment sur la page Create a workflow from <blueprint> (Créer un flux de travail à partir du <blueprint>). | 
| IAMRoleArn | Nom de ressource Amazon (ARN) d'un rôle Gestion des identités et des accès AWS (IAM). Génère un sélecteur de rôle sur la page Create a workflow from <blueprint> (Créer un flux de travail à partir du <blueprint>). | 
| IAMRoleName | Nom d'un rôle IAM. Génère un sélecteur de rôle sur la page Create a workflow from <blueprint> (Créer un flux de travail à partir du <blueprint>). | 

# Exemple de projet de plan
<a name="developing-blueprints-sample"></a>

La conversion de format de données est un cas d'utilisation fréquent d'extraction, de transformation et de chargement (ETL). Dans les charges de travail analytiques typiques, les formats de fichiers basés sur des colonnes comme Parquet ou ORC sont préférés aux formats de texte tels que CSV ou JSON. Cet exemple de plan vous permet de convertir des données CSV/JSON/etc de. en Parquet pour les fichiers sur Amazon S3. 

Ce modèle prend une liste de chemins S3 définis par un paramètre de modèle, convertit les données au format Parquet et les écrit à l'emplacement S3 spécifié par un autre paramètre de modèle. Le script de structure crée un crawler et une tâche pour chaque chemin d'accès. Le script de structure télécharge également le script ETL se trouvant dans `Conversion.py` vers un compartiment S3 spécifié par un autre paramètre de modèle. Le script de structure spécifie ensuite le script téléchargé en tant que script ETL pour chaque tâche. L'archive ZIP du projet contient le script de structure, le script ETL et le fichier de configuration du modèle.

Pour plus d'informations sur d'autres projets de modèle, veuillez consulter la rubrique [Exemples de plans](developing-blueprints-samples.md).

Ce qui suit est le script de structure, dans le fichier `Layout.py`.

```
from awsglue.blueprint.workflow import *
from awsglue.blueprint.job import *
from awsglue.blueprint.crawler import *
import boto3

s3_client = boto3.client('s3')

# Ingesting all the S3 paths as Glue table in parquet format
def generate_layout(user_params, system_params):
    #Always give the full path for the file
    with open("ConversionBlueprint/Conversion.py", "rb") as f:
        s3_client.upload_fileobj(f, user_params['ScriptsBucket'], "Conversion.py")
    etlScriptLocation = "s3://{}/Conversion.py".format(user_params['ScriptsBucket'])    
    crawlers = []
    jobs = []
    workflowName = user_params['WorkflowName']
    for path in user_params['S3Paths']:
      tablePrefix = "source_" 
      crawler = Crawler(Name="{}_crawler".format(workflowName),
                        Role=user_params['PassRole'],
                        DatabaseName=user_params['TargetDatabase'],
                        TablePrefix=tablePrefix,
                        Targets= {"S3Targets": [{"Path": path}]})
      crawlers.append(crawler)
      transform_job = Job(Name="{}_transform_job".format(workflowName),
                         Command={"Name": "glueetl",
                                  "ScriptLocation": etlScriptLocation,
                                  "PythonVersion": "3"},
                         Role=user_params['PassRole'],
                         DefaultArguments={"--database_name": user_params['TargetDatabase'],
                                           "--table_prefix": tablePrefix,
                                           "--region_name": system_params['region'],
                                           "--output_path": user_params['TargetS3Location']},
                         DependsOn={crawler: "SUCCEEDED"},
                         WaitForDependencies="AND")
      jobs.append(transform_job)
    conversion_workflow = Workflow(Name=workflowName, Entities=Entities(Jobs=jobs, Crawlers=crawlers))
    return conversion_workflow
```

Ce qui suit est le fichier de configuration du modèle correspondant `blueprint.cfg`.

```
{
    "layoutGenerator": "ConversionBlueprint.Layout.generate_layout",
    "parameterSpec" : {
        "WorkflowName" : {
            "type": "String",
            "collection": false,
            "description": "Name for the workflow."
        },
        "S3Paths" : {
            "type": "S3Uri",
            "collection": true,
            "description": "List of Amazon S3 paths for data ingestion."
        },
        "PassRole" : {
            "type": "IAMRoleName",
            "collection": false,
            "description": "Choose an IAM role to be used in running the job/crawler"
        },
        "TargetDatabase": {
            "type": "String",
            "collection" : false,
            "description": "Choose a database in the Data Catalog."
        },
        "TargetS3Location": {
            "type": "S3Uri",
            "collection" : false,
            "description": "Choose an Amazon S3 output path: ex:s3://<target_path>/."
        },
        "ScriptsBucket": {
            "type": "S3Bucket",
            "collection": false,
            "description": "Provide an S3 bucket name(in the same AWS Region) to store the scripts."
        }
    }
}
```

Le script suivant dans le fichier `Conversion.py` est le script ETL téléchargé. Notez qu'il conserve le schéma de partitionnement pendant la conversion. 

```
import sys
from pyspark.sql.functions import *
from pyspark.context import SparkContext
from awsglue.transforms import *
from awsglue.context import GlueContext
from awsglue.job import Job
from awsglue.utils import getResolvedOptions
import boto3

args = getResolvedOptions(sys.argv, [
    'JOB_NAME',
    'region_name',
    'database_name',
    'table_prefix',
    'output_path'])
databaseName = args['database_name']
tablePrefix = args['table_prefix']
outputPath = args['output_path']

glue = boto3.client('glue', region_name=args['region_name'])

glue_context = GlueContext(SparkContext.getOrCreate())
spark = glue_context.spark_session
job = Job(glue_context)
job.init(args['JOB_NAME'], args)

def get_tables(database_name, table_prefix):
    tables = []
    paginator = glue.get_paginator('get_tables')
    for page in paginator.paginate(DatabaseName=database_name, Expression=table_prefix+"*"):
        tables.extend(page['TableList'])
    return tables

for table in get_tables(databaseName, tablePrefix):
    tableName = table['Name']
    partitionList = table['PartitionKeys']
    partitionKeys = []
    for partition in partitionList:
        partitionKeys.append(partition['Name'])

    # Create DynamicFrame from Catalog
    dyf = glue_context.create_dynamic_frame.from_catalog(
        name_space=databaseName,
        table_name=tableName,
        additional_options={
            'useS3ListImplementation': True
        },
        transformation_ctx='dyf'
    )

    # Resolve choice type with make_struct
    dyf = ResolveChoice.apply(
        frame=dyf,
        choice='make_struct',
        transformation_ctx='resolvechoice_' + tableName
    )

    # Drop null fields
    dyf = DropNullFields.apply(
        frame=dyf,
        transformation_ctx="dropnullfields_" + tableName
    )

    # Write DynamicFrame to S3 in glueparquet
    sink = glue_context.getSink(
        connection_type="s3",
        path=outputPath,
        enableUpdateCatalog=True,
        partitionKeys=partitionKeys
    )
    sink.setFormat("glueparquet")

    sink.setCatalogInfo(
        catalogDatabase=databaseName,
        catalogTableName=tableName[len(tablePrefix):]
    )
    sink.writeFrame(dyf)

job.commit()
```

**Note**  
Seuls deux chemins Amazon S3 peuvent être fournis en entrée pour l'exemple de modèle. La raison en est que les déclencheurs AWS Glue sont limités à invoquer seulement deux actions de crawler.

# Test d'un plan
<a name="developing-blueprints-testing"></a>

Pendant que vous développez votre code, vous devez effectuer des tests locaux pour vérifier que la structure du flux de travail est correcte.

Les tests locaux ne génèrent pas de tâches, d'crawlers ou de déclencheurs AWS Glue. Au lieu de cela, vous exécutez le script de structure localement et utilisez la méthode `to_json()` et `validate()` pour imprimer des objets et trouver des erreurs. Ces méthodes sont disponibles dans les trois classes définies dans les bibliothèques. 

Il existe deux façons de gérer les arguments `user_params` et `system_params` que AWS Glue passe à votre fonction de structure. Votre code de banc de test peut créer un dictionnaire d'exemples de valeurs de paramètre de modèle et le transmettre à la fonction de structure en tant qu'argument `user_params`. Vous pouvez également supprimer les références à `user_params` et remplacez-les par des chaînes codées en dur.

Si votre code utilise les propriétés `region` et `accountId` dans `system_params`, vous pouvez passer votre propre dictionnaire pour `system_params`.

**Pour tester un modèle**

1. Démarrez un interpréteur Python dans un répertoire avec les bibliothèques, ou chargez les fichiers du modèle et les bibliothèques fournies dans votre environnement de développement intégré (IDE) préféré.

1. Assurez-vous que votre code importe les bibliothèques fournies.

1. Ajouter du code à votre fonction de structure pour appeler `validate()` ou `to_json()` sur n'importe quelle entité ou sur l'objet `Workflow`. Par exemple, si votre code crée un objet `Crawler` nommé `mycrawler`, vous pouvez appeler `validate()` comme suit.

   ```
   mycrawler.validate()
   ```

   Vous pouvez imprimer `mycrawler` comme suit :

   ```
   print(mycrawler.to_json())
   ```

   Si vous appelez `to_json` sur un objet, il n'est pas nécessaire d'appeler également `validate()`, parce que ` to_json()` appelle `validate()`. 

   Il est plus utile d'appeler ces méthodes sur l'objet de flux de travail. En supposant que votre script nomme l'objet de flux de travail `my_workflow`, validez et imprimez l'objet de flux de travail comme suit.

   ```
   print(my_workflow.to_json())
   ```

   Pour plus d'informations sur `to_json()` et `validate()`, consultez [Méthodes de classe](developing-blueprints-code-classes.md#developing-blueprints-code-methods).

   Vous pouvez également importer `pprint` et imprimer l'objet de flux de travail, tel que décrit dans l'exemple plus loin dans cette section.

1. Exécutez le code, corrigez les erreurs et supprimez enfin tous les appels à `validate()` ou `to_json()`.

**Example**  
L'exemple suivant montre comment construire un dictionnaire d'exemples de paramètres de modèle et le transmettre en tant qu'argument `user_params` à la fonction de structure `generate_compaction_workflow`. L'exemple montre également comment imprimer automatiquement l'objet de flux de travail généré.  

```
from pprint import pprint
from awsglue.blueprint.workflow import *
from awsglue.blueprint.job import *
from awsglue.blueprint.crawler import *
 
USER_PARAMS = {"WorkflowName": "compaction_workflow",
               "ScriptLocation": "s3://amzn-s3-demo-bucket/scripts/threaded-compaction.py",
               "PassRole": "arn:aws:iam::111122223333:role/GlueRole-ETL",
               "DatabaseName": "cloudtrial",
               "TableName": "ct_cloudtrail",
               "CoalesceFactor": 4,
               "MaxThreadWorkers": 200}
 
 
def generate_compaction_workflow(user_params: dict, system_params: dict) -> Workflow:
    compaction_job = Job(Name=f"{user_params['WorkflowName']}_etl_job",
                         Command={"Name": "glueetl",
                                  "ScriptLocation": user_params['ScriptLocation'],
                                  "PythonVersion": "3"},
                         Role="arn:aws:iam::111122223333:role/AWSGlueServiceRoleDefault",
                         DefaultArguments={"DatabaseName": user_params['DatabaseName'],
                                           "TableName": user_params['TableName'],
                                           "CoalesceFactor": user_params['CoalesceFactor'],
                                           "max_thread_workers": user_params['MaxThreadWorkers']})
 
    catalog_target = {"CatalogTargets": [{"DatabaseName": user_params['DatabaseName'], "Tables": [user_params['TableName']]}]}
 
    compacted_files_crawler = Crawler(Name=f"{user_params['WorkflowName']}_post_crawl",
                                      Targets = catalog_target,
                                      Role=user_params['PassRole'],
                                      DependsOn={compaction_job: "SUCCEEDED"},
                                      WaitForDependencies="AND",
                                      SchemaChangePolicy={"DeleteBehavior": "LOG"})
 
    compaction_workflow = Workflow(Name=user_params['WorkflowName'],
                                   Entities=Entities(Jobs=[compaction_job],
                                                     Crawlers=[compacted_files_crawler]))
    return compaction_workflow
 
generated = generate_compaction_workflow(user_params=USER_PARAMS, system_params={})
gen_dict = generated.to_json()
 
pprint(gen_dict)
```

# Publication d'un plan
<a name="developing-blueprints-publishing"></a>

Une fois que vous avez développé un modèle, vous devez le télécharger vers Amazon S3. Vous devez disposer d'autorisations en écriture sur le compartiment Amazon S3 que vous utilisez pour publier le modèle. Vous devez également vous assurer que l'administrateur AWS Glue, qui enregistrera le plan, dispose d'un accès en lecture au compartiment Amazon S3. Pour les politiques d'autorisation Gestion des identités et des accès AWS (IAM) suggérées pour les personas et les rôles pour les AWS Glue plans, voir. [Autorisations de personas et de rôles pour les plans AWS Glue](blueprints-personas-permissions.md)

**Pour publier un modèle**

1. Créez les scripts, les ressources et le fichier de configuration de modèle nécessaires.

1. Ajoutez tous les fichiers à une archive ZIP et téléchargez ce fichier ZIP sur Amazon S3. Utilisez un compartiment S3 qui se trouve dans la même région que celle dans laquelle les utilisateurs vont enregistrer et exécuter le modèle.

   Vous pouvez créer un fichier ZIP à partir de la ligne de commande à l'aide de la commande suivante.

   ```
   zip -r folder.zip folder
   ```

1. Ajoutez une politique de compartiment qui accorde des autorisations de lecture au compte AWS souhaité. Voici un exemple de politique.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "arn:aws:iam::111122223333:root"
         },
         "Action": "s3:GetObject",
         "Resource": "arn:aws:s3:::my-blueprints/*"
       }
     ]
   }
   ```

------

1. Accorder à l'administrateur AWS Glue, ou à quiconque va enregistrer des plans, l'autorisation IAM `s3:GetObject` d'accès au compartiment Amazon S3. Pour obtenir un exemple de politique d'octroi d'accès aux administrateurs, veuillez consulter la rubrique [Autorisations d'administrateur AWS Glue pour les plans](blueprints-personas-permissions.md#bp-persona-admin).

Une fois que vous avez terminé les tests locaux de votre plan, vous pouvez également tester un plan sur AWS Glue. Pour tester un plan sur AWS Glue, il doit être enregistré. Vous pouvez limiter qui voit le modèle enregistré à l'aide de l'autorisation IAM ou à l'aide de comptes de test distincts.

**Voir aussi :**  
[Enregistrement d'un plan dans AWS Glue](registering-blueprints.md)

# Référence des classes de plan AWS Glue
<a name="developing-blueprints-code-classes"></a>

Les bibliothèques pour les modèles AWS Glue définissent trois classes que vous utilisez dans votre script de structure de flux de travail : `Job`, `Crawler` et `Workflow`.

**Topics**
+ [Classe Tâche](#developing-blueprints-code-jobclass)
+ [Classe de crawler](#developing-blueprints-code-crawlerclass)
+ [Classe de flux de travail](#developing-blueprints-code-workflowclass)
+ [Méthodes de classe](#developing-blueprints-code-methods)

## Classe Tâche
<a name="developing-blueprints-code-jobclass"></a>

La classe `Job` représente une tâche ETL AWS Glue.

**Arguments de constructeur obligatoires**  
Les arguments de constructeur suivants sont obligatoires pour la classe `Job`.


| Nom d'argument | Type | Description | 
| --- | --- | --- | 
| Name | str | Nom à affecter à la tâche. AWS Glue ajoute un suffixe généré de manière aléatoire au nom pour distinguer la tâche de celles créées par d'autres exécutions de plan. | 
| Role | str | Amazon Resource Name (ARN) du rôle que la tâche doit assumer lors de son exécution. | 
| Command | dict | Commande de tâche, comme spécifié dans la rubrique [JobCommand structure](aws-glue-api-jobs-job.md#aws-glue-api-jobs-job-JobCommand) de la documentation de l'API.  | 

**Arguments de constructeur facultatifs**  
Les arguments de constructeur suivants sont facultatifs pour la classe `Job`.


| Nom d'argument | Type | Description | 
| --- | --- | --- | 
| DependsOn | dict | Liste des entités de flux de travail dont dépend la tâche. Pour de plus amples informations, veuillez consulter [Utilisation de l' DependsOn argument](developing-blueprints-code-layout.md#developing-blueprints-code-layout-depends-on). | 
| WaitForDependencies | str | Indique si la tâche doit attendre jusqu'à ce que toutes les entités dont elle dépend se terminent ou qu'une seule d'entre elles se termine avant de s'exécuter. Pour de plus amples informations, veuillez consulter [Utilisation de l' WaitForDependencies argument](developing-blueprints-code-layout.md#developing-blueprints-code-layout-wait-for-dependencies). Omettre si la tâche ne dépend que d'une seule entité. | 
| (Propriétés de la tâche) | - | Toutes les propriétés de tâche répertoriées dans [Structure Job](aws-glue-api-jobs-job.md#aws-glue-api-jobs-job-Job) dans la documentation de l'API AWS Glue (sauf CreatedOn et LastModifiedOn). | 

## Classe de crawler
<a name="developing-blueprints-code-crawlerclass"></a>

La classe `Crawler` représente un crawler AWS Glue.

**Arguments de constructeur obligatoires**  
Les arguments de constructeur suivants sont obligatoires pour la classe `Crawler`.


| Nom d'argument | Type | Description | 
| --- | --- | --- | 
| Name | str | Nom à affecter à la recherche. AWS Glue ajoute un suffixe généré de manière aléatoire au nom pour distinguer l'crawler de ceux créés par d'autres exécutions de plan. | 
| Role | str | ARN du rôle que l'crawler doit assumer lors de l'exécution. | 
| Targets | dict | Collecte de cibles à analyser. Les arguments de constructeur de classe Targets sont définis dans la rubrique [CrawlerTargets structure](aws-glue-api-crawler-crawling.md#aws-glue-api-crawler-crawling-CrawlerTargets) de la documentation de l'API. Tous les arguments de constructeur Targets sont facultatifs, mais vous devez en passer au moins un.  | 

**Arguments de constructeur facultatifs**  
Les arguments de constructeur suivants sont facultatifs pour la classe `Crawler`.


| Nom d'argument | Type | Description | 
| --- | --- | --- | 
| DependsOn | dict | Liste des entités de flux de travail dont dépend l'crawler. Pour de plus amples informations, veuillez consulter [Utilisation de l' DependsOn argument](developing-blueprints-code-layout.md#developing-blueprints-code-layout-depends-on). | 
| WaitForDependencies | str | Indique si l'crawler doit attendre jusqu'à ce que toutes les entités dont il dépend se terminent ou qu'une seule d'entre elles se termine avant de s'exécuter. Pour de plus amples informations, veuillez consulter [Utilisation de l' WaitForDependencies argument](developing-blueprints-code-layout.md#developing-blueprints-code-layout-wait-for-dependencies). Omettre si l'crawler ne dépend que d'une seule entité. | 
| (Propriétés de l'crawler) | - | Toutes les propriétés de l'crawler répertoriées dans [Structure du crawler](aws-glue-api-crawler-crawling.md#aws-glue-api-crawler-crawling-Crawler) de la documentation de l'API AWS Glue, avec les exceptions suivantes :[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/developing-blueprints-code-classes.html) | 

## Classe de flux de travail
<a name="developing-blueprints-code-workflowclass"></a>

La classe `Workflow` représente un flux de travail AWS Glue. Le script de mise en page du flux de travail renvoie un objet `Workflow`. AWS Glue crée un flux de travail basé sur cet objet.

**Arguments de constructeur obligatoires**  
Les arguments de constructeur suivants sont obligatoires pour la classe `Workflow`.


| Nom d'argument | Type | Description | 
| --- | --- | --- | 
| Name | str | Nom à affecter au flux de travail. | 
| Entities | Entities | Ensemble d'entités (tâches et crawlers) à inclure dans le flux de travail. Le constructeur de classe Entities accepte un argument Jobs, qui est une liste de Job et un objet Crawlers, qui est une liste d'objets Crawler. | 

**Arguments de constructeur facultatifs**  
Les arguments de constructeur suivants sont facultatifs pour la classe `Workflow`.


| Nom d'argument | Type | Description | 
| --- | --- | --- | 
| Description | str | Consultez [Structure de flux de travail](aws-glue-api-workflow.md#aws-glue-api-workflow-Workflow). | 
| DefaultRunProperties | dict | Consultez [Structure de flux de travail](aws-glue-api-workflow.md#aws-glue-api-workflow-Workflow). | 
| OnSchedule | str | Une expression cron. | 

## Méthodes de classe
<a name="developing-blueprints-code-methods"></a>

Les trois classes comprennent les méthodes suivantes.

**validate()**  
Valide les propriétés de l'objet et, si des erreurs sont détectées, affiche un message et sort. Ne génère aucune sortie s'il n'y a pas d'erreurs. Pour la classe `Workflow`, s'appelle elle-même pour chaque entité du flux de travail.

**to\$1json()**  
Sérialise l'objet au format JSON. Appelle également `validate()`. Pour la classe `Workflow`, l'objet JSON inclut des listes de tâches et d'crawlers, ainsi qu'une liste de déclencheurs générés par les spécifications de dépendance de la tâche et de l'crawler.

# Exemples de plans
<a name="developing-blueprints-samples"></a>

Un certain nombre d'exemples de projets de plan sont disponibles dans le [répertoire Github de plan AWS Glue](https://github.com/awslabs/aws-glue-blueprint-libs/tree/master/samples). Ces exemples sont à titre de référence seulement et ne sont pas destinés à la production.

Les titres des projets exemples sont :
+ Compactage : ce modèle crée une tâche qui compacte les fichiers d'entrée en paquets plus volumineux en fonction de la taille de fichier souhaitée.
+ Conversion : ce modèle convertit les fichiers d'entrée dans différents formats de fichiers standard au format Apache Parquet, qui est optimisé pour les charges de travail analytiques.
+ Analyse des emplacements Amazon S3 : ce modèle analyse plusieurs emplacements Amazon S3 pour ajouter des tables de métadonnées au catalogue de données.
+ Connexion personnalisée au catalogue de données : ce plan accède aux magasins de données à l'aide de connecteurs AWS Glue personnalisés, lit les enregistrements et remplit les définitions des tables dans le catalogue de données AWS Glue en fonction du schéma d'enregistrement.
+ Encodage : ce modèle convertit vos fichiers non-UTF en fichiers encodés UTF.
+ Partitionnement : ce modèle crée une tâche de partitionnement qui place les fichiers de sortie dans des partitions basées sur des clés de partition spécifiques.
+ Importation de données Amazon S3 dans une table DynamoDB : ce modèle importe les données d'Amazon S3 dans une table DynamoDB.
+ Table standard à gouverner : ce plan importe une table AWS Glue Data Catalog dans une table Lake Formation.

# Enregistrement d'un plan dans AWS Glue
<a name="registering-blueprints"></a>

Une fois que le développeur AWS Glue a codé le plan et téléchargé une archive ZIP sur Amazon Simple Storage Service (Amazon S3), un administrateur AWS Glue doit enregistrer ce plan. L'enregistrement du modèle le rend disponible pour utilisation.

Lorsque vous enregistrez un plan, AWS Glue copie l'archive de celui-ci vers un emplacement Amazon S3 réservé. Vous pouvez ensuite supprimer l'archive de l'emplacement de téléchargement.

Pour enregistrer un modèle, vous avez besoin d'autorisations de lecture sur l'emplacement Amazon S3 qui contient l'archive téléchargée. Vous avez également besoin de l'autorisation Gestion des identités et des accès AWS `glue:CreateBlueprint` (IAM). Pour obtenir les autorisations suggérées pour un administrateur AWS Glue qui doit enregistrer, afficher et gérer des plans, consulter [Autorisations d'administrateur AWS Glue pour les plans](blueprints-personas-permissions.md#bp-persona-admin).

Vous pouvez enregistrer un plan en utilisant la console AWS Glue, l'API AWS Glue ou AWS Command Line Interface (AWS CLI).

**Pour enregistrer un modèle (console)**

1. Assurez-vous de disposer des autorisations de lecture (`s3:GetObject`) dans l'archive ZIP du modèle dans Amazon S3.

1. Ouvrez la console AWS Glue à l’adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

   Connectez-vous sous un profil utilisateur qui dispose des autorisations nécessaires pour enregistrer un modèle. Basculez vers la même région AWS en tant que compartiment Amazon S3 contenant l'archive ZIP du modèle.

1. Dans le panneau de navigation, sélectionnez **Plans**. Ensuite, sur la page **Plans**, sélectionnez **Ajouter un plan**.

1. Saisissez un nom de modèle et, éventuellement, une description.

1. Pour **ZIP archive location (S3)** (Emplacement de l'archive ZIP [S3]), saisissez le chemin Amazon S3 de l'archive ZIP du modèle téléchargé. Incluez le nom du fichier d'archive dans le chemin d'accès et commencez le chemin par `s3://`.

1. (Facultatif) Ajoutez une balise ou plusieurs balises.

1. Sélectionnez **Add blueprint** (Ajouter un modèle).

   La page **Plans** renvoie des résultats et indique que le statut du plan est à `CREATING`. Cliquez sur le bouton d'actualisation jusqu'à ce que le statut devienne `ACTIVE` ou `FAILED`.

1. Si le statut est `FAILED`, sélectionnez le modèle et dans le menu **Actions**, sélectionnez **View** (Afficher).

   La page des détails indique la raison de l'échec. Si le message d'erreur est « Unable to access object at location... » (Impossible d'accéder à l'objet à l'emplacement...) ou « Access denied on object at location... » (Accès refusé sur l'objet à l'emplacement...), passez en revue les exigences suivantes :
   + L'utilisateur sous lequel vous êtes connecté doit disposer d'une autorisation de lecture sur l'archive ZIP du modèle dans Amazon S3.
   + Le compartiment Amazon S3 qui contient l'archive ZIP doit avoir une politique de compartiment qui accorde une autorisation de lecture sur l'objet à votre identifiant de AWS compte. Pour de plus amples informations, veuillez consulter [Développement des plans dans AWS Glue](developing-blueprints.md).
   + Le compartiment Amazon S3 que vous utilisez doit se trouver dans la même région que la région à laquelle vous êtes connecté sur la console.

1. Assurez-vous que les analystes de données disposent d'autorisations sur le modèle.

   La politique IAM suggérée pour les analystes des données est illustrée dans[Autorisations d'analyste des données pour les plans](blueprints-personas-permissions.md#bp-persona-analyst). Cette politique accorde `glue:GetBlueprint` pour n'importe quelle ressource. Si votre politique est plus précise au niveau des ressources, accordez des autorisations aux analystes des données sur cette ressource qui vient d'être créée.

**Pour enregistrer un plan (AWS CLI)**

1. Entrez la commande suivante.

   ```
   aws glue create-blueprint --name <blueprint-name> [--description <description>] --blueprint-location s3://<s3-path>/<archive-filename>
   ```

1. Pour vérifier l'état du modèle, saisissez la commande suivante. Répétez la commande jusqu'à ce que le statut devienne `ACTIVE` ou `FAILED`.

   ```
   aws glue get-blueprint --name <blueprint-name>
   ```

   Si le statut est `FAILED` et le message d'erreur est « Unable to access object at location... » (Impossible d'accéder à l'objet à l'emplacement...) ou « Access denied on object at location... » (Accès refusé sur l'objet à l'emplacement...), passez en revue les exigences suivantes :
   + L'utilisateur sous lequel vous êtes connecté doit disposer d'une autorisation de lecture sur l'archive ZIP du modèle dans Amazon S3.
   + Le compartiment Amazon S3 contenant l'archive ZIP doit avoir une politique de compartiment qui accorde une autorisation de lecture sur l'objet à votre identifiant de AWS compte. Pour de plus amples informations, veuillez consulter [Publication d'un plan](developing-blueprints-publishing.md).
   + Le compartiment Amazon S3 que vous utilisez doit se trouver dans la même région que la région à laquelle vous êtes connecté sur la console.

**Voir aussi :**  
[Présentation des plans dans AWS Glue](blueprints-overview.md)

# Affichage des plans dans AWS Glue
<a name="viewing_blueprints"></a>

Affichez un modèle pour consulter la description, l'état et les spécifications des paramètres du celui-ci, et pour télécharger son archive ZIP.

Vous pouvez afficher un plan à l'aide de la console AWS Glue, de l'API AWS Glue, ou de l' AWS Command Line Interface (AWS CLI).

**Pour afficher un modèle (console)**

1. Ouvrez la console AWS Glue à l’adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

1. Dans le panneau de navigation, sélectionnez **Plans**.

1. Sur la page **plans**, sélectionnez un plan. Ensuite, dans le menu **Actions**, sélectionnez **View (Afficher)**.

**Pour afficher un plan (AWS CLI)**
+ Saisissez la commande suivante pour afficher uniquement le nom, la description et l'état du modèle. Remplacez *<blueprint-name>* par le nom du plan à afficher.

  ```
  aws glue get-blueprint --name <blueprint-name>
  ```

  Le résultat de la commande se présente comme suit.

  ```
  {
      "Blueprint": {
          "Name": "myDemoBP",
          "CreatedOn": 1587414516.92,
          "LastModifiedOn": 1587428838.671,
          "BlueprintLocation": "s3://amzn-s3-demo-bucket1/demo/DemoBlueprintProject.zip",
          "Status": "ACTIVE"
      }
  }
  ```

  Saisissez la commande suivante pour afficher également les spécifications des paramètres.

  ```
  aws glue get-blueprint --name <blueprint-name>  --include-parameter-spec
  ```

  Le résultat de la commande se présente comme suit.

  ```
  {
      "Blueprint": {
          "Name": "myDemoBP",
          "CreatedOn": 1587414516.92,
          "LastModifiedOn": 1587428838.671,
          "ParameterSpec": "{\"WorkflowName\":{\"type\":\"String\",\"collection\":false,\"description\":null,\"defaultValue\":null,\"allowedValues\":null},\"PassRole\":{\"type\":\"String\",\"collection\":false,\"description\":null,\"defaultValue\":null,\"allowedValues\":null},\"DynamoDBTableName\":{\"type\":\"String\",\"collection\":false,\"description\":null,\"defaultValue\":null,\"allowedValues\":null},\"ScriptLocation\":{\"type\":\"String\",\"collection\":false,\"description\":null,\"defaultValue\":null,\"allowedValues\":null}}",
          "BlueprintLocation": "s3://awsexamplebucket1/demo/DemoBlueprintProject.zip",
          "Status": "ACTIVE"
      }
  }
  ```

  Ajoutez `--include-blueprint` pour inclure une URL dans le résultat que vous pouvez coller dans votre navigateur pour télécharger l'archive ZIP du plan que AWS Glue a stocké.

**Voir aussi :**  
[Présentation des plans dans AWS Glue](blueprints-overview.md)

# Mise à jour d'un plan dans AWS Glue
<a name="updating_blueprints"></a>

Vous pouvez mettre à jour un modèle si vous disposez d'un script de mise en page révisé, d'un ensemble révisé de paramètres de modèle ou de fichiers de support révisés. La mise à jour d'un modèle crée une nouvelle version.

La mise à jour d'un modèle n'affecte pas les flux de travail existants créés à partir du modèle.

Vous pouvez mettre à jour un plan en utilisant la console AWS Glue Glue, l'API Glue AWS Glue ou AWS Command Line Interface (AWS CLI).

La procédure suivante suppose que le développeur AWS Glue a créé et chargé une archive ZIP de plan mise à jour sur Amazon S3.

**Pour mettre à jour un plan (console)**

1. Assurez-vous de disposer des autorisations de lecture (`s3:GetObject`) dans l'archive ZIP du modèle dans Amazon S3.

1. Ouvrez la console AWS Glue à l’adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

   Connectez-vous sous un profil utilisateur qui dispose des autorisations nécessaires pour mettre à jour un modèle. Basculez vers la même région AWS en tant que compartiment Amazon S3 contenant l'archive ZIP du modèle.

1. Dans le panneau de navigation, sélectionnez **Plans**.

1. Sur la page **plans**, sélectionnez un plan, puis dans le menu **Actions**, sélectionnez **Modifier**.

1. Dans la page **Edit a blueprint** (Modifier un modèle), mettez à jour la **Description** du modèle ou **ZIP archive location (S3)** (Emplacement de l'archive ZIP [S3]). Veillez à inclure le nom du fichier de l'archive dans le chemin.

1. Choisissez **Enregistrer**.

   La page **plans** affiche des résultats indiquant que le statut du plan est `UPDATING`. Cliquez sur le bouton d'actualisation jusqu'à ce que le statut devienne `ACTIVE` ou `FAILED`.

1. Si le statut est `FAILED`, sélectionnez le modèle et dans le menu **Actions**, sélectionnez **View** (Afficher).

   La page des détails indique la raison de l'échec. Si le message d'erreur est « Unable to access object at location... » (Impossible d'accéder à l'objet à l'emplacement...) ou « Access denied on object at location... » (Accès refusé sur l'objet à l'emplacement...), passez en revue les exigences suivantes :
   + L'utilisateur sous lequel vous êtes connecté doit disposer d'une autorisation de lecture sur l'archive ZIP du modèle dans Amazon S3.
   + Le compartiment Amazon S3 qui contient l'archive ZIP doit avoir une politique de compartiment qui accorde une autorisation de lecture sur l'objet à votre identifiant de AWS compte. Pour de plus amples informations, veuillez consulter [Publication d'un plan](developing-blueprints-publishing.md).
   + Le compartiment Amazon S3 que vous utilisez doit se trouver dans la même région que la région à laquelle vous êtes connecté sur la console.
**Note**  
Si la mise à jour échoue, la prochaine exécution de modèle utilise la dernière version du modèle qui a été enregistrée ou mise à jour avec succès.

**Pour mettre à jour un modèle (AWS CLI)**

1. Entrez la commande suivante.

   ```
   aws glue update-blueprint --name <blueprint-name> [--description <description>] --blueprint-location s3://<s3-path>/<archive-filename>
   ```

1. Pour vérifier l'état du modèle, saisissez la commande suivante. Répétez la commande jusqu'à ce que le statut devienne `ACTIVE` ou `FAILED`.

   ```
   aws glue get-blueprint --name <blueprint-name>
   ```

   Si le statut est `FAILED` et le message d'erreur est « Unable to access object at location... » (Impossible d'accéder à l'objet à l'emplacement...) ou « Access denied on object at location... » (Accès refusé sur l'objet à l'emplacement...), passez en revue les exigences suivantes :
   + L'utilisateur sous lequel vous êtes connecté doit disposer d'une autorisation de lecture sur l'archive ZIP du modèle dans Amazon S3.
   + Le compartiment Amazon S3 contenant l'archive ZIP doit avoir une politique de compartiment qui accorde une autorisation de lecture sur l'objet à votre identifiant de AWS compte. Pour de plus amples informations, veuillez consulter [Publication d'un plan](developing-blueprints-publishing.md).
   + Le compartiment Amazon S3 que vous utilisez doit se trouver dans la même région que la région à laquelle vous êtes connecté sur la console.

**Consultez aussi**  
[Présentation des plans dans AWS Glue](blueprints-overview.md)

# Création d'un flux de travail à partir d'un plan dans AWS Glue
<a name="creating_workflow_blueprint"></a>

Vous pouvez créer un flux de travail AWS Glue manuellement, en ajoutant un composant à la fois, ou vous pouvez créer un flux de travail à partir d'un [plan AWS Glue](blueprints-overview.md). AWS Glue comprend des plans pour les cas d'utilisation courants. Vos développeurs AWS Glue peuvent créer des plans supplémentaires.

**Important**  
Limitez le nombre total de tâches, de crawlers et de déclencheurs au sein d'un flux de travail à 100 ou moins. Si vous en incluez plus de 100, vous risquez de rencontrer des erreurs lorsque vous tentez de reprendre ou d'arrêter les exécutions du flux de travail.

Lorsque vous utilisez un modèle, vous pouvez générer rapidement un flux de travail pour un cas d'utilisation spécifique basé sur le cas d'utilisation généralisé défini par le modèle. Vous définissez le cas d'utilisation spécifique en fournissant des valeurs pour les paramètres de modèle. Par exemple, un modèle qui partitionne un jeu de données peut avoir les chemins source et cible Amazon S3 comme paramètres.

AWS Glue crée un flux de travail à partir d'un plan en *exécutant* celui-ci. L'exécution du modèle directeur enregistre les valeurs des paramètres que vous avez fournies et est utilisée pour suivre la progression et le résultat de la création du flux de travail et de ses composants. Lors du dépannage d'un flux de travail, vous pouvez afficher l'exécution du modèle pour déterminer les valeurs des paramètres de modèle qui ont été utilisées pour créer un flux de travail.

Pour créer et afficher des flux de travail, vous avez besoin de certaines autorisations IAM. Pour consulter un exemple de politique IAM, veuillez consulter [Autorisations d'analyste des données pour les plans](blueprints-personas-permissions.md#bp-persona-analyst).

Vous pouvez créer un flux de travail à partir d'un plan en utilisant la console AWS Glue, l'API AWS Glue ou AWS Command Line Interface (AWS CLI).

**Pour créer un flux de travail à partir d'un modèle (console)**

1. Ouvrez la console AWS Glue à l’adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

   Connectez-vous en tant qu'utilisateur disposant des autorisations pour créer un flux de travail.

1. Dans le panneau de navigation, sélectionnez **Plans**.

1. Sélectionnez un modèle, puis dans le menu **Actions**, sélectionnez **Create workflow** (Créer un flux de travail). 

1. Dans la page **Create a workflow from <blueprint-name>** (Créer un flux de travail à partir de <blueprint-name>), saisissez les informations suivantes :  
**Paramètres des modèles**  
Ceux-ci varient en fonction de la conception du modèle. Pour toute question concernant les paramètres, veuillez consulter le développeur. Les plans incluent généralement un paramètre pour le nom du flux de travail.  
**Rôle IAM**  
Le rôle que AWS Glue endosse pour créer le flux de travail et ses composants. Le rôle doit disposer des autorisations pour créer et supprimer des flux de travail, des tâches, des crawlers et des déclencheurs. Pour obtenir un exemple de politique pour le rôle, veuillez consulter [Autorisations des rôles de plans](blueprints-personas-permissions.md#blueprints-role-permissions).

1. Sélectionnez **Soumettre**.

   La page **Blueprint Details** (Détails du modèle) s'affiche et affiche une liste des exécutions de modèle en bas.

1. Dans la liste des exécutions de modèle, vérifiez l'exécution de modèle en tête de liste pour connaître l'état de création du flux de travail. 

   L'état initial est `RUNNING`. Cliquez sur le bouton d'actualisation jusqu'à ce que le statut devienne `SUCCEEDED` ou `FAILED`. 

1. Effectuez l'une des actions suivantes :
   + Si le statut d'achèvement est `SUCCEEDED`, vous pouvez accéder à la page **Workflows** (Flux de travail), puis sélectionnez le flux de travail qui vient d'être créé et exécutez-le. Avant d'exécuter le flux de travail, vous pouvez consulter le graphique de conception.
   + Si le statut d'achèvement est `FAILED`, sélectionnez l'exécution du modèle, puis dans la fenêtre **Actions**, sélectionnez **View** (Afficher) pour afficher le message d'erreur.

Pour en savoir plus sur les flux de travail et les plans, consultez les rubriques suivantes.
+ [Présentation des flux de travail dans AWS Glue](workflows_overview.md)
+ [Mise à jour d'un plan dans AWS Glue](updating_blueprints.md)
+ [Création et développement d'un flux de travail manuellement dans AWS Glue](creating_running_workflows.md)

# Affichage des exécutions du plan dans AWS Glue
<a name="viewing_blueprint_runs"></a>

Affichez une exécution de modèle pour afficher les informations suivantes :
+ Nom du flux de travail qui a été créé.
+ Valeurs de paramètre du plan utilisées pour créer le flux de travail.
+ Statut de l'opération de création du flux de travail.

Vous pouvez afficher une exécution de plan à l'aide de la console AWS Glue, de l'API AWS Glue, ou de l' AWS Command Line Interface (AWS CLI).

**Pour afficher une exécution de modèle (console)**

1. Ouvrez la console AWS Glue à l’adresse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

1. Dans le panneau de navigation, sélectionnez **Plans**.

1. Sur la page **plans**, sélectionnez un plan. Ensuite, dans le menu **Actions**, sélectionnez **View (Afficher)**.

1. Au bas de la page **Blueprint Details (Détails des modèles)**, sélectionnez une exécution de modèle, puis dans le menu **Actions**, sélectionnez **View (Afficher)**.

**Pour afficher une exécution de modèle (AWS CLI)**
+ Entrez la commande suivante. Remplacez *<blueprint-name>* par le nom du plan. Remplacez *<blueprint-run-id>* par l'ID d'exécution du plan.

  ```
  aws glue get-blueprint-run --blueprint-name <blueprint-name> --run-id <blueprint-run-id>
  ```

**Voir aussi :**  
[Présentation des plans dans AWS Glue](blueprints-overview.md)