Determinar cuándo configurar o cuándo codificar

6 minutos

Como desarrollador, debe plantearse las aplicaciones en Microsoft Power Platform desde la perspectiva de que la escritura de código para lograr la funcionalidad deseada de la aplicación empresarial debe considerarse una excepción a los enfoques sin código y con poco código. Sin embargo, las áreas de calidad como el mantenimiento, la capacidad de actualización, la estabilidad y el rendimiento también deben tenerse en cuenta cuando se determina cuál es el mejor enfoque para un escenario determinado.

Es importante saber lo que puede hacer Microsoft Power Platform de forma preconfigurada para evitar crear algún proceso que ya incorpora y que solo necesita configurarse. Esto también se aplica a la funcionalidad implementada en las aplicaciones de Dynamics 365 disponibles. Por ejemplo, los cálculos de facturas con listas de precios variables en diversas divisas son complejos, pero están bien implementados y probados en Dynamics 365 Sales. Si se requiere esta funcionalidad, debería considerar usar las funcionalidades integradas de Dynamics 365 Sales en lugar de implementar su propio motor de cálculo.

También debe identificar que Microsoft Power Platform a menudo implementa algo de una manera particular que beneficia a la plataforma. Esto puede ser diferente si está acostumbrado a utilizar código de aplicación personalizado. No es raro que los desarrolladores que son nuevos en la creación de soluciones de Microsoft Power Platform intenten personalizar la plataforma con los mismos procesos que solían utilizar para crear aplicaciones personalizadas anteriormente. Esto debe evitarse cuando sea posible y debe intentar aprovechar lo que la plataforma hace bien, en lugar de intentar cambiarlo a lo que está acostumbrado a hacer. Por ejemplo, es posible que en el pasado haya implementado la seguridad de nivel de columna mediante código personalizado. Sin embargo, esto no es necesario en Dataverse, donde la seguridad de nivel de columna es una característica lista para usar y simplemente necesita configurarse.

Reglas de negocio frente a scripts de clientes

La ventaja de las reglas de negocio es que resultan fáciles de entender e implementar para quienes no son desarrolladores, y pueden incluirse como parte de una solución de Dataverse para su implementación en producción. En las organizaciones donde las capacidades de desarrollador no suelen estar disponibles y la administración del ciclo de vida de las aplicaciones no está implementada, las reglas de negocio representan la mejor opción a la hora de implementar la lógica incluso si se requieren algunas alternativas, por ejemplo, campos calculados intermedios que contienen los valores para verificar una regla.

Sin embargo, habrá ocasiones en las que reglas de negocio no podrán implementar los requisitos de negocio o, tal vez, que la complejidad de las reglas haga que los desarrolladores prefieran escribir la lógica en el script del cliente. Un escenario podría ser la lógica compleja anidada "if/then/else" que se desarrollaría mejor en una instrucción switch o una secuencia simple de bloques if. El otro escenario es cuando hay valores dinámicos a los que no se puede acceder fácilmente mediante una regla de negocio. Por ejemplo, las notificaciones de formulario y el filtrado de valores de conjunto de opciones no están disponibles a través de las reglas de negocio.

Flujos de trabajo/flujos de Power Automate frente a complementos

Dataverse ofrece varios métodos para implementar la lógica para responder a eventos del sistema, en particular a los cambios de datos tales como crear, actualizar y borrar las filas de datos. Los requisitos de negocio pueden satisfacerse con soluciones sin código que utilizan flujos de trabajo y Power Automate y extendiendo Dataverse mediante código del lado del servidor (complementos) o del lado del cliente (scripts).

Puede evaluar las opciones utilizando un enfoque similar al utilizado en la discusión de reglas de negocio frente a scripts de cliente: evalúe los requisitos de negocio y las capacidades de la organización para implementarlos. También existen algunas diferencias fundamentales en las capacidades. La siguiente tabla puede ayudarle a determinar cuándo sería mejor usar un enfoque u otro.

Funcionalidad	Flujo de Power Automate	Flujo de trabajo	Complemento
Sincrónico o asincrónico	Asincrónico	Cualquiera (se recomiendan flujos de Power Automate en lugar de flujos de trabajo asincrónicos)	Cualquiera
Acceder a datos externos	Sí, mediante conectores	No	Sí, usando API, algunas restricciones de seguridad
Mantenimiento	Creadores	Usuarios empresariales	Desarrolladores
Puede ejecutarse como	Usuario actual o propietario del flujo	Usuario actual o propietario del flujo de trabajo	Cualquier usuario con licencia, del sistema o el usuario actual
Se puede ejecutar a petición	Sí	Sí	No
Puede anidar procesos secundarios	Sí	Sí	Sí
Fase de ejecución	Después	Antes/después	Antes/después
Desencadenadores	Crear, cambiar de columna, eliminar, a petición, programado	Crear, cambiar de columna, eliminar, a petición	Crear, cambiar de columna, eliminar, otros mensajes, incluidos los personalizados

Microsoft Power Platform evoluciona continuamente y, como desarrollador, debe estar al tanto de las funciones nuevas y futuras. Por ejemplo, si su solución requería valores de configuración o valores personalizados, anteriormente habría tenido que usar tablas personalizadas para almacenar estos valores y luego usar código personalizado o herramientas de plataforma para implementar los datos. La nueva adición de variables de entorno simplificó esta tarea y la redujo a declarar sus variables, incluirlas como parte de las soluciones y establecer los valores, todo sin ningún código.

Power Apps Component Framework (PCF)

Durante muchos años, los recursos web HTML solían ser un mecanismo de extensibilidad para el lado del cliente en aplicaciones basadas en modelos. Uno de los puntos débiles de este enfoque fue la baja reutilización de estos elementos monolíticos y no extensibles. Ahora controles de PCF han reemplazado a los recursos web HTML.

PCF permite a los desarrolladores crear componentes reutilizables a los que los fabricantes pueden recurrir en lugar de los controles estándar. Este es un buen ejemplo de cuándo los avances en las capacidades de la plataforma permiten a las empresas enfocar sus esfuerzos de desarrollo en crear una infraestructura sólida y capacitar a los creadores de aplicaciones.

Sistemas externos

Las comunicaciones con sistemas externos son una característica común de las implementaciones de la solución. Desde tareas simples, como enviar un mensaje SMS o actualizar los tipos de cambio de divisa, hasta escenarios complejos de sincronización de datos, solía ser un dominio exclusivo para desarrolladores. Las implementaciones utilizaban complementos, publicación de eventos a través de puntos de conexión de servicio y webhooks.

Sin embargo, con la adopción de Power Automate, con sus cientos de conectores, los creadores de aplicaciones ahora pueden implementar las interacciones con sistemas externos sin usar ningún código.

No obstante, esto no significa que el rol del desarrollador esté de más. Hay muchos escenarios complejos o de alto rendimiento en los que se requiere código. Además, los desarrolladores ahora pueden concentrar sus esfuerzos en la creación de servicios y conectores personalizados mientras delegan la conexión de los bloques de creación a los fabricantes.

Portales frente a sitios personalizados

Power Pages proporcionan numerosas funciones listas para usar y permiten a los fabricantes crear sitios web eficaces y ampliarlos según sea necesario. Los desarrolladores a menudo ayudan con tareas de portal más desafiantes, como diseños de página sofisticados (utilizando el lenguaje de plantillas Liquid) o ampliar la funcionalidad del sitio de front-end utilizando JavaScript.

Para escenarios altamente especializados, puede decidir crear un portal personalizado completo utilizando ASP.NET o tecnologías similares. Este enfoque no es infrecuente, pero requiere de desarrolladores altamente capacitados para implementarlo. Una vez más, la decisión suele ser un compromiso entre una implementación sin código de la funcionalidad estándar, pero generalizada, y el uso controlado de los recursos del desarrollador para ofrecer funciones especializadas.

Decidir cuándo usar el código no es una simple decisión binaria. Debe tener en cuenta muchos factores: qué habilidades y recursos tiene disponibles, el grado de madurez de su organización en lo que respecta a la administración del ciclo de vida de las aplicaciones, lo complejos que son los requisitos, etc. A menudo, los requisitos deben evaluarse en caso por caso, porque un pequeño compromiso en las limitaciones comerciales puede simplificar la solución y reducirla de un proyecto de desarrollo complejo a un simple ejercicio de configuración.