Досліджуйте шаблони інтеграції

На основі вашого аналізу сплануйте інтеграцію та визначте найкращий шаблон для ваших потреб. Наступний список шаблонів інтеграції не є вичерпним. Можливо, ви знайдете, що комбінація цих схем найкраще підходить для вашої ситуації.

Кожен шаблон враховує конкретні бізнес-сценарії та технічні обмеження:

• Миттєвий тригерний патерн: цей патерн відображає взаємодію користувачів із системами. Дія, керована користувачем, запускає заздалегідь визначену серію дій.
• Патерн, керований подіями: Цей патерн вимагає автоматичного тригера, наприклад, реакції на події, що відбуваються в певній системі.
• Патерн консолідації даних: Цей шаблон є необхідним для організацій з кількома системами управління, які потребують повного уявлення про свої дані у різних системах.
• Сервісно-орієнтований архітектурний патерн: Цей шаблон зазвичай передбачає кілька потоків між системами, що дозволяє модульну, масштабовану інтеграцію у складних середовищах.
• Патерн синхронізації: цей патерн підтримує синхронізацію даних між різними базами даних і відповідає вимогам до продуктивності та регуляторних вимог.

Миттєвий патерн тригера

Миттєвий тригерний патерн керується користувачем і інтуїтивно зрозумілий. Він запускає процес інтеграції, коли користувач виконує дію, наприклад, натискає кнопку в Power App. Ця модель ідеальна для ситуацій, коли дані потрібні на вимогу, а не постійно.

Приклад сценарію

Power App дозволяє менеджерам продукту переглядати відгуки клієнтів і створювати плани дій. Деякі технічні специфікації зберігаються в системі управління життєвим циклом продукту Oracle. Замість копіювання всього набору даних у Dataverse, додаток має кнопку для завантаження даних за потреби.

Причини для інтеграції, а не для перенаправлення користувачів до Oracle, включають:

• Поганий користувацький досвід
• Проблеми з безпекою
• Витрати на ліцензування

З огляду на економічну ефективність інтеграцій Power Platform, будь-яка з цих причин може виправдати впровадження.

Проєктування потоку

Використовуйте миттєвий хмарний потік, який запускається натисканням кнопки в додатку.

Ця діаграма ілюструє патерн Instant trigger, коли дія, ініційована користувачем, отримує дані з зовнішньої системи і записує їх у Dataverse:

Потік включає такі кроки:

1. Запитуйте записи в Oracle, використовуючи параметри (наприклад, Product ID), які надає додаток.
2. Поверніть записи з Oracle у додаток.
3. Записуйте записи у Dataverse.

Ці дані потім відображаються в інтерфейсі Power Apps.

Міркування:

• Моделі даних між Oracle і Dataverse можуть відрізнятися, вимагаючи етапів трансформації.
• Миттєві тригери не є справді миттєвими. Час виконання залежить від доступності системи та складності трансформації.
• Додайте візуальні індикатори в додатку для показу прогресу і дозвольте скасування, якщо операція триває надто довго.
• У великих організаціях одночасні запити від багатьох користувачів можуть навантажувати систему.
• Інтеграції можуть зазнавати невдачі з різних причин. Переконайтеся, що додаток надає користувачам зворотний зв'язок під час виконання. Уникайте ситуацій, коли користувачі обирають кнопку і не отримують відповіді, що призводить до поганого користувацького досвіду.

Патерн, керований подіями

Архітектури, керовані подіями (також відомі як автоматичний тригер), реагують на зміни в системах без прямої взаємодії користувача. Наприклад, тригери можна налаштувати для реагування на запис, створений у Dataverse, вхідні листи, файли, додані до OneDrive, та будь-яку кількість інших подій. Цей шаблон є інтуїтивно зрозумілим і масштабованим, що робить його ідеальним для автоматизації бізнес-процесів на основі системних подій.

Приклад сценарію

Відділ обслуговування клієнтів використовує додаток, пов'язаний із Dataverse, для роботи над справами та автоматичного надання оновлень клієнтам, без ручного написання листів. Лише конкретні зміни — такі як додавання нотатки або зміна статусу — повинні запускати сповіщення.

Використовуйте автоматичний тригер у Power Automate, щоб реагувати на ці події. Потік слухає зміни у записах Dataverse і надсилає сповіщення при виконанні визначених умов.

Ця діаграма показує автоматичний патерн тригерів, коли зміни в Dataverse автоматично ініціюють подальші дії, які оновлюють клієнтів відповідною інформацією про кейс:

Конфігурація спускового механізму

Налаштуйте потік таким чином:

• Вкажіть тип зміни для монітора.
• Визначте стовпці для відповіді за допомогою параметра Select Columns .
• Використовуйте параметр Filter Rows , щоб переконатися, що потік запускає лише зміни статусу, орієнтовані на клієнта, а також інші вимоги фільтрації.

Уникайте реалізації цієї логіки безпосередньо у потоці за допомогою дії If . Використовуйте параметри тригерів для зменшення зайвих виконань і підвищення продуктивності.

Уникати логічних конфліктів

Оцініть логіку події, щоб запобігти небажаній поведінці:

• Уникайте циклів, коли подія запускає дію, що повторно запускає ту саму подію.
• Запобігайте численним оновленням, які спричиняють швидкі, повторювані сповіщення.
• Проєктування працює для обробки крайніх випадків і уникнення надмірних виконань.

Об'єм і частота

Розумійте очікуваний обсяг тригерних подій. Сервіси сповіщень (електронна пошта, SMS та інші) обмежують кількість повідомлень, які ви можете надіслати за певний проміжок часу.

• Оцініть кількість подій на день або місяць.
• Впровадьте механізми тротлінгу або обмеження швидкості.
• Підготуйте план пом'якшення несподіваних стрибків частоти подій.

Патерн консолідації даних

Консолідація даних (також відома як запланований тригер) допомагає організаціям об'єднувати інформацію між кількома системами для підтримки звітності та операційних процесів. Хоча аналітика часто вимагає повних наборів даних, операційні сценарії зосереджені на отриманні лише тих даних, необхідних для виконання бізнес-завдань.

Приклад сценарію

Компанія використовує три застарілі системи для управління основними бізнес-функціями: SAP для замовлень і дебіторської заборгованості, Oracle для інвентаризації продукції та IBM для управління контентом, пов'язаним із клієнтами. Організація замовила новий додаток Power Platform, який використовує штучний інтелект для прогнозування наступної найкращої дії для кожного клієнта на основі історичних даних. Додаток має збирати релевантну інформацію з усіх трьох систем і генерувати план дій з продажу для менеджерів з продажу, щоб спрямовувати залученість.

Підхід до інтеграції

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

У цьому випадку запланований тригер консолідує дані таким чином:

• Запитує лише необхідні дані з кожної системи
• Повертає дані у формат, сумісний з Dataverse
• Завантажує дані в модель ШІ для аналізу

Ця діаграма ілюструє заплановану модель консолідації даних, коли повторюваний процес збирає інформацію з кількох систем і завантажує об'єднаний набір даних у Dataverse:

Конфігурація запланованого тригера

Заплановані тригери пропонують гнучкі варіанти повторення — від одного разу на секунду до одного разу на рік. Вони передбачувані за часом, але можуть стати непередбачуваними за обсягом, якщо обсяг даних розширюється або зростання перевищує очікування.

• Відстежуйте час виконання потоку, щоб уникнути накладань або затримок
• Впровадити запобіжні заходи для запобігання погіршенню продуктивності
• Використовуйте Application Insights або подібні інструменти, щоб переконатися, що потік працює стабільно

Зниження ризиків

Якщо запланований потік триває довше, ніж очікувалося, це може порушити бізнес-процеси. Наприклад, потік, розрахований на кожні 10 хвилин, може не вдатися, якщо його завершення триватиме більше 10 хвилин.

• Моніторинг часу виконання та встановлення сповіщень про аномалії
• Плануйте масштабованість у міру збільшення обсягу даних
• Забезпечте видимість стану потоку, щоб запобігти непомітним збоям

Сервісно-орієнтований шаблон інтеграції

Великі організації часто експлуатують кілька систем у різних відділах. Ці системи еволюціонують, щоб залежати одна від одної для завершення бізнес-процесів. Інтеграційний шар об'єднує ці системи, дозволяючи кожній виконувати свою основну функцію та водночас забезпечуючи міжсистемну комунікацію.

Приклад повторного сценарію

Давайте продовжимо з нашим прикладом, коли організація використовує кілька систем для управління різними частинами бізнесу. SAP обробляє замовлення та дебіторську заборгованість, Oracle керує запасами продукції, а IBM зберігає внутрішню фінансову документацію. Dataverse запускає додатки для продажів, обслуговування клієнтів і управління продуктами. SharePoint підтримує внутрішню співпрацю та управління базою знань, тоді як API Maersk автоматизують логістичні процеси.

Ця діаграма ілюструє подійно-орієнтовану закономірність у багатосистемному ландшафті, де оновлення в різних корпоративних системах запускають автоматизовані потоки, які координують дані та дії між ними:

Кожна система взаємодіє з іншими через заплановані події або ручні дії користувача. Жоден єдиний флоу не охоплює всі випадки використання. Натомість рішення вимагає кількох потоків, адаптованих до конкретних тригерів і бізнес-процесів.

Уникати монолітних потоків

Створювати один великий потік для всіх інтеграцій — непрактично. Вона створює виклики продуктивності, безпеки та обслуговування. Замість цього:

• Створюйте модульні потоки для кожного тригера та процесу
• Оптимізація потоків для конкретних випадків використання
• Масштабуйте ландшафт інтеграції за допомогою керованих компонентів

Оптимізація міжсистемних процесів

Шукайте можливості для консолідації логіки, де це доречно. Наприклад, якщо документ у SharePoint потрібно надіслати і SAP, і Oracle під час однієї події, може виникнути спокуса створити один потік, який читатиме файл один раз і записує його в обидві системи. Спершу ж розгляньте, чи не надто жорстка логіка, яку ви створюєте. У великому світі зміни у роботі бізнес-процесів у різних системах відбуваються так само часто, як і зміни в цих системах.

Уникайте надмірної консолідації. Бізнес-процеси та конфігурації систем часто змінюються. Жорстка, централізована логіка зменшує гнучкість і збільшує витрати на обслуговування.

Проєктні потоки, які такі:

• Модульний і підтримуваний
• Масштабування між відділами та системами
• Стійкість до змін у бізнес-логіці та поведінці системи

Ця модель призводить до сервісно-орієнтованої архітектури — іноді жартома називається «спагеті-архітектурою» — де системи взаємопов'язані чітко визначеними, спеціально побудованими потоками.

Патерн синхронізації даних

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

• Продуктивність: Локальний доступ до даних підвищує оперативність, особливо в галузях, чутливих до затримки.
• Відповідність: Законодавчі норми можуть вимагати, щоб дані зберігалися в межах національних кордонів. Організації часто розгортають локальні екземпляри з процесами синхронізації для задоволення цих вимог.

Приклад сценарію

Компанія з виробництва медичних пристроїв працює у кількох регіонах Європи у співпраці з місцевими медичними установами. Закони кожного регіону чітко стосуються медичних даних — вони мають зберігатися в межах цього регіону. Інформація про замовлення, товари та доставку може зберігатися за кордоном. Щоб виконати регуляторні вимоги, компанія створила екземпляр свого додатку для управління клієнтами Power Platform та Dataverse у кожному регіоні.

Для підтримки операцій з продажу компанія бажає синхронізувати нечутливі дані, такі як контактні дані, замовлення та доставка, між усіма інстансами. Медичні дані виключені з синхронізації.

Підхід до інтеграції

Використовуйте автоматичний хмарний потік, який запускається оновленням запису облікового запису. Налаштуйте фільтри так:

• Дозволені поля лише для моніторингу
• Запобігти синхронізації обмежених даних

Такий підхід призводить до цілеспрямованої, подійно орієнтованої інтеграції, що підтримує відповідність і операційну ефективність.

Ця діаграма ілюструє патерн синхронізації, керованого подіями, коли оновлення в одному середовищі Dataverse автоматично запускають відповідні оновлення в іншому:

Очікування щодо часу відгуку

Встановіть реалістичні очікування щодо швидкості синхронізації. Power Automate є асинхронним і не гарантує продуктивність у реальному часі. Якщо бізнес-користувачі очікують негайної доступності даних, уточніть обмеження на ранніх етапах процесу проєктування.

• Оцініть, чи відповідає Power Automate вимогам продуктивності
• Уникайте надмірної інженерії для доступу в реальному часі, якщо це не виправдано бізнес-вимогами

Багато запитів на доступ у реальному часі не мають вагомої бізнес-підстави. Пріоритет — чіткість, масштабованість і підтримуваність у дизайні інтеграції.

Поза потоками хмар

При виборі інструменту інтеграції починайте з Power Automate як опції за замовчуванням. Він пропонує неперевершену економічну ефективність як для розробки, так і в обслуговуванні.

Power Automate є пріоритетним інструментом інтеграції для багатьох сценаріїв, оскільки він:

• Забезпечує швидку розробку за допомогою роз'ємів з низьким кодом
• Мінімізує довгострокові витрати на обслуговування
• Підтримує широкий спектр тригерів і систем
• Добре масштабується для більшості бізнес-сценаріїв

Власний код, Azure Functions, Data Factory або Service Bus можуть дати більше контролю або кращу продуктивність, але вони додають складності та вартості. Використовуйте ці опції лише тоді, коли Power Automate не відповідає вашим бізнес-або технічним потребам.

Приклад сценарію

Онлайн-банкінг прагне швидше кваліфікувати клієнтів на кредити. Процес кваліфікації включає складні розрахунки та отримання даних з кількох систем для визначення остаточного оцінки ризику. Після початкової оцінки банківська служба вважала хмарний потік непридатним через складність розрахунків.

Однак у цьому випадку відповіддю є гібридний підхід:

• Power Automate обробляє збір даних за допомогою вбудованих роз'ємів
• Складні обчислення інкапсулюються у власному коді, що працює як функція Azure, яку можна незалежно масштабувати, або в власному конекторі

Цей гібридний підхід балансує між продуктивністю, масштабованістю та вартістю.

Стратегія інтеграції

Не обирайте інструменти окремо. Натомість поєднуйте їхні сильні сторони. Приклад.

• Використовуйте Power Automate для оркестрації та підключення
• Use Azure Functions for compute-intensive tasks
• Використовуйте спеціальні роз'єми для розширення функціональності за потреби

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