Editing transformations

Folder structure

Las transformaciones de una aplicación de proceso consisten en un proyecto dbt . A continuación se muestra una descripción del contenido de una carpeta de proyecto dbt .

Carpeta/Archivo	Contiene
dbt_packages\	el paquete pm_utils y sus macros.
logs\	registros creados al ejecutar dbt.
macros\	macros personalizadas.
models\	.sql archivos que definen las transformaciones.
models\schema\	.yml archivos que definen las pruebas en los datos.
seed	Archivos.csv con ajustes de configuración.
dbt_project.yml	la configuración del proyecto dbt.

Consulta la siguiente ilustración.

Transformaciones de datos

Las transformaciones de datos se definen en archivos .sql en el directorio models\ . Las transformaciones de datos están organizadas en un conjunto estándar de subdirectorios:

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

Consulta Estructura de las transformaciones.

Los archivos .sql están escritos en Jinja SQL, lo que te permite insertar instrucciones Jinja dentro de consultas SQL simples. Cuando dbt ejecuta todos los archivos .sql , cada archivo .sql da como resultado una nueva vista o tabla en la base de datos.

Normalmente, los archivos .sql tienen la siguiente estructura:

1. Con instrucciones: una o más instrucciones con para incluir las tablas secundarias necesarias.

   • {{ ref(‘My_table) }} se refiere a la tabla definida por otro archivo .sql archivo.
   • {{ source(var("schema_sources"), 'My_table') }} se refiere a una tabla de entrada.
2. Consulta principal: la consulta que define la nueva tabla.
3. Consulta final: normalmente se utiliza una consulta como Select * from table al final. Esto facilita hacer subelecciones durante la depuración.

   

Para obtener más consejos sobre cómo escribir transformaciones de forma efectiva, consulta Consejos para escribir SQL.

Adding source tables

Para añadir una nueva tabla de origen al proyecto dbt , debe aparecer en models\schema\sources.yml. De esta manera, otros modelos pueden referirse a ella usando {{ source(var("schema_sources"), 'My_table_raw') }}. Consulta la siguiente ilustración para ver un ejemplo.

Importante: Cada tabla de origen nueva debe aparecer en sources.yml.

Nota:

El sufijo _raw se añade a los nombres de las tablas de origen al cargar datos. Por ejemplo, una tabla llamada my_table debe denominarse my_table_raw.

Para obtener información más detallada, consulta la documentación oficial de dbt sobre " Orígenes".

Data output

Las transformaciones de datos deben generar el modelo de datos que requiere la aplicación correspondiente; todas las tablas y campos esperados deben estar presentes.

En la práctica, esto significa que las tablas de models\5_business_logic no deben eliminarse. Además, los campos de salida de las consultas correspondientes no se deben eliminar.

Si desea agregar nuevos campos a su aplicación de proceso, puede usar los campos personalizados que están disponibles para la aplicación de proceso. Asigna los campos en las transformaciones a los campos personalizados para tenerlos disponibles en la salida. Asegúrese de que los campos personalizados reciban el nombre en la salida como se describe en el modelo de datos de la aplicación de proceso.

Consejo:

Puedes utilizar los comandos dbt docs para generar un sitio de documentación para el proyecto dbt y abrirlo en tu explorador predeterminado. El sitio de documentación también contiene un gráfico de linaje que proporciona un diagrama de relación de entidad con una representación gráfica de la vinculación entre cada tabla de datos de tu proyecto.

Para obtener información detallada, consulta la documentación oficial de dbt en dbt docs.

Macros

Las macros facilitan la reutilización de construcciones SQL comunes. Para obtener información detallada, consulta la documentación oficial de dbt sobre macros Jinja.

pm_utils

El paquete pm-utils contiene un conjunto de macros que se usan normalmente en las transformaciones de Process Mining. Para obtener más información sobre las macros pm_utils , consulta ProcessMining-pm-utils.

A continuación se muestra un ejemplo de código Jinja que llama a la macro pm_utils.optional() .

Semillas

Las semillas son archivos csv que se utilizan para añadir tablas de datos a tus transformaciones. Para obtener información detallada, consulta la documentación oficial de dbt sobre semillas de jinja.

En Process Mining, esto se usa normalmente para facilitar la configuración de las asignaciones en tus transformaciones.

Después de editar los archivos de inicialización, estos archivos no se actualizan automáticamente en la base de datos de forma inmediata. Para indicar a dbt que cargue el contenido del nuevo archivo de inicialización en la base de datos, ejecute

• dbt seed , que solo actualizará las tablas de archivos de inicialización, o
• dbt build , que también ejecutará todos los modelos y pruebas.
  Nota: si el archivo de inicialización no tenía registros de datos inicialmente, es posible que los tipos de datos de la base de datos no se hayan configurado correctamente. Para solucionar este problema, llama a run dbt seed --full-refresh. Esto también actualizará el conjunto de columnas en la base de datos.

Activity configuration

El archivo activity_configuration.csv se usa para establecer campos adicionales relacionados con las actividades. activity_order se usa como desempate cuando dos eventos ocurren en la misma marca de tiempo. Consulta la siguiente ilustración para ver un ejemplo.

Pruebas

La carpeta models\schema\ contiene un conjunto de .yml archivos que definen las pruebas. Validan la estructura y el contenido de los datos esperados. Para obtener información detallada, consulta la documentación oficial de dbt sobre pruebas.

Cuando las transformaciones se ejecutan en Process Mining, solo se ejecutan las pruebas en sources.yml en cada ingestión de datos. Esto se hace para comprobar si los datos de entrada tienen el formato correcto.

Nota: al editar transformaciones, asegúrate de actualizar las pruebas en consecuencia. Las pruebas pueden eliminarse si se desea.

Métricas personalizadas de tiempo de procesamiento

Introducción

Con la personalización de las transformaciones de datos y la edición de paneles puedes crear y usar métricas de tiempo de procesamiento personalizadas. Los tiempos de procesamiento son los tiempos entre dos actividades A y B. A continuación se describen los pasos que debes realizar para crear una métrica de tiempo de procesamiento personalizada al editar transformaciones y cómo habilitar la métrica de tiempo de procesamiento en los paneles de la aplicación de proceso.

Crear una métrica de tiempo de procesamiento personalizada con edición de transformaciones

Primero debe calcular el tiempo de procesamiento y luego hacer que esté disponible como campo de caso .

Calcular el tiempo de procesamiento

Por caso, puedes calcular los tiempos de rendimiento entre la Actividad A y la Actividad B.Dado que las actividades pueden ocurrir más de una vez por caso, debes tener en cuenta si tomas la primera o la última ocurrencia de una actividad.

1. Cree un modelo adicional basado en el registro de eventos para calcular los tiempos de procesamiento deseados. Por ejemplo, Casos_con_tiempo_procesamiento.

2. En este modelo, crea tablas de preprocesamiento en las que defines qué extremos de evento quieres utilizar para los cálculos. Por tabla, necesita el ID de casoy el Evento final de una actividad. A continuación se muestra un ejemplo de cómo seleccionar la última aparición de la actividad A para un caso.

   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")

   Nota:

   En este ejemplo, si quieres seleccionar la primera aparición de la actividad, reemplaza max por min.

3. Defina la tabla de tiempo de procesamiento uniendo las tablas de preprocesamiento al registro de eventos y calculando el tiempo de procesamiento real.

   Consejo:

   Puede usar la función dateiff proporcionada en el paquete pm-utils para calcular la diferencia de tiempo entre el final de dos eventos.

   El tiempo de procesamiento debe calcularse en milisegundos para las instancias en las que la actividad A precede a la actividad B.Los milisegundos son la unidad de tiempo utilizada para definir duraciones en la plantilla de la aplicación. Como los tiempos de procesamiento ya están agrupados por caso en las tablas de preprocesamiento, puedes elegir cualquier registro. En el ejemplo anterior se utiliza la agregación mínima . La tabla de tiempo de procesamiento, la selección del tiempo de procesamiento y un ID de caso, se pueden definir como se muestra a continuación.

   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)"

Cálculo del tiempo de procesamiento en días sin incluir los fines de semana

Puedes utilizar la función date_from_timestamp proporcionada en el paquete pm-utils para calcular el número de días entre dos actividades. Además, la función diff_weekdays te permite filtrar los días de fin de semana.

Consulta el siguiente ejemplo de código para saber cómo calcular el número de días de la semana entre la actividad A y la actividad B.

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

Cálculo del tiempo de procesamiento en días sin incluir festivos

Sigue los siguientes pasos para calcular el tiempo de procesamiento en días entre la actividad A y la actividad B , excluyendo los fines de semana y los días festivos.

1. Crea un archivo Holidays.csv para definir los días que deben contarse como vacaciones. El archivo debe contener al menos un registro para cada día festivo. Utiliza el siguiente formato:

Vacaciones	Fecha	Día de la semana
Día de año nuevo	2024-01-01	Sí
Semana Santa	2024-03-31	No
..	..	..

Los registros del archivo Holidays.csv se utilizan para contar el número de días que deben excluirse de un intervalo de fechas.

2. Carga el archivo Holidays.csv como archivo semilla en el proyecto dbt . Para obtener información detallada, consulta la documentación oficial de dbt sobre semillas de jinja.

3. Calcula el tiempo de procesamiento en días sin fines de semana utilizando las funciones date_from_timestamp y diff_weekdays proporcionadas en el paquete pm-utils como se describe anteriormente en Cálculo del tiempo de procesamiento en días sin fines de semana.

4. Calcula el número de registros que se almacenan en el archivo de vacaciones .csv que se encuentran dentro del rango de fechas dado para cada caso. Consulta el siguiente código de ejemplo.

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"
)

Nota:

En el ejemplo anterior, el filtro Weekday = 'Yes' se utiliza para no restar días festivos cuando el día festivo es un sábado o un domingo. Esto ya se ha solucionado en la función diff_weekday .

5. Resta el número calculado de días festivos del número total de días calculados para cada caso. Consulta el siguiente código de ejemplo.

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"
)

Hacer que el tiempo de procesamiento esté disponible como campo de caso

Una vez creada la tabla de tiempo de procesamiento, esta tabla debe unirse a la tabla Casos para añadir los datos de tiempo de procesamiento adicionales como información del caso. Para tener el nuevo campo de tiempo de procesamiento disponible en los paneles, es necesario convertir el nuevo campo de tiempo de procesamiento a uno de los campos de duración del caso personalizados.

Reemplaza una de las líneas de duración de casos personalizados en la tabla Casos que se ve así:

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

con el tiempo de procesamiento recién creado:

Cases_with_throughput_times."Throughput_time_activity_A_to_activity_B" as "custom_case_duration_1",

Las actualizaciones de las transformaciones para la métrica de tiempo de procesamiento personalizada están listas y se pueden importar a la plantilla de la aplicación.

Habilitar la métrica de tiempo de procesamiento en los paneles de la aplicación de proceso

Cuando creas un tiempo de rendimiento personalizado en tus transformaciones, está disponible en tu plantilla de aplicación como propiedad de caso bajo su alias. Puedes personalizar tu aplicación de proceso para crear una métrica de tiempo de rendimiento en función del tiempo de rendimiento personalizado que creaste en las transformaciones.

Nota:

De forma predeterminada, se añade un nuevo campo de duración personalizado como campo de tipo numérico. Asegúrate de editar el campo y cambiar el Tipo del nuevo campo a duración. Consulta también Gestor de datos.

• Dirígete a Data Manager y crea una nueva métrica.
• Selecciona el campo de duración personalizado que se utilizará para el tiempo de procesamiento y selecciona Promedio o cualquier otra agregación deseada. También puedes cambiar el nombre del campo de duración del caso personalizado al nombre deseado en el Gestor de datos.
• Edita la aplicación y coloca la nueva métrica en los gráficos donde quieras que esté disponible para los usuarios empresariales.
• Publica los paneles para que la métrica de tiempo de procesamiento esté disponible en los paneles.

Nota:

En las plantillas de la aplicación Purchase-to-Pay y Order-to-Cash , ya está disponible un cálculo del tiempo de procesamiento en Purchase_order_items_with_throput_pieces y Sales_order_items_with_throput_pieces, respectivamente. Los tiempos de procesamiento personalizados se pueden agregar allí y luego estar disponibles como una duración personalizada en Purchase_order_items o Sales_order_items.

SQL differences between Snowflake and SQL Server

SQL Server vs. Snowflake

En un entorno de desarrollo local, las transformaciones se ejecutan en SQL Server, mientras que Snowflake se utiliza en Process Mining Automation Suite. Aunque la mayoría de las sentencias SQL funcionarán tanto en SQL Server como en Snowflake, puede haber ligeras diferencias en la sintaxis, lo que puede dar lugar a resultados de retorno diferentes.

Para escribir instrucciones SQL que funcionen en ambos sistemas de bases de datos:

• Escriba los nombres de los campos entre comillas dobles, por ejemplo Table."Field".
• Evite el uso de funciones SQL que son diferentes en Snowflake y SQL Server, por ejemplo, string_agg() y listagg().
  El paquete pm_utils viene con un conjunto de funciones que funcionan en ambos tipos de bases de datos, consulta Varias bases de datos. Por ejemplo, en lugar de usar string_agg() o listagg(), el pm_utils.string_agg() dará como resultado el mismo comportamiento para ambas bases de datos. Si pm_utils no contiene la función deseada, entonces se debe crear una instrucción Jinja para asegurarse de que se llama a la función correcta en cada base de datos.

Concatenación de cadenas

Para combinar en cadenas, usa la función pm_utils.concat() . Esto producirá los mismos resultados tanto para SQL Server como para Snowflake.

Ejemplo: pm_utils.concat("This is a nice string", null) = "This is a nice string" La concatenación de cadenas no debe realizarse con operadores como + o ||, ya que son diferentes para ambas bases de datos (Snowflake usa || y SQL Server usa +). Además, la función concat() estándar tiene un comportamiento diferente en ambos sistemas:

Servidor SQL	Snowflake
Los valoresnull se ignorarán y se tratarán como una cadena vacía.	Los valoresnull harán que el resultado completo sea null.

Clasificación

La clasificación se gestiona de forma diferente en Snowflake y en el servidor SQL.

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

Valores nulos

Servidor SQL	Snowflake
null se ordenará de forma predeterminada (ascendente)	null se ordenarán por defecto en último lugar (ascendente)

Handling capital letters

Servidor SQL	Snowflake
las mayúsculas se ordenan como se esperaba (AaBbCc)	primero ordena por mayúsculas, luego por no mayúsculas (ABCabc)

Barras

Ejemplo: -Accountant-

Servidor SQL	Snowflake
los guiones se ignoran al ordenar (por lo que '-Contador-' se trata igual que 'Contador')	los guiones se ordenarán en la parte superior

Manejo de espacios en blanco

Cuando se agrupan por valores "A" y "A", esto se ve como un valor en SQL Server, pero como dos valores diferentes en Snowflake. Por lo tanto, se recomienda recortar si sus datos pueden causar este problema.

Distinguir mayúsculas y minúsculas

De forma predeterminada, SQL Server no distingue entre mayúsculas y minúsculas, mientras que Snowflake distingue entre mayúsculas y minúsculas. Esto significa que Table."Field" = "Some_value" y Table."Field" = "SOME_VALUE" devolverán el mismo conjunto de resultados en SQL Server, pero potencialmente dos conjuntos de resultados diferentes en Snowflake.

Se le recomienda cambiar el comportamiento de su base de datos local de SQL Server para que coincida con el comportamiento de Snowflake, a fin de evitar cualquier problema. Esto se puede lograr estableciendo la colación de la base de datos en un valor que distinga entre mayúsculas y minúsculas.

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.

Al crear una nueva aplicación de proceso, asegúrate siempre de que los datos de entrada están en el formato necesario para la plantilla de aplicación que utilizas con el fin de crear una nueva aplicación. Consulta Plantillas de aplicación.

Importante:

Las nuevas aplicaciones de proceso se aplicarán al nuevo modelo de datos de forma predeterminada. Las aplicaciones de proceso existentes seguirán funcionando en Process Mining 2023.4 y Process Mining 2023.10. Cambiar la configuración de carga de datos de sus aplicaciones de proceso antes de Process Mining 2024.4, para asegurarse de que la carga de datos sigue funcionando correctamente. La configuración de AddRawTablePostFix y StripeSpecialCharacter son temporales y se eliminarán en Process Mining 2024.4. A partir de entonces, todas las aplicaciones de proceso funcionarán como si estos ajustes estuvieran establecidos en falso.

Configuración	Formato	Descripción
AñadirPostfijoDeTablaDeDatos	Booleano	Por añadir un sufijo _raw a sus tablas de origen cuando utiliza la carga de archivos a través de la opción Cargar datos . Por ejemplo, si el archivo que carga se llama Event_log.csv , cambiará a Event_log_raw.csv si esta configuración está establecida en verdadero.
EliminarCaracteresEspeciales	Booleano	Para eliminar caracteres especiales y reemplazar espacios por guiones bajos en los nombres de tablas y / o campos. Por ejemplo, un campo llamado Evento + fin cambia a Eventend.

Usar aplicaciones de proceso existentes con la nueva configuración del modelo de datos

Sigue estos pasos para usar tus aplicaciones de proceso existentes con la configuración del nuevo modelo de datos.

1. Download the settings.json.zip and unzip the file.

2. Exporta las transformaciones de tu app de proceso. Consulta Editar transformaciones de datos en un entorno local.

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

4. Asegúrese de que tanto AddRawTablePost corrigir como EliminarCaracteresEspeciales estén establecidos en falso.

5. Cambie sus archivos de entrada, o transformaciones, de manera que los nombres de archivo coincidan exactamente. Por ejemplo, si tus transformaciones de entrada esperan event_log_raw , tu archivo csv también debe llamarse event_log_raw.csv.

6. Si usas caracteres especiales en los nombres de tablas o campos (por ejemplo, "", "(" o "?), Asegúrate de que las transformaciones de entrada usan el mismo nombre. Por ejemplo, una categoría de actividad de campo se debe denominar categoría de actividad en tus consultas y no categoría_actividad.

7. Importar transformaciones e ingerir nuevos datos.

Las transformaciones se ejecutarán de nuevo en la plataforma y las tablas de origen se cambiarán en consecuencia.

Proyectos Dbt

Las transformaciones de datos se utilizan para transformar los datos de entrada en datos adecuados para Process Mining. Las transformaciones en Process Mining se escriben como proyectos dbt .

Esta página le ofrece una introducción a dbt. Para obtener información más detallada, consulta la documentación oficial dela base de datos.

pm-utils package

Las plantillas de la aplicación Process Mining vienen con un paquete dbt llamado pm_utils. Este paquete pm-utils contiene funciones de utilidad y macros para proyectos dbt de Process Mining. Para obtener más información sobre pm_utils , consulta ProcessMining-pm-utils.

Actualizar la versión de pm-utils utilizada para la plantilla de su aplicación

UiPath® mejora constantemente el paquete pm-utils añadiendo nuevas funciones.

Cuando se lanza una nueva versión del paquete pm-utils , se recomienda actualizar la versión utilizada en tus transformaciones, para asegurarte de que utilizas las últimas funciones y macros del paquete pm-utils .

Encontrarás el número de versión de la última versión del paquete pm-utils en el panel Versiones de ProcessMining-pm-utils.

Siga estos pasos para actualizar la versión pm-utils en sus transformaciones.

1. Descarga el código fuente (zip) de la versión de pm-utils.
2. Extrae el archivo zip y cámbiale el nombre a la carpeta pm_utils.

3. Exporta las transformaciones desde el editor de transformaciones de datos en línea y extrae los archivos.

4. Reemplaza la carpeta pm_utils de las transformaciones exportadas con la nueva carpeta pm_utils .

5. Vuelve a comprimir el contenido de las transformaciones e impórtalo en el editor de Transformaciones de datos .