Biztalk 提取内部模式XML值以映射到编排的方法'；s入站架构_Biztalk_Biztalk2006r2

Biztalk 提取内部模式XML值以映射到编排的方法'；s入站架构

biztalk

Biztalk 提取内部模式XML值以映射到编排的方法'；s入站架构,biztalk,biztalk2006r2,Biztalk,Biztalk2006r2,有几个应用程序系统在工作过程中相互传递消息。由于事务完整性方面的技术限制，应用程序数据和消息传递都提交到单个大型机DB2数据库中。消息不会直接传递到BizTalk server（2006 R2）；稍后由BTS从DB2数据库中取出消息 DB2数据库中的消息队列表有几个字段。关键字段是消息\数据列-实际消息；它是XML内容本身。当使用DB2适配器从表中查询出记录时，传入的模式如下更正更新：DB2Message模式是基于属性的；我以前误认为它是基于元素的 <DB2Message MESSAGE

有几个应用程序系统在工作过程中相互传递消息。由于事务完整性方面的技术限制，应用程序数据和消息传递都提交到单个大型机DB2数据库中。消息不会直接传递到BizTalk server（2006 R2）；稍后由BTS从DB2数据库中取出消息

DB2数据库中的消息队列表有几个字段。关键字段是消息\数据列-实际消息；它是XML内容本身。当使用DB2适配器从表中查询出记录时，传入的模式如下

更正更新：DB2Message模式是基于属性的；我以前误认为它是基于元素的

<DB2Message MESSAGE_DATA="&lt;InternalXML&gt; ........ &lt;/InternalXML&gt;"
 MESSAGE_DATE="2008-1-1 00:00:00" MESSAGE_ID="GUID" TXN_ID="GUID" .... other attrib />

业务流程使用架构

<EAIMessage>
 <Header>
  <ServiceID>
  <MessageID>
  ....
  <Mode>
 </Header>
 <Body>
  <RawXML>
 </Body>
</EAIMessage>


....

编排将使用标题中的几个提升字段来做出路由和处理决策。问题是，这些头字段实际上来自存储在DB2Message的MESSAGE_数据中的内部XML内容

在这一级别上，当将两个模式放在一起时，映射程序不知道消息_数据中的这个不完整XML模式。可能会有一些XPath functoid可以进一步深入MESSAGET_数据元素以进行正确的值映射，但之前没有处理过大量的XML和XSLT应用程序，因此我无法看到可以帮助我执行此任务的可用功能

以前有人做过这样的数据提取和映射吗

更新。根据请求，在消息_数据中，内部XML可能如下所示

<Message>
    <Id>e86970f4-0455-4535-8e65-a06eb7aaef8a</Id>
    <SenderApp>999</SenderApp>
    <ReceiverApp>2000</ReceiverApp>
    <ServiceId>8798973454</ServiceId>
    <Mode>P</Mode>
    <MuxId></MuxId>
    <ExceptionCode></ExceptionCode>
    <ExceptionMessage></ExceptionMessage>
    <Body>
        <WorkItem xmlns="http://tempuri.org/WorkItem.xsd">
            <ServiceHeader xmlns="http://tempuri.org/Service.xsd">
                <ID_UPDATED_BY>username</ID_UPDATED_BY>
                <ID_HISTORY_REF>xxxxxxx</ID_HISTORY_REF>
                <SESSION_ID>sessionID</SESSION_ID>
                <DT_LAST_UPDATE>timestamp</DT_LAST_UPDATE>
                <TM_LAST_UPDATE>time</TM_LAST_UPDATE>
            </ServiceHeader>
        </WorkItem>
    </Body>
</Message>


e86970f4-0455-4535-8e65-a06eb7aaef8a
999
2000
8798973454
P
用户名
xxxxxxx
会话ID
时间戳
时间

我建议查看信封模式，从外部消息中“打开”内部消息。我相信信封可以在通过接收管道时将属性从信封提升到内部消息的上下文中。然后，内部消息必须映射到它自己类型的模式。然后，您将能够根据模式类型进行路由或决策，并使用XPath选择您需要的内容。我还没有尝试过所有这些东西，但我确信有这样的功能

克里斯是对的——似乎你真正关心的只是信息的内部，外部只是一个信封

因此，我建议您创建一个反汇编程序，在接收管道中，该反汇编程序将剥离信封（您可以将信封作为上下文属性保留其整体，和/或从中提取一些位作为单个属性，如果您需要对其进行操作），并提取内部部分，该部分将成为发布到消息框中的消息

现在，真正的消息是get处理的消息，但是其余的发送端口和任何订户，以及您从信封中需要的任何信息都会通过它的上下文进行传递

现在您可以完全访问消息及其属性；如果适用，您可以为此消息部署一个架构，该架构可以具有可区分的属性，从而使您能够快速访问某些（简单类型）节点。或者，您可以使用xlang/s xpath来提取信息

如果您的嵌入消息位于信封中的一个元素中，那么您当然可以使用内置的XmlDeformer来完成所有这一切（您只需要正确地部署模式并相应地配置组件；我不确定这对包含在属性中的消息的效果如何，但可能值得一试

最糟糕的情况是，您正在考虑编写一个自定义反汇编程序，该程序将剥离信封，然后调用内置反汇编程序来处理内部消息，但这也不应该太费力。

Chris是正确的-似乎您真正关心的只是消息的内部部分，外部部分只是一个信封

因此，我建议您在接收管道中创建一个反汇编程序，该反汇编程序将去掉信封（您可以将信封作为一个上下文属性整体保存，和/或从中提取一些位作为单个属性，如果您需要对其进行操作的话），并提取将成为消息发布到消息框中的消息的内部部分

现在，真正的消息是get处理的消息，但是其余的发送端口和任何订户，以及您从信封中需要的任何信息都会通过它的上下文进行传递

现在，您可以完全访问消息及其属性；如果适用，您可以为此消息部署一个架构，该架构可以具有可区分的属性，使您能够快速访问某些（简单类型）节点。或者，您可以使用xlang/s xpath提取信息

如果您的嵌入消息位于信封中的一个元素中，那么您当然可以使用内置的XmlDeformer来完成所有这一切（您只需要正确地部署模式并相应地配置组件；我不确定这对包含在属性中的消息的效果如何，但这可能值得一试