Средний

7 мин

15K

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

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

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

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

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

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

• аналитики сами согласовывают и «мапят» поля;

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

• • аналитики сами согласовывают и «мапят» поля;

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

• аналитики сами согласовывают и «мапят» поля;

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

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

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

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

1. Минимальная поддержка со стороны программистов. Расширение ставится на любую систему. Да, да — с версии 8.3.23 всё летает, а до этой версии… ну, вы поняли — всё вылетает!

2. Бизнес‑аналитики занимаются настройкой и поддержкой. Они больше не пишут ТЗ и не убеждают программистов как надо. Экономия времени — до 80 %.

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

4. Нет необходимости релизить новые интеграции. Всё работает из пользовательского режима. Аналитики глубже познают структуру конфигурации и начинают писать более грамотные ТЗ. В итоге прокачивается вся команда!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Запускаем 1С!

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

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

• выбираем основной объект;

• удаляем ненужные поля;

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

Можно:

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

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

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

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

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

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

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

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

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

• Эндпоинт — строка (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); // Срезаем последнюю запятую
    КонецЕсли;
    Возврат ТаблЗнач;
КонецФункции

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

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

1. Создаём новую интеграцию:

   • указываем эндпоинт (например, /hs/MyIntegration/Data);

   • выбираем основной объект (например, «Справочник.Номенклатура»);

   • настраиваем поля в табличной части (указываем реквизиты, их типы и псевдонимы).

2. Нажимаем кнопку «Создать запрос» — в поле «Запрос» появится готовый текст SQL‑подобного запроса.

3. Нажимаем кнопку «Создать JSON» — в поле «JSONРезультат» появится сформированный JSON.

4. Проверяем HTTP‑сервис:

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

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

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

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

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

• Фильтрация данных. Добавить возможность задавать условия отбора (WHERE) прямо в интерфейсе.

• Пагинация. Реализовать постраничный вывод данных для больших таблиц.

• Аутентификация. Настроить базовую аутентификацию или токены для доступа к HTTP‑сервису.

• Логирование. Вести журнал запросов и ошибок для отладки и мониторинга.

• Кэширование. Кэшировать результаты частых запросов, чтобы снизить нагрузку на базу данных.

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

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

• экономит до 80 % времени аналитиков;

• освобождает программистов от рутинной поддержки;

• позволяет быстро настраивать обмен данными без релизов;

• даёт возможность масштабировать систему без больших затрат.

А что дальше?

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

• как работать с регистрами сведений и накопления?

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

• как организовать двусторонний обмен?

• как обеспечить безопасность данных?

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

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