Коротко: вибір між сервісним обліковим записом і делегованим доступом — найважливіше архітектурне рішення інтеграції. Перший простіший, але всі користувачі бачитимуть однаковий зріз даних. Другий складніший і дає розмежування. Перехід між ними означає переробку.
Два варіанти й різниця між ними
Сервісний обліковий запис. MCP-сервер має власні облікові дані й звертається до Business Central від свого імені. Хто б не поставив запитання, доступ однаковий.
Плюси: просто реалізувати, передбачувано в поведінці, працює для фонових завдань і запусків за розкладом. Мінус один, але великий: розмежувати доступ між людьми неможливо.
Делегований доступ. Сервер діє від імені користувача, який поставив завдання. Business Central бачить конкретну людину й застосовує її дозволи.
Плюси: кожен бачить рівно те, що йому дозволено, у журналі видно реальну людину, не треба окремо проєктувати розмежування — воно вже є у ваших ролях. Мінус: складніше, бо треба провести ідентичність користувача через увесь ланцюжок від клієнта до Business Central.
Як обрати
Три запитання, які дають відповідь однозначно.
Чи мають різні люди бачити різні дані? Якщо так — делегований доступ, і далі можна не читати. Це найчастіший випадок у компаніях, де є кілька напрямів або юридичних осіб.
Чи працює система за розкладом без людини? Фонові завдання за визначенням не мають користувача, тож для них потрібен сервісний запис. У змішаному сценарії — обидва: делегований для інтерактивних запитів, сервісний для фонових.
Чи потрібно в аудиті бачити конкретну людину? Якщо так — делегований. Під спільним записом розібрати постфактум, хто що запитував, буде складно.
Найпоширеніша помилка — узяти сервісний запис «щоб швидше», плануючи додати розмежування пізніше. Пізніше це не додається: змінюється спосіб отримання доступу, змінюється обробка помилок, змінюється тестування.
Як влаштований потік доступу
Без коду, на рівні того, що відбувається.
Сервісний варіант. Застосунок зареєстрований у Entra ID, має власні облікові дані, отримує токен від свого імені й звертається з ним до Business Central. Business Central зіставляє застосунок із внутрішнім обліковим записом і застосовує його набір дозволів.
Делегований варіант. Користувач автентифікується, застосунок отримує токен від його імені, і Business Central бачить цього користувача з усіма його правами. Ідентичність доводиться пронести через клієнта, MCP-сервер і виклик — саме тут і зосереджена додаткова складність.
В обох випадках облікові дані живуть на сервері й ніколи не потрапляють до моделі. Модель формує намір викликати операцію; автентифікується сервер.
Що потрібно від адміністратора
Конкретний перелік, який варто узгодити до старту робіт — очікування цієї людини найчастіша причина простою в таких проєктах.
- Реєстрація застосунку в Entra ID.
- Видача прав доступу до Business Central.
- Згода адміністратора на ці права.
- Реєстрація застосунку всередині Business Central і зіставлення з обліковим записом.
- Окремі облікові дані для пісочниці й продуктиву.
Разом це приблизно пів години роботи. Проблема не в обсязі, а в тому, що ця людина зазвичай зайнята, а без неї розробка стоїть.
Дозволи всередині Business Central
Автентифікація відповідає на питання «хто», дозволи — на питання «що можна». Друге налаштовується окремо, і саме воно є реальною межею.
Правило одне: окремий набір дозволів під інтеграцію, зібраний під перелік операцій, а не копія ролі бухгалтера. Права на читання — рівно тих таблиць, які потрібні. Права на запис — окремо й тільки під конкретні операції. Для фінансових сценаріїв набір робиться без права проведення: це найнадійніший запобіжник, бо працює на рівні платформи.
Тут же задається область компанії, якщо юридичних осіб кілька. Детальніше — у розборі безпеки MCP.
Середовища й облікові дані
Окрема тема, яку зазвичай згадують надто пізно — коли конфігурація пісочниці вже поїхала в продуктив.
Правило просте: стільки середовищ у інтеграції, скільки у вашого Business Central, і в кожного власні облікові дані. Зазвичай це пісочниця й продуктив, іноді ще окреме середовище для розробки.
Що це означає на практиці:
- Окремий набір облікових даних для кожного середовища, і вони не лежать поруч у одному файлі конфігурації.
- Окремий обліковий запис Business Central у кожному, навіть якщо набір дозволів однаковий — інакше журнали змішуються.
- Пісочниця з реалістичним обсягом даних. Порожня не показує ані проблем зі швидкістю, ані реальних граничних випадків, а запит, який там миттєвий, у продуктиві може впертися в час очікування.
- Явна перевірка перед розгортанням: до якого середовища зараз під'єднана конфігурація. Це має бути видно, а не мати на увазі.
Остання позиція виглядає надмірною рівно до першого разу, коли тестовий прогін піде в продуктивну базу.
П'ять типових проблем
- Немає згоди адміністратора. Найчастіша. Права видані, згоди немає, звернення відхиляються. Виглядає як проблема коду, вирішується одним натисканням у портале.
- Застосунок не зіставлений з обліковим записом у Business Central. Автентифікація проходить, а дозволів нема ніяких.
- Облікові дані пісочниці в продуктиві. Очевидна проблема рівно до того моменту, поки не трапляється. Середовища мають бути розділені з першого дня.
- Токен протух посеред довгого завдання. Агент, що працює кілька хвилин, має вміти оновити доступ, інакше довгі завдання падають випадково.
- Делегований доступ дає менше, ніж очікували. Не помилка: користувач справді не має цих прав. Перевіряти треба в Business Central, а не в інтеграції.
Що зробите самі
Реєстрація застосунку й набір дозволів — це стандартні процедури, і ваш адміністратор зробить їх швидше за зовнішнього підрядника, бо знає вашу модель прав. Вибір між сервісним і делегованим варіантом — теж ваше рішення: воно про те, хто в компанії що має бачити.
Складна частина — реалізація делегованого доступу наскрізь і обробка граничних випадків: протухлі токени, часткові відмови, поведінка при нестачі прав. Це не багато коду, але це той код, де помилки виявляються не одразу.
Орієнтир: AI Discovery від $750 включає рекомендацію щодо моделі автентифікації з обґрунтуванням — і саме це рішення потім найдорожче переграти. Асистент від $3 000, агент від $6 000.
Часті запитання
Який варіант обрати, якщо не впевнені?
Делегований доступ, якщо є хоч якась ймовірність, що різні люди мають бачити різне. Перехід із сервісного запису на делегований — це переробка інтеграції, а не налаштування, тому невпевненість є аргументом на його користь.
Чи бачить модель наші облікові дані?
Ніколи. Вони живуть на MCP-сервері. Модель формує намір викликати операцію, а автентифікується й звертається до Business Central сервер.
Скільки часу займає налаштування?
Сама процедура — близько пів години в адміністратора тенанта. Проблема не в обсязі, а в тому, що цю людину треба дочекатися, тому домовлятися варто до старту робіт.
Чому інтеграція не бачить даних, хоча права видані?
Найчастіше — немає згоди адміністратора на видані права, або застосунок не зіставлений із обліковим записом усередині Business Central. Обидва випадки виглядають як помилка коду й вирішуються в налаштуваннях.
Чи можна використовувати обидва варіанти одночасно?
Так, і в змішаних сценаріях це нормально: делегований доступ для інтерактивних запитів, сервісний запис для фонових завдань за розкладом, які не мають користувача.
Що робити з довгими завданнями?
Передбачити оновлення доступу: агент, що працює кілька хвилин, інакше падатиме випадковим чином, коли термін дії токена спливає посеред роботи.