Editing transformations

Folder structure

Die Transformationen einer Prozess-App bestehen aus einem dbt- Projekt. Nachfolgend finden Sie eine Beschreibung des Inhalts eines dbt- Projektordners.

Ordner/Datei	Enthält
dbt_packages\	das pm_utils -Paket und seine Makros.
logs\	Protokolle, die beim Ausführen von dbterstellt werden.
macros\	benutzerdefinierte Makros.
models\	.sql die Transformationen definieren.
models\schema\	.yml die Tests für die Daten definieren.
seed	.csv Dateien mit Konfigurationseinstellungen.
dbt_project.yml	die Einstellungen des dbt-Projekts.

Siehe Abbildung unten.

Datentransformationen

Die Datenumwandlungen sind in .sql -Dateien im Verzeichnis models\ definiert. Die Datenumwandlungen sind in einem Standardsatz von Unterverzeichnissen organisiert:

• 1_input,
• 2_entities,
• 3_events,
• 4_event_logs,
• 5_business_logic.

Siehe Struktur von Transformationen.

Die .sql -Dateien sind in Jinja SQL geschrieben, sodass Sie Jinja-Anweisungen in einfache SQL-Abfragen einfügen können. Wenn dbt alle .sql -Dateien ausführt, führt jede .sql -Datei zu einer neuen Ansicht oder Tabelle in der Datenbank.

Normalerweise haben die .sql -Dateien die folgende Struktur:

1. With-Anweisungen: Eine oder mehrere with-Anweisungen zum Einschließen der erforderlichen Untertabellen.

   • {{ ref(‘My_table) }} verweist auf eine Tabelle, die durch eine andere SQL-Datei definiert ist Datei.
   • {{ source(var("schema_sources"), 'My_table') }} verweist auf eine Eingabetabelle.
2. Hauptabfrage: Die Abfrage, die die neue Tabelle definiert.
3. Letzte Abfrage: Normalerweise wird eine Abfrage wie Select * from table am Ende verwendet. Dadurch ist es einfach, während des Debuggens Unterauswahlen zu treffen.

   

Weitere Tipps zum effektiven Schreiben von Transformationen finden Sie unter Tipps zum Schreiben von SQL

Adding source tables

Um dem dbt -Projekt eine neue Quelltabelle hinzuzufügen, muss sie in models\schema\sources.yml aufgeführt sein. Auf diese Weise können andere Modelle darauf verweisen, indem sie {{ source(var("schema_sources"), 'My_table_raw') }} verwenden. Ein Beispiel finden Sie in der Abbildung unten.

Wichtig: Jede neue Quelltabelle muss in sources.yml aufgeführt sein.

Hinweis:

Das Suffix _raw wird beim Laden von Daten zu den Tabellennamen der Quelltabellen hinzugefügt. Beispielsweise sollte eine Tabelle mit dem Namen my_table als my_table_rawbezeichnet werden.

Ausführliche Informationen finden Sie in der offiziellen dbt-Dokumentation zu Quellen.

Data output

Die Datenumwandlungen müssen das Datenmodell ausgeben, das von der entsprechenden App benötigt wird. jede erwartete Tabelle und jedes Feld muss vorhanden sein.

Praktisch bedeutet dies, dass die Tabellen in models\5_business_logic nicht gelöscht werden sollten. Außerdem sollten die Ausgabefelder in den entsprechenden Abfragen nicht entfernt werden.

Wenn Sie Ihrer Prozess-App neue Felder hinzufügen möchten, können Sie die benutzerdefinierten Felder verwenden, die für die Prozess-App verfügbar sind. Ordnen Sie die Felder in den Transformationen den benutzerdefinierten Feldern zu, damit sie in der Ausgabe verfügbar sind. Stellen Sie sicher, dass die benutzerdefinierten Felder in der Ausgabe wie im Datenmodell der Prozess-App beschrieben benannt sind.

Tipp:

Sie können die dbt docs-Befehle verwenden, um eine Dokumentationsseite für Ihr dbt-Projekt zu generieren und in Ihrem Standardbrowser zu öffnen. Die Dokumentationsseite enthält auch ein Herkunftsdiagramm, das ein Entitätsbeziehungsdiagramm mit einer grafischen Darstellung der Verknüpfungen zwischen den einzelnen Datentabellen in Ihrem Projekt bietet.

Ausführliche Informationen finden Sie in der offiziellen dbt-Dokumentation auf dbt docs.

Makros

Makros machen es einfach, gängige SQL-Konstruktionen wiederzuverwenden. Ausführliche Informationen finden Sie in der offiziellen dbt-Dokumentation zuJinja-Makros.

pm_utils

Das Paket pm-utils enthält eine Reihe von Makros, die normalerweise in Process Mining-Transformationen verwendet werden. Weitere Informationen zu den pm_utils -Makros finden Sie unter ProcessMining-pm-utils.

Nachfolgend finden Sie ein Beispiel für Jinja-Code, der das Makro pm_utils.optional() aufruft.

Samen

Startwerte sind csv -Dateien, die verwendet werden, um Ihren Transformationen Datentabellen hinzuzufügen. Ausführliche Informationen finden Sie in der offiziellen dbt-Dokumentation zu jinja-Samen.

In Process Miningwird dies normalerweise verwendet, um die Konfiguration von Zuordnungen in Ihren Transformationen zu vereinfachen.

Nach dem Bearbeiten von Seed-Dateien werden diese Dateien nicht sofort automatisch in der Datenbank aktualisiert. Um dbt anzuweisen, den Inhalt der neuen Seed-Datei in die Datenbank zu laden, führen Sie entweder

• dbt seed – wodurch nur die Seed-Dateitabellen aktualisiert werden, oder
• dbt build – führt auch alle Modelle und Tests aus.
  Hinweis: Wenn die Seed-Datei anfangs keine Datensätze hatte, wurden die Datentypen in der Datenbank möglicherweise nicht korrekt festgelegt. Um dies zu beheben, rufen run dbt seed --full-refresh auf. Dadurch wird auch der Spaltensatz in der Datenbank aktualisiert.

Activity configuration

Die Datei activity_configuration.csv wird verwendet, um zusätzliche Felder im Zusammenhang mit Aktivitäten festzulegen. activity_order wird als Tie-Breaker verwendet, wenn zwei Ereignisse auf demselben Zeitstempel stattfinden. Ein Beispiel finden Sie in der Abbildung unten.

Tests

Der Ordner models\schema\ enthält einen Satz von .yml -Dateien, die Tests definieren. Diese überprüfen die Struktur und den Inhalt der erwarteten Daten. Ausführliche Informationen finden Sie in der offiziellen dbt-Dokumentation zu Tests.

Wenn die Transformationen in Process Miningausgeführt werden, werden bei jeder Datenaufnahme nur die Tests in sources.yml ausgeführt. Dies geschieht, um zu überprüfen, ob die Eingabedaten richtig formatiert sind.

Hinweis: Stellen Sie beim Bearbeiten von Transformationen sicher, dass die Tests entsprechend aktualisiert werden. Die Tests können bei Bedarf entfernt werden.

Benutzerdefinierte Metriken zur Durchsatzzeit

Einleitung

Mit dem Anpassen von Datentransformationen und der Dashboard-Bearbeitung können Sie benutzerdefinierte Metriken für die Durchsatzzeit erstellen und verwenden. Durchsatzzeiten sind die Zeitpunkte zwischen zwei Aktivitäten A und B. Nachfolgend finden Sie eine Beschreibung der Schritte, die Sie ausführen müssen, um eine benutzerdefinierte Durchsatzzeitmetrik beim Bearbeiten von Transformationen zu erstellen, und wie Sie die Durchsatzzeitmetrik in den Prozess-App-Dashboards aktivieren.

Erstellen einer benutzerdefinierten Metrik für die Durchsatzzeit mit Bearbeitung von Transformationen

Sie müssen zuerst die Durchsatzzeit berechnen und sie dann als Feld „ Fall “ verfügbar machen.

Berechnung der Durchlaufzeit

Pro Fall können Sie die Durchsatzzeiten zwischen Aktivität A und Aktivität Bberechnen. Da Aktivitäten mehr als einmal pro Fall auftreten können, müssen Sie berücksichtigen, ob Sie das erste oder letzte Vorkommen einer Aktivität verwenden.

1. Erstellen Sie ein zusätzliches Modell basierend auf dem Ereignisprotokoll , um die gewünschten Durchsatzzeiten zu berechnen. Zum Beispiel Cases_with_throughput_times.

2. Erstellen Sie in diesem Modell Vorverarbeitungstabellen, in denen Sie definieren, welche Ereignisenden Sie für die Berechnungen verwenden möchten. Pro Tabelle benötigen Sie die Fall-IDund das Ereignisende einer Aktivität. Nachfolgend finden Sie ein Beispiel dafür, wie das letzte Vorkommen von Aktivität A für einen Fall ausgewählt wird.

   Event_end_activity_A as (
       select
           Event_log."Case_ID",
           max(Event_log."Event_end") as "Event_end_activity_A"
       from Event_log
       where Event_log."Activity" = 'Activity A'
       group by Event_log."Case_ID")

   Hinweis:

   Wenn Sie in diesem Beispiel das erste Vorkommen der Aktivität auswählen möchten, ersetzen Sie max durch min.

3. Definieren Sie die Durchsatzzeittabelle, indem Sie die Vorverarbeitungstabellen mit dem Ereignisprotokoll verbinden und die tatsächliche Durchsatzzeit berechnen.

   Tipp:

   Sie können die Funktion datediff im Paket pm-utils verwenden, um den Zeitunterschied zwischen zwei beliebigen Ereignisenden zu berechnen.

   Die Durchsatzzeit sollte in Millisekunden für die Instanzen berechnet werden, in denen Aktivität A Aktivität Bvorausgeht. Millisekunden sind die Zeiteinheit, die zum Definieren von Dauern in der App-Vorlage verwendet wird. Da die Durchlaufzeiten in den Vorverarbeitungstabellen bereits pro Fall gruppiert sind, können Sie einen beliebigen Datensatz auswählen. Im obigen Beispiel wird die Aggregation min verwendet. Die Tabelle für die Durchsatzzeit, in der die Durchsatzzeit und eine Fall-IDausgewählt werden, kann wie unten angezeigt definiert werden.

   Cases_with_throughput_times as (
       select
           Event_log."Case_ID",
           case
               when min(Event_end_activity_A."Event_end_activity_A") <= min(Event_end_activity_B."Event_end_activity_B")
                   then {{ pm_utils.datediff('millisecond',
                   'min(Event_end_activity_A."Event_end_activity_A")',
                   'min(Event_end_activity_B."Event_end_activity_B")') }}
           end as "Throughput_time_activity_A_to_activity_B"
       from Event_log
       left join Event_end_activity_A
           on Event_log."Case_ID" = Event_end_activity_A."Case_ID"
       left join Event_end_activity_B
           on Event_log."Case_ID" = Event_end_activity_B."Case_ID"
       group by Event_log."Case_ID)"

Berechnen der Durchsatzzeit in Tagen ohne Wochenenden

Sie können die Funktion date_from_timestamp im Paket pm-utils verwenden, um die Anzahl der Tage zwischen zwei Aktivitäten zu berechnen. Darüber hinaus können Sie mit der Funktion diff_weekdays Wochenendtage herausfiltern.

Im folgenden Codebeispiel erfahren Sie, wie die Anzahl der Wochentage zwischen Aktivität A und Aktivität B berechnet wird.

with Event_log as (
    select * from {{ ref('Event_log') }}
),

Activity_A as (
    select
        Event_log."Case_ID",
        min({{ pm_utils.date_from_timestamp('Event_log."Event_end"') }}) as "Date_activity_A"
    from Event_log
    where Event_log."Activity" = 'Receive invoice'
    group by Event_log."Case_ID"
),

Activity_B as (
    select
        Event_log."Case_ID",
        min({{ pm_utils.date_from_timestamp('Event_log."Event_end"') }}) as "Date_activity_B"
    from Event_log
    where Event_log."Activity" = 'Pay invoice'
    group by Event_log."Case_ID"
),

Total_days_minus_weekends as (
    select
        Activity_A."Case_ID",
        Activity_A."Date_activity_A",
        Activity_B."Date_activity_B",
        {{ pm_utils.diff_weekdays('Activity_A."Date_activity_A"', 'Activity_B."Date_activity_B"') }}
    -- Only compute for cases where both dates are known.
    from Activity_A
    inner join Activity_B
        on Activity_A."Case_ID" = Activity_B."Case_ID"
)

select * from Total_days_minus_weekends

Berechnen der Durchlaufzeit in Tagen ohne Feiertage

Führen Sie die folgenden Schritte aus, um die Durchsatzzeit in Tagen zwischen Aktivität A und Aktivität B ohne Wochenendtage und Feiertage zu berechnen.

1. Erstellen Sie eine Holidays.csv -Datei, um die Tage zu definieren, die als Feiertage gezählt werden sollen. Die Datei sollte mindestens einen Datensatz für jeden Feiertag enthalten. Verwenden Sie das folgende Format:

Feiertag	Datum	Wochentag
Tag des neuen Jahres	2024-01-01	Ja
Verbesserungen	2024-03-31	Nein
..	..	..

Die Datensätze in der Holidays.csv -Datei werden verwendet, um die Anzahl der Tage zu zählen, die aus einem Datumsbereich ausgeschlossen werden müssen.

2. Laden Sie die Holidays.csv -Datei als Startdatei in das dbt -Projekt. Ausführliche Informationen finden Sie in der offiziellen dbt-Dokumentation zu jinja-Samen.

3. Berechnen Sie die Durchsatzzeit in Tagen ohne Wochenenden mithilfe der Funktionen date_from_timestamp und diff_weekdays , die im Paket pm-utils bereitgestellt werden, wie oben unter Berechnen der Durchsatzzeit in Tagen ohne Wochenenden beschrieben.

4. Berechnen Sie für jeden Fall die Anzahl der Datensätze, die in der Datei „Feiertage .csv “ gespeichert sind und in den angegebenen Datumsbereich fallen. Siehe Beispielcode unten.

Holidays_count as (
    select
        Total_days_minus_weekends."Case_ID",
        count(Holidays."Date") as "Number_of_holidays"
    from Total_days_minus_weekends
    left join Holidays
        on Holidays."Date" between Total_days_minus_weekends."Date_activity_A" and Total_days_minus_weekends."Date_activity_B"
    where Holidays."Weekday" = 'Yes'
    group by Total_days_minus_weekends."Case_ID"
)

Hinweis:

Im obigen Beispiel wird der Filter Weekday = 'Yes' verwendet, um Feiertage nicht zu subtrahieren, wenn der Feiertag auf einen Samstag oder Sonntag fällt. Dies ist bereits in der Funktion diff_weekday berücksichtigt.

5. Subtrahieren Sie die berechnete Anzahl der Feiertage von der Gesamtzahl der für jeden Fall berechneten Tage. Siehe Beispielcode unten.

Total_days_minus_weekends_and_holidays as (
    select
        Total_days_minus_weekends."Case_ID",
        Total_days_minus_weekends."Number_of_days" - Holidays_count."Number_of_holidays" as "Number_of_days_between_dates"
    from Total_days_minus_weekends
    inner join Holidays_count
        on Total_days_minus_weekends."Case_ID" = Holidays_count."Case_ID"
)

Durchsatzzeit als Fallfeld verfügbar machen

Sobald die Durchsatzzeittabelle erstellt wurde, muss diese Tabelle mit der Tabelle Fälle verknüpft werden, um die zusätzlichen Durchsatzzeitdaten als Fallinformationen hinzuzufügen. Damit das neue Feld für die Durchsatzzeit in den Dashboards verfügbar ist, muss das neue Feld für die Durchsatzzeit in eines der benutzerdefinierten Felder für die Falldauer umgewandelt werden.

Ersetzen Sie eine der benutzerdefinierten Zeilen für die Falldauer in der Tabelle Fälle , die wie folgt aussehen:

{{ pm_utils.optional(ref('Cases_base'), '"custom_case_duration_1"', 'integer') }} as "custom_case_duration_1",

mit der neu erstellten Durchlaufzeit:

Cases_with_throughput_times."Throughput_time_activity_A_to_activity_B" as "custom_case_duration_1",

Die Aktualisierungen der Transformationen für die benutzerdefinierte Durchsatzzeitmetrik sind jetzt abgeschlossen und können in die App-Vorlage importiert werden.

Aktivieren der Durchsatzzeitmetrik in den Prozess-App-Dashboards

Wenn Sie eine benutzerdefinierte Durchsatzzeit in Ihren Transformationen erstellt haben, ist sie in Ihrer App-Vorlage als Falleigenschaft unter ihrem Alias verfügbar. Sie können Ihre Prozess-App anpassen, um eine Metrik für die Durchsatzzeit basierend auf der benutzerdefinierten Durchsatzzeit zu erstellen, die Sie in den Transformationen erstellt haben.

Hinweis:

Standardmäßig wird ein neues benutzerdefiniertes Feld für die Dauer als Feld vom Typ numeric hinzugefügt. Stellen Sie sicher, dass Sie das Feld bearbeiten und den Type des neuen Felds in duration ändern. Siehe auch Data Manager.

• Wechseln Sie zu Data Manager und erstellen Sie eine neue Metrik.
• Wählen Sie das benutzerdefinierte Dauerfeld aus, das für die Durchsatzzeit verwendet werden soll, und wählen Sie Durchschnitt oder eine andere gewünschte Aggregation aus. Sie können auch das benutzerdefinierte Feld für die Falldauer im Datenmanagerin Ihren gewünschten Namen umbenennen.
• Bearbeiten Sie die Anwendung, und fügen Sie die neue Metrik in die Diagramme ein, wo Sie sie für Geschäftsbenutzer verfügbar machen möchten.
• Veröffentlichen Sie die Dashboards, um die Metrik für die Durchsatzzeit in den Dashboards verfügbar zu machen.

Hinweis:

In Purchase-to-Pay- und Order-to-Cash- App-Vorlagen ist eine Durchlaufzeitberechnung bereits in Purchase_order_items_with_throughput_times bzw. Sales_order_items_with_throughput_timesverfügbar. Benutzerdefinierte Durchlaufzeiten können dort hinzugefügt und dann als benutzerdefinierte Dauer für Purchase_order_items oder Sales_order_itemsverfügbar gemacht werden.

SQL differences between Snowflake and SQL Server

SQL Server vs. Snowflake

In einer lokalen Entwicklungsumgebung werden Transformationen auf SQL Server ausgeführt, während Snowflake in der Process Mining Automation Suite verwendet wird. Obwohl die meisten SQL-Anweisungen sowohl auf SQL Server als auch auf Snowflake funktionieren, kann es geringfügige Unterschiede in der Syntax geben, die zu unterschiedlichen Rückgabeergebnissen führen können.

So schreiben Sie SQL-Anweisungen, die auf beiden Datenbanksystemen funktionieren:

• Schreiben Sie Feldnamen in doppelte Anführungszeichen, z. B. Table."Field" .
• Verhindern der Verwendung von SQL-Funktionen, die sich in Snowflake und SQL Server unterscheiden, z. B. string_agg() und listagg() .
  Das pm_utils -Paket enthält eine Reihe von Funktionen, die für beide Datenbanktypen funktionieren, siehe Mehrere Datenbanken. Anstatt beispielsweise string_agg() oder listagg() zu verwenden, führt pm_utils.string_agg() zu demselben Verhalten für beide Datenbanken. Wenn pm_utils nicht die gewünschte Funktion enthält, sollte eine Chinja-Anweisung erstellt werden, um sicherzustellen, dass die richtige Funktion für jede Datenbank aufgerufen wird.

Zeichenfolgenverkettung

Um zu Strings zu kombinieren, verwenden Sie die Funktion pm_utils.concat() . Dies führt zu den gleichen Ergebnissen für SQL Server und Snowflake.

Beispiel: pm_utils.concat("This is a nice string", null) = "This is a nice string" Das Verketten von Zeichenfolgen sollte nicht mit Operatoren wie + oder || erfolgen, da sie sich für beide Datenbanken unterscheiden (Snowflake verwendet || und SQL Server verwendet + ). Auch die Standardfunktion concat() hat auf beiden Systemen ein unterschiedliches Verhalten:

SQL-Server	Snowflake
null werden ignoriert und als leere Zeichenfolge behandelt.	null führen dazu, dass das gesamte Ergebnis null ist.

Sortierung

Die Sortierung wird in Snowflake und SQL Server unterschiedlich gehandhabt.

Beispiel: ... order by "Attribute_1" desc, "Attribute_2" ...

NULL-Werte

SQL-Server	Snowflake
null werden standardmäßig zuerst sortiert (aufsteigend)	null werden standardmäßig als letztes sortiert (aufsteigend)

Handling capital letters

SQL-Server	Snowflake
Großbuchstaben werden wie erwartet sortiert (AaBbCc)	Sortiert zuerst nach Großbuchstaben, dann nach Nicht-Großbuchstaben (ABCabc)

Bindestriche

Beispiel: -Accountant-

SQL-Server	Snowflake
Bindestriche werden bei der Sortierung ignoriert (daher wird „-Accountant-“ genauso behandelt wie „Accountant“).	Bindestriche werden oben sortiert

Umgang mit Leerzeichen

Wenn Sie nach den Werten „A“ und „A“ gruppieren, wird dies in SQL Server als ein Wert angesehen, in Snowflake jedoch als zwei verschiedene Werte. Daher wird das Trimmen empfohlen, wenn Ihre Daten dieses Problem verursachen können.

Berücksichtigung von Groß- und Kleinschreibung

Standardmäßig unterscheidet SQL Server die Groß-/Kleinschreibung, während Snowflake die Groß-/Kleinschreibung berücksichtigt. Das bedeutet, dass Table."Field" = "Some_value" und Table."Field" = "SOME_VALUE" dasselbe Resultset in SQL Server zurückgeben, aber möglicherweise zwei verschiedene Resultsets in Snowflake.

Es wird empfohlen, das Verhalten Ihrer lokalen SQL Server-Datenbank so zu ändern, dass es dem Verhalten von Snowflakes entspricht, um Probleme zu vermeiden. Dies kann erreicht werden, indem die Datenbanksortierung auf einen Wert festgelegt wird, bei dem die Groß-/Kleinschreibung beachtet wird.

Configuration settings for loading input data

Settings.json

The settings.json file contains settings related to loading input data. These settings are temporary and should be used to switch existing process apps (created before March 2023) to the new data loading behavior. You should not change the settings.json file for new process apps.

Wenn Sie eine neue Prozess-App erstellen, stellen Sie immer sicher, dass die Eingabedaten im erforderlichen Format für die App-Vorlage sind, die Sie zum Erstellen einer neuen App verwenden. Siehe App-Vorlagen.

Wichtig:

Neue Prozess-Apps gelten standardmäßig für das neue Datenmodell. Vorhandene Prozess-Apps funktionieren weiterhin in Process Mining 2023.4 und Process Mining 2023.10. Stellen Sie die Datenladeeinstellungen Ihrer Prozess-Apps vor Process Mining 2024.4 um, um sicherzustellen, dass das Hochladen von Daten weiterhin ordnungsgemäß funktioniert. Die Einstellungen AddRawTablePostfix und StripSpecialCharacters sind temporär und werden in Process Mining 2024.4entfernt. Von da an funktionieren alle Prozess-Apps so, als wären diese Einstellungen auf falsefestgelegt.

Einstellung	Format	Beschreibung
AddRawTablePostfix	boolean	Zum Hinzufügen eines _raw- Suffix zu Ihren Quelltabellen, wenn Sie Datei-Uploads über die Option Daten hochladen verwenden. Wenn die von Ihnen hochgeladene Datei beispielsweise Event_log.csv heißt, ändert sie sich in Event_log_raw.csv , wenn diese Einstellung auf truefestgelegt ist.
StripSpecialCharacters	boolean	Zum Entfernen von Sonderzeichen und Ersetzen von Leerzeichen durch Unterstriche in Tabellennamen und/oder Feldnamen. Ein Feld namens Event+end wird beispielsweise in Eventend geändert.

Verwenden vorhandener Prozess-Apps mit den neuen Datenmodelleinstellungen

Führen Sie diese Schritte aus, um Ihre vorhandenen Prozess-Apps mit den neuen Datenmodelleinstellungen zu verwenden.

1. Laden Sie settings.json.zip herunter und entpacken Sie die Datei.

2. Exportieren Sie die Transformationen Ihrer Prozess-App. Siehe Bearbeiten von Datentransformationen in einer lokalen Umgebung.

3. Add the settings.json file (if not already present) to transformations.

4. Stellen Sie sicher, dass sowohl AddRawTablePostfix als auch StripSpecialCharacters auf „false“ festgelegt sind.

5. Ändern Sie Ihre Eingabedateien oder Transformationen so, dass die Dateinamen genau übereinstimmen. Wenn Ihre Eingabeumwandlungen beispielsweise event_log_raw erwarten, sollte Ihre CSV -Datei auch event_log_raw.csvheißen.

6. Wenn Sie Sonderzeichen in Tabellen- oder Feldnamen verwenden (z. B. ' ', '(' oder '?'), stellen Sie sicher, dass die Eingabeumwandlungen denselben Namen verwenden. Beispielsweise sollte ein Feld Aktivitätskategorie in Ihren Abfragen als Aktivitätskategorie und nicht als Aktivitätskategoriebezeichnet werden.

7. Importieren Sie Transformationen und erfassen Sie neue Daten.

Die Transformationen werden erneut in der Plattform ausgeführt und die Quelltabellen werden entsprechend geändert.

Dbt-Projekte

Datentransformationen werden verwendet, um Eingabedaten in Daten umzuwandeln, die für Process Mining geeignet sind. Die Transformationen in Process Mining werden als dbt- Projekte geschrieben.

Auf dieser Seite wird eine Einführung in dbt angezeigt. Ausführliche Informationen finden Sie in der offiziellen dbt-Dokumentation.

pm-utils package

Process Mining -App-Vorlagen sind in einem dbt -Paket namens pm_utils enthalten. Dieses pm-utils -Paket enthält Dienstprogrammfunktionen und Makros für Process Mining- dbt -Projekte. Weitere Informationen zu pm_utils finden Sie unter ProcessMining-pm-utils.

Aktualisieren der PM-utils-Version, die für Ihre App-Vorlage verwendet wird

UiPath® verbessert das pm-utils -Paket ständig durch neue Funktionen.

Wenn eine neue Version des pm-utils -Pakets veröffentlicht wird, wird Ihnen empfohlen, die in Ihren Transformationen verwendete Version zu aktualisieren, um sicherzustellen, dass Sie die neuesten Funktionen und Makros des pm-utils -Pakets nutzen.

Die Versionsnummer der neuesten Version des pm-utils -Pakets finden Sie im Bereich Versionen der ProcessMining -pm-utils.

Führen Sie die folgenden Schritte aus, um die pm-utils -Version in Ihren Transformationen zu aktualisieren.

1. Laden Sie den Quellcode (ZIP) aus der Version von pm-utils herunter.
2. Extrahieren Sie die zip -Datei, und benennen Sie den Ordner in pm_utils um.

3. Exportieren Sie Transformationen aus dem Inline- Datentransformations -Editor und extrahieren Sie die Dateien.

4. Ersetzen Sie den Ordner pm_utils aus den exportierten Transformationen durch den neuen Ordner pm_utils .

5. Zippen Sie die Inhalte der Transformationen erneut und importieren Sie sie in den Datentransformations- Editor.

Siehe auch .