- 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
- TemplateOne menus and dashboards
- 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<br />
- 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
- 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
Process Mining
Utilisez la partitionnement dans vos applications
Sharding est une solution innovante pour améliorer les performances de vos applications de Process Mining. En bref, le sharding divise les données de votre journal des événements en parties plus petites appelées « fragments ». Plus chaque partition est petite, plus elle sera rapide.
Avec une partition, les utilisateurs finaux ne prennent en compte que la partie applicable des données qui les intéressent. Lorsqu'un utilisateur se connecte à l'application, seule la partition de données applicable est chargée.
Les fragments peuvent être divisés en deux types différents :
- Partitions standard, qui contiennent des parties de vos données au niveau détaillé.
- Partitions de référence (Benchmark shards) , qui contiennent une vue agrégée de haut niveau de toutes vos données.
Il existe plusieurs techniques pour créer des partitions normales ainsi que des partitions de référence. Des partitions standard peuvent être créées en divisant vos données en fonction des attributs de cas. Les partitions de référence combinent les données de toutes les partitions. En règle générale, le niveau de détail des données est réduit à l'aide de la pré-agrégation, du filtrage ou de l'échantillonnage.
Un exemple d'attribut de partitionnement pourrait être Code de l'entreprise, où chaque partition contient tous les cas appartenant à un seul code d'entreprise. Si vous deviez avoir 10 sociétés dans votre ensemble de données, chaque partition sera alors environ 10 fois plus rapide que l'originale (en supposant des fractionnements égaux).
Voir illustration ci-dessous.
En plus de diviser vos données en partitions distinctes, il est utile d'avoir une partition de vue d'ensemble contenant une vue de niveau supérieur de toutes les données, une « partition de référence ».
Vous pouvez configurer cela de plusieurs manières :
- En pré-agrégeant des valeurs ou des attributs : cela vous empêche de faire une analyse détaillée, mais vous permet toujours de comparer les différences entre les partitions.
- En abaissant le niveau de détail en filtrant les événements à granularité fine : cela vous permet de comparer les processus à un niveau grossier.
- Par filtrage : vous pouvez supprimer toutes les données d'événement et ne conserver que les balises et les cas respectifs. Vous pouvez ainsi comparer les balises sur plusieurs partitions.
- Par échantillonnage : vous pouvez échantillonner des observations dans votre ensemble de données pour n'en conserver qu'une partie, en conservant un échantillon représentatif d'observations comme ensemble de données de référence.
Vous pouvez également configurer plusieurs partitions de référence à l'aide de différentes méthodes.
Vous pouvez utiliser un seul connecteur pour votre ETL, même lorsque vous utilisez le sharding. Pour ce faire, configurez des modules d'application, en utilisant un module par partition que vous souhaitez créer.
Dans votre connecteur, ajoutez une table système avec une étendue de table définie sur « current user » pour obtenir ActiveApplicationCode, qui indique le module actuellement actif. Vous pouvez utiliser cet attribut de la table système pour créer des conditions pour le chargement de vos données.
Exemple
Lors de l'application de la partitionnement à l'aide de types de cas, configurez une expression Type_Case_Shard en fonction de l'attribut ActiveApplicationCode , pour déterminer quel type de cas appartient à quel code d'application. Ensuite, dans la table case_base , vous définissez la condition de jointure sur :
Cases_preprocessing where Case_type_Shard = Case_type
Cela garantit que seuls les cas qui ont un type de cas appartenant à la partition actuelle sont transmis dans votre sortie finale.
events_preprocessing
, créez une expression de recherche vers la table cases_base
qui vérifie si les incidents se trouvent dans la partition sélectionnée.
Voir illustration ci-dessous.
Utilisez cet attribut d'expression dans la condition de jointure de la table events_base avec l'expression :
Events_preprocessing where Case_in_shard
.
Pour configurer votre application pour le sharding, vous avez également besoin d'un module par partition. Ces modules doivent avoir les mêmes codes de module que ceux de votre connecteur.
En outre, selon le type de partition de référence que vous utilisez, la structure des données peut être différente pour les partitions standard et la partition de référence. Si tel est le cas, vous avez besoin d'une application distincte pour la partition de référence.
Étant donné que vous utilisez plusieurs modules, vous devez recharger les données à l'aide d'un script pour vous assurer que les données de tous les modules de connecteur se retrouvent dans le même ensemble de données. De cette façon, l'application sait, en fonction du module ouvert, quelle partie des données doit être prise en compte. Voir Configurer l'actualisation automatisée des données pour le script de rechargement de vos données.