Este artículo es el primero de una serie en la que escribiré sobre el Event Framework de Dataverse. Hay muchas maneras diferentes de implementar lógica de negocio en Power Platform y, por regla general, siempre intentaremos favorecer el enfoque más Low-Code posible. Por lo tanto, la decisión natural suele ser usar Power Automate, pero hay muchas otras opciones no consideradas habitualmente que pueden ayudarle a crear una solución con una arquitectura más modular.
En este post, intentaré explicar (con un caso de uso) el enfoque Low Code para aprovecharse del Event Framework.
¿Qué es el Event Framework y por qué debería importarme?
En el caso de trabajar con Dataverse, los makers normalmente crean automatizaciones usando los triggers out-of-the-box: crear / eliminar / modificar / actualizar. Estos triggers que nos permite usar el sistema son lo que llamamos "verbs" (verbos), y tú puedes crear tus propios verbos también.
Y esto, ¿pa qué? Pues crear nuestros propios verbs nos va a permitir crear una lógica de negocio más desacoplada. Imaginemos el ejemplo:
Why would this be useful? Well, it allows us to create our own business logic in a more decoupled manner. Let's imagine the example:
Tenemos una tabla de Facturas, y queremos lanzar un proceso de aprobación cuando la factura está "revisada" (Status Reason) y se cumplen ciertas condiciones.
Estas condiciones checkean valores de columnas como "importe", "fecha", o incluso valores de una Lookup column (como "proveedor").
En funcón de las condiciones que se cumplan, se ejecutará una lógica de negocio que acabará mandando un Approvals
El maker habitual trataría de definir todas esas condiciones en el trigger o tal vez las intentará separar de la lógica de nogocio mediante un child flow (lo que no funciona muy bien con la ALM). ¿Y qué pasa cuando hay que cambiar condiciones? Esto puede forzarnos a realizar bastantes cambios a nivel de flow.
¿Y si puediéramos agrupar toda esa lógica en un trigger que fuera "Cuando una factura necesita ser revisada"? Pues aquí es precisamente cuando crear nuestro propio evento tiene sentido.
¿Cómo funciona?
Básicamente, toda operación que ocurre en Dataverse va a disparar un evento. Piensa en ellos como eventos "primitivos": Create, Retrieve, RetrieveMultiple, Update, Delete, Associate and Disassociate.
Puedes registrar tu propia lógica (step) en estos stages de cada uno de esos eventos "primitivos". Usemos el evento Create como ejemplo:
PreValidation: aquí es cuando se validan las columnas antes de crear la fila. Aquí puede añadir sus propias validaciones y cancelar la operación.
PreOperation: justo antes de que se cree el registro (ya estamos "dentro" de la transacción de la base de datos). Puedes cambiar los valores aquí, pero no es recomendable cancelar la operación (afectará al rendimiento).
MainOperation: se crea el registro. No podemos añadir nuestra propia lógica aquí (salvo algunas excepciones).
PostOperation: justo después de crear el registro. Aquí es cuando se disparan los Power Automate flows.
Puedes leer una explicación mucho mejor y más compeleta en: Event Framework (Microsoft Dataverse) - Power Apps | Microsoft Learn
Nota: Nota: si tienes conocimientos de JavaScript, puede que estés familiarizado con el bonito Event Loop de Node.js. Eso puede ayudarte a entender cómo funciona esta arquitectura basada en eventos. Sin embargo, ten en cuenta que el core de Dataverse está construido sobre SQL Server, por lo que puedes aprovechar los eventos síncronos también (lo cual es MUCHA responsabilidad, ya que puedes arruinar el rendimiento de TODO un entorno).
El enfoque Low-Code: utilizar una Custom Action para crear su propio mensaje
Esto no es una guía paso a paso, ya que ese trabajo ya está hecho en la documentación: Create a custom process action - Power Apps | Microsoft Learn, pero te proporcionaré algunas capturas de pantalla que puedes seguir:
¿Qué componentes necesitamos?
Siguiendo el escenario, que he descrito anteriormente, necesitaremos:
Un workflow síncrono que "disparará" nuestra Acción Personalizada cuando se cumplan ciertas condiciones. Poniendo algunos nombres aquí: enviará nuestro "custom message" (mensaje personalizado) para que sea escuchado por quien quiera dentro del entorno Power Platform.
2. La propia Custom Action. Definimos el mensaje personalizado cuando configuramos nuestra Custom Action.
3. Un Power Automate cloud flow que ejecutará la lógica de negocio y se activará cuando se envíe el "custom message"..
El orden recomendado es el 2-1-3, ya que necesitarás definir la Custom Action antes de configurar el Workflow síncrono.
2. La Custom Action
Queremos definir un mensaje que nos diga claramente "La factura ya ha sido revisada". Por lo tanto, poner un nombre que siga teniendo sentido para nostros en 2 meses. Luego, basta con añadir un parámetro de entrada: la referencia a la factura (la fila de Dataverse).
1. El Workflow síncrono
Configúralo para que sólo se active cuando cambie el Status Reason, comprueba que está en estado "Review" y, finalmente, que se ejecute la Custom Action.
3. El Power Automate cloud flow
Usaremos el trigger "When an action is performed" (Microsoft Dataverse - Connectors | Microsoft Learn), y luego el resto ya es construir el flow que tenga sentido para tu lógica de negocio.
Nota: Debido a la forma en que hemos configurado la acción personalizada, sólo recibiremos la referencia al registro (el GUID). Por lo tanto, asegúrese de recuperar el registro si necesitas trabajar con otras columnas.
¿Desde dónde más podemos ejectuar una Custom Action?
Hay muchas formas de activar su Acción Personalizada. Éstas son las principales:
Un Power Automate cloud flow (la acción "perform a bound/unbound").
Mediante Power Apps (desde February 2023 😀 Call Dataverse actions directly in Power Fx | Microsoft Power Apps).
Mediante JavaScript customizando un Form. E.g.,
let serverURL = Xrm.Page.context.getClientUrl();
let actionName = "abg_IncomingInvoiceIsReviewed";
fetch(`${serverURL }/api/data/v9.2/${actionName}` ,
{
method: "POST",
headers: {
"Accept": "application/json",
"Content-Type": "application/json;charset=utf-8",
"OData-MaxVersion": "4.0",
"OData-Version": "4.0"
},
body: JSON.stringify({
"IncomingInvoiceReference": {
"abg_incominginvoiceid": "xxxxxxxxxx-xxxx-xxxx-xxxx-002248081d18"
}
})
}
).then((res) => {console.log(res))
.catch(err => console.error(err))
Invocándolo mediante la Dataverse Web API.
Comentarios finales
Espero haber podido explicarte cómo funcionan las Custom Actions. Y, lo que es más importante, por qué es muy útil tenerlas en tu caja de herramientas.
En la próxima entrada del blog, intentaré mostrarte una forma diferente de añadir lógica de negocio a tu solución basada en Power Platform.
Gracias por leerme y haber llegado hasta aquí. Por favor, déjame saber tus impresiones en los comentarios de abajo.
Saludos,
Andrés
Comments