Nettoyage des données d'entrée

Nettoyage des données d'entrée

Lorsque les données sont chargées dans le Connecteur de base, il est possible que l'ensemble de données contienne des cas et des événements incorrects ou non pertinents. Le Connecteur de base contient deux filtres qui peuvent être utilisés pour supprimer ces incidents et événements, le Cases filter et Events filter.

Voir illustration ci-dessous.

Filtre de cas

Le filtre Incidents s'applique à tous les incidents de la table Cases_input et est souvent utilisé pour supprimer des incidents en double ou pour omettre certains types d'incidents. Dans l'exemple ci-dessous, les cas avec un montant négatif sont filtrés. Le panneau des résultats montre que 15 incidents seront filtrés en fonction de cette définition.

Filtre d'événements

Le filtre Événements s'applique à tous les événements de la table Events_input et est souvent utilisé pour omettre certaines activités ou pour filtrer les événements antérieurs à une date spécifique. Le filtre Événements fait toujours référence au filtre Incidents pour supprimer les événements pour lesquels l'incident a été filtré dans le filtre Incidents. Dans l'exemple ci-dessous, les événements survenus avant le 01/01/2016 sont supprimés. Le panneau des résultats montre que cela entraîne la suppression de 72 191 événements.

Application du filtre

Par défaut, Cases filter et Events filter sont appliqués dans la jointure des tables Cases_preprocessing et Events_preprocessing . Pour cette raison, il suffit de ne modifier que les filtres eux-mêmes. Ce paramètre garantit que les tables de prétraitement ne contiennent que des données conformes à la définition du filtre.

Double-cliquez sur la table Cases_preprocessing ou Events_preprocessing pour inspecter la façon dont le filtre est appliqué.

Cases_preprocessing

La jointure de la table Cases_preprocessing applique le filtre Cas dans sa condition où. Par conséquent, la table contient toutes les données contenues dans la table Cases_input , à l'exception des enregistrements filtrés par le filtre Incidents. L'exemple ci-dessous montre que 15 enregistrements sont exclus, ce qui correspond aux 15 valeurs fausses dans le filtre Incidents lui-même.

Events_preprocessing

Le filtre Événements s'applique à tous les événements de la table Events_input et est souvent utilisé pour omettre certaines activités ou pour filtrer les événements antérieurs à une date spécifique. Le filtre Événements fait toujours référence au filtre Incidents pour supprimer les événements pour lesquels l'incident a été filtré dans le filtre Incidents. Dans l'exemple ci-dessous, les événements survenus avant le 01/01/2016 ont été supprimés. Le panneau des résultats montre que cela entraîne la suppression de 72 191 événements.

Remplacement des attributs

Au lieu d’avoir des attributs dans votre ensemble de données qui n’existent pas dans le Connecteur de base, il est également possible qu’il existe des champs définis dans AppOne qui ne correspondent pas directement à l’un des champs de votre fichier de données d’entrée. Dans ce cas, vous devez créer une expression pour ce champ dans le Connecteur de base.

Dans certains cas, vous souhaiterez peut-être ne pas supprimer l’intégralité de l’enregistrement, mais simplement corriger les valeurs de l’attribut incorrect.

Pour corriger un tel attribut dans UiPath Process Mining, il est d'abord nécessaire de créer une expression qui calcule les valeurs correctes, puis de remplacer l'attribut incorrect par la nouvelle expression.

Correction de la valeur de l'attribut

Pour corriger l'attribut, créez une nouvelle expression qui calcule les valeurs correctes. Créez cette expression dans la même table d'où provient l'attribut incorrect.

Par exemple, l'attribut Case ID est disponible dans les tables Cases_preprocessing et Cases_base , mais il provient de Cases_input . Par conséquent, la nouvelle expression pour la corriger doit également être calculée dans Cases_input .

Remarque :

Il est recommandé de donner à la nouvelle expression le même nom que l'attribut d'origine.

Voir l'illustration ci-dessous pour un exemple sur la façon de supprimer le préfixe CORS du Case ID dans la table Cases_input .

Remplacement de l'attribut

Les attributs des tables du connecteur de base sont utilisés dans différentes expressions dans l'ensemble du connecteur. Par conséquent, il n'est pas possible de supprimer simplement l'attribut incorrect, mais il doit être remplacé par la nouvelle expression. Les étapes ci-dessous expliquent comment remplacer un attribut.

Remarque :

Il est important de suivre ces étapes dans la table d’où proviennent l’attribut incorrect et la nouvelle expression.

Étape 1 : définir la disponibilité de la nouvelle expression

Pour remplacer un attribut, la disponibilité des deux attributs doit être la même. Les deux attributs d'ID de cas dans la figure ci-dessous ont des disponibilités différentes.

Cliquez avec le bouton droit sur la deuxième expression d'ID d'incident et sélectionnez Disponibilité - Public dans le menu contextuel pour passer la disponibilité sur Publique.

Étape 2 : échanger les UID

Pour remplacer l'attribut incorrect à tous les emplacements où il est utilisé dans le connecteur par la nouvelle expression, les UID des deux attributs doivent être interchangés. En échangeant les UID, le logiciel remplace toutes les références à l'attribut d'origine par des références à la nouvelle expression, et vice versa. Pour échanger des UID, sélectionnez les deux attributs, cliquez avec le bouton droit de la souris et sélectionnez Avancé - Intervertir les UID dans le menu contextuel. Voir l'illustration ci-dessous.

Remarque :

• L'UID est un ID de logiciel interne et non l'ID affiché dans l'éditeur d'expression. Après avoir permuté les UID, le nom et l'ID de l'attribut ou de l'expression n'auront pas changé.
• Si l'échange des UID n'est pas effectué dans la table d'où proviennent l'attribut d'origine et la nouvelle expression, un avertissement s'affiche et l'échange n'est pas exécuté dans la table d'origine. Vous pouvez annuler les modifications en utilisant CTRL + Z et remplacer l'attribut dans la bonne table.

Étape 3 : Vérifier les références

Pour vérifier si l'échange a réussi, vérifiez les références de chacun des attributs. Toutes les références qui pointaient vers l'attribut d'origine doivent maintenant pointer vers la nouvelle expression (voir l'exemple ci-dessous). L'attribut incorrect ne doit être référencé que par notre nouvelle expression elle-même. Pour vérifier les références, sélectionnez un attribut, cliquez avec le bouton droit de la souris et sélectionnez Avancé - Afficher les références dans le menu contextuel.

Fantômes

Un fantôme est un attribut devenu indisponible même s'il est toujours utilisé dans le connecteur. Un avertissement s'affiche lorsqu'un fantôme est créé. Un fantôme est indiqué par l'icône. Ne supprimez jamais un fantôme qui a encore des références pointant vers lui. Annulez les modifications à l'aide de CTRL+Z jusqu'à ce que le fantôme soit remplacé par l'attribut réel. Évaluez les étapes qui ont mal tourné lors du remplacement de l’attribut et répétez l’opération si nécessaire.

Étape 4 : Définir la disponibilité de l'attribut d'origine

Si l'échange a réussi et que les références renvoient aux attributs corrects, il est recommandé de définir la disponibilité de l'attribut d'origine sur Privé. De cette façon, il ne peut pas être utilisé dans d'autres tables telles que les tables Preprocessing et Base . Voir l'illustration ci-dessous pour les deux attributs d'ID d'incident après l'échange et l'attribut d'origine défini sur privé.