- Notes de publication
- Démarrage
- Installation
- Prérequis logiciels et matériels
- Installation du serveur
- Mise à jour de la licence
- Déploiement du profileur d'UiPath Process Mining
- Déploiement d’un connecteur(.mvp)
- Mise à jour d'UiPath Process Mining
- Mettre à jour une version personnalisée d'une application ou d'un accélérateur de découverte
- Installation d'un environnement de formation
- Configuration
- Intégrations
- Authentification
- Working with Apps and Discovery Accelerators
- Menus et tableaux de bord AppOne
- Configuration d'AppOne
- TemplateOne 1.0.0 menus et tableaux de bord
- Configuration de TemplateOne 1.0.0
- Menus et tableaux de bord de TemplateOne
- Configuration de TemplateOne 2021.4.0
- Menus et tableaux de bord de l’accélérateur de découverte Purchase to Pay
- Configuration de Discovery Accelerator de l’achat au paiement
- Menus et tableaux de bord de l’accélérateur de découverte Order-to-Cash
- Configuration de Order to Cash Discovery Accelerator
- Basic Connector for AppOne
- Déploiement du connecteur de base
- Présentation du connecteur de base
- Tables d'entrée du connecteur de base
- Ajout de balises
- Ajout d’estimations d’automatisation
- Ajout de dates d'échéance
- Ajout de modèles de référence
- Configuration d'Actionable Insights
- Réglage des graphiques réductibles
- Utilisation de l’ensemble de données de sortie dans AppOne
- Output tables of the Basic Connector
- Déploiement du connecteur de base
- SAP Connectors
- Introduction to SAP Connector
- Entrée SAP
- Vérification des données dans le connecteur SAP
- Ajout de balises spécifiques à un processus au connecteur SAP pour AppOne
- Ajout de dates d'échéance spécifiques aux processus au connecteur SAP pour AppOne
- Ajout d’estimations d’automatisation au connecteur SAP pour AppOne
- Ajout d'attributs au connecteur SAP pour AppOne
- Ajout d’activités au connecteur SAP pour AppOne
- Ajout d’entités au connecteur SAP pour AppOne
- Connecteur SAP Order to Cash pour AppOne
- Connecteur SAP Purchase to Pay pour AppOne
- Connecteur SAP pour Purchase to Pay Discovery Accelerator
- Connecteur SAP pour l’accélérateur de découverte Order-to-Cash
- Superadmin
- L'onglet Espaces de travail (Workspaces)
- L'onglet Données de développement (Development Data)
- L'onglet Versions (Releases)
- L'onglet Données publiées (Released data)
- The Builds tab
- L'onglet Données du serveur (Server data)
- Onglet Paramètres (Settings)
- L'onglet Utilisateurs Superadmin
- L'onglet Statut (Status)
- Onglet Licence (License)
- Création de versions
- Afficher l'historique de la branche
- Creating Apps
- Modules
- Tableaux de bord et graphiques
- Tables et éléments de table
- Intégrité de l'application
- How to ....
- Travailler avec les connecteurs SQL
- Introduction to SQL connectors
- Setting up a SQL connector
- CData Sync extractions
- Running a SQL connector
- Editing transformations
- Libération d'un connecteur SQL
- Scheduling data extraction
- Structure of transformations
- Using SQL connectors for released apps
- Generating a cache with scripts
- Setting up a local test environment
- Separate development and production environments
- Ressources utiles
Data Loading
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.
- ODBC : cela dépend également du pilote et de la base de données.
- Fichiers plats :
csv’s. - 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.
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).
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.
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.
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.
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.
Assurez-vous toujours que vous avez installé les dernières versions des pilotes ODBC MSSQL pour Windows Server 2016.
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.
