动态解析动态发送端口的自定义管道。 [英] Dynamically resolving custom pipeline for dynamic send port.

问题描述

伙计们，

我对ESB相对较新，所以这可能是一个noobie问题，所以如果有的话，请提前预测！ 

I am relatively new to ESB so this may be a bit of a noobie question, so appologies in advance if it is! 

我的情景......

My scenario...

我有一个行程......

I have an itinerary which...

1。可以接受来自多个源的CSV文件，这些源使用接收管道中的平面文件架构映射到XML

1. Can accept CSV files from multiple sources, which are mapped to XML using a flat file schema in the receive pipeline

2。我动态地解析（BRE解析器）正确的映射（取决于所接收的CSV文件）以将平面文件XML映射到标准的"内部"文件中。 XML格式

2. I dynamically resolve (BRE Resolver) the correct map (depending on the CSV file received) to map the flat file XML into a standard "internal" XML format

3。步骤2中的映射对接收的文档执行验证，以确定它是否有效（数据库查找等）。 对于任何无效的节点，该节点的状态设置为"ERROR"

3. The maps in step 2 perform validation on the received document, to determine if it is valid (DB lookups etc.).  For any Nodes which are invalid, the status of that node is set to "ERROR"

4。我使用BRE解析器来确定生成的"内部"解决方案的正确地图。 XML - 取决于它是否包含错误。  我使用CBR来查看邮件的实际内容，以查看是否有任何节点包含错误。 
如果他们这样做，我会返回一张地图，从内部格式转换为错误格式，否则，内部格式为最终成功格式。

4. I use the BRE resolver to determine the correct map for the resulting "internal" XML - depending on whether it contained errors or not.  I use CBR for this and look at the actual content of the message to see if any of the nodes contain errors.  If they do, I return a map to go from internal to error format, otherwise, internal to final success format.

5。基于上面执行的地图，我最终得到了一个"错误"。消息或"成功"消息消息。

5. Based on the map execute above, I end up with either an "error" message or a "success" message.

6。根据是错误消息还是成功消息，我使用BRE解析器来确定正确的终点信息（错误被赋予不同的文件名等），但最重要的是，成功的消息必须在$ b $中使用自定义管道b发送端口，因为它们将被写为CSV文件（而错误是XML）。

6. Depending upon whether it is an error or success message, I use the BRE resolver to determine the correct end point information (errors are given different filenames etc.), but most importantly, success messages MUST use a custom pipeline in the send port as they are to be written out as a CSV file (whilst errors are XML).

7. 我使用off ramp将消息发送到文件系统（基于步骤6中解决的终点信息）

7. I use the off ramp to send the message to the file system (based on the end point information resolved in step 6)

我的问题发生在第6步 ...并且是由于"成功"的事实。和"错误"邮件必须在发送端口中使用不同的管道。 如果在动态发送端口中我使用标准ESB管道，则这适用于"错误"。
消息（因为它们是标准XML），但是对于我的"成功消息"而言，这是失败的。因为管道不执行我的平面文件汇编程序。 如果我反过来这样做（在动态发送端口中使用我的自定义管道），那么它适用于"成功"。
但不是"错误"消息。

My problem occurs at step 6... and is due to the fact that "success" and "error" messages must use differing pipelines in the send port.  If in the dynamic send port I use the standard ESB pipeline, this works fine for the "error" messages (as they are standard XML), but this fails for my "success messages" as the pipeline does not execute my flat file assembler.  If I do it the other way round (use my custom pipeline in the dynamic send port), then it works for "success" but not "error" messages.

我已经尝试了一些方法来解决这个问题...

I have tried a few things to get around this...

a）查看ESB BRE词汇，看看我是否可以设置要在动态发送端口中执行的管道的名称（例如，我可以设置传输类型）。 这将是理想的，因为这将在步骤6中在运行时解决。 
这里没有喜悦，我看不到这个词汇项目。

a) looked in the ESB BRE vocabs to see if I can set the name of the pipeline to execute in the dynamic send port (in the same way I can set the transport type for example).  This would be ideal, as this would be resolved at runtime in step 6.  No joy here, I cannot see a vocab item for this.

b）尝试了两个动态发送端口（一个用于标准ESB管道的错误，一个用于成功平面文件管道），并设置发送端口过滤器以包括我正在处理的消息的消息类型（除了
3标准ESB过滤器）。 猜猜看，BTS.MessageType在最终消息中没有被提升，所以它也不起作用。

b) tried having two dynamic send ports (one for error with the standard ESB pipeline, one for success with the flat file pipeline), and setting the send port filter to include the Message Type of the message I am processing (in addition to the 3 standard ESB filters).  And guess what, BTS.MessageType is NOT promoted in the final message, so that did not work either.

c）尝试了b）上面的变化，其中DOES有效，但是非常笨重......有两个动态发送端口，带有3个ESB过滤器，然后使用"出站消息传输位置"。区分这两者。例如

c) Tried a variation on b) above which DOES work, but is very clunky... Have two dynamic send ports, with the 3 ESB filters, and then use the "Outbound Message Transport Location" to distinguish between the two. e.g.

过滤发送端口1 - 成功。

Filter for send port 1 - success.

Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName  ==  ESB101OneWaySend  And

   Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType  ==  Messaging 以及
   Microsoft.Practices.ESB.Itinerary .Schemas.ServiceState  == 待定 和

   BTS.OutboundTransportLocation  ==  C：\ Data\Dev\ESB101 Bits \BztFiles\101 \ DropOff\Valid_Journal_％MessageID％.xml

Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == ESB101OneWaySend And
  Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == Messaging And
  Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == Pending And
  BTS.OutboundTransportLocation == C:\Data\Dev\ESB101 Bits\BztFiles\101\DropOff\Valid_Journal_%MessageID%.xml

使用带有FF dissasembler的自定义管道

uses custom pipeline with FF dissasembler

过滤发送端口2 - 错误。

Filter for send port 2 - error.

Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName  ==  ESB101OneWaySend 以及
   Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType  ; == 消息 和

   Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState  == 待定 以及
                 ; BTS.OutboundTr ansportLocation  ==  C：\ Data \Dev \ ESB101 Bits \BztFiles \101 \DropOff\ERROR_Journal_％MessageID％.xml

Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == ESB101OneWaySend And
  Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == Messaging And
  Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == Pending And
  BTS.OutboundTransportLocation == C:\Data\Dev\ESB101 Bits\BztFiles\101\DropOff\ERROR_Journal_%MessageID%.xml

使用标准ESB发送管道

uses standard ESB send pipeline

虽然这是"在OutboundTransportLocation上过滤"确实有用，看起来很糟糕，并且将我的动态发送端口紧密耦合到消息的目标位置（性感和脆弱）。

Whilst this "filter on OutboundTransportLocation" does work, it seems horrible, and is tightly coupling my dynamic send port to the destination location of the message (natsy and brittle).

那么，我在这里缺少什么？ 或者我的方法对于我想要做的事情是完全错误的？

So, what am I missing here?  Or is my approach simply wrong for what I am trying to do?

我确实考虑过调用业务流程来执行自定义管道（如果消息成功并且需要转到CSV），并将结果消息返回给行程（这将从动态发送端口中删除管道问题）。 
但是我试图避免编排这种标准的消息传递方式。

I did consider calling an orchestration to execute the custom pipeline (if the message a success and needs to go to CSV), and returning the resulting message to the itinerary (which would remove the pipeline issue from the dynamic send port).  But I was trying to avoid orchestrations for what seems such a standard messaging style scenario.

最受欢迎的想法和评论。

Thoughts and comments most welcome.

谢谢，

Roy

 

 

推荐答案

Hello Roy，

Hello Roy,

您的问题属于付费支持类别，需要更多信息 - 深度支持。请访问以下链接，查看可以更好地满足您需求的各种付费支持选项。
http://support.microsoft.com/default。 aspx？id = fh; en-us; offerprophone

谢谢，

Belinda

这篇关于动态解析动态发送端口的自定义管道。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！