我现在从事的项目中，应该使用服务器代理功能将多个POS同步到主服务器。现在我为这个解决方案准备了错误处理，并想向客户展示它是如何工作的。这意味着我将为每种错误准备测试脚本，客户端在测试POS上运行它，看看它是否正确处理了错误。
我们将使用SQL Server 2008R2，毒消息=关闭。
消息类型=XML（但内部可以是不同类型的数据，有些节点将包含BLOB）。
POS将在domen之外，因此传输将是安全的（但没有对话加密）。
我将错误分为几个子组：
-
逻辑错误（例如字符串数量）。它将由处理服务器端的TRY-CATCH块。是的易于模拟
-
Service Broker配置错误（消息或将不会返回或无法到达目的地）。我想可以使用SQl进行处理服务器Service Broker事件和模拟会有点"糟糕"configuration"（SB GUID，服务名称等）
-
传输错误。这是我们有一条坏消息。事实上客户意见以测试此类错误我不知道我们是否有安全运输水平（证书）我们受到保护这种错误。另一个问题我该如何模拟。
问题：
- 还有其他错误类型吗
- 描述的#2错误处理逻辑是否足够好
- 如何处理和模拟#3
本文的第二部分将讨论Service Broker错误、它们是如何发生的以及如何处理它们。对你来说，重要的是区分两类错误：
- 可恢复：传输问题，大多数配置错误，如路由错误、无法访问的服务器。所有这些都不会导致SSB错误，而是导致延迟。消息将停留在transmission_queue中，期望问题是暂时的并且可以解决，包括一些配置问题。一旦问题得到解决，SSB将重试并传递消息
- 不可恢复：这些是SSB认为不可恢复的问题，例如错误的消息格式。在这种情况下，会话将被中止，并且两个端点都会收到错误消息
我还有一篇文章ServiceBroker过程中的错误处理，讨论了SSB激活上下文中异常处理的一些特定主题。
最后一点：我强烈建议您不要关闭有害消息检测。禁用处理比因为有害消息而恶心得没有进展要好得多。
关于如何模拟损坏的消息的主题：很难模拟（你可以尝试设置一个端口转发器，让所有流量通过，但会随机损坏其中的一些流量），但这是毫无意义的。所有SSB流量，即使是明文流量，都是加密签名的，任何消息损坏都会导致由于消息签名验证失败而突然断开连接。