Перейти к основному содержимому

Группы участников

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

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

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

Для того чтобы учитывать информационные системы, с которыми взаимодействует «1С:Шина», существует системный справочник Инфосистемы.

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

Значения этих реквизитов вы можете использовать при заполнении свойств узлов. Например, есть информационные системы, к которым нужно обращаться по протоколу HTTP по некоторым адресам — URL. Вы можете добавить в справочник Инфосистемы реквизит URI и этот реквизит URI задать в качестве свойства узла HTTP, чтобы процесс интеграции обращался к информационным системам по протоколу HTTP. Затем в справочнике Инфосистемы вы можете создать информационные системы и для каждой из них определить собственный URI.

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

Группа участников

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

В случае, когда узел-назначение связан с группой участников, сообщению можно установить заголовок RecipientCode. Его можно установить двумя способами:

  • на стороне системы-отправителя;
  • в трансляторе с помощью метода ИмяПроцессаИнтеграции.Сообщение.УстановитьКодыПолучателей(Значение: ЧитаемыйМассив<Строка>).

Значение заголовка должно соответствовать коду участника из группы, связанной с узлом-назначением. По указанному коду будет выполняться маршрутизация сообщения соответствующему участнику процесса без использования узла-маршрутизатора. Для передачи сообщения нескольким участникам в заголовке RecipientCode можно перечислить коды получателей через запятую «,». Получить значение заголовка RecipientCode из встроенного языка можно с помощью свойства Получатели типа ИмяПроцессаИнтеграции.Сообщение.

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

Пример 1​

Есть следующий процесс интеграции: периодически, по таймеру, выполняется HTTP-запрос на сайты поставщиков. Полученные ответы обрабатываются и отправляются в приложения «1С:Предприятия».

Пример 1. Схема процесса интеграции

Чтобы существовала возможность задать адрес каждого поставщика, в справочник Инфосистемы добавлен реквизит URI. Этот реквизит используется в свойстве URI узла СайтПоставщика.

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

Поставщики и информационные базы в процессе интеграции

Поставщикам вы задаете значения их реквизитов URI и включаете эти системы в группу Поставщики. Другие две информационные системы включаете в группу Инфобазы.

В результате «1С:Шина» преобразует эту схему следующим образом:

Преобразованная схема процесса интеграции

Для каждого из участников-поставщиков создается собственный узел HTTP с URI соответствующего участника. Сообщения от таймера доставляются к каждый из этих узлов независимо и обрабатываются каждым узлом независимо. Затем независимо отправляются в узел Обработка. После этого результаты отправляются независимо в приложение Торговля и в приложение Бухгалтерия через узлы-получатели.

Пример 2​

Есть следующий процесс интеграции: мы выполняем HTTP-запросы к сайтам, которые содержат котировки, получаем у них содержимое, отправляем это содержимое без изменения внутрь системы «1С:Предприятие» (ДляПолучателей). А для контроля пишем протокол, чем закончилось обращение к каждому сайту (Протокол).

Пример 2. Схема процесса интеграции

Так как узел HTTP связан с группой участников, то свойства этого узла могут задаваться не жесткими константами, но и формироваться с использованием свойств участников. В данном случае свойство URI выглядит так:

%{Участник.Uri}

Таймер периодически порождает сообщение. Оно попадает в узлы HTTP. Этих узлов столько, сколько информационных систем в группе Сайты. Для каждого из этих узлов свойство URI формируется с использованием реквизита URI справочника Инфосистемы.

После узла HTTP сообщения попадают в МаршрутизаторПоСодержимому. Там происходит разделение потоков. Одна копия сообщения всегда направляется в узел ФормированиеЗаписиПротокола, а другая, если HTTP-запрос выполнен успешно, отправляется в узел ДляПолучателей.

метод МаршрутОтветаСайта(Контекст: КонтекстВызоваИнтеграции, 
                         Сообщение: ГруппыПример2.Сообщение): Коллекция<УзелСхемыИнтеграции>

   возврат Сообщение.КодОтветаHttp == 200
            ? [Схема.Узлы.ДляПолучателей, Схема.Узлы.ФормированиеЗаписиПротокола]
            : [Схема.Узлы.ФормированиеЗаписиПротокола]
;

Пример 3​

Есть следующий процесс интеграции, очень похожий на пример 2:

Пример 3. Схема процесса интеграции

Есть информационные системы партнеров. Мы их опрашиваем по протоколу HTTP. После этого мы либо отправляем данные в один из офисов, либо формируем протоколы. Узел МаршрутизаторПоСодержимому, обработчик события ОбработчикОпределенияПолучателей:

метод ВОфисИлиВПротокол(Контекст: КонтекстВызоваИнтеграции, 
                        Сообщение: ГруппыПример3.Сообщение): Коллекция<УзелСхемыИнтеграции>

   возврат Сообщение.КодОтветаHttp == 200
            ? [Схема.Узлы.ВходящиеОфис, Схема.Узлы.ФормированиеПротокола]
            : [Схема.Узлы.ФормированиеПротокола]
;

Сформируем отдельные файлы для каждой информационной системы из группы Партнеры (чтобы иметь доказательство того, что нам присылал каждый из партнеров в ответ на запрос). Узел ФормированиеПротокола, обработчик события ОбработчикПреобразования:

метод ФормироватьЗаписьПротокола(Контекст: КонтекстВызоваИнтеграции, 
                                 Сообщение: ГруппыПример3.Сообщение): СообщениеИнтеграции

   исп Тело = новый ВременныйПотокЗаписи()
   пер Адрес = Сообщение.Получатели.Размер() == 1
                  ? Сообщение.Получатели[0].Uri
                  : "???"
   Тело.Записать("%{Момент.Сейчас()}, %{Сообщение.КодОтветаHttp}, 
                  %{Сообщение.ТекстОтветаHttp}, %{Адрес}\n")
    
   возврат Сообщение 
;

Обработчик события ОбработчикОпределенияИмени в узле Протокол устроен следующим образом:

метод ФормированиеИмениПротокола(Контекст: ГруппыПример3.КонтекстВызова, 
                                 Сообщение: ГруппыПример3.Сообщение): Строка

   возврат Сообщение.УзлыПути.Получить(Схема.Узлы.HTTP).Получатель.Код
;

В нем используется история движения сообщения по маршруту (Сообщение.УзлыПути) и выясняется, какое значение (Получатель.Код) было после того, как сообщение ушло из узла HTTP.

Последнее обновление