前段时间有个BizTalk 2006的项目使用发送端口组时碰到一个问题，通过管理控制台查询发现存在许多消息状态为“已挂起（不可恢复）”，服务状态为“已挂起（不可恢复）”的消息。后来找到原因是发送端口组和业务流程的设置引起。一些使用BizTalk的朋友可能也会碰到这方面问题，因此笔者在BLOG上记下以供参考。
程序介绍
本BizTalk程序通过接收端口接受XML文档，并由业务流程进行订阅，在业务流程内部对消息进行XML变换，然后将消息路由到发送端口。整个业务流程事务类型设置为“长期事务”，对于报文的XML转换和发送在业务流程的一个作用域中，而该作用域的事务类型设置为“原子事务”。发送端口的通达通知属性设置为“已传输”（其默认值为“无”），通过该属性指明“如果消息传输在该端口上失败，应该向业务流程通知DeliveryFailureException”。
在对该BizTalk应用程序进行实际部署时使用以下物理端口：
接收端口包含一个接收位置，使用FTP适配器，接收管道使用XMLReceive。该端口的消息由业务流程订阅，在业务流程处理完消息后，绑定到发送端口组。发送端口组包含3个发送端口，分别是SQL适配器，FILE适配器和FTP适配器，发送管道使用“XMLTransmit”。
错误信息
运行部署好的应用程序，放置报文到接收位置，查看发送端口组对应的输出报文或SQL数据库记录，数据和报文输出正常。但是，通过BizTalk管理控制台查询显示许多消息消息状态为“已挂起（不可恢复）”，服务状态为“已挂起（不可恢复）”。查看消息对应的服务示例，服务实例状态为“已挂起（不可恢复）”。错误代码“0xC0C01B4C”，同时错误说明为“实例已完成但并未使用其所有消息。该实例及其未使用的消息已被挂起。”。查看消息详细内容，在消息部分的Body看到所有该类型的消息内容为“ < S t r i n g \ > ”，长度为24个字符。
错误分析
针对该业务流程，前段时间是使用一个发送端口绑定业务流程的逻辑发送端口，不存在上述错误现象。由于数据分发的需要后来修改成发送端口组出现该问题，想到跟物理发送端口组和业务流程的逻辑发送端口有关系。最终问题还是通过微软BizTalk工程师的协助得到解决。出现该问题的根源在于设置了业务流程发送端口的通达通知属性为“已传输”。由于使用发送端口组同该逻辑发送端口进行绑定，在消息发送到端口组的3个端口后，在某一个发送端口成功处理完消息后，产生反馈通知信息返回给业务流程，业务流程会收到“消息已传输成功”的通知，流程会继续往下走，而不会等待另外两个发送端口处理消息的结果反馈消息。在另外两个消息的传输通知反馈给业务流程的时候，该业务流程已经走到下一个阶段，不会对返回的消息进行处理，从而出现错误说明为“实例已完成但并未使用其所有消息。该实例及其未使用的消息已被挂起。”
解决方案
可以想到的方案是修改业务流程的发送端口的通达通知属性设置为“默认值“无”。确实笔者采用了该方案，实现比较简单，设置完成后重新部署，重起主机示例，问题得到解决。不过，微软提供了另一种方案，通过vbs脚本，定时的轮循MessageBox的消息，把上述这些有问题的消息提取出来然后进行清理。
引用自：http://www.itgrass.com/a/dotnet/NET-Framework/200707/31-7730.html
程序介绍
本BizTalk程序通过接收端口接受XML文档，并由业务流程进行订阅，在业务流程内部对消息进行XML变换，然后将消息路由到发送端口。整个业务流程事务类型设置为“长期事务”，对于报文的XML转换和发送在业务流程的一个作用域中，而该作用域的事务类型设置为“原子事务”。发送端口的通达通知属性设置为“已传输”（其默认值为“无”），通过该属性指明“如果消息传输在该端口上失败，应该向业务流程通知DeliveryFailureException”。
在对该BizTalk应用程序进行实际部署时使用以下物理端口：
接收端口包含一个接收位置，使用FTP适配器，接收管道使用XMLReceive。该端口的消息由业务流程订阅，在业务流程处理完消息后，绑定到发送端口组。发送端口组包含3个发送端口，分别是SQL适配器，FILE适配器和FTP适配器，发送管道使用“XMLTransmit”。
错误信息
运行部署好的应用程序，放置报文到接收位置，查看发送端口组对应的输出报文或SQL数据库记录，数据和报文输出正常。但是，通过BizTalk管理控制台查询显示许多消息消息状态为“已挂起（不可恢复）”，服务状态为“已挂起（不可恢复）”。查看消息对应的服务示例，服务实例状态为“已挂起（不可恢复）”。错误代码“0xC0C01B4C”，同时错误说明为“实例已完成但并未使用其所有消息。该实例及其未使用的消息已被挂起。”。查看消息详细内容，在消息部分的Body看到所有该类型的消息内容为“ < S t r i n g \ > ”，长度为24个字符。
错误分析
针对该业务流程，前段时间是使用一个发送端口绑定业务流程的逻辑发送端口，不存在上述错误现象。由于数据分发的需要后来修改成发送端口组出现该问题，想到跟物理发送端口组和业务流程的逻辑发送端口有关系。最终问题还是通过微软BizTalk工程师的协助得到解决。出现该问题的根源在于设置了业务流程发送端口的通达通知属性为“已传输”。由于使用发送端口组同该逻辑发送端口进行绑定，在消息发送到端口组的3个端口后，在某一个发送端口成功处理完消息后，产生反馈通知信息返回给业务流程，业务流程会收到“消息已传输成功”的通知，流程会继续往下走，而不会等待另外两个发送端口处理消息的结果反馈消息。在另外两个消息的传输通知反馈给业务流程的时候，该业务流程已经走到下一个阶段，不会对返回的消息进行处理，从而出现错误说明为“实例已完成但并未使用其所有消息。该实例及其未使用的消息已被挂起。”
解决方案
可以想到的方案是修改业务流程的发送端口的通达通知属性设置为“默认值“无”。确实笔者采用了该方案，实现比较简单，设置完成后重新部署，重起主机示例，问题得到解决。不过，微软提供了另一种方案，通过vbs脚本，定时的轮循MessageBox的消息，把上述这些有问题的消息提取出来然后进行清理。
引用自：http://www.itgrass.com/a/dotnet/NET-Framework/200707/31-7730.html
