Правила обмена больше не нужны

План выступления:

• начнем с обзора – какие инструменты и технологии используются для обменов с 1С-системами сейчас;

• я расскажу, почему я перестал их использовать, и что меня заставило разработать новый фреймворк liteExchange;

• расскажу, что он мне дает в цифрах и кейсах, и на каких технологиях он основан;

• бонусом поделюсь ссылками на GitHub, на группу в Telegram, где можно обсуждать продукт – все это находится в открытом доступе.

Немного о себе:

• в отрасли я 11 лет;

• за это время прошёл путь от рядового разработчика до руководителя группы – в группе в разное время было до десяти человек;

• за эти 11 лет я также побывал в ролях разработчика коробочного решения, руководителя направления, побывал в шкуре руководителя проектов или лидирующего разработчика, архитектора – все это происходило в компании-франчайзи.

• сейчас я покинул франчайзи и занимаюсь цифровой трансформацией на одном из производственных предприятий Санкт-Петербурга.

• кроме прочего, я автор нового фреймворка – liteExchange.

Какие есть инструменты для обмена данными с 1С

Чтобы быть в контексте, нужно будет обязательно чуть-чуть погрузиться – будет немного лирики, прежде чем мы пойдем к технической части.

Говоря об инструментах обмена, я сознательно объединяю в единое целое и перемешиваю в кучу инструменты, решения, технологии – прошу сильно не кидаться в меня комментариями, что я не прав.

• Очень долгое время практически все обмены в 1С реализовывались при помощи инструмента (фреймворка) «Конвертация данных 2.0», где разрабатывались правила обмена. Сам обмен производился через план обмена или с помощью обработки «Универсальный обмен в формате XML».

• Позже появилась конфигурация «Конвертация данных 3.0», где можно было описывать правила конвертации по технологии EnterpriseData.

• Кроме этого, существует обработка по обмену между одинаковыми конфигурациями «Выгрузка и загрузка XML».

Наверное, всем знакомы правила обмена XML – использовать их просто и понятно, все плюсы и минусы этого инструмента известны. Я расскажу, какие минусы не устроили конкретно меня.

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

• В самой обработке обмена 35 тысяч строк кода, если что-то идет не так, приходится это отлаживать.

• Дальше я подробнее расскажу, почему я не стал пользоваться правилами обмена.

Что касается обработки «Выгрузка загрузка XML», то ее можно использовать только для разовых случаев и для одинаковых конфигураций – для постоянного обмена она тоже не совсем подходит.

Другие инструменты для обмена – я считаю, что они подходят для высоконагруженных систем, с которыми я не сталкивался на практике. Это:

• разного рода «кролики» – разноцветные RabbitMQ;

• шина данных DATAREON MQ;

• Apache Kafka и прочие аналогичные инструменты.

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

На Инфостарте есть миллион решений для обменов данными:

• через COM-соединение;

• с использованием HTTP-сервисов;

• с использованием веб-сервисов;

• с сохранением данных в файл в формате XML, TXT или CSV – неважно.

Все эти разработки я тоже специально смешиваю в кучу, используя в контексте технологии для решения задач обмена. Многие из них меня тоже не устроили:

• COM – это медленное и платформозависимое решение, с ним часто возникают проблемы

• веб-сервис – уже лучше, но все-таки там надо знать XDTO, технологию работы с форматом XML – записывать туда данные либо через XDTO, либо вручную. Ключевое слово «Знать», надо очень много знать.

Почему существующие инструменты не подходят?

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

Два года назад я занял должность руководителя отдела внедрения в одной из крупных фирм-франчайзи. У нас был молодой отдел, где работало десять сотрудников, которые один-четыре-шесть-десять месяцев назад увидели конфигуратор. При этом у нас было много задач по обмену данными, а времени на то, чтобы изучать десяток инструментов, скачивать какие-то готовые обработки и их изучать – не было. Поэтому пришлось найти и выбрать какое-то одно решение, с которым будем в последствии работать.

Недавно я собрал на Инфостарте всю информацию по решениям, которые перечислял выше, в виде таблички, и выложил все это в публикации //infostart.ru/public/1221657/.

Там я постарался изложить свои личные впечатления, связанные с выбором решения или технологии для решения задачи обмена данными.

В конечном счете победил обмен с использованием формата JSON с передачей данных через HTTP-сервис.

Почему?

• На мой взгляд, HTTP-сервис – это наиболее популярное, наиболее быстро работающее решение из тех, что может предложить платформа 1С без использования внешних компонент. Да, там приходится ставить веб-сервер, но достаточно часто он у организации уже по факту есть – осталась им воспользоваться.

• Использование HTTP-сервисов позволяет писать и реализовывать задачи по обмену максимально нативно, без использования каких-то дополнительных библиотек, без использования там сложных инструментов, существующих на рынке.

• Кроме прочего, использование HTTP-сервисов дает очень интересный эффект для бизнеса. За последние пару десятков лет уже все привыкли, что обмен с 1С происходит по расписанию раз в день или раз в час, что это происходит с какими-то задержками, тормозами. После этого демонстрация того, что скорость обмена данными может быть равна скорости переключения двух окон программы 1С, вызывает у бизнеса очень интересный вау-эффект, и они готовы это покупать. А если они готовы это покупать, зачем вам этому мешать?

#liteExchange

Несколько слов про liteExchange – что представляет собой этот инструмент?

Я постарался тот код, который чаще всего используется (это передача данных в интернет, конвертация в JSON, получение входящих данных и их распаковка, если они были зазипованы), объединить в готовое решение – в десяток команд, которые достаточно выучить, чтобы решать свои задачи дальше.

Собрал все это в расширение, дал ему название liteExchange и придумал небольшую методологию, как этим пользоваться.

Показатели обмена через liteExchange

Цифры, которые у меня получались при использовании фреймворка liteExchange:

• Три десятых секунды на обмен из «Комплексной автоматизации 2.4» в «Комплексную автоматизацию 1.1». Максимальная скорость, которая была достигнута в этом кейсе – 176 миллисекунд, а средняя – 0.3 секунды.

• Обратный обмен выполнялся чуть дольше, но это происходило из-за того, что в более сложной программе КА 2.4 документ дольше записывается и проводится.

• Интересная особенность у меня возникла при обмене через РИБ – транзакция в 1С длилась дольше, чем сам обмен и иногда еще и откатывалась – приходилось сознательно вносить в код “замедляторы” – функции «пауза» и т.д. Реализовали для этого во фреймворке интересное решение.

• Очень интересные результаты получались при обмене не между двумя 1С, а между 1С и чем-то сторонним – чаще всего, это мобильное приложение или личный кабинет заказчика на сайте. Это максимально быстрый обмен, потому что там используется очень маленькие пакеты данных.

Кейсы обменов

За последний год я понял, что сообщество и моих коллег больше всего интересует кейсы обменов между двумя базами 1С. Опишу несколько вариантов использования.

1С vs 1С

Постепенный переход на новую систему. У одного из наших заказчиков была задача перехода с «Комплексной 1.1» на «Комплексную 2.4». У другого заказчика ситуация была похожая – там был переход с УПП на ERP. Эти два кейса встречаются наиболее часто, и для них имеет смысл использовать мое решение, а не какие-то готовые правила обмена – сейчас объясню, почему.

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

Как это можно обойти? Можно реализовать постоянную бесшовную интеграцию между двумя системами (старой и новой) – это позволяет без особых усилий переходить постепенно, растянуть процесс перехода примерно на год, если это требуется, или на несколько месяцев, переводить компанию по отделам, по чуть-чуть. При этом важно очень быстро передавать данные одной системы в другую, чтобы не возникало коллизий, что один отдел в одной системе продал товар, а другой отдел в новой системе тот же самый товар продал.

Торговля «с колес». Во втором кейсе менеджеры торговали с колес, а складские сотрудники работали в отдельной программе – при этом менеджер видит, что приехала машина, очень хотят торговать этим товаром, но не могут, потому что обмен все еще идет. В том случае три минуты задержки вызывали до пяти звонков в техническую поддержку с вопросом: «Где наш товар? Хотим продавать!» Казалось бы, три минуты вроде бы ни о чем, но в данном случае это было важно.

Централизованная система для НСИ. Еще один кейс, который используется в последнее время, когда появляется необходимость централизовано хранить базу нормативно-справочной информации в виде MDM-системы. Это особенно актуально, если у нас основная система, например, ERP, а информация по ее номенклатуре нужна на сайте или в какой-то сторонней базе WMS, или в учетной системе для дилеров, или в учетной системе для менеджеров на портале (опять же сайт). В этом случае появляется потребность базу НСИ вынести куда-то отдельно, чтобы она выступала источником данных через HTTP, а нам не приходилось всю ERP светить на весь интернет.

Опять же, раз мы вынесли данные в интернет, в отдельную базу для управления НСИ было бы неплохо потом их обратно синхронизировать, если мы вынесли данные в отдельную базу «Управление НСИ», было бы неплохо обратно их синхронизировать с ERP. И тут вопрос уже не в скорости, а в том, что можно написать код один раз и полученное решение в формате API будет применимо для всех получателей информации – нам не нужно писать обмены отдельно для сайта, отдельно для ERP, отдельно для учетных систем дилеров.

Быстрее, чем РИБ. Всего пару раз, но очень показательно – встречались решения на замену платформенного механизма распределенных информационных баз. Поскольку п умолчанию обмен в РИБ работает по расписанию, у него, опять же, может возникнуть ситуация, когда один и тот же товар можно продать из разных учетных систем дважды. Чтобы избежать этой коллизии, надо значительно ускорить обмен вплоть до бесшовной интеграции, позволяющей делать обмен за секунду.

Любые попытки ускорить обмен типовыми средствами не увенчались успехом, пришлось его переписать. Но зачем придумывать что-то новое – я взял свой фреймворк, и реализовал на нем обмен. При этом стандартный РИБ тоже остался в качестве страхующего механизма – он, не торопясь, догружает данные, которые не нужны в оперативном режиме.

1С vs Other

Лично мне больше нравится кейс, когда обмен данными производится между двумя базами 1C, а между 1С и сторонними системами.

Обмен между 1С и сайтом. Многие разработчики знают о наличии формата CommerceML, есть готовое решение для этих обменов, но я им не пользуюсь, потому что в моих кейсах размеры данных при обмене в этом формате были достаточно большими, и сайт иногда падал при обмене.

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

Обмен между 1С и мобильным приложением. По сути, 1С выступает бэкендом для сайта или для мобильного приложения. Например, в GooglePlay можно найти мобильное приложение «Вместе» для благотворительных фондов. Вся его серверная часть, весь бэкенд, написан на платформе 1С и использует liteExchange для передачи данных или обработки данных в запросах мобильного приложения. Нагрузка при этом создается невысокая.

Кстати, важно понимать, что, если мы говорим о высоконагруженных системах, я даже не пытаюсь применять liteExchange – там нужны все-таки нативные решения со стороны сайта, со стороны мобильного приложения – шины данных что-то такое. А для малых нагрузок – скажем до 100 пользователей 1С, до нескольких сотен документов «Заказ» в день, 10-20 тысяч SKU, две-три тысячи сообщений обмена в день, но не сотни тысяч – в этом случае это решение подходит.

Примеры применения

Дальше будут образцы кода, показывающие порядок применения фреймворка liteExchange, но я все-таки чуть-чуть расскажу, как мы решали задачи обмена раньше.

Берем конфигурацию «Конвертация данных 2.0» или «Конвертация данных 3.0», загружаем туда метаданные, запускаем мастера или вручную синхронизируем данные, расставляем галочки. Казалось бы, очень удобно – первый релиз правил обмена можно получить достаточно быстро. Но что делать потом – когда эти правила не работают или надо вносить изменения?

Лично меня не устраивает скорость отладки этих инструментов и скорость выполнения самого обмена.

В первую очередь, все-таки скорость отладки. Когда разработчик вносит изменения – это может быть тысяча очень маленьких изменений. При этом на каждое изменение надо открыть конвертацию, ввести там пару строк кода, сохранить правила; загрузить правила в обработку, выгрузить данные; понять, что ничего не получилось, и начать сначала. И так умножаем на 1000 раз – очень сильно тратится время.

С другой стороны, когда надо отладить код для КД 3.0 – надо сохранить модуль менеджера, переподключить обработку, а она что-то не переподключается, не сохраняется, не отлаживается – было много косяков, возможно они были связаны с моей неопытностью.

Это был достаточно древний травматический опыт, который убедил меня в том, что правила конвертации мне не нравятся.

Мне было проще написать код на выгрузку данных – на слайде показано порядка 30-40 строчек кода на выгрузку данных в документ «Реализация товаров и услуг».

Естественно, в первый раз этот код писался вручную, а впоследствии я сделал инструмент, который позволяет, описав сопоставление данных на уровне инструмента «Конвертация данных 2.0», сгенерировать нужный код, скопировать, вставить его, и всю последующую отладку вести сразу в обработке.

Именно этот код впоследствии исполняется.

Сама «Конвертация данных» дальше уже не используется, она больше не нужна. Если нужно что-то поправить, я правлю одну-две строчки кода. Обработка сохраняется – на изменение нужно потратить пару секунд. Не пара минут, а именно пара секунд.

Сами данные передается по протоколу HTTP.

Обратите внимание, что в этой функции о передаче данных через интернет вообще ничего не сказано, потому что фреймворк занимается передачей данных самостоятельно, а программист в 1С оперирует простыми, привычными ему типами данных – структура, массив, строка, дата, число. И используя кнопочки Shift+F9 (или «Вычислить выражение»), может визуально увидеть, что он передает.

В базе-источнике программист получает структуру массивов или элементов, в базе-приемнике тоже без каких-либо усилий, без какого-то дополнительного кода – точно такую же структуру, чтобы разобрать ее.

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

Я на слайд вывел покрупнее кусочек кода по выгрузке элемента справочника – здесь нужна всего лишь одна строчка.

Фреймворк делает большую часть работы за программиста автоматически.

Функция «ДобавитьСсылкуНаСправочник()» – это полностью автоматическая конвертация. Точно так же, если нас устраивает синхронизация по уникальным идентификаторам, если структура метаданных плюс-минус похожа, то код можно и не писать. Я покажу этот пример чуть дальше, через пару слайдов.

В случае с обработкой запроса с сайта – вот пример из мобильного приложения «Вместе», про которое я говорил.

Здесь тоже 40 строчек кода, и это обработка одного запроса мобильного приложения. Всего было порядка 20 запросов у мобильного приложения. Соответственно, менее 1000 строчек кода и бэкенд готов.

По времени появление первого релиза заняло два дня, после чего потребовалась еще неделя отладки, пока мы договаривались о нюансах.

В этом обмене:

• нет ничего, что связано с передачей данных,

• я как разработчик здесь полностью абстрагирован от необходимости распаковки данных, хотя, они приходят в сжатом виде.

• я абстрагирован от понятия заголовков запросов

• здесь почти нет ничего по-английски, кроме имен полей

Это позволяет мне работать с обменом в привычном для меня окружении конфигуратора.

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

Дальше идет пример по упрощению выгрузки РИБ – это, скорее, частный случай, потому что в целом для РИБ есть готовое решение, которое, если работает, то не трожь.

Чтобы реализовать отмен через РИБ даже не приходится использовать какие-то хитрости с кучей кода. Фактически, я всего лишь вызываю одну функцию (показано на первой картинке), в которую при обработке вставляются служебные параметры для логирования, для удобства.

РИБ работает автоматически со скоростью менее секунды.

Здесь показано продолжение этого кода. Это работа фонового задания – тут очень много логирования, его тоже можно опускать при желании.

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

Технически подкованный специалист может оценить, что тут большая часть кода не относится к обмену данными вообще. Сам обмен здесь происходит в функции леРаботаСJSON.ДанныеВJSON(), где данные преобразуются в JSON.

Обратите внимание, что мы здесь реализовали запись в файл, потому что поднимать веб-сервер для разового обмена смысла не было.

Гораздо интереснее происходит обработка данных на этапе загрузки. Те же самые данные, что ранее были сохранены, теперь мы загружаем – здесь тоже не так много строчек кода, потому что, когда метаданные похожи фреймворк управляются с работой по переносу автоматически, не приходится кодить.

Если очень надо, то в функции «ЗагрузитьОбъект()» сам объект, который может быть получен, можно модифицировать – дозаполнить какой-то спецификой, преобразовать.

Ссылки

По состоянию на 2021 год существует два ресурса, где можно познакомиться со фреймворком:

• Исходный код фреймворка, про который я рассказывал, доступен на GitHub в репозитории https://github.com/liteappsru/liteExchange. К сожалению, он пока плохо документирован, но со временем документация появится. Исходники заброшены и устарели. Актуальная версия проходит отладку. Подпишитесь, но не скачивайте)

• Канал в Телеграме https://t.me/liteExchange_group, где можно вести обсуждение, задавать вопросы. Там присутствую я и мои коллеги – порядка двухсот человек. Если прокрутить обсуждение в начало группы – там я выкладывал кейсы, которые мы реализовали летом и осенью 2019 года. Все это можно применять у себя, чтобы понять, а надо ли вообще что-то новое придумывать, или вам подойдет готовое, ранее реализованное решение.

Почему правила обмена больше не нужны

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

В моем случае девочка, недавно пришедшая в компанию (на тот момент времени полтора месяца работала в компании) за неделю реализовала обмен с мессенджером Slack на платформе 1С. Конфигурация «1С:CRM» посылала запросы в Slack, создавала там группы на каждую сделку, и в рамках группы велось общение, которое сливалось в 1С. Все это с синхронизацией файлов, с уведомлениями и т.д. И это сделал внедренец, впервые увидевший конфигуратор полтора месяца назад. То, что она смогла легко справиться с этой задачей, во многом связано с тем, что часть кода была написана и шаблонизирована во фреймворке.

Давайте подведем резюме, почему правила обмена данными больше не нужны?

• Существующие инструменты сложны для изучения, ни один из них за час не выучить.

• Исполнение самого обмена, процесс выполнения обмена данными – достаточно медленный (за рядом исключений). Я не беру в расчет шины данных, которые более-менее быстро работают, не беру в расчет HTTP-сервисы – они работают быстро, но с ними я универсальных решений не встречал, хотя примеров решений на Инфостарте много.

• Я не встречал отладку удобнее, чем отладка обычной обработки в конфигураторе. Отлаживать «Конвертацию данных 3» еще более-менее можно, но «Конвертацию данных 2» отлаживать очень неудобно. Самописные решения я не рассматриваю – их можно хорошо отлаживать и работать, но это все-таки отдельные решения под каждую уникальную задачу, никакой универсализации.

Свое универсальное решение я создал, потому что:

• оно позволяет облегчить жизнь мне как руководителю, потому что я могу быстро передать знания;

• сотрудникам нужно знать один инструмент – это хорошо;

• инструмент очень быстро работает, дает эффект «вау» у заказчика и хорошо продается.

Почему бы и нет?

Вопросы

• Ваше решение построено на HTTP-сервисах и обмене в виде JSON-пакетов – сколько времени встраивается этого решение в конфигурацию клиента?

• Развертывание – это просто установка расширения для тех и конфигураций, которые расширения поддерживают. Где расширения не поддерживаются, модули копируются в конфигурацию. На это нужно, наверное, минут пять. Плюс развертывание на веб-сервере – тут каждый справляется с разной скоростью, может занять от 15 минут до 2 часов в зависимости от поведения системного администратора и ограничений. Грубо говоря, первый обмен можно запустить в течение часа, если это что-то простое – например, передать в мобильное приложение список заказов.

• Значит, для регистрации изменений у вас используются планы обмена? Если используются планы обмена, то как обрабатывается снятие с регистрации?

• По-разному работает, в зависимости от задачи. Если мы говорим про обмены не между двумя базами 1С, а между, например, отправка данных из 1С на портал amoCRM, то первая попытка отправки данных производится онлайн прямо в том же потоке. В моем случае скорость была достаточной, чтобы обмениваться данными в том же потоке без фоновых заданий. Если что-то пошло не так, например, сервер, принимающий данные, недоступен, данные складывается в регистр сведений и впоследствии отправляются через минуту еще раз и еще раз – пока не заработает. Если мы говорим про обмен между двумя базами 1С, где можно взять существующие планы обмена (например, план обмена «Полный» для работы с РИБ), то, естественно, он используется – там при обмене между двумя базами 1С реализовано дополнительное фоновое задание, которое и выполняет обмен. Действительно, мы, запуская обмен, считываем изменения, которые успели накопиться за последнюю секунду в плане обмена. Или за последние 10 секунд – смотря сколько времени идет вызов фонового задания. Считываем, отправляем по HTTP, и после этого отменяем регистрацию изменений. Сейчас в продукте не реализована передача события удаления.

• Вопрос про отправку в одном потоке – вы в момент записи документа производите и его отправку? В транзакции модуля объекта?

• Это смотря в каком кейсе. Для тех кейсов, где это не страшно – например, регистрация CRM-события с клиентом – можно в том же потоке отправлять. Там откат транзакции произойдет с очень малой вероятностью, зато максимальная скорость. Если мы говорим про работу с учетными системами, где откат транзакции – это важно, там сознательно даже вводится задержка в скорости передачи данных. Она не онлайн идет, а через пять-десять секунд – это вычислено эмпирическим путем, исходя из количества времени, которое нужно, чтобы транзакция точно завершилась. Если уж она не завершилась, и откатилась, то и никакого обмена не будет.

• Насколько я понимаю, вы не тестировали свой обмен под высоконагруженными системами? Вы тестировали только на обмене, содержащем малый и средний объем данных?

• Да, мне кажется, что под высоконагруженные системы все-таки уже есть готовые решения, зачем там придумывать что-то новое – я не вижу. А под низконагруженные системы в последние 10 лет существенно ничего не менялось. и я подумал, почему бы не занять эту нишу.

• Пробовали ли вы реализовывать обмены с сайтом или интернет-магазином на Битрикс?

• Да, конечно. Веб-разработчики знают, что существует типовая возможность обмена через CommerceML, но как-то и мы используем типовой обмен. Если 3-10 заказов в день, если никто никуда не торопится – то достаточно типовых возможностей. Но как только появляется необходимость модифицировать этот самый обмен, то веб-разработчики и 1С-разработчики начинают плакаться от того инструмента, который есть. Поэтому никто не стесняется переписать этот обмен на что-то более продуктивное, быстрое и понятное для конечного пользователя. С точки зрения 1С-разработчика задача сводится к тому, чтобы договориться с веб-разработчиком о составе передаваемых данных и их именах. Дальше 1С-разработчик создает массив структур, и одной командой передает это куда-то в интернет.

• В типовых правилах обмена в формате EnterpriseData заложена большая работа – их можно использовать или от этого удовольствия стоит отказаться при применении фреймворка?

• Очень важный момент – я считаю, если работает – не трожь! EnterpriseData – в целом, хороший инструмент, там тоже есть передача данных через HTTP-сервисы. Единственный минус – EnterpriseData использует XML-пакеты данных, которые передаются чуть дольше, чем JSON. Для работы EnterpriseData используется очень много кода, в котором труднее разобраться. И важно, если у вас работает типовой обмен, куда нужно добавить один реквизит – используйте EnterpriseData. Если вы хотите написать свой обмен – я по пути EnterpriseData ни разу не пытался ходить, ровно потому, что оценил трудоемкость один раз и понял, что я не хочу слишком много копаться.

• Сколько времени было потрачено на написание фреймворка и над чем он написан?

• Это нативный код – никаких внешних компонент, написан на платформе 1С. Времени было потрачено немного – первый релиз был сделан под конкурс, где объявили такую задачу. Потом в рамках проекта на одном из крупных автомобильных предприятий мы реализовывали одновременные обмены между четырьмя информационными системами – сайт, CRM-система, Документооборот и БИТ-Финанс. Их надо было очень быстро синхронизировать, и за основу был выбран код, реализованный для конкурса. В общей сложности всю задачу целиком у нас получилось реализовать за 27 дней. Создание фреймворка в ней заняло дней 10, наверное. Потом этот фреймворк год не менялся, потому что был сделан достаточно хорошо. А в прошлом году я выпустил второй релиз и начал накручивать на него функциональность – тогда и появились РИБ, и «Конвертация данных», и поддержка JSON, потому что стандартно не всегда хорошо конвертируется, иногда платформа падает. С датой там проблемы, с передачей данных через HTTP тоже – можно писать пять строчек кода, можно одну. И так повсюду. Суть фреймворка в том, что половина кода уже написано.

• Можете поделиться планами, какие фичи ожидать в ближайшее время?

• Там требуется повысить качество, провести рефакторинг, потому что многое наделано. Я сейчас стремлюсь к тому, чтобы перевести все исполняемые модули чуть ближе к ООП. Это мое желание, поэтому весь код выводится в обработке вместо того, чтобы использовать общие модули. Этот подход позволяет менять код без динамического обновления прямо в режиме онлайн. И главное, без перезапуска конфигуратора, а значит ещё и экономить время, потому что при разработке на той же «Комплексной автоматизации» или ERP каждый перезапуск конфигуратора – это хотя бы минута, а если 30 или 50 раз в день, то уже час вылетает просто на ожидание. Поэтому собственный фреймворк помогает повысить скорость разработки. Но концептуально там уже все сделано еще в 2018 году.

• Работает ли ваше решение на Linux, в частности на Centos?

• Да, так как там не используется никаких хитростей, связанных с операционной системой.

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Saint Petersburg.Online.