Как приручить драконов. История построения экосистемы на основе 1С

Однажды к нам в компанию пришел нетривиальный запрос – никто не знал, как за него взяться, с какой стороны подойти. Но в итоге у нас получилось «приручить драконов» – так же, как и в той легенде.

 

 

Давайте немного окунемся в сказку.

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

 

 

Но вскоре спокойной жизни стали мешать вредители – драконы. Они сжигали дома, уносили скот, портили продукты. Но все изменило приключение, случившееся однажды.

Нашими «драконами» были задачи по разработке драйверов с внешними устройствами, с которыми надо взаимодействовать, и их обертка в экосистему 1С. Эти драконы перечислены на слайде.

 

 

Осмелело последнее поколение викингов. Для борьбы с драконами решили соорудить из подручных средств какое-то орудие. Это было орудие первой задачи, класса «Долети, пожалуйста, до цели» (до самих устройств). Сложность его разработки была вызвано непрозрачностью протокола обмена и разнообразностью самих устройств.

 

Выбор языка программирования для организации связи с устройствами

 

 

Для организации связи с устройствами были призваны книги с магическими заклинаниями.

Первой книгой стал священный язык викингов – наш желтый 1С.

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

• Во-первых, у нас планировалось облачная версия 1С, а доступ к COM-объектам на сервере есть только у администраторов сервера.

• Также мы столкнулись с медленной работой COM-портов.

 

 

Поэтому на второй полке взяли великий могучий язык Java.

Потратив N-ное количество времени, мы не нашли каких-то подходящих библиотек по работе с COM-портами, они не закрывали все необходимые потребности.

 

 

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

 

Архитектура системы взаимодействия

 

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

 

 

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

• В фундаменте лежит 1С, как учетная система. Она написана с нуля на основе БСП и БИП (библиотеки интернет-поддержки). Здесь хранятся все данные об устройствах, транспорте до них, генерируются наши задачи (очереди) и принимаются эти очереди от системы опросов.

• Помощником для взаимодействия выступали HTTP-сервисы. Чтобы с ними работать, мы взяли за основу веб-сервер Apache, написали для него PHP-запросы. Через эти инструменты 1С взаимодействовала с системой опросов.

• И для непосредственного взаимодействия с устройствами была разработана архитектура системы опросов. Исполняемый файл системы опросов, как я уже говорил, был написан на C#. Через систему опросов построено взаимодействие через модемы (телефоны либо IP-адреса) с устройствами. И была выстроена файловая система, я чуть позже про нее расскажу.

 

Формирование очереди на стороне 1С

 

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

Процесс достаточно прост – формируем, отправляем, получаем, разбираем.

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

• У нас множество устройств, много параметров, по которым надо опрашивать. Из всех этих данные, подготовленных в JSON файлах, формируется очередь – это первый этап.

• Потом эти JSON-файлы отправляются через php-запрос в наш Apache.

• Система опросов получает на вход все задачи (тикеты), чтобы обрабатывать и опрашивать наши устройства, взаимодействует с устройствами и отдает на выходе показатели этих устройств в виде подготовленных JSON-файлов.

• При получении этих данных мы компонуем показатели из нескольких заданий (из нескольких JSON-ов) в массивы и получаем массив JSON-ов. Процесс получения всех этих данных мы разбили на 2 этапа.

  • На первом этапе мы просто объединяем эти JSON-ы и записываем текстом, не разбирая на показатели.

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

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

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

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

 

Система опросов

 

Чуть подробнее про саму систему опросов.

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

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

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

• Далее наш модем обращается к модему устройства и получает либо не получает данные (на разных этапах могут быть разные последствия). Если опрос прошел успешно, задание с готовым JSON-ом помещается в OUT, если не получает данные, то задание помещается в ERROR.

• В дальнейшем 1С время от времени по регламентному заданию опрашивает папки OUT, объединяет в JSON-ы в массив JSON-ов и перемещает все успешные тикеты из OUT в COMPLETE.

• Если есть ошибка или не дозвонились – тикет у нас попадает в ERROR мы в рамка определенного количества времени и лимита попыток пытаемся дозвониться. Сначала система опросов время от времени (раз в 1 час, если я не ошибаюсь) опрашивает эти же устройства, при этом данные из ERROR снова помещаются в IN, потом в IN PROGRESS, если все удачно, то в OUT, если неудачно, то опять в ERROR. После определенного количества попыток либо истечении лимита времени, тикет с неудачным результатом задания помещается из ERROR в OUT, но уже не с информацией о том, что было на устройстве, а с информацией о том, что это устройство неработоспособно.

• При этом он также копируется в FAILED, чтобы понимать, какие устройства стали неработоспособны. В 1С эта информация тоже накапливается.

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

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

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

 

Система мониторинга

 

 

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

Графики сюда выводятся через фреймворк chart.js. При этом за счет использования технологии Ajax информация загружается в реальном времени без необходимости обновлять html-страницу.

Так как у нас все пользователи работают в 1С, нам не хотелось использовать какой-то отдельный браузер, и с помощью пары строк кода, реквизита строкового типа и элемента вида ПолеHTMLДокумента мы весь этот HTML-код засунули в макет вида HTML-документ и получили этот же дашборд в 1С.

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

 

Балансировщик

 

 

Хорошо. 1С сформировала все очереди, а что дальше?

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

 

 

Для этого на C# был разработан балансировщик очередей.

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

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

 

 

Непосредственно опросом устройств занимается второй компонент балансировщика – MI, Meters Interrogator.

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

Т.е. это наша рабочая лошадка, которая производит опрос наших устройств.

 

 

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

 

 

И конечно кладезь знаний – все наши библиотеки, которые написаны внутри данного балансировщика. Там описаны:

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

• и вспомогательные функции.

 

Архитектура хранения данных по показателям в виде Ключ/Значение и их вывод в динамический список

 

 

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

Поэтому мы решили уйти от какой-то плоской структуры ресурсов (ресурс 1, ресурс 2) и перейти на архитектуру хранения данных в виде ключ/значение. Я на слайде отобразил ее плюсы и минусы.

 

 

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

У нас есть динамический список, при активизации строки в котором есть ряд параметров, которые влияют на второй динамический список. Соответственно, в зависимости от выделенной строки и тех параметров, которые там лежат, нам нужно вставить все ключи наших показателей в колоночки. Например, мы выделяем одну строку и для нее показываем пять ключей. А при выделении другой строки вторая таблица должна сформировать 20 ключей/колонок, чтобы вывести все показания, которые получили с этих устройств за определенные даты.

Как это можно сделать? Можно при активизации строки формировать:

• либо таблицу значений с динамическим построением наших колонок;

• либо отчет СКД;

• либо какие-то макеты ТабДок или СКД;

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

Но для всего этого требуется перегонять весь контекст формы на сервер, использовать серверные вызовы с директивой компиляции &НаСервере, а для динамического списка справка платформы это запрещает. То есть технически это сделать можно, но вывод будет тормозить, поскольку показаний от устройств у нас достаточно много.

 

 

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

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

Из такой пустышки мы формировали динамический список.

 

 

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

Поскольку в событии динамического списка ПриПолученииДанныхНаСервере мы работаем с ограниченным количество ключей (около 40-60 в зависимости от разрешения экрана), строк получается мало. По этим данным вычисляются показатели – некоторые из полей вычисляются арифметически, а после этого через условное оформление этих ячеек просто отключаем видимость ненужных колонок.

 

Помощники системы

 

 

Какие еще инструменты были использованы?

• Многие уже стали использовать и EDT, и там есть прекрасный инструмент – схема данных https://wonderland.v8.1c.ru/blog/skhema-dannykh/. Это ER-диаграмма, которая показывает в визуальном виде связь одних объектов метаданных с другими. С помощью нее можно либо посмотреть всю архитектуру, либо непосредственно при вводе нового разработчика в проект показывать, какие есть взаимосвязи между нашими метаданными.

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

 

Дополнительные инструменты

 

 

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

• Представьте: от устройств нам прилетают двоичные, шестнадцатеричные данные. Поскольку работа с устройствами организована на низком уровне, данные могут иметь float-значения, какие-то контрольные суммы. Инструменты, приведенные по ссылкам https://crccalc.com/ и https://www.h-schmidt.net/FloatConverter/IEEE754.html помогают рассчитывать все эти моменты. Если вы учились на программистов, то вспоминайте ваши лабораторные и получайте данные в нужном виде с помощью этих инструментов.

• Так как мы работаем через COM-порты, очень важно было понимать, какие данные приходят на COM-порты, а какие уходят. Так как не вся документация отражала правду, и в принципе не понятно, какие данные сейчас пришли – и вообще пришли они или нет, мы использовали программку Serial Port Monitor, с помощью которой в достаточно удобном виде можно получать по нужному COM-порту те данные, которые ты принимаешь либо отправляешь. Также она позволяет простейшие команды отправлять на сами COM-порты, делать тест связи с ними, перезагружать их, другие команды туда посылать.

• И еще любимый у сообщества Инфостарта GIT. Разработка на C# велась с помощью Git – он позволял проверять кучу гипотез, так как не всегда было понятно, что будет именно сейчас, что будет чуть попозже, какие именно данные сейчас придут. Формировались некоторые гипотезы, они проверялись через ветки в Git. Также Git помогал при затирании некоторых строк кода, реально служил бэкапом. Поскольку он «встроен» в систему IDE для C#, идет «из коробки», то организации этого версионирования никаких дополнительных действий делать было не надо. В качестве Git-сервера у нас использовался GitHub – он нам помогал стремиться к релизам, там есть некоторые практики – доски канбан, активность коммитов, и с их помощью можно стремиться к релизам для системы опросов (проекта, который ведется в Git).

 

Подводные камни

 

 

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

 

 

О чем я хотел сказать? О том, что надо уделить внимание буквам М, Т, С, которые визуально в стандартных шрифтах не отличишь русские от английских.

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

 

Повышение эффективности работы в команде

 

 

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

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

 

 

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

 

 

Еще один инструмент – визуализация самих процессов и идей, которые пока у тебя еще «на кончиках пальцев», и ты пока не знаешь, как их реализовать. Я использовал mind map, как для визуализации процессов, так и для подготовки этой презентации, где некоторые слайды были реализованы с помощью mind map Xmind Zen. Также можно использовать бесплатный веб-сервис https://www.draw.io/.

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

 

 

Есть и другие инструменты:

• флипчарты;

• ватманы;

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

Не забывайте, что надо использовать стираемые маркеры. Но если вы уверены на 100% в архитектуре, можете использовать нестираемые маркеры.

 

 

Еще один из подходов для улучшения эффективности генерации путей решения, его описал Джефф Паттон, называется Story mapping. Его суть тоже достаточно простая.

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

• И вместе они вырабатывают вначале крупноблочно то, что надо бизнесу (проекту, продукту) – записывают это в каких-то системах либо просто на стикерах.

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

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

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

 

О чем нельзя забывать

 

 

Конечно же, на любом проекте может понадобиться «джентльменский набор». Я думаю, о нем все 1С-ники знают. Это:

• индексы,

• блокировки,

• транзакции.

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

 

С чего начать

 

 

Хотелось еще поднять такой вопрос: точно ли стоит брать 1С-нику не 1С-ные проекты?

Мы в своей компании, например, начали не-1С-ную разработку с хакатона. Год назад мы организовали такое мероприятие, в котором участвовало порядка 8 команд, и они выполняли какие-то проекты, не связанные с повседневной работой. По классическим правилам – два дня команды формировали с нуля продукт/ проект, потом презентовали его. Это дает опыт и драйв, помогает в дальнейшем развивать свои навыки.

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

Экспериментируйте! И вы точно прикоснетесь к прекрасному и приручите своих драконов.

 

 

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

 

Вопросы

 

• Сколько времени заняла реализация всего проекта?

• До конечного релиза - MVP, который можно пощупать, ориентировочно 4 месяца.

• Сколько конечных устройств в итоге сейчас опрашивает система.

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

• А по твоему мнению, сколько устройств потянет эта архитектура?

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

• А если поменять на IP-модем?

• Там не получится так, к сожалению. Там, скорее всего, нужно будет докупить плашку, которая соединяет все эти COM-порты. Сколько удастся потянуть? Это распределенная система, поэтому, я думаю, она потянет всю Россию.

• Какие интересные проекты были на хакатоне?

• У нас были проекты про распознавание штрихкода data matrix с pdf. Еще было приложение-агрегатор данных по бронированию столиков в ресторанах, чтобы можно было заказать столик на компанию, не обзванивая окрестные рестораны – сейчас уже вроде такое, тогда еще не было. Еще был проект, когда соединяли через Arduino аналоговые наши телефоны, которые есть у наших бабушек и дедушек. И непосредственно сама 1С-ка звонила на IP-телефонию, набирала на диск, определяла по положению, что это за цифра. А у тех телефонов нет никакой цифровой составляющей, чисто аналоговое определение: от угла – 0, 1, 2 и т.д.

• Последний вопрос. Часть на C# внутренними силами реализована?

• Да, полностью нашими разработчиками 1С. Почему я говорил про не 1С-ные проекты. Всё наши ребята сделали сами, 1С-ники.

 

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

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