Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Термины и определения

ТерминОписание
RabbitMQ

Платформа, реализующая систему обмена сообщениями между компонентами программной системы (Message Oriented Middleware) на основе стандарта AMQP (Advanced Message Queuing Protocol).

Красивую картинку и описание терминов на английском см. https://www.cloudamqp.com/docs/index.html

Очередь (Queue)Буфер содержащий сообщения для получения клиентами (из одной очереди могут получать сообщения один или несколько клиентов)
Сообщение (Message)Единица обмена которая передается от отправителя получателю, состоит из ключа маршрутизации и текста сообщения (у нас в виде строки)
Узел обмена (Exchange)Получает сообщение от отправителя и пересылает его в одну или несколько очередей в зависимости от правил маршрутизации
Правила маршрутизации (Binding)Правила, по которым определяется списко очередей в который поместить сообщение из узла обмена. В данном проекте используются только правила с видом "прямой обмен" (Direct Exchange), которые позволяют определить очередь по равенству ключа маршрутизации (но возможны и другие виды чуть более сложных правил)
Ключ маршрутизацииСтроковой ключ характеризующий сообщение и использующейся для маршрутизации
База МДМБаза данных БИТ:MDM в которой ведется общая НСИ
Прикладные системы (базы)Другие базы на предприятии (как на базе 1С так и нет) которые получают информацию из базы МДМ и обмениваются между собой прочей информацией с использованием RabbitMQ
Enterprise DataТиповой 1Сный формат (и механизм) обмена данными между базами
БрокерСервис предоставляющий услуги по обмену сообщениями, пока предполагается использовать  www.cloudamqp.com

Принцип работы RabbitMQ

Концепция

UI Steps
UI Step

RabbitMQ используется как один из каналов обмена между учетными системами предприятия и базой МДМ (может использоваться как единственный канал и как один из нескольких каналов). В частности для обмена информацией об НСИ RabbitMQ используется для online передачи информации об НСИ, но параллельно могут использоваться и старые каналы (типовой обмен 1С через Enterprise Data) для offline обмена

UI Step

Для обеспечение обмена через RabbitMQ для баз на основе 1С используется внешняя компонента Yellow Rabbit MQ http://infostart.ru/public/570477/

UI Step

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

UI Step

При изменении объекта в базе НСИ по нему готовиться сводная информация и помещается в точку обмена НСИ "data_bitmdm". Дальше база MDM "забывает" о том, что отправила сообщение по данному объекту (отправил и забыл). Сообщение об НСИ одинаковое (общее) для всех прикладных систем:

  • Один объект - одно сообщение
  • Ключ сообщения содержит идентификатор объекта НСИ, который отправляется в прикладные подсистемы (может использоваться для маршрутизации)
  • Текст сообщения содержит информацию о реквизитах изменившегося объекта + дополнительную информацию которая может потребоваться для его обработки в прикладных системах (например ключевые реквизиты подчиненных справочников)
UI Step

Информация по объекту НСИ включает в себя всю информацию, необходимую для его загрузки в прикладные системы

  • реквизиты объекта, отмеченные как участвующие в обмене
  • информация дубль/эталон
  • пометка удаления
  • ключевые реквизиты объектов, ссылки на которые есть в выгружаемом объекте, если эти реквизиты требуются для корректной загрузки объекта (механизм интерактивной отметки таких реквизитов уже есть в базе МДМ)
  • Описание самого объекта (Имя, тип)
UI Step

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

UI Step

Для целей обмена НСИ создаются следующие очереди:

  • для каждой прикладной системы создается отдельная очередь сообщений с НСИ, называется <Код узла>.data.bitmdm
  • для каждой прикладной системы создается отдельная очередь сообщений со структурой НСИ, называется <Код узла>.datastructure.bitmdm
  • для каждой прикладной системы создается отдельная очередь сообщений с файлами присоединенными к НСИ, называется <Код узла>.files.bitmdm
  • общая очередь сообщений с текущим состоянием приема НСИ, называется mdm.log.bitmdm
UI Step

В точке обмена "data_bitmdm" происходит "разделение" сообщения и рассылка по очередям "*.data.bitmdm", по одной отдельной очереди для каждой прикладной системы. По умолчанию сообщение рассылается всем прикладным системам, но можно настроить маршрутизацию и отправлять каждой прикладной подсистеме не все объекты метаданных, а только часть (например ЗУПу не нужна информация по номенклатуре)

UI Step

В процессе обработки полученного сообщение прикладная подсистема:

  • Обрабатывает сообщение в несколько этапов, при этом по каждому этапу выкладывает ЛОГ в очередь "mdm.log.bitmdm" через точку обмена "log_bitmdm"
  • Как только сообщение получено оно удаляется из очереди "mdm.log.bitmdm", даже если его не удалось обработать
  • Предполагается поэтапная обработка сообщений в прикладных системах: вначале при приеме пытаемся записать полученный объект "как есть" (даже с "битыми" ссылками), затем регл. заданием проверяем корректность полученного объекта и выполняем его обработку (если требуется)
UI Step

Общие правила создание объекта НСИ из сообщения:

  • при полученной объект создается только по данным находящимся в сообщении (нельзя закладываться на наличие какие-либо другие данные в прикладной базе)
  • если для создания объекта требуется какая-либо дополнительная информация, то ее нужно включить в ключевые реквизиты в базе МДМ и выгружать вместе с сообщением. Например в в зависимости от значения реквизита "Тип темы" в справочнике "Темы расчетов" ссылка на которую есть в Договоре, в базе ERP могут создаваться разные договора (с контрагентом, договор лизинга, договор кредита,..), в этом случае "Тип темы" нужно сделать ключевым реквизитом и выгружать вместе с договором
  • если для полноценного создания объекта НСИ в прикладной базе требуются данные из нескольких сообщений (невозможно решить задачу через ключевые реквизиты), то при загрузке сообщения создается "не консистентный" (не полностью заполненный) объект НСИ, а затем регламентное задание в базе получателе, проверят получения всех данных, и до создает объект (и пишет об этом в "mdm.log.bitmdm" для базы МДМ).
    Например в базе ERP на основании данных о "Спецификации на продажу" и "Договора" мы создаем виртуальный договора под каждую спецификацию. Не целесообразно включать в сообщение со спецификацией и с договорам полностью все данные из связанного справочника, по этому такие виртуальные договора создаются отдельно регл. заданием, при условии что и основной договор и спецификация получены.
UI Step

Пакет содержащий информацию о ходе загрузки в очереди mdm.log.bitmdm содержит следующую информацию

  • Ключ сообщения "<Состояние загрузки>.<Код узла>" (Возможные состояния: Отправлено/Загружено/Обработано/Ошибка)
  • Тело сообщения содержит ГУИД элемента, дату и время события, само событие, имя системы сгенерировавшей сообщение, а также текст сообщения об ошибке (если произошла ошибка)
UI Step

Система МДМ обрабатывает сообщения из очереди mdm.log.bitmdm

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

...