Во второй части статьи я продолжаю начатую ранее тему про работу с 1С:Шиной и про свое видение построения эффективной системы по обмену данными в развитой информационной инфраструктуре.
Здесь можно ознакомиться с остальными частями статьи:
А вот и Шина подъехала! Часть 1
А вот и Шина подъехала! Часть 3. Итоги
Для начала продолжу описание некоторых неочевидных практических моментов, с которыми вам, возможно, придется столкнуться при работе с Шиной.
Практические моменты
"Гарантированная недоставка" сообщений
Одним из основных преимуществ 1С:Шины я считаю ее поддержку принципа "гарантированной доставки" сообщений, декларируемый разработчиками продукта.
В справке говорится об этом следующее: "Сообщение хранится в приложении «1С:Шины» до тех пор, пока «1С:Шина» не получит подтверждение о том, что получатель это сообщение принял".
И приводится следующая схема (без моих красных вставок, разумеется), отображающая обмен данными двух конфигураций 1С через Шину с демонстрацией жизненного цикла сообщения в разных системах (отправитель-Шина-получатель):
Принцип гарантированной доставки в случае использования баз 1С в качестве отправителя и/или получателя распространяется и на них.
Сообщение, не отправленное из базы-отправителя по причине, например, недоступности Шины, будет хранится в канале отправления базы 1С и стучаться в Шину каждый раз при инициализации фонового задания отправки сообщений.
К слову, в 1С инициализирует фоновые задания отправки/получения сообщений вызов метода СервисыИнтеграции.ВыполнитьОбработку(), который рекомендуется вызывать регламентным заданием каждые две минуты.
И надо иметь в виду, что этот рекомендованный 1С интервал не означает, что задержка получения данных после их отправки будет в максимуме составлять те же две или даже четыре минуты.
Используемые внутренние механизмы каналов в конфигурации и шине позволяют сообщению при таком интервале попадать к получателю, обычно, практически сразу.
Проблемы с сообщением могут начаться на стороне получателя. То есть, когда Шина на самом деле свою работу уже сделала.
До этого проблемы, конечно же, тоже могут возникнуть: недоступность Шины или программные проблемы маршрутизации или обработки данных внутри нее. Но тут все достаточно очевидно и есть определенные механизмы мониторинга и отладки в Шине, чтобы это исправить.
Несомненно, и в 1С тоже есть механизмы выявления проблем в каналах сервиса интеграции. Если из одной системы вы благополучно отправили абсолютно невинное сообщение типа "Hello, World!", через Шину оно также прошло, увеличив счетчики сообщений на каналах входа/выхода процесса интеграции, а в системе-получателе 1С его получить не можете, то самое время заглянуть в канал получения системы.
То есть, определить количество сообщений в канале получения (<СервисИнтеграции>.<КаналСервисаИнтеграции>.ВыбратьСообщения().Количество()).
Наверняка вы получите ненулевое число. Причем ваше безобидное "Hello, World!" тут будет, скорее всего, ни при чем.
Дело в том, что, по всей видимости, обработка получения сообщений в канале организована в порядке их поступления в канал. Первый пришел - первым и обработали. Это, несомненно, логично. По другому можно получить коллизию: неактуальными данными "зетереть" более поздние актуальные.
В самой же обработке получения сообщения (а обрабатываются они в коде 1С по одному за раз) можно оперировать параметром Отказ.
Если его установить в значение Истина, то сообщение не просто не будет "обработано" и потеряно, а будет повторно стучаться к вам до тех пор, пока не будет обработано так, чтобы параметр Отказ имел значение Ложь.
Причем, все остальные сообщения, полученные позже "сбойного", будут терпеливо ждать своей очереди. Попыток их обработать система делать не будет пока вы не разберетесь со сбойным.
Ваше "Hello, World!" скорее всего будет где-то среди них, а сообщение-"виновника" вы отправили раньше него, и, возможно, даже совсем из другой системы.
Таким образом, можно спровоцировать "гарантированную недоставку" сообщений, как непосредственно "сбойного", так и всех следующих за ним. Сколько их скопится в канале базы 1С (тут еще интересно - а какова его емкость?) - вопрос скорости реакции на ситуацию. Причем вашей реакции. Ну, или кого-то еще из ответственных за обмен данными...
Абсолютно такой же эффект вы получите при необработанном исключении, возникшем при обработке получения сообщения: очередь сообщений окажется заблокированной.
Как поведет себя система, если обработка получения проводится вне транзакции, я сказать не могу, такого эксперимента не ставил. Подозреваю, что аналогично.
В любом случае, эта настройка - использование транзакции - находится на уровне канала сервиса интеграции в конфигурации, управлять динамически ей нельзя. Но, если нужно, можно сделать пару каналов получения и передавать то что подлежит транзакционной обработке через один, а что не подлежит - через второй.
Но я отвлекся...
В начале моих экспериментов с Шиной мне пришлось осознать и принять такой подход.
Он тоже является частью реализации постулата "гарантированной доставки": ни одно сообщение не должно быть не просто не потеряно, но еще и обрабатываться сообщения должны в строгой последовательности!
Если вы пишете безупречно-безошибочный код, всегда предусматривающий все возможные ситуации и коллизии, то следующие пару абзацев вам не понадобятся.
Как решать такую проблему "гарантированной недоставки"? Да, в общем-то, тривиально: обрабатывать ошибки при обработке сообщений и не устанавливать параметр Отказ в значение Истина.
Но тут важно решить вопрос: нужно ли разрешать при наличии ошибок загрузку следующих сообщений или нет. В случае, если вы не разрешаете загрузку, оставляя "сбойное" сообщение вместе со всеми следующими за ним в канале получения, то кто-то должен достаточно оперативно отреагировать на такую ситуацию. Поскольку загрузка через канал будет остановлена.
Эта оперативность, в свою очередь, может зависеть от критичности всего комплекса передаваемых через этот канал в систему данных.
Можно ранжировать критичность и самого "сбойного" сообщения, опираясь на его параметры, несущие информацию о характере данных сообщения.
Можно ранжировать по характеру возникающей ошибки, локализовав место ее возникновения.
А можно даже создать несколько каналов получения, направляя разной критичности данные через разные каналы, чтобы самые важные данные меньше зависели от остальных.
При этом, можно сохранять информацию об ошибке в какой-нибудь справочник или регистр сведений. Сообщение всегда имеет свой уникальный идентификатор для поиска его в канале или идентификации при сохранении в справочнике. Можно сохранить и тело, и параметры сообщения.
Сохраненной о сообщении и об ошибке, которую оно спровоцировало, информацией можно оперировать при принятии решения об удалении сообщения из канала для освобождения пути остальным сообщениям. С ее помощью можно, после исправления проблемы в программном коде, провести повторную загрузку в базу данных этого сообщения.
Поле для фантазии как именно решить эту проблему широкое.
Но результат должен быть один: обеспечение целостности и актуальности данных в связанных системах!
Общая группа информационных систем в проекте Шины
В элементе "Процесс интеграции" проекта 1С:Шины можно разместить блоки типа "Группа участников":
В приложении 1С:Шины эти группы участников объединяют информационные системы, описанные в системном справочнике Шины Инфосистемы.
Большое количество групп участников затрудняет, на мой взгляд, управление приложением Шины. Нужно очень хорошо разбираться в этом приложении, да еще банально не ошибиться, добавляя Инфосистему в какую-то группу.
А еще, каждая Инфосистема может входить в несколько групп одновременно, что тоже не добавляет простоты в процесс.
На одном из вебинаров, посвященных Шине, демонстрировался внедренный и реально работающий проект по интеграции достаточно большого количества систем одного из крупных ВУЗов страны. Так там я наблюдал отдельную группу участников для каждой информационной системы проекта.
В таком варианте ошибиться, наверное, сложнее, но сам проект, опять же, на мой вкус, выглядел ну совсем нечитаемым и плохо масштабируемым - огромный "паук". Хотя говорилось о том, что после внедрения Шины затраты на управление интеграциями снизились многократно. Видимо, до этого, было совсем все "не очень"...
В любом случае, мне эстетически всегда приятнее минимизировать количество элементов в проекте. Причем в любом - про Шину ли это, про схему ли бизнес-процесса или про что-либо еще.
Шина вполне позволяет это сделать. Как говорилось в первой части статьи, управлять адресацией сообщений можно через свойство сообщения КодПолучателя, в котором можно перечислить коды всех Инфоосистем, которые должны получить сообщение.
Сообщение, "долетев" в процессе интеграции до блока группы участников, будет доставлено только тем Инфосистемам, чьи коды присутствуют в этом свойстве. Остальные будут проигнорированы.
При этом, вполне допустимо использовать на весь проект вообще единственную группу участников, в которую будут входить все отправители и получатели сообщений. Просто каналов входа/выхода к этой группе будет присоединяться несколько. Например, вполне допустим такой вариант:
На рисунке в процессе интеграции присутствует единственная группа участников, которая в данном случае может содержать базы 1С и системы, работающие с Кроликом (RabbitMQ). Пара каналов Получение1С и Отправка1С отвечает за базы 1С, ПолучениеRMQ и ОтправкаRMQ - за системы с Кроликом.
Адресация сообщений с помощью свойства сообщения КодПолучателя решает вопросы корректной доставки. Но, при этом, важно понимать, что система-отправитель должна четко знать в какие системы идет сообщение, чтобы это свойство инициализировать.
Либо этим должна заниматься Шина, неважно. Важно, что где-то и как-то (в общей системе, управляющей интеграцией) должна содержаться информация о том кому должны адресоваться те или иные данные, передаваемые из тех или иных систем. И эта информация должна быть доступна и использоваться при формировании и/или передаче сообщения.
Есть еще момент подключения базы, добавленной в группу УчастникиОбмена (см. рисунок) к "нужным" каналам отправки/получения.
Для Кролика, например, параметров подключения чуть больше чем много.
Проще всего осуществить подключение с помощью реквизитов, добавленных в справочник Инфосистем в проекте Шины.
Как добавить справочник и его реквизиты в проект показано в первой части статьи под спойлером "Описание доработки проекта 1С:Шины для реализации синхронного обмена".
А вот такие реквизиты нужно добавить для работы с Кроликом:
Естественно, назвать вы можете их произвольно. Типы у всех, кроме числового PortRMQ, строковые, необходимой вам длины.
Инициализироваться реквизиты требуемыми значениями уже должны в работающем приложении Шины при добавлении новой Инфосистемы. Можно отредактировать их и после добавления. Естественно, только для тех систем, которые должны работать с Шиной через Кролика. Для остальных Инфосистем их инициализировать не нужно.
А вот трансляция этих параметров подключения к Кролику из Инфосистемы в каналы ПолучениеRMQ и ОтправкаRMQ осуществляется через свойства соответствующих блоков в схеме процесса интеграции следующим образом:
Это один из вариантов. Можно еще использовать прямо совсем динамическое определение параметров подключения из функций в программных модулях проекта Шины.
Схожим образом (через реквизиты Инфосистем и свойства блоков-каналов) можно осуществлять подключение и к другим типам источников/получателей, доступным на текущий момент: Ftp, Jms, ОчередьШины, Файл.
Все это, по сути, свободное изложение справочной информации, но без нее дальше не двинемся. А может, кому-то и полезно/интересно будет)...
Подключение к блокам-каналам по реквизитам Инфосистем, когда группа участников с некоторым количеством "разнотипных" систем подключена сразу к нескольким "разнотипным" блокам-каналам, имеет пару неприятных, но не смертельных моментов.
Один из них - при старте приложения Шины каждый блок-канал пробует подключить каждую Инфосистему из группы участников, с которой он связан. Так как он ожидает увидеть заполненными требуемые ему параметры подключения, а в некоторых инфосистемах они будут не заполнены, поскольку они относятся к другому типу подключения, то подключения не произойдет.
О чем в журнале событий Шины появится две соответствующих записи на каждую неподключенную к коннектору Инфоистему - об остановке отправки в Инфосистему и об остановке получения из Инфосистемы:
В несовершенном интерфейсе шины выглядит это именно так. Но при наведении на строку события можно увидеть текст полностью:
Ошибка при выполнении процесса Основной::ПроцессИнтеграции в узле ОтправкаRMQ: Остановлено получение сообщений от участника "ШинаТест2" в узле "ОтправкаRMQ" из-за ошибки вычисления выражения в свойстве "Хост" узла. Проверьте значения реквизитов данного участника.
Пока мои исследования не привели к обнаружению каких-либо проблем в функционировании такого построения процесса интеграции, кроме, разумеется, этих сообщений в журнале операций.
Надеюсь, не приведут и в дальнейшем. Поскольку подобная структура проекта представляется мне более "правильной" с точки зрения как сопровождения проекта, так и управления интеграциями в целом.
Но я упомянул про "пару" неприятных моментов.
Второй момент уже менее безобидный и касается маршрутизации сообщений в проекте.
Отправленное сообщение одной или нескольким системам должно быть получено только теми блоками-каналами получения, Инфосистемам которых оно предназначено. Иначе сообщение "зависнет" в канале Шины, так и не подключившемся ко всем Инфосистемам в группе участников.
К счастью, этот момент решается довольно несложно с помощью, как я это назвал, "неявной маршрутизации сообщений". Но рассмотрю я его решение уже в третьей части статьи, поскольку вторая уже на текущий момент получается достаточно объемной.
А нужно еще поговорить об эмпиреях, то есть, о построении концепции эффективного использования 1С:Шины.
Концепция эффективного использования 1С:Шины. Первые шаги
Здесь и сейчас мы подведем только промежуточные итоги по материалам этой и предыдущей статьи. Завершить построение концепции попробуем в следующей, надеюсь, последней статье цикла.
Что же на текущий момент нам известно?
При построении нашей информационной инфраструктуры мы можем связать проектом 1С:Шины определенное количество типов информационных систем. Только те, для которых можем в процессе интеграции проекта "прикрутить" готовые блоки-каналы (или коннекторы).
Наличие среди них, например, коннектора для Кролика (RabbiMQ) очень существенно расширяет перечень подобных систем.
Если среди ваших систем нет такой, которая является абсолютно обязательной для участия в общей системе обмена данными, и которая при этом не может подключиться ни к к одному из коннекторов 1С:Шины (давайте обмен с помощью файлов все-таки не рассматривать), то это уже можно рассматривать как показание к ее (Шины) использованию.
Далее. Самый "родной" коннектор в Шине обеспечивает соединение с базами 1С (а также с системами, имеющими возможность обмениваться информацией по протоколу AMQP).
При этом, реализация каналов сервисов интеграции в платформе 1С, также как и Шина, обеспечивает принцип "гарантированной доставки" сообщений.
Поэтому, если в вашей информационной инфраструктуре находятся преимущественно базы 1С (или вообще, только они и есть), то это тоже можно рассматривать как еще один плюс в сторону использования 1С:Шины.
Стоп! Вот здесь есть еще и проблема!
Предположим, базы 1С, да, есть. И их сразу несколько. И характер передаваемой между ними информации носит очень разнородный характер. И самих структур "тип данных-отправитель-получатель" получается очень много.
Выходит, в каждой отдельной базе придется прописывать систему, реализующую формирование и отправку "специфичных" для системы данных через Шину или прием и обработку получаемых и таких же специфичных данных?
Сейчас, обычно, обмен так и выглядит: зарегистрированные в планах обмена, специфичных для каждой конфигурации, данные выгружаются в файлы или "напрямую" передаются в системы-получатели. От формата данных зависит как их будет загружать система-получатель.
То есть, помянутые структуры "тип данных-отправитель-получатель" живут практически сами по себе. Вернее в каждой паре отправитель-получатель. При необходимости корректировки нужно "ковырять" и отправителя, и систему формирования сообщений (КД2, например), и, зачастую, получателя.
Основной момент в том, что общей картины всех интеграций нигде нет, она фрагментирована по отдельным системам. Описывать и актуализировать описание, как я говорил уже в первой части статьи, достаточно сложно. Для интеграторов это настоящая головная боль.
Значит, нужна единая система, которая агрегировала бы в себе всю информацию по всем используемым Инфосистемам. Описывала бы все возможные интеграции между ними (те самые структуры "тип данных-отправитель-получатель").
Крайне желательно, чтобы не просто описывала, а являлась "настраивающей" интеграции системой. То есть, изменение в описании тут же приводило бы к изменениям в процессах обмена.
А значит, описание должно содержать информацию и о форматах обмена (о правилах конвертации КД2 или версии формата EnterpriseData, например).
А раз "тут же приводило бы к изменениям в процессах обмена", то и передача "настроечных" данных из системы управления интеграциями (назовем ее СУИ), тоже должна осуществляться быстро и качественно в "заинтересованные" системы.
Вот это, как раз, 1С:Шина вполне может обеспечить. Просто форматы для сообщений обмена данными и "настроечных" сообщений могут несколько отличаться.
СУИ, в идеале, должна управлять процессами регистрации изменений, выгрузки, передачи и загрузки данных. А еще неплохо бы добавить в нее передачу произвольных наборов данных по запросу. Ну, и управление синхронными обменами тоже, если в первой части статьи я не смог уговорить вас от них отказаться...
Еще она должна обязательно предотвращать "несанкционированный обмен" (см. также первую часть статьи) и обеспечивать единый формат информационных сообщений.
Она может выступать отдельной системой, также включенной в общий процесс интеграции через проект 1С:Шины, передавая свои данные всем вовлеченным в этот процесс системам. Может и не выступать, но об этом в третьей части).
Но от идеи использовать для организации такой системы сам проект Шины я отказался - на момент принятия решения там даже еще Регистров сведений не добавили. Да и интерфейс приложения Шины для подобной затеи - так себе решение...
Да, сама по себе 1С:Шина всего этого, как кому бы ни хотелось, не обеспечивает. Да, чтобы написать нечто подобное нужно потратить N-ое количество ресурсов.
Но, если ваша информационная инфраструктура начинает давить на вас проблемами с интеграцией, если вам приходится часто перенастраивать ваши рабочие и тестовые контуры, если вы начинаете организовывать обмен заново там, где он уже есть и нужно только чуть подправить - вам придется этим заняться...однозначно)...
Окончание не за горами!..
В заключительной третьей части статьи я постараюсь завершить формирование "крупными мазками" концепции системы управления интеграциями (СУИ), основанной на том небольшом пока опыте, что я приобрел, работая с 1С:Шиной. Ну, и нас ждет еще пара практических моментов работы с Шиной и с системой 1С, которая должна быть связана с Шиной в рамках реализации этой концепции.
