Изменить

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

Microsoft Power Platform
Microsoft Dataverse
Azure Logic Apps

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

Архитектура

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

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

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

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

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

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

Потенциальные варианты использования

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

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

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

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

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

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

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

Примеры

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

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

Схема, показывающая успешную синхронизацию нескольких систем.

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

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

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

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

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

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

Рекомендации

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

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

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

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