Аудит інтеграцій з зовнішніми системами

IN-01. Окремі бізнес-процеси та критерії пошуку

Критичність: середня
Опис

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

Вплив

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

Рекомендації

  • Розробляти окремі бізнес-процеси під зовнішні інтеграції

  • Розробляти окремі критерії пошуку під зовнішні інтеграції

  • При оновленні контракту взаємодії, випускати нову версію бізнес-процесу та критерію пошуку залишаючи стару версію тимчасово для зворотної сумісності

IN-02. Симуляція АПІ зовнішніх систем

Критичність: середня
Опис

Проводити тестування вихідних інтеграцій з зовнішніми системами за допомогою функціональності симуляції АПІ зовнішніх систем перед виходом в промислове середовище. Не потрібно відкладати до промислового середовища повноцінну e2e перевірку відповідних бізнес-процесів.

Вплив

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

Рекомендації

  • Проводити тестування використовуючи можливості по симуляції АПІ зовнішніх систем

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

IN-03. Обробка помилок

Критичність: середня
Опис

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

На момент написання документа, за замовчуванням відповіді викликів зовнішніх систем з HTTP статус кодами 4** або 5\** вважаються помилками та генерують виключення. Тобто при використанні відповідного делегату, буде виконаний виклик, згенерована помилка та токен виконання бізнес-процесу буде повернутий до останнього wait-state. При асинхронному виклику, додатково ще будуть відпрацьовані retry policy.
Вплив

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

Рекомендації

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

  • При виникненні помилки може бути застосована одна з наступних тактик:

    • Відкат до останнього wait-state. Це може бути, як користувацька задача, так і старт асинхронного виконання. Слід зауважити, що якщо останній wait-state є користувацькою задачею, то відповідну помилку побачить користувач, і саме він повинен бути ініціювати повторну спробу. При асинхронному виконанні, буде спочатку відпрацьована політика retry policy, після чого буде сформований інцидент. В такому варіанті, повторну спробу повинен бути ініціювати адміністратор ресурсу.

    • Обробка помилок за допомогою Error Boundary Event на сервісній задачі зовнішнього виклику. Якщо помилка при виклику зовнішньої системи є станом, що можна передбачити та обробити відповідним чином, цю поведінку потрібно імплементувати в бізнес-процесі.

Детальніше про wait-state можна ознайомитись в офіційній документації Camunda