• [アーティクル]

この記事は機械翻訳されたものです。

BizTalk

BizTalk Server 2010 で EDI データをバッチ処理する (機械翻訳)

Mark Beckner

 

ExpandedElectronic データ交換 （EDI） キャパと­bilities Microsoft BizTalk Server 2010 で使用可能なより多くの会社が見て環境内で利用する方法。 EDI データのバッチ処理プラットフォームを提供することができる、最も重要な機能の一部ですが、混乱と実装が複雑にすることができます。 この資料で説明する手順を使用して、迅速かつ容易に、ソース データベースからデータを抽出し、マッピングといくつかのシナリオを使用してバッチ処理を実装する方法を学びます。 議論に含まれている FOR XML を使用してデータを取得するには、SQL アダプターの構成情報です。

ソリューションの概要

BizTalk Server 2010 内のバッチのデータを扱う非常に複雑にすることができますがあなたのアーキテクチャを考えるときにバッチ処理のさまざまな側面を処理するために、最高の場所を決定するとこの複雑さの多くは削除することができます。 バッチ処理の主なコンポーネントを理解するには、作成とそれぞれの構成をするつもりです。 BizTalk によって容易に使用できる形式のソース データを抽出するストアド プロシージャの作成を開始します — の場合、データをバッチ処理する方法には、さまざまなオプションを選択する形式。 次に、スキーマとデータをターゲットの EDI 形式にマッピングするためのオプションを作成するを見てみましょう。 最後に、データを作成して、ファイルに書き込まれるので、BizTalk パーティ アグリーメントでバッチ処理を設定します。 このソリューションを使用するには、BizTalk Server 2010、Visual Studio 2010 および SQL Server 2008 R2 を必要があります。

FOR XML と with XMLNAMESPACES を使用して SQL Server からデータを抽出します。

クエリのデータを SQL Server から BizTalk を使用する場合は強力なオプションがあります。 このオプションは、FOR XML は、データを特定の XML 形式で取得することができますです。 XML は BizTalk のすべてのデータに基づいて、財団です。 として XML を抽出すると、ストアド プロシージャからデータ消費オーケストレーション、マップは、さまざまな SQL アダプターを介して通信するとき一般に必要な複雑な成果物を生成することがなくすぐに準備することができます。 FOR XML アプローチはいくつかの大きな利点があります。

  • それには、SQL Server 開発者が BizTalk を習得することなくが、統合アーキテクチャの重要な部分を記述することができます。
  • 追加のフィールドは、結果に追加でき、BizTalk コンポーネントに比較的容易に組み込みます。
  • データを処理する効率的な方法は、それを開発する必要があるコンポーネントの数を減らします。
  • ターゲット スキーマ マッピングを簡略化するために一致するように設定できます。

SQL Server での XML の使用に関連するオプションの数です。 BizTalk の作成データを扱うときに使用する、最も適切な方法は、with XMLNAMESPACES を使用して、特定の名前空間を宣言して特に (としてに対して SQL Server 自動的にそれはあなたのために、自動モードを使用して名前をさせる)、パスのモードを使用すると、XML の書式を設定します。 With XMLNAMESPACES、XML を作成する SELECT ステートメントの前に追加することができます単純な句ですし、任意の種類の階層とは、適切な形式でデータをレンダリングするために必要がある属性と要素の組み合わせを作成できますパス モードを保証します。

図 1 の XML パスおよび with XMLNAMESPACES を使用して、ストアド プロシージャの例を示します。 まず、XML ドキュメントが XML をフォーマットと、名前空間を宣言しています。 XML の構造を構築この XML のなるを見るときに、最善のアプローチで BizTalk マップします。 ソース スキーマとターゲット スキーマの構造と一致することができる場合は、2 つの間のマッピングははるかに単純になります。 たとえば、ターゲットに従業員の構造をマップするのには、従業員の構造を作成する場合は、する従業員の階層 (名前、生年月日、アドレス、携帯電話などのソース一致対象従業員の階層。

図 1 のストアド プロシージャを FOR XML と with XMLNAMESPACES を使用して

    CREATE PROCEDURE [dbo].[GetData] AS
    BEGIN
     -- define the namespace and prefix
     WITH XMLNAMESPACES('http://sql.claims.extract' as "ns0")
     -- top level is set to NULL
     SELECT NULL
           ,(SELECT ClaimData.ClaimType As [ns0:ClaimType]
                 ,ClaimData.ClaimNo As [ns0:ClaimNo]
                 ,ClaimData.DateFrom As [ns0:DateFrom]
                 ,(SELECT first As [ns0:FName]
                         ,last As [ns0:LName]
                         ,birth As [ns0:BDate]
                  FROM Members
                  WHERE Members.ID = ClaimData.MemberID
                  FOR XML PATH('ns0:Member'), TYPE)
           FROM ClaimData 
         FOR XML PATH('ns0:Claim'), TYPE)
       FOR XML PATH('ns0:ClaimExtract'), TYPE
    END

データの書式設定に加え、ビジネス ルール、ストアド プロシージャの追加を検討します。 多くのロジックはこのレベルでは、ことが容易にソリューションを維持しての開発には追加することができます-コードを再コンパイルまたは複雑なテストの手順を実行する必要はありません。 単にストアド プロシージャを更新し、結果セットに適切なビジネス ルールが適用されていることをテストします。 多くの場合ビジネス ルールに biztalk ビジネス ルール エンジン (BRE) を通じて対処しようとしてではなく、ストアド プロシージャに組み込まれてすることができます。 強力な BizTalk アーキテクチャを作成する各段階で、最も適切なテクノロジーを使用することを確保することによって開始します。

データをプルするには、SQL アダプターを構成します。

XML を返すストアド プロシージャが今、次の手順はデータを取得する BizTalk Server を構成します。 これは、製品に付属の標準 SQL アダプターを使用して行うことができます。 開発者は、非常に面倒なことには、SQL アダプターの使用を見つけるかもしれない。 私の経験では通常、世代数の結果をさまざまなターゲット アイテムには、マッピングするために使用される、一般的に直感的な作業にも簡単に保守および拡張スキーマが必要です。 ただし、いくつかのケースで — 今見てつもり 1 のように-それは驚くほど簡単に使用できると素晴らしいサービスを提供します。

まっすぐストアド プロシージャから XML データを抽出するの場合、あるが、SQL アダプターを使用していくつかの優秀な利点。構成するのには、追加の BizTalk スキーマは必要なく、簡単、スケジュールで実行するように構成することができます。 一般に、それの XML データの抽出は便利ですが、Microsoft を使用してください。NET Framework クラスを使用して SQL サーバーと対話します。

ストアド プロシージャを呼び出す SQL アダプターを使用するには、新しい BizTalk 受信場所の作成を開始します。 受信場所の種類「SQL、「する必要がありますと、パイプラインは、標準の PassThruReceive パイプラインとして設定できます。 議論に値するいくつかのフィールドです。

  • ドキュメント ルート要素名この結果セットのコンテナー ノードです。 既に XML 結果セットをストアド プロシージャからの定義は、ルート要素がありますが、アダプター、追加ノードでラップされます。 これは、結果セットをエンベロープ スキーマを使用して個々 のドキュメントに分割する必要がある場合に便利です — がこれを行うにはすべてのソリューション必要があります。
  • ドキュメント ターゲット Namespace この名前空間は、スキーマで使用されます。 あなたは何を名前空間として、ストアド プロシージャ内で宣言したに似たようなことができます。
  • SQL コマンドを使用してストアド プロシージャを呼び出すに、EXEC コマンドです。 前述したストアド プロシージャの場合、この値は EXEC GetData でしょう。 簡単にパラメーターを追加することができます。 たとえば、特定の取引先およびレコードの特定の数の GetData を呼び出したい場合は、EXEC GetData 'TradingPartnerName'、'100' を入力できます。

関連付けられている受信ポートと受信場所を作成した後は、単純な送信ポート、受信ポートにサブスクライブし、XML ファイル ドロップに書き込みますを作成できます。 これを行うには、BTS を設定だけです。送信ポートのフィルターは、受信ポートの名前を ReceivePortName、SQL アダプターの作成。 すべて有効になっているし、実行して、示すような出力が表示されます図 2。

図 2 サンプルの結果の SQL アダプターのストアド プロシージャの呼び出し

<DataResultSet xmlns="http://SQLExtract.DataResultSet">
  <ns0:ClaimExtract xmlns:ns0="http://sql.claims.extract">
    <ns0:Claim xmlns:ns0="http://sql.claims.extract">
      <ns0:ClaimType>Institutional</ns0:ClaimType>
      <ns0:ClaimNo>ABC100</ns0:ClaimNo>
      <ns0:DateFrom>2012-01-01T00:00:00</ns0:DateFrom>
      <ns0:Member xmlns:ns0="http://sql.claims.extract">
        <ns0:FName>John</ns0:FName>
        <ns0:LName>Doe</ns0:LName>
        <ns0:BDate>1975-01-28T00:00:00</ns0:BDate>
      </ns0:Member>
    </ns0:Claim>
    <ns0:Claim xmlns:ns0="http://sql.claims.extract">
      <ns0:ClaimType>Institutional</ns0:ClaimType>
      <ns0:ClaimNo>XYZ200</ns0:ClaimNo>
      <ns0:DateFrom>2012-01-05T00:00:00</ns0:DateFrom>
      <ns0:Member xmlns:ns0="http://sql.claims.extract">
        <ns0:FName>Jane</ns0:FName>
        <ns0:LName>Doe</ns0:LName>
        <ns0:BDate>1976-10-08T00:00:00</ns0:BDate>
      </ns0:Member>
    </ns0:Claim>
  </ns0:ClaimExtract>
</DataResultSet>

クエリの結果から、スキーマの作成

BizTalk SQL アダプターで、ストアド プロシージャから取得した XML に基づく XSD の実際の作成は、ウィザードを使用して実現できます。 スキーマを作成するには、次の手順に従います。

  1. スキーマに追加し、追加を選択する、Visual Studio の BizTalk プロジェクトを右クリックして |生成された項目。
  2. 表示されたウィンドウでは、上のスキーマの生成] をクリックします。
  3. [スキーマの生成] ダイアログ ボックスで、「整形式 xml」のドキュメント タイプを設定します。既定では、これでは最初に利用可能なないことに注意してください。 エラーは、どのようなファイルをこの機能を有効にするために実行する必要がありますのアウトラインをポップアップ表示されます。
  4. 入力ファイルで示されている XML のインスタンスを設定図 3 、[ok] をクリックします。

The Generated XSD
図 3 は、生成される XSD

手順 2 の Xsd をプロジェクトに追加されます。 それらを使用する方法を決定することができ、必要に応じてそれらを 1 つの XSD に組み合わせることもできます。 トップレベルのスキーマの例を示します図 3。

マッピングとオプションのバッチ処理

今ソース データ状態に、EDI 形式にマップする必要があります。 ニーズを考えたこと形式とバッチ EDI する最善の方法に送信しようとしているドキュメントします。 その他このグループ内の 1 つのレコードが必要いくつかの取引を 1 つのセント ・ SE グループ内の複数のレコードを必要があります。 1 つのドキュメントまたは単一のセント ・ SE、内のレコードの合計数に制限がある可能性がありますや可能性があるバッチが作成および配信を取得するときの周りの要件。 837 (健康管理要求仕様) ドキュメント形式は、優秀な例を示します。 取引先など、最大 2,500 要求の各セント ・ SE グループ内に存在して、最大 20 の個別 ST SEs の 1 つのドキュメント内で存在している必要があります。 さまざまなパーティーの情報を交換している要件を評価する BizTalk を介してデータのパスを構成する最善の方法の決定に します。

実際の BizTalk マップと関連付けられているバッチ処理は、2 つの基本的なオプションは利用可能です。 1 つは、あなたのデータは単一のセント ・ SE グループでターゲット EDI スキーマをマップするある; 2 番目のソース内の複数のレコードを 1 つのセント ・ SE グループにマップすることです。 必要がありますどのルートに応じてエンベロープ スキーマをソース データを分割するには設定する必要があり、マッピングでは、バッチ構成のいくつかの違いがあるでしょう。

1 レコードずつ個別セント/SE では、ソース データが分割し、個々 のセント ・ SE グループ内の 1 つのレコードとしてバッチ処理のシナリオを見て開始します。 示すように、サンプル ソース データ図 3 2 つの主張があります。 目標は (<ns0:Claim>) の個別の要求をターゲットの 837 スキーマに個別にマッピングすることができますそれらを分割することです。 BizTalk で到着したマップとは、データ バッチ処理することができます。 データを分割するには、エンベロープ スキーマを作成する必要があります。

  • エンベロープ プロパティ スキーマに「はい」に設定
  • ボディ XPath 要求ノードを含むノードをドキュメントのルートの設定-この場合、ClaimExtract ノード。
  • エンベロープ スキーマを展開します。 ファイル受信実装、既定の XMLReceive パイプラインを持つ場所で受信した瞬間はそれを使用して分割されます。 エンベロープ スキーマを任意の場所を参照する必要はありません。
  • 分割するには、ドキュメントを受信している受信ポートに購読するのには、送信ポートを設定すると、送信ポートは個々 の要求の XML ファイルを記述します。 これらをマッピングのソースとしてターゲット EDI スキーマを使用してできます。 送信ポートは、EDI トランザクション ソースがあります。

この時点ではファイル ディレクトリに積み重ね、多くの個々 の EDI ドキュメントです。 今、2 番目の受信場所を設定することができます/­は、バッチとして次のように送信ポートの組み合わせ。

  • あなたの受信場所の受信パイプライン EdiReceive に設定します。 それだけで最初の受信/送信コンボを書かれた個々 の EDI ドキュメントを選択します。
  • 送信ポートが、フィルターの設定図 4。 注意、EDI。BatchName と EDI。DestinationPartyName の情報は、次の手順で構成される党に設定されます。 EDISend パイプラインとして指定されたこの送信ポートは、ファイルをドロップする設定することができます — 出力はバッチのデータになります。

Filters on the Batching Send Port
図 4 のフィルター、バッチの送信ポートに

  • 新しい BizTalk パーティおよびバッチのドキュメントを受信する取引先とのデータ交換を表す契約を作成します。 構成する、主要なフィールドです。
    • [識別子] タブで、適切な値を送信者と受信者の Id を設定します。 DestinationPartyName もので、送信ポートのフィルターを設定と一致する必要があります。
    • ローカル ホストの設定と封筒タブには、処理している特定の EDI ドキュメントのプロパティを設定します。
    • バッチ構成タブには、次のプロパティを設定します。
      • バッチ名前何に、送信ポートのフィルターの設定に設定します。
      • バッチ フィルターに 2 つのプロパティを設定します。
        • BTS。ReceivePortName = [の名前をここでは、個々 の EDI ドキュメントで来ているポートを受信]
        • EDI。ST01 ！ 997 =
      • [リリース] オプションを設定します。 これは最も可能性の高いベースとなるスケジュールのいずれか (、最後の 24 時間以上が並んでいる複数のドキュメントを提供) または合計数 (2,500 アイテムの合計がある場合は、このバッチ キューに送信)。 「トランザクションの最大数を設定」プロパティを解放する場合は、ドロップ ダウン リストにグループを設定します。
      • プロパティが設定されている場合、バッチ処理を有効に開始をクリックします。 バッチが完全に開始される前に数分をかかることができます。 「バッチ処理アクティブです」メッセージが表示されるまで [更新] ボタンをクリックしますします。 (この BizTalk グループ ハブ レポートの実行インスタンス経由で見ることができる) BizTalk で実行、バッチ オーケストレーションのインスタンスする必要があります。 このオーケストレーションを BizTalk で EDI コンポーネントがインストールされている BizTalk EDI アプリケーションの一部です-これは何かを記述する必要があるではないです。
    • すべての設定を保存するには、[ok] をクリックします。

すべて構成、参加、開始有効にされると、BizTalk ホスト インスタンスを再起動します。 これすべては記憶に新しいですようになります。 次に、個々 のセント ・ SE ドキュメントを受信場所にドロップし、(2,500 の個々 のドキュメントをドロップする必要があり、たとえば、2,500 のトランザクション セットの数として指定する場合) のリリース メカニズムをトリガーすると、バッチが生成されます。

多くレコードごと個別セント/見て SE、次のシナリオ個々 のセント ・ SE グループに複数のレコードのマッピングです。 表示サンプル ソース データ、 図 3 2 つの主張があります。 新たな目標が、個別の要求 (、<ns0:Claim> を取ること ルート ノードは 1 つのクレームのです)、それらの両方を 1 つのターゲット 837 スキーマにマップします。 マップとは、データか、1 つのドキュメントを 1 つセント月 SE、として配信することができます。 またはそれは前の例のように複数 ST ・ SEs、それぞれの主張の複数のレコードを文書にバッチ処理できます。

開始あなたは書きました、ストアド プロシージャを変更すると (を参照してください図 1)。 今、単にそれをもたらすすべてのレコードで、データベースをバックアップします。 戻るレコードの数を制限するパラメーターを追加する必要があります。 たとえば、5,000 レコードを 1 つのセント ・ SE に配置することができるようにする場合は、ソース データベースから一度にのみ 5,000 レコードを取得する必要があります。 「取引パートナー何が戻って来るさらに制限する ID」など追加パラメーターを追加し、、ストアド プロシージャ複数の当事者間で再利用可能な確認しますできます。 追加後は、追加のパラメーターを渡す、SQL アダプターの設定を変更できます。 最終的に、定期的なサイクル (毎時間、たとえば) を実行するには、SQL アダプターを設定する必要がありますたびに 5,000 レコードを抽出します。

次に、あなたのマッピングを変更します。 ターゲットの EDI スキーマをソースの場所に今置くどんなマッピング、ループを変更する必要があります。 837 の場合は、たとえば、ループ functoid、<ns0:Claim>、ソースを設定するよ (スキーマから図 3） と、TS837_2000A_Loop は、ターゲットの主張の最上位レベルの構成されているターゲット。

今、あなたのマッピングが完了したので、BizTalk パーティ内かバッチを設定するかどうかを決めることができます。 単に、1 つのセント ・ se 1 つのドキュメントで、5,000 の主張を提供する場合は、あなたの仕事をされる-は、送信ポートを設定し、EDISend パイプラインを使用して、データの船。 バッチ処理を設定する場合は、構成をこの資料の前半で働いたものと同じになります。

バッチ リリース オプション

あなたは、バッチをリリースする使用可能なオプションがあります。 前述、2 つとして最も一般的なは特定のスケジュールでは、バッチをリリースして、特定のトランザクション数に達したときに解放します。 スケジューラでは、1 時間ごと、毎日、毎週の構成のさまざまなことができます。 たとえば、どのようなレコードを毎日深夜にかかわらず数は、キューが提供する必要がある場合毎日スケジュールは、真夜中にリリースするバッチを構成します。 簡単に、特定のトランザクションの数に基づいて、バッチをリリースするためのオプションが構成されている — だけ数を指定します。 指定したインターチェンジ内の文字数と、外部リリースのトリガー リリースに追加バッチ処理オプションが含まれます。

外部リリースのトリガーは、メッセージ ボックスにドロップ コントロール メッセージを使用してトリガーすることができます。

偉大な簡素化

Biztalk バッチ プロセスを作成すると、あなたは、できるだけ単純なものを構築しているを確認してください。 BizTalk ソリューションの多くは、過剰なオーケストレーション、スキーマ、参照される Dll とその他のアイテムによって負担です。 開発者はしばしば彼らはユニークな状況が感じるものを処理するために、カスタムのバッチ処理オーケストレーションを作成する必要がありますを決定します。 常に、ソリューションの長期的な可能性に焦点を当てます。 開発者することができます何をしていた今見てから 6 ヶ月とそれを使用する方法を理解するか。 一般的に、BizTalk からデータを抽出し、オーケストレーションのいずれか 1 つまたはないでのさまざまな取引先に提供するためのプロセスを構築することができます 1 つのスキーマをソース データをターゲット データと 1 団体あたりのマップを表す 1 つのスキーマを表します。 これより多くの部品を作成する場合、ステップを取り戻し、ソリューションを reanalyze します。 可能性が高いいくつかの偉大な簡素化を行うことができることを発見します。

Mark Beckner Inotek コンサルティング グループ LLC の創設者である (inotekgroup.com)。彼は BizTalk、SharePoint、Dynamics CRM および一般的なを含む、Microsoft スタックで動作します。NET Framework 開発。

この記事のレビュー、技術スタッフに感謝： Karthik Bharathy