Transformationen

Einleitung

Im Transformationsschritt werden die extrahierten Daten in das erforderliche Datenmodell transformiert. Je nach App, für die der Connector entwickelt wurde, ist das Datenmodell entweder das generische Process Mining-Modell (TemplateOne) oder das prozessspezifische Datenmodell (Purchase-to-Pay und Order-to-Cash Discovery Accelerator).

Anschluss für	Datenmodell
TemplateOne	Eingabetabellen von TemplateOne.
Purchase-to-Pay Discovery Accelerator	Purchase-to-Pay-Eingabefelder.
Order-to-Cash Discovery Accelerator	Order-to-Cash-Eingabefelder.

Dbt-Projektdateien

Variablen in einem dbt- Projekt müssen für die angegebene Datenbank korrekt konfiguriert sein. Dies kann entweder SQL Server oder Snowflake sein. dbt_project_sqlserver.yml sollte die spezifischen Einstellungen für das dbt- Projekt enthalten, wenn es mit SQL Server verwendet wird. dbt_project.yml sollte die spezifischen Einstellungen für das dbt- Projekt enthalten, wenn es mit Snowflake verwendet wird.

Transformationsschritte

Das Erstellen der Transformationen besteht aus den Schritten, wie in der Abbildung unten gezeigt.

Hinweis: Um die Wartbarkeit und Lesbarkeit der Connectors sicherzustellen, müssen alle Transformationen der gleichen Gesamtstruktur und den gleichen Namenskonventionen folgen. Die Richtlinien, die ein UiPath Process Mining Connector einhalten sollte, finden Sie unter Struktur von Transformationen.

Die Transformationen bestehen aus einem system- und prozessspezifischen Teil. Im systemspezifischen Teil wandeln die Transformationen die Eingabedaten in ein Format um, bei dem es keine Rolle spielt, ob die Daten aus Quellsystem A oder Quellsystem B stammen. Die prozessspezifischen Transformationen stellen sicher, dass die Daten in ein Format umgewandelt werden, das kann in Process Mining-Dashboards verwendet werden.

Die Aufteilung zwischen den Systemtransformationen und den Prozesstransformationen ist der Unterschied zwischen dem Datenmodell für die Discovery Accelerators (Purchase-to-Pay und Order-to-Cash) und TemplateOne.

• Für die Discovery Accelerators gelten nur die Systemumwandlungen. Das Datenmodell besteht aus Entitäten und Ereignissen. Entitäten sind prozessspezifisch. Das Datenmodell „Purchase-to-Pay“ enthält beispielsweise Bestellungen und Rechnungen.
• Für TemplateOne gelten sowohl die System- als auch die Prozessumwandlung. Basierend auf den Entitäten und Ereignissen wird das Ereignisprotokoll erstellt. Darüber hinaus müssen Geschäftsdaten in Form von Tags und Fälligkeitsdaten bereitgestellt werden. Es wird erwartet, dass die prozessspezifischen Transformationen quellsystemagnostisch sind.

Transformationsrichtlinien

Allgemein

• Die Transformationsstruktur sollte den unter Struktur von Transformationen beschriebenen Richtlinien entsprechen.
• Die Transformationen sollten auf SQL Server sowie Snowflake ausgeführt werden können. Weitere Informationen finden Sie unter Unterstützung mehrerer Datenbanken.
• Die Ausgabe der Transformationen des Connectors sollte mit der Eingabe der entsprechenden Process Mining-App kompatibel sein.
• Alle Felder sollten in den Datentyp umgewandelt werden, wie im Datenmodell kommuniziert. Insbesondere für Textfelder sollte der Datentyp in SQL Server ein nvarchar sein, der nicht vom Typ max ist. Um die Implementierung dieser Typumwandlung zu unterstützen, können die Makros in pm-utils verwendet werden.

Konventionen

• Alle SQL-Modelle werden als Tabelle materialisiert, mit Ausnahme der Modelle im Verzeichnis 1_input. Dies erfordert mehr Speicherplatz, um die Ergebnisse zu speichern. Die Laufzeit der Abfragen verbessert sich jedoch erheblich im Vergleich zur Materialisierung von Modellen als Ansicht.
• SQL-Befehle und -Funktionen werden in Kleinbuchstaben geschrieben.

• Verwenden Sie dieselbe Einrückungsebene für select , from , where , join usw., um die Struktur des Modells besser zu verstehen.

  • Verwenden Sie Einrückungen für die Verwendung von Funktionen, wenn dies die Lesbarkeit verbessert. Verwenden Sie beispielsweise einen Einzug für jede Anweisung in einer case-Funktion.
  • Ziehen Sie on in Joins ein und z. B. jede Anweisung in einer case -Funktion. Der Einzug sollte um 4 Leerzeichen erfolgen.

• Verwenden Sie konsistente Namenskonventionen für Tabellen und Felder, um SQL-Fehler zu vermeiden, die darauf hinweisen, dass Tabellen oder Felder in der Datenbank nicht vorhanden sind. Halten Sie sich an die folgenden Richtlinien:

  • Tabellen und Felder beginnen mit einem Großbuchstaben.
  • Verwenden Sie einen Unterstrich ('_') zwischen einzelnen Wörtern in Tabellen und Feldern.
  • Alle Felder enthalten Anführungszeichen. Bei Snowflake werden alle Feldnamen in der Datenbank mit Großbuchstaben angezeigt, wenn sie ohne Anführungszeichen geschrieben werden.
  • Tabellen enthalten keine Anführungszeichen. Dadurch wird die Lesbarkeit in Kombination mit Feldern mit Anführungszeichen verbessert.
  • Versuchen Sie, Ihre Felder so weit wie möglich in alphabetischer Reihenfolge zu definieren, es sei denn, eine andere Reihenfolge ist sinnvoller.
• Allen Feldern wird die Tabelle vorangestellt, aus der sie stammen, um das Modell leichter zu verstehen und zu erweitern.
• Kommas zur Trennung von Feldern werden am Ende der Zeile platziert.
• Verwenden Sie Inline-Kommentare, wenn bestimmte Konstruktionen erklärt werden müssen. Stellen Sie anschließend sicher, dass der Kommentar einen Mehrwert bietet.

Weitere Tipps und Tricks, die beim Entwickeln von SQL-Transformationen verwendet werden können, finden Sie unter Tipps zum Schreiben von SQL.

Als Teil des Frameworks ist ein devkit-connector dbt-Projekt verfügbar, bei dem der Umriss der Transformationen bereits den Transformationsrichtlinien entspricht.

Samen

Die DBT-Seed- Funktionalität sollte für Einstellungen verwendet werden, die eine Zuordnung erfordern. Seeds-Dateien sind CSV-Dateien. Verwenden Sie die gleiche Namenskonvention für die Seed-Dateien wie für die Quelldaten. Verweisen Sie auf die Seed-Dateien in den Transformationen wie auf jedes andere Modell. Wenn Sie auf die Seed-Datei verweisen, stellen Sie sicher, dass Sie auch die Typumwandlung auf alle Felder anwenden.

SQL-Linter

Die Datei .sqlfluff im Ordner transformations enthält die Konfiguration für die Verwendung des Linters.

• Weitere Informationen zu SQLFluff finden Sie in der Dokumentation Erste Schritte – SQLFluff 1.1.0.
• Sie können SQLFluff über Python installieren, indem Sie die folgenden Befehle ausführen: pip install sqlfluff==0.11.0 und pip install sqlfluff-templater-dbt==1.0.0 .
• Sie können die folgenden Befehle im Transformationsordner ausführen, um den Linter zu verwenden: sqlfluff lint und sqlfluff fix .

Konfigurationen

Alle Transformationseinstellungen, von denen erwartet wird, dass sie häufig geändert werden, sollten einfach zu konfigurieren sein:

• Einstellungen, die mit einer Konstanten festgelegt werden können, sollten als dbt varsdefiniert werden. Weitere Informationen zur Verwendung von Variablenfinden Sie in der offiziellen dbt-Dokumentation.
• Einstellungen, die eine Zuordnung erfordern, sollten als dbt- Seedsdefiniert werden. Weitere Informationen finden Sie in der offiziellen dbt-Dokumentation zu Seeds.
• Stellen Sie sicher, dass die Einstellungen ordnungsgemäß dokumentiert sind. Fügen Sie nach Möglichkeit Kommentare im Code hinzu.

Dbt-Variablen

• Ein Connector hat immer den Abschnitt vars in den dbt_project.yml -Dateien.
• Wenn eine Variable hinzugefügt wird, für die ein Kommentar erforderlich ist, wird der Kommentar in dieselbe Zeile wie die Variable eingefügt.

• Wenn es eine Variable mit unterschiedlichen Werten für Snowflake und für SQL Server gibt, sollten die Variablen in der Snowflake-Projektdatei dem Format des Beispiels entsprechen:

  datetime_format: "{{ 'YYYY-MM-DD hh24:mi:ss.ff3' if target.type == 'snowflake' else 20 }}"

Filtern

Verwenden Sie für Filter, die in den Transformationen definiert sind, die folgenden Richtlinien:

• Filter, die erforderlich sind, um die richtige Ausgabe zu erhalten, sollten sowohl bei der Extraktion als auch bei der Transformation wiederholt werden. Wenn ein Connector beispielsweise nur Rechnungen vom Typ X benötigt, sollte er in der Transformation als solche gefiltert werden, auch wenn der Extraktor bereits danach filtert. Dies geschieht, um Probleme zu vermeiden, wenn aus irgendeinem Grund ungefilterte Eingabedaten in die Transformation geladen werden.
• Filter, die konfigurierbar sind und zum Begrenzen des Datenvolumens verwendet werden, sollten nur im Extraktor und nicht in der Transformation vorhanden sein, es sei denn, dies kann nicht verhindert werden. Wenn der Extraktor beispielsweise bereits über eine Konfigurationsoption zum Einschränken des Datumsbereichs verfügt, sollte diese nicht auch in der Transformation definiert werden.

Unterstützung mehrerer Datenbanken

Die Transformationen sollten in mehreren Datenbanken ausgeführt werden können. Jede Datenbank hat eine bestimmte SQL-Syntax. Die meisten Transformationen können in jeder Datenbank ausgeführt werden, aber einige Funktionen haben eine datenbankspezifische Syntax. Um das dbt- Projekt in mehreren Datenbanken auszuführen, werden Makros in Kombination mit der Vorlagensprache Jinja verwendet. Weitere Informationen zu Jinja und Makros finden Sie in der offiziellen dbt-Dokumentation .

Um den Entwicklungsprozess der Transformationen zu beschleunigen, wurde das dbt-Paket pm-utils erstellt, das bereits häufig verwendete Makros für bekannte Unterschiede zwischen den beiden Systemen enthält.

Automatisierte Prüfungen

Um robuste und korrekte Transformationen zu erstellen, wird eine automatisierte Prüfung für jede Pull-Anforderung (PR) oder für die Push-Übertragung von Code an einen Remote-Zweig ausgeführt, um zu überprüfen, ob die Transformationen korrekt sind. Siehe Automatisierte Prüfungen.