Backend силами 1С. 4 кейса внедрений

Доклад является продолжением предыдущего выступления.

Я презентую 4 кейса о реальных внедрениях, в которых использовался один и тот же инструмент – фреймворк liteExchange.

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

А еще - каким образом мы тестировали нагрузку и убедились, что эта интеграционная связка при реальной эксплуатации не упадет.

О докладчике

Меня зовут Николай Крылов, я работаю с 1С 11 лет, начинал как рядовой внедренец, дорос до руководителя.

По ходу карьеры разработал коробочное решение CRM. Сейчас руковожу цифровой трансформацией крупной производственной компании.

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

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

Кейс «Камаз»

Первый кейс разработан в одном из юридических лиц компании «Камаз». В одном из продающих подразделений этой компании было много информационных систем: два сайта – старый и новый, CRM-система от компании «ПервыйБИТ», 1С:Документооборот и 1С:Бухгалтерия, куда был прикручен БИТ.Финанс.

• Первая задача, которая была нам поставлена – это автоматизировать движение задач по воронке продаж в CRM-системе, при этом исполнение этих задач в воронке продаж должно выполняться в 1С:Документообороте. БИТ.CRM – это конфигурация на основе УТ11, которая имеет обмен данными с 1C:Документооборотом, но дорабатывать его нам показалось сложным.

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

Также требовалось настроить:

• Данные CRM-системы, 1С:Документооборота и БИТ.Финанса должны быть доступны в личном кабинете покупателя на сайте. Там должны выводиться актуальные данные по заявкам на покупку транспорта, по запросам на документы (на лизинг, на кредит), отображаться состояние по процессам согласования документов.

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

Этот кейс был самым первым, и во время его решения и появился liteExchange. Прошло уже три года, но созданное решение до сих пор функционирует.

Схема взаимодействия информационных систем описана на этом слайде (для упрощения здесь не упомянут БИТ.Финанс, он был четвертой колонкой).

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

Мы долго согласовывали формат обмена, потому что компания большая, приходилось писать много документации.

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

Итак. что мы сделали:

• база 1С была опубликована на веб-сервере;

• в базу интегрировали расширение – сервис liteExchange: набор кода был написан заранее, а мы смогли быстро модифицировать этот код под задачи конкретного заказчика;

• настроили этот сервис;

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

Какие потоки данных в итоге были автоматизированы?

• Клиент, приходя на сайт, оставляет там заявку. Заявка тут же поступает в обработку и попадает в CRM-систему через HTTP-запрос, отправленный методом POST.

• На предыдущем слайде показано поля тела запроса «Передать заявку на расчет» и его JSON-представление – когда такой пакет данных передается с сайта, менеджер его обрабатывает уже в интерфейсе БИТ.CRM.

• Как только подходит этап запросить документы (сведения о компании, уставные документы), информация появляется уже обратным обменом из 1С на сайт в личном кабинете.

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

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

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

• После того, как прошло согласование, сам заключенный договор из БИТ.CRM опять HTTP-запросом отправляется в БИТ.Финанс. Тут мы уже не стали выбирать, просто взяли и сделали.

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

• сайт – это фронт;

• CRM-система – бэк;

• на сайте данные не хранятся, запрашиваются, за секунду отправляются на сайт, и конечный пользователь не видит зависаний.

На старте мы боялись, что 1С будет медленно работать, потому что стандартный обмен с сайтом через CommerceML требует 2, 3, 5, 10 секунд на ответ– это медленно. 1С-ники считают, что это нормальная скорость, но на мой взгляд - это медленно.

В результате обмена через HTTP-сервисы и JSON-пакеты мы получили скорость меньше секунды, в крайнем случае, скорость была 1.3 секунды. Решение получилось хорошим, мы сами такого не ожидали.

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

Важно, что для решения этой задачи можно было использовать более общепринятые методы.

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

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

Фреймворк liteExchange

Немного о фреймворке liteExchange – код можно посмотреть на GitHub.

Фреймворк liteExchange полностью написан на 1С, он нативен для этой платформы, там нет никаких внешних компонент, никаких запросов к сторонним ресурсам.

Написано все по-русски, код открыт. Весь этот код умещается в 1000 строчек, и его не надо знать. Надо знать 2-3 команды, которые использует программист. Поэтому начинающий осваивает его за 4-5 часов. Опытный программист, возможно, задаст больше вопросов, станет больше копаться, полезет в глубину, потому что там интереснее. Но начинающие осваивают быстро.

Что внутри:

• В основе фреймворка – HTTP-сервисы,

• Формат обмена данными жестко задан – JSON, другие форматы я не использую.

• За счет того, что очень узко обрезана используемая функциональность, кода мало, работает быстро.

• Особенно важно для начинающих: от программиста скрыты особенности протоколов HTTP и HTTPS. Единственное, с чем я столкнулся на практике: решая задачу подключения Jira к 1С, обмен по протоколу HTTPS не хотел работать с 1С. Оказалось, что проблема в сертификате. Программист просто передал задачу администраторам, и они все исправили.

Кейс «Доброфонд»

Другой кейс реализован в компании «Доброфонд». Это благотворительный фонд, который работает в южных регионах России, оказывает денежную и нематериальную помощь нуждающимся.

В компании есть несколько удаленных офисов и люди, которые ходят по семьям нуждающихся, я их назову инспекторами. Инспектора ходят по нуждающимся и проверяют, действительно ли им нужна помощь.

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

В рамках решения нашей задачи:

• мы за неделю написали суммарно на все задачи 300 строк кода;

• всего было реализовано 17 методов API;

• первый шаг сделан 2,5 года назад и потом в несколько итераций решение дописывалось;

• суммарное время реализации – 60-70 часов.

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

При отправке заявки из мобильного приложения в 1С:

• происходит HTTP-запрос к самописной базе, опубликованной на веб-сервере, работающей на платформе 1С;

• HTTP-запрос обрабатывается фреймворком liteExchange.

• данные передаются в формате JSON – пример формата данных такой же, как был показан для «Камаза», передаются такие же маленькие пакеты;

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

Разрабатывая приложение «Вместе», в рамках поставленной задачи:

• Мы реализовали общепринятый подход к регистрации пользователей через мобильное приложение, по номеру мобильного телефона с подтверждением по SMS.

• С помощью кода на 1С реализовали работу с пуш-сообщениями – 1С по факту отработки заявки отправляет пуши в приложение.

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

• Токены доступа – это само собой разумеющееся, не буду акцентировать на них внимание.

Кейс «Дашборды»

Наиболее часто встречающиеся задачи – реализовать дашборды для руководителя.

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

• на локальном компьютере публикую базу, подключаю к ней liteExchange;

• делаю запрос к базе данных на языке 1С, например, собираю статистику продаж;

• и в одну команду даю ответ на запрос, сформированный с локально расположенной веб-странички – в данном примере для визуализации используется JavaScript-библиотека amCharts, она умеет принимать HTTP-запросы в формате JSON.

Эти данные можно отобразить на своем компьютере локально, показать, что прототип работает. На следующих шагах рисуются нормальные дашборды. Такие же красивые, как в BI-системах.

Важно тут то, что задача решается с очень малыми затратами времени. Программирования тут совсем мало – разве что только для того, чтобы сделать запрос к регистру «Продажи», это 5-10-15 строчек кода, плюс отладка и проверка. Конечно, это возможно при условии, что веб-страничка уже реализована, но когда мы делаем прототипы, у меня в загашнике уже что-то есть.

Кейс «Мастер-база»

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

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

• собственные ИС – 1С:ERP и 1С:УТ;

• сайт в двух вариантах (включая личный кабинет);

• информационные системы дилеров;

• информационные системы франчайзи.

Сейчас номенклатура хранится внутри ERP, давать прямой доступ к ERP-системе не хочется. С точки зрения безопасности и поддержки этой системы хочется выделить место хранения номенклатуры в отдельную базу. Так и сделали:

• Реализовали базу на основе БСП, куда продублировали справочник номенклатуры в том виде, в каком он есть сейчас.

• Опубликовали эту базу на веб-сервере, установили в нее liteExchange

• На слайде показан стандартный ответ liteExchange на запрос к справочнику номенклатуры. Там несколько десятков полей, я специально оставил только четыре. Этот ответ можно запрограммировать, для этого написано десяток строчек кода. Этого достаточно, чтобы данные скачались в центральную базу номенклатуры.

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

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

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

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

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

Другие кейсы

На самом деле, кейсов, которые успели накопиться за три года, множество – от многократно решенных задач обмена сообщениями с Телеграмом до более специализированных и редко встречающихся задач: например, мы интегрировали Jira с УТ11 - заказы клиентов в виде задач на разработку уходили в Jira и обратная связь туда же, и зачем-то в Jira попросили выгружать себестоимость.

Был хороший кейс, когда один сервер обращается к другому серверу 1С, чтобы спросить актуальные остатки – распределенная сеть розничных магазинов, торгуя с центрального склада, должны оперативно сказать клиенту перед кассой, есть товар или нет и тоже оперативно его зарезервировать, пока то же самое не сделал соседний магазин. Обычные обмены РИБ в этом случае не подходили, там есть задержки в 1-2-5 минут, которые нас не устраивали. Мы нивелировали риски, сделали обмен через HTTP, через liteExchange.

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

Тест нагрузки

Более интересно, как проверить, что система не упадет при реальной нагрузке. Важно понимать ограничение. У моих заказчиков – текущих или тех, с которыми я работал, – не используются big data и высоконагруженные системы. У них используются системы с количеством пользователей 50-150 или вообще 5. Нам не требуется сильно углубляться в особенности работы серверов, платформы или в кэширование, чтобы решать свою задачу. С заданной скоростью, заданным уровнем качества фреймворк обеспечивает решение задач, с которыми я сталкивался.

Чтобы его протестировать:

• я взял первый попавшийся облачный сервер под Windows. Цена аренды – 1000 рублей. За эту тысячу мне дали 4 ядра, 4 Гб оперативной памяти и SSD-диск;

• развернул там базу 1С:УТ 11 и прикрутил к ней liteExchange;

• реализовал API, возвращающее результат запроса к регистру «Продажи»;

• нашел сайт, который занимается ping-тестами, и попросил его атаковать веб-сервер - веб-сервер выдержал 50 запросов, и после 50 начал отвечать не на все;

• после 75 запросов у меня отвалилась терминальная сессия – сервер оказался перегруженным.

Но когда ping-тест завершился, оказалось, что сервер не упал, он работает. Из этого я сделал вывод, что простая задача вывода остатков на маломощном сервере с файловой базой обрабатывает 50 запросов в секунду. Дальше мы с заказчиком прикинули, сколько реально будет запросов в секунду. Поняли, что их 2-3, такая кратность нас вполне устроила, притом, что реальный боевой сервер мощнее, чем тот, который я арендовал за тысячу рублей.

Выводы

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

Последние цифры, которые мне удавалось получить при обмене с помощью фреймворка:

• Обмен из КА 2.4 в КА 1.1 происходит за 0.3 секунды – это передача данных о заказе клиента с проведением.

• В обратном направлении обмен идет дольше, потому что КА 2.4 сама по себе более тяжелая. Это полный цикл обмена с проведением, не только HTTP-вызов.

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

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

Ссылки

Стабильная версия фреймворка опубликована в виде расширения:

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

• Есть канал в Телеграме https://t.me/liteExchange_group, где можно вести обсуждение, задавать вопросы.

Вопросы

Какое количество одновременных сеансов при обмене?

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

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

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

Нарушение контракта и схемы на входе никак не контролируется?

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

Как обеспечивается событийность обмена между ERP и УТ 11? Выгрузка реализована по расписанию или после записи номенклатуры?

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

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

Второе решение – это записать данные в план обмена и также фоновым заданием запустить обмен. Если удалось произвести обмен, данные из плана обмена очистить, иначе – оставить и отправить при следующем обмене.

Мобильное приложение «Вместе» для фонда Доброфонд реализовано на 1С?

Мобильное приложение нативное, сейчас написано под Android.

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

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Интеграционные решения в 1С".