失败的CSV文件如何适应ESB场景？ [英] How do failed CSV files fit into the ESB Scenario ?
问题描述
假设我们有一个非常基本的CSV文件，我们有一个管道设置来解析该CSV文件。
我们设置了faultportal，每次解析CSV失败时我们都想在faultportal中输入一个条目...
所以我们将EnableRoutingFor Failed消息设置为true ...
我知道当一个管道组件发生故障时，管道组件的原始流将被传递而不是被解析的流....
因此，这将导致失败的消息不是XML。 ...
故障端口如何处理这种错误情况？ （文档只显示失败的xml，所以我想知道它的外观）
从文档中我了解到你只能将flatfiles重新提交到HTTP位置。
但是然后HTTP接收location必须具有正确的管道...
因此，当您处理多个CSV文件时，您将获得大量端口。 （一个用于文件适配器的每个csv格式，另一个用于HTTP重新提交...）
如果你必须选择要重新提交的端口，这肯定会导致很多问题如果您选择了错误的端口....
我的第二个问题....
有没有人尝试过多个同时运行的大型CSV文件实例？
Well0549
Let's say we have a pretty basic CSV file, and we have a pipeline set up to parse that CSV file.
We have the faultportal set up and everytime parsing of the CSV fails we want an entry in the faultportal...
So we set EnableRoutingFor Failed messages to true...
Iknow that when a pipeline component fails the original stream of the pipeline component is passed through instead of the parsed stream....
So this will result in a Failed message that's not XML....
How will the faultportal handle this error situation ? ( The documentation only shows failed xml so I am wondering how it will look)
From the documentation I understand that you can only resubmit flatfiles to a HTTP location..
But then the HTTP Receive location must have the correct pipeline ...
So when you handle multiple CSV files you will get a lot of ports. (One for each csv format for the file adapter and another one for the HTTP resubmit...)
And if you have to select the port to resubmit to, this could for sure cause a lot of problems if you select the wrong port....
And my second question ....
Has anybody tried this with multiple instances of large CSV files running at the same time ?
Well0549
推荐答案
文本文件将正确存储在异常数据库中，因为它是基于文本的文件。该文件将显示为非常大的csv文件可能会有趣。可以选择下载邮件内容并保存到磁盘。对于大型csv文件，这可能很有用。此时您可以重新提交到提到的Http接收位置。
您对多个大型.csv文件有何顾虑？是否关注异常管理框架及其处理多个大文件的能力？
这篇关于失败的CSV文件如何适应ESB场景？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
