В публикации описана концепция и первая реализация. Развитие концепции и загрузка материалов всех версий в следующей части: //infostart.ru/public/1062681/
Мир меняется, мы все теперь в онлайн. Даже кассовые аппараты в онлайн. «Мир вещей» на пороге.
Мир меняется, мы все теперь в онлайн. Даже кассовые аппараты в онлайн. «Мир вещей» на пороге.
Людям свойственно общаться и нормальное общение — это всегда диалог. Мы говорим несколько фраз и ждем ответа собеседника. Представьте, как в будущем придется общаться с «марсианами», если ответа нужно будет ждать от 6 до 40 минут? В таком случае нужно будет «наговорить» минут на 10 (а потом выяснится, что половина сказанного уже неактуально или неинтересно собеседнику), и затем разбираться с его ответами (возможно, тоже минут на 10 монолога собеседника).
Базы данных 1С сейчас общаются, в основном, как приведенном примере с «марсианами». Это планы обмена и конвертация данных, проверенная и надежная технология. Но времена меняются и актуальность оперативного обмена только растет. Компания 1С реализовала поддержку в платформе двух ключевых технологий: HTTP-сервисы и расширения конфигурации. Но «обвязки» всей этой красоты на уровне стандартных библиотек, к сожалению, нет.
В общем, звезды сошлись … вначале у меня появилась идея-фикс: разработать универсальное компактное расширение конфигурации, не требующее внесения изменений в саму конфигурацию и обеспечивающее оперативный обмен данными между базами 1С на различных конфигурациях. Работающее под Windows и под Linux, на мобильных платформах (после внедрения в мобильную конфигурацию). Обмен экономичный, с минимальными объемами передаваемых данных, с регистрацией всех передаваемых данных. С оперативно изменяемым функционалом. Одно и тоже расширение, которое может использоваться и в качестве клиента, и в качестве сервера. Которое может обмениваться с различными базами данных (хоть перебирать их в цикле). Безопасное.
Примерно, как радиомодуль в мобильных устройствах – он работает по стандартным протоколам, и как только его добавили в устройство, обеспечивает возможность обмена с другими устройствами. А нам даёт новое измерение жизни, онлайн.
Свой вариант реализации этой идеи — технологию hsИнтегратор, я и представляю в данной публикации. Префикс hs в названии технологии — начальные буквы слов http service. С помощью hsИнтегратор можно быстро и просто научить базы данных 1С «разговаривать» между собой, превратить монологи в диалоги и конференции.
Первое применение hsИнтегратор (без расширений, обмен только с одним центральным сервером) уже работает несколько месяцев и обеспечивает обмен данными ФГИС «Меркурий» между центральным сервером (УТ) и учетными системами (РТ) в магазинах.
На этой же технологии реализован обмен между терминалами сбора данных с установленной мобильной платформой и РТ.
hsИнтегратор не заменяет традиционную технологию интеграции с помощью планов обмена, а дополняет её.
Ключевые отличия технологий обмена:
Интеграция с помощью планов обмена и конвертации данных позволяет передать практически любые объемы данных, хоть гигабайты информации, поскольку использует потоковую обработку данных. Объем необходимой для обработки оперативной памяти практически не зависит от размеров передаваемых данных;
- технология разработки «правил обмена» выполняется снизу вверх, от более простых типов к более сложным.
- источник сразу готовит все правила и все данные, а приемник разбирается с ними.
- технология уже давно существует, отработана и позволяет передавать любые данные между базами 1С.
- при типичных настройках обмена время прохождения данных между двумя сторонами обмена (в обе стороны) составляет от десятков минут до нескольких часов.
hsИнтегратор «переваривает» данные в оперативной памяти, поэтому объем данных ограничен несколькими сотнями мегабайт. Данные упаковываются после сериализации в формат JSON или, если передаются коллекции, содержащие только простые типы, в еще более эффективном формате, без дополнительной сериализации. Например, если нужно передать массив ссылок, он преобразуется в соответствие, по типам ссылок, содержащее массивы уникальных идентификаторов. Это в разы меньше, чем передача ссылок в формате XML.
- поскольку обмен данными выполняется в онлайне, необходимости в передаче гигабайтов нет. Данные передаются чаще, поэтому их объемы гораздо меньше. Кроме того, приняты специальные меры для минимизации объемов передаваемых данных.
- типичное время прохождения данных (в обе стороны) составляет от долей секунды до нескольких секунд.
- разработка настроек обмена выполняется «сверху вниз», от сложных типов к простым. Для объектов с похожей структурой можно вообще не использовать настройку, будут переданы данные только для совпадающих по именам реквизитов.
- источник и приемник «общаются» друг с другом по следующей схеме (пример):
- Запросили накладные, заказы, все эти данные пришли, при получении запоминаются все ссылки, которые есть в этих данных.
- для всех ссылок используется один из вариантов (по выбору):
- оптимистичный, у источника по ссылкам запрашиваются только объекты, которые отсутствуют в приемнике;
- пессимистичный — запрашиваются все объекты по ссылкам
Эти подходы можно чередовать, например: один раз в час получать все объекты НСИ по ссылкам, а в течение часа — только отсутствующие в приемнике.
Если возможно внесение изменений в конфигурации баз данных, обменивающиеся через hsИнтегратор, то можно использовать и «специальный» вариант синхронизации, для всей нормативно-справочной информации (НСИ). Например, добавить регистр сведений с измерением «ЛюбаяСсылка» и числовым ресурсом «Версия». И подписку на событие «При записи» для синхронизируемых объектов метаданных на сервере. Инкрементирует версию только сервер, клиент хранит ту, что получил от сервера. Тогда клиент вначале передаёт серверу все ссылки (а фактически соответствие с массивами GUID-ов) и версии объектов НСИ, которые есть в базе клиента (вот тут и пригодится эффективная упаковка ссылок), а сервер в ответ высылает объекты по тем ссылкам, версии которых у клиента меньше. Запрос на сервере простой и быстрый, объемы передаваемых данных небольшие и синхронизация данных НСИ происходит практически мгновенно. При работе по планам обмена сервер каждому клиенту готовит отдельный информационный пакет. И чем больше клиентов, тем выше нагрузка на сервер. «Специальный» вариант синхронизации НСИ через hsИнтегратор снимает нагрузку с сервера, он по запросу клиента высылает только обновленные данные НСИ именно для этого клиента.
- При получении объектов запоминаются новые ссылки.
- Приемник запрашивает снова объекты по новым ссылкам (которые ранее не запрашивались) и история повторяется, пока все новые ссылки не будут «разрешены». То есть объекты по ним получены от источника или отсутствуют (битая ссылка в источнике).
- Каждый информационный обмен протоколируется на сервере — что запросили, что ответили, какая функция и в каком модуле была выполнена, какие характеристики информационной среды клиентского компьютера (процессор, память, версия операционной системы, пользователь). Можно хоть географические координаты клиентского компьютера передавать и фиксировать на сервере — это актуально для мобильных устройств.
- Все полученные объекты в транзакции записываются.
В результате вместо одного большого информационного пакета, включающего «всё», информационный обмен дробится на несколько небольших пакетов, не содержащих лишней информации. Кроме того, нет необходимости передачи «Правил обмена». Разработчик сам знает, что передал при вызове каждой функции и как «это» нужно обработать на приемнике. При таком подходе объемы пакетов значительно меньше, базы данных начинают «разговаривать» друг с другом. В течение одной секунды может пройти несколько информационных обменов.
Еще пример использования онлайновой синхронизации с централизованным ведением НСИ, когда мы хотим дать возможность клиенту заведения новых объектов НСИ:
- в качестве источника данных используется объект, сформированный на клиенте на момент наступления события «Перед записью».
- клиент передаёт объект серверу, по данным объекта сервер выполняет поиск аналогичного существующего объекта в своей базе. Если поиск успешен, сервер возвращает клиенту этот объект, данные объекта от сервера замещают данные клиента и событие «При записи» завершается. Если на сервере поиск не удался, то записывается объект, полученный от клиента и результат возвращается клиенту, который также записывает данные, полученные от сервера.
В результате в обоих базах мы получим идентичные или похожие объекты с одним уникальным идентификатором. То есть сможем делегировать часть функций по добавлению новых объектов на клиентские рабочие места.
- в качестве источника данных используется объект, сформированный на клиенте на момент наступления события «Перед записью».
- клиент передаёт объект серверу, по данным объекта сервер выполняет поиск аналогичного существующего объекта в своей базе. Если поиск успешен, сервер возвращает клиенту этот объект, данные объекта от сервера замещают данные клиента и событие «При записи» завершается. Если на сервере поиск не удался, то записывается объект, полученный от клиента и результат возвращается клиенту, который также записывает данные, полученные от сервера.
В результате в обоих базах мы получим идентичные или похожие объекты с одним уникальным идентификатором. То есть сможем делегировать часть функций по добавлению новых объектов на клиентские рабочие места.
Возможности текущей версии (1.0) реализации hsИнтегратор:
- Реализация в виде расширения, работает на платформе 1С:Предприятие 8.3.11 и выше. Применение расширения не требует внесения каких-либо изменений в конфигурации для организации обменов между базами данных.
- Интеграция в конфигурацию, работает на платформе 1С:Предприятие 8.3.9 и выше, и на мобильной платформе;
- Реализован обмен следующими объектами метаданных:
- Документы;
- Справочники;
- Перечисления;
- Простые типы (в т.ч. хранилище значений)
- Коллекциии (в т.ч. вложенные): массив, структура, соответствие, таблица значений.
- Один сеанс приложения 1С может подключаться к нескольким базам данных различных конфигураций и выступать сервером (если опубликован http сервис hsExchange). Возможно создание унифицированных модулей, которые возвращают данные одного формата клиенту, при подключении к серверным базам различных конфигураций. Например, в одной конфигурации содержится документ ПоступлениеТоваровУслуг, а в другой ПоступлениеТоваров, и структуры документов различные. Клиенту будут возвращаться данные в едином формате, соответствующем его структуре метаданных.
- При обмене возможно преобразование данных источника к структуре объектов приемника, в том числе и программная генерация данных для приемника.
- Рекурсивное «разрешение» ссылок для реквизитов запрошенных объектов.
- Возможна реализация последовательных цепочек обмена. Например: база РТ обращается к базе УТ за получением документов, а база УТ обращается в базу ЗУП для получения актуальной информации по ответственным за документы. Объединенные данные возвращаются в РТ. Поскольку обращение выполняется практически мгновенно (для повторных обращений, при первом обращении сеанс сервиса еще не кэширован и время обращения составит от одной до нескольких секунд), данные будут получены практически за секунду. Возможно также параллельное обращение к ЗУП и УТ со стороны РТ (если это будет разрешено службой безопасности).
- Концепция модулей. Модуль — это контейнер для хранения функций удаленного исполнения на сервере. Модуль характеризуется именем и может быть общим модулем расширения конфигурации, самой конфигурации или храниться в подключаемой дополнительно обработке с таким же именем (тогда это модуль объекта обработки). Если существует и общий модуль и подключаемая обработка, используется модуль обработки. Благодаря этому возможно оперативное изменение функционала приложения. Нужно просто скопировать текст общего модуля в модуль объекта новой обработки с таким же именем, подключить её и установить флаг использования.
- Протоколирование обмена на стороне сервера. В каждый информационный пакет, передаваемый клиентом или возвращаемом сервером, автоматически включается служебная информация. Протоколируется имя и место вызова модуля, имя вызываемой функции и все передаваемые и возвращаемые данные (протоколирование можно отключать). Служебная информация от клиента также содержит системную информацию о компьютере и среде исполнения на клиенте. Имеется встроенная функция быстрой очистки протокола до указанной даты . Пример содержимого записи протокола обмена:
- Уровни безопасности — стандартные (Web-сервер, аутентификация 1С:Предприятия, права доступа) и дополнительные: разрешение исполнения для конкретного идентификатора клиента (можно отключить проверку для всех клиентов), разрешение исполнения конкретных модулей (эта проверка не отключается из соображений безопасности). Настройка разрешений на сервере:
- Вызов функции удаленного исполнения на клиенте подобен следующему: Результат = ФункцияНаСервере(Параметры) , где Параметры и Результат — в общем случае коллекции данных, которые могут содержать вложенные коллекции. Для обмена объектами баз данных используется набор функций для преобразования объектов в коллекцию «ТаблицаЗначений» специального формата hsТаблицаЗначений и обратно. Ссылки передаются также в специальном формате hsСсылка.
- Передача информации об ошибках, возникших при исполнении на стороне сервера на сторону клиента и сохранение в протоколе на сервере.
Состав файлов публикации, которые можно загрузить из архива:
- Расширение hsИнтегратор
- Демонстрационные базы данных клиента и сервера. Никаких технических ограничений в демонстрационных базах нет, они предназначены именно для демонстрации технологии. В каждую из баз подключено расширение hsИнтегратор. Прикладные объекты различной структуры содержатся в конфигурациях клиента и сервера. Клиентская конфигурация содержит тестовую обработку для демонстрации различных вариантов использования технологии hsИнтегратор.
- Демонстрационная база мобильного приложения. Фактически является копией базы клиента, в которую расширение hsИнтегратор интегрировано (мобильная платформа пока не поддерживает работу с расширениями).
Перед загрузкой архива можно посмотреть видеоматериалы о технологии. Ссылка на папку с видеоматериалами:
На момент публикации в папке размещены следующие видеоматериалы:
- Инструкция по настройке подключения клиента к сервису.
- Обзор тестов в демонстрационной версии программы.
- Небольшой видеоматериал (18.5 минут) с демонстрацией технологии hsИнтегратор для мобильного приложения. Этот видеоматериал был создан на ранней стадии разработки технологии hsИнтегратор и показывает работу демонстрационного мобильного приложения, которое обменивается данными с конфигурацией, разработанной на базе 1С:Розница.
Технология hsИнтегратор не содержит ничего такого, что нельзя разработать в виде отдельных сервисов. Но она предлагает единый унифицированный сервис и формат обмена, позволяет быстро, с минимальными затратами на программирование, организовать онлайновый обмен между базами данных 1С. Это попытка создания унифицированного решения, как в приведенном выше примере с радиомодулем. В основу создания решения были положены следующие основные принципы:
- Решение должно быть простым в использовании на прикладном уровне.
- Должно одновременно работать в качестве клиента и сервиса (в мобильном приложении – только клиента);
- Не обязательно должно требовать внесения изменений в конфигурации интегрируемых баз данных;
- Насколько возможно, должно минимизировать трафик обмена данными и обеспечивать быструю реакцию на запросы со стороны клиента;
- Должно позволять выполнять обмен данными различной структуры через единый сервис;
- Должно обеспечивать безопасность использования;
Материалы к данной публикации можно загрузить здесь: //infostart.ru/public/1062681/. Материалы к публикации не содержат подробного описания возможных сценариев использования. На примерах из демонюстрационных баз уже можно создавать собственные прикладные решения для онлайнового обмена. Целями публикации являются рассказ о самой технологии hsИнтегратор, демонстрация возможностей текущей реализации и потенциала технологии.
Публикации о технологии будут продолжены, если будет интерес со стороны Сообщества программистов 1С.
