Огненный РИБ на базе YRMQ

Контекст:

  • существует БСП - библиотека стандартных подсистем
  • внутри БСП существует подсистема обмена данными
  • указанная подсистема встроена в любую типовую или не типовую конфигурацию 1С с режимом совместимости не ниже 8.2.13 запускаемых на версиях платформы старше 8.3.6 (УПП возможна ;-))

Сценарий

  • Когда при развертывании сколь угодного большого количества узлов распределенной информационной системы выбирается транспорт “RabbitMQ”
  • Тогда распределенные узлы начинают обмениваться пакетами в онлайне посредством протокола AMQP
  • И вся необходимая топология обмена создается на сервере RabbitMQ автоматически
  • И внедренцу остается только загрузить в распределенный узел штатный файл НастройкиРаспределённойБазы.XML

А теперь если коротко:

Предпосылки

При переходе на событийную интеграцию, существует 2 необходимых шага

  • Развертывание инфраструктуры RabbitMQ
  • Выявление события в бизнесе которое требует реального онлайна

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

Вместе с этим все типовые обмены сейчас большей частью работают на базе подсистемы БСП “ОбменДанными” - включая не только РИБ, но и обмен между УНФ и Бухгалтерией например (конечно там чуть сложней, но для простоты объяснения пусть будет так).

Как сделать быстрей ?

главное сделать первый шаг - а первый шаг заключается в формировании заявки на выделение серверов RabbitMQ.

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

Что в итоге ?

По двум проектам, которые у нас в Пуле были в работе мы сделали из своих наработок продукт - встраиваемый в БСП в виде протокола и дополнительной обвязки.

Фактически является частью нашего проекта по внедрению YRMQ в периметр предприятия.

Если есть желание внедрить проект с онлайн-РИБом

  • телефон написан на сайте, почта всем известна.
  • разработчиков уровня БОГ не требуют - с вашей стороны понадобится только один 1С специалист и один администратор. У которых РИБ сейчас есть в работе.

Что получают бизнесмены

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

За счёт чего происходит ускорение работы с часов до миллисекунд? В риб же тормозит не транспорт, а планы обмена и чтение сообщений. Чем смена транспорта может в этом помочь?

2 Симпатий

Имеется в виду моментальное попадание пакета к приемнику, без почты, ftp, смс и всяких таких немного архаичных транспортов. По уму, все равно правильной схемой является централизованная событийка с прописанными интерфейсами данных для межсистемного обмена. Но эта подсистема позволит создать предпосылки для перехода к “правильной” интеграции.

2 Симпатий

Сообщение перенесено в новую тему: Как правильно передавать CF в условиях РИБ

Про цф я не говорил. Речь про данные

А если отбросить вопрос скорости?
У кролика же есть лимит на размер сообщения? Тогда, вероятно, отправка обновления конфигурации может не пройти. Как решается такая проблема?

Давайте, тогда уж разберемся с терминологией. Речь идет о подсистеме “Обмен данными” из БСП. Это не РИБ в том смысле, о котором ты говоришь. Мы встроились именно туда. Просто так повелось, что термины используют взаимозаменяемо, хоть это и ошибка.

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

Итак, большие файлы таки на ФТП, Кролик только говорит, что их пора забирать.
Сообщения ребита афаир разбираются фоновыми заданиями.
Ручная магия в в 99% случаев от транспорта не зависит.

Откуда берутся “большие файлы”? Если вы делаете “акт обмена” раз в 1-2 минуты, то в плане обмена регистрируется немного данных. Они очень быстро уезжают кроликом, и очень быстро из соседнего узла прилетает ответ. Объемы данных в такой схеме не должны вырастать радикально.

Если же это Highload и за 1-2 минуты успевает накопиться дофигищща данных, то вам полюбому не надо смотреть на планы обмена и БСП с его “Обмен данными”. Ваш путь - нормальная событийка, когда бизнес-события нигде не копятся, а отправляются заинтересованным лицам по мере возникновения.

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

В телеге поняли правильно - новый транспорт в штатной БСП.

Дык БСП поддерживает РИБ. Это тоже часть подсистемы Обмен данными

йа ниновижу риб, у мну личная неприязнь. Риб мастдай, R.I.P, ололо!!!11

3 Симпатий

Я же в заголовке написал

Видимо всех настолько достал сам РИБ, что не обратили внимание на описание.

Название темы несколько смущает. А так после дополнений здесь и в соседней теме стало понятней (мне по крайней мере). Спасибо.