MTB ESB Documentation

Заявка на подключение

Какие данные нужны ESB Team для создания нового Consumer.

Заявка на подключение

Onboarding начинается с заявки в согласованном сервисном канале. Заявка должна описывать не только название Consumer, но и конкретный сценарий использования, требуемые API и технические ограничения.

Обязательные данные

ПолеЧто указать
Организация и системаЮридическое или внутреннее название организации и название приложения
API и операцииAPI, версия и необходимые resources/methods
Use caseКто и зачем инициирует вызов, какой результат ожидается
Тип взаимодействияSync, async или оба варианта
ТрафикСреднее и пиковое количество запросов за минуту
Технический контактИмя, рабочая почта и оперативный канал связи
Исходящие IPСтабильные адреса, с которых Consumer обращается к ESB
ОкружениеКак правило, сначала Sandbox
CallbackURL и требования защиты для async API
СертификатыПубличные сертификаты/CA, если применимы TLS или mTLS
Желаемая датаПлановая дата Sandbox и Production запуска

Как описать use case

Хорошее описание отвечает на четыре вопроса:

  1. Какая система инициирует запрос?
  2. Какую бизнес-операцию она выполняет?
  3. Какие API и операции для этого нужны?
  4. Что должно произойти при успехе, ошибке или недоступности Consumer?

Полезный формат

«Приложение [название] вызывает [API и операция], чтобы [бизнес-цель]. Ожидаемый режим — [sync/async], пиковая нагрузка — [N запросов/мин]. Для async-результата используется [callback URL]».

Шаблон новой заявки

Тип заявки: Onboarding (new)

Организация:
Название Consumer application:
API / версии / операции:
Use case:
Тип взаимодействия: sync | async | mixed
Средняя нагрузка:
Пиковая нагрузка:
Технический контакт:
Операционный контакт:
Исходящие IP:
Sandbox callback URL: не требуется | URL
Production callback URL: не требуется | URL
TLS / mTLS requirements:
Публичные сертификаты или ключи: переданы защищённым каналом | не требуются
Желаемая дата Sandbox:
Желаемая дата Production:

Что происходит после подачи

ESB Team:

  • проверяет полноту и обоснованность доступа;
  • определяет владельца согласования;
  • сверяет API, версию и требуемые resources;
  • назначает scopes и rate limit;
  • согласует network и certificate requirements;
  • создаёт Sandbox application и подписки;
  • передаёт environment details и credentials защищённым каналом.

Изменение существующего доступа

Для уже подключённого Consumer создаётся отдельная заявка Access modification. В ней указывается текущее приложение и только требуемая разница:

  • добавить или удалить API/resource;
  • изменить scope или роль;
  • изменить rate limit;
  • добавить или удалить IP;
  • заменить callback URL;
  • ротировать credentials, certificate или public key.

Изменение Production-доступа

Любое изменение должно содержать обоснование, окружение, желаемое окно и оценку обратной совместимости. Sandbox-доступ не предоставляет автоматического права на Production.

On this page