- Versionshinweise
- Erste Schritte
- Installation
- Hard- und Softwareanforderungen
- Serverinstallation
- Aktualisierung der Lizenz
- Bereitstellen des UiPath Process Mining-Profilers
- Bereitstellen eines Connectors (.mvp)
- Aktualisieren von UiPath Process Mining
- Aktualisieren einer benutzerdefinierten Version einer App oder eines Discovery Accelerators
- Installieren einer Trainingsumgebung
- Konfiguration
- Integrationen
- Authentication
- Working with Apps and Discovery Accelerators
- AppOne-Menüs und -Dashboards
- AppOne-Einrichtung
- Menüs und Dashboards von TemplateOne 1.0.0
- Setup von TemplateOne 1.0.0
- TemplateOne menus and dashboards
- Setup von TemplateOne 2021.4.0
- Purchase-to-Pay Discovery Accelerator-Menüs und -Dashboards
- Einrichtung des Purchase-to-Pay-Discovery-Beschleunigers
- Menüs und Dashboards des Order-to-Cash Discovery Accelerators
- Einrichtung des Order-to-Cash Discovery-Beschleunigers
- Basic Connector for AppOne
- Bereitstellen des einfachen Connectors
- Einführung zu Basic Connector
- Eingabetabellen des Basic Connectors
- Hinzufügen von Tags
- Hinzufügen von Automatisierungsschätzungen
- Hinzufügen von Fälligkeitsdaten
- Hinzufügen von Referenzmodellen
- Einrichten von praktisch umsetzbaren Erkenntnissen
- Festlegen von reduzierbaren Diagrammen
- Verwenden des Ausgabe-Datasets in AppOne
- Output tables of the Basic Connector
- SAP Connectors
- Introduction to SAP Connector
- SAP-Eingabe
- Überprüfen der Daten im SAP Connector
- Hinzufügen von prozessspezifischen Tags zum SAP Connector für AppOne
- Hinzufügen von prozessspezifischen Fälligkeitsdaten zum SAP Connector für AppOne
- Hinzufügen von Automatisierungsschätzungen zum SAP Connector für AppOne
- Hinzufügen von Attributen zum SAP Connector für AppOne
- Hinzufügen von Aktivitäten zum SAP Connector für AppOne
- Hinzufügen von Entitäten zum SAP Connector für AppOne
- SAP Order to Cash Connector für AppOne
- SAP Purchase to Pay Connector für AppOne
- SAP Connector for Purchase to Pay Discovery Accelerator
- SAP Connector für den Order-to-Cash Discovery Accelerator
- Superadmin
- Die Registerkarte Arbeitsbereiche
- Die Registerkarte Entwicklungsdaten
- Die Registerkarte Versionen
- Die Registerkarte Freigegebene Daten
- The Builds tab
- Die Registerkarte Serverdaten
- Die Registerkarte Einstellungen (Settings)
- Die Registerkarte Superadmin-Benutzer
- Die Registerkarte Status
- Die Registerkarte Lizenz
- Erstellen von Releases
- Anzeigen des Verlaufs der Verzweigung
- Creating Apps
- Modules
- Dashboards und Diagramme
- Tabellen und Tabellenelemente
- Anwendungsintegrität
- How to ....
- Arbeiten mit SQL-Connectors
- Introduction to SQL connectors
- Setting up a SQL connector
- CData Sync extractions
- Running a SQL connector
- Editing transformations
- Freigeben eines SQL-Connectors
- 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
- Nützliche Ressourcen
Process Mining
Verwenden Sie Sharding in Ihren Anwendungen
Sharding ist eine innovative Lösung zur Verbesserung der Leistung Ihrer Process Mining-Anwendungen. Kurz gesagt, Sharding unterteilt die Daten in Ihrem Ereignisprotokoll in kleinere Teile, die als „Shards“ bezeichnet werden. Je kleiner jeder Shard ist, desto schneller ist er.
Bei einem Shard berücksichtigen Endbenutzer nur den entsprechenden Teil der Daten, an dem sie interessiert sind. Wenn sich ein Benutzer bei der Anwendung anmeldet, wird nur der entsprechende Daten-Shard geladen.
Shards können in zwei verschiedene Typen unterteilt werden:
- Reguläre Shards, die Teile Ihrer Daten auf Detailebene enthalten.
- Benchmark-Shards, die eine aggregierte, allgemeine Ansicht aller Ihrer Daten enthalten.
Es gibt mehrere Techniken zum Erstellen von regulären Shards sowie für Benchmark-Shards. Regelmäßige Shards können erstellt werden, indem Sie Ihre Daten basierend auf Fallattributen aufteilen. Benchmark-Shards kombinieren die Daten aller Shards. In der Regel wird die Detailebene der Daten durch Voraggregation, Filterung oder Stichprobenziehung reduziert.
Ein Beispielattribut für das Sharding könnte „Unternehmenscode“ sein, wobei jeder Shard alle Fälle enthält, die zu einem einzelnen Buchungskreis gehören. Wenn Sie 10 Buchungskreise in Ihrem Dataset haben, ist jeder Shard ungefähr 10-mal schneller als das Original (unter der Annahme gleicher Aufteilungen).
Siehe Abbildung unten.
Neben der Aufteilung Ihrer Daten in separate Shards ist es nützlich, einen Übersichts-Shard zu haben, der eine übergeordnete Ansicht aller Daten enthält, einen „Benchmark-Shard“.
Sie können dies auf verschiedene Arten einrichten:
- Durch Voraggregieren von Werten oder Attributen: Dadurch können Sie keine detaillierte Analyse durchführen, können aber dennoch Unterschiede über Shards vergleichen.
- Durch Verringern der Detailebene durch Herausfiltern feinkörniger Ereignisse: Dies ermöglicht es Ihnen, Prozesse auf einer groben Ebene zu vergleichen.
- Durch Filtern: Sie können alle Ereignisdaten entfernen und nur Tags und die jeweiligen Fälle behalten. Auf diese Weise können Sie Tags über mehrere Shards hinweg vergleichen.
- Durch Stichproben: Sie können Stichproben von Fällen in Ihrem Dataset erstellen, um nur einen Teil der Fälle zu behalten und eine repräsentative Stichprobe von Fällen als Benchmark-Dataset zu behalten.
Sie können auch mehrere Benchmark-Shards mit verschiedenen Methoden einrichten.
Sie können einen einzelnen Connector für Ihre ETL verwenden, auch wenn Sie Sharding verwenden. Dazu richten Sie Anwendungsmodule ein und verwenden ein Modul pro Shard, das Sie erstellen möchten.
Fügen Sie in Ihrem Connector eine Systemtabelle hinzu, deren Tabellenbereich auf „aktueller Benutzer“ festgelegt ist, um den ActiveApplicationCode abzurufen, der das derzeit aktive Modul angibt. Sie können dieses Attribut aus der Systemtabelle verwenden, um Bedingungen für das Laden von Daten zu erstellen.
Beispiel
Wenn Sie Sharding mithilfe von Falltypen anwenden, richten Sie einen Ausdruck Case_Type_Shard basierend auf dem ActiveApplicationCode- Attribut ein, um zu bestimmen, welcher Falltyp zu welchem Anwendungscode gehört. Dann legen Sie in der Tabelle „ cases_base “ die Join-Bedingung fest auf:
Cases_preprocessing where Case_type_Shard = Case_type
Dadurch wird sichergestellt, dass nur die Fälle mit einem Falltyp, der zum aktuellen Shard gehört, in Ihrer endgültigen Ausgabe übergeben werden.
events_preprocessing
einen Nachschlageausdruck für die Tabelle cases_base
, der überprüft, ob sich Fälle im ausgewählten Shard befinden.
Siehe Abbildung unten.
Verwenden Sie dieses Ausdrucksattribut in der Join-Bedingung der Tabelle events_base mit dem Ausdruck:
Events_preprocessing where Case_in_shard
.
Um Ihre Anwendung für das Sharding einzurichten, benötigen Sie auch ein Modul pro Shard. Diese Module müssen dieselben Modulcodes wie die in Ihrem Connector haben.
Darüber hinaus kann sich die Datenstruktur für die regulären Shards und die Benchmark-Shards unterscheiden, je nachdem, welchen Benchmark-Shard Sie verwenden. In diesem Fall benötigen Sie eine separate Anwendung für den Benchmark-Shard.
Da Sie mehrere Module verwenden, müssen Sie die Daten mit einem Skript neu laden, um sicherzustellen, dass die Daten aller Connector-Module im selben Dataset landen. So weiß die Anwendung basierend auf dem geöffneten Modul, welcher Teil der Daten berücksichtigt werden soll. Das Skript zum Neuladen Ihrer Daten finden Sie unter Einrichten von automatisierten Datenaktualisierungen .