1С: обмен через OData и типовые конфигурации

Глава 6 руководства «Вайбкодинг в 1С и Битрикс24». Общие главы — про постановку задачи и проверку кода — там же.

Коротко

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

Обмен через OData

В платформе есть встроенный способ отдать данные наружу — автоматический REST-сервис. Его публикуют на веб-сервере, после чего к справочникам, документам и регистрам можно обращаться обычными запросами по сети. Ничего писать для этого не надо, надо настроить.

Это лучший вариант для интеграции, и вот почему он важнее самописного обмена:

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

Где помощник обычно ошибается. Он предлагает написать свой обмен файлами или свой веб-сервис, потому что таких примеров в интернете больше. Если задача — «отдать данные наружу», сначала проверьте, закрывается ли она публикацией стандартного сервиса.

Что спрашивать у помощника про OData

Здесь он полезен и надёжен, потому что речь про обычные сетевые запросы, а не про язык 1С.

• Разобрать структуру ответа и объяснить, что в нём.
• Написать код на стороне принимающей системы, который заберёт и разложит данные.
• Составить фильтр выборки, чтобы не тянуть всё.
• Обработать постраничную выдачу при больших объёмах.

Проверять всё равно надо: имена сущностей в сервисе строятся из имён метаданных по правилам платформы, и помощник их иногда угадывает неверно. Точный список всегда можно получить у самого сервиса.

Безопасность обмена

Пункт, который пропускают чаще всего.

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

Типовая конфигурация: главное правило

Типовая конфигурация обновляется поставщиком. Пока она на поддержке, обновления ставятся почти автоматически. Как только вы правите её напрямую, каждое обновление превращается в ручное сравнение и объединение — и так навсегда.

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

Расширения закрывают большую часть задач: добавить реквизит, изменить форму, перехватить процедуру, добавить отчёт или печатную форму.

Почему это важно для вайбкодинга

Прямая связь: помощник не знает, что ваша конфигурация типовая и стоит на поддержке. Он предложит поправить модуль напрямую, потому что так короче.

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

Что делать: в задаче помощнику прямо писать, что конфигурация типовая и доработка должна быть расширением. И проверять результат: если он предлагает изменить существующую процедуру, спросите, как то же самое сделать через расширение.

Что обычно выносят в расширение

Порядок примерно такой, от самого частого к редкому.

• Дополнительные реквизиты и сведения. Своё поле у справочника или документа. Закрывается расширением почти всегда.
• Изменения формы. Добавить поле, спрятать лишнее, поменять порядок элементов, дописать проверку при записи.
• Свои отчёты и печатные формы. Полностью новые объекты, к типовым не привязаны.
• Перехват процедур. Дописать поведение до или после типовой процедуры, не трогая её саму.
• Свои роли и права. Когда типовых разграничений не хватает.

Как формулировать задачу, чтобы получить расширение

Помощник по умолчанию предложит правку модуля. Разница в постановке задачи.

Даёт неправильный ответ: «как при проведении расходной накладной проверять остаток на складе».

Даёт правильный: «конфигурация типовая и стоит на поддержке, снимать нельзя. Нужна проверка остатка при проведении расходной накладной. Сделать расширением, через перехват процедуры проведения. Типовой модуль не изменять».

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

Неочевидное про OData

Три вещи, о которых узнают на практике.

• Имена в сервисе не совпадают с именами в конфигураторе. Они строятся по правилам платформы: у справочников, документов и регистров разные приставки. Помощник эти правила знает приблизительно и часто угадывает неверно. Точный список всегда отдаёт сам сервис — запросите его и работайте по нему, а не по догадкам.
• Выдача постраничная. Первый запрос вернёт часть данных, и если этого не учесть, вы будете думать, что записей мало. Помощник про это забывает почти всегда.
• Скорость. Сервис удобен, но это не способ выкачать миллион строк. Для больших объёмов лучше отбор на стороне 1С, а не выгрузка всего и фильтрация снаружи.

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

Чего расширениями не сделать

Честно о границах, иначе совет выглядит как обещание.

• Глубокая переделка логики проведения документа.
• Изменение структуры хранения данных в типовых объектах.
• Некоторые изменения в модулях, где поставщик не оставил точек расширения.

В этих случаях приходится снимать с поддержки — но это осознанное решение с понятной ценой, а не случайность из-за принятого совета помощника.

← Все девять глав руководства