1

作業プロセスの一部として互いにメッセージを渡すアプリケーション システムがいくつかあります。トランザクションの整合性に関する技術的な制約により、アプリケーション データとメッセージ配信はすべて単一のメインフレーム DB2 データベースにコミットされます。メッセージは BizTalk サーバー (2006 R2) に直接渡されません。後で DB2 データベースからメッセージを引き出すのは BTS 次第です。

DB2 データベースのメッセージ キュー テーブルには、いくつかのフィールドがあります。キー フィールドは MESSAGE_DATA 列で、実際のメッセージです。それは 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_DATA に格納されている内部 XML コンテンツから来ています。

この単一レベルでは、マッパーは、2 つのスキーマを組み合わせるときに、MESSAGE_DATA 内のこの基礎となる XML スキーマを認識しません。おそらく、MESSAGET_DATA 要素をさらにドリルダウンして値の適切なマッピングを実行できる XPath Functoid がいくつかあるはずですが、これまで大規模な XML および XSLT アプリケーションを扱ったことがないため、このタスクの実行に役立つ利用可能な機能を確認できません。 .

以前にそのようなデータ抽出とマッピングを行った人はいますか?

アップデート。要求に応じて、MESSAGE_DATA 内の 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>
4

2 に答える 2

1

Chris の言うとおりです。あなたが実際に気にかけているのは、メッセージの内側の部分だけのようです。外側の部分は単なる封筒です。

そのため、受信パイプラインでエンベロープを取り除く逆アセンブラーを作成することをお勧めします (アクションが必要な場合は、エンベロープ全体をコンテキスト プロパティとして保持したり、個別のプロパティとして抽出したりできます)。それらの上に）、メッセージボックスに公開されるメッセージになる内部部分を抽出します。

これで、実際のメッセージが処理されますが、残りの送信ポートとサブスクライバー、およびエンベロープから必要な情報は、そのコンテキストを介して流れます。

これで、メッセージとそのプロパティに完全にアクセスできるようになりました。該当する場合は、このメッセージのスキーマを展開できます。スキーマには、いくつかの (単純なタイプの) ノードにすばやくアクセスできるようにする識別可能なプロパティがあります。または、xlang/s xpath を使用して情報を抽出することもできます。

埋め込まれたメッセージがエンベロープの要素内にある場合は、組み込みの XmlDisassemblyr を使用してこれらすべてを実行できます (スキーマを正しく展開し、それに応じてコンポーネントを構成するだけで済みます。これがどのように機能するかはわかりません)。属性に含まれるメッセージですが、おそらく試してみる価値があります。

最悪の場合、エンベロープを取り除き、組み込みの逆アセンブラーを呼び出して内部メッセージを処理するカスタム逆アセンブラーを作成することを考えていますが、それもあまり手間がかからないはずです。

于 2008-12-06T14:20:55.537 に答える
0

エンベロープ スキーマを調べて、内部メッセージを外部メッセージから「アンラップ」することをお勧めします。エンベロープは、受信パイプラインを移動するときに、エンベロープから内部メッセージのコンテキストにプロパティを昇格できると思います。内部メッセージは、独自のタイプのスキーマにマップする必要があります。その後、スキーマ タイプに基づいてルーティングまたは決定を行い、XPath を使用して必要なものを選択できます。これらすべてを試したわけではありませんが、これを行うための機能が存在することは確かです。

于 2008-12-05T04:15:11.003 に答える