Распутывая узлы интеграции: Построение архитектуры слабосвязанных систем, или Кролики наступают

Управление - Интеграция

116
Речь пойдет об интеграции систем. Кому вообще стоит обратить внимание на эту статью? Если у вас всего лишь две типовые конфигурации, то вам, наверное, эта тема будет не очень интересна – у вас нет тех проблем, с которыми сталкиваются люди, имеющие три системы и более. Но если у вас есть больше двух систем, а особенно, если есть веб-сайт, который обменивается с 1С, вам точно стоит это прочитать.

О чем будем говорить?

  • О типичных проблемах интеграции в проектах 1С и о том, как их решать.
  • Я постараюсь донести до вас концепцию событийной интеграции и рассказать о том, насколько это хорошо и правильно.
  • Мы рассмотрим паттерны решений различных проблем с помощью очередей.
  • Я расскажу о нашей подсистеме Yellow RabbitMQ («Желтый кролик») – что это и как это «дружит» с 1С.

Как выглядит типовой корпоративный ландшафт?

Типовой корпоративный ландшафт сегодня – это зоопарк систем, где есть:

  • База для ведения бухгалтерии;
  • База НСИ;
  • База для склада;
  • Свой сайт;
  • Все, что угодно.

 

Пример из жизни (торговая организация):

  • В системе продаж продажники заводят контрагентов;
  • В складской системе регистрируется запуск фур по каким-то заявкам;
  • На сайте принимаются заказы клиентов;
  • Работает своя система для учета звонков call-центра;
  • Типовая база для ведения бухгалтерии;
  • И тут же еще рядом «Зарплата и управление персоналом», куда сотрудникам падают премии за продажи.

 

Множество различных систем, и все это между собой интегрировано.

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

Типичные проблемы при интеграции множества систем

Какие типичные проблемы возникают при интеграции множества систем?

  • Это – сильная связанность смежных систем между собой, обусловленная взаимозависимостью их компонентов. Она влияет:
    • На работоспособность этих систем;
    • На их реализацию.

Такое состояние, когда изменения в одной системе «ломают» другую систему, из-за чего в нее также приходится вносить изменения, как раз и называется «сильной связанностью».

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

Привычные средства интеграции в мире 1С

В мире 1С приняты следующие классические средства интеграции:

  • Обмен файлами, который все любят – в одной системе кнопочку нажали, документы выгрузили, в другой – загрузили. Перепутали, загрузили какой-то не тот файл, поудаляли документы – все как обычно.
  • Более «продвинутые пацаны» используют удаленные вызовы процедур (некие вызовы из системы в систему). Сюда относятся:
    • Веб-сервисы;
    • HTTP-сервисы;
    • COM/OLE.
  • Некоторые используют прямой доступ к базе данных 1С – способ не очень красивый, но также распространенный. Залезают на SQL-сервер и что-нибудь из базы 1С вычитывают, или даже, не дай бог, туда пишут, притворяясь сервером 1С – такое тоже бывает.

Два типа интерфейсов

Существует два типа взаимодействия, два типа интерфейсов.

  • Первый тип – это pull-интерфейсы, вытягивающие или «сосущие» интерфейсы. Это когда мы обращаемся в некую систему с целью забрать оттуда какие-то данные. Или опросить ее, нет ли у нее для нас каких-либо новостей, каких-либо изменений.
  • И второй тип – это уведомляющие интерфейсы. Здесь ситуация полностью обратная: когда в какой-нибудь системе происходит событие (некий акт ввода данных), эта система уведомляет всех заинтересованных о том, что в ней что-то произошло.

 

Использовать «сосущий» вариант интерфейса – это неправильно, поскольку:

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

Интегрирующая среда

Когда систем становится много, обязательно возникает потребность в интегрирующей среде.

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

Наличие интегрирующей среды обеспечивает:

  • Слабую связанность систем. Мы можем вообще заменить одну систему на другую (например, убрать SAP и поставить 1С), а остальные клиенты этого даже не заметят.
  • А также прозрачность. Например, когда вам нужно «распутать клубок», вы, глядя на административный интерфейс интегрирующего ядра, сможете понять:
    • Кто;
    • С кем интегрируется;
    • В каком формате;
    • Как часто;
    • А также измерить нагрузку на системы, возникающую в процессе обмена.

Без имени – нет предмета

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

Казалось бы, причем здесь интеграция?

Выделение потоков данных

 

А интеграция здесь вот причем. Перед ее реализацией нам обязательно нужно:

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

Распутываем клубок

После выделения потоков данных переходим к «распутыванию клубка»:

  • Пытаемся отсортировать потоки данных – их все, как правило, можно отнести к трем категориям.
    • Нормативно-справочная информация.
    • Оперативные данные, «первичка» (то, что приходит из реального мира).
    • И порождаемые данные – это то, что выходит из бизнес-процесса.
  • Итак, мы выделили все эти бизнес-потоки, дали им отдельные имена, написали их на бумажках и прикололи на доску. Дальше начинаем растаскивать эти бумажки по категориям – здесь у нас НСИ, здесь «первичка», здесь порождаемые данные. И следующим шагом определяем взаимосвязи между потоками. Чтобы это было легче делать, лучше рисовать диаграммы.
    • Data-Flow-диаграммы;
    • Или диаграммы сущность-связь, которые все знают.

Это – очень полезно, особенно с учетом того, что есть много бесплатных инструментов, которые позволяют удобно делать все эти диаграммы. Их можно хранить в том же GIT, как и другую документацию по проекту.

Уникальность НСИ

Отдельно хотелось бы остановиться на НСИ, потому что это – самая большая часть задачи, которая требует наведения порядка.

Существует масса подходов к наведению порядка в нормативно-справочной информации.

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

То есть, система должна обеспечивать однозначную идентификацию объектов. По этому поводу есть замечательная статья Александра Масляева на Инфостарте Mom and Dad`s Misery. Если у вас проблемы с интеграцией по справочникам – обязательно ее прочитайте. Это прямо must read.

Инвертировать хранение

Следующее, на что нужно осмелиться – это реализовать инвертирование хранения. Это значит, что:

  • Нужно хранить у себя собственную копию данных для каждой системы.
  • Например, если вам нужно забирать из какой-то системы справочники, не надо постоянно к ней обращаться за этими данными, скопируйте эти справочники себе и обновляйте их по событию, когда в источнике они поменяются.
  • Вы так развязываете системы между собой – когда вторая система «сломается», у вас не «встанет» обмен, первая система продолжит работать.
  • Для этого нужно обеспечить обособленное хранение данных для обеих этих систем у себя и событийную интеграцию их между собой (обновление).
  • Там, где это сделать нельзя, нужно использовать резервирование системы, чтобы бизнес-процессы не останавливались при сбоях.

Все есть событие

И последний момент из теории – «Все есть событие»:

  • Ось времени реального мира – это ваш ориентир. Разбираясь с бизнес-процессом, разбираясь с интеграцией, которая потребуется для этого бизнес-процесса, всегда рисуйте себе таймлайн реального времени и отмечайте на нем:
    • Что;
    • В какой момент;
    • И в какой из систем происходит (или в каком-то отделе или корпорации).
  • Задним числом ничего не бывает – машины времени не существует.
    • Попытки строить интеграцию, которая разрешает проведение задним числом – это выкапывание ямы самому себе. Даже перепроведение документов задним числом происходит сейчас – в прошлое бухгалтер не улетал.
    • Поэтому намного дешевле организационно запретить любые операции «задним числом», чем потом пытаться построить такую интеграцию, которая бы при изменении в прошлых периодах автоматически деактуализировала данные во всех смежных системах.
    • Лучше просто это запретить и сказать «Сторнируйте и все». Это будет реально дешевле, хотя и неизбежно встретит сопротивление.
  • После того как мы выделили эти бизнес-события, происходящие в системе, мы должны разослать их всем заинтересованным.
  • И по большому счету, нам больше ничего делать не нужно – задача интеграции на этом заканчивается.

Если бы все было так просто… на самом деле, здесь все только начинается.

Captain Rabbit to the Rescue!

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

Существует высокопроизводительный промышленный сервер очередей, который называется RabbitMQ. В переводе, если кто не знает, это значит «кролик».

Этот сервер очередей позволяет организовать самые разные схемы взаимодействия систем между собой. Он:

  • Высокопроизводительный;
  • Отказоустойчивый;
  • Масштабируемый;
  • Много лет уже используется на мировом рынке;
  • Доказал свою надежность делом во множестве тысяч организаций в мире.

Терминология

Чтобы к нему подступиться, нужно немного разобраться с терминологией. Я на ней сильно останавливаться не буду, потому что в документации все это есть.

  • Первое – это Exchange, точка обмена, то, куда мы публикуем сообщения.
  • Второй важный термин – это очередьQueue. В ней мы храним сообщения, пока они не доехали до клиента.
  • И третий важный термин – это Consumer, потребитель, тот, кто эти сообщения из очереди вычитывает.

Остальные термины, так или иначе, связаны с первыми тремя.

Основные схемы взаимодействия, которые можно построить с помощью RabbitMQ.

Прямой обмен

Самая простая схема – это прямой обмен.

  • Издатель публикует события;
  • Потребитель эти события забирает;
  • Если потребитель по каким-то причинам недоступен, посередине находится буфер, в котором эти сообщения хранятся до тех пор, пока он их не начнет оттуда «вычитывать».

До меня выступал Сергей Сорокин, который рассказывал про интеграцию с сайтом. Там говорилось, что когда на сайт что-то выгружается, посылается GET-запрос, чтобы получить ответ об успешной загрузке. Это тот самый «сосущий» интерфейс, так делать не надо. Мы предлагаем другой способ:

  • Отправили на сайт событие,
  • Сайт на это событие подписан, он его забрал.
  • Все, ничего больше делать не нужно. Если нам от сайта необходима обратная связь, он нам сам ответит, что все успешно загрузил – не надо его опрашивать.

Сбалансированная обработка

Второй паттерн – это сбалансированная обработка.

Если прикладной код, который обрабатывает события, довольно медленный и тяжелый, мы можем разбалансировать нагрузку по нескольким потребителям, чтобы уже сам сервер RabbitMQ распределял задания между теми потребителями, которые на эту очередь подписаны, и сам по мере их загруженности выбирал того, кому дать задание на эту обработку.

С помощью этого паттерна обеспечивается балансировка нагрузки в два клика мышки.

Издатель-подписчик

Еще один, наиболее распространенный паттерн – это «Издатель-подписчик». Он очень простой:

  • Система, публикующая сообщения, не знает, кому она их отправляет. Она просто «кидает» эти события «во вселенную». Сообщает: «Я провел документ» или «Товар оприходован».
  • А те системы, которым интересны события прихода товаров или изменения номенклатуры, на них подписываются.

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

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

Очень важный момент в сервере RabbitMQ – это то, что он поддерживает маршрутизацию сообщений.

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

На рисунке можно рассмотреть пример, когда у нас есть:

  • Система 1С, которая просто пишет сообщения в журнал регистрации – среди этих сообщений есть ошибки, предупреждения, информационные сообщения.
  • И есть у нас две смежные системы.
    • Первая – это мониторинг, который в случае ошибок зажигает красную лампочку. Мониторингу интересны только ошибки;
    • И вторая – это система хранения логов (чтобы через Elastic Search в них быстро искать). Система хранения логов подписана на все и просто складывает логи себе.

В первую очередь пойдут только ошибки, а во вторую – вообще все. Это можно организовать с помощью маршрутизации на «ключах».

RPC (вызовы процедур)

И последний паттерн – это тот самый RPC.

  • С помощью RabbitMQ, как правило, организуется асинхронный RPC, позволяющий «развязать» системы между собой.
  • Вызвали систему и не ждем, пока она ответит, потому что она в этот момент может не работать. Если мы будем ждать ответ, то мы тоже не будем работать. Вдруг она «сломалась», или у нее там регламентное обновление.
  • Меняем модель программирования: асинхронные вызовы позволяют не ждать ответа от системы, потому что система в этот момент может не работать.
    • Отправляем вызов в систему: «Система, сделай нечто». Например: «Сайт, загрузи товары». И сайт их событийно забирает из очереди.
    • Или системе посылается вызов: «Выполни такой-то код». Отправляем вызов, и он падает в очередь.
    • Или еще пример – резервирование товаров – бросили вызов о необходимости резервирования. Система-приемник подхватывает этот вызов, выполняет его, а мы уже пошли заниматься своими делами.
  • Ответ об успешном выполнении вызова система нам точно так же запускает по очереди, а мы его у себя забираем. Если вдруг у нас в этот момент что-то «сломалось», мы этот ответ забираем потом, когда свою систему починим. Делается это довольно просто:
    • В каждом вызове есть некий «ключ вызова» (номер этого вызова).
    • И когда вам приходит ответ, вы по номеру вызова можете определить, какой на него был ответ.

Интеграция на очередях

Есть замечательный сайт http://tryrabbitmq.com/.

На нем можно строить вот такие схемы (диаграммы взаимодействий) и «играться» с RabbitMQ, даже не устанавливая его себе.

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

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

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

А где же у него кнопка?

Так «где же у него кнопка»?

  • Yellow RabbitMQ – это пакет программ, пакет инструментов. Почему он называется «Желтый кролик»? Все просто. Потому что он позволяет связывать «желтые» программы с «кроличьими» очередями.
  • Этот набор инструментов работает на Windows и на Linux.
  • Он обеспечивает нативную, родную интеграцию 1С с сервером очередей по протоколу AMQP. Никаких HTTP-вызовов, никаких посредников, все на голом TCP, честные байты «гоняются» очень быстро. Записали справочник, через секунду он у вас уже на сайте. Никаких накладных расходов на HTTP-вызовы нет.
  • Этот набор инструментов содержит упрощенный API для быстрого старта, чтобы «поставить и запустить».
  • Производит все это компания SilverBulleters.

Состав пакета

  • Основой пакета является внешняя компонента 1С, которая реализует различные низкоуровневые операции с байтами. Эта компонента встроена в подсистему 1С (по типу БСП), которую вы можете внедрить в свою конфигурацию.
  • Подсистема Yellow RabbitMQ содержит в себе высокоуровневые абстракции для наиболее распространенных схем, о которых я говорил:
    • Подписчик-издатель;
    • Асинхронный сервис;
    • Прямой обмен и т.д.;
    • Реализованы даже более высокоуровневые абстракции, которые позволяют не сильно заботиться о детализации протокола AMQP.
  • При этом низкоуровневый доступ к протоколу AMQP остается открытым и если очень хочется, то можно еще и вживую AMQP «подергать» за методы.
  • Кроме того, в состав пакета входят скрипты для поднятия тестовой виртуальной среды. Если хочется попробовать, там есть Vagrantfile. Вы просто пишете vagrant up и получаете себе сразу сервер RabbitMQ, с которым сразу же можно «поиграться».
  • Также в состав пакета входят демо-конфигурации, которые позволяют посмотреть, как обеспечивается интеграция с базами 1С.

1 год – полет нормальный

Самому инструменту всего год. Разрабатывать мы его начали не так давно. Но за этот год он себя очень хорошо показал. Yellow RabbitMQ активно используется:

  • В общероссийском проекте, в одном из министерств.
  • В крупной федеральной оптовой сети автозапчастей.
  • В реализации тиражного решения БИТ:MDM.
  • И еще более 20 компаний, где это уже более года работает практически как часы, без нареканий.

Отправка сообщений

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

  • Основную нагрузку выполняют классы абстракций, сделанные в виде обработок. На слайде показаны фрагменты кода, как этими обработками пользоваться.
  • Например, если мы хотим просто отправить событие в мир, то наверху написаны три строки, как это сделать:
    • Мы создаем объект Публикатор;
    • Говорим ему: Публикатор.ОтправитьСообщение(ТелоСообщения);
    • И кладем тело сообщения в какую-то очередь.
  • Или наоборот, если вы хотите использовать отправку, основанную на механизме транзакций (если вдруг документ не провелся, то событие в очередь не класть), то для этого в подсистеме предусмотрен механизм отложенной транзакционной отправки (когда вы событие записываете не сразу в очередь, а сначала в справочник). В этом случае события из справочника будут отправлены «в мир» только если транзакция уже зафиксировалась.

Все эти механизмы в подсистеме уже из коробки есть.

Подписка на событие

Как делается подписка на событие?

  • Вы пишете прикладной обработчик, который будет обрабатывать ваше событие.
    • Например, вы написали код, который будет ставить товар на резерв – это какая-то процедура в общем модуле.
  • А дальше вы заходите в переопределяемый модуль нашей библиотеки и добавляете туда свой обработчик под конкретную очередь (указываете, что события из этой очереди будут обрабатываться вот этим методом).
  • Дальше у вас стартует регламентное задание, которое подписывается на очередь и получает оттуда сообщения.
  • При получении сообщения из очереди это регламентное задание вызывает нужный метод.

Таким образом, вы у себя в конфигурации организуете подписку на приходящие к вам события.

Асинхронный RPC

Асинхронный вызов RPC – как я уже говорил, это несколько другая модель программирования.

  • Поначалу довольно страшно оставаться без ответа от системы. Когда вы вызываете удаленную систему и не получаете ответ сразу, непонятно, получился вызов или нет. Поначалу действительно очень страшно, как же так программировать – я вызов-то отправил, а вдруг она не работает?
  • Системы часто ломаются, такое бывает, поэтому это нормально, что она не работает, не надо этого бояться. Да, не работает – когда включится, тогда и обработает, ничего страшного. Это такой небольшой психологический момент по пересмотру модели программирования.
  • По большому счету, если очень страшно, всегда можно сымитировать синхронный вызов и ждать, когда же система ответит. Но так делать все-таки не нужно, это – антипаттерн.

Как работает RPC на стороне сервиса?

Давайте рассмотрим гипотетический сервис, который отправляет SMS, получая на вход номер телефона абонента и текст сообщения. Как наладить работу такого сервиса в рамках подсистемы YRMQ?

  • Во-первых, на стороне сервиса вы точно так же пишете прикладной обработчик, который как-то отправляет SMS. Это ваш прикладной код, который пишет ваш программист.
  • А в переопределяемом модуле подсистемы YRMQ добавляете обработчик вызова (ДобавитьОбработчикВызова()), где указываете, что:
    • при вызове вот этого асинхронного сервиса должен быть запущен вот этот код.
  • И подсистема будет это делать.

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

RPC на стороне клиента

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

  • Мы точно так же мы подготавливаем параметры вызова – номер телефона абонента и текст сообщения.
  • Создаем объект асинхронного сервиса через подсистему – Сервис.Вызвать().
  • Больше делать ничего не надо. Дальше мы идем заниматься своими делами.
  • И потом у вас стартует фоновое задание, в котором вы ждете ответ от сервиса SMS, если он вам нужен.

Предположим, вы хотите отправлять SMS в момент проведения заказа.

  • Если вы используете синхронный сервис SMS и он не работает, то заказы вы принимать не сможете, и у вас случится простой.
  • А при использовании асинхронного сервиса отправки SMS все будет работать.

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

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

В этом весь смысл – развязать системы между собой.

Низкоуровневые методы

Как я уже говорил, в компоненте есть низкоуровневые методы. Если вам недостаточно высокоуровневых абстракций, вы можете построить свои собственные паттерны, используя AMQP в чистом виде.

Дайте две!

 

Где взять этот замечательный продукт?

  • Взять его можно на infostart.ru.
  • Под каждого клиента формируется отдельная персональная именная сборка.
  • Сюда же входят консультации и техническая поддержка по определенным условиям, которые можно уточнить уже у производителя/
  • И понятное дело, что мы не одобряем утечки этого инструмента.

Памятка интегратора

Итак, чтобы распутать свою интеграцию, нужно сделать чек-лист.

  • Обязательно нужно назвать свои потоки данных четкими, понятными именами, чтобы в разговоре с коллегами все понимали, что говорят об одном и том же.
  • Каждый поток данных атрибутировать и задокументировать эти атрибуты.
  • Зафиксировать интерфейсы, построить диаграммы обмена.
  • Внедрить в 1С подсистему Yellow RMQ.
  • И… наслаждаться жизнью!

Планы по развитию

  • В первую очередь мы планируем развивать 1С-ную часть.
  • Планируем поддержать сервер очередей Apache Kafka, который немного другой, чем RabbitMQ, но тоже хороший.
  • Хотим поддержать современный протокол AMQP 1.0, который пока еще находится в черновиках, но скоро будет опубликован. Там много разных «плюшек», которые мы тоже хотим поддерживать.
  • И потом хотим поддержать deepstream.io – это немного не про очереди, это про быструю интеграцию.

 

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

Данная статья написана по итогам доклада (ВИДЕО), прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

Приглашаем вас на новую конференцию INFOSTART EVENT 2018 Education.

116

См. также

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

Комментарии
Избранное Подписка Сортировка: Древо
1. Новиков 290 28.05.18 10:36 Сейчас в теме
Wow! Спасибо Вам за офигенную статью! Как раз в тему интереса.

Если позволите, пару вопросов:
1. Вроде на хакатоне, который прошел, как говорят, какой-то чувак делал доклад о том, что он нашел программулину, которая сама уведомляет приемник о том, что в очереди для него есть сообщение? Можно как-то эту тему раскрыть, и вообще - насколько это с вашей точки зрения правильно и что за программка (если не секрет, конечно)?
2.Сервер очередей Apache Kafka как-то связан Apache ServiceMix? Вы что-нибудь слыхали про ServiceMix? И на данный момент в какой стадии поддержка Apache Kafka?
3. Скажите, а как используются в таких схемах обмена - планы обмены 1С? Есть ли какие-то решения, которые позволяют от них отказаться?
2. Evil Beaver 5370 28.05.18 10:49 Сейчас в теме
1. По первому пункту - не совсем понял. На хакатоне был, но "программулину которая уведомляет приемник" не помню. По идее - такая прогроаммулина не нужна, сервер очередей сам и уведомляет приемник. Поясните вопрос?

2. Насколько я понимаю, ServiceMix не связан с Kafka. Поддержка Apache Kafka сейчас в разработке. Какая-то демо или бета-версия, возможно, будет в августе.

3. Здесь простор для творчества. Можно формировать сообщения онлайн, можно использовать планы обмена для формирования выгрузки, а очереди - только в качестве транспорта. Вопрос бизнес-целей, требований и имеющихся реалий. Отказаться от Планов в пользу очередей можно. А можно и наоборот - сделать решение в виде симбиоза. Мы на своих проектах Планы не используем, возможно, кто-то делает такие решения, но мне неизвестно.
3. Новиков 290 28.05.18 11:30 Сейчас в теме
Андрей, спасибо за оперативный ответ!

1. Сам вопрос, я задавал разработчику похожего на Ваш адаптер из Бита, тут. Я процитирую:
Есть два узла на 1С. В данный момент есть обмен, который происходит по расписанию. В качестве формата обмена используются правила КД 2. Планы обмена не подключены, и не хочется их подключать. Хочется перейти от такой модели, к событие-ориентированной - отдать сообщение брокеру/адаптеру, тот сам дернул бы хттп-сервис приемника и отдал что нужно. Это в общем виде.


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


по п.2 - ясно.

Отказаться от Планов в пользу очередей можно. А можно и наоборот - сделать решение в виде симбиоза. Мы на своих проектах Планы не используем, возможно, кто-то делает такие решения, но мне неизвестно

Слушайте, а на эту тему у вас какие-то методические материалы/курсы или что есть? Как бы "бест-практикс" ваши заюзать, как говорил классик "по методичке" ;)
5. Evil Beaver 5370 28.05.18 15:22 Сейчас в теме
(3) лучше написать на наш b2b@silverbulleters.org и рассказать - что именно хочется изучить. Коробочного курса "оплатить и прослушать", насколько я знаю нет, но я могу ошибаться.
4. genayo 28.05.18 12:28 Сейчас в теме
Если все интегрируемые системы внутренние, то все понятно. А если нужна интеграция с внешними системами, которыми мы не управляем, из которых получаем данные во множестве форматов и множеством способов, нужна шина данных? Что у вас используется в качестве шины?
6. Evil Beaver 5370 28.05.18 15:26 Сейчас в теме
(4) опять же, зависит от требований. Если все форматы способен принимать один и тот же приемник - логику приемки можно реализовать и прямо в нем. Шина данных - это слишком общее понятие. В частности, вы спрашиваете про "трансформер" - это всего лишь один из компонентов шины. Сервер очередей - это другой ее компонент. В каждом конкретном предприятии может быть (или не быть) какого-то компонента и шины тоже может не быть, а бизнес-задача - все равно выполняться.

У нас в качестве "шины" либо не используется ничего, либо используется та шина, которая уже есть у заказчика, либо подбирается какая-то другая под его требования - вариантов слишком много, чтобы вот прямо так сказать "мы используем вот это". Мы используем то, что целесообразно в конкретном проекте.
7. genayo 28.05.18 15:41 Сейчас в теме
(6) Хорошо, хотя бы расскажите, что использовали. Есть, например, Axelot Datareon ESB, есть реализации протокола AS2 для EDI...
И еще, есть ли смысл использовать Кролика, если, условно, нас устраивает появление данных не онлайн, а с задержкой 5-10 минут?
8. Evil Beaver 5370 28.05.18 18:02 Сейчас в теме
(7) Мне сложно ответить на вопрос "имеет ли смысл использовать кролика". Если у вас нет проблем с взаимозависимостью систем, когда простой одной системы влияет на другие, если вам некритично запаздывание информации - тут и файловый обмен сгодится. Вопрос "имеет ли смысл использовать" актуален только в связке с бизнес-требованиями...
9. azhilichev 29.05.18 05:48 Сейчас в теме
Андрей, здравствуйте. Насколько производительным должно быть оборудование, на котором развернут сервер очередей, чтобы можно было обрабатывать 300-500 тыс. сообщений в сутки?
10. kuzyara 529 29.05.18 12:57 Сейчас в теме
(9)
ТелоСообщения = "{
	|   ""isDeleted"":false,
	|   ""amountpayment"":3462,
	|   ""amountshipping"":0,
	|   ""deliveryAddress"":"""",
	|   ""orderID"":"""",
	|   ""items"":[
	|
	|   ],
	|   ""UIDDocument"":""f9f27768-5437-11e8-ae4b-00505699b663"",
	|   ""TypeDocument"":""Оплата наличными"",
	|   ""Number"":""ОТ00007588"",
	|   ""Date"":1525971210000,
	|   ""PerfomanceDocument"":""Приходный кассовый ордер ОТ00007588 от 10.05.2018 16:53:30"",
	|   ""UIDContractor"":""e4782045-c5db-11e6-bd59-005056997d23"",
	|   ""NameContractor"":""ЧАСТНОЕ ЛИЦО"",
	|   ""NameOrganization"":""ООО Ромашка (Иркутск)"",
	|   ""isSelling"":false,
	|   ""UIDContractor2"":"""",
	|   ""NameContractor2"":"""",
	|   ""DateShipment"":null
	|}";

д1 = ТекущаяУниверсальнаяДатаВМиллисекундах();

Для Сч = 1 По 1000 Цикл	
	ПакетСообщений = Справочники.ИсходящиеСообщения.СоздатьЭлемент();
	ПакетСообщений.ТочкаПубликации   = "api.gazprom.ut10";
	ПакетСообщений.КлючМаршрутизации = "settlement.document";
	ПакетСообщений.ДатаВремяСобытия  = '00010101';
	ПакетСообщений.Таймштамп         = СобытияСлужебный.ТекущееЮниксВремяВМилисекундах();

	НовоеСообщение 			 = ПакетСообщений.Сообщения.Добавить();
	НовоеСообщение.Сообщение = Справочники.ИсходящиеСообщения.ДобавитьЗаголокВСообщение(ПакетСообщений, ТелоСообщения);
	
	ПакетСообщений.Записать();
КонецЦикла;

д2 = ТекущаяУниверсальнаяДатаВМиллисекундах();

ОтправкаСообщений.ПоФИФОИзОчередиИсходящих();

д3 = ТекущаяУниверсальнаяДатаВМиллисекундах();

Издатель = ОчередьСообщений.НовыйАдресныйИздатель("api.gazprom.ut10");	
Для Сч = 1 по 1000 Цикл
	Издатель.ОтправитьСообщение(ТелоСообщения, "settlement.document");
КонецЦикла;	

д4 = ТекущаяУниверсальнаяДатаВМиллисекундах();

Рез1 = (д2-д1)/1000;
Рез2 = (д3-д2)/1000;
Рез3 = (д4-д3)/1000;

Сообщить("Формирование сообщений, шт/сек: " + Цел(1000 / Рез1));
Сообщить("Отправка сообщений с квитанцией об отправке, шт/сек: " + Цел(1000 / Рез2));
Сообщить("Проливка сообщений без квитанции об отправке, шт/сек: " + Цел(1000 / Рез3));
Показать

Формирование сообщений, шт/сек: 20
Отправка сообщений с квитанцией об отправке, шт/сек: 26
Проливка сообщений без квитанции об отправке, шт/сек: 511
20. lustin 998 25.08.18 14:47 Сейчас в теме
(10) это слишком низкие цифры

Формирование сообщений, шт/сек: 20
Отправка сообщений с квитанцией об отправке, шт/сек: 26
Проливка сообщений без квитанции об отправке, шт/сек: 51


Сервер rabbitMQ находится "далеко" по сети между файерволами и NAT. У вас кто-то режет пропускную способность, и скорее всего это инфраструктурщики и безопасники. Учитывая что я вижу название API я даю 99% вероятность что это именно они.
11. kuzyara 529 29.05.18 13:07 Сейчас в теме
Из недостатков кролика:
- Отсутствие монитора обмена данными (т.е. нельзя зайти и посмотреть состояние всех обменов как в типовых)
- В отличии от 1С:Конвертация данных 2.0 интерактивная настройка правил конвертации не предусмотрена, только программная конвертация (никаких ПКО, ПКС, ПВД и т.п. - все писать в коде ручками для каждого объекта, каждого реквизита!)

Немного документации от битовцев: БИТ:Адаптер - простая подсистема обмена данными для 1С на платформе RabbitMQ
12. karimov_m 30.05.18 15:29 Сейчас в теме
(11) почему нет монитора?
Management plugin

The rabbitmq-management plugin provides an HTTP-based API for management and monitoring of your RabbitMQ server, along with a browser-based UI and a command line tool
15. kuzyara 529 01.06.18 05:51 Сейчас в теме
(12) Всё равно приходится вручную вести список какая очередь какой базе соответствует и за какое событие отвечает.
16. karimov_m 02.06.18 16:51 Сейчас в теме
(15) а вы как хотели? завести "кролика" в огород и чтоб он сам понял, где морковки лежат, откуда брать и кому нести?)
Процесс настройки Интеграции, как бы, подразумевает первоначальную настройку потоков, очереjav * ascript:void(0);дей и тп. Уже после этого, можно включить рубильник и все закрутиться.
17. kuzyara 529 04.06.18 13:54 Сейчас в теме
(16) кстати, вам удавалось преодолеть порог в 1000 сообщений/сек при разнесённых кролике и эске или это ограничение компоненты?
18. karimov_m 20.06.18 19:39 Сейчас в теме
(17) мы не используем у себя Кролика) Так сложилась исторически.
О какой компоненте вы говорите?

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

К тому же на одним кроликом жив подход, есть Кафка и ВэбСфер и тп
21. lustin 998 25.08.18 14:49 Сейчас в теме
(17) показатели порога составляют в среднем 22.000 собщений в секунду Если бы втихую не тестировали, а обратились по штатным каналам поддержки - вам бы объяснили как это сделать.
23. kuzyara 529 27.08.18 05:28 Сейчас в теме
Я не тот человек, которому нужна техподдержка. Самостоятельно пытаюсь изучать документацию.
24. lustin 998 30.08.18 20:44 Сейчас в теме
(23) Ах вы значит НЕ тот человек... Я повторюсь - не вводите людей в заблуждение: вы НЕлегально используете старую версию подсистемы, хуже того НЕпрофессионально её тестируете, и самое главное допускаете публичные заявления о результатах ваших НЕкомпетентных тестах.

И теперь вам дескать не нужна тех поддержка.... Ну хорошо.... Я эскалирую ваше поведение до вашего заказчика - пусть он с вами разбирается.
Irwin; kuzyara; +2 Ответить
22. lustin 998 25.08.18 14:51 Сейчас в теме
(11) монитор и трассировка собщений - это штатная функциональность серверов RabbitMQ, не вводите людей в заблуждение. За конвертацию данных отвечает сервис трансформации, который поддерживает разных алгоритмы трансформайции, в том числе по правилам обмена.
19. blackhole321 810 06.07.18 19:40 Сейчас в теме
Андрей, проясни пожалуйста ситуацию с прямым обменом. У тебя написано, что сайту отправляется get запрос. Я так понимаю с параметрами обновлений (допустим это post запрос и в теле содержатся изменения) и собственно мы получаем код ответа 200, если данные успешно обновлены и что-то другое в противном случае. Чем эта схема плоха и почему так делать не надо?
Оставьте свое сообщение