次の方法で共有

アダプターのデザインに関するヒント

  • [アーティクル]

ここでは、アダプターをデザインする間にアダプターの開発者が習得したヒントについて説明します。

既定の構成として使用する場合はハンドラー プロパティを文字列にする

XSD で生成されたハンドラー プロパティ シートのプロパティを Location プロパティの既定値として使用するのは魅力的なようです。 Locationで値 が設定されていない場合、ランタイムはハンドラーで設定された値を自動的に使用するためです。 ところが、この方法の利便性を損なういくつかの問題点があります。

問題の原因は、ランタイムに対して提示される値がオーバーライドされるかどうかが不明であることです。 通常は、値に対して NULL の概念を定義しておき、その値に対してテストを実行します。 BizTalk Server で XSD ベースのプロパティ シートを使用するときの問題は、NULL は文字列でのみサポートされるということです。 この NULL テストを使用することによってアダプターに既定の設定値を指定し、アダプターの設定の種類を文字列型に制限しようとした場合も、ユーザー インターフェイスが不適切に表示される可能性があります。

XSD で生成されたプロパティ シートでは、プロパティを右クリックして NULL に戻すプロパティの設定のみがサポートされます。この時点で 、nullify? コンテキスト メニューが表示され、プロパティを NULL に設定できます。 プロパティが NULL であるかどうかについての視覚的なフィードバックはありません。

スキーマ生成ウィザードを実装する際の考慮事項

プログラマは、厳密に型指定されたオブジェクト モデルに逆らう形でコードを作成します。 コードで XML を操作するのは、最初のうちは作業しづらく、エラーの発生を招くことがあります。 ただし、コツや .NET Framework によって提供されているサポートを適切に使用することによって、劇的に簡単になることがあります。

文字列連結を使用して XML ドキュメントを作成しない

XML に関連する間違いのうち、最も不適切なものの 1 つが、文字列連結とメモリ内の print ステートメントから生成を試みることです。 この処理では、CPU の時間とメモリが大量に消費されます。 最も小さい XML スニペットが対象であっても、XmlWriter またはドキュメント オブジェクト モデル (DOM) のようなツールを使用する方が簡単です。 XmlWriter を使用している場合は、ライターがドキュメントの状態を喪失するため、生の書き込み機能を使用しないでください。

実行時は、DOM に関連するメモリの高消費量の問題があるため、XML DOM よりも XmlWriter を使用することをお勧めします。 ただし、構成時またはデザイン時には、ほとんどの場合、これは問題になりません。 DOM を使用することによって簡単に XPATH クエリを使用できるようになり、それが便利な追加ツールになる可能性があります。

XML ドキュメントのスケルトンをリソースとして定義する際の考慮事項

デザイン ツールから大きなサイズの XML ドキュメントを生成し、その生成したドキュメントが常に同じ基本的な構造に従っている場合、スケルトン XML ファイルの全体をプロジェクトのリソースとして配置し、編集が必要なときに変更できるようにすることを検討してください。

コードを DOM に読み込み、XPATH を使用して追加先とするノードを選択することによって、ドキュメントの骨組みに必要な肉付けを追加します。 この例では、Web サービス記述言語 (WSDL) ファイルを作成します。 ウィザードによって、スケルトンの WSDL ファイルがリソースに保存され、生成された XML スキーマ定義 (XSD) の子の部分が追加されます。 このウィザードでは selectNode と xpath を使用して、正しい親が検索されます。 これはユーザー インターフェイスのコードなので、パフォーマンスは問題にならず、結果として得られる実装は、無駄なく、堅牢で、保守が可能なものになります。

BizTalk パイプラインで処理手順を配置する際の考慮事項

一般的に、Microsoft でビルドされたアダプターは、メッセージ形式をベースにした処理をアダプターから BizTalk パイプラインに移動します。 たとえば、構造化されたものの XML ではないデータ ソースに対するアダプターがその一例です。

この例では、アダプターはデータだけを取得し、BizTalk パイプラインはそれを解析して XML で該当するものに変換するために使用されます。 利点は、パイプライン コンポーネント自体がアーキテクチャの再利用可能な部分になることです。

アダプターの動作を構成可能にする

MQSeries アダプター ベータ プログラムで得られた教訓の 1 つは、すべてのお客様が同じ動作に満足していたわけではないということでした。 これは、エラーの処理と順序付けについて考える場合に、特に当てはまります。 これに対する解決策は、アダプターの動作を構成可能にすることでした。 アダプターが順序付けをサポートするかどうか、エラーが保留キューに移動されるかどうか、またはエラーによってアダプターが処理を中止してアダプター自体が無効にされるかどうかを指定できます。 このような動作を構成可能にすると、同じ結果を得るために、BizTalk Server外部に複雑なオーケストレーションやスクリプトを記述する必要があるときに、顧客の生活を大幅に簡素化できます。

メッセージ キューとの関連付けのサポート

多くのメッセージ プラットフォームは、アプリケーション レベルの要求 - 応答シナリオに対応するため、メッセージ ヘッダーの関連付け ID の概念をサポートしています。 たとえば、MQSeries、MSMQ、SQL Service Broker などです。 外部メッセージング システムの要求 - 応答パターンを、BizTalk Server の送信 - 応答アダプターにマップするのは便利なように見えるかもしれません。 ところが、このような考え方は、トランザクションがアクティブな場所が原因で通用しません。 具体的には、外部メッセージング システムへの送信では、キューのもう一方の端でデータが表示される前にトランザクション コミットが必要です。 受信も別のトランザクションである必要があります。

BizTalk Server での解決策は次のようになります。

  • オーケストレーションで関連付けセットを使用します。

  • 2 つの個別のポートを構成します。1 つは送信用、1 つは受信用です

    単純な例では、アダプターによってメッセージに関連付けられている関連付け ID が、オーケストレーションによって指定されます。 これは、メッセージのコンテキスト プロパティとしてアダプターに渡されます。 より複雑なケースでは、このシナリオでは、外部メッセージング システムを呼び出して ID を割り当てます。 この場合は、応答メッセージを使用して送信ポートからオーケストレーションに渡すことができます。 この応答メッセージは、単に ID を戻すだけであり、実際のメッセージ応答ではありません。

Note

オーケストレーション エンジンには、メッセージに対する実際の応答が送信からの ID 応答よりも優先される可能性があるような競合状態があります。 この競合状態は、オーケストレーション自体によって処理する必要があります。