Почему я решил писать эту статью?
Вводная часть
Три инструмента сервисов интеграции
Сервисы интеграции, каналы, сообщения сервисов интеграции
Что мы использовали ранее?
Процесс создания сервиса интеграции
Три таблицы СУБД после добавления сервиса интеграции
Ненужное поле «Адрес внешнего сервиса интеграции»
Форма загрузки каналов «под капотом»
Как работает таблица [IntegServiceSettings]?
Создание сообщения сервиса интеграции
Необходимо проверить активность сервиса интеграции
Демонстрация ошибки с выключенной активностью
Необходимо указывать дату устаревания больше текущей даты сеанса
Необходимо указывать канал с типом отправка.
Нюанс с телом сообщения
Как хранятся сообщения?
Как работает таблица [IntegChannelOutQueue]?
Что хранится в MessageHeader?
Сквозной пример с Шиной
Таблицы каналов в СУБД
Как проверить, что каналы подключены к Шине?
Как запустить обмены с Шиной?
Как работает таблица [IntegChannelInQueue]?
Эксперимент с переносом сообщения средствами СУБД (Без Шины)
Обработка чтения сообщения
Отправитель и получатель в сообщениях сервисов интеграции
Неприятные ошибки при отборах сообщений
Баг по отбору количества сообщений
Баг с отбором по «ИдентификаторСообщенияЗапроса»
Схемы работы Сервисов интеграции при работе с Шиной
Включаем активность сервиса интеграции
Выключаем активность сервиса интеграции
Устанавливаем настройки сервиса интеграции
Создаем сообщение в канале сервиса интеграции
Запускаем фоновые задания и отправляем сообщения в Шину
Запускаем фоновые задания и получаем сообщения из Шины
Останавливаем фоновые задания
Где можно еще применять сервисы интеграции?
Ссылка на статью с примером «Сервисы интеграции без Шины и интеграции»
Заключение
Полезные ссылки
Во-первых, я запланировал цикл статей по интеграции и для продолжения мне необходимо рассказать про механизм «Сервисы интеграции».
Во-вторых, этот механизм новый и незаслуженно пылится, вот я и решил показать его типовое и не типовое использование. Возможно, кто-то после прочтения статьи избавит свои разработки от лишних регистров сведений.
В-третьих, если «загуглить» информацию по «Сервисам интеграции», мы найдем информацию только по взаимодействию с 1С:Шиной. И даже на ИТС прямым текстом написано, что разработаны они для взаимодействия с системами класса сервисная шина предприятия через «Внешние сервисы интеграции».
Между тем мы получили новый «Золотой стандарт», ну если и не золотой, то желтый как минимум.
Я очень люблю "мясо" и в статье его будет с избытком.
Давайте разбираться!
В статье «Поинтегрируем: нужна ли Шина вам?» я предупреждал, что буду плотно рассказывать
про сервисы интеграции, также я говорил, что поделюсь инструментами.
Инструменты, которые будут использоваться в этой статье, я выложил в статье «Три инструмента для сервисов интеграции», также создал проект на GitHub и выложил туда все исходники.
Нам понадобятся три обработки:
- Сообщения сервисов интеграции
- Настройка сервисов интеграции
- Отправка сообщения сервисов интеграции
Начнем с того, что «Сервисы интеграции» и «Сообщения сервисов интеграции» работают в паре.
Появились «Сервисы интеграции» в платформе 8.3.17.
Сервисы интеграции — это как ящики электронной почты, они содержат «Каналы».
Каналы — это как папки в ящике электронной почты, в которые складываются «Сообщения сервисов интеграции». При этом «Канал» может быть, либо на отправку, либо на получение.
Сообщения сервисов интеграции — это как электронные письма. При этом у этих писем есть свойства, которые нельзя изменять, есть параметры, которые служат для дополнительной детализации, и есть тело сообщения.
Свойства:
ДатаОтправки (Чтение) – Дата отправки сообщения. [с версии "8.3.17"]
ДатаУстаревания (Редактируемое при создании сообщения, после того как сообщение создано, его изменять нельзя) – Дата и время, после которого сообщение не должно обрабатываться. [с версии "8.3.17"]
Идентификатор (Чтение) – Идентификатор сообщения. [с версии "8.3.17"]
ИдентификаторСообщенияЗапроса (Редактируемое) – Идентификатор сообщения, на которое создается ответ. [с версии "8.3.17"]
КодОтправителя (Редактируемое) – От кого сообщение. [с версии "8.3.17"]
КодПолучателя (Редактируемое) – Можно указать через запятую нужных получателей. Если не указан уйдет всем возможным получателям. [с версии "8.3.17"]
Параметры (Редактируемое) – Соответствие, в котором можно указать дополнительную информацию, например для маршрутизации или чтения данных. [с версии "8.3.17"]
РазмерТела (Чтение) – Это поле показывает размер тела сообщения. До появления нужно было создавать в параметрах программно свойство «РазмерТела». [с версии "8.3.21"]
Что мы использовали ранее?
Все мы когда-то создавали регистры сведений для хранения пакетов. Пакеты хранили данные для дальнейшей передачи. В этих регистрах мы хранили ИД пакетов, дату создания, статусы и прочие реквизиты, по которым можно было понять, что за информация в них и кому предназначается.
Пример такого регистра:
Мы создавали все новые и новые регистры. Теперь у нас есть возможность не плодить такие регистры, а использовать «Сервисы интеграции». Но об этом позже, сначала посмотрим на их внутренности.
В конфигураторе и в расширении начиная с 8.3.17 появилась возможность добавить «Сервис интеграции», на данном этапе я буду демонстрировать не в расширении, но дальше в статье будут примеры и с расширениями.
Моя цель показать, как выглядит структура в СУБД и что происходит, когда мы делаем какие-то действия в платформе.
Добавим «Сервис интеграции» с именем «ТестовыйСервис»:
После добавления «Сервиса интеграции» в СУБД, появились три таблицы:
IntegServiceSettings47 – Настройки сервиса интеграции
IntegServiceMsgBody48 – Тело сообщения сервиса интеграции
IntegServiceExtMsgBody49 – Внешнее тело сообщения сервиса интеграции
Нумерация может отличатся от вашей.
Ненужное поле в форме создания сервиса:
Обратите внимание на поле «Адрес внешнего сервиса интеграции». По факту оно не нужно и ниже мы это увидим.
Это поле хранит значение для формы загрузки каналов, при этом настройки для подключения хранятся совсем в другом месте, а каналы можно добавить вручную.
Как работает форма загрузки каналов?
Форма загрузки каналов сделана небрежно, на скорую руку.
Где:
Пользователь = Идентификатор ключа
Пароль = Секрет клиента
Эта форма делает следующее:
1 Отправляет POST запрос для получения JWT(JSON Web Token) токена.
2 С полученным токеном отправляется GET запрос на получение списка каналов.
При нажатии кнопки «Загрузить», добавляет выбранные каналы:
Из того, что добавилось, важны два пункта, которые приходят из запроса:
1 «Имя канала внешнего сервиса интеграции» формируется с помощью свойств process + ”.” + channel
"process": "Основной::ОбменМеждуБазами"
"channel": "ВБазу2"
2 «Направление сообщения» формируется с помощью свойства access
Отправка => "access": "WRITE_ONLY"
Получение => "access": "READ_ONLY"
Как работает таблица [IntegServiceSettings]?
Данная таблица отвечает за хранение настроек сервиса интеграции. Давайте активируем «Сервис интеграции», воспользовавшись типовой обработкой или обработкой «Настройка сервисов интеграции».
Или кодом:
СервисыИнтеграции[Сервис].УстановитьАктивность(Истина);
После включения в [IntegServiceSettings47] появилось следующее значение:
Значения _Active:
0x01 – Включено
0x00 - Выключено
*Если настройки не заполнены, тогда при выключении удаляется строчка в СУБД по данному каналу
Обратите внимание на поле «Адрес внешнего сервиса интеграции», оно заполнено значением из конфигуратора «123». Но я же говорил, что поле в конфигураторе ненужное, а тут мы видим обратное!
Поменяем в нем значение на 1234, добавим имя пользователя "111" и пароль "111".
То же самое можно сделать кодом:
НастройкиСИ = Новый НастройкиСервисаИнтеграции;
НастройкиСИ.АдресВнешнегоСервисаИнтеграции = "1234";
//НастройкиСИ.ИмяПользователя = "";
НастройкиСИ.ИмяПользователяВнешнегоСервисаИнтеграции = "111";
НастройкиСИ.ПарольПользователяВнешнегоСервисаИнтеграции = "111";
СервисыИнтеграции[Сервис].УстановитьНастройки(НастройкиСИ);
После чего в поле _Content таблицы [IntegServiceSettings47] записались настройки:
Давайте зайдем в конфигуратор:
Обратите внимание, в конфигураторе у нас старое значение, которое будет вас сбивать. Поэтому лучше в конфигураторе не заполнять поле «Адрес внешнего сервиса интеграции». Надеюсь, когда-нибудь его уберут.
Есть важные моменты, которые надо учесть при создании сообщений сервисов интеграции, опишу эти моменты в этом блоке.
Важно:
- Необходимо проверить активность сервиса интеграции. Я видел много примеров, где про это нет ни слова. Мало того отправку делают сразу «ПередЗаписью» в Попытке. Если активность не проверять и кто-то выключит активность, тогда сообщения просто не будут создаваться, так как произойдет ошибка.
Демонстрация ошибки с выключенной активностью.
Выключаем «Сервис интеграции» и пытаемся отправить сообщение:
Получаем ошибку «Сервис интеграции не активен»:
Мы видим странное, фатальное поведение. Помните про этот момент, когда будете писать интеграции.
Логичнее было бы создавать сообщения, но не передавать их в Шину, но, к сожалению, сделали как сделали.
Активность проверяется при помощи кода:
АктивностьСервиса = СервисыИнтеграции[Сервис].ПолучитьАктивность();
- Необходимо указывать дату устаревания больше текущей даты сеанса. Если по каким-то причинам дата будет меньше текущей даты сеанса, вы поймаете ошибку «Не допускается создания сообщения с датой устаревания, меньше текущей».
Код установки даты устаревания:
Сообщение = СервисыИнтеграции[Сервис].СоздатьСообщение(ДатаУстаревания);
Что произойдет, когда будут запущены фоновые задания для обработки сообщений в канале с устаревшими датами?
Такие сообщения будут удалены, поэтому важно следить за такими вещами.
- Необходимо указывать канал с типом отправка. Если по каким-то причинам вы укажете канал с типом получение, поймаете ошибку «Не допускается отправка сообщения в канал, не предназначенный для отправки сообщений».
- Если у вас платформа младше 8.3.21 обязательно в параметры добавьте параметр с размером тела сообщения. Данный параметр нужен при чтении сообщения, об этом напишу ниже.
Код создания тела сообщения и создания параметра с размером:
Тело = Сообщение.ПолучитьТелоКакПоток();
Буфер = ПолучитьБуферДвоичныхДанныхИзСтроки(ТекстСообщения);
Тело.Записать(Буфер, 0, Буфер.Размер);
Тело.Закрыть();
// С платформы 8.3.21 этот кусок необязателен, так как было добавлено свойство РазмерТела
// Это свойство делает тоже самое, но автоматически
Если ВключитьРазмерСообщения Тогда
Сообщение.Параметры.Вставить("РазмерСообщения", Буфер.Размер);
КонецЕсли;
Давайте выяснять, где в СУБД хранятся свойства, параметры и тело.
Для начала я создам «чистое» сообщение. Без тела, без параметров и без отправителя с получателем.
Мы видим, что поле MessageBody в таблице [IntegChannelOutQueue53] равно «NULL»:
Теперь введем в тело сообщение “1” и создадим сообщение вновь:
Мы видим, что во втором сообщении в MessageBody появилось значение «0x31».
Это и есть наша единица:
https://bytetool.web.app/en/ascii/code/0x31/
Еще мы видим, что MessageHeader в первом и втором сообщении поменялось. Это из-за того, что у меня платформа старше 8.3.21, соответственно в свойство «РазмерСообщения» записался размер тела сообщения и изменился «Идентификатор» сообщения.
Сверяем текст из MessageHeader:
0x55DCE683889C54884A9DED4461E763942391C042BC15919C37F7D90946AC2DD29DE8D6FFA791E0FAD4
41A94402009100531B25AD44020081C1E1818181812812020
Обратите внимание на вот эти части: DCE683889C54884A9DED4461E763942391C042BC и 15919C37F7D90946AC2DD29DE8D6FFA791E0FAD4
А теперь посмотрим на поле «MessageId»:
Я не знаю, что обозначает 0x55, но мне теперь понятно, что после этого значения идет идентификатор из «MessageId».
https://bytetool.web.app/en/ascii/code/0x55/
Далее я решил создать еще одно сообщение, в котором в «ИдентификаторСообщенияЗапроса» помещу идентификатор первого сообщения:
ИдентификаторСообщенияЗапроса = Новый УникальныйИдентификатор("8883e6dc-549c-4a88-9ded-4461e7639423");
В MessageHeader я увидел два идентификатора:
0x55C3B6F18F3682E14C967208BE846566A49140884651A94402009100531B25AD44020095
DCE683889C54884A9DED4461E7639423C1E181818181812020
Где:
8883e6dc-549c-4a88-9ded-4461e7639423 => DCE683889C54884A9DED4461E7639423
8ff1b6c3-8236-4ce1-9672-08be846566a4 => C3B6F18F3682E14C967208BE846566A4
Вывод: [IntegChannelOutQueue] служит для исходящих сообщений.
Где:
MessageId – Идентификатор
ExpirationDate – Дата устаревания
MessageHeader – Свойства и параметры. Тут хранятся все значения для отборов сообщений.
MessageBody – Тело сообщения
Я еще немного покопался в этой теме. Создал сообщение, где указал отправителя alfa и получателя betta.
В итоге получил вот такой «MessageHeader»:
0x552246D1DA61C6CD4E812CFB7B5C9500BD9140D182F1AB44020091005B9D23AC44020095
5188AA08CC01F34ABC7EB836C6ECC2D8C1FA04616C66619A056265747461818182812020
Где:
Начальный символ -> 0x55 => U
Идентификатор -> 9EABEC76293F2F4194C9AB0110C9AA48 => b8f7a2be-86d1-4504-a473-2434b70f3b09
ИдентификаторСообщенияЗапроса -> 5188AA08CC01F34ABC7EB836C6ECC2D8 => 08aa8851-01cc-4af3-bc7e-b836c6ecc2d8
КодОтправителя -> 616C6661 => alfa
КодПолучателя -> 6265747461 => betta
Я пробовал в отправителя написать betta, а в получателя alfa и хвост выглядел вот так:
C1FA0562657474619A04616C6661818181812020
Обратите внимание на FA и 9A они остались на тех же местах.
А 05 и 04 поменялись местами в месте с отправителем и получателем.
После чего в отправителя положил вот такое значение:
КодОтправителя -> 62657474616265747461626574746162657474616265747461 => bettabettabettabettabetta
Хвост получился вот такой:
C1FA19626574746162657474616265747461626574746162657474619A04616C6661818181812020
Как вы видите, после FA появилась 19, делаю вывод, что это значение служит для расшифровки.
Дальше я не стал раскручивать эту тему.
Вы можете сказать: -Какой еще Шиной? В кратком содержании…
Не торопитесь. Для начала нужно показать, как работает стандартный обмен. То, для чего создавались «Сервисы интеграции». После мы посмотрим на то, что мы получили помимо стандартного использования.
Не буду пошагово описывать, как создать проект в Шине, акцент будет не на это.
Маршрут будет такой:
У нас две группы, между ними двухсторонний обмен. Базы, подключенные к этим группам, смогут принимать и отправлять сообщения. В документации Шины есть пример с магазинами под №3, наш маршрут точная копия.
В Шине будут следующие каналы:
Создаю две базы. В базе «Альфа», «Сервисы интеграции» будут в основной конфигурации:
После добавления каналов в СУБД появились две таблицы:
IntegChannelInQueue52 – Очередь получения канала сервиса интеграции
IntegChannelOutQueue53 – Очередь отправки канала сервиса интеграции
Нумерация может отличатся от вашей.
Включаем канал и добавляем настройки:
В базе «Бетта» добавлю сервисы интеграции через расширение:
В СУБД появились следующие таблицы:
IntegServiceSettings47X1 – Настройки сервиса интеграции
IntegServiceMsgBody48X1 – Тело сообщения сервиса интеграции
IntegServiceExtMsgBody49X1 – Внешнее тело сообщения сервиса интеграции
IntegChannelInQueue50X1 – Очередь получения канала сервиса интеграции
IntegChannelOutQueue51X1 – Очередь отправки канала сервиса интеграции
Нумерация может отличатся от вашей.
X1 обозначение расширения
Включаем канал и добавляем настройки:
Как проверить, что каналы подключены к Шине?
Проверить состояние с помощью кода:
СервисыИнтеграции[Сервис][Канал].ПолучитьСостояние()
Или посмотреть через обработку "Сообщения сервисов интеграции":
Как запустить обмены с Шиной?
Базы созданы, каналы включены, настройки сохранены. Чтобы запустить обмены, необходимо запустить фоновое задание (если сказать честно, то запускается 3 фоновых задания).
Для запуска фоновых заданий необходимо выполнить следующий код:
СервисыИнтеграции.ВыполнитьОбработку();
Фоновые задания запускаются на 2 минуты и проверяют есть сообщения к получению или отправке. В рекомендациях написано, что необходимо добавить регламент, который будет запускать эти задания раз в две минуты. Если установить запуск с меньшим периодом ничего плохого не случится. Для запуска необходимы права Администратора.
Я запущу фоновое задание используя обработку «Отправка сообщения сервисов интеграции». для этого нажму кнопку «Выполнить обработку»:
Три фоновых задания заработали:
Для того, чтобы выключить фоновые задания, нужно выполнить следующий код:
СервисыИнтеграции.ОстановитьОбработку();
Создадим сообщение в базе Альфа и передадим его в базу «Бетта»:
Далее проверим, появилось ли сообщение в канале отправки.
Для этого используем обработку «Сообщения сервисов интеграции»:
Мы видим, что сообщение попало в канал, давайте глянем в СУБД.
В таблице [IntegChannelOutQueue53] появилась запись:
На этом этапе я сохраню сообщение, чтобы сравнить с тем, что прилетит в базу «Бетта».
Теперь включим фоновое задание для обработки сообщений в базе «Альфа».
Сообщение пропало в таблице [IntegChannelOutQueue53], в данный момент оно в Шине:
В базе «Бетта» я специально сделал ошибку в коде, чтобы сообщение не прочиталось и осталось в канале:
Теперь включим фоновое задание для обработки сообщений в базе «Бетта» и сразу остановим обработку.
Обратите внимание, сообщение прилетело и ждет в канале, когда его прочитают:
В СУБД базы «Бетта» в таблице [IntegChannelInQueue50X1] мы видим данное сообщение:
Где:
MessageId – Идентификатор
ExpirationDate – Дата устаревания
MessageHeader – Свойства и параметры
MessageBody – Тело сообщения
Processed – Статус (0x01 – Прочитано, 0x00 – Не прочитано)
После того как сообщение прочитано, в поля MessageHeader и MessageBody записывается Null, а в Processed записывается «0x01»:
При сравнении сообщений в базе «Альфа» и базе «Бетта» обнаружил, что содержимое всех полей совпадают, отличается только содержимое MessageHeader.
Различия в тексте MessageHeader:
0x55B707DC56D4692E4DA5344229C663855491B0B22A2C5C6428A94402009100531B25AD44020081C35
C04B53970C220438043F0421043E043E043104490435043D0438044F04EB53970C1E0431043C0435043D
04140430043D043D044B043C04380420E04B53970F2004300437043C043504400421043E043E04310449
0435043D0438044F04EB4E89538B3820E04B539A10696E7465675F6D6573736167655F6964EB539A2435
366463303762372D363964342D346432652D613533342D34323239633636333835353420E04B539A114
A4D535844656C6976657279436F756E74EB4E822020FA04616C66619A056265747461818189812020
Делаем вывод:
В шапке сообщения что-то меняется непосредственно в Шине. Я предполагаю, что происходит замена получателей и отправителей, может быть, добавляются еще свойства.
И действительно в базе получателе я увидел, что в параметрах после Шины появились дополнительные свойства:
JMSXDeliveryCount
integ_message_correlation_id
integ_message_id
Но это уже связано с механизмами Шины, и я не стал анализировать таблицы Шины в поисках ответов.
!!! Данный эксперимент делался чисто из инженерного интереса, я делал его на свой страх и риск. Ни в коем случае не делайте это на продакшн !!!
Предыдущее исследование, меня огорчило, так как оно рушило то, что я хочу показать в этом пункте. Шина вносит в сообщение какие-то данные, происходит «Инъекция», но я все же решил попробовать на «дурака».
Создаю сообщение:
Вот сообщение:
В СУБД базы «Альфа» сообщение появилось:
Перебрасываю сообщение из базы «Альфа» в базу «Бетта» используя SQL:
INSERT INTO [iser2].[dbo].[_IntegChannelInQueue50X1] (_MessageId,_Position,_ExpirationDate, _MessageHeader, _MessageBody, _Processed)
SELECT [_MessageId]
,[_Position]
,[_ExpirationDate]
,[_MessageHeader]
,[_MessageBody]
, CAST(0 as binary(1)) as _Processed
FROM [iser].[dbo].[_IntegChannelOutQueue53] WHERE _MessageId = 0xA6E1978907ACBE44B054BF53C53704F1
Пояснение по SQL запросу:
Iser – База Альфа
iser2 – База Бетта
_Processed – Поле статус, в исходящих сообщениях данное поле отсутствует, поэтому создаем его в запросе CAST(0 as binary(1)) as _Processed
Запрос выбирает из базы «Альфа» все сообщения с указанным идентификатором из исходящих сообщений и копирует во входящие в базу «Бетта».
В СУБД базы «Бетта» появилось наше сообщение:
Ставлю точку остановы и запускаю фоновое задание по чтению сообщений.
Вижу, что сообщение читается нормально:
В СУБД после прочтения сработал стандартный механизм. В MessageHeader и MessageBody записывается Null, а в Processed записывается «0x01».
Как видите можно передать сообщение без использования Шины, но у этого способа есть много минусов, хотя плюсы тоже имеются.
Как мы уже видели ранее, в сообщении присутствует два свойства отвечающих за маршрутизацию «КодОтправителя» и «КодПолучателя», но какие есть нюансы с ними?
- Если не указать «КодОтправителя», тогда он проставится в Шине.
А что, если перебросить сообщение без Шины?
Перебрасываем сообщение средствами SQL и считываем в базе «Бетта»:
Как мы видим, Шина нам «прощает», если мы что-то не заполняем, но если мы используем «Сервисы интеграции» без Шины, то должны следить за заполнением свойств, отвечающих за маршрутизацию.
- Если не указать «КодПолучателя», тогда в Шине будут подставлены все возможные получатели, но в базу прилетит сообщение, адресованное только этой базе. То есть в каждой базе будет только один получатель в свойстве «КодПолучателя».
- Можно ли скомпрометировать отправителя через шину?
Для этого эксперимента в Шине создам еще одну инфосистему «Зетта» и подклю ее к группе «Бетта»:
Теперь отправим сообщение из базы «Бетта», указав, что оно отправлено от «Зетты»:
Смотрим, что прилетело в «Альфа»:
Шина подставила реального отправителя:
Соответственно если мы не используем Шину, нужно следить за заполнением верного отправителя, чтобы не скомпрометировать базу отправителя. Для этого можно, например, создать константу, хранящую отправителя, и в отправке сообщения проставлять «КодОтправителя».
Я поймал две ошибки, одну отправил в фирму 1с и ее приняли, а вторая отправлена 07.03.2024 и еще на первой линии.
1 Баг по отбору количества сообщений. В платформе отбор по количеству не работает, из-за чего выбираются все подходящие под отбор сообщения.
Баг отправлен в 1С, ждем, когда поправят:
2 Не работает отбор по свойству «ИдентификаторСообщенияЗапроса» со значением:
ИдентификаторСообщенияЗапроса = Новый УникальныйИдентификатор("00000000-0000-0000-0000-000000000000")
Выбираются абсолютно все сообщения, даже те у которых «ИдентификаторСообщенияЗапроса» заполнен.
Код отбора:
Отбор = Новый Структура;
Отбор.Вставить("ИдентификаторСообщенияЗапроса",
Новый УникальныйИдентификатор("00000000-0000-0000-0000-000000000000"));
СообщенияСервиса = СервисыИнтеграции[Сервис][Канал].ВыбратьСообщения(Отбор);
Баг отправлен в 1С, ждем, когда поправят: HL-802851
Схемы работы Сервисов интеграции при работе с Шиной
Включаем активность сервиса интеграции:
Выключаем активность сервиса интеграции:
Устанавливаем настройки сервиса интеграции:
Создаем сообщение в канале сервиса интеграции:
Запускаем фоновые задания и отправляем сообщения в Шину:
Запускаем фоновые задания и получаем сообщения из Шины:
Останавливаем фоновые задания:
Где можно еще применять сервисы интеграции?
Вообще если копнуть глубже, а мы копнем в статье «Сервисы интеграции без Шины и интеграции», «Сервисы интеграции» можно применять без Шины. Частично мы это уже проделали при помощи SQL.
Давайте подумаем, где можно применить «Сервисы интеграции»?
Можно придумать массу применений.
Вот несколько из них:
- Буфер для отправки электронной почты. Создаем сообщение в канале, а потом регламентом делаем массовые рассылки.
- Замена регистров с пакетами при различных обменах.
- Для работы в паре с ПоказатьОповещениеПользователя. Сейчас для этого используются регистры.
Примеры таких регистров:
И прочие варианты.
Один из возможных примеров применения я покажу в статье «Сервисы интеграции без Шины и интеграции».
Заключение
Механизм новый и вполне годный. Уже сейчас можно его применять в своих интеграционных и не интеграционных процессах. Многие его не используют из-за мифа, что это просто коннектор, также не было нормальной информации про данный механизм и, самое главное, не было инструментов.
Надеюсь, после этой статьи часть препятствий спадет.
На этом статью завершаю.
Всем желаю профессионального роста и интересных задач!
Полезные ссылки:
Поинтегрируем: нужна ли Шина вам? – Статья, с которой начался цикл статей по интеграции.
Три инструмента для сервисов интеграции – Бесплатные инструменты по работе с сервисами интеграции.
PAPI-tools – Проект на GitHub, содержащий исходники обработок, которые будут первоначально выкладываться в данном проекте, а в будущем перетекать в подсистему PAPI (релиз подсистемы запланирован на 19.05.2024)
Сервисы интеграции без Шины и интеграции – Пример использования «Сервисов интеграции» в базе без подключения к Шине и вообще без обменов.
