This document aims to guide you through the different steps of developing a Connector for UiPath Process Mining.
Before getting started with this guide, make sure your chosen process and data source are suitable for a Process Mining implementation. Process Mining requires:
- an activity to define the performed process events;
- a timestamp to show when each step happened,
- an identifier to tie all events in one process execution.
Without one of these three mandatory elements, a Process Mining analysis is not possible. Therefore, it is important to know the tables and fields of your data before getting started.
Many of these steps are part of the data transformation process. This transformation is necessary since Process Mining requires the data in the form of an event log to be able to visualize it. This format is called the data model. The data model describes the tables and fields that need to be part of the output dataset generated by the connector. However, most source systems do not provide data in this format. Therefore, it is necessary to transform the data.
To help with the data transformation, Process Mining has created several connectors which can be used as a template for loading, cleaning, and transforming data. These pre-built connectors are specific for a certain system and process such as the SAP Connector for Purchase-to-Pay Discovery Accelerator.
When starting with a new project, it is recommended to check whether you can make use of UiPath pre-built connectors. In the simplest cases, the input data fits directly with one of the connectors, and there is no need for a custom connector. If neither of these options are applicable, you will need to build a connector yourself.
The goal of a connector is to produce a dataset that fits the data model. The most standard Process Mining data model consists of a Cases and an Event log table. Alternative data models consist of several Entity and Events tables. Independent of the data model, we recommend structuring the first transformation steps of the connector as listed below.
If Event log, Tags, or Due dates are part of the data model, the following two transformation steps must be performed.
In SQL, not all transformations can be computed in the same table. The reason for this may be aggregates or properties that cannot be expressed in a single select statement. You can create supporting tables for this purpose. Creating a supporting table in the database allows you to use the model in multiple transformations. If it is not needed to reuse the model, the supporting transformation can also be added as a preprocessing query in the existing table. It is a balance between creating supporting tables and preprocessing queries to get readable transformations.
To make a distinction between supporting transformations and the other transformations, you can group them in a separate sub directory. The default name of this group should be
supporting_models, but more descriptive names are also allowed.
Completing the above steps must result in a main folder structure for the connector with the following naming conventions:
In any of these main folders, the folder supporting_models may be present, or any other grouping that enhances the understandability of the transformations.
It is required that models only depend on models until the same main group. It is therefore not allowed to define tables in
3. Events which are dependent on a table from
This guide leads you through the steps to create these different sections and provides you with conceptual explanations as well as tips and tricks for the actual implementation. The guide is written in a generic way so that you can apply it to any kind of process and system. To successfully follow this guide, make sure you are familiar with your input data and its underlying model.
Updated 5 months ago