Имитация обработки ошибок Service Broker - PullRequest
Новая
       4

Имитация обработки ошибок Service Broker

0 голосов
/ 26 мая 2011

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

Мы будем использовать SQL Server 2008R2 с сообщением об ошибке = OFF.

Тип сообщения = XML (но внутри могут быть разные типы данных, некоторые узлы будут содержать большие двоичные объекты).

POS будут находиться вне домена, поэтому транспорт будет защищен (но без шифрования диалога).

Я делю ошибки на несколько подгрупп:

  1. Логическая ошибка (например, строка вместо числа). Обрабатывается блоком TRY-CATCH на стороне сервера.. Простое моделирование

  2. Ошибка конфигурации компонента Service Broker (сообщение или не будет возвращено или не может достичь пункта назначения).Я думаю, что это может быть обработано с помощью событий SQl Server Service Broker, и имитация будет своего рода «неправильной конфигурацией» (GUID SB, имя службы и т. Д.)

  3. Ошибка транспорта.Это когда у нас есть сломанное сообщение.На самом деле это мнение клиента, чтобы проверить такого рода ошибки.Я не знаю, обеспечили ли мы транспортный уровень (сертификат), мы защищены от такого рода ошибок.Другой вопрос, как я могу смоделировать это.

Вопросы:

  • существуют ли другие типы ошибок?
  • описана логика обработки ошибок №2достаточно хорошо?
  • как справиться и симулировать # 3?

1 Ответ

1 голос
/ 02 июня 2011

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

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

У меня также есть статья Обработка ошибок в процедурах компонента Service Broker , в которой рассматриваются некоторые темы, относящиеся к обработке исключений в активированном контексте SSB.

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

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

...