Назначение и возможности административного приложения сервисной шины.

Назначение административного приложения

Административное приложение позволяет:

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

Все настройки, выполненные через административное приложение, сохраняются в базу данных шины.

Внешний вид главной страницы административного приложения:

Развертывание и запуск административного приложения

Подробно установка и запуск административного приложения описаны в статье Установка и запуск шины в Docker.

Настройка пересылки сообщений через сервисную шину

Для того чтобы приложения могли обмениваться сообщениями через сервисную шину, необходимо:

  1. Создать типы сообщений для отправки между приложениями.
  2. Создать клиентов (отправителей и получателей сообщений).
  3. Создать подписки на получение сообщений.

Справку по основным терминам можно получить, ознакомившись с тезаурусом.

Создание перечисленных данных производится через пункт меню “Маршрутизация”:

Создание типов сообщений

Для создания типов сообщений необходимо перейти на соответствующий список:

Для создания нового типа сообщения необходимо нажать на кнопку “Добавить”. Для редактирования существующего типа сообщения необходимо щелкнуть по соответствующей строке.

В открывшейся форме необходимо обязательно заполнить поля “Идентификатор” и “Имя”:

Создание клиентов

Для создания клиентов необходимо перейти на соответствующий список:

Для создания нового клиента необходимо нажать на кнопку “Добавить”. Для редактирования существующего клиента необходимо щелкнуть по соответствующей строке.

При создании клиента-отправителя сообщений необходимо помимо “Имени” и “Идентификатора” клиента обязательно заполнить также “Разрешения на отправку”, где необходимо указать возможные типы отправляемых сообщений:

При создании клиента-получателя сообщений “Разрешения на отправку” создавать не требуется, однако необходимо указать адрес, по которому сервис шины будет пытаться доставить сообщения, а также подписку с указанием типа принимаемого сообщения, срока действия и способа передачи данных:

Подписка может быть создана или отредактирована как на отдельной форме, так и на форме редактирования конкретного клиента.

Использование идентификаторов клиентов и типов сообщений

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

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

Необходимо также учитывать, что при поиске подписок на отправленное сообщение сервис шины обрабатывает идентификаторы клиента и типа сообщения особым образом. Если идентификатор не совпадает с идентификатором клиента (или типа сообщения), то сервис шины пытается интерпретировать идентификатор как GUID и сравнить его с первичным ключом (Primary Key) этого клиента (или типа сообщения).

Управление сообщениями сервисной шины

Для управления сообщениями, находящимися в очереди внутри сервиса шины, необходимо открыть соответствующий список:

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