Editing transformations

Projets dbt

Les transformations de données sont utilisées pour transformer les données d'entrée en données adaptées à Process Mining. Les transformations dans Process Mining sont écrites en tant que projets dbt .

Cette page donne une introduction à dbt. Pour plus d'informations, consultez la documentation officielle de dbt.

pm-utils package

Les modèles d'application Process Mining sont fournis avec un package dbt appelé pm_utils. Ce package pm-utils contient des fonctions utilitaires et des macros pour les projets dbt Process Mining. Pour plus d'informations sur les pm_utils , consultez ProcessMining-pm-utils.

Mise à jour de la version pm-utils utilisée pour votre modèle d'application

UiPath® améliore constamment le package pm-utils en ajoutant de nouvelles fonctions.

Lorsqu'une nouvelle version du paquet pm-utils est publiée, il est conseillé de mettre à jour la version utilisée dans vos transformations, pour vous assurer que vous utilisez les dernières fonctions et macros du paquet pm-utils .

Vous trouverez le numéro de version de la dernière version du package pm-utils dans le panneau Versions ( Releases ) du ProcessMining-pm-utils.

Suivez ces étapes pour mettre à jour la version pm-utils dans vos transformations.

1. Téléchargez le code source (zip) à partir de la version pm-utils.
2. Extrayez le fichier zip et renommez le dossier en pm_utils.

3. Exportez les transformations à partir de l'éditeur de transformations de données intégré et extrayez les fichiers.

4. Remplacez le dossier pm_utils des transformations exportées par le nouveau dossier pm_utils .

5. Compressez à nouveau le contenu des transformations et importez-les dans l' éditeur de transformations de données .

Folder structure

Les transformations d'une application de processus consistent en un projet dbt . Vous trouverez ci-dessous une description du contenu d'un dossier de projet dbt .

Dossier/Fichier	Contient
dbt_packages\	le package pm_utils et ses macros.
logs\	journaux créés lors de l’exécution de dbt.
macros\	macros personnalisées.
models\	.sql qui définissent les transformations.
models\schema\	.yml qui définissent les tests sur les données.
seed	.csv avec les paramètres de configuration.
dbt_project.yml	les paramètres du projet dbt.

Voir illustration ci-dessous.

Transformations de données

Les transformations de données sont définies dans des fichiers .sql dans le répertoire models\ . Les transformations de données sont organisées dans un ensemble standard de sous-répertoires :

• 1_input,
• 2_entities,
• 3_events,
• 4_event_logs,
• 5_business_logic.

Voir Structure des transformations.

Les fichiers .sql sont écrits en Jinja SQL, ce qui vous permet d'insérer des instructions Jinja dans des requêtes SQL simples. Lorsque dbt exécute tous les .sql fichiers, chaque fichier .sql génère une nouvelle vue ou une nouvelle table dans la base de données.

En règle générale, les fichiers .sql ont la structure suivante :

1. Instruction With: une ou plusieurs instructions with pour inclure les sous-tables requises.

   • {{ ref(‘My_table) }} fait référence à une table définie par un autre fichier .sql fichier.
   • {{ source(var("schema_sources"), 'My_table') }} fait référence à une table d'entrée.
2. Requête principale: la requête qui définit la nouvelle table.
3. Requête finale: une requête telle que Select * from table est généralement utilisée à la fin. Cela facilite la réalisation de sous-sélections lors du débogage.

   

Pour plus de conseils sur l'écriture efficace des transformations, consultez Conseils pour l'écriture de SQL

Adding source tables

Pour ajouter une nouvelle table source au projet dbt , elle doit être répertoriée dans models\schema\sources.yml . De cette façon, d'autres modèles peuvent s'y référer en utilisant {{ source(var("schema_sources"), 'My_table_raw') }} . Voir l’illustration ci-dessous pour un exemple.

Important : chaque nouvelle table source doit être répertoriée dans sources.yml .

Remarque :

Le suffixe _raw est ajouté aux noms de table des tables source lors du chargement des données. Par exemple, une table appelée ma_table doit être appelée ma_table_raw.

Pour plus d'informations, consultez la documentation officielle de dbt sur Sources.

Data output

Les transformations de données doivent générer le modèle de données requis par l'application correspondante ; chaque table et chaque champ attendus doivent être présents.

En pratique, cela signifie que les tables du models\5_business_logic ne doivent pas être supprimées. De plus, les champs de sortie des requêtes correspondantes ne doivent pas être supprimés.

Si vous souhaitez ajouter de nouveaux champs à votre application de processus, vous pouvez utiliser les champs personnalisés disponibles pour l'application de processus. Mappez les champs des transformations aux champs personnalisés pour les rendre disponibles dans la sortie. Assurez-vous que les champs personnalisés sont nommés dans la sortie comme décrit dans le modèle de données de l'application de processus.

Astuce :

Vous pouvez utiliser les commandes dbt docs pour générer un site de documentation pour votre projet dbt et l'ouvrir dans votre navigateur par défaut. Le site de documentation contient également un graphique de lignage qui fournit un diagramme entité-relation avec une représentation graphique du lien entre chaque table de données de votre projet.

Pour des informations détaillées, consultez la documentation officielle de dbt sur dbt docs.

Macros

Les macros facilitent la réutilisation des constructions SQL courantes. Pour plus d'informations, consultez la documentation officielle de dbt sur les macros Jinja.

pm_utils

Le paquet pm-utils contient un ensemble de macros qui sont généralement utilisées dans les transformations Process Mining. Pour plus d'informations sur les macros pm_utils , consultez ProcessMining-pm-utils.

Vous trouverez ci-dessous un exemple de code Jinja appelant la macro pm_utils.optional() .

Graines

Les valeurs sont des fichiers csv utilisés pour ajouter des tables de données à vos transformations. Pour des informations détaillées, consultez la documentation officielle de dbt sur les labels jinja.

Dans Process Mining, cela est généralement utilisé pour faciliter la configuration des mappages dans vos transformations.

Après la modification des fichiers de départ, ces fichiers ne sont pas automatiquement mis à jour immédiatement dans la base de données. Pour indiquer à dbt de charger le nouveau contenu du fichier d'origine dans la base de données, exécutez soit

• dbt seed - qui ne mettra à jour que les tables des fichiers d'origine, ou
• dbt build - qui exécutera également tous les modèles et tests.
  Remarque : si le fichier d'origine ne contenait aucun enregistrement de données au départ, les types de données dans la base de données n'avaient peut-être pas été définis correctement. Pour résoudre ce problème, appelez run dbt seed --full-refresh . Cela mettra également à jour l'ensemble de colonnes dans la base de données.

Activity configuration

Le fichier activity_configuration.csv est utilisé pour définir des champs supplémentaires liés aux activités. activity_order est utilisé comme condition de départage lorsque deux événements se produisent avec le même horodatage. Voir l’illustration ci-dessous pour un exemple.

Tests

Le dossier models\schema\ contient un ensemble de fichiers .yml qui définissent les tests. Ceux-ci valident la structure et le contenu des données attendues. Pour plus d'informations, consultez la documentation officielle de dbt sur les tests.

Lorsque les transformations sont exécutées dans Process Mining, seuls les tests dans sources.yml sont exécutés à chaque ingestion de données. Cela permet de vérifier si les données d'entrée sont correctement formatées.

Remarque : lorsque vous modifiez des transformations, veillez à mettre à jour les tests en conséquence. Les tests peuvent être supprimés si vous le souhaitez.