En este artículo se describe un escenario en el que un cliente hipotético con sede en Estados Unidos, Contoso, ha adquirido recientemente otra empresa con sede en Europa y está en proceso de unir los sistemas CRM y ERP de las dos empresas. Como parte de esta integración, deben mantener sincronizadas una parte de sus entidades de Dynamics 365 Dataverse hasta que se puedan integrar completamente. Una aplicación de línea de negocio (LOB) propiedad de Contoso consume datos de ambos sistemas y debe poder aceptar solicitudes si los datos están en espera de la sincronización o si faltan. En la siguiente guía se muestra cómo tener en cuenta la coherencia final entre las instancias de Power Platform.
Architecture
Complemento o flujo para actualizar/insertar (upsert) siempre con el GUID o la clave alternativa
Descargue un archivo Visio de esta arquitectura.
Flujo de trabajo
Esta solución se puede crear con varios pasos de un complemento, dentro del ciclo de vida del complemento. Si la entidad que va a crear es obligatoria, use el paso de validación previa. La validación previa se produce antes de que se inicien las transacciones de base de datos. Esta es la opción preferida si el campo es obligatorio. Sin embargo, en algunos escenarios, un paso del complemento previo a la creación será suficiente.
- La instancia de EE. UU. intenta sincronizar una nueva cuenta en la instancia de Europa mediante una aplicación lógica. La instancia de Europa no es accesible, debido a un tiempo de inactividad o una actualización.
- La aplicación de línea de negocio de Contoso lee las entidades de cuenta principales de la instancia de EE. UU. Intenta enviar una llamada API que hace referencia a una entidad de cuenta que no se ha replicado en la instancia de Europa. Tal como está, se producirá un error en la llamada API, ya que el registro no existe porque la sincronización no funciona.
- Sin embargo, un complemento PreValidation/PreCreate realiza primero una operación upsert basada en el GUID de la entidad y los datos de referencia proporcionados. Si ya existe, no se cambia nada. Si no existe, se crea una cuenta con la mayoría de los campos en blanco.
- La llamada API se realiza correctamente porque la cuenta con el identificador especificado existe en el sistema. El complemento interceptó la operación y controló correctamente el registro que faltaba. El informe de la aplicación de línea de negocio se genera correctamente.
Nota:
Microsoft recomienda introducir un modelo de interruptor en el código personalizado para volver a intentarlo como parte de esta solución para controlar las interrupciones de la plataforma al hacer referencia a cualquiera de las instancias. Para más información sobre el uso de un disyuntor, consulte Patrón de disyuntor.
Alternativas
El escenario que se ha descrito anteriormente usa una aplicación lógica personalizada como método de replicación. Sin embargo, hay varias formas de replicar datos entre instancias de Dataverse, entre las que se incluyen, entre otras:
- Logic Apps
- Aplicaciones de funciones de Azure Functions
- Azure Data Factory
- Azure Synapse Analytics
- Power Automate
Detalles del escenario
En ocasiones, las organizaciones tienen la necesidad de mantener sincronizadas dos o más instancias de Power Platform, más concretamente, normalmente se trata de un subconjunto de entidades de Dataverse. Este requisito puede ocurrir cuando una organización ha agregado intencionadamente nuevas instancias para el aislamiento geográfico, pero necesita un conjunto de datos común en todas las ubicaciones geográficas. O bien, puede ocurrir cuando se fusionan dos organizaciones antes de que se complete la consolidación de Power Platform.
Si el proceso de sincronización funciona según lo diseñado, las aplicaciones de línea de negocio que consumen ambas instancias no tendrán problemas. Sin embargo, los mecanismos de sincronización nunca son a prueba de errores, es probable que surjan interrupciones o problemas inesperados. En ese caso, la aplicación de línea de negocio que consume datos de ambas instancias debe diseñarse para manejar datos incompletos.
Para que la nueva filial europea de Contoso se integre en la estructura empresarial de esta, deben sincronizar las cuentas y contactos de una instancia de Power Platform con los de la otra. En este escenario, la instancia de Estados Unidos de Power Platform sincroniza un lote diario de datos de referencia mediante una aplicación lógica personalizada con los de la instancia europea. Una aplicación de línea de negocio propiedad de Contoso genera informes sobre incidencias de problemas que los usuarios han creado. Para completar esta tarea, la aplicación de línea de negocio lee los datos de usuario de ambas instancias de Dataverse para extraer los datos pertinentes, las claves de referencia principales de la instancia de EE. UU. y los datos sobre incidencias de la instancia de Europa. Si el proceso de sincronización no se ha completado debido a un tiempo de inactividad, mantenimiento u otro problema de comunicaciones, la solicitud producirá un error ya que faltan entidades de la instancia de Europa.
Posibles casos de uso
Este patrón puede ser útil en las situaciones siguientes:
- El sistema que envía los datos de referencia está fuera de servicio.
- La sincronización de datos tarda mucho tiempo o el proceso se retrasa.
- Los sistemas consumidores no disponen de lógica para la creación de la entidad que se va a crear.
Cuándo utilizar este enfoque
Utilice este enfoque en los escenarios siguientes:
- Quiere garantizar que existe un registro con una clave determinada y no le importa que el registro no esté totalmente hidratado.
- Debe aceptar la creación, incluso si los datos todavía no están sincronizados.
Este patrón puede no ser adecuado en el escenario siguiente:
- La lógica se aplica cuando se crea el registro. Dado que los datos no se hidratarán, no es seguro confiar en que determinadas propiedades estén disponibles.
Ejemplos
En los ejemplos siguientes se muestran los posibles recorridos y el resultado de los retrasos en la sincronización.
Ejemplo 1: ruta correcta sin interrupciones ni errores transitorios
Descargue un archivo Visio de esta arquitectura.
- La instancia de EE. UU. sincroniza una nueva cuenta en la instancia de Europa mediante una aplicación lógica. Todos funcionan porque no se ha producido ningún error transitorio ni interrupción.
- La aplicación de línea de negocio de Contoso lee las entidades de cuenta principales de la instancia de EE. UU. y pretende enviar una llamada API que hace referencia a una entidad de cuenta que se ha replicado en la instancia de Europa. Funciona porque todo estaba en funcionamiento y no se produjeron interrupciones ni errores transitorios. El informe de la aplicación de línea de negocio se genera correctamente.
Ejemplo 2: ruta incorrecta en la que la sincronización está fuera de servicio o retrasada
Descargue un archivo Visio de esta arquitectura.
- La instancia de EE. UU. intenta sincronizar una nueva cuenta en la instancia de Europa mediante una aplicación lógica. La instancia de Europa no es accesible, debido a un problema de tiempo de inactividad, mantenimiento u otro problema de comunicaciones.
- La aplicación de línea de negocio de Contoso lee las entidades de cuenta principales de la instancia de EE. UU. y pretende enviar una llamada API que hace referencia a una entidad de cuenta que no se ha replicado en la instancia de Europa. Se produce un error en la llamada API porque la cuenta con el identificador especificado no se creó en la instancia de Europa y no se genera el informe.
Consideraciones
Tenga en cuenta el impacto de cualquier lógica de negocios en una entidad que aún no está hidratada. Considere un escenario en el que la entidad aún no está totalmente hidratada y sincronizada. Algunas de las propiedades serán NULL, por lo que debe asegurarse de que las decisiones sobre los datos se tengan en cuenta al usar este enfoque.
Pasos siguientes
Recursos relacionados
Arquitecturas relacionadas:
Guía para el desarrollo web: