Editing transformations

Estructura de la carpeta

The transformations of a process app consist of a dbt project. Below is a description of the contents of a dbt project folder.

Carpeta/Archivo	Contiene
dbt_packages\	el paquete pm_utils y sus macros.
logs\	logs created when running dbt.
macros\	macros personalizadas.
models\	.sql archivos que definen las transformaciones.
models\schema\	.yml archivos que definen pruebas en los datos.
seed	.csv archivos con los 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_objects:
• 3_events:
• 4_event_logs:
• 5_business_logic.

Consulta Estructura de las transformaciones.

The .sql files are written in Jinja SQL, which allows you to insert Jinja statements inside plain SQL queries. When dbt runs all .sql files, each .sql file results in a new view or table in the database.

Normalmente, los archivos .sql tienen la siguiente estructura:

1. Con declaraciones: una o más declaraciones con para incluir las subtablas 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 la realización de subselecciones durante la depuración.

   

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

Añadir tablas de origen

To add a new source table to the dbt project, it must be listed in models\schema\sources.yml. This way, other models can refer to it by using {{ source(var("schema_sources"), 'My_table_raw') }}. See the illustration below for an example.

Importante:

Each new source table must be listed in 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 en Fuentes.

Salida de datos

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 las macros de Jinja.

pm_utils

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

La siguiente ilustración 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 utiliza normalmente para facilitar la configuración de las asignaciones en tus transformaciones.

After editing seed files, these files are not automatically updated in the database immediately. To instruct dbt to load the new seed file contents into the database, run either

• 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:

  If the seed file had no data records initially, the data types in the database might not have been set correctly. To fix this, call run dbt seed --full-refresh. This will also update the set of columns in the database.

Activity configuration

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

Pruebas

La carpeta models\schema\ contiene un conjunto de archivos .yml que definen pruebas. Estos 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:

When you edit transformations, make sure to update the tests accordingly. The tests can be removed if desired.

Métricas personalizadas de tiempo de procesamiento

Introducción

Con la personalización de las transformaciones de datos y la edición del panel, puedes crear y utilizar métricas de tiempo de rendimiento personalizadas. Los tiempos de procesamiento son los tiempos entre dos actividades A y B. Las siguientes secciones 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 debes calcular el tiempo de procesamiento y luego ponerlo a disposición como un campo Caso.

Calcular el tiempo de procesamiento

Por caso, puedes calcular los tiempos de procesamiento 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. Crea un modelo adicional basado en el registro de eventos para calcular los tiempos de rendimiento deseados. Por ejemplo, Casos_con_rendimiento_veces.

2. En este modelo, crea tablas de preprocesamiento en las que defines qué finales de evento quieres utilizar para los cálculos. Por tabla, necesitas el ID de caso y el final del evento de una actividad. El siguiente código muestra un ejemplo de cómo seleccionar la última repetició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 repetición de la actividad, reemplaza max por min.

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

   Consejo:

   Puedes utilizar la función dateiff proporcionada en el paquete pm-utils para calcular la diferencia de tiempo entre dos finales de evento cualesquiera.

   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 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 el mínimo de agregación. La tabla de tiempo de procesamiento, seleccionando el tiempo de procesamiento y un ID de caso, se puede definir como se muestra en el siguiente bloque de código.

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

Calcular el tiempo de procesamiento en días excluyendo 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.

El siguiente ejemplo de código muestra 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 estos 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 inicial 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 incluir fines de semana utilizando las funciones date_from_timestamp y diff_weekdays proporcionadas en el paquete pm-utils como se describe anteriormente en Calcular el tiempo de procesamiento en días sin incluir 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. El siguiente código muestra un 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 vacaciones del número total de días calculados para cada caso. El siguiente código muestra un 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 que el nuevo campo de tiempo de procesamiento esté disponible en los paneles, es necesario convertir el nuevo campo de tiempo de procesamiento en uno de los campos de duración del caso personalizados.

Reemplaza una de las líneas de duración del caso personalizado 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 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 por el nombre que desees en Data Manager.
• 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 aplicación Purchase-to-Pay y Order-to-Cash ya está disponible un cálculo del tiempo de procesamiento en Purchase_order_items_with_throughput_times y Sales_order_items_with_throughput_times, respectivamente. Los tiempos de procesamiento personalizados pueden añadirse allí y luego estar disponibles como una duración personalizada en Purchase_order_items o Sales_order_items.

Diferencias de SQL entre Snowflake y SQL Server

SQL Server frente a Snowflake

En un entorno de desarrollo local, las transformaciones se ejecutan en SQL Server, mientras que Snowflake se utiliza en Process Mining Automation Cloud. Aunque la mayoría de las instrucciones 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 utilizar string_agg() o listagg(), 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
null serán ignorados y tratados como una cadena vacía.	null valores harán que todo el resultado 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án por defecto en primer lugar (ascendente)	null se ordenarán por defecto en último lugar (ascendente)

Gestionar mayúsculas

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

El archivo settings.json contiene ajustes relacionados con la carga de datos de entrada. Estos ajustes son temporales y deben utilizarse para cambiar las aplicaciones de proceso existentes (creadas antes de marzo de 2023) al nuevo comportamiento de carga de datos. No debes cambiar el archivo settings.json para las nuevas aplicaciones de proceso.

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. Cambie 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. Las configuraciones AddRawTablePostfix y StripSpecialCharacters son temporales y se eliminarán en Process Mining 2024.4. A partir de ese momento, todas las aplicaciones de proceso funcionarán como si esta configuración se hubiera establecido como falsa.

Configuración	Formato	Descripción
AñadirPostfijoDeTablaDeDatos	Booleano	Para añadir un sufijo _raw a tus tablas de origen al utilizar cargas de archivos a través de la opción Cargar datos . Por ejemplo, si el archivo que cargas se llama Event_log.csv, cambia a Event_log_raw.csv si esta configuración se establece en true.
EliminarCaracteresEspeciales	Booleano	Para eliminar caracteres especiales y reemplazar espacios con guiones bajos en nombres de tablas y/o nombres de campos. Por ejemplo, un campo llamado Evento+final 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. Descarga settings.json.zip y descomprime el archivo .
2. Exporta las transformaciones de tu aplicación de proceso.
3. Añade el archivo settings.json (si no está ya presente) a las transformaciones.
4. Asegúrate de que tanto AddRawTablePostfix como StripSpecialCharacters estén establecidos en falso.
5. Cambia tus archivos de entrada, o transformaciones, para que los nombres de los archivos coincidan exactamente. Por ejemplo, si tus transformaciones de entrada esperan event_log_raw, entonces tu archivo csv también debería llamarse event_log_raw.csv.
6. Si utilizas caracteres especiales en los nombres de las tablas o de los campos (por ejemplo, ' ', '(' o '?'), asegúrate de que las transformaciones de entrada utilizan el mismo nombre. Por ejemplo, un campo Categoría de actividad debe denominarse Categoría de actividad en tus consultas y no Categoría_actividad.
7. Importar transformaciones y cargar 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 ofrece una introducción a dbt. Para obtener información más detallada, consulta la documentación oficial de dbt.

pm-utils package

Las plantillas de aplicación de 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 Transformaciones de datos .