Что включить в задание на адаптер обмена между двумя системами

Подготовлено 23 октября 2026 года

В задании на адаптер обмена опишите не только поля, но и действие получателя: что должно появиться или измениться, какое подтверждение возвращается и кто видит итог. Для начала достаточно одного объекта и одного направления передачи.

Ни список технологий, ни фраза «связать две системы» не объясняют, что принимать в конце работы. Удобнее подготовить таблицу одного обмена и отдельно отметить неизвестные условия. По ней участники смогут проверить возможности систем и обсудить оценку.

Назовите две системы и один объект

Учебная ситуация: сайт собирает заявки на расчёт, а рабочая система помогает сотрудникам их разбирать. Адаптер должен передать новую заявку с сайта в эту систему. Источник — сайт, получатель — рабочая система, объект — одна заявка на расчёт. Обратная передача статусов пока не входит в этот пример.

Такая формулировка уже ограничивает разговор. Она не включает перенос прежней базы, замену сайта и перестройку работы отдела. Если нужен ещё один объект, например документ к заявке, добавьте его отдельным пунктом и проверьте, что меняется в составе.

До выбора языка программирования выясните, как источник отдаёт данные и как получатель их принимает. Если это ещё неизвестно, зафиксируйте вопрос владельцу системы. Название предполагаемой технологии не доказывает наличие рабочего интерфейса и прав на него.

Отделите данные от действия

Список полей отвечает на вопрос «что передаём». Требование к действию — «что получатель должен с этим сделать». Создать новую запись, дополнить существующую и заменить её целиком — разные действия, даже если набор полей одинаковый.

Для каждого поля полезно записать смысл, обязательность и источник. Например, «номер заявки» может обозначать номер сайта или номер рабочей системы. Если их два, не объединяйте их одним названием. Нельзя заранее считать, что одноимённые поля в разных системах имеют одинаковые значения и правила.

Опишите результат успешной передачи

В учебной постановке успех выглядит так: рабочая система приняла заявку, присвоила ей номер, а сотрудник может найти её с согласованными данными. Источник получил понятный результат операции. Сам факт отправки запроса ещё не подтверждает этот итог.

Назовите свидетельство: ответ получателя, запись в системе или другой доступный результат, который умеет проверить принимающий специалист. Уточните, какое сообщение означает только начало обработки, а какое — её завершение. Это зависит от конкретного интерфейса, поэтому готовое поведение стороннего сервиса не следует придумывать.

Согласуйте и точку наблюдения. Пользователь сайта, сотрудник получателя и технический специалист могут видеть разные сведения. В задании должно быть понятно, кому нужен итог и кто разбирает ошибку. Не обязательно показывать человеку весь технический ответ, если для его действия достаточно номера заявки и понятного состояния.

Зафиксируйте исключения для обсуждения

Одного успешного примера мало для согласования обмена. Добавьте несколько разных ситуаций и обсудите ожидаемое поведение. Таблица ниже — перечень вопросов к постановке, а не универсальный алгоритм повторных запросов.

Запишите неизвестный исход отдельно от подтверждённого отказа. Иначе команда может принять отсутствие ответа за разрешение отправить данные ещё раз. Если нужной проверки в доступном интерфейсе нет, это ограничение будущего решения, которое нужно рассмотреть до обязательства по внедрению.

Приложите документацию и безопасный пример

Для первого разбора нужны описание обеих систем, доступная документация, обезличенный образец объекта и контакт специалиста, который может подтвердить правила. Пароли и действующие секретные ключи в общей переписке для этого не нужны. Порядок защищённого доступа согласуют отдельно.

В документации проверьте операции, допустимые поля, результаты и ограничения, которые относятся именно к выбранному обмену. Ссылка на главную страницу сервиса не заменяет описание нужной операции. Если объект включает вложение, отдельно разберите условия передачи файла: это добавляет свой предмет проверки.

Для внешнего обмена с 1С сначала нужны готовый интерфейс и специалист заказчика. Внутренние доработки конфигурации 1С в предложение АИС по внешнему обмену не входят. Готовый коннектор также стоит проверить до заказа нового адаптера: возможно, он уже закрывает нужное действие.

Как понять, что задания достаточно для оценки

Попросите участников объяснить обмен по одной таблице. Если понятно, откуда приходит объект, что делает получатель, какое подтверждение требуется и где остаются открытые вопросы, можно переходить к оценке конкретного состава. Это ещё не обещание цены или срока.

Источник и получатель:
Один передаваемый объект:
Событие начала:
Поля, их смысл и обязательность:
Действие получателя:
Пример входа без реальных данных:
Ожидаемый результат и подтверждение:
Известный отказ:
Неизвестный исход и способ его выяснить:
Что не входит в этот обмен:
Документация и её владелец:
Кто проверит результат:
Что ещё неизвестно и кто уточняет:

Пустой пункт можно оставить вопросом с ответственным. Важнее честно назвать отсутствие документации или разрешённого доступа, чем заполнить таблицу предположениями. По такой карточке удобно обсудить один внешний обмен и выяснить, какие сведения ещё потребуются.