Коротко: MCP-сервер для Business Central — це застосунок, який публікує каталог операцій, автентифікується в ERP і виконує лише те, що в каталозі. Технічно він невеликий. Дорого коштує все, що навколо: рішення про доступ, проєктування операцій під модель даних і тестування відмов.
Куди насправді йде час
| Етап | Частка | Хто робить |
|---|---|---|
| Рішення про доступ і межі | ~15% | Бізнес + архітектор |
| Проєктування каталогу операцій | ~30% | Знавець BC + архітектор |
| Написання сервера | ~20% | Розробник |
| Тестування відмов і граничних випадків | ~25% | Розробник + бізнес |
| Розгортання, журналювання, документація | ~10% | Розробник |
Половина роботи — другий і четвертий рядки, і жоден із них не про написання коду. Саме тому оцінки на кшталт «підняти MCP-сервер за тиждень» технічно правдиві й практично марні: тиждень — це третій рядок.
Що вирішується до коду
Чотири рішення, які визначають архітектуру. Ухвалювати їх під час розробки означає переписувати.
Модель автентифікації. Сервісний обліковий запис чи делегований доступ. Друге складніше й дає розмежування між користувачами; перехід між варіантами — переробка. Розгорнуто в статті про автентифікацію через Entra ID.
Де розгортається сервер. У вашому середовищі Azure чи в підрядника. Впливає на те, де опиняються облікові дані й журнали, тож це радше питання політики даних.
Які дані не залишають контур. Перелік полів, які не передаються назовні взагалі. Складає бізнес, не розробник.
Чи буде запис. Якщо так, треба одразу вирішити, як обробляти повтори — інакше обрив зв'язку створить дублікати.
Від моделі даних до операцій
Найважча інтелектуальна частина. Проблема в тому, що бізнес формулює потребу в термінах питань, а Business Central зберігає дані в термінах документів і проводок, і між ними немає прямої відповідності.
Робочий порядок:
- Виписати запитання у формулюванні тих, хто їх ставить. Не «дані по дебіторці», а «хто з клієнтів затримує оплату більше, ніж зазвичай».
- Під кожним — з чого складається відповідь. Які таблиці, які поля, які умови, що виключається.
- Зафіксувати визначення. Що таке прострочення, з якої дати, які суми не рахуються. Тут виявляється, що два відділи рахують по-різному.
- Згрупувати в операції. Кілька запитань часто закриваються однією операцією з параметрами.
- Перевірити на повноту. Чи можна відповісти на кожне вихідне запитання, використовуючи лише операції з каталогу.
Крок 5 показує розриви до написання коду. Типовий приклад: усе є, але немає операції, яка повертає історію платіжної поведінки, — а без неї половина фінансових запитань не працює.
Приклади готових каталогів за напрямами — у статті про операції MCP.
Збірка сервера
Технічна частина. Що має бути в сервері незалежно від того, як ви його пишете:
- Публікація каталогу зі схемами параметрів і описами, за якими модель обирає.
- Перевірка параметрів до звернення до Business Central. Діапазони сум, коректність дат, допустимі коди компаній.
- Автентифікація й зберігання облікових даних, які ніколи не потрапляють до моделі.
- Явна відповідь «даних немає», яку неможливо сплутати з помилкою.
- Журналювання: яка операція, з якими параметрами, що повернулося, скільки тривало.
- Обробка обмежень запитів — Business Central обмежує інтенсивність, і сервер має поводитися передбачувано, коли впирається в ліміт.
Останні два пункти пропускають найчастіше. Журнал без параметрів робить розбір інциденту неможливим, а необроблений ліміт запитів виглядає як випадкові збої.
Тестування
Перевірка того, що операції повертають правильні дані, — очевидна частина: результати звіряють із порахованими вручну.
Менш очевидна й довша частина — перевірка відмов:
- Операція, якої немає в каталозі.
- Операція поза набором дозволів облікового запису.
- Параметри поза допустимими межами.
- Порожній результат проти помилки виконання.
- Часткова невдача при пакетній операції.
- Повторний виклик операції запису.
- Вихід на обмеження інтенсивності запитів.
- Спроба дістати дані іншої компанії.
Пісочниця для цього має мати реалістичний обсяг даних. Порожня не покаже ані проблем зі швидкістю, ані виходу на ліміти, а запит, який там миттєвий, у продуктиві може впертися в час очікування — і агент інтерпретує це як «даних немає».
Оновлення Business Central
Сервер — така сама інтеграція, як будь-яка інша, і релізи двічі на рік стосуються його безпосередньо.
Побудований на стандартному API — переживає оновлення, потребує перевірки. Практично це прогін ключових операцій у пісочниці з новою версією до того, як оновлення дійде до продуктиву: кілька годин роботи.
Той, що читає недокументовані внутрішні структури, — не переживає. Тому якщо потрібних даних немає в стандартному API, правильна відповідь — опублікувати власну API-сторінку на AL, а не обходити. Про межу доробок — у матеріалі коли AL виправданий.
Хто потрібен
- Людина, яка знає модель даних Business Central. Не «загалом ERP»: чим записи складу відрізняються від вартісних, як працюють облікові групи, чому маржа в двох звітах різна. Без цієї ролі виходить технічно коректний сервер, який віддає цифри, що не сходяться зі звітами.
- Розробник інтеграцій. API, автентифікація, обробка помилок, ліміти.
- Власник процесу з боку бізнесу. Той, хто вирішує, що правильно, і фіксує визначення.
- Адміністратор тенанта — на пів години, для реєстрації застосунку. Домовлятися заздалегідь: очікування цієї людини найчастіша причина простою.
Робити самим чи замовляти
| Частина | Самотужки |
|---|---|
| Виписати запитання й визначення | Тільки ви |
| Вибрати модель автентифікації | Ваше рішення |
| Реєстрація застосунку, набір дозволів | Так, ваш адміністратор |
| Написати сервер із кількома операціями | Так, якщо є розробник інтеграцій |
| Перекласти запитання в операції під модель даних BC | Потрібне знання системи |
| Обробка повторів і часткових невдач | Небагато коду, але помилки виявляються пізно |
| Перелік перевірок відмов | Складається з чужих помилок |
Перші чотири рядки цілком реально закрити власною командою — і варто, бо це дає ясність щодо обсягу. Пілот із трьома-чотирма операціями на пісочниці за тиждень покаже, чи взагалі корисно те, що ви задумали.
Орієнтир, якщо вирішите замовляти: AI Discovery від $750 — на цьому етапі складається каталог операцій і рекомендація щодо архітектури, документ лишається вам незалежно від продовження. Асистент від $3 000, агент із операціями запису від $6 000, рішення під конкретний бізнес-процес від $10 000. Хостинг сервера й використання моделі — окремі поточні витрати.
Часті запитання
Скільки часу займає побудова MCP-сервера?
Технічна збірка з кількома операціями — тиждень-два. Повний цикл із проєктуванням каталогу й тестуванням відмов — від чотирьох до восьми тижнів. Половина часу йде на роботу, яка не є програмуванням.
Чи можна зробити це власною командою?
Так, якщо є розробник інтеграцій і людина, яка знає модель даних Business Central. Без другої ролі виходить сервер, який віддає технічно коректні цифри, що не сходяться зі звітами, і причину шукають довго.
Що робити, якщо потрібних даних немає в стандартному API?
Опублікувати вебсервіс або власну API-сторінку на AL. Це невелика доробка. Читати недокументовані внутрішні структури не варто: таке рішення не переживе оновлення.
Скільки операцій у першій версії?
Вісім-п'ятнадцять під один напрям. Перелік має вміщатися в документ, який читається за один раз, — інакше його ніхто не перевірить, а модель почне плутати схожі операції.
Що перевіряти перед оновленням Business Central?
Прогін ключових операцій у пісочниці з новою версією до того, як оновлення дійде до продуктиву. Для рішення на стандартному API це кілька годин.
Скільки коштує підтримка сервера?
Хостинг, моніторинг і перевірка після кожного великого релізу — два рази на рік. Плюс періодичний перегляд каталогу операцій: кожен доданий за рік зручний інструмент розширює поверхню доступу.