在 BizTalk 中捕获 FTP 接收连接异常
我有一个连接到 FTP 服务器的 BizTalk 演示。
但是，可能会发生各种异常，例如：
- 服务器可能不可用
- 用户名/密码可能会更改
- 下载后的文件删除可能因权限问题而无法进行等。
这些都会在错误日志中生成异常。
之外，我看不到任何简单的方法来处理这些异常
- 但是，除了编写自定义 WMI 适配器来轮询错误日志并尝试根据适配器名称匹配异常
- 。使用 FTP 适配器的日志功能并解析日志文件以查找 FTP 异常。
互联网上的解决方案似乎围绕启用“失败消息路由”或使用 ESB 异常处理程序。但是，我相信这两者都需要实际的消息，如果适配器遇到异常并且连接失败，则不会有实际的消息。
我考虑过但认为不可能的一种可能性是在编排中动态地执行“接收”，并在那里捕获异常 - 这可能吗？
如果没有，有什么方法可以在收集消息之前捕获接收适配器抛出的异常吗？
谢谢！
I have a BizTalk demo connecting to an FTP server.
However, there are various exceptions that can occur such as:
- The server may be unavailable
- The username/password may change
- File deletion after downloading may not work due to permissions etc.
These generate exceptions in the Error Log.
However, I can't see any easy way for me to handle these exceptions beyond
- Writing a custom WMI adapter to poll the Error Log and try and match exceptions based on adapter name.
- Using the Log functionality of the FTP adapter and parsing the log file for FTP exceptions.
Solutions on the internet seem to revolve around enabling "Failed Message Routing" or using the ESB Exception Handler. However, I believe both of these require actual messages, which there won't be if the adapter encounters an exception and fails to connect.
One possibility I've considered, but don't think is possible, is dynamically doing a "receive" in an orchestration, and catching exceptions there - is this possible?
If not, is there any way to catch an exception thrown by a receive adapter before messages are collected?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
BizTalk 将通过发生错误并关闭接收位置来“处理”这些异常情况。这是正常的，我认为非常合理的行为。
在这种情况下，BizTalk 并未停止工作。将消息接收到接收端口的其他方法将继续工作。
不知道您想到的处理方式是怎样的？您可以通过多种方式监控事件日志。
您希望例外情况发生什么？
在回答您的其他问题时，您可以通过从编排中调用 .net 组件来“动态地进行接收”。您可以有一个编排，它围绕“轮询”FTP 服务器的表达式形状循环。在这种情况下，您当然可以访问常规异常处理机制。
附言。您是正确的，失败的消息路由依赖于存在消息。例如，如果入站消息在管道处理期间失败。
BizTalk will "handle" these exception cases by eventing an error and shutting down the receive location. This is normal and I think very reasonable behavior.
In this instance BizTalk has not stopped working. Other methods of receiving messages into the receive port will continue to work.
I am not sure what kind of handling you have in mind? There are plenty of ways you can monitor an event log.
What do you want to happen as a result of the exceptions?
In answer to your other question, you can "dynamically do a receive" by calling a .net component from an orchestration. You could have an orchestration which looped around an expression shape which "polled" the FTP server. In this case you would certainly have access to regular exception handling mechanisms.
PS. You are correct that failed message routing relies on there being a message. For example if an inbound message failed during pipeline processing.