Изменить

Поделиться через

Итоговая согласованность между несколькими экземплярами Power Apps

Microsoft Power Platform
Microsoft Dataverse
Azure Logic Apps

В этой статье описывается сценарий, в котором клиент, основанный на США, Компания Contoso недавно приобрела другую компанию, основанную в Европе, и находится в процессе crm и ERP-систем между двумя компаниями. В рамках этой интеграции они должны хранить часть своих сущностей Dynamics 365 Dataverse в синхронизации, пока они не смогут полностью интегрироваться. Приложение Conotso с собственной бизнес-моделью использует данные из обеих систем и должно принимать запросы, когда данные ожидают синхронизации или когда отсутствуют. В следующем руководстве показано, как учитывать конечную согласованность между экземплярами Power Platform.

Архитектура

Подключаемый модуль или поток для всегда upsert на основе GUID или альтернативного ключа

схема с подключаемым модулем обработки данных, предоставляющим решение сбой многосистемной синхронизации.

Скачайте файл Visio этой архитектуры.

Рабочий процесс

Это решение можно построить с помощью нескольких шагов подключаемых модулей в рамках жизненного цикла подключаемого модуля. При обязательном создании сущности используйте шаг preValidation. preValidation происходит до запуска транзакций базы данных. Это предпочтительный вариант, если поле является обязательным. Однако в некоторых сценариях достаточно шага подключаемого модуля preCreate.

  1. Экземпляр США пытается синхронизировать новую учетную запись с экземпляром Европы через приложение логики. Экземпляр Европе недоступен из-за простоя или обновления.
  2. Бизнес-приложение Contoso считывает сущности основной учетной записи из экземпляра США. Он намерен отправить вызов API, ссылающийся на сущность учетной записи, которая не была реплицирована в экземпляре Европы. По мере того как вызов API завершится ошибкой, так как запись не существует, из-за отсутствия синхронизации.
  3. Однако подключаемый модуль PreValidation/PreCreate сначала выполняет upsert на основе предоставленного GUID сущности и предоставленных ссылочных данных. Если он уже существует, то ничего не изменится. Если она не существует, создается новая учетная запись с большинством полей пустыми.
  4. Вызов API завершается успешно, так как учетная запись с заданным идентификатором существует в системе. Подключаемый модуль перехватил операцию и обработал недостающую запись корректно. Отчет из бизнес-приложения успешно создается.

Заметка

Корпорация Майкрософт рекомендует ввести шаблон разбиения цепи в пользовательском коде, чтобы выключиться и повторить попытку в рамках этого решения для обработки сбоев платформ при обращении к экземпляру. Дополнительные сведения об использовании средства разбиения цепи см. в разделе Шаблон разбиения цепи.

Альтернативы

Описанный выше сценарий использует пользовательское приложение логики в качестве метода репликации. Однако существует несколько способов репликации данных между экземплярами Dataverse, которые включают в себя, но не ограничиваются следующими способами:

  • Logic Apps
  • Приложения-функции в Функциях Azure
  • Фабрика данных Azure
  • Azure Synapse Analytics
  • Power Automate

Сведения о сценарии

Организации иногда находят необходимость хранить два или более экземпляров Power Platform в синхронизации, в частности, подмножество сущностей Dataverse. Это требование может произойти, если организация намеренно добавила новые экземпляры для географической изоляции, но требует общего набора данных для всех регионов. Или может произойти при слиянии двух организаций до завершения консолидации Power Platform.

Когда процесс синхронизации работает как разработанный, бизнес-приложения, использующие оба экземпляра, не имеют проблем. Однако механизмы синхронизации никогда не являются подтверждением ошибок, сбоями или непредвиденными проблемами, скорее всего, возникнут. В этом случае бизнес-приложение, использующее данные из обоих экземпляров, должно быть создано для обработки неполных данных.

Чтобы новая европейская дочерняя компания Contoso была интегрирована в бизнес-структуру Компании Contoso, они должны синхронизировать учетные записи и контакты из одного экземпляра Power Platform в другой. В этом сценарии экземпляр Power Platform в США синхронизирует ежедневный пакет ссылочных данных с помощью пользовательского приложения логики с европейским экземпляром. Частное приложение Contoso LOB создает отчеты о проблемах, созданных пользователями. Для выполнения этой задачи бизнес-приложение считывает пользовательские данные из обоих экземпляров Dataverse для извлечения соответствующих данных, первичных ссылочных ключей из экземпляра США и данных билета из экземпляра Европы. Если процесс синхронизации не был завершен из-за простоя, обслуживания или другой проблемы связи, запрос приведет к ошибке из-за отсутствия сущностей из экземпляра Европы.

Возможные варианты использования

Этот шаблон может быть полезным в следующих ситуациях:

  • Система, которая отправляет справочные данные, отключена.
  • Синхронизация данных занимает много времени или процесс задерживается.
  • Использование систем не имеет логики при создании создаваемой сущности.

Когда следует использовать этот подход

Используйте этот подход в следующих сценариях:

  • Вы хотите гарантировать наличие записи с заданным ключом, и вы не заботитесь о том, что запись не полностью гидратирована.
  • Необходимо принять создание, даже если данные по-прежнему не синхронизированы.

Этот шаблон может не подходить в следующем сценарии:

  • Логика применяется при создании записи. Так как данные не будут гидратироваться, это небезопасно полагаться на некоторые свойства, доступные.

Примеры

В следующих примерах показаны потенциальные пути и результат задержек синхронизации.

пример 1. Успешный путь без сбоя или временных ошибок

схема успешной синхронизации с несколькими системами.

Скачайте файл Visio этой архитектуры.

  1. Экземпляр США синхронизирует новую учетную запись с экземпляром Европы с помощью приложения логики. Все работают, так как не произошло временных сбоев или сбоев.
  2. Бизнес-приложение Contoso считывает сущности основной учетной записи из экземпляра США и собирается отправить вызов API, который ссылается на сущность учетной записи, которая была реплицирована в экземпляре Европы. Это работает, потому что все было вверх, и не произошло временных сбоев. Отчет из бизнес-приложения успешно создается.

примере 2. Неудачный путь, в котором синхронизация отключена или отложена

диаграмме, на которой показана сбой синхронизации с несколькими системами.

Скачайте файл Visio этой архитектуры.

  1. Экземпляр США пытается синхронизировать новую учетную запись с экземпляром Европы через приложение логики. Экземпляр Европы недоступен из-за простоя, обслуживания или другой проблемы с обменом данными.
  2. Бизнес-приложение Contoso считывает сущности основной учетной записи из экземпляра США и собирается отправить вызов API, который ссылается на сущность учетной записи, которая не была реплицирована в экземпляре Европы. Вызов API завершается ошибкой, так как учетная запись с заданным идентификатором не была создана в экземпляре Европы, и отчет не создается.

Соображения

Рассмотрим влияние любой бизнес-логики на сущность, которая еще не гидратирована. Рассмотрим сценарий, в котором сущность еще не полностью гидратирована и синхронизирована. Некоторые свойства будут иметь значение NULL, поэтому необходимо убедиться, что при использовании этого подхода все решения о данных учитываются.

Дальнейшие действия

Связанные архитектуры:

Руководство по веб-разработке: