Comment automatiquement analyser les données présentes dans les pièces jointes de vos e-mails ?

Dans l’environnement numérique actuel, l’e-mail conserve une place majeure pour l’échange de messages d’une personne ou d’une source vers un ou plusieurs destinataires. Parmi les plus de 300 milliards d’e-mails échangés chaque année dans le monde (rapport en anglais), 25% de ceux envoyés dans le cadre professionnel contiennent une pièce jointe. Avec un nombre moyen d’e-mail reçus chaque jour contenant une pièce jointe estimé à plus de 50 dans le monde professionnel, traiter de manière automatisée ces données est une nécessité pour toutes les entreprises désirant mettre en place une approche orientée données.

La facilité d’usage des pièces jointes pour transmettre des données s’accompagne d’une difficulté de traitement lorsque la quantité et la taille des données échangées dépasse la capacité de traitement des individus. En conséquence, des données peuvent fréquemment être perdues si les pièces jointes des e-mails ne sont pas automatiquement analysées et ingérées dans une solution de stockage organisé.

La coexistence de données importantes dans des pièces jointes d’e-mail avec des données stockées dans des solutions modernes (Data Lake, Data Warehouse) met également en exergue le retard des solutions de traitement automatisés des pièces jointes d’e-mails comparées aux données déjà ingérées par ces moyens plus récents.

Par exemple, imaginons le cas d’une analyste financière qui utilise régulièrement des données issues du Data Warehouse de son entreprise. Elle génère régulièrement des graphiques et des rapports chiffrés à partir de ces dernières. Lorsque cette analyste recevra des informations importantes par e-mail (au format CSV par exemple), elle n’aura pas la possibilité de facilement comparer, traiter, ajouter ces données aux précédentes. Il faudrait pour cela qu’elle possède les permissions et les compétences nécessaires pour ajouter et valider ces nouvelles données au Data Warehouse.

Dans cet article, nous proposons une architecture entièrement serverless qui permet d’ingérer automatiquement des données tabulaires (fichiers CSV, feuilles de calcul Excel) présentes dans des pièces jointes e-mails, de filtrer ces e-mails par origine, d’exécuter des tests de validation des données, de les stocker dans un Data Lake, et de rendre ces données disponibles pour de l’analyse SQL ou de la visualisation graphique.

Simplifiez la gestion des données par e-mail en tirant parti des services AWS, du serverless et de l’Infrastructure-as-Code

La solution que nous vous proposons ici utilise AWS CDK pour générer l’Infrastructure-as-Code. Les principaux services utilisés sont Amazon SNS (pour la réception des e-mails), Amazon S3 (pour le stockage et la gestion du cycle de vie des données) et AWS Lambda pour le traitement sans serveur.

Nous utilisons également Amazon SNS pour la notification en cas d’incident (observabilité) et AWS Glue Data Catalog pour le stockage des schémas des données.

Concernant l’ingestion des e-mails et de leurs pièces jointes, notre architecture utilise Amazon SES comme service de réception des e-mails. Amazon SES possède une fonctionnalité de règles de réception permettant de déclencher dans notre cas une fonction Lambda qui filtre les e-mails afin de n’accepter que des e-mails provenant d’une liste d’expéditeurs autorisés. Une fois accepté, les e-mails sont stockés dans Amazon S3, ce qui déclenche une seconde fonction Lambda de traitement, qui stocke à son tour l’e-mail et sa pièce jointe dans la destination idoine avec le schéma de données correspondant. Nous utilisons le projet Open Source Data Wrangler pour écrire les données tabulaires dans Amazon S3 ainsi que pour l’inférence des schémas, ce qui permet de créer les Amazon Glue Tables à la volée sans faire appel à des AWS Glue Crawlers.

La donnée finale est stockée dans le même bucket S3, dans deux préfixes différents :

• Curated (sélection) : les pièces jointes sont stockées après traitement et transformation au format Parquet pour analyse ultérieure,
• Quarantine (quarantaine) : ce préfixe contient les pièces jointes ainsi que l’e-mail correspondant lorsque les tests de validation dans la fonction Lambda de traitement. Chaque ajoût dans ce préfixe du bucket S3 déclenche un évènement de notification utilisant Amazon SNS afin d’avertir l’équipe en charge de cette architecture.

L’architecture que nous présentons ici tire parti de deux concepts relativement récents dans le monde du Cloud Computing et du DevOps : le serverless (“sans serveur”) et l’Infrastructure-as-Code (IaC, “infrastructure définie par du code”).

L’utilisation de technologies et services serverless (Amazon S3, Amazon SNS, Amazon SES, AWS Lambda) permet de se concentrer sur la logique métier de l’application, sans se soucier de devoir provisionner, mettre à jour, sécuriser, remplacer, toute l’infrastructure physique et logicielle sous-jacente.

L’Infrastructure-as-Code, de son côté, permet de faciliter l’application des meilleures pratiques en matière de DevOps : disparition des opérations manuelles de déploiement, gestion de version sous Git des ressources utilisées en parallèle de la gestion de version classique appliqué au code applicatif et déploiement facilité en cas de besoin sur une autre région AWS.

Architecture et fonctionnement

La figure 1 ci-dessous présente l’architecture serverless que nous avons développée afin de répondre au besoin d’analyse automatisée des pièces jointes contenant de la donnée tabulaire. Le paragraphe qui suit détaille de manière chronologique le traitement des pièces jointes d’e-mails de leur ingestion jusqu’à leur analyse.

Fig 1 – Architecture et principales étapes de traitement

1. Réception des e-mails avec Amazon SES
Avant de pouvoir utiliser correctement cette application, il est nécessaire de configurer Amazon SES avec une adresse e-mail que vous maîtrisez, et qui est validée par Amazon SES

2 & 3. Utilisation conjointe d’AWS Lambda et des règles de réception d’Amazon SES pour le filtrage de l’expéditeur

Une fois Amazon SES correctement configuré, chaque message arrivant sur l’adresse que vous avez choisie va déclencher l’activation conditionnelle de deux règles de réception (“Receipt rules”) faisant partie du même ensemble de règles.

Fig. 2 – Règles de réception appliquées à chaque nouvel e-mail entrant

La première règle est déclenchée à chaque nouvel e-mail et invoque la fonction Lambda de filtrage (“filtering”) qui va s’assurer que l’expéditeur est bien autorisé à envoyer des e-mails à l’adresse enregistrée dans SES. Le type d’invocation choisi est le type synchrone, qui permet de contrôler le flux d’e-mails. AWS SES ne poursuit pas vers l’action en deuxième position si la lambda en position 1 retourne une disposition de type STOP_RULE_SET. Plus d’information sur la gestion des SES rule set https://docs.thinkwithwp.com/ses/latest/DeveloperGuide/receiving-email-action-lambda.html

4. Stockage des pièces jointes issues d’expéditeurs autorisés dans Amazon S3

Si le retour de la fonction de filtrage est positif, la seconde règle de réception s’applique : l’e-mail et ses pièces jointes sont stockés dans un bucket S3 dédié. Le préfixe par défaut est tooling et peut être modifié dans le fichier cdk.json.

5. Traitement et stockage conditionnel des pièces jointes tabulaires avec AWS Lambda

L’ajout d’un nouvel e-mail issu d’un expéditeur autorisé dans le bucket S3 dédié déclenche automatiquement une exécution de la fonction lambda de traitement (“processing”).

6. Inférence de schémas avec AWS Data Wrangler

La fonction lambda de traitement effectue plusieurs étapes d’analyse et de formatage des données présentes dans les pièces jointes de l’e-mail reçu :

• le format de fichier de chaque pièce jointe est découvert (par défaut, l’application supporte le format .csv, .xls et .xlsx) afin de lister le nombre de colonnes présentes et leurs noms.
• Chaque table de données est convertie au format .csv
• Chaque pièce jointe est stocké dans le préfixe “Curated” (“sélectionné”) du bucket S3 au format Parquet
• Les métadonnées extraites de de chaque tableau sont ensuite stockées dans une table de la base de données AWS Glue créée par le déploiement CDK.

Cette fonction lambda utilise AWS Data Wrangler qui permet d’écrire les données dans S3 et de créer les catalogues de données correspondants dans AWS Glue sans faire appel à un Glue Crawler.

res = wr.s3.to_parquet(
            df=pandas_data_frame,
            path=f"s3://{self.parent_email.bucket_name}/"
                 f"{self.S3_PREFIX_CURATED}/"
                 f"{self.attachment_filename}",
            dataset=True,
            database=os.environ.get('GLUE_DATABASE_NAME'),
            table=self.attachment_filename,
            mode="append",
            description="Table created automatically from the email parser system",
            parameters=param
            # columns_comments=comments Add meta data on the columns if needed
        )

La fonction lambda de traitement créé automatiquement les catalogues de données dans la base de donnée AWS Glue.

Si les pièces jointes analysées ne font pas partie du type de pièces jointes autorisées (avec le mauvais format de fichier, ou bien contenant des données corrompues), elles sont stockées dans le bucket S3 avec le préfixe “quarantine” et leur ajout déclenche une notification SNS qui envoie simultanément un e-mail à l’équipe en charge de l’application, et un message à une queue SQS pour analyse asynchrone par un autre composant de l’application.

7. Visualisation des données avec Amazon Quicksight et analyse SQL avec Amazon Athena

Après traitement par la seconde fonction lambda, les données tabulaires sont prêtes à être analysées ou visualisées au moyen de Amazon Athena ou Amazon Quicksight.

Fig. 6 – Amazon Athena permet d’analyser les données avec des requêtes SQL sur la table. Dans cet exemple la table issue d’une pièce jointe contenant les données est data_csv et fait partie de la base de données database_email_integration créée par notre application

Fig. 7 – Amazon Quicksight permet de visualiser facilement les données issues de nombreuses sources, dont Amazon Athena. Dans cet exemple la table issue d’une pièce jointe contient plusieurs champs (Latitude, Longitude, …etc) qui peuvent être ajoutés à différents types de graphiques.

Déploiement

Pré-requis

Afin de déployer l’architecture décrite ci-dessus, vous aurez besoin des éléments suivants :
Un compte AWS possédant les permissions nécessaires pour déployer des stacks AWS CDK et créer les ressources nécessaires (voir la Figure 1 ci-dessus)

• AWS CLI, l’outil de ligne de commande AWS, configuré et authentifié à votre compte AWS
• AWS CDK (il est nécessaire de réaliser une opération de bootstrap avant le premier déploiement)
• Git
• Python 3.6+

Étapes de déploiement

Voici les étapes à suivre qui vous permettront de déployer cette architecture :

1. Clonez le présent dépôt Git dans un répertoire local de votre machine en utilisant la ligne de commande : $ git clone https://github.com/aws-samples/aws-cdk-ingest-email-spreadsheet
2. Placez-vous dans le répertoire créé à l’étape précédente : $ cd aws-cdk-ingest-email-spreadsheet/
3. Créez un environnement virtuel python : macOS/Linux: $ python3 -m venv .cdk-venv  ou Windows: $ python -m venv .cdk-venv
4. Activez l’environnement virtuel créé à l’étape précédente : macOS/Linux: $ source .cdk-venv/bin/activate ou Windows: $ .cdk-venv\Scripts\activate.bat
5. Installez les dépendances python requises par l’application : $ pip3 install -r requirements/stacks.txt
6. Synthétisez le template CloudFormation. AWS CDK utilise du code pour définir l’infrastructure de votre architecture. L’étape de synthèse permet de produire un template CloudFormation à partir du code CDK : $ cdk synthesize
7. Déployez la stack CDK complète : $ cdk deploy cdk-email-integration

Afin d’adapter l’application à votre cas d’usage, vous pouvez modifier le fichier cdk.json qui se trouve à la racine du dépôt Git. Ce fichier permet de modifier les adresses e-mail autorisées à envoyer des données, ainsi que d’autres configurations personnalisables.

Suppression des ressources

Afin d’éviter des coûts involontaires après utilisation, n’oubliez pas de supprimer les ressources créées par le déploiement lorsque vous n’aurez plus besoin de l’application.

Voici les étapes à suivre pour supprimer correctement l’ensemble des ressources :

• Désactivez la Règle de réception SES
• Supprimez l’ensemble de la stack CloudFormation avec la commande $ cdk destroy cdk-email-integration

Veuillez noter que le bucket S3 créé à l’occasion n’est pas supprimé lors de l’exécution de la commande précédente. Ce comportement est normal et attendu ; en effet il peut être utile de conserver les données générées après suppression de l’application elle-même.

Conclusion

Dans cet article nous avons présenté et détaillé une architecture 100% serverless pour l’ingestion, le traitement et le stockage des données tabulaires reçues dans des pièces jointes d’e-mails. Cette solution permet d’automatiser le traitement de vos pièces jointes et de faire le lien entre un moyen ancien et très répandu de transmettre des données (l’e-mail) et les méthodes modernes de traitement de la donnée.

La solution que nous présentons dans cet article peut aisément être modifiée pour mieux correspondre à vos besoins de traitement automatisé de la donnée : support d’autres extensions de fichiers répandues, ajout d’extensions propres à votre organisation, mise en relation des données des pièces jointes avec d’autres types de données de votre Data Lake.

A propos des auteurs

Amine Ait el harraj est un architecte de données de l’équipe AWS Professional Services. Il aide les clients et les partenaires à améliorer leur projet analytique dans le cloud avec des architectures flexibles et résilientes utilisant les services AWS. Dans son temps libre, Amine aime jouer à des jeux vidéo compétitifs.

Étienne Castanié est un consultant IoT (Internet of Things) de l’équipe AWS Professional Services. Il accompagne les clients et partenaires d’AWS à accélerer leur projets de connexion d’objets physiques au cloud et d’analyse des données collectées. Il conseille les clients d’AWS sur la bonne manière d’utiliser les services d’AWS afin d’obtenir des résultats mesurables et rapides.