我之前也遇到过类似的性能困扰，完全理解你不想开启接收端口失败消息路由的顾虑。下面给你几个可行的方案，不用生成错误报告就能订阅到这些挂起消息：

方法一：用BizTalk管理控制台的自定义查询直接定位 #

这是最直接的方式，不用写任何代码就能查看和管理挂起消息：

• 打开BizTalk Administration Console，找到你的BizTalk组，右键点击「Queries」选择「New Query」
• 在查询配置界面，把查询类型设为「Messages」，然后添加筛选条件：
  • 第一个条件选「Message Status」，运算符「Equals」，值选「Suspended (Resumable)」或者「Suspended (Not Resumable)」，根据你的消息状态需求来
  • 还可以叠加筛选，比如加上「Port Name」指定特定接收端口，或者「Message Type」缩小目标范围，这样能精准定位你要的消息
• 保存这个查询后，就能随时查看符合条件的挂起消息，还能设置控制台警报，有新的挂起消息时及时提醒

方法二：用自定义订阅（Orchestration或发送端口）自动捕获 #

如果需要自动处理这些挂起消息，比如转发到存储位置或者做后续处理，可以用自定义订阅：

针对Orchestration的订阅方式 #

• 新建一个专门的Orchestration，添加一个接收形状，绑定到直接绑定的接收端口（也就是不指定具体物理端口）
• 在接收形状的筛选器里设置条件，比如：

  BTS.MessageStatus == "Suspended" AND BTS.MessageType == "你的消息类型命名空间#消息类型名称"
  

  你还可以结合BTS.ReceivePortName来指定特定接收端口的挂起消息，确保只捕获你关心的内容
• 注意给这个Orchestration分配足够的权限，保证它能访问到这些挂起消息，同时不要和原有业务流程冲突

针对发送端口的订阅方式 #

• 创建一个静态发送端口（比如文件端口，把消息存到指定目录），在筛选器里设置和上面类似的条件，比如针对特定消息类型的挂起消息
• 这样一来，符合条件的挂起消息会自动被路由到这个发送端口，不用人工干预，也不会生成额外的错误报告

针对你提到的Orchestration超时场景的特殊处理 #

你说的那种「发送请求后Orchestration超时完成，后续响应回来导致挂起」的情况，可以针对性设置筛选条件：

• 利用BTS.CorrelationToken属性，这个属性关联着原Orchestration的相关性令牌，结合BTS.MessageStatus == "Suspended"，就能精准捕获那些因为原流程已结束而找不到订阅者的响应消息
• 或者结合MessageType（响应消息的类型）和BTS.ReceivePortName（接收响应的端口）来筛选，效果也很好

一些注意事项 #

• 千万不要开启接收端口的「Enable Failed Message Routing」，避免生成大量错误报告拖垮性能
• 记得定期清理捕获到的挂起消息，不然会占用BizTalk数据库的存储空间，影响整体性能
• 所有配置先在测试环境验证一遍，确保筛选条件能准确命中目标消息，再部署到生产环境

内容的提问来源于stack exchange，提问作者Techie