RabbitMQ + Конвертация Данных 3.0

Публикация № 692798

Обмен - Обмен с другими системами

RabbitMQ КД3 Enterprise Data YellowRabbitMQ БИТ:Адаптер Событийная модель Серебряная пуля

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

Содержание:

  1. Пользовательская история
  2. Критерии оценки вариантов
  3. Событийная модель и RMQ
  4. Маршрутизация в RMQ
  5. Принцип работы БСП по обработке сообщений в формате Enterprise Data
  6. Моделирование
  7. Механизм оповещения об ошибках
  8. Коллективная работа с КД3 и с универсальным форматом
  9. Механизм автотестирования
  10. Итоги проекта
  11. Полезные ссылки

 

Пользовательская история

Зайдя на проект, мы услышали следующую историю:

Исходное состояние:

Сложный ландшафт производственной компании, состоящий из нескольких территориально-распределенных систем на базе 1С:УПП, одну из которых планируется заменить на 1С:ERP в качестве основного результата проекта. Параллельно с ERP планируется внедрить новую версию PLM взамен старой. Кроме УПП есть другие 1С-системы: MDM, WMS, ТОИР и ЗУП2.5, которые по возможности надо оставить без изменений. Система MDM является основным, но не единственным поставщиком НСИ: например, физические лица рождаются в ЗУПе, полуфабрикаты в PLM, договоры в ERP. Между всеми системами действует обмен типа точка-точка, написанный на "1С:Конвертация данных 2.0", транспорт - XML-файлы через общие папки. Все конфигурации сильно кастомизированы.

Требования к результатам проекта в части интеграции:

- сократить время синхронизации данных между системами с 15-60 минут до нескольких секунд

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

- по факту возникновения ошибок обмена уведомлять систему Help Desk о каждом недоставленном объекте. После устранения причин сбоя недоставленные объекты должны быть переотправлены автоматически, чтобы исключить любые потери

- новый релиз правил обмена должен предварительно проходить автоматическое регрессионное тестирование, чтобы гарантировать целостность работающих правил

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

- в качестве потенциальных решений транспортного механизма рассматриваются:

-- web-сервисы,

-- Axelot Datareon ESB

-- БИТ:Адаптер, в котором используется внешняя компонента YellowRabbitMQ для работы с RabbitMQ от "Серебряной пули".

- времени на принятие концепции и ее реализацию - 5 месяцев

ОК, прежде чем генерить идеи, команда сформулировала: 

Критерии оценки вариантов

- Тестируемость

- Скорость

- Оптимальность потоков

- Независимость от обновления

- Трудоёмкость

- Централизация правил обменов (унификация)

- Поддержка событийной модели

Мы отлично понимали две вещи:

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

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

Далее идут варианты решений, вынесенные на обсуждение, в самом конце будет победитель:

Вариант №1. Вариант с Datareon сразу не прошел ни по срокам, ни по бюджету. Когда знакомишься с такими предложениями, на ум приходит треугольник качества имени Артемия Лебедева: "Долго, дорого, ах...нно!". Интересно, но не в этот раз, возможно когда интеграция будет единственным результатом проекта.

Вариант №2. Во всех информационных системах обновить версию БСП до последней, в которой появились web-сервисы в качестве транспорта для синхронизации данных, и продолжить использование существующие правила КД2. В принципе идея неплохая, учитывая, что 1С в последних версиях платформы 8.3 потрудился над кешированием открытия WS-сессий и заставил их работать реально быстро. Но в нашем проекте мы имели пять ИБ под 8.2, две из которых аж с уровнем совместимости 8.2.13, повышать который еще то развлечение. Следуя древнему принципу "работает - не трогай", мы решили не ворошить мамонтов.

Вариант №3. Создать 1С-базу в роли посредника обмена (аналог шины данных), архитектура данных которой будет похожа на заменяемую УПП и содержать объекты с максимальным количеством реквизитов, участвующих во всём обмене. Правила для обмена будут создаваться в КД2. Потоки данных будут входить в нее и расходиться в соответствии с правилами маршрутизации, заложенными внутри нее. Т.е. базам-отправителям необязательно знать обо всех получателях, их задача передать данные в одну эту базу. Плюсы: больше половины существующих правил КД2 удастся сохранить и использовать. Минусы: оперативность доставки будет недостаточная, потому что файл сообщения КД2 несет в себе схему данных и правила всех преобразований на стороне Получателя, а в рамках событийной модели каждый объект будет отправляться отдельным сообщением, даже если использовать web-сервисы или RMQ, каждое сообщение будет перегружено лишней информацией и накладные расходы на доставку будут чувствительны. Кроме того, еще одна 1С-база будет отжирать серверные ресурсы.

Вариант №4. Сымитировать в конфигурации КД2 концепцию КД3. Если представить универсальный формат Enterprise Data в виде реально существующей конфигурации и написать пару правил Источник->ED и ED->Получатель, при этом программные преобразования на стороне ED как получателя и отправителя свести к нулю, то для каждого направления обмена можно сложить, как из мозаики свой набор правил. Например, можно написать правила для MDM-ED, ED-ERP, ED-УПП, а на выходе получить скомпонованные правила для MDM-ERP и MDM-УПП. Конечно потребуется доработка КД2. Этот вариант по плюсам схож с №3, но в нем нет главного минуса - базы посредника, значит обмен будет идти быстрее. Но все равно недостаточно быстро из-за КД2-сообщения, перегруженного служебными данными.

Вариант №5. Реализовать концепцию, предлагаемую БИТ:Адаптером - база-отправитель является источником XSD-схемы данных, преобразования при отправке практически минимальны, основное преобразование происходит непосредственно на стороне получателей. Эта модель победила во всех номинациях, кроме "Унификация" и "Централизация". Мы увидели в ней много низкоуровневого кода - как потенциального источника ошибок и непрозрачности. Роль разработчиков выходит на первый план. Но концепция действительно рабочая в тех проектах, где нет строгих требований к централизации, и количество объектов обмена и сложность их преобразований невысокая. По мнению БИТа, она является эволюционной с точки зрения развития интеграционного контура предприятия: встраивание новых информационных систем происходит в основном силами разработчиков, ответственных за новые системы.

Вариант №6. Идея универсального формата и КД3 была принята большинством голосов. Как ни странно, она тоже является эволюционной при определенных обстоятельствах. Нет, когда в интеграционном контуре всего две-три информационные базы с сильно непохожими конфигурациями, кажется избыточным выполнение двойной работы по написанию правил выгрузки из источника в универсальный формат и из универсального формата в получателя. Но когда у каждой из трех непохожих баз есть очень похожие родственники, как в нашем случае два семейства: пять УПП-образных баз, две ERP-образных, и одиноко стоящий ЗУП2.5 по сути осколок УПП; и когда из любой базы данные могут передаваться в любые другие базы, идея с универсальным форматом уже не кажется дикой, напротив вполне рабочей. Ведь по сути типовые конфигурации 1С делятся на старые и новые архитектурные поколения, если в информационном ландшафте организации присутствует оба поколения, и для обоих написаны правила преобразования к универсальному формату, то никаких сюрпризов больше не будет. Отраслевые решения, такие как Axelot:WMS или Appius:PLM вынуждены архитектурно подстраиваются под современные типовые конфигурации. А если в ландшафт зайдет не 1С-система, типа SAP, никто не мешает договориться с сапёрами использовать существующий универсальный формат, или если сапёры упрутся, инкапсулировать их формат в существующий универсальный формат. Выбирая вариант №6, мы сознательно отказываемся от тяжёлого наследия КД2-правил и переходим к полноценным КД3-правилам. Конечно мы будем использовать код из старых правил КД2, и конечно мы будем подглядывать в типовые правила КД3. И мы сознательно идем на реформацию старых правил, т.к. это часть требований проекта.

Итоговый подсчет очков по 5-бальной шкале:

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

Событийная модель и RMQ

Тут всё просто. Событийная модель позволяет забыть про планы обмена и связанные с ними пакетные выгрузки. Проще говоря, больше нет необходимости накапливать ссылки на измененные объекты, а потом в условленный час отправлять большую телегу, в которую попадают только последние версии объектов. Теперь мы можем отдавать миру объект атомарно, столько раз, сколько успешно завершилась транзакция при его изменении. При этом отправитель не обязан ждать подтверждения доставки, его миссия закончилась, когда сообщение ушло за его пределы. За доставку и обработку сообщений отвечают другие системы. Безошибочная доставка и обработка сообщений - это нормальное поведение интеграционного контура, не надо тратить ресурсы на уведомление об этом. Извещать отправителя надо только в случае ненормального поведения.

Считается, что основная ценность событийной модели - не столько в оперативности доставки, сколько в соблюдении хронологии событий. У типичного брокера сообщений типа RabbitMQ три главные задачи: быстро получать сообщения из разных источников, быстро перенаправлять сообщения в одну или несколько очередей согласно правилам маршрутизации, и обеспечивать быстрое чтение очередей по методу FIFO. Фишка RMQ еще и в том, что он принципиально не хранит прочитанные сообщения, что делает его слегка безалаберным, но в то же время не слишком требовательным к файловым ресурсам, что радует.

Собственно чтение очереди по FIFO и даёт гарантию соблюдения хроники. Это ключевая функция RMQ, которая гарантирует правильное соблюдение цепочки бизнес-процессов на стороне получателя. Например, сначала должен появиться договор, а затем проведен инвойс по этому договору. Но бывают ситуации, когда допускается несоблюдение последовательности действий, если это не влияет на бизнес. Например, многие типовые конфигурации в пределах одной транзакции сначала создают подчиненный элемент, а потом самого владельца. С точки зрения событийной модели - это два разных события, которые будут воспроизведены на стороне получателя в такой же последовательности, и подчиненный элемент поживет какое-то время с битой ссылкой на владельца. Если это не повлияло на проведение документов, то бизнес ничего не заметит и все будут счастливы. Но если доставка новой номенклатуры задержалась на 15 минут или вообще остановилась, а через 15 минут начали поступать накладные с этой номенклатурой и их проведение остановились, то бизнес это почувствует и встанет на дыбы. Поэтому событийная модель должна быть обогащена системой приоритизации ошибок. Если упаковка прилетела без номенклатуры, мы позволяем ее записать с битой ссылкой и не считаем за ошибку. Если накладная прилетела без номенклатуры, то считаем это ошибкой и фиксируем ее в Help Desk как критический инцидент.

Маршрутизация в RMQ

Немного про маршрутизацию сообщений в RMQ. Сообщение RMQ состоит из шапки (Header) и доставляемых данных (Payload). В Header есть свойства:

Exchange - точка обмена, в нее отправители передают сообщения. Exchange бывают разных типов по способам маршрутизации. Мы использовали тип topic. Exchange хранит правила маршрутизации (Bindings), в соответствии с Bindings RMQ перенаправляет сообщение в очереди (Queues)

Routing Key - ключ маршрутизации

Properties - произвольный набор служебных параметров, которые помимо самого XML-объекта мы хотим показать получателям

Например, мы хотим, чтобы сообщение с XML-образом нового элемента номенклатуры было доставлено из MDM в PLM и ERP. Создаем в RMQ:

- две очереди Data_PLM и Data_ERP

- точку обмена Data

- в точке обмена Data создаем правила маршрутизации:

-- Если Routing Key содержит #.PLM.# - перенаправлять в очередь Data_PLM

-- Если Routing Key содержит #.ERP.# - перенаправлять в очередь Data_ERP

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

Теперь если мы из MDM отправим в RMQ сообщение, в котором Exchange = Data и Routing Key = .PLM.ERP., то RMQ переправит такое сообщение в две очереди Data_PLM и Data_ERP. Т.е. за формирование строки Routing Key отвечает база-источник, а за выполнение самой маршрутизации отвечает RMQ, при этом из базы источника в RMQ отправляется всего одно сообщение, а размножение этого сообщения на нужное количество сообщений и помещение их в очереди происходит в RMQ.

Разумеется Exchanges, Bindings и Queues в RMQ надо создать заранее, перед началом обмена.

Более подробно про маршрутизацию RMQ можно почитать тут или найти описание протокола AMQP, он реализован не только в RMQ.

RabbitMQ является свободным программным обеспечением, мануал по установке на CentOS тут. За внешнюю компоненту конечно придется заплатить. Мануал ВК YellowRabbitMQ можно почитать тут. Форум Пули про YellowRabbitMQ тут. При покупке компоненты вам подскажут адрес облака. Но не спешите делать выводы о производительности, у бесплатного сервиса ограничена пропускная способность, лучше заведите Кролика в своей локальной сети. У него достаточно скромные аппетиты к железу, мы использовали такую машину: vCPU (Core) / vRAM Gb / vSSD Total Gb - 2 / 4 / 100.

Принцип работы БСП по обработке сообщений в формате Enterprise Data

Первый релиз КД3 вышел 30.04.2015, в том же году в БСП 2.2 в подсистеме "ОбменДанными" появилась возможность обрабатывать сообщения через универсальный формат. Технология достаточно старая, 1С не собирается от нее отказываться и активно развивает, выпуская готовые правила для большинства современных типовых конфигураций, доведя количество релизов ED до шести.

КД3 обновляется не так часто, как хотелось бы. Последний релиз датируется 27.04.17, и там есть что дорабатывать. Но то что уже есть вполне пригодно, в том числе для коллективной разработки. Сердце КД3 - генератор кода - очень удобная фича: в визуальном конструкторе КД3 можно просто накликать передаваемые свойства и тут же получить модуль с кодом, что само по себе уменьшает трудозатраты и вероятность появления ошибок. Наполнение и отладку обработчиков "При отправке", "При конвертации данных XDTO", "Перед записью полученных данных" можно продолжить уже в целевой конфигурации. Модуль с кодом правил в типовых конфигурациях называется МенеджерОбменаЧерезУниверсальныйФормат. Кто помнит танцы с бубнами для отладки правил КД2, тот возрадуется!

Модуль БСП, формирующий XML-сообщение из выборки данных и получающий данные из XML-сообщения, называется ОбменДаннымиXDTOСервер. Описание универсального формата хранится в типовых конфигурациях в XDTO-пакетах с именами типа EnterpriseData_1_X. Мы возьмем за основу версию 1.5, т.к. на момент проекта она была последней.

Формат сообщения хранится в XDTO-пакете ExchangeMessage. Сообщение в универсальном формате имеет такую же структуру, как и в RMQ: шапка Header и тело сообщения Body. Body не является частью какого либо формата, это искусственный XML-элемент, поэтому оставим его для эстетики. Шапку для RMQ будем формировать сами, поэтому от ExchangeMessage надо избавляться. Но ExchangeMessage хранит в себе тип значения Ref, который используется как базовый тип в EnterpriseData, а в модуле ОбменДаннымиXDTOСервер используется в функции ЭтоСсылкаXDTO(). Значит тип Ref надо перенести в EnterpriseData, переписать ссылки на него, и доработать функцию ЭтоСсылкаXDTO().

Конечно это не единственная доработка модуля ОбменДаннымиXDTOСервер и XDTO-схемы EnterpriseData. Нам предстоит сделать обособленную подсистему, со своими префиксами имен объектов конфигурации и своим URI пространства имен, чтобы они не пересекались с типовыми, когда будем встраивать их в целевые конфигурации информационных баз, участвующих в обмене.

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

Модуль с кодом правил будем хранить в модуле внешней обработки, файл которой будем компоновать автоматически из КД3, запуская конфигуратор в пакетном режиме с параметром LoadExternalDataProcessorOrReportFromFiles.

Впрочем, обо всем по порядку.

Моделирование

Выше мы приняли решение применять концепцию событийной модели, формировать правила обмена в КД3, использовать универсальный формат ED, доставлять сообщения через RabbitMQ, оповещать базы-отправители только об ошибках. Опишем поведенческую модель механизма обмена. По нашей практике моделирование позволяет увидеть и учесть все нюансы прежде чем приступать к выработке архитектурного решения.

Шаг №1 "Регистрация"

При записи объекта данных на стороне отправителя:

Шаг 1.1. Определяем, участвует ли объект метаданных в обмене

Шаг 1.2. Определяем наличие изменений в сравнении с последней версией объекта. Это опциональная фича - защита от повторной передачи одинаковых данных с целью экономии трафика. В КД2 это называлось "Фильтр выборочной регистрации объектов". Это не просто сравнение двух XML-текстов, полученных методом СериализаторXDTO.ЗаписатьXML. Правильно сравнивать только те реквизиты, которые участвуют в обмене. Ну или хотя бы исключить общие реквизиты, типа "Дата изменения", опять же если они не участвуют в обмене.

Шаг 1.3. На основании правил регистрации данных определяем, каким получателям этот объект должен быть доставлен, и формируем строку Routing Key. Правила регистрации хранятся в РС "Получатели данных". Сами правила - это произвольный текст с кодом, или другими словами "Модуль отбора", цель которого - определить булево значение переменной "Отказ". В каждой базе-отправителе, для каждого типа данных, участвующего в обмене, для каждого получателя этого типа данных надо создать отдельную запись РС "Получатели данных". Если в каком-то направлении при определенных условиях данные не должны передаваться - тогда пишем код для этого условия в модуле отбора.

Шаг 1.4.  Определяем последнюю версии формата и модуля менеджера обмена. Зачем вообще версионировать формат и менеджер обмена? Допустим мы обновили версию формата одновременно во всех базах, но в очередях остались непрочитанные сообщения, сформированные с помощью предыдущей версии формата. Значит получатели должны иметь доступ ко всем предыдущим версиям формата и к последней версии менеджера каждой версии формата. Кроме того на случай отказа последней версии менеджера (если модуль не проходит проверку при компиляции из-за малейшей синтаксической ошибки - останавливается работа всех правил!) мы всегда должны иметь возможность откатиться на предыдущую стабильно работающую версию менеджера, хотя бы для передачи служебных данных (тех же версий форматов и менеджеров). В идеале мы конечно исключаем вероятность помещения в продуктив не протестированных версий, но разработчики в тестовом контуре должны иметь право на ошибку.

Шаг 1.5. С помощью доработанного модуля ОбменДаннымиXDTOСервер формируем текст XML-сообщения в формате Enterprise Data.

Шаг 1.6. Формируем параметры сообщения:

-- Exchange ID: это обязательный параметр, он указывает RMQ какая точка обмена будет обрабатывать сообщение. У каждой точки обмена свой набор правил маршрутизации. Наличие разных точек обмена расширяет возможности маршрутизации. Мы создали три точки обмена: XSD (для версий форматов и менеджеров обмена), DATA (для пользовательских данных) и LOG (для РС "Состояния сообщений" и "Ошибки обмена"). Сообщение с Exchange = XSD и RoutingKey = .ERP.PLM., будет переправлено в очереди XSD_ERP м XSD_PLM. Сообщение c Exchange = DATA и RoutingKey = .ERP.PLM. будет переправлено в очереди DATA_ERP и DATA_PLM. Хотя обе очереди XSD_ERP и DATA_ERP читает одна база ERP, приоритет обработки у них разный. Служебные данные надо доставлять в первую очередь. Получатели должны сначала выбрать все сообщения из очереди XSD, и только после этого приступить к очереди DATA.

-- идентификатор сообщения (Message ID): для облегчения отслеживания маршрута сообщения при разборе полетов

-- системное время события - время в миллисекундах завершения транзакции для соблюдения событийной модели (результат функции ТекущаяУниверсальнаяДатаВМиллисекундах)

-- сценарий обработки на стороне получателя: здесь может быть раздолье для творчества. Например, сколько раз делать попытку записи при конфликте блокировок транзакций, или что делать с документом, если он проводится с ошибкой, или снимать ли контроль при записи (ОбменДанными.Загрузка = Истина)

-- указатель на объект данных: сериализованный в XML однозначный идентификатор объекта данных, пригодится при разборе сбойных ситуаций, в частности для повторной отправки недоставленных сообщений. Для ссылочных типов - это пара "тип метаданных" и GUID ссылки, для регистров сведений - набор измерений.

-- HASH указателя на объект данных: его будем использовать на этапе записи объекта на стороне получателя: на случай если один и тот же объект передаётся в коротком интервале времени - будем использовать последовательную, а не параллельную обработку сообщений, но об этом чуть ниже. Сам HASH будет иметь тип УникальныйИдентификатор, полученный из предыдущего параметра (указатель на объект данных) по алгоритму MD5. Для совместимости с 8.2 алгоритм MD5 придётся брать из Windows, а не из платформы 1С, платформа .NET Framework обязательно должна стоять на машине с сервером 1С, чтобы обеспечить вызов COM-объектов:

Crypt = Новый COMОбъект("System.Security.Cryptography.MD5CryptoServiceProvider");
Text = Новый COMОбъект("System.Text.UTF8Encoding");

Шаг 1.7. Записываем полученное сообщение в регистре "Лог недоставленных сообщений"

Шаг 1.8. Записываем событие "Зарегистрирован" в регистр "Состояния сообщений"

Все механизмы шага №1 должны выполняться с максимальной скоростью, и защищены от каких либо падений по ошибкам, так как происходят на глазах у пользователя внутри транзакции записи данных. Нам удалось добиться длительности выполнения шага "Регистрация" не более 0,4 сек.

Шаг №2 "Отправка"

Шаг 2.1. Регламентное задание "Отправить сообщения в RMQ" отправляет в RMQ сообщения, накопившиеся в РС "Очередь недоставленных сообщений". После успешной отправки сообщения в RMQ запись из РС удаляется. Периодичность регл задания мы выбрали эмпирическим путём: каждые три секунды. Регл задание должно иметь уникальный ключ, чтобы исключить параллельное выполнение, что при такой частоте запуска не исключено. Результат запроса должен быть отсортирован по реквизиту СистемноеВремяСобытия, чтобы соблюсти событийную модель.

Выполнение запроса к РС надо выполнять внутри программной транзакции, чтобы исключить грязное чтение, т.к. запись в РС происходит внутри транзакций записи объекта данных, значит есть вероятность отката транзакции. Согласно теории, на объекты, записанные внутри транзакции накладывается блокировка типа X, которая запрещает другим транзакциям накладывать на этот объект любые другие блокировки. А при чтении внутри транзакции на объекты накладывается блокировка типа S. Значит запрос внутри транзакции ко всей таблице РС выполнится тогда, когда завершатся все начатые до этого транзакции, что и защищает от грязного чтения. Но такая защита не сработает, если база данных SQL переведена в режим READ COMMITTED SNAPSHOT. Эксперты так делают сознательно, когда ценность отсутствия блокировок при чтении внутри транзакции выше чем грязное чтение.

Почему нельзя было отправить сообщение на шаге "Регистрация" и тем самым ускорить процесс обмена? Честно говоря мы испугались оптимистичного сценария: что транзакция записи объекта данных после отправки не будет прервана, и что не будет коммуникационных проблем с сервером RMQ. Разработчики 1С-платформы не гарантируют очередности выполнения подписок на события в порядке следования в конфигураторе. Но даже если это и так, нет гарантии, что в будущем какой-то внедренец не вставит в конец списка свою подписку и она не будет прерывать транзакцию. Что касается коммуникационных проблем - как показала практика сам Кролик работает стабильно, и сообщения уходят быстро, потому что мы не передавали тяжелые бинарные данные, и вообще старались не помещать в сообщение больше одного объекта. Но опять же нет гарантии что в будущем не найдется внедренец, который нарушит эти правила.

Шаг 2.2.- записываем событие "Отправлен" в регистр "Состояния сообщений"

При желании передачи записей регистра "Состояния сообщений" в отдельную базу с целью логирования - можно рассматривать этот регистр как объект обмена (на диаграмме отправки он закольцован на вход алгоритма), но тут главное вовремя прервать бесконечную рекурсию - отключить запись состояний "Зарегистрирован" и "Отправлен" при передаче самого регистра "Состояния сообщений"!

 

Шаг №3. "Доставка"

Шаг 3.1. На стороне получателя регламентное задание "Получить сообщение от RMQ" читает содержимое очередей RMQ и записывает их в РС "Лог состояний сообщений" со статусом "Доставлен". РС хранит не только статус сообщений, но и содержимое, чтобы на следующем шаге можно было их преобразовать из универсального формата в объект получателя и записать.

Имена очередей и их приоритетность хранится в справочнике "Источники данных". Сначала выбираем все сообщения из очереди с приоритетом 0. После этого читаем одно сообщение из очереди с приоритетом 1, возвращаемся к нулевой очереди и так далее. Почему так? Через очередь XSD мы передаем служебные данные (версии форматов и версии менеджеров обмена), их мы должны получить как можно быстрее и быть во всеоружии, т.к. в очереди DATA могут быть сообщения с обновленной версией формата.

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

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

Шаг №4. "Запись"

Шаг 4.1. Фоновое задание "Обработать доставленные сообщения" читает из РС "Лог состояний сообщений" необработанные сообщения, разумеется в порядке системного времени события, полученного на шаге 1.6.

Шаг 4.2. Для каждого сообщения запускается отдельное фоновое задание "Обработать доставленное сообщение", которое производит преобразование и запись объекта, а так же снимает признак "Не обработано" с полученных сообщений и записывает в РС состояние "Записан".

Фоновое задание "Обработать доставленные сообщения" выполняет две важные функции:

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

- выстраивает сообщения с одинаковым HASH указателя на объект данных (полученного в шаге 1.6) в последовательную цепочку, чтобы не получить взаимных блокировок.

Для чего нужны все эти сложности с параллельностью обработки полученных сообщений? Для производительности. Шаг Записи из всех четырех шагов (Регистрация, Отправка, Доставка, Запись) самый медленный, а быстродействие всего механизма обмена определяется суммой всех шагов.

Опытным путем мы установили оптимальное число фоновых заданий - пять. Это то число, которое в реалиях заказчика обеспечивало скорость доставки в среднем 4 секунды, и в то же время не мешало работе пользователей на стороне получателя. При 50 параллельных заданиях пару раз в день мы наблюдали картину, как вся база вставала колом. Изоляция фоновых заданий в отдельные рабочие процессы на сервере 1С не сильно помогала. Причем это была именно деградация производительности сервера, а не эскалация блокировок.

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

 

Механизм оповещения об ошибках

На тему ошибок есть две важные установки:

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

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

Поведенческая модель механизма следующая:

- сообщение об ошибке попадает в РС "Ошибки обмена". У него заполняется три измерения "HASH указателя на объект данных", "ИБ возникновения ошибки", "ИБ источник объекта". Соответственно если ошибка возникает в том же месте, по тому же объекту, то информация о ней актуализируется, а не множится.

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

- все записи РС "Ошибки обмена" передаются на сторону ИБ-отправителя. В форме списка РС есть две кнопки: "Переотправить выделенные сообщения" и "Переотправить все сообщения". Поиск объекта для переотправки происходит с помощью реквизита "Указатель на объект данных". Для ссылочных типов - это пара "тип метаданных" и GUID ссылки, для регистров сведений - набор измерений. Таким образом, после устранения причины ошибки у службы поддержки есть возможность одним нажатием переотправить все недоставленные объекты из ИБ-отправителя.

- каждые 15 минут запускается регламентное задание по отправке сообщений о текущих ошибках в Help Desk. Оповещения об ошибках отправляется непосредственно из ИБ возникновения ошибки. В Help Desk по виду объекта и месту возникновения определяется уровень критичности ошибки.

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

- Внешняя компонента V8RMQClient вдруг перестала работать, причем метод ПодключитьВнешнююКомпоненту("ОбщийМакет.V8RMQClient", "V8RMQClient", ТипВнешнейКомпоненты.Native) выполняется успешно, но любые другие действия приводят к ошибке "не найден файл внешней компоненты". Выяснилось что айтишники периодически в папках сервера 1С чистят кэш. 1С-платформа само действие по записи файла компоненты из общего макета на диск выполняет лишь раз, а при повторном обращении сразу берет файл с диска. В общем договорились с айтишниками, что они чистку кэша будут совмещают с перезагрузкой сервера 1С и проблема исчезла.

- В самом начале мы забыли про защиту запуска регл заданий от копирования базы, и с удивлением наблюдали, как из очередей стали пропадать сообщения - одну очредь читали разные базы! Сделали стандартный механизм  сравнение со строкой подключения ИБ, и заодно сценарий поведения при разоваричивании копии продуктовой базы в тестовом контуре - автоматическое переподключение к другому серверу RMQ и отключение оповещений Help Desk.

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

- Это даже не ошибка, а фича. Все наверное уже забыли, что в СУБД платформы 8.2.13 константы хранились в одной таблице в виде одной строки с кучей колонок. И в языке запросов обращение к ним было "Выбрать К.ИмяКонстанты Из Константы КАК К", а не "Выбрать К.Значение Из Константа.ИмяКонстанты КАК К". Мы это "вспоминали" каждый раз, когда обновляли нашу подсистему в конфигурациях 8.2.13. Вообще, написание универсальной подсистемы, совместимой со всеми версиями платформы, начиная с 8.2.13 и выше - сильно взбодрило! Пришлось вспомнить многие хорошо забытые вещи. И все равно в итоге при обновлении каждой конфигурации приходилось идти по внушительному чек-листу, чтобы не забыть учесть все локальные нюансы.

Коллективная работа с КД3 и с универсальным форматом

Большая часть времени проекта была посвящена написанию правил обмена в КД3 и обогащению универсального формата Enterprise Data новыми объектами. Временами количество одновременных разработчиков доходило до 5. Как мы решили проблему коллективной разработки:

- в состав типовой конфигурация КД3 включен план обмена "Рабочие места" с правилами обмена на КД2. Каждому разработчику создали распределенную базу КД3

- так же в составе конфигурация КД3 есть иерархический справочник "Группы правил", он прошивает все правила обработки данных, правила конвертации объектов, правила конвертации предопределенных данных и алгоритмы. В нем мы создали группу "Разработка" и под ним имена разработчиков. Мы договорились, что пока идет разработка и тестирование новых правил, разработчик помещает правила в свою папку. Это служит сигналом для других разработчиков, что правила захвачены и их трогать нельзя.

- доработку XDTO-объекта EnterpriseData каждый разработчик вел в конфигураторе своей базы КД3. Базы КД3 подключены к хранилищу конфигурации. Разработчик захватывает XDTO-пакет, вносит изменения, выгружает пакет в XSD-файл, загружает файл в структуру формата в своей базе КД3, проверяет, помещает XDTO-пакет в хранилище, извещает остальных разработчиков, если были затронуты чужие объекты.

 

Жизненный путь релиза с правилами в итоге получился такой:

- разработка и тестирование правил в контуре разработчика

- автотестирование релиза правил в тестовом контуре

- разворачивание в продуктивном контуре копии КД3 из тестового контура

- распространение правил из КД3 по информационным базам продуктового контура

 

Механизм автотестирования

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

Мы разработали справочник "Шаблоны автотестирования" и регламентное задание, которое выполняет на стороне ИБ-отправителей создание и удаление объектов данных по шаблонам. Далее вся информация о результатах обмена стекается в базу анализа результатов автотестирования.

На первом уровне анализа проверяется сам факт передачи объектов в нужных направлениях.

На втором уровне проверяется качество передачи - сравниваем подготовленные заранее XML-эталоны: с XML объекта данных на стороне отправителя, c XML текстом сообщения в формате ED, и с XML объекта данных на стороне получателей.

На скриншоте показан отчет первого уровня анализа. Очевидно, что тест "Штрихкоды" не выполнился, т.к. на стороне получателя была ошибка.

 

Итоги проекта

  1. Все исходные требования к результатам проекта в части интеграции были выполнены
  2. Появился прецедент синтеза двух современных механизмов интеграции - КД3 и RMQ

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

Полезные ссылки:

Авторы:

Рецензенты:

125

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. pbabincev 108 21.03.19 19:30 Сейчас в теме
Парни, вы круты! Очень реально круто!
Kosstikk; tva120; o.nikolaev; barelpro; A_Max; Krio2; +6 Ответить
2. SirAlex1C 21.03.19 22:14 Сейчас в теме
Спасибо за качественную статью!
o.nikolaev; barelpro; A_Max; Krio2; +4 Ответить
3. kalyaka 476 22.03.19 07:05 Сейчас в теме
Напишите как вы на практике решали вопрос с массовыми изменениями? Скажем если происходит обновление данных в справочниках, достаточно ли эффективен в этом случае подход пообъектной сериализации или для таких случаев лучше выполнять синхронизацию, используя другие технологии?
DimaP; A_Max; +2 Ответить
23. barelpro 960 22.03.19 14:40 Сейчас в теме
(3) Хороший овпрос! Массовый обмен надо разделить на два случая:
1. Первичный перенос из старой системы в новую - лучше делать на КД2. Все таки накладные расходы на поштучную обработку отнимают ресурсы и время, да и событийность не надо соблюдать
2. Групповая обработка - тут ничего не поделаешь, если изменяется значение реквизита, который участвует в обмене - ничего не поделаешь надо обмениваться. Но:
- Если реквизит не участвует в обмене - от лишнего трафика спасает механизм на шаге 1.2.
- Если реквизит участвует в обмене - время обработки очереди на шаге №4 (Запись) конечно удлинняется. Если такие изменения позарез нужны бизнесу в течение дня и нет возможности перенести на вечер, тогда кратковременно врубаем 50 параллельных фоновых. Так же у нас есть возможность на шаге №2 в пользовательском режиме отключать чтение очереди "в транзакции". Ведь когда он включен - мы ничем не лучше чтения таблиц регистрации планов обмена - тот же эффект ожидания блокировок. Но мы хотя бы можем это параметрически регулировать.
4. jobkostya1c8 81 22.03.19 09:24 Сейчас в теме
Интересно будет подробнее прочитать про новые технологии.
5. Robbi 53 22.03.19 10:27 Сейчас в теме
Хороший подход, так и надо делать все обмены и рэббит отличная вещь.
Имхо: кд3, куча форматов ed, xdto, xml - это кошмар и тупик. Очень жаль, что 1с идет в этом направлении.
И лично мне не нравится использование com компонент для рэббита и хэша, хотя это простой и легкий путь, но красивее что-то другое придумать.
6. lustin 1020 22.03.19 10:48 Сейчас в теме
(5)
com компонент для рэббита


Откуда взялась информация о COM компоненте ? Там чистый Native Win32/Win64/GCC32/GCC64
7. Evil Beaver 5546 22.03.19 11:10 Сейчас в теме
(6) Переведу многонерусскихбукв от Алексея на 1С-овский :)

Там нет COM-компонентов, не надо ничего на машине регистрировать/администрировать, плюс это полная кроссплатформенность Windows/Linux 32 и 64 бита.

Кстати, у нас вышло в продажу еще и дополнение для БСП, в котором как раз штатными обменами отправляются сообщения в RabbitMQ. На сайте пока нету, но по телефону можно все узнать. Позволяет быстро получить интеграцию на штатных механизмах типовых 1С-систем. С другой стороны, быстро - не значит правильно, и для сложных гетерогенных проектов, когда есть не только 1С, нужно что-то "посерьезнее".
o.nikolaev; artbear; +2 Ответить
9. AntonSm 23 22.03.19 11:37 Сейчас в теме
(7)
у нас вышло в продажу еще и дополнение для БСП, в котором как раз штатными обменами отправляются сообщения в RabbitMQ.

скажите, пожалуйста, стало очень интересно.
Т.е. получается, что можно взять типовые обмены, например, между УТ11 и Розницей, вашу компоненту, поставить рядом RabbitMQ и все будет обмениваться практически в реальном времени?
Я имею ввиду именно ту ситуацию, когда типового обмена достаточно, когда нет реальной необходимости в полноценном внедрении RabbitMQ вашими силами с учетом всех мыслимых нюансов и вот этим всем.
18. lustin 1020 22.03.19 13:28 Сейчас в теме
(9) В целом именно так. То есть меняется только транспорт с файлов/web-сервисов

позволяет сделать следующий ход

0. старт
1. взять инфраструктурщиков и попросить у них кластер RMQ
2. поменять транспорт БСП
3. запустить обмен по новому транспорту
4. переписывать обмены не надо - все полетит уже по новому, PROFFIT Номер 1
5. прикинуть где нужен реальный обмен уже с явным использованием событийной интеграции
6. взять бизнес-событие (например "Обновление данных Номенклатуры")
7. реализовать по новому
8. запустить "Событийную интеграциию для номенклатуры"
9. Запустить уже БЕЗ инфраструктурщиков
10. Proffit Номер 2

То есть получается этакий гибрид штатного обмена и нового.
Прикрепленные файлы:
A_Max; barelpro; +2 Ответить
8. Evil Beaver 5546 22.03.19 11:13 Сейчас в теме
Выяснилось что айтишники периодически в папках сервера 1С чистят кэш


Я просто поинтересоваться - а как это они у вас так чистят кеш? При работающем сервере, прямо у него из-под носа убирают файлы? Клево, а кто им такое разрешил?
15. barelpro 960 22.03.19 13:20 Сейчас в теме
(8) Мы не стали интересоваться, просто перевели сервера в другую обслуживающую компанию )
19. lustin 1020 22.03.19 13:30 Сейчас в теме
(8) это прям жестоко получается - серверный кеш при попытке удаления будет ругаться что файл занят. Это надо постараться чтобы так сделать.
10. artbear 1116 22.03.19 11:46 Сейчас в теме
(0) Добавьте правильную ссылку на компоненту и описание интеграции от Серебряной Пули, пожалуйста.

https://silverbulleters.org/elasticbus
13. barelpro 960 22.03.19 13:10 Сейчас в теме
(10)
Там чтобы скачать документацию надо ввести свои данные. ввел пару раз, но так ничего и не пришло. Это может отпугнуть разрабов, слишок коммерческая страничка.
16. lustin 1020 22.03.19 13:20 Сейчас в теме
(13) Это я так сделал. Я увидел твои заявки и подумал что ты экспериментируешь с сайтом и их почистил ;-). Поэтому коллеги твоих запросов не увидели ;-).
49. barelpro 960 25.03.19 17:13 Сейчас в теме
(16) Мне ответил по почте руководитель отдела продаж, и сказал, что "Документацию предоставляем, кто приобрел dll, но саму документацию утерял."

Вот я сижу и думаю, что за хиртый рекламный ход - размещать на страничке продукта кнопку "Скачать документацию PDF", а потом отказывать в этом?! )
JohnyDeath; +1 Ответить
14. barelpro 960 22.03.19 13:11 Сейчас в теме
(10)
Там чтобы скачать документацию надо ввести свои данные. Ввел пару раз, но так ничего и не пришло. Слишком коммерческая страничка, это может отпугнуть разрабов, .
11. Pipapalamm 22.03.19 11:55 Сейчас в теме
Аплодирую стоя. Пока такие спецы есть - родина без автоматизации не останется!
A_Max; jif; barelpro; +3 Ответить
12. artbear 1116 22.03.19 11:58 Сейчас в теме
(0)
На первом уровне анализа проверяется сам факт передачи объектов в нужных направлениях.

На втором уровне проверяется качество передачи - сравниваем подготовленные заранее XML-эталоны: с XML объекта данных на стороне отправителя, c XML текстом сообщения в формате ED, и с XML объекта данных на стороне получателей.


не совсем понял, зачем и что проверяете.

кролик же гарантирует доставку и качество.

у вас были случаи, когда сообщение доставлено, но частично?
17. petrpk 22.03.19 13:25 Сейчас в теме
(12)когда идёт доработка правил одновременно с разработкой конфигурации есть большой шанс что кто то накосячит, например уберет реквизит или целый справочник . Поэтому сравнение итогового сообщения важная штука.
20. barelpro 960 22.03.19 13:38 Сейчас в теме
(12) Тут речь немного о другом. Мы же проверем новый релиз перед накатом на продуктив.
Качественный анализ автотеста показывает, что с момента создания шаблона что-то произошло именно в контексте этого объекта метаданных - изменились правила, изменился формат, изменилась архитектура. Т.е. заставляет тестировщика сфокусироватья на конкретных изменениях. Если это ошибка - отдать на исправление, если это развитие - актуализировать шаблон.
21. ManyakRus 283 22.03.19 13:52 Сейчас в теме
1) про КОМ-обмен между 1С ничего не написано,
подошло бы лучше всего.
2) В 1С правила обмена уже содежит список изменённых данных предназначенных для обмена, поэтому никакой RabbitMQ не нужен, можно этот же список использовать как очередь
3) "...ERP обменивается со всеми остальными системами" - достаточно изменить 1 конфигурацию 1С, а вашим методом все конфигурации изменять придётся
22. barelpro 960 22.03.19 14:20 Сейчас в теме
(21)
1. К обмену через com-соединение много вопросов: по быстродействую, по чуствуительности к обновлению платформы. Не наш вариант.
2. Механизм "Планы обмена" - хорошая штука, у 95% организаций до сих пор работает. А вы пробовали запускать такой обмен каждые три секунды?
3. Если оставаться на планах обмена и правилах КД2 - то да, ничего менять не надо, кроме самих правил. Но тут см п.2
24. ManyakRus 283 22.03.19 15:49 Сейчас в теме
(22)
1) по быстродействию быстрее, только платформа одинаковая должна быть
2) КОМ-обмен будет работать каждые 3 секунды, через XML вряд ли
3) с КОМ-обменом тоже изменять надо только 1 базу
25. barelpro 960 22.03.19 16:23 Сейчас в теме
(24)Если есть конкретный проект - опишите, с удовольствием почитаем! Я серьезно!
26. MaxS 1537 23.03.19 08:38 Сейчас в теме
Интересно было почитать. Не во все тонкости ещё вник. Была подобная задача в 2015-м году. Интеграция стороннего софта для производства с 1С УПП, в перспективе с КА 2, БП 3 и т.п. Поэтому выбрал КД3. По окончании проекта явно прослеживалась необходимость в другом транспорте, но бюджет и сроки не дали развития. Хорошо, что вам удалось разработать концепцию, собрать команду, реализовать и поделиться идеей.

По поводу формирования строки Routing Key. В типовом XDTO пакете ExchangeMessage есть же свойства To и From тип строка. Можно было их использовать? В поле To записать всех адресатов, на стороне приемника перепроверять для него ли это сообщение.

И некоторое время назад появилось свойство AvailableObjectTypes. Может быть это пригодилось бы.
Это свойство с одной стороны увеличило объем сообщения как в КД2 - в каждое сообщение добавляется список поддерживаемых объектов - что может принять база и что может отправить, чтобы не выгружать то, что не может принять другая сторона.
Может быть имело смысл обмениваться этими данными не в каждом сообщении, а при изменении правил. Как это зафиксировать - другой вопрос. Можно по факту перезаписи настроек узла или по таймеру раз в сутки.
28. barelpro 960 23.03.19 15:44 Сейчас в теме
(26) Спасибо за комментарий!
Вы пишите про маршрутизацию - механизм, который указывает, какие типы метаданных из какого источника в какие получатели и при каких условиях должны уходить. В 1С-ской концепции обмена через универсальный формат за маршрутизацию отвечают знаменитые правила регистрации КД2. Ваше предложение я тоже понял: в конечном итоге надо минимизировать доработки типового механизма, как это кстати сделали ребята из Пули, выпустив. недавно дополнение для БСП, в котором штатными обменами отправляются сообщения в RabbitMQ.
Все эти знания в конечном итоге поступают на вход конкретных проектов, и архитектор принимает одно из двух решений:
1. Использовать комбинацию тиражных решений с минимальныи доработками и в дальнейшем мириться с тем что это не до конца вписывается в потребности конкретного бизнеса (кто-то скажет что у него вписалось идеально, но я в сказки не верю, особенно для крупного бизнеса, где каждая деталь имеет значение)
2. Или кастомизировать имеющиеся решения с максимальным учетом особенностей бизнеса.

А теперь скажите, какое из двух решений является более интересным для нас с вами, и является эволюционным с точки зрения развития имеющихся решений или даже появления новых тиражных продуктов? )))
29. MaxS 1537 23.03.19 16:48 Сейчас в теме
(28) Лично мне интереснее 1-й вариант, т.к. позволяет многократно использовать(продавать) собственные решения за счет максимальной совместимости с тиражными решениями. Проще найти специалиста для поддержки.
2-й вариант на первых порах интереснее бизнесу, дороже, сложнее в долговременной поддержке, т.к. нужны уникальные знания специалистов. И данное решение может отстать в развитии от тиражного, где скорее всего появится что-то интересное для этого бизнеса. Вероятность того что это индивидуальное решение для бизнеса станет тиражным - низкая. А для команды разработчиков и внедренцев этот вариант может оказаться топтанием на месте. Время идёт, деньги платят, собственного развития нет. А конкуренты из варианта 1 за это время уже наработали более совершенный материал для будущего проекта.
30. barelpro 960 23.03.19 20:23 Сейчас в теме
(29) согласен полностью, но я немного о другом )
27. alexei366 23.03.19 15:17 Сейчас в теме
Может быть пригодится, в тексте было:

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

Я гарантирую!) Если создать динамическую подписку "ПодключитьОбработчик" - он точно последним сработает.
То есть можно сделать подписку на все объекты на событие "ПередЗаписью", и там на объект подключать динамическую подписку.
Я использовал такую схему, чтобы замерить к примеру проведение документов, чтоб гарантирована замерить все операции и не вставлять замеры во всевозможных местах.
31. barelpro 960 23.03.19 20:26 Сейчас в теме
(27) интересно!
А можно чуть подробнее про метод ПодключитьОбработчик или ссылку?
45. alexei366 25.03.19 02:25 Сейчас в теме
(31) Да проще в синтаксис помощнике почитать, этого хватить должно.
https://its.1c.ru/db/v8314doc#bookmark:dev:TI000000212​;
barelpro; +1 Ответить
47. barelpro 960 25.03.19 12:17 Сейчас в теме
(45) А, понял, ДобавитьОбработчик, а не ПодключитьОбработчик. Да, инересно, мы совсем забыли про эту возможность, хотя она в 8.2.13 уже была. Спасибо за идею!
32. Vladimir Litvinenko 1637 24.03.19 12:31 Сейчас в теме
Как в при такой схеме обмена решалась проблема с коллизиями изменения данных?

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

Возьмем классическое описание коллизии для такого случая.

1) В базе "А" изменился элемент справочника "Номенклатура".
2) Одновременно с этим в базе "В" изменился тот же элемент справочника.
3) База "А" выгружается свои изменения в RMQ.
4) База "В" выгружается свои изменения в RMQ.
5) В базу "А" приходит элемент из базы "В" и затирает ранее сделанные в базе "А" изменения.
6) В базу "В" приходит элемент из базы "А" и затирает ранее сделанные в базе "В" изменения.
7) Имеем итог: две базы просто обменялись состоянием элементов. Ни в одной из них оно не стало корректным.

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

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

Обрабатывалась ли такая ситуация в данном случае?
35. barelpro 960 24.03.19 16:04 Сейчас в теме
(32) Да, в теории коллизии возможны, но реальный бизнес мы (автоматизаторы) должны убеждать, что у каждого элемента НСИ или документа должно быть одно место публикации, остальные места - чисто подписчики для чтения. Допускается цепочка дообогащения элементов по базам, но без обработной связи. Иначе будет хаос в информационной системе и в конечном счете в бизнесе .

В данном проекте нам удалось решить коллизию с номенклатурой, которая рождается и в НСИ и в PLM следующим образом:
- выделили разные диапазоны артикулов для новой номенклатуры, заводимой в MDM и в PLM.
- номенклатура, попавшая в PLM из MDM блокируется програмно для изменений
- как только номенклатура, попавшая в MDM из PLM дообогащена, то такая номенклатура в PLM блокируется для изменения
DimaP; A_Max; Vladimir Litvinenko; acanta; +4 Ответить
42. Vladimir Litvinenko 1637 24.03.19 21:32 Сейчас в теме
(35) Большое спасибо за ответ!

А сам RMQ не содержит средств для анализа таких ситуаций? Всё же хотелось бы, чтобы такого ограничения не было.

Представьте себе ситуацию (пример из реальной практики) когда есть центральная база, например ERP, где контрагент/партнер создаётся через обмен с сайтом или после звонка в кол-центр. Затем этот клиент может прийти в магазин, где идёт работа в другой базе, например УТ или Рознице. Там он уточняет персональные данные, которые уходят обменами в центральную базу. Сразу после покупки он может зайти на сайт с телефона или позвонить в кол-центр и поменять ещё какие-то данные о себе. Например забыл в магазине сообщить новый номер телефона и решил его уточнить. А данные эти идут в центральную базу и затем снова в базу магазина.

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


Нет ли при использовании RMQ возможности обработать коллизии программно, а не организационными методами? Например, можно ли при отправке в очередь получить от самого RMQ информацию, что аналогичная информация (например с таким же GUID или заголовком) уже есть в очереди для обработки той базой, которая собиралась отправить её со своей стороны, и перед отправкой должна быть получена и обработана ей?
44. barelpro 960 24.03.19 23:15 Сейчас в теме
(42) Нет, RMQ это всего лишь быстрый транспорт, не более.
Ситуацию которую вы описали можно попробовать решить так: разделить карточку клиента на две группы одинаковых реквизитов по их автору:
1 группа - реквизиты измененные сотрудниками компании
2 группа - реквизиты измененные самим клиентом

Далее должен быть какой-то механизм принятия одного из вариантов в качестве основного, скорее всего привязанный к какому-то событию - не знаю, личному общению клиента с оператором, либо валидация документов. В любом случае - это задача службы, ответственно за НСИ.
Vladimir Litvinenko; acanta; +2 Ответить
33. acanta 48 24.03.19 13:12 Сейчас в теме
При коллизии есть возможность увидеть, чей вариант в данной базе и когда он возник в источнике?
36. barelpro 960 24.03.19 16:06 Сейчас в теме
(33) да, там где это нужно, мы сделали специальный РС для ссылочных объектов - указывающий место публикации элемента
34. acanta 48 24.03.19 14:10 Сейчас в теме
Спасибо за статью, хотела сказать что лично мы застряли на 4 варианте и даже не представляли что такое возможно.
37. barelpro 960 24.03.19 16:09 Сейчас в теме
(34) Интересно, удалось в итоге внедрить эту схему?
38. acanta 48 24.03.19 16:40 Сейчас в теме
(37) это оказалось вредная идея фикс, из за которой генерация других идей и вариантов был остановлен, а реализация этого требует больше времени, чем прогнозное время поддержки формата ED.
Со временем, думаю кд 3 допилят, добавив в нее то, чего в ней не хватает, например корреляции между конфигурациями и форматом ED.
39. barelpro 960 24.03.19 17:52 Сейчас в теме
(38) Вангую, что 1С поймет наконец, что ED надо дать возможность дорабатывать, а не пользоваться суррогатами, типа AdditionalInfo. Может сделают нормальный конструктор. Загрузчик данных из конфигураций. Подключение к хранилищу....
Vladimir Litvinenko; acanta; +2 Ответить
41. MaxS 1537 24.03.19 18:03 Сейчас в теме
(39) универсальный формат ED можно дорабатывать, никто не запрещает и даже КД3 поддерживает. Правда его универсальность пропадёт. Но если в рамках одной организации нужно наладить обмен между зоопарком разных баз, это может быть выходом. Универсальный формат в пределах Вашей организации будет.
43. Vladimir Litvinenko 1637 24.03.19 21:50 Сейчас в теме
(39) Ох. Сколько лет уже прошло, но этой возможности не появилось. Кажется что ED изначально создавался и сейчас развивается в основном для обмена с базами регламентированного учета (БП, ЗУП). Раньше даже обмен характеристиками номенклатуры не был полноценно реализован и доработка была не из простых. И чтобы видами номенклатуры обменяться надо было сильно постараться. Сейчас наверное уже доработали.

P.S.: Проверил. Видов номенклатуры по прежнему нет. То есть, например, чтобы отправить из одной базы УТ в другую номенклатуру нового вида по прежнему нужно свой пакет создавать или делать собственную сериализацию и паковать вид в AdditionalInfo. В таких условиях конструктор пакета действительно не помешал бы.
46. MaxS 1537 25.03.19 06:40 Сейчас в теме
(43) В формате 1.6 виды номенклатуры есть и в ERP 2.4.7 и аналогичных КА, УТ они появились так же как и характеристики, но вариант из коробки опять нерабочий. Нет обмена дополнительными реквизитами характеристик, вид номенклатуры без справочника "Наборы дополнительных реквизитов и сведений".
Пришлось всё переделать в расширении. Но оно не решает все вопросы - пока нельзя изменить состав плана обмена не меняя конфигурации.
Не хватает в ED универсального документа и справочника с универсальной табличной частью, чтобы не меняя формата была возможность обменяться неподдерживаемыми форматом документами и справочниками. Пришлось в качестве универсального справочника использовать статьиДДС и на стороне приемника проверять что это, чтобы подставить нужное ПКО.
A_Max; acanta; +2 Ответить
69. acanta 48 01.04.19 13:22 Сейчас в теме
(43)
P.S.: Проверил. Видов номенклатуры по прежнему нет. То есть, например, чтобы отправить из одной базы УТ в другую номенклатуру нового вида по прежнему нужно свой пакет создавать или делать собственную сериализацию и паковать вид в AdditionalInfo.


Если учитывать что
ED изначально создавался и сейчас развивается в основном для обмена с базами регламентированного учета (БП, ЗУП).

То это логично, в БП виды номенклатуры соответствуют группам финансового учета (хотя он этого тоже не знает).
40. acanta 48 24.03.19 17:56 Сейчас в теме
На доработки конфигурации лимит установлен был виндоус, а не 1с. Количество одновременно открытых объектов при объединении конфигураций ограничено.
Следовательно либо групповая разработка одной конфигурации без объединения, либо предельный размер конфигурации в половину от лимита.
48. DimaP 56 25.03.19 16:24 Сейчас в теме
Очень ценная статья!
Наконец-то начали использовать RMQ для обменов между конфигурациями на 1С.
Собственно, к этому уже давно шло. Возможно, когда-нибудь появится типовое тиражируемое решение.

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

Отдельно увидел ссылку на "Пулю" - было бы интересно увидеть как это решение организовано и работает. Возможно, какие-то сравнительные тесты и как использовали на практике.
50. barelpro 960 25.03.19 19:01 Сейчас в теме
(48) Согласен, для принятие решения, какой вариант использвать в проекте, надо больше информации и сравнительных тестов.
Такие тесты по идее могут себе позволить разработчики тиражных решений, но они точно будут предвзяты в свою пользу )
Мы руководствовались интуицией и здравым смыслом, бюджета и времени на принятие более взвешенных решений не было. И нам очень не хватало независимых мнений. Поэтому мы и написали эту статью, чтобы хоть как-то заполнить пробелы, и помочь членам нашего сообщества.
51. OerlandHue 26.03.19 04:10 Сейчас в теме
Баг, при котором затирается базовый тип у объектов при импорте xsd схемы вы как обошли?
52. barelpro 960 26.03.19 09:22 Сейчас в теме
(51) Ого, тоже через это прошли? )

Ну собственно как я и описал - избавились от ссылки на базовый тип Ref пакета ExchangeMessage. Просто перенесли его внутрь самого пакета ED и переписали на него ссылки всех ссылочных типов.
А до этого в явном виде указывали путь к ExchangeMessage внутри XSD-файла с помощью конструкции:
<xs:import schemaLocation="\\Server\EM.xsd" namespace="http://www.1c.ru/SSL/Exchange/Message"/>
Только так он начинал видеть базовый тип Ref, а не AnyType.
Но это варварство каждый раз дергать файловую систему, поэтому решили радикально.
OerlandHue; +1 Ответить
53. OerlandHue 26.03.19 09:36 Сейчас в теме
(52)
вый тип Ref пакета ExchangeMessage. Просто перенесли его внутрь самого пакета ED и переписали на него ссылки всех ссылочных типов.
А до этого в явном виде указывали путь к ExchangeMessage внутри XSD-файла с помощью конструкции:

Только так он начинал видеть базовый тип Ref, а не AnyType.


А как без решения этого бага можно делать свой ED? Мы сейчас, например, берем, в УП добавляем в свой ED новый объект, теперь нужно обновить в БП его же, приходится делать через сравнение объединение конфигураций, потому что удалять-добавлять из буфера Пакет - а это значит менять идентификатор объекта метаданных, чего делать не хочется - GIT захламляется ненужными изменениями, да и сравнение-объединение не по наименованию при обновлении правильно использовать.

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

Спасибо, что потрудились все выложить, тут материала намного больше, чем кажется и некоторые решения вызывают восхищение. И у нас как раз куплен rabbit MQ, но мы еще не остро столкнулись с медленной работой обмена, нет срочных требований этот обмен ускорить, поэтому не думали, как шину данных применять в этом кейсе.
barelpro; +1 Ответить
63. petrpk 27.03.19 12:00 Сейчас в теме
(53)Мы сейчас, например, берем, в УП добавляем в свой ED новый объект, теперь нужно обновить в БП его же, приходится делать через сравнение объединение конфигураций, потому что удалять-добавлять из буфера Пакет - а это значит менять идентификатор объекта метаданных .

Тоже через это прошли. Поэтому вынесли наш пакет(ed) в хранилище значений отдельного справочника. Добавили к нему номер версии и автоматизировали создание и рассылку новой версии ed из базы кд3 по всем конфигурациям.
54. MaxS 1537 26.03.19 09:42 Сейчас в теме
(51) сталкивался, ещё не пробовал автоматизировать. Может быть поможет совет. В командном режиме выгрузить конфигурацию полностью или частично в файлы, посмотреть в каком виде оно там хранится, подменить файл пакета и загрузить обратно файлы в конфигурацию.
55. barelpro 960 26.03.19 09:50 Сейчас в теме
(54) Ага, почти так и делали. Только когда делаешь выгрузить конифгурацию в файлы, XDTO-пакет туда не попадает. Все гораздо проще делается:

Делаем "Экспорт XML-схемы". Делаем поиск и замену. Делаем "Импорт XML-схемы". Дальше появлется окно "Выбор обновляемых простанств имен", ставишь галочку - и все готово!
56. Vladimir Litvinenko 1637 26.03.19 10:19 Сейчас в теме
(55) При выгрузке/загрузке конфигурации XDTO-пакеты выгружаются/загружаются также как и все прочие объекты. Просто ему даётся расширение .bin. Но фактически это текстовый файл с xml-содержимым:
57. barelpro 960 26.03.19 12:46 Сейчас в теме
(56) Согласен, погорячился )
58. maxim4566 26.03.19 21:21 Сейчас в теме
Только решил изучить, захожу а тут токая годнота.
59. Kosstikk 86 26.03.19 21:38 Сейчас в теме
Спасибо за статью!

Несколько не прозрачно, что именно выбрали для взаимодействия с RabbitMQ из 1С, YellowRabbitMQ?

Подскажите, рассматривали вариант взаимодействия через http api? Насколько он приемлем, есть ли ограничения? (скорость, количество запросов и т.д.)

Если правильно понимаю, такая возможность есть:
https://pulse.mozilla.org/api/
https://stackoverflow.com/questions/32486398/publishing-to-the-default-rabbitmq-exchange-using-the-http-api
60. barelpro 960 26.03.19 22:37 Сейчас в теме
(59) Отвечаю по пунктам:

1. Взяли YRMQ из коробки БИТ:Адаптер (сразу не разобрались, что концепция БИТ:Адаптер нам не подходит, иначе купили бы только YRMQ)

2. Мы тоже по-началу думали, что запросы HTTP можно реализовать средствами 1С и отказаться от внешней компоненты. Но, знающие люди подсказали, что это будет работать в разы медленее. Хотя и не привели никаких веских доказательств или замеров, кроме общедоступных: RPC работает на транспортном протоколе TCP, а HTTP изначально не транспортный протокол. Так что вопрос на самом деле остается открытым. Может кто сможет внятно объяснить или привести пруфлинки?

PS Если поискать в англоязычной среде, то можно найти те же самые выводы, но чуть более обоснованные: https://stackoverflow.com/questions/16838416/service-oriented-architecture-amqp-or-http
61. Kosstikk 86 27.03.19 08:17 Сейчас в теме
(60)
YRMQ


Тоже сразу подумал, про ограничения, http - это 250-500 запросов в секунду, никак не 150 000 )))
а Rabbit умеет MQTT -> AMPQ и это круто, конечно.

Надо подумать про YRMQ.
Просто в одном случае мы имеем доступное api от разработчика rabbit и возможности 1с для реализации, в другом прослойку native api с возможными ограничениями (там вроде же подписку надо покупать и компонента именная, утечет - будут проблемы).
Причем, как я вижу, для любых популярных языков работа с rabbitMQ - разжевана, 1с как всегда оставляет возможность разработать что-то самому и запаковать в компоненту.

Еще вопрос, почему отказались от 1с планов обмена как механизма регистрации изменений?) Объективно.
barelpro; +1 Ответить
62. barelpro 960 27.03.19 11:00 Сейчас в теме
(61)

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

2. Планы обмена не вписывались в концепцию быстрой передачи.Нам надо формировать XML-образ объекта в формате ED сразу, внутри транзакции при измененнии. Поэтому мы сделали РС "Очередь недоставленных сообщений" - по сути аналог плана обмена, С той лишь раницей, что у нас образ объекта формируется сразу на момент изменения, а таблицы изменений плана обмен хранят ссылки. И мы в любой момент готовы отказаться от этого промежуточного буфера, и отправлять сообщение сразу внутри транзакции, если будем иметь гарантию, что транзакция не прервется и каналы связи не заглючат. По поводу действий в конце транзакци транзакции - тут в форуме подсказали старый добрый ДобавитьОбработчик. А по поводу надежности канала - тут надо время пособирать статистику.

Хотя вот прям сейчас подумал, если использовать ДобавитьОбработчик, то последднюю милю по формированию сообщения в ED и его отправке можно пройти уже в фоновом задании, которое запускать прямо перед завершением транакции. В общем есть еще куда расти )))
70. barelpro 960 02.04.19 23:47 Сейчас в теме
(61)
Да, Пуля подтвердила, компонента именная!
Годовая подписка на обновление компоненты - порядка 30тр. Брать или не брать - личное дело каждого. Мы например использовали старую версию, в которой еще не было метода сжатия сообщений, сейчас бы это пригодилось. И еще узнали про пару полезных фичей и исправленных багов. В общем для следующего проекта будем брать компоненту сразу у Пули. Сейчас активно изучаем Кафку (и вспоминаем Грегора Замзу )))
64. Cyberhawk 110 28.03.19 09:22 Сейчас в теме
В шаге 2.1 вы пишете, что накладываете разделяемую блокировку на весь регистр объектов к отправке, что делает невозможным запись в этот регистр на время такой блокировки.
Т.е. во время отправки каждая транзакция записи объекта в БД, которая уже готова пополнить очередь отправки (заблокированный регистр), будет ждать окончания отправки, правильно понимаю?
65. barelpro 960 28.03.19 13:10 Сейчас в теме
(64) Всё верно, это защита от грязного чтения. Точно такой же эффект в механизме планов обмена.
Блокировка типа S накладывается на время выполнения запроса, это никому не мешающая пара миллисекунд, зато запрос читает только записи завершенных транзакций.
Если вдаваться в детали - блокировка S устанавливается не на всю таблицу, а на весь результат запроса - а это уже завершенные записи. Т.е. сам он никому не мешает, зато ему мешают незаконченные транзакции.

Но выше было описан способ как обойти эту проблему.
67. Cyberhawk 110 28.03.19 13:57 Сейчас в теме
(65)
блокировка S устанавливается не на всю таблицу, а на весь результат запроса
А, понятно, т.е. просто Запрос.Выполнить() в транзакции, что в худшем случае (8.2) блокирует считанный диапазон на запись только на время выполнения этого запроса, а в лучшем (8.3 или RCSI) вообще ничего не блокирует.
Я-то сначала думал, что речь о явной (устанавливаемой кодом) упр. блокировке, которая держится до конца транзакции (выгрузки), поэтому и "напрягся" :)
68. barelpro 960 28.03.19 14:24 Сейчас в теме
(67) ага, именно так:
НачатьТранзакцию();
Р = Запрос.Выполнить();
ЗафиксироватьТранзакцию();
71. tambu 9 18.04.19 08:27 Сейчас в теме
Спасибо за такой содержательный материал. Порадовала связка ED+Rabbit. Когда-то, когда появился самый первый курс по КД3, я спрашивал преподавателя, не является ли КД3 предтечей появления шины данных 1С. Он поговорил с разработчиками КД3 и ответил, что таких планов нет.
Спасибо за ваш труд, уверен, он будет очень полезен всем 1Сникам.
Не нашел ответа лишь на один вопрос, как дела у этой связки с производительностью. Понятно, что сам кролик быстр, но всё в комплексе? Если, к примеру, связи не будет сутки и накопится большая очередь? Когда-то мы сравнивали производительность обменов КД2 и КД3 и последняя была не на высоте, на наших объемах скорость выгрузки падала в разы, до загрузки даже и не доходило. Правда это было три года назад.
Плюс, событийная модель. Если «классический» обмен мы можем провести ночью, тем самым утилизируя сервера, когда нет пользователей, то в событийной модели мы как будто получим в базе-приемнике прирост количества пользователей на количество пользователей источника.
Я понял, что вы ограничили количество фоновых и тем самым снизили нагрузку, но хотелось бы услышать для какой системы приемлемы такие параметры? Сколько пользователей, сколько документов создается в час\сутки, сколько сейчас "весит" база и как быстро растёт?
Есть ли у вас опыт применения в высоконагруженных системах, где в источнике и приемнике работают несколько сотен пользователей одновременно?
Понятно, что самое длительное – это проведение документов и его можно отложить на ночь, но тогда несколько теряется смысл, вроде данные доставили, а в отчетах всё равно получим информацию «завтра».
Любопытство не праздное - сами сейчас на распутье, КД2 уже "не вывозит", думаем на что заменить. Пока рабочий вариант - пустить НСИ через веб-сервисы (возможно с кроликом), а документы через КД2, но уже без справочной информации (только ссылки).
Оставьте свое сообщение