Коротко: технічна частина підключення займає менше часу, ніж підготовка до неї. Найдовші затримки — не в коді, а в очікуванні прав адміністратора тенанта й узгодженні того, що агенту дозволено. Обидві речі можна почати заздалегідь.
Що підготувати до початку
Три речі, відсутність яких зупиняє роботи вже на другий день:
- Людина з правами адміністратора тенанта. Потрібна для реєстрації застосунку й надання згоди. Не «доступ на місяць», а конкретна людина, яка виконає дві дії за півгодини.
- Пісочниця Business Central з реалістичними даними. Порожня пісочниця не годиться: на ній не видно ані проблем із продуктивністю, ані реальних крайніх випадків.
- Власник процесу з боку бізнесу. Той, хто вирішує, що правильно. Без нього проєкт стає на першому спірному випадку й чекає.
Крок 1–2: реєстрація й доступ
Крок 1. Реєструється застосунок у Microsoft Entra ID. Йому видаються права доступу до Business Central і надається згода адміністратора. Тут же обирається спосіб автентифікації, і це рішення визначає всю подальшу роботу:
- Сервіс-до-сервісу — агент працює під власним технічним записом. Простіше, але всі користувачі бачитимуть однаковий зріз даних.
- Делегований доступ — агент діє від імені того, хто поставив завдання. Складніше, але кожен бачить своє, а журнал показує реальну людину.
Обирати треба тут, а не потім: перехід між варіантами — це переробка інтеграції.
Крок 2. Застосунок реєструється всередині самого Business Central і зіставляється з обліковим записом. Формальна операція, яка виконується за кілька хвилин, але без кроку 1 недоступна.
Крок 3: набір дозволів
Створюється окремий набір дозволів під агента. Не копія ролі бухгалтера, не «повний доступ, потім звузимо» — звужувати ніхто не буде, це закономірність, а не гіпотеза.
Практичний спосіб: випишіть операції, які агент має виконувати, і видайте права рівно під них. Якщо агент готує нагадування по дебіторці, йому потрібне читання книги клієнтів і документів продажу — і, ймовірно, більше нічого. Право запису додається окремо й тільки під конкретні операції.
Тут же вирішується область компанії, якщо у вас кілька юридичних осіб, і призначається окремий обліковий запис кожному агенту, якщо їх планується кілька.
Крок 4: ендпоїнти
Перевіряється, чи є потрібні дані у стандартному API. Практичне правило: спершу все, що можна, беруть звідти, і лише те, чого бракує, публікують окремо.
Три джерела в порядку переваги: стандартний REST API, вебсервіси OData, власні API-сторінки на AL. Останнє — невелика доробка, але її варто виявити зараз, а не посеред розробки, бо вона потребує залучення розробника й окремого розгортання. Детальніше про способи — у матеріалі як підключити AI до Business Central.
Крок 5: перелік операцій
Найважливіший крок і той, від якого залежить і безпека, і поведінка агента.
Кожна операція описується вузько: назва, що робить, коли застосовувати, які параметри приймає й що повертає. «Отримати прострочену заборгованість понад суму за період» — правильно. «Виконати запит» — неправильно, бо переносить межу безпеки з вашого коду в судження моделі.
Операції запису робляться окремо й свідомо: не «оновити запис», а «оновити дату наступного контакту в картці клієнта». Кожна перевіряє параметри до виклику Business Central.
Готовий перелік має бути документом, який можна прочитати за один раз. Якщо його неможливо охопити поглядом, він завеликий для першої версії.
Крок 6–7: пісочниця й тестування відмов
Крок 6. Агент збирається й запускається на пісочниці. Мета — не «щоб працювало», а щоб люди, які ним користуватимуться, побачили результати на реальних сценаріях і сказали, що не так. Цей етап скорочувати не варто: зауваження, отримані тут, коштують у рази дешевше за ті самі зауваження після запуску.
Крок 7. Тестування того, від чого агент має відмовитися. Пропускають найчастіше, а визначає воно найбільше. Мінімальний перелік перевірок:
- Запит операції, якої немає в переліку — агент має повідомити, що не може, а не шукати обхід.
- Операція поза набором дозволів — Business Central відмовляє, агент коректно це обробляє.
- Порожній результат — агент розрізняє «даних немає» і «сталася помилка» й не заповнює пропуск припущенням.
- Часткова невдача — з дванадцяти записів три не вдалися: агент завершує по дев'яти й окремо повідомляє про три.
- Ліміт кроків — агент, який не може досягти мети, зупиняється, а не крутиться.
Крок 8–9: продуктив і спостереження
Крок 8. Вихід у продуктив із власними обліковими даними, власним набором дозволів і записаним переліком того, що агенту дозволено. Останнє — документ, а не усна домовленість: через пів року ніхто не пам'ятатиме, що вирішили.
Крок 9. Спостереження. З першого дня фіксуються: кількість кроків на завдання, частка завершень за лімітом, відмови через дозволи і — головне — скільки підготовленого людина відхиляє. Остання метрика єдина відповідає на питання, чи корисний агент, і її треба закладати одразу, бо ретроспективно її не відновити.
Три місця, де проєкти застрягають
Права адміністратора тенанта. Розробка впирається в очікування людини, яка може надати згоду. Починати домовлятися варто до старту робіт, а не тоді, коли все інше готове.
Невизначені правила. Виявляється, що «прострочення» рахують по-різному у двох відділах, і ніхто не готовий сказати, як правильно. Проєкт стоїть, поки бізнес не вирішить. Це не технічна проблема, і підрядник її не розв'яже.
Обсяг, що росте під час розробки. «Раз уже робимо, додаймо ще…» — і замість чотирьох тижнів виходить чотири місяці. Перший агент має бути вузьким; другий процес додається дешевше, бо вся інфраструктура вже є.
Загальний вступ у тему — в повному гайді по агентах, а компоненти рішення розібрані в статті про архітектуру.
Часті запитання
Скільки часу займає технічне підключення?
Сама інтеграція — від кількох днів до двох тижнів. Основний час проєкту йде на визначення правил, побудову переліку операцій і тестування відмов. Реалістичний строк першого вузького агента — від чотирьох до восьми тижнів після discovery.
Хто має надати доступ у Entra ID?
Адміністратор вашого тенанта: потрібні реєстрація застосунку, права доступу до Business Central і згода адміністратора. Це півгодини роботи, але домовлятися про неї варто до старту — очікування цієї людини найчастіша причина простою.
Чи можна підключити агента до продуктиву одразу?
Технічно так, робити не варто. Пісочниця потрібна не для перевірки з'єднання, а щоб люди побачили результати на реальних сценаріях до того, як агент почне щось змінювати.
Що робити, якщо потрібних даних немає в стандартному API?
Опублікувати вебсервіс або зробити власну API-сторінку на AL. Це невелика доробка, але вона потребує розробника й окремого розгортання, тому виявляти таку потребу треба на кроці 4, а не посеред розробки.
Скільки операцій має бути в першій версії?
Стільки, скільки поміщається в документ, який читається за один раз. Якщо перелік неможливо охопити поглядом, обсяг завеликий: тестування розтягнеться, а критерій успіху розмиється.
Що робити перед оновленням Business Central?
Прогнати ключові сценарії агента в пісочниці з новою версією до того, як оновлення дійде до продуктиву. Для рішення на стандартному API це кілька годин.