Data Loading

Introduction

Chargement des données dans le connecteur

Le chargement des données fait référence au temps requis pour charger de nouvelles données dans le Connecteur. Ceci est déterminé par le nombre de colonnes lors de la lecture à partir de la base de données.

Certains types de données sont plus rapides à charger que d’autres. Au sens large, l'ordre est le suivant.

1. ODBC : cela dépend également du pilote et de la base de données.
2. Fichiers plats : csv’s .
3. Excel : ces fichiers contiennent une surcharge pour l'utilisation dans Excel, ce qui les rend plus lents à lire. Si possible, utilisez des fichiers texte au lieu de fichiers Excel. Les fichiers texte sont beaucoup plus rapides.

Le script multifichier est assez lent pour analyser tous les différents fichiers plats ensemble et doit être évité si possible. Évitez également les API pour charger des quantités massives de données.

 

Chargement des données dans l'application

Les données peuvent être chargées des manières suivantes :

• au démarrage de l'application (données actives) ;
• à la suite d'une exécution de données planifiée (données mises en cache) ;
• une combinaison de données actives et mises en cache (charge incrémentielle).

Données en direct

En général, les données en direct sont beaucoup plus lentes, surtout s'il y a beaucoup de données. Les données en direct nécessitent également un accès continu aux données, ce qui peut être un problème pendant les heures de production.

En règle générale, il est recommandé de conserver les données en direct en dessous de 100 000 événements. Les performances réelles dépendent fortement des données et des sources de données utilisées.

Il est possible de récupérer des données en direct en fonction de la valeur d'un filtre. Si le filtre est modifié, les nouvelles données sont demandées. Les performances doivent être sérieusement prises en compte pour ce type de cas d’utilisation.

Les tables dynamiques sont chargées lorsque l'utilisateur se connecte et/ou modifie une commande de filtre. Les tables dynamiques entraînent souvent des problèmes de performances. Il est recommandé d'utiliser des tables mises en cache dans la mesure du possible.

Données mises en cache

Pour les données mises en cache, l'heure de démarrage de l'application est indépendante du nombre de colonnes. Lorsque les données sont précalculées et mises en cache, elles peuvent être chargées directement à partir du cache lorsque cela est demandé. L'extraction des données des systèmes sources peut prendre beaucoup de temps. Il est recommandé de planifier les mises à jour du cache, par exemple en dehors des heures de production.

Outre l'extraction des données, les données sont également transformées au format interne UiPath Process Mining et tous les calculs qui ne dépendent pas de l'entrée de l'utilisateur sont mis en cache.

Pour les calculs qui dépendent de l'entrée de l'utilisateur, l'état initial est mis en cache. Lorsque l'utilisateur modifie une commande ou un filtre qui modifie le calcul, le calcul est effectué à nouveau. Pour une bonne conception de l'application, il est très important de réduire au minimum ces recalculs.

Charge incrémentielle

Par défaut, UiPath Process Mining ne charge pas les données de manière incrémentielle. Étant donné que des mutations ont souvent lieu sur les éléments des systèmes ERP, l'archivage des données n'est souvent pas une approche souhaitée. Par conséquent, toutes les données sont chargées à partir du système pour garantir que nous avons les dernières modifications de notre modèle de données.

Le chargement incrémentiel des données peut théoriquement être configuré par les développeurs d'applications. Cela nécessite suffisamment d'informations dans la base de données pour déterminer quelles données sont nouvelles et quelles données doivent faire l'objet de requêtes. Les performances doivent être examinées attentivement. Nous vous recommandons d’utiliser le chargement de données incrémentiel uniquement lorsque cela est absolument nécessaire.

Une alternative plus appropriée consiste à exécuter des charges incrémentielles du système source vers un lac de données/un entrepôt de données à l'aide d'outils spécialisés, puis à interroger le lac de données/l'entrepôt de données depuis UiPath Process Mining. Cela garantit un faible impact sur le système source et partage les gains des charges incrémentielles avec l'ensemble de l'organisation, plutôt que spécialement pour UiPath Process Mining.

Scripts externes

Dans UiPath Process Mining, vous pouvez charger des données via des scripts en utilisant ou par exemple Python ou R. Ces scripts appelleront un programme externe à exécuter et cette sortie pourra être lue à nouveau. UiPath Process Mining prend en charge l'interface entre notre plate-forme et le script. UiPath Process Mining ne prend pas en charge les problèmes avec le script réel qui peuvent entraîner un long temps d’exécution de l’outil externe.

 

Solutions

Pilotes

Assurez-vous toujours que vous avez installé les dernières versions des pilotes ODBC MSSQL pour Windows Server 2016.

Module de débogage

Parfois, il n'est pas possible de réduire les données à lire, par exemple. lorsque les données d'entrée ne peuvent pas encore être filtrées. Avec une grande entrée dans votre Connector, les temps de réaction peuvent être lents. Afin d'accélérer le développement, vous pouvez ajouter des modules à votre application.

Vous pouvez utiliser le code du module pour vous assurer que les données sont réellement lues dans un seul module, tandis que l'autre module ne charge pas de données et peut être utilisé pour apporter des modifications à votre modèle de données. De cette façon, les modifications sont affectées sans avoir à attendre que les données soient initialisées.