Космическая Одиссея 2020 года

21.11.22

Интеграция - Периферийные устройства

Организация потокового обмена системы 1С с большим количеством разнородных устройств – нетривиальная задача. О том, как организовать архитектуру такого решения с учетом возможного масштабирования хранимых данных и поддерживаемых интерфейсов, на конференции Infostart Event 2021 Post-Apocalypse рассказал TeamLead и специалист по внедрению компании ИнфоСофт Григорий Шатров.

 

Меня зовут Григорий Шатров, я из компании «ИнфоСофт», город Новосибирск.

Хочу рассказать вам интересную историю, вдохновением и САСПЕНСом для которой послужило великое произведение режиссера Стенли Кубрика – фильм «Космическая Одиссея 2001 года».

 

 

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

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

 

 

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

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

  • Правой рукой, артерией служил веб-сервер Apache и самописные PHP-запросы – они помогали нашей системе 1С взаимодействовать с «Системой опросов устройств».

  • И на острие атаки у нас использовалась самописная программа на C# «Система опросов устройств» (MIS) – она опрашивала все эти устройства, получала от них нужные данные и записывала их в 1С. Для разработки этой программы мы специально использовали C#. Несмотря на то, что большинство разработок с нуля у нас в компании ведется на платформе 1С, наши внутренние хакатоны позволили нам расширить вектор во все стороны, и для данного проекта мы выбрали наиболее эффективные инструменты из имеющихся.

 

Используем гравитацию: строим экосистему с 1С-ным ядром

 

 

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

  • Первый микросервис запускал процесс «Формирование и отправка заданий для устройств». В данном процессе 1С дает устройству задание проинициализировать какое-то действие и отправляет это задание в «Систему опросов».

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

  • Эта информация фиксируется в нашей системе – как положительные, так и отрицательные результаты. Отрицательный результат по опросу – это тоже результат. Процесс получения данных JSON из этих устройств и разбор этих JSON по нужным аналитикам внутри системы 1С у нас также разделен по отдельным микросервисам – «Получение» и «Разбор».

Давайте рассмотрим все эти процессы по отдельности.

 

 

За первый процесс отвечает микросервис «Формирование и отправка». Ему нужно уделить отдельное внимание, так как в этом микросервисе для обмена с нашей «Системой опросов» все данные уже должны быть подготовлены в нужном формате.

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

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

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

 

Балансируем в невесомости: разрабатываем центр управления тысячами внешних устройств

 

 

Следующей составляющей системы стала «Система опросов» – наше C#-ное детище, которое и опрашивает разнородные устройства.

«Система опросов» состоит из нескольких компонент.

  • Первый компонент – это MQB, сам балансировщик заданий, тикетов и т.д. Балансировщик работает с каждым заданием, ни одно из них не будет им пропущено – при этом будут получены все нужные данные.

  • Второй компонент – MI. Но это не Xiaomi-телефон, а компонента MI MTI, которая по разным протоколам опрашивает каждое из устройств и получает данные. Т.е. это – рабочая лошадка, ядро самой системы опросов, которое непосредственно уже отправляет конкретные задания, опрашивая конкретные устройства.

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

 

 

А как управлять большим количеством тикетов, и при этом не построить какой-то сложный пульт управления?

 

 

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

Тут нам на помощь приходит система Канбан-доски. В этом случае мы определяем каждое из заданий по аналитике или статусам данных заданий. И формируем нашу систему.

 

 

В нашем случае мы организовали данные на стороне «Системы опросов» в виде простой файловой системы из нескольких папок, где задания от 1С просто поделены по логическим предметам:

  • В папку IN у нас попадают все задания, нужные для опроса.

  • После этого, если балансировщик подхватил данное задание, он определяет его в папку IN PROGRESS.

  • После этого, если это устройство успешно опрошено, задание попадает в папку OUT.

  • И когда 1С успешно забирает данные через PHP-запрос, как лог перемещается в COMPLETE.

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

  • И после прохода N итераций, если устройство все-таки не выходит на связь, задание попадает в FAILED. Если выходит, в OUT.

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

 

Наблюдаем в иллюминатор из 1С: разбираем вопросы взаимодействия инфосистем

 

 

Для формирования панели мониторинга с данными заданиями была написана панель на основе графического движка chart.js с применением технологии AJAX. Она позволяет получать все нужные данные без обновления самой странички.

Так как наши пользователи работают в 1С, с помощью реквизита строкового типа и поля HTML-документа можно максимально просто поместить данную панель мониторинга в 1С.

Также можно скомпилировать ее в Android-приложение – это тоже прекрасно работает.

 

Подчиняем космические скорости: создаем балансировщик системы опросов

 

 

Но как сделать данные очереди максимально эффективными для самой «Системы опросов»?

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

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

  • Содержания, где содержится сам JSON запроса, с помощью чего уже опрашиватель собирает данный JSON и опрашивает соответствующее устройство.

 

 

После опроса нашей MIS все JSON-запросы попадают в 1С и разбираются по нужным аналитикам.

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

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

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

 

Отображаем динамические показатели

 

 

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

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

 

 

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

Т.е. фиксировалась колонка под каждый показатель, типизировалась.

 

 

И после этого в обработчике «ПриПолученииДанныхНаСервере» для определенных строк просто определялось, какие колонки нужно показывать. Эти колонки заполнялись нужными данными, а для остальных убиралась видимость.

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

 

Тестируем связь с устройствами

 

 

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

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

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

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

 

Реализуем многопоточность

 

 

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

Кейс обработки нескольких потоков я разделяю на два типа:

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

  • И второй кейс – это пополняемый стек каких-то данных. В нашем случае, JSON-запросов. Т.е. в момент, когда вы запустили много потоков, может прилететь еще столько же, либо большее количество JSON-запросов. Это непрогнозируемый объем данных. В этом же случае к нам приходит на помощь метод «ОжидатьЗавершения(<Таймаут>)» управляющего фонового задания. Этот метод образует паузу, которая нужна всем 1С-никам, чтобы не грузить ЦП на 100% в бесконечном цикле. И после этого мы проверяем – есть ли сейчас вообще, чему опрашиваться. Есть ли неопрошенный JSON. Если он есть, мы формируем фоновое задание – если оно не превышает количество необходимых нам потоков. Если оно превышает, то мы ждем дальше через «ОжидатьЗавершения(<Таймаут>)». И точкой выхода из этого бесконечного цикла с паузами, конечно, является то, что уже нет JSON-запросов для разбора. Мы выходим их этого управляющего фонового задания и после этого по регламенту заново пробуждаем это управляющее задание.

 

Обманываем оптимизатор запросов СКД

 

 

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

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

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

При этом конструктор запросов внутри СКД максимально правильно это обработает, ничего не допишет, не уберет из группировок – таким образом мы оптимизатор «обманываем».

 

Время историй

 

 

Расскажу об особенностях, с которыми мы столкнулись в нашей истории.

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

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

  • Следующее, с чем мы столкнулись – это то, что при группировке реквизитов строкового типа внутри объекта «Запрос» сама 1С не смотрит на регистр данных строк. Допустим, «а» и «А» будут сгруппированы в одну строку. То же самое – «Иванов» и «иванов». Возможно, это известный факт, но я выделил его здесь для тех, кто с этим не сталкивался, чтобы в дальнейшем вы у себя в системе это учитывали.

  • У нас в системе для каждого из устройств хранился уникальный номер – в реквизите строкового типа справочника по этим устройствам. При этом заранее не было известно, что должно было быть внутри этих номеров. Сейчас мы определились, что туда попадают только числа – заложили это в алгоритмы по опросу данных устройств. Потому что в какой-то момент одно из устройств реально украли с адреса, где оно находилось. И мы в качестве значения реквизита этого устройства мы записали «123_Украден», чтобы исключить его из общего пула всех заданий.

  • Также мы столкнулись с особенностями работы присоединенных файлов в режиме мобильного клиента. Как я говорил ранее, мы использовали крутую возможность мобильного клиента фотографировать устройство через камеру телефона. При этом БСП очень классно обрабатывает – файл сразу же прикрепляется к нужному объекту из системы. Но в БСП 3.0.3 мы столкнулись с проблемой, что при переключении с мобильного клиента на десктопную версию рабочий каталог, куда сохранялись временные файлы по этим присоединенным файлам, не переключался обратно. Тем самым, при работе на компьютере просто не было возможности вообще работать с присоединенными файлами – он пытался обратиться в нужную ему папку на Android. В этом случае помогала очистка рабочего каталога.

 

Полезные инструменты не-1С-ника

 

 

При работе с не-1С-ными системами мы наткнулись на интересные моменты:

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

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

  • И мы постоянно использовали всеми любимый GIT. В мире 1С его люди тоже все чаще и чаще начинают использовать. Но внутри мира C# GIT дает возможность попробовать подтвердить либо не подтвердить гипотезы, а также может быть крутым источником для бэкапирования.

 

Заключение

 

 

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

На этом история нашей космической одиссеи заканчивается. Да прибудут всем интересные и новые прогрессивные идеи!

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Распознавание номеров автомашин с ip - камер, видео, фото

Распознавание документов и образов Периферийные устройства Автомобили, автосервисы Россия Платные (руб)

Программа считывает кадры с ip-камер (http - запрос к камере), видео, фото (источники кадров (нет ограничения на их количество) настраивается в конфигурационном файле), находит и распознает номера автомашин и сохраняет в базу db, с сохранением фото номера и автомашины, а также времени детекции.

20400 руб.

31.05.2023    4166    4    2    

7

Мониторинг баз и серверов 1С

Журнал регистрации Мониторинг Платформа 1С v8.3 Платные (руб)

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

9000 руб.

28.08.2019    31426    15    21    

68

Конфигурация Session Monitor

Мониторинг Инструменты администратора БД Платформа 1С v8.3 Россия Платные (руб)

Конфигурация Session Monitor предназначена для мониторинга сервера 1С с целью отслеживания чрезмерной нагрузки от конкретных сеансов и скорости реакции рабочих процессов.

1500 руб.

01.12.2020    14605    36    0    

51

Информация по рабочему каталогу центрального сервера (srvinfo) и его очистка

Мониторинг Сервера Платформа 1С v8.3 Управляемые формы Абонемент ($m)

Размер, имя информационной базы из реестра кластера (файл 1CV8Clst.lst), дата последнего изменения файлов в каталоге баз (srvinfo\reg_*\uuid) центрального сервера. Отдельно показан размер индекса ППД (полнотекстовый поиск данных) и его актуальность. Полезна в случае, если у вас удалялись базы 1С и никто не озаботился удалением журналов регистрации.

1 стартмани

15.05.2024    491    7    MaximSh    0    

4

Настройка принтера по умолчанию при печати ценников и этикеток в Рознице 2.3

Периферийные устройства Платформа 1С v8.3 1С:Розница 2 Россия Абонемент ($m)

Расширение для 1С: Розница 2.3 версий 2.3.15.ХХХ и выше. Удобный способ изменения принтера по умолчанию во встроенной обработке печати ценников и этикеток. Только для операционной системы Windows.

1 стартмани

13.05.2024    405    2    independ    0    

5

Тернистый путь к физической клавиатуре для программиста 1С

Периферийные устройства Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

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

1 стартмани

15.04.2024    6984    madonov    57    

35

Как вызвать скрипты на python в 1С по технологии NativeAPI

Языки и среды Платформа 1С v8.3 Бесплатно (free)

Будем писать свои скрипты на питоне и запускать их на 1С.

15.04.2024    2061    YA_418728146    11    

56

[История разработки] Управляем промышленным принтером EBS-1500 из 1С

Периферийные устройства Платформа 1С v8.3 Бесплатно (free)

«У нас было два контроллера Huidu, семьдесят две китайские монохромные панели на светоизлучающих диодах, они же LED, четыре мегабайта flash памяти, 1С и целое море поддерживаемых форматов вывода информации - текстов, картинок, анимаций, а так же литр промывочной жидкости, литр разбавителя, ящик черных чернил, и 12 патч-кордов и различных удлинителей. Не то, чтобы всё это было категорически необходимо в маркировке, но если уж начал собирать маркиратор на 1С, то к делу надо подходить серьёзно.» - Страх и ненависть в Маркировке, 2019 г.

01.04.2024    2018    Interrupted    14    

34
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. starik-2005 3046 11.11.22 22:50 Сейчас в теме
Но наши стандарты разработки считают формирование вложенных запросов неправильным
Т.е. не люди считают, а стандарты считают. Отлично!
https://www.google.com/teapot
maksa2005; G.Shatrov; awk; +3 Ответить
2. maksa2005 536 24.08.23 13:15 Сейчас в теме
Я типичный 1Сник) Вроде бы не обидно, но...
Прикрепленные файлы:
G.Shatrov; +1 Ответить
Оставьте свое сообщение