Інтеграція сьогодні

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

Іноді все, що вам потрібно зробити, це підключити одну програму безпосередньо до іншої. Однак частіше інтеграція програм означає з’єднання кількох незалежних систем, часто складним способом. Ось чому організації зазвичай покладаються на спеціалізовані інтеграційні платформи, які надають необхідні для цього послуги. Як і багато іншого сьогодні, ці платформи перемістилися з локальних центрів обробки даних у публічну хмару. Замість того, щоб використовувати традиційні технології інтеграції, такі як BizTalk Server, все більше організацій використовують рішення інтеграційної платформи як послуги (iPaaS), тобто хмарні інтеграційні платформи.

Для задоволення цієї потреби Microsoft надає служби інтеграції Azure. Рішення iPaaS — це набір хмарних служб для критично важливої корпоративної інтеграції. Для досягнення цієї мети ці служби надають чотири основні технології, необхідні для хмарної інтеграції. Малюнок 1 їх ілюструє.

Малюнок 1. Сучасна хмарна інтеграція спирається на чотири основні служби.

Сьогодні для інтеграції потрібні чотири основні хмарні служби:

• API як спосіб публікації та керування інтерфейсами прикладного програмування. Служба API робить програмні засоби доступними для іншого програмного забезпечення, незалежно від того, працюють ці служби в хмарі чи локально.
• Оркестровка – наглядний спосіб створення та запуску логіки інтеграції. Наприклад, вам може знадобитися реалізувати бізнес-процес, який покладається на кілька різних програм, доступ до яких здійснюється через API.
• Щоб створити такий робочий процес, iPaaS забезпечує оркестровку, як правило, за допомогою графічного інструменту для визначення логіки робочого процесу.
• Обмін повідомленнями (мессенджинг) - певний спосіб для програм і технологій інтеграції спілкуватися слабко пов’язаними способами. Ця служба надає черги, які зберігають повідомлення, доки їх не зможе отримати одержувач. Це дозволяє додаткам і програмному забезпеченню для інтеграції асинхронно спілкуватися навіть на різних технологічних платформах, що часто потрібно в сценаріях інтеграції.
• Події (івенти) - технологія, яка підтримує спілкування через події. Замість опитування черги в службі обміну повідомленнями, наприклад, іноді простіше та ефективніше дізнатися про зміни, отримавши подію.

Ці хмарні служби, іноді в поєднанні з іншими хмарними технологіями, можна використовувати для інтеграції як хмарних, так і локальних програм. Як описано далі, Azure Integration Services надає всі чотири вказані служби.

Служби інтеграції Azure: загальна картина

Чотири компоненти Azure Integration Services:

• API Management, який надає службу API.
• Логічні програми, що підтримують оркестровку бізнес-процесів, робочих процесів тощо.
• Service Bus, що забезпечує надійний корпоративний обмін повідомленнями.
• Сітка подій, яка дозволяє створювати та доставляти події.

Малюнок 2 показує ці чотири компоненти.

Малюнок 2. Служби інтеграції Azure дозволяють об’єднувати хмарні та локальні програми за допомогою єдиного набору хмарних служб.

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

Як би ви використовували служби інтеграції Azure? Ось деякі з найпоширеніших сценаріїв:

• Підключення програм у вашій організації. Програми можуть працювати у вашому власному локальному центрі обробки даних, у хмарі або поєднувати те й інше. Цей вид інтеграції корпоративних програм (EAI) був важливим протягом десятиліть; зараз його адаптують для гібридного світу.
• З’єднання програм у вашій організації з програмами ділового партнера. Широко відоме як інтеграція «бізнес-бізнес» (B2B), воно часто базується на стандартних форматах, таких як електронний обмін даними (EDI). Як описано далі, служби інтеграції Azure підтримують ці широко використовувані стандарти.
• Підключення програм у вашій організації до програмного забезпечення як послуги (SaaS). Оскільки бізнес-програми, які ви купуєте, продовжують переходити на SaaS, інтеграція програм потребує підключення до цих хмарних служб. Наприклад, бізнес-процесу в гібридному середовищі може знадобитися доступ як до вашої локальної системи обліку, так і до рішення хмарної CRM.
• Інтеграція програм із пристроями Інтернету речей (IoT). Постійне зростання популярності IoT породжує низку нових задач інтеграції. Хмарне рішення — iPaaS — унікально підходить для вирішення цих проблем, оскільки до нього можуть отримати доступ пристрої, що працюють будь-де.

Значення Azure

Чотири компоненти служб інтеграції Azure вирішують основні вимоги інтеграції додатків. Але реальні сценарії часто потребують більше. Можливо, ваш додаток для інтеграції потребує місце для зберігання неструктурованих даних, наприклад, або вимагає включення особливого коду, який здійснює спеціалізовані перетворення даних. Оскільки «послуги інтеграції Azure» є частиною більшої «хмарної платформи Azure», ці речі легко доступні. Ви можете зберігати неструктуровані дані в Azure Data Lake Store, наприклад, або записувати спеціальний код за допомогою функцій Azure, без інтеграційного сервера.

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

Служби інтеграції Azure: технології

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

API Management 

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

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

Проте зробити API доступними для виклику іншого програмного забезпечення складніше, ніж ви думаєте.

Фактично, для типових сценаріїв інтеграції недостатньо просто відкрити API програми безпосередньо у вашій мережі. Щоб зробити це ефективно, вам потрібно мати чіткі відповіді на такі запитання, як:

• Як обмежити кількість запитів, які ваша програма може отримати від клієнтів? Більшість програм, які надають API, не можуть обробляти необмежену кількість запитів, тому вам потрібен спосіб контролювати це.
• Як ви контролюєте, як автентифікуються виклики API вашої програми? Безпека завжди важлива, особливо для програм, підключених через загальнодоступний Інтернет.
• Як переконатися, що ваші API достатньо швидкі? Можливо, ви захочете кешувати відповіді на часті запити, наприклад, щоб пришвидшити відповіді.
• Як ви відстежуєте та аналізуєте, як використовуються ваші API? Шаблони у використанні API можуть вказувати на тенденцію, яка суттєво впливає на ваш бізнес.
• Як полегшити розробникам використання ваших API? Вам потрібен спосіб надати їм документацію, зразки коду, тощо.

Azure API Management вирішує всі ці проблеми. Малюнок 3 підсумовує роль, яку відіграє ця хмарна служба.

Малюнок 3. API Management надає доступ до API із серверних служб різним клієнтам.

API Management може відкривати REST і SOAP API від усіх типів серверного програмного забезпечення, у тому числі програм, що працюють у хмарі, і програм, що працюють локально. Довільний стек технологій створення цього програмного забезпечення — .NET, Java чи щось інше — не має значення; API Management працює з будь-чим. Навіть інші служби Azure можна відкрити за допомогою API Management, що дає змогу використовувати керований API угорі Service Bus, Logic Apps та інших служб, які ви виберете. 

Для цього API Management створює фасади — проксі — справжніх API у внутрішніх програмах. Клієнти, включаючи Logic Apps, хмарні та локальні програми та інші, можуть викликати ці фасади. Все це необхідно, щоб клієнт міг створювати та отримувати HTTP-запити. Кожен виклик зрештою передається на базову програму, але, як описано нижче, API Management може надавати кілька корисних послуг перш ніж це станеться. 

Основи діяльності API Management неважко зрозуміти. Але ця проста картина піднімає кілька очевидних питань. Як API серверних служб стають доступними через цю службу API? І як розробники дізнаються те, що їм потрібно, щоб викликати ці API? Малюнок 4 ілюструє відповіді на обидва питання.

Малюнок 4. Видавці API використовують розширення Azure Portal API Management, щоб зробити свої API доступними, а API користувачі покладаються на Developer Portal, щоб дізнатися, як отримати доступ до API.

Щоб зробити серверний API доступним для клієнтів, власник API може використовувати розширення API Management у Порталі Azure. Це розширення дозволяє вказати достатньо деталей API, включаючи операції з ним, які містять також і параметри для кожного з них. Потім API Management створює фасад для API. Коли виклик створено на цьому фасаді, API Management направляє його до відповідної серверної програми. Результат кожного виклику повертається тим же шляхом. (Сервіс також надає API, який дозволяє виконувати ці дії програмно.). Але розширення API Management робить більше, ніж просто публікує API. Він надає аналітику, наприклад, дозволяючи відстежувати використання та справність опублікованих API. Це також дозволяє встановлювати правила контролю по різних аспектах функціонування кожного API. Є десятки правил; ось кілька прикладів що вони дозволяють:
Обмеження кількості викликів, які можуть надходити з одного джерела за визначений період.

• Визначення способу автентифікації абонента.
• Блокування викликів із певних IP-адрес.
• Увімкнення та вимкнення кешування даних.
• Перетворення запитів із SOAP на REST.
• Перетворення даних з XML на JSON і навпаки.

API Management також надає Developer Portal, як показано на Малюнку 4. Люди, які хочуть використовувати API, як правило розробники, можуть використовувати цей портал щоб дізнатися, як це зробити і запросити доступ до цього API. Разом з документацією, що описує деталі — операції та параметри API — також цей портал надає зразок коду для виклику API з C#, Java, JavaScript та інших мов програмування. У сучасному світі практично все є, або ймовірно має бути представлено, як API. Це покращує гнучкість бізнесу та відкриває бізнес-цінність. Тому що це вирішує проблеми, які зникають при застосуванні API, а API Management дає вам ефективний спосіб досягти цієї мети.

Logic Apps

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

Але як створити цю логіку? Одним із варіантів є створення традиційним способом за допомогою C#, JavaScript, Java або іншої мови програмування. Проте процес, який залежить від кількох різних програм може зайняти довгий час, і можливо, знадобиться пауза між кроками. Для подібних сценаріїв створення логіки використання технології workflow (робочого процесу) часто є кращим підходом. 

Саме це забезпечує Logic Apps. Кожна Logic Apps — це workflow, який реалізує певний процес. Це може бути міжсистемний процес, наприклад з’єднання двох або більше програм. Крім того, це може бути процесом «користувач-система», який з’єднує людей із програмним забезпеченням і потенційно має тривалі затримки. Logic Apps розроблено для підтримки будь-якого з цих сценаріїв. Щоб реалізувати процес, Logic Apps може отримати доступ до всіх видів інших програм, включаючи хмарні програми, локальні програми та служби Azure. На малюнку 5 показано як це виглядає.

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

Logic App складається з серії дій, кожна з яких є логічним кроком у процесі, який реалізує цей workflow. Ці дії можуть виражати умови (оператори if), цикли тощо. Важливо те, що Logic App також може використовувати дії для виклику зовнішнього програмного забезпечення та служб. 

Один із способів зробити це — викликати API, доступні через API Management. (Насправді, сама Logic App може бути таким чином виставлена як API.) Але щоб полегшити роботу зі звичайними програмами, джерелами даних та іншими службами, Logic Apps надає понад 200 конекторів, кожен з яких забезпечує простий спосіб для взаємодії з певним зовнішнім сервісом. Існують конектори для взаємодії з Office 365, із Dynamics 365, багатьма CRM системами, соціальними мережами та багатьма іншими хмарними програмами. Також є конектори для локальних технологій, таких як SharePoint, SQL Server, Oracle і SAP, а також посилання на стандартні протоколи, такі як SMTP і FTP. Інші з’єднувачі дозволяють отримати доступ до загальних функцій інтеграції, таких як перетворення даних XSLT і EDI. Незалежно від їх функції, розробники можуть використовувати ці з’єднувачі для створення логічних програм досить швидко навіть для складної інтеграції. Корпорація Майкрософт також надає з’єднувачі для передових технологій, зокрема Azure Machine Learning і Cognitive Services, що дозволяє Logic Apps використовувати переваги сучасних підходів до побудови інтелектуальних інтеграцій, як-от надання аналізу даних, що передаються. 

Але як створювати Logic Apps? За кулісами кожен з них виражений в нотації об’єктів JavaScript (JSON). Це допомагає Logic Apps добре вписуватися в існуючі середовища DevOps — кожен з них є лише текстовим файлом — і навіть можна створити новий робочий процес безпосередньо в JSON. Однак робити це не потрібно. Насправді для створення Logic Apps зазвичай не потрібно писати код взагалі. Натомість розробники використовують Logic Apps Designer, візуальний інструмент, для створення нових процесів. На Малюнку 6 показано приклад графічного інтерфейсу цього інструменту.

Малюнок 6. Конструктор Logic App Designer дозволяє розробникам створювати Logic Apps без написання 

Як показано в цьому прикладі, Logic App Designer дозволяє своїм користувачам створювати робочі процеси, впорядковуючи послідовності дій. Як і всі Logic Apps, ця запускається з тригера, який у цьому випадку вказує, що робочий процес має запускатися кожного разу, коли на сервері FTP додається або змінюється файл. Потім він викликає дві функції Azure, безсерверні фрагменти коду, які перетворюють дані в цьому файлі: спочатку в JSON, потім у PDF. У цьому прикладі розробник Logic Apps визначає наступну дію, яка створює файл у Azure Blob Storage. Після цього робочий процес надсилає електронний лист, а потім виконує умовний запит: якщо щойно доданий файл є терміновим, програма логіки також надсилає SMS повідомлення. 

У цьому простому прикладі немає доступу до хмарних або локальних програм — він здебільшого використовує служби Azure. Тим не менш, це ілюструє основи того, як розробник створює Logic App. Ключовим моментом є те, що не потрібно писати код, що дозволяє розробникам впроваджувати бізнес-процеси швидко й легко. Logic Apps є основою пропозиції iPaaS від Azure, що дозволяє легко підключати програмне забезпечення та служби, до яких вам потрібно отримати доступ. І тому, що це дозволяє вам інтегрувати різні служби, що працюють у хмарі і локально, Logic Apps забезпечує ефективне рішення робочих процесів для сучасного світу.

Безсерверна інтеграція

Розвиток безсерверних обчислень є одним із найважливіших інновацій сучасності. Безсерверні технології, такі як функції Azure, дозволяють розробникам повністю зосередитися на написанні коду. Уся обчислювальна інфраструктура, на яку вони покладаються — віртуальні машини (ВМ), підтримка масштабованості, тощо — надано у комплексі. Завдяки цьому створення програм стає швидшим і легшим. І запуск цих програм часто стає дешевшим, оскільки ви платите лише за обчислювальні ресурси, які фактично використовує ваш код. 

Logic Apps також є безсерверною технологією. Хоча кожна Logic App зрештою працює на якійсь віртуальній машині, все це приховано від розробників. Їм не потрібно думати про інфраструктуру чи масштабованість — все це реалізовано за них. Це дозволяє їм зосереджуватися виключно на створенні логіки інтеграції. Logic Apps також забезпечує безсерверне ціноутворення, мінімізуючи вартість запуску логіки інтеграції. Безсерверна технологія вперше з’явилася в так званих технологіях Application Platform as a Service (aPaaS). Завдяки Logic Apps служба інтеграції Azure також вносить цю інновацію в iPaaS.

Service Bus (Службова шина)

Суть інтеграції програми полягає в тому, що програмне забезпечення спілкується з іншим програмним забезпеченням. Але як має відбуватися це спілкування? Іноді ідеальним є прямий виклик через API Management. Однак в інших випадках цей синхронний стиль спілкування не працюватиме. Що робити, якщо, наприклад, обидві програми недоступні одночасно? Для подібних ситуацій потрібен асинхронний підхід. Саме такий зв’язок забезпечує службова шина Service Bus. Оскільки вона дозволяє програмам обмінюватися повідомленнями через черги, службова шина забезпечує неблокуючу взаємодію між різними частинами програмного забезпечення. Малюнок 7 ілюструє цю ідею.
 

Малюнок 7: Service Bus забезпечує асинхронний зв’язок між усіма видами програмного забезпечення.

Як показано на малюнку, Service Bus забезпечує корпоративний обмін повідомленнями серед багатьох видів програмного забезпечення, включаючи хмарні програми, локальні програми та служби Azure. Для забезпечення цього необхідно мати різноманітний набір функцій — це складніше, ніж ви думаєте. Відповідно, Service Bus забезпечує наступне:

• Семантика черги, включаючи постійність повідомлень і суворе впорядкування повідомлень у черги «першим прийшов, першим вийшов». Сервіс також виявляє та видаляє дублікати повідомлень.
• Атомарні транзакції, що забезпечує ставити у чергу завдання зчитування або запису як частинки більшої операції, яка успішно виконується або виходить з ладу як єдине ціле.
• Обробка шкідливих повідомлень, щоб повідомлення, яке спричиняє проблеми, не призводило до безперервного циклу.
• Висока доступність, включаючи геореплікацію разом із вбудованим аварійним відновленням. 

Одним словом, Service Bus надає всі функції, необхідні для корпоративного обміну повідомленнями. 
Однак ця служба Azure надає ще більше, ніж вже описано. Наприклад, Service Bus дозволяє користувачеві створити одну або кілька тем (Topics), а потім надсилати повідомлення до цієї теми. Одержувачі можуть підписатися на певні теми, а потім отримувати лише повідомлення, надіслані на ці теми. На малюнку 8 показано, як це виглядає.

Малюнок 8: Service Bus дозволяє підписникам вибірково отримувати повідомлення, надіслані на теми.

Як показано на малюнку, одержувачі не зобов’язані отримувати кожне повідомлення, надіслане на певну тему. Натомість кожен отримувач може визначати фільтри, які точно визначають, яку підмножину повідомлень вони отримують. Наприклад, одержувач, який підписався на тему з повідомленнями про фінансові операції, може вибрати отримання лише ті повідомлення на суму від 10 000 євро. 

Асинхронне спілкування на основі повідомлень є важливим аспектом корпоративної інтеграції. Service Bus надає це та багато іншого як хмарний сервіс на Azure. Це фундаментальний компонент в Azure Integration Services. 

Event Grid (Сітка подій) 

Існує багато сценаріїв інтеграції, у яких комунікації через повідомлення здійснюються як найкращий підхід, а не через виклики API. Але програмне забезпечення для періодичної перевірки наявності отримання чи прибуття нового повідомлення, широко відомий як polling (опитування), може бути марнотратним. Чому б не дозволити одержувачу отримувати сповіщення через подію замість цього і не навантажувати безперервно процесорні потужності? 

Це саме те, що дозволяє Event Grid. Замість того, щоб вимагати від одержувача опитувати нові повідомлення, приймач натомість реєструє обробник подій для джерела подій, яке його цікавить. Після цього Event Grid викликає цей обробник події, коли відбувається зазначена подія. Малюнок 9 ілюструє цю ідею.
 

Малюнок 9. Event Grid викликає приймачі, коли сталася певна подія

Як показано на малюнку, багато служб Azure можуть генерувати події. Наприклад, прихід нового повідомлення Service Bus може призвести до того, що Event Grid надішле повідомлення, яке запускає Logic App, або створення нового великого об’єкта в Azure Blob Storage може призвести до того, що спеціальна хмарна програма почне обробляти вміст цього великого об’єкта. Використання підходу, керованого подіями, може спростити розробку додатків, і це можливо також заощадити гроші, оскільки одержувачу не потрібно витрачати цикли на пошук нових повідомлень. 

Щоб отримати подію від служби Azure, наприклад Blob Storage, одержувач підписується на стандартну тему, надану для цієї служби. Але хоча підписка на події зі служб Azure є, ймовірно, найпоширенішим сьогодні використанням Event Grid, це не єдиний варіант. Хмарні та локальні програми також можуть створювати спеціальні теми, дозволяючи службам Azure та іншому програмному забезпеченню отримувати спеціальні події, підписавшись на ці теми.

Усе це викликає очевидне запитання: чи не є Event Grid дуже схожим на теми в Service Bus? Чому Azure Integration Services включає обидва методи? Основна причина полягає в тому, що Service Bus — це корпоративна система обміну повідомленнями, яка має всі необхідні функції та надійність, тоді як Event Grid забезпечує лише простий та швидкий спосіб надсилання подій. Ось деякі з відмінностей, які випливають із розбіжностей цих цілей:

• Теми Service Bus працюють із повідомленнями, а не з подіями. Вони дозволяють одержувачам вирішувати, коли читати повідомлення, і вони вимагають від одержувача активного опитування нових повідомлень. А з Event Grid події створюються від Azure Blob Storage або десь інде, а потім доставляються підписникам. Немає необхідності в постійному опитуванні джерел для отримання цих легких подій.
• Event Grid є значно більш масштабованим, ніж Service Bus, з підтримкою до 10 000 000 подій в секунду в одному регіоні Azure. Щоб досягти цього, Event Grid може доставляти події в довільному порядку, тоді як Service Bus гарантує доставку повідомлень у порядку їх створення.
• Service Bus працює швидко, але Event Grid забезпечує продуктивність майже в реальному часі, 99% подій доставляється менше ніж за секунду.

Асинхронний зв’язок є необхідною частиною iPaaS. Надаючи Event Grid і Service Bus, Azure Integration Services задовольняє будь-які комунікаційні потреби, які можуть знадобитися у вашому сценарії.
Інтеграція даних: роль фабрики даних Azure (Azure Data Factory)

Хоча служби інтеграції Azure безумовно можуть працювати з даними, Основна увага приділяється інтеграції додатків. Що робити, якщо вам потрібно виконати інтеграцію даних? Можливо, ви хочете реалізувати традиційний процес «вилучення/перетворення/завантаження» (ETL) у хмарі за допомогою Azure SQL Data Warehouse, наприклад, або завантажувати та обробляти неструктуровані великі дані за допомогою Azure Data Lake Storage.

Служби інтеграції Azure не обов’язково є найкращим вибором для подібних ситуацій. Натомість Microsoft надає Azure Data Factory, хмарну службу для інтеграції даних. Ця служба адресує обидва щойно описані сценарії разом із багатьма іншими. Різні види інтеграції вимагають різних інтеграційних технологій. Ось чому Microsoft пропонує як Azure Data Factory, так і Azure Integration Services.

Об'єднання послуг: сценарій

Кожен компонент Azure Integration Services має цінність сам по собі. Але справжня вартість цих технології стають зрозумілими, коли всі чотири компоненти задіяні разом. На Малюнку 10 показано приклад того, як ви може зробити це.
 

Малюнок 10. Технології в Azure Integration Services можна використовувати разом для забезпечення повної інтеграції рішення.

Сценарій починається, коли клієнт надсилає замовлення через веб-додаток (крок 1). Це додаток надсилає повідомлення до службової шини Service Bus з описом нового замовлення (крок 2). Це повідомлення може містити документ JSON, що ідентифікує клієнта, товар і замовлену кількість. Коли це повідомлення надходить до черги службової шини, генерується подія для сітки подій Event Grid (крок 3). Потім запускається ця подія виконання Logic App (крок 4), яка негайно читає повідомлення, що очікує в службовій шині (крок 5). Logic App витягує інформацію з цього повідомлення, а потім виконує бізнес-процес, отримуючи доступ до необхідної програми (крок 6). У цьому прикладі бізнес-процес складається з трьох частин, кожна з яких виконується окремою програмою. Вони є наступними:

• Перша вимога — перевірити, чи є в наявності замовлений товар і кількість. Зробити це, Logic App отримує доступ до спеціальної локальної програми інвентаризації. Оскільки цей додаток є доступний через API Management, зробити це просто.
• Якщо запитаний товар і кількість доступні, процес засвідчує добру репутацію клієнта і отримує поштову адресу клієнта. Для цього програма логіки викликає CRM-систему організації. Тут CRM надається програмою SaaS, такою як Salesforce або Dynamics 365, але це також може бути локальна система CRM. Щоб отримати доступ до цієї програми, Logic App використовує відповідний з’єднувач для рішення CRM. (Це дуже просто, конектори покладаються на покриття API Management, тому цей аспект Azure Integration Services все ще використовується тут.)
• Якщо виконано перші дві умови, Logic App розміщує замовлення, отримуючи доступ до системи ERP цієї організації, локальної програми SAP. Ця взаємодія залежить від SAP Connector.

Хоча це не показано на малюнку 10, Logic App може зробити більше. Він може викликати систему електронної пошти, наприклад, ще раз через API Management, щоб надіслати клієнту лист із підтвердженням замовлення. API Management також можна розмістити між веб-програмою та Service Bus на кроці 2, як варіант це спростило б використання додатком цієї служби обміну повідомленнями.

Важливо розуміти, що оскільки Azure Integration Services працює на Azure, його компоненти мають багато спільного. До них можна отримати доступ, наприклад, через портал Azure, і всі вони можуть бути автоматизовані за допомогою PowerShell. Вони мають загальний механізм розгортання, а також служби моніторингу та керування: Azure Monitor, Application Insights і Log Analytics. Ці чотири компоненти також використовують ту саму систему ідентифікації та ту саму рольову модель безпеки. Можна навіть створювати спеціальні інформаційні панелі для моніторингу комплексних інтеграційних рішень як єдиного блоку. Ви можете, наприклад, створити інформаційну панель, розроблену виключно для того, щоб інформувати вас про різні компоненти в сценарії, показаному на малюнку 10.

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

Висновок

Сучасне корпоративне інтеграційне рішення — iPaaS — надає групу хмарних технологій, які працюють разом. Azure Integration Services включає технології:

• API Management для публікації та керування API додатків.
• Logic Apps для графічного створення робочих процесів.
• Service Bus для корпоративних повідомлень.
• Event Grid для спілкування на основі подій.

Кожен із цих хмарних сервісів має цінність окремо. Разом вони забезпечують повнофункціональний iPaaS, здатний підключати як хмарне, так і локальне програмне забезпечення. Розроблені для інтеграції критично важливих підприємств, Azure Integration Services — це iPaaS для сучасного гібридного світу.

For more information 

Home page: Azure Integration Services 
Video: Azure Essentials – Integrating your Apps with Azure 
Webinar: Azure Integration Services 
White paper: Driving Digital Transformation in Today’s API Economy 
Gartner Magic Quadrant: Enterprise Integration Platform as a Service

 

Андрій Безгубенко, по матеріалам сайту Microsoft®

 

Дана стаття розміщена на умовах ліцензії Creative Commons Attribution 4.0 International.