Канал, хранящий сообщения

Узел этого вида получает сообщения от информационных систем по протоколу AMQP. Такими информационными системами, в частности, являются информационные базы «1С:Предприятия».

Свойства канала

• ИмяКанала

  Имя канала, хранящего сообщения (подробнее)

• ЭтоКанал

  Является ли канал хранящим сообщения. Чтобы отметить канал как хранящий сообщения, следует установить значение Истина (по умолчанию — Ложь)

Пример использования канала, хранящего сообщения

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

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

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

Чтобы этого не произошло, после того как сообщение покинуло узел HTTP, его нужно сохранить. Для этого следует использовать свойство маршрута — ЭтоКанал. Нужно выделить канал, идущий от узла HTTP к узлу Транслятор, и установить у него в свойстве ЭтоКанал значение Истина.

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

Бесконечная доставка

Нужно учитывать, что если в описанном процессе интеграции в узле Транслятор в обработчике события ОбработчикПреобразования происходит необработанное программное исключение, то сообщение снова и снова будет доставляться в узел Транслятор, что может застопорить всю обработку сообщений. Чтобы этого не произошло, в панели управления приложением следует открыть в карточку процесса интеграции, и во вкладке Схема, в свойствах, задать максимальное количество повторных доставок для процесса.

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

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

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

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

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

Не имеет смысла использовать канал, хранящий сообщения:

• после узла «ПрограммныйИсточник»
• после узла «Канал1СИсточник»
• перед узлом «Канал1СНазначение»
• после узла «ОчередьШиныИсточник»
• перед узлом «ОчередьШиныНазначение»

Эти виды узлов сами по себе обладают функциональностью хранения сообщений.

Имена каналов

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

Каждый узел схемы и каждый канал схемы имеют уникальный системный идентификатор, который они автоматически получают при своем создании. Если вы удалили узел схемы, а затем создали новый с таким же именем, то при обновлении приложения «1С:Шина» будет считать, что старый узел удален, а новый узел добавлен, так как у него другой системный идентификатор.

То же самое относится к маршрутам. Если вы на схеме удалили маршрут вида «канал, хранящий сообщения», и создали его заново, то сообщения будут утеряны. Чтобы этого не произошло, новому маршруту следует дать то же имя. Если при обновлении приложения «1С:Шина» увидит, что идентификаторы каналов отличаются, но имена каналов совпадают, то она будет считать, что это тот же самый канал, и не удалит его.

В общем случае после обновления приложения и старта процесса интеграции возможны следующие варианты событий:

1. Если прежде канал с именем Х соединял узлы А и Б, а в новой схеме канал с именем Х соединяет узлы Ю и Я, то сообщения, находящиеся в очереди канала X, попадут в узел Я.
2. Если прежде в схеме был канал с системным идентификатором ID и именем Х, а в новой схеме есть канал с таким же системным идентификатором ID и именем Y, то сообщения, находящиеся в очереди канала X, попадут в очередь канала Y, а очередь канала X будет удалена.
3. Если прежде канал с именем Х соединял узлы А и Б, а в новой схеме канала с таким именем нет, то сообщения, находящиеся в очереди канала Х, попадут в канал недоставленных сообщений, а сама очередь будет удалена.