Определение требований к интеграции

Успешная разработка интеграции начинается с понимания трех базовых измерений: громкости и частоты, направления и возможностей. Эти измерения помогают оценить бизнес-требования, ограничения системы и потребности масштабируемости.

Например, представьте себе, что у вас есть такая высокоуровневая цель, как подключение SAP к Dataverse или отправка уведомления каждый раз, когда есть обновление в случае, над которым работает пользователь. Что является отправной точкой для разработки интеграции?

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

• Объем и частота — это первый основной компонент процесса принятия решений. Он помогает определить типы инструментов, которые необходимо использовать для реализации бизнес-требований.

• Направление, следующий компонент, определяет направление потоков данных: откуда и куда они идут. Понимание направления помогает настроить шаблон успешной интеграции.

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

Том и частота

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

Сравнение объёма против частоты

Два сценария интеграции могут включать один и тот же общий объем, например 60 000 записей в час и 1000 записей в минуту, но отличаются частотой. Хотя оба варианта дают одинаковый почасовой объем, поминутные ожидания влияют на дизайн решения.

• Не предполагайте, что одно решение соответствует обоим.
• Проверьте способность системы обрабатывать нагрузку с более высокой частотой.
• Рекомендуется создавать отдельные решения, если один шаблон является ресурсоемким или редко используемым.

Типы триггеров

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

Запланированные триггеры (также известные как "Пакет"):

• Запуск через фиксированные интервалы.
• Проще прогнозировать и управлять ими.
• Подходит для стабильных шаблонов роста данных.

Триггеры на основе событий: событие может быть нажатием кнопки, изменением записи в одной из систем или вызовом API.

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

Сезонность

Объем данных изменяется с бизнес-циклами. Планируйте сезонные пики в запланированных и обусловленных событиями интеграциях.

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

Совместная работа с заинтересованными лицами

Обсудите объем и частоту с владельцами процессов и бизнес-пользователями. Проверьте предположения относительно фактических рабочих процессов.

• Бизнес-пользователи могут не знать полный процесс.
• Архитекторы должны исследовать и подтвердить операционные реалии.

Планирование будущего

Проектирование решений интеграции с учетом роста.

• Четко определите условия работы.
• Включите долгосрочные планы масштабируемости.
• Оцените, когда требуется масштабирование.

Directionality

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

Заинтересованные лица и соответствие требованиям

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

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

Capability

Производительность интеграции зависит от возможностей каждой системы. Самая слабая система в цепочке ограничивает общий результат.

• Оцените возможности системы в соответствии с бизнес-требованиями.
• Определите узкие места, которые могут повлиять на передачу данных высокой частоты или больших объемов.
• Рассмотрите улучшения, если система не может соответствовать ожиданиям производительности.

Возможность и частота

Частота влияет на то, насколько хорошо система обрабатывает передачу данных. Система, которая хорошо работает один раз в день, может выйти из строя при нескольких ежедневных нагрузках.

• Соответствие системной возможности требуемой частоте.
• Не предполагайте, что только объем влияет на целесообразность.

Кэширование

Кэширование — это обычное решение, когда система не может соответствовать требованиям к производительности.

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

Преобразование и бизнес-логика

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

• Оцените, что каждая система может делать до, во время и после передачи данных.
• Рассмотрите сложность исходных данных, потребностей преобразования и целевой системной обработки.

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

Заинтересованные стороны по возможностям

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

• Перед выбором шаблона интеграции оцените каждую систему.
• Убедитесь, что технические возможности соответствуют ожиданиям бизнеса.

Соберите всё вместе

Эффективная архитектура интеграции начинается с понимания трех основных компонентов. Подведение итогов.

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

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

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

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

Пример сценария

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

Объем запросов и частота срабатывания триггера

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

Общий объем обновлений можно вычислить следующим образом:

[Customers] × [Cases per customer] × [Average updates per case]

Визуализировать это число на диаграмме, чтобы показать, как он растет с течением времени. Например, если вы начинаете с 10 миллионов обновлений в год и ожидаете увеличения на 20% каждый год, диаграмма должна показать постоянный рост количества обновлений из года в год.

Используйте исторические данные и прогнозы роста для оценки будущей нагрузки. Например, если система обрабатывает 10 миллионов обновлений в год и растет на 20% ежегодно, интеграция должна поддерживать 25 миллионов обновлений в год в течение пяти лет.

Анализ частоты показывает ежемесячные пики. Если текущий спрос составляет 3,2 миллиона запросов в месяц, будущий спрос может достичь 8 миллионов в месяц. Создайте интеграцию для удовлетворения этих пороговых значений производительности.

Чтобы обеспечить эффективность интеграции в течение типичного пятилетнего периода рентабельности инвестиций (ROI), создайте решение для поддержки по крайней мере 25 миллионов запросов в год. Этот план планирования емкости учитывает прогнозируемый рост и помогает решению оставаться масштабируемым и надежным по мере развития бизнес-потребностей.

Частота объема — это возможность задействованных систем обрабатывать информацию в течение года. Опять же, мы можем провести диаграмму исторических данных, чтобы понять, как применяется частота.

Направление и поток данных

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

• Непрерывная передача данных с веб-сайта для внесения обновлений дел в Dataverse
• Еще один поток, через который сайт считывает обновления из Dataverse
• Третий поток данных, в котором инженеры записывают обновления в Dataverse из Power App
• Окончательный поток данных для чтения обновлений в Power App

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

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

Способность в действии

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

Используйте Dataverse Analytics для мониторинга текущего использования. Если Dataverse приближается к прогнозной нагрузке запроса, попробуйте добавить защитный буфер в виде Azure Data Lake.

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

Эта стратегия помогает уменьшить объем чтения из Dataverse и предотвратить ошибки регулирования (например, HTTP 429 "Слишком много запросов").

Чтобы еще больше снизить степень зависимости, отделите запросы на создание и обновление от веб-сайта, используя службу очередей, такую как Служебная шина Azure.

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

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

Следующий шаг

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

Связанные ресурсы

• Что такое Azure Synapse Link для Dataverse?
• Добавление проверки подлинности OAuth для триггеров HTTP-запроса
• Ограничения автоматизированных, запланированных и мгновенных потоков
• Просмотр и скачивание аналитики Microsoft Dataverse
• Создание Azure Synapse Link для Dataverse с помощью Azure Data Lake
• Очереди, темы и подписки служебной шины