Toni, he estado viendo vídeos sobre funcionalidad de Dynamics 365 y también sobre personalización, realmente parece que está bastante bien pensado… Pero cuando he llegado a lo de Reglas de Negocio me he cansado. No entiendo qué sentido tiene utilizar un mecanismo como ese en vez de cacharrear directamente los formularios vía jscript…
Bien, pequeño saltamontes!. Me alegro de que empieces a ver cosas interesantes en el entorno de PowerApps, y la respuesta a tu duda sobre las Reglas de Negocio es fácil de entender. Vamos allá!.
Como sabéis, me gusta contar batallitas de tiempos pretéritos. Sin duda, estas batallitas condensadas en unas pocas líneas ayudan a entender de dónde venimos y adónde vamos…
Pues hace muchos, muchos años… Bueno, bien mirado tampoco hace tantos!!. Digamos que cuando allá por CRM 4.0, el Gran Hacedor dijo a la Comunidad:
En verdad os digo que el futuro Silverligth es. Creer en aquellos que prometen que HTML es la solución no aceptaréis, y si migrar a CRM 2011 sin problemas esperáis olvidar el uso de jscript en vuestras soluciones debéis.
Como éramos gente humilde y creyente, aún a sabiendas de las dificultades que acarreaba formarnos en Silverlight, dando un nuevo paso en nuestra travesía nos formamos y migramos las soluciones, y nos sentimos afortunados por formar parte de una Comunidad dinámica, fresca y ágil. Y nos sentimos orgullosos de nuestro esfuerzo…
Y llegó un día, allá por el año 2012, en que el que percibimos una fuerte perturbación en La Fuerza, coincidiendo con la publicación por parte del Gran Hacedor de una escueta nota de prensa indicando que Microsoft abandonaba Silverlight, deseando larga vida al HTML…
Toni, tus historias me cansan… ¿A cuento de qué ha venido esta batallita?
Muy fácil, pequeño saltamontes. Si en aquel momento hubiese existido algo parecido a las Reglas de Negocio hubiésemos preferido mil veces personalizar el comportamiento de los formularios prescindiendo de la comodidad de jscript (…o la presunta comodidad de Silverlight) a cambio de tener garantizada la migración de versiones…
La moraleja de esta historieta es que cuando trabajamos con la Power Platform debemos entender que la última opción es escribir código, y para ello es imprescindible dominar las capacidades de personalización y extensión a nuestro alcance cuando desarrollemos sobre Common Data Service for Apps.
…muchos serán los llamados, pero pocos los elegidos…
La verdad es que verlos todos es realmente complicado porque son muchos y muy buenos, pero al igual que en el evento en vivo seleccioné aquellos que vi más interesantes para los temas que gestiono en mi día a día desde Sothis, también he seleccionado los que he visto más interesantes del resto de sesiones publicadas, dedicando unas 100 horitas a la labor…
Realmente ha sido un detalle que Microsoft haya publicado en abierto todas las sesiones, en otros eventos sólo se tiene acceso a las sesiones si has asistido al evento, pero en este caso todas las sesiones están disponibles para toda la comunidad. Obviamente, no hay nada como asistir a las sesiones en vivo, ya que la oportunidad de poder hablar con el ponente para plantear dudas o pedir aclaraciones es lo que justifica el esfuerzo en tiempo, coste directo y coste de oportunidad, y más en un evento de estas características.
Comento sólo un par de temas relacionados con la charla, a modo de spoiler, y luego desarrollaré el tema que me ha sugerido el título para este post.
El Summit es nuestro evento, sin lugar a dudas. Por el contenido, por los ponentes, porque se celebra en Seattle, única ciudad del mundo en la que he visto que en el aeropuerto hay un mostrador de facturación exclusivo para empleados de Microsoft… 😊
Es un evento en el que participan como ponentes muchas personas de los equipos de producto de Microsoft, no es casual que se lleve a cabo en Seattle sino que se hace allí para facilitar esta importantísima presencia, que nos permite disponer de acceso directo a interlocutores con los que habitualmente no es fácil conectar.
Se anunció que la próxima edición sería en primavera (…del Hemisferio Norte!!) pero no se precisaron ni las fechas ni la ubicación. Os sugiero que os registréis siguiendo el siguiente enlace para tener información de primera mano de los datos del Summit 2019: https://info.microsoft.com/Business_Applications_Summit_2019_Sign_Up.html
Dicho lo cual, entro en el post propiamente dicho, parte del cual inspira la sesión que tendré el honor de presentar en el Sharepoint Saturday que se llevará a cabo en Barcelona el próximo 27 de Octubre.
239 páginas tiene el documento Microsoft Business Applications October 2018 Release Notes… Sólo 239… Os lo podéis descargar siguiendo el siguiente enlace: https://docs.microsoft.com/en-us/business-applications-release-notes/october18/. Por cierto, los más observadores os habréis dado cuenta de que hasta el nombre del documento ha cambiado, ya no es Dynamics 365 si no Business Applications…
Nada que objetar ni al nombre del documento ni a su contenido, ver cómo aumentan las capacidades de nuestro entorno favorito cuantitativa y cualitativamente no hace más que recordarnos que valió la pena el esfuerzo en las épocas difíciles.
Pero preocupación al planificar acciones y al ver qué está pasando y recordar cosas que ya pasaron antes…
La Power Plattform es el conjunto de tres productos muy importantes estratégicamente para Microsoft: PowerApps, Flow y Power BI. Dentro de su estrategia hay un fuerte componente de difusión orientado fundamentalmente a dar cobertura a su marketing corporativo basado en los dos siguientes mensajes:
Personalice, extienda y cree todas las aplicaciones que necesita con la Microsoft Power Plattform
Permita que todos puedan innovar con una plataforma de aplicaciones conectadas
Una vez más, nada que objetar a estos mensajes, sin duda los comparto. Pero creo que, por si solos, sugieren una ambigüedad que puede causar problemas.
Dejando de lado a Power Bi a los efectos de mis reflexiones, creo que el mensaje lanzado desde marketing puede crear falsas expectativas. Incluso peor que eso, puede provocar que equipos profesionales de desarrollo que aterricen hoy en la Power Plattform cometan el error de empezar a desarrollar ignorando buena parte de las prestaciones que ofrece el framework de desarrollo, tanto a nivel funcional como a nivel de personalización, parametrización y extensión.
La primera oleada de PowerApps implicó la creación del CDM (Common Data Model) y los CDS (Common Data Services). Esta oleada puso sobre la mesa una serie de herramientas y funcionalidades que poco tienen que ver con las de la versión actual.
Imaginemos el siguiente escenario (sé que es bastante absurdo pero será ilustrativo). Nos entregan un vehículo para circular que no necesita ruedas. Nunca antes hemos visto un vehículo así, es algo nuevo, ignoramos como se sustenta en el aire, sabemos que subyace una tecnología compleja pero no necesitamos profundizar, nos basta con saber que funciona. Nos lo entregan en una calle completamente horizontal, sin desniveles.
Estudiamos la documentación y vemos que además del volante y los pedales del acelerador y freno hay una pantalla táctil apagada, y aunque pulsamos sobre ella no ocurre nada. Nos surgen dudas, pero como llevamos toda la vida innovando preparamos algo parecido a un ancla con un peazopiedro y una cadena, para que actúe como un freno de mano. Como vemos que el vehículo sólo avanza hacia delante instalamos un generador eólico en el techo que carga una batería que a su vez alimenta un ventilador que permite que cuando el vehículo está detenido pueda retroceder con tracción viento. Y con esta solución ya tenemos, más o menos, las funcionalidades a las que estamos acostumbrados cuando conducimos. Cierto, hay alguna incomodidad al poner y quitar el freno de mano, la velocidad de arrancada para ir marcha atrás no siempre responde de forma eficiente y la batería hay que sustituirla con frecuencia porque se descarga fácilmente. Pero ya vamos bien…
Lo que ignoramos es que el fabricante no nos ha informado que, por seguridad, bajo al asiento del conductor hay un interruptor que enciende la pantalla táctil, en la que tenemos botones para seleccionar marcha atrás, para bloqueo del vehículo y muchas más funcionalidades.
Algo parecido a esto aplicaría a plantearnos el mundo del desarrollo profesional con PowerApps sin tener en cuenta que hay un interruptor llamado Dynamics 365, que tiene un modelo de datos llamado CDM. Y que dentro de Dynamics 365 tenemos “de serie” una serie de funcionalidades (Procesos de Negocio, Reglas de Negocio, Flujos de Trabajo, etc) que nos permiten hacer desarrollos basados en personalizaciones sostenibles, funcionalmente ricos y preparados para recibir las actualizaciones de la Business Applications Platform a medida que Microsoft las vaya liberando.
Probablemente, prescindiendo de este interruptor, podremos construir soluciones, pero serán ineficientes, pondrán en riesgo la actualización de versión y la usabilidad no será la que se espera…
¿Cómo resolvemos esto? No hay informagia, es necesario conocer la existencia de este interruptor (fácil) y entender el funcionamiento de las funcionalidades que se activan al accionarlo (no tan fácil).
Creo que es tarea de los profesionales evangelizar para evitar situaciones que ya vivimos los que apostamos desde el principio por XRM como framework de desarrollo, cuando la aparente facilidad que ofrecía se transformó en un infierno al ver como el seguimiento de las buenas prácticas brillaba por su ausencia y se escribía código para dar cobertura a necesidades que la propia plataforma ya incluía.
Y lamentablemente, aún hoy me toca ver más a menudo de lo que querría proyectos que se han llevado a cabo en el último año en los que se observa a vista de pájaro que quien lo ha diseñado no conoce la funcionalidad que ofrece la plataforma…
Y hay una segunda derivada, de la cual hablaré en el evento de Octubre. Se trata del impacto de los Power Users, también descritos como Citizen Developers. No estoy inventando nombres ni adjetivos, este nomenclátor es powered by Microsoft…
De momento no veo una solución para esta derivada, pero el tema puede ser más que delicado. No hay que olvidar que los roles de los usuarios serán los mismos cuando esté ejecutando una solución suministrada por un proveedor y cuando esté ejecutando una App propia. Esto quiere decir que deberemos extremar las precauciones a la hora de diseñar el modelo de seguridad de nuestras soluciones, incluso deberemos diseñar procesos que garanticen que un usuario no pueda comprometer la integridad de los datos de nuestra implantación. A modo de ejemplo, si en una entidad requerimos que el valor de un atributo dependa del valor de otro, probablemente nos veremos obligados a aplicar una Regla de Negocio de Entidad para garantizarlo, o un Plugin, o ¿tal vez un Workflow síncrono? ¿Y si el Administrador del Sistema asigna a un usuario un tipo de Licencia de PowerApps que no soporta workflows síncronos?.
Un buen melón se abre ante nosotros, que implica que asumamos el reto en tiempo de diseño si no queremos sufrir las consecuencias de la ejecución de Apps mutantes que no podremos controlar. Hay cosas en las que pensar, ¿no os parece?
Probablemente Microsoft ofrecerá respuestas a estas y otras incógnitas, y la evolución de la Power Platform brindará soluciones a los problemas planteados.
Mientras sigo preparando el siguiente post de la serie CDS 2.0, dedicado a mi amigo Pequeño Saltamontes, os dejo un tráiler de la película que da el título a este post. Y os la recomiendo, meteorológicamente está bien documentada…
