恢复实例时路由失败 - BizTalk
我创建了一个小型 BizTalk 应用程序,它有一个动态发送端口,并传输了传递通知 == 。
发送端口配置为文件夹路径,当该文件夹不存在时,它会暂停编排。当我在创建文件夹后尝试恢复编排时。我在 BizTalk 查询表达式中得到两个实例。实例错误消息为
- 状态:挂起(不可恢复)
错误代码:0xC0C01B4e(路由失败报告)
““”的路由失败报告”的路由失败报告
- 状态:暂停(可恢复)
错误代码:0xc0c01b02
错误描述:无法路由已发布的消息,因为未找到订阅者。
注意:
仅当我设置“投递通知 == 已发送”时,我才会收到此错误消息
这在某些环境中工作正常。
I have created a small BizTalk application which has a single dynamic send port with the Delivery Notification == transmitted.
The send port is configured to a folder path and when the folder is not exist it suspends the orchestration. When I try to resume the orchestration after creating the folder. I'm getting two instances in the BizTalk query expression. the instance err messages are
- Status : Suspend(Not resumable)
Error code : 0xC0C01B4e (Routing Failure Report)
Routing Failure Report for "Routing Failure Report for """
- Status : Suspend(resumable)
Error code : 0xc0c01b02
Error Description: The published message could not be routed because no subscribers were found.
NOTE:
I'm getting this error message only when I set the Delivery notification == transmitted
This works fine in some environment.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这可能是因为接收位置中定义的管道未设置为 XML 管道。改变管道,它应该可以工作。
it might be because the pipeline define in the receive location was not set to be an XML pipeline. Change the pipeline and it should work.
在路由失败的情况下,总会有 2 个失败实例:
第一个是不可恢复的、仅供参考的“路由失败报告”。
第二个是由于未找到订阅者而未路由的实际消息。因此,“无法路由已发布的消息,因为找不到订阅者。”这类似于我们在编排路由失败时看到的“将状态保存到数据库时发生异常”错误消息。
现在有什么区别:
挂起(可恢复)实例将显示消息正文,您将能够看到消息的内容(正文)。但是,该消息的上下文属性不会帮助您找到路由失败的原因。
但是,挂起(不可恢复)消息将具有所需的“上下文属性”,这将帮助您确定路由失败的原因。这就是为什么我们会看到以下内容
:“此服务实例的存在是为了帮助调试实例“{您的消息实例 id}”的路由失败。与此实例关联的消息的上下文包含路由失败时的所有升级属性。”
There will always be 2 failure instances in case of routing failure:
First is a non resumable, information only "Routing failure report".
Second is the actual message which was not routed because no subscriber found. Hence "the published message could not be routed because no subscribers were found." This is similar to "Exception occurred when persisting state to the database." error message we see in case of Orchestration routing failures.
Now whats is the difference:
The Suspend(resumable)instance will have the message body present, and you will be able see the contents(body) of the message. However the context properties of that message won't help you finding the reason of routing failure.
However the Suspended(Not resumable) message will have the required "Context properties" which will help you determine the reason of routing failure. That's why we see following
"This service instance exists to help debug routing failures for instance "{your message instance id}". The context of the message associated with this instance contains all the promoted properties at the time of the routing failure."