Быстрые интеграции в 1С: прощайте, бесконечные переделки

Как же бесит, когда приходится переписывать интеграции снова и снова… Опять растет тех. долг, пока исправляешь названия полей в JSON…

Меня зовут Михеев Антон – я ведущий специалист модуля разработки 1С, и я прошел через это: переписывал интеграции по несколько раз в день, снова и снова «договаривался» с внешней системой. И вот, когда всё протестировано и пора стартовать, кто‑то вдруг менял структуру пакета!

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

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

Решение: конструктор внутри 1С

Мы собрались командой и начали строить конструктор внутри 1С, (описание решения будет ниже). Идея простая:

аналитики сами согласовывают и «мапят» поля;
программисты расширяют функциональность системы.
- аналитики сами согласовывают и «мапят» поля;
- программисты расширяют функциональность системы.

аналитики сами согласовывают и «мапят» поля;
программисты расширяют функциональность системы.

Это решение идеально вписалась в гибкую методологию AGILE. В нашем варианте AGILE звучит как «Айгуль» — это когда всё меняется так же быстро, как женское настроение.

Результаты внедрения

Сейчас наши системы работают на быстрых интеграциях на 70 % — постепенно переводим старые на быстрый режим. Что это даёт:

Минимальная поддержка со стороны программистов. Расширение ставится на любую систему. Да, да — с версии 8.3.23 всё летает, а до этой версии… ну, вы поняли — всё вылетает!
Бизнес‑аналитики занимаются настройкой и поддержкой. Они больше не пишут ТЗ и не убеждают программистов как надо. Экономия времени — до 80 %.
Программисты фокусируются на развитии функциональности. Они не тратят время на поддержку старых интеграций, а реализуют новые задачи.
Нет необходимости релизить новые интеграции. Всё работает из пользовательского режима. Аналитики глубже познают структуру конфигурации и начинают писать более грамотные ТЗ. В итоге прокачивается вся команда!

Сравнение бизнес‑процессов

Вспомните, сколько времени отнимает каждая интеграция: согласование полей, обсуждение с программистом, повторное согласование, тестирование, доработка, повторное тестирование… Несколько дней на интеграцию — это норма.

Бизнес‑процесс в компании «Виллариба» (старый подход):

ТТ → Анализ → Согласование → ТЗ → Разработка → Тестирование → Доработка → Тестирование → Старт.

Бизнес‑процесс в компании «Вилабаджа» (быстрые интеграции):

ТТ → Анализ → Согласование → Настройка БИ → Старт.

*Настройка БИ включает в себя маппинг и быстрое тестирование в пользовательском режиме без написания программного кода

Вы всё ещё кодите интеграции руками? В это время у нас junior‑аналитик сам настраивает интеграции: согласовывает поля с другими системами и запускает процессы. Время освобождается для разработки и новых интересных задач. Минимум поддержки — максимум результата!

Как подключить быстрые интеграции?

Если у вас те же проблемы и интеграции нужны уже вчера, то давайте вместе подключим быстрые интеграции с блэкджеком и плюшками к вашему проекту!

Шаг 1. Создаём новое расширение в 2 клика

Назовём его «Быстрый пробник» (или как вам больше нравится — это же ваше расширение!).

Шаг 2. Загружаем расширение

Просто загружаем «Быстрый пробничек» в систему. Готово! Какой же вы молодец!

Шаг 3. Настраиваем окружение

Ещё пара кликов — и всё заработает. Вам понадобится сервер типа IIS или Apache на сервере или компьютере с 1С. Обычно он уже есть, но если нет — придётся его установить или «замучить» сисадмина (они это любят).

Шаг 4. Активируем функциональность

Предположим, сервер работает. Далее:

Включаем опцию «Публиковать расширения HTTP‑сервиса автоматически».
Запускаем 1С!

Шаг 5. Начинаем работать

Теперь можно взять любой документ или справочник и выгрузить все нужные поля! Разве не чудо? Не нужно стоять в очереди к программисту и кодить. Всё работает как конструктор:

выбираем основной объект;
удаляем ненужные поля;
получаем готовый запрос для программиста (если нужен) и JSON для всего на свете.

Можно:

Взять готовый JSON и выгрузить прямо из текстового поля;

а можно постучаться в HTTP‑дверь:

http://Сервер/База/hs/Alabuga/Sync/Номенклатура

И прямо в браузере вы увидите результат!

Представьте, сколько времени вы сэкономите! Не нужно бегать и согласовывать всё по сто раз. Просто меняете набор реквизитов и псевдонимы полей — и готово. Без релизов, без программистов, без угрызений совести 🙂

Техническая реализация

Думаю, вы уже загорелись этой идеей. Хватайте программиста — пусть реализует всё по инструкции ниже (а сами пока можете наслаждаться быстрыми интеграциями).

Создаём документ «Интеграции»

Добавляем реквизиты:

Эндпоинт — строка (20 символов). Сюда будет стучаться другая система.
ОсновнойОбъект — строка (200 символов). Объект, который мы будем отдавать.
Запрос — строка неограниченной длины.
Табличная часть:

Реквизит — строка (100 символов);

ТипОбщий — строка (50 символов);

Псевдоним — строка (100 символов).

2. Добавляем форму

На форму добавляем виртуальный реквизит и оформляем её.

3. Реализуем логику выбора объекта

Чтобы определить тип объекта, нам понадобится «Чубака». В 1С это называется «Метаданные», но смысл тот же.

Копируем код:

&НаСервереПроцедура ВыборОсновногоПриИзмененииНаСервере()    МетаданныеОбъекта = ВыборОсновного.Метаданные(); // Получаем «Чубаку»    Объект.ОсновнойОбъект = МетаданныеОбъекта.ПолноеИмя(); // Определяем его тип («Существо.Чубака»)    ЗаполнитьДанные();КонецПроцедуры&НаКлиентеПроцедура ВыборОсновногоПриИзменении(Элемент)    ВыборОсновногоПриИзмененииНаСервере();КонецПроцедуры&НаСервере// Это чтобы реквизиты все увидеть как в конфигуратореПроцедура ЗаполнитьДанные()    Объект.Данные.Очистить();    Реквизиты = НайтиРеквизитыОбъектаСервер(Объект.ОсновнойОбъект);    Для Каждого Рек Из Реквизиты Цикл        НовРек = Объект.Данные.Добавить();        ЗаполнитьЗначенияСвойств(НовРек, Рек);

Теперь при выборе основного объекта вы точно знаете, что это за штука. Супер!

    КонецЦикла;КонецПроцедуры

5. Дорабатываем логику формирования запроса и JSON

Создаём общий модуль для формирования JSON отовсюду.

В общем модуле добавляем функции:

// Тут формируем массив структур ответа

Функция СоздатьJSONНаСервере(ТЗ) Экспорт    Запрос = Новый Запрос;    Запрос.Текст = ТЗ;    РезультатЗапроса = Запрос.Выполнить();    ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();    Массив = Новый Массив;    Пока ВыборкаДетальныеЗаписи.Следующий() Цикл        СтруктураДанных = Новый Структура;        Для Каждого Колонка Из РезультатЗапроса.Колонки Цикл            Значение = ВыборкаДетальныеЗаписи[Колонка.Имя];            СтруктураДанных.Вставить(Колонка.Имя, Значение);        КонецЦикла;        Массив.Добавить(СтруктураДанных);    КонецЦикла;    Возврат СформироватьJSON(Массив);КонецФункции

Тут формируем JSON

Функция СформироватьJSON(Структура) Экспорт    ЗаписьJSON = Новый ЗаписьJSON;    ЗаписьJSON.УстановитьСтроку();    ЗаписатьJSON(ЗаписьJSON, Структура);    Результат = ЗаписьJSON.Закрыть();    Возврат Результат;КонецФункции

6. Добавляем кнопки на форму

Добавим две кнопки:

«Создать запрос». Собирает запрос с помощью кода:

&НаКлиенте// Тут создаём запросПроцедура СоздатьЗапрос(Команда)    ТЗ = "ВЫБРАТЬ";    Для Каждого Строчка из Объект.Данные Цикл        РеквизитнаяЧасть = СоздатьРеквизитнуюЧасть(Строчка);        ТЗ = ТЗ + Символы.ПС + РеквизитнаяЧасть + " КАК " + Строчка.Псевдоним + ",";    КонецЦикла;    ТЗ = СрезатьПоследнийСимвол(",", ТЗ);    ТЗ = ТЗ + Символы.ПС + "ИЗ";    ТЗ = ТЗ + Символы.ПС + Объект.ОсновнойОбъект;    Объект.Запрос = ТЗ;КонецПроцедуры

«Создать JSON». Формирует JSON на основе запроса:

&НаКлиентеПроцедура СоздатьJSON(Команда)    JSON = Проб_ВызовСервера.СоздатьJSONНаСервере(Объект.Запрос);    Объект.JSONРезультат = JSON; // Сохраняем результат в поле документаКонецПроцедуры

7. Дорабатываем функцию создания реквизитной части

Функция СоздатьРеквизитнуюЧасть определяет, как обрабатывать разные типы данных.

Вот полный код:

&НаКлиентеФункция СоздатьРеквизитнуюЧасть(Строчка)    Если Строчка.ТипОбщий = "string" Тогда        Возврат Строчка.Реквизит;    ИначеЕсли Строчка.ТипОбщий = "bool" Тогда          Возврат "ЕСТЬNULL(" + Строчка.Реквизит + ", ЛОЖЬ)";    ИначеЕсли Строчка.ТипОбщий = "number" Тогда          Возврат "ЕСТЬNULL(" + Строчка.Реквизит + ", 0)";    ИначеЕсли Строчка.ТипОбщий = "date" Тогда          Возврат "ЕСТЬNULL(" + Строчка.Реквизит + ", " + Символ(34) + "01.01.0001" + Символ(34) + ")";    ИначеЕсли Строчка.ТипОбщий = "enum" Тогда          Возврат "ЕСТЬNULL(ПРЕДСТАВЛЕНИЕ(" + Строчка.Реквизит + "), " + Символ(34) + "" + Символ(34) + ")";    ИначеЕсли Строчка.ТипОбщий = "link" Тогда        Возврат "ПРЕДСТАВЛЕНИЕ(УНИКАЛЬНЫЙИДЕНТИФИКАТОР(" + Строчка.Реквизит + "))";    КонецЕсли;        // Если тип не распознан, возвращаем просто имя реквизита    Возврат Строчка.Реквизит;КонецФункции

8. Реализуем функцию срезания последнего символа

Функция СрезатьПоследнийСимвол убирает лишнюю запятую в конце строки запроса:

&НаКлиентеФункция СрезатьПоследнийСимвол(СимволДляСрезки, ТаблЗнач) Экспорт    ПоследняяЗапятая = СтрНайти(ТаблЗнач, СимволДляСрезки, НаправлениеПоиска.СКонца);    Если ПоследняяЗапятая = СтрДлина(ТаблЗнач) Тогда        ТаблЗнач = Лев(ТаблЗнач, СтрДлина(ТаблЗнач) - 1); // Срезаем последнюю запятую    КонецЕсли;    Возврат ТаблЗнач;КонецФункции

Проверка работы системы

После реализации всех шагов можно проверить, как всё работает:

Создаём новую интеграцию:
- указываем эндпоинт (например, /hs/MyIntegration/Data);
- выбираем основной объект (например, «Справочник.Номенклатура»);
- настраиваем поля в табличной части (указываем реквизиты, их типы и псевдонимы).
Нажимаем кнопку «Создать запрос» — в поле «Запрос» появится готовый текст SQL‑подобного запроса.
Нажимаем кнопку «Создать JSON» — в поле «JSONРезультат» появится сформированный JSON.
Проверяем HTTP‑сервис:

открываем браузер и переходим по адресу:

http://Сервер/База/hs/MyIntegration/Data;

убеждаемся, что сервер возвращает корректный JSON с данными.

Дополнительные возможности

Что ещё можно сделать, чтобы расширить функциональность:

Фильтрация данных. Добавить возможность задавать условия отбора (WHERE) прямо в интерфейсе.
Пагинация. Реализовать постраничный вывод данных для больших таблиц.
Аутентификация. Настроить базовую аутентификацию или токены для доступа к HTTP‑сервису.
Логирование. Вести журнал запросов и ошибок для отладки и мониторинга.
Кэширование. Кэшировать результаты частых запросов, чтобы снизить нагрузку на базу данных.

Итоги и перспективы

Мы реализовали конструктор интеграций, который:

экономит до 80 % времени аналитиков;
освобождает программистов от рутинной поддержки;
позволяет быстро настраивать обмен данными без релизов;
даёт возможность масштабировать систему без больших затрат.

А что дальше?

У вас наверняка возникли вопросы:

как работать с регистрами сведений и накопления?
как передавать табличные части и связанные документы?
как организовать двусторонний обмен?
как обеспечить безопасность данных?

Но это уже совсем другая история… Расскажу о ней в следующей статье, если эта вам покажется интересной. До скорых встреч!

Вы пишете интеграции руками? Делитесь мнением в комментариях

ссылка на оригинал статьи https://habr.com/ru/articles/1039770/