Мова: Українська
В ActivityInfo 4.0 з'явилися вебхуки: база даних могла зареєструвати URL-адресу, і ActivityInfo надсилала на неї JSON-повідомлення щоразу, коли запис додавався, редагувався або видалявся. Багато організацій побудували на цьому інтеграції — робочі процеси сповіщень у Power Automate або Pipedream, завдання синхронізації та сам конектор ActivityInfo для Power Automate.
Новий механізм автоматизації узагальнює цю ідею, і варто розібратися, що змінилося, що свідомо не змінилося, і як обирати між форматами корисного навантаження вебхуків.
Що змінилося
Вебхук версії 4.0 був єдиним фіксованим конвеєром: подія, необов'язкова формула фільтра та HTTP-запит в одному фіксованому форматі. Автоматизація — це потік кроків: тригер, що генерує дані, за яким слідує будь-яка комбінація кроків фільтра, емейла та вебхука.
Ключовим новим поняттям є дані кроку. Кожен тригер створює таблицю — для тригерів записів це один рядок, що містить поля запису разом із зарезервованими колонками _previous, _user та _trigger. Кожен наступний крок працює з цим самим рядком: фільтр оцінює свою умову на його основі, крок емейла інтерполює його в шаблони, а крок вебхука може серіалізувати його або інтерполювати в налаштовуване тіло. Одна модель даних, вивчена один раз, використовується всюди — і це та сама мова формул, що використовується в ActivityInfo для обчислюваних полів та показників.
Саме тому фільтри стали потужнішими: формула фільтра версії 4.0 могла бачити лише сам запис, тоді як крок фільтра може порівнювати з попередньою версією до редагування (_previous.STATUS != STATUS), переходити за посиланнями (CLINIC.NAME == "Mangina Health Post") та перевіряти виконавця (_user.email).
Імпорти тепер запускають тригери
Вебхуки ActivityInfo 4.0 не спрацьовували на зміни, що виникали внаслідок імпорту. Це виключення мало на меті захистити приймаючі системи від сплесків, але на практиці створювало реальні проблеми: записи, імпортовані масово, мовчки оминали робочі процеси, побудовані на вебхуках, і споживачі ніколи не могли бути впевнені, що бачили кожну зміну. Автоматизація скасовує це виключення — тригери записів спрацьовують на кожну зміну, незалежно від її походження: введення даних, мобільний додаток, API та імпорт, по одному запуску на запис.
Це зміна поведінки для перенесених вебхуків: автоматизація, перенесена з вебхука версії 4.0, починає отримувати події і для імпортованих записів. Якщо ваша приймаюча система не може впоратися зі сплеском одного запиту на кожен імпортований запис, додайте крок фільтра, щоб звузити коло подій, що проходять далі, або адаптуйте приймач для постановки вхідних запитів у чергу.
Що свідомо не змінилося
Наявні вебхуки продовжують працювати, байт у байт. Вебхук, створений в ActivityInfo 4.0, з'являється в новому редакторі як автоматизація — тригер запису, ваша формула фільтра (якщо вона була) та крок вебхука — і його формат корисного навантаження є сумісним з ActivityInfo 4.0: точна структура JSON, яку створювала версія 4.0, підтримується як опублікований контракт і закріплена набором регресійних тестів на основі знімка робочих подій. Інтеграції, побудовані на вебхуках версії 4.0, включно з потоками, що використовують конектор Power Automate, продовжують працювати без змін у корисному навантаженні, яке вони отримують — єдина відмінність у поведінці полягає в тому, що імпорт тепер також запускає події, як описано вище.
Підписання також переноситься без змін: ті ж самі заголовки standard-webhooks і та ж сама схема підпису v1 HMAC-SHA256, що обчислюється на основі точного тіла запиту.
Навіщо взагалі нові формати корисного навантаження
Формат 4.0 орієнтований на події: його тіло update містить лише поля, змінені подією, а значення полів були розроблені для моделі даних 4.0. Це робить його точним для відстеження змін, але незручним для двох поширених випадків:
«Просто дайте мені запис». Споживачі, яким потрібен повний поточний стан запису, мали самостійно об'єднувати
updateзprevious— а обчислювані поля були повністю відсутні, оскільки формат 4.0 будується на основі збережених значень запису, а обчислювані поля розраховуються під час зчитування. Стандартний формат (Standard) натомість надсилає дані кроку тригера: кожне поле форми для кожної події, включно з обчислюваними полями, у стабільній структурі, разом з_previous,_userта_trigger— саме те, що бачать формули, тож те, що ви тестуєте у фільтрі, отримує ваш споживач.«Приймач диктує формат». Чати та багато API вимагають специфічного тіла запиту. Раніше це означало використання проміжного сервісу лише для зміни формату JSON. Налаштовуваний формат (Custom) усуває цей крок: ви пишете тіло як шаблон з посиланнями
${...}, а ActivityInfo підставляє значення — екрановані для JSON, щоб документ залишався дійсним незалежно від вмісту даних. Сповіщення в Google Chat стає одним кроком вебхука з однорядковим шаблоном.
Вибір формату
| Ви... | Оберіть ||------------|--------|| Підтримуєте інтеграцію, побудовану на вебхуках версії 4.0, або використовуєте конектор Power Automate | Сумісний з ActivityInfo 4.0 | | Створюєте нову інтеграцію, яка використовує стан запису | Стандартний (Standard) | | Надсилаєте дані безпосередньо в систему, яка диктує формат тіла — Google Chat, Slack, API | Налаштовуваний (Custom) |
Перенесені вебхуки та підключення Power Automate зберігають формат, сумісний з ActivityInfo 4.0, тому для наявних інтеграцій нічого не змінюється; нові кроки вебхука за замовчуванням використовують Стандартний формат (Standard). Формат є налаштуванням для кожного кроку, тому ви можете додати Стандартний (Standard) або Налаштовуваний (Custom) вебхук поруч з наявним, сумісним з ActivityInfo 4.0, і переносити споживачів у власному темпі.