sql-server - Service Broker错误处理模拟

我现在在项目中工作，其中应使用服务器代理功能将多个POS同步到主服务器。现在我为此解决方案准备错误处理，并希望向客户展示它是如何工作的。这意味着我将为各种错误准备测试脚本，客户端在测试POS上运行它以查看错误是否正确处理。

我们将使用带有有害消息= OFF的SQL Server 2008R2。

消息类型= XML（但内部可以是不同类型的数据，某些节点将包含BLOB）。

POS将位于domen之外，因此传输将受到保护（但没有对话加密）。

我在几个子组中划分错误：

逻辑错误（例如字符串数量）。它将由。处理服务器端的TRY-CATCH块。它是易于模拟
Service Broker配置错误（消息或不会被退回或无法到达目的地）。我认为它可以通过使用SQl来处理服务器服务代理事件和模拟将是某种“坏” 配置“（SB GUID，服务名称等）
传输错误。这是我们的时候有一个破碎的消息。事实上它是客户意见来测试这种错误。我不知道我们有没有安全运输水平（证书）我们受到保护这种错误。另一个问题我怎么能模拟这个。

问题：

我的文章here的第二部分讨论了Service Broker错误，它们是如何发生以及如何处理它们的。对您而言重要的是区分两类错误：

可恢复：传输问题，大多数配置错误，例如错误的路由，无法访问的服务器。所有这些都不会导致SSB错误，但会导致延迟。消息将保留在transmission_queue中，期望问题是暂时的并且可以解决，包括一些配置问题。问题解决后，SSB将重试并传递消息。
不可恢复：这些是SSB认为不可恢复的问题，例如。一种糟糕的消息格式。在这种情况下，会话将被中止，并且两个端点都会收到错误消息。

我还有一篇文章Error Handling in Service Broker procedures，讨论了SSB激活上下文中异常处理的一些特定主题。

最后一点：我强烈反对你禁止将毒物信息检测关闭。最好禁用处理，而不是因为有毒信息而无法进行恶心循环。

关于如何模拟损坏的消息的主题：难以模拟（您可以尝试设置一个端口转发器，让所有流量通过，但随机破坏其中的一些）但是相当无意义。所有SSB流量（即使是明文形式）都经过加密签名，任何消息损坏都会因消息签名验证失败而导致突然断开。