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

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

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

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

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

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

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

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

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

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

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

Пример 1

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

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

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

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

В результате преобразует эту схему следующим образом:

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

Пример 2

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

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

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

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

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

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

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

Пример 3

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

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

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

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

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

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

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

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

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

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

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