Словник для інженерів з інтеграції

Інтеграційна інженерія — з’єднання різних систем, застосунків і сервісів, щоб вони могли обмінюватися даними — має свій власний спеціалізований словник. Незалежно від того, працюєте ви з Enterprise Service Bus, платформою iPaaS або вручну інтегруєте за допомогою API REST і черг повідомлень, цей словник допоможе вам краще зрозуміти архітектуру інтеграції.

---

Основні концепції інтеграції

Integration

У програмному забезпеченні інтеграція відноситься до процесу надання двом або більше системам можливості обмінюватися даними і координувати поведінку. Інтеграція може бути від точки до точки, hub-and-spoke або заснована на події.

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

Інтеграція з точка-до-точки

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

• “У нас дванадцять систем з прямими з’єднаннями “точка-точка”. Додавання нової системи означає оновлення одинадцяти існуючих інтеграцій. Нам потрібен кращий підхід».*

Спицеві колеса

У ** hub-and-spoke ** моделі, всі системи з’єднуються до центрального інтеграційного шару (концентратора), а не безпосередньо один з одним. Концентратор маршрутизує і перетворює повідомлення між спицями.

“З архітектурою hub- and- spoke, додавання нової системи вимагає лише однієї інтеграції з хабом — а не з кожною існуючою системою.”

---

Середовище і ESB

Middleware

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

“Програмне забезпечення перекладає між застарілим SOAP- заснованим ERP системою і сучасним REST- заснованим API інвентарізації.”

• “Без середовища, кожна система повинна розуміти формат даних кожної іншої системи, з якою вона спілкується.” *

Економічний факультет (Economic Faculty)

** Enterprise Service Bus ** — це платформа середнього рівня, яка забезпечує централізоване маршрутизацію повідомлень, перетворення, посередництво протоколів і оркестрування для інтеграції на рівні підприємства.

“Ми використовуємо MuleSoft як наш ESB. Він обробляє маршрутизацію, перетворення формату і обробку помилок для всіх сорока семи інтеграцій в нашому корпоративному ландшафті. ” “ESB відокремлює наші системи — система управління замовленнями не знає і не турбується про те, як реалізована система виконання.”

Брокер повідомлень

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

• “Ми використовуємо RabbitMQ як брокера повідомлень між службою замовлень і службою сповіщень. Служба замовлень публікує подію; брокер доставляє її всім підписникам.”*

---

iPaaS

iPaaS (Інтеграційна платформа як послуга)

iPaaS це хмарна платформа інтеграції, яка надає інструменти для з’єднання програм, даних і процесів, зазвичай без потреби в локальній інфраструктурі. Поширені платформи включають MuleSoft Anypoint, Dell Boomi, Workato і Zapier (для простіших випадків використання).

• “Ми перейшли від локальної ESB до рішення iPaaS. Керована інфраструктура значно зменшила наші операційні витрати». * “iPaaS платформи, як правило, пропонують попередньо побудовані конектори для звичайних SaaS застосунків, таких як Salesforce, Workday, і ServiceNow, що прискорює інтеграцію розробки.”

---

Конектори і адаптери

Connector

** Connector ** — це попередньо створений компонент інтеграції, який обробляє автентифікацію, виклики API і відображення даних, необхідних для з’ єднання з певною системою або службою.

“Конектор Salesforce обробляє автентифікацію OAuth і надає типові методи для запиту контактів, можливостей та облікових записів — нам не потрібно писати HTTP-виклики вручну.”

• “Ми створили нетиповий роз’ єднання для застарілої системи інвентаризації, оскільки не існувало попередньо створеного роз’ єднання для її власного API SOAP.” *

Adapter

** Адаптер ** (подібний до з’ єднання) є компонентом, який перетворює дані між двома несумісними інтерфейсами або форматами даних.

“Адаптер XML- до- JSON перетворює відповідь SOAP постачальника у формат JSON, який очікується нашими внутрішніми системами.”

---

Перетворення повідомлень

Перетворення повідомлень

** Перетворення повідомлення ** — це процес перетворення повідомлення з одного формату або структури на інший під час його перенесення через шар інтеграції.

“Потік інтеграції перетворює запис клієнта з формату Salesforce в формат, очікуваний системою ERP, перед тим, як передати його далі.”

Схема картографування

** Привязка схеми ** визначає, як поля у схемі джерела відповідають полям у схемі призначення.

“Документ відображення схеми показує, що поля FirstName і LastName Salesforce відображаються на об’єднане поле FullName ERP з роздільником пробілу.”

Збагачення даних

** Збагачення даних ** додає інформацію до повідомлення з додаткових джерел під час потоку інтеграції.

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

---

Оркестрація і хореографія

Оркестровий квартет

** Оркестрація ** включає у себе центральний компонент (оркестратор), який викликає декілька служб у визначеній послідовності і збирає результати.

• “Потік створення замовлення організовано: шлюз API викликає службу інвентарізації, потім службу ціноутворення, потім службу оплати, і складає остаточну відповідь на замовлення.” *

Choreography

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

“Ми використовуємо хореографію для потоку після замовлення: служба замовлення публікує подію OrderPlaced; служба складу, служба сповіщення і служба аналітики підписуються і реагують незалежно.”

---

Інтеграційні моделі

Запит-відповідь

Викликаючий відсилає запит і чекає на відповідь — синхронне спілкування.

• “Потік оплати використовує запит- відповідь: інтерфейс викликає API ціноутворення і чекає відповіді щодо цін перед показом загальної суми.” *

Огонь и забвение

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

• “Після того, як замовлення буде зроблено, електронну пошту з підтвердженням буде надіслано за допомогою асинхронної черги повідомлень. Користувач отримує негайну відповідь, не чекаючи на відправку електронної пошти.”*

Кількість мертвих листів (DLQ)

У черзі ** dead letter queue ** зберігаються повідомлення, які не вдалося успішно обробити — для перевірки і повторення спроби.

• “Повідомлення, які не вдалося відіслати, буде перенаправлено до черги недійсних листів після трьох спроб. Інженер на виклику переглядає вміст DLQ щодня і вирішує, чи повторити спробу або відкинути.”*

---

Практичні фрази для інтеграційних інженерів

• • “Це синхронна інтеграція запит- відповідь — якщо система нижче за запитом повільна, виклик блокується.” *
• “ESB обробляє протокол посередництва між постачальником SOAP і нашими системами, заснованими на REST.”
• • “Ми потребуємо документа з відображення схеми, перш ніж ми зможемо збудувати з’ єднання.” *
• “Точка-точка добре для двох систем, але у нас їх дванадцять — нам потрібен концентратор.”
• • “Моніторинг черги мертвих листів є частиною нашого щоденного оперативного списку.” *

---

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

Національні мови: мова мовців, що не є рідними для країни

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

Одна з областей, де часто виникають нерозуміння, це рівень деталей, наданих в комунікаціях. Структурне твердження на кшталт «Інтеграція потребує поліпшення» може здатися нечітким і розчаруючим, особливо коли хтось провів години на усунення несправностей. Рідні носії часто цінують * явний * зворотній зв’язок - “Я помітив, що затримка між Сервісом A і Сервісом B постійно перевищує 50 мс. Чи могли б ви дослідити потенційні вузли у логіці перетворення?» Це не лише питання точності; це демонструє повагу до часу і зусиль розробника. Аналогічно, коли ви описуєте проблему колегі через Slack, не просто скажіть «Це не працює». Замість цього спробуйте щось на зразок: «Я бачу періодичні помилки з синхронізацією даних між середовищем стажування і виробництвом. Журнали вказують на потенційну проблему з відображенням схеми»

Інша проблема часто виникає з різних очікувань навколо термінології. Те, що може здатися вам цілком розумним поясненням – наприклад, опис ESB як «центру для всіх наших інтеграцій» – може бути неправильно інтерпретовано кимось, хто не знайомий зі звичайним індустріальним жаргоном. Важливо розуміти, що технічна мова розвивається і має певні конотації. Не думайте, що ваші знання є загальними. Активно шукати пояснення - “Чи можете ви розібратися, що ви маєте на увазі під “оркестрацією” в цьому контексті?” - це * потужний * інструмент як для навчання, так і для забезпечення точного спілкування. Крім того, пам’ятайте, що формулювання має значення; “Ми повинні оптимізувати інтеграцію” має іншу вагу, ніж “Ми повинні зробити це швидше”

Нарешті, звертай увагу на тон, який ти використовуєш. Навіть якщо ваш технічний опис є досить чітким, відверте або надто настійливе мовлення може пошкодити відносини і перешкодити співпраці. Сфокусуйтеся на конструктивній мові — « Давайте разом дослідимо потенційні рішення » замість « Вам слід це виправити ». Правило: коли ви сумніваєтеся, вибирайте ясність і ввічливість.

# Example using kubectl (Kubernetes) - a common tool for integration orchestration
kubectl get pods -n my-integration-namespace

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