En la Power Platform, existen tres tipos principales de aplicaciones que podemos crear: Model-Driven Apps, Canvas Apps y Power Pages. Cada una tiene sus características particulares y está diseñada para diferentes escenarios de uso. En este artículo, te explicaré las diferencias entre estas herramientas y cuándo deberías elegir una sobre la otra.
¿Qué es una Model-Driven App, una Canvas App y un Power Page?
Para comenzar, es importante que tengamos claro qué es cada tipo de aplicación. Esto te ayudará a visualizar mejor cuándo es adecuado usar una sobre la otra.
En este post, te enseñaré cómo recibir notificaciones en tiempo real mientras utilizas tu aplicación en Model Driven. Esto es especialmente útil cuando trabajamos con Dynamics CRM (Customer Engagement), ya que es común encontrarse con procesos que se ejecutan en segundo plano y que pueden tardar mucho tiempo en completarse. Es esencial proporcionar feedback al usuario de que el proceso ha finalizado.
El tipo de dato «Money» en Dynamics 365 CRM, que es parte del ecosistema de Dataverse (por lo tanto, este artículo es valido tanto para Dynamics 365 CE como para Power Platform), ofrece una manera especializada de gestionar valores monetarios dentro de la plataforma. Esta especialización permite que las aplicaciones que dependen de Dataverse, manejen cantidades de dinero de manera consistente y precisa, teniendo en cuenta aspectos como los tipos de cambio y la precisión decimal necesaria para operaciones financieras.
La elección entre usar el tipo «Money» y el tipo «Decimal» en Dynamics 365 CRM o Microsoft Dataverse depende de las necesidades específicas de tu aplicación o solución y de la naturaleza de los datos que estás manejando. Ambos tipos ofrecen precisión decimal, pero tienen características y usos óptimos diferentes. Aquí hay algunas consideraciones para ayudarte a decidir.
Los usuarios de aplicación, también conocidos como identidades de servicio o cuentas de servicio, son un tipo de cuenta utilizada en entornos de software y plataformas en la nube para permitir que las aplicaciones y scripts se autentiquen y realicen acciones de manera automática. Estas cuentas son diferentes de las cuentas de usuario tradicionales que están diseñadas para individuos. Aquí están los aspectos clave que definen a un usuario de aplicación:
En esta entrada vamos a ver como crear un formulario de creación rápida (o Quick Forms en ingles). Lo que vamos a ver es valido para las aplicaciones basadas en modelo, por lo tanto, servirá para una Model Driven de Power Platform o para Dynamics 365 CE (aka CRM).
Los formularios de creación rápida (como su nombre indica) son un formulario básico que nos permite crear un registro de una entidad determinada. Por ejemplo, en la siguiente imagen se puede ver como se ven los formularios de creación rápida, con datos obligatorios de la entidad, y donde podemos trabajar sin necesidad de navegar a otra pantalla.
Por fin velocidad en Dataverse gracias a Dataverse elastic tables.
Si has trabajado con Dataverse, ya sea con Power Platform o con Dynamics 365 te habrás dado cuenta que ofrece muchas cosas buenas, pero que la velocidad no sería una de ellas. Sobre todo si lo comparas con otras bases de datos. Vale, no es exactamente lo mismo, Dataverse es mas que simplemente persistir datos, pero a veces necesitas un poco de «chicha». En la operativa diaria de la aplicación no se nota tanto, pero cuando tenemos que hacer cargas de datos o trabajar con una volumetría alta donde has de responder en tiempos bajos, las velocidades que ofrece Dataverse nos hace sufrir como desarrolladores.
El otro día leí un artículo del compañero @jmfloreszazo sobre un tema muy interesante a la par que importante: la sostenibilidad. Así que ni corto ni perezoso, me he puesto a profundizar mas en el tema y os aseguro que ya no voy a parar 😊. Entre otras cosas, hice una formación on-line y totalmente gratuita sobre Green Software (también me animo el José Maria) que ha terminado con su correspondiente certificación. Si te interesa el tema, visita este enlace para la formación sobre y este otro para el examen.
Además de ser algo muy importante para todos, la sostenibilidad se esta convirtiendo a pasos agigantados en un tema prioritario para las grandes empresas, dándole muchísima importancia. Es por eso, que quisiera comentaros en este post dos puntos que me han parecido muy interesantes y que nos pueden ayudar muy rápidamente a ser mas sostenibles desde el punto de vista de la creación de software, que es de lo que solemos hablar en este blog. Y para esto, la adopción del cloud nos va a ayudar muchísimo.
Power Pages es uno de los diversos componentes de la Power Platform, en concreto es el que nos permite crear páginas web desde un entorno de No-Code o Low-Code.
He de decir que en el pasado me toco trabajar con Portals, que era la herramienta que te proporcionaba Dynamics365 CE para crear portales de comunicación con tu CRM, por ejemplo para crear una página donde los usuarios externos al CRM pudiesen incluir casos de soporte en Customer Service y la experiencia no fue muy buena, así que cuando he probado Power Pages, me he sorprendido gratamente. Os cuento.
No soy yo muy fan del low code, pero oye, a veces me ha tocado usarlo. No negaré que puede llegar a tener sus ventajas en ciertos contextos y si sabemos ver cuando usarlo y cuando no, puede llegar a ser un buen acelerador. Una de las herramientas que se nos ofrece dentro de Power Platform (la plataforma low code de Microsoft) es Power Automate (antes llamados Flow), que a partir de la configuración de «cajitas» nos permite realizar ciertas acciones.
Una de las cosas con las que nos encontramos a tener que crear un flujo, es como gestionamos los datos cuando uno de los pasos que estamos configurando fallan. Cuando algo no va bien, el flujo se detiene y entrando en la página de gestión puedes ver el log y el histórico de ejecuciones, pero eso no suele ser suficiente.
Para tener un poco mas de control, podemos configurar dentro de la tarea que estamos creando, un comportamiento respecto a la ejecución anterior.
De este modo, podemos definir que la acción solo suceda cuando un estado concreto de la acción anterior se cumpla:
Así pues, podemos definir acciones para cuando la acción haya ido mal, y cuando haya ido bien, creando distintos caminos de comportamiento.
A partir de aquí, puedes realizar las acciones que necesites, como dejar un log en una Table Storage, un mensaje en Insights, un correo, etc…
