メッセージの考慮事項
BizTalk Serverでは、メッセージの送信、受信、変換、および処理のための広範な機能セットが提供されます。 これらには、次のような機能があります。
HTTP、SMTP、FTP/FTPS、WCF などの複数の業界標準トランスポートを使用してメッセージを送受信する機能。 メッセージの送受信に関するトランスポート レベルのサポートは、BizTalk Server アダプターを使用して実現されます。 BizTalk Server メッセージ処理とさまざまな "基幹業務" (LOB) アプリケーションの統合は、BizTalk Accelerator for HIPAA、BizTalk Accelerator for SWIFT、BizTalk SAP アダプターなど、使用可能な多くのBizTalk Server アクセラレータまたはアダプターのいずれかを使用して実現されます。 これらのアクセラレータとアダプターは業界標準に準拠しており、特定の業界標準に準拠するシステムとのBizTalk Serverの簡単な統合に対応します。
プレーン テキスト、XML、バイナリなどの複数のメッセージ形式を処理する機能。 この機能は、広範な取引先とのBizTalk Serverの統合を提供するために重要です。
メッセージ変換またはドキュメント マッピングのサポート。 マッピングは、異なるスキーマ間のデータ変換に対応します。 たとえば、マッピングを使用して、受信した顧客の発注書の内容を、顧客に返送する出荷通知を含むレシートに変換できます。
BizTalk Server オーケストレーションは、時間、組織、アプリケーション、およびユーザーにまたがるビジネス プロセスを作成するための機能を提供します。 BizTalk Serverは、オーケストレーション Designerグラフィカル インターフェイスを提供し、トランザクションのサポート (従来の "アトミック" MSDTC 型と長時間実行の両方)、例外処理、デバッグ、追跡、および外部コードの呼び出しの拡張性を含むビジネス プロセスを開発します。
Note
BizTalk Serverでオーケストレーションを使用する場合に従うベスト プラクティスについては、「オーケストレーションパフォーマンスの最適化」を参照してください。 オーケストレーションDesignerの使用に関する詳細については、BizTalk Serverドキュメントの「オーケストレーションDesignerを使用したオーケストレーションの作成(https://go.microsoft.com/fwlink/?LinkId=158997)」を参照してください。
このトピックの残りの部分では、BizTalk Server環境で処理されるメッセージのサイズ、複雑さ、および配布プロファイルに関連するパフォーマンスに関する考慮事項について説明します。
メッセージ サイズに関する考慮事項
BizTalk Serverではメッセージ サイズに制限はありませんが、実際的な制限と依存関係では、メッセージのサイズを最小限に抑える必要がある場合があります。大きなメッセージには、より多くの処理リソースが必要になるためです。 メッセージ サイズが大きくなると、全体的なスループット (1 秒あたりに処理されるメッセージ) が減少します。 シナリオを設計し、容量を計画する場合は、平均メッセージ サイズ、メッセージの種類、およびプロセスBizTalk Serverメッセージ数を考慮してください。 不必要に長い属性とタグ名を使用しないでください。可能な場合は、長さを 50 文字以下にしてください。 たとえば、メッセージ サイズが 1 バイトの場合は、200 文字のタグ名を使用しないでください。
受信したメッセージのメモリ内サイズが、大きなメッセージ フラグメント サイズに指定されたバイト数を超える場合 (BizTalk Server管理コンソールの BizTalk グループの [グループ のプロパティ] ページで構成できます)、メッセージは指定したサイズのフラグメントに分割されます。 さらに、フラグメントは、次のように Microsoft 分散トランザクション コーディネーター (MSDTC) トランザクションのコンテキストでメッセージ ボックスに書き込まれます。
受信メッセージが既存の MSDTC トランザクションのコンテキストで発行されている場合、このトランザクションはメッセージ フラグメントを BizTalk MessageBox データベースに書き込むときに使用されます。 たとえば、受信メッセージがトランザクションを要求するように構成されたトランザクション アダプターによって発行されている場合、メッセージ フラグメントを MessageBox データベースに書き込むときに既存のトランザクションが使用されます。
受信メッセージが既存の MSDTC トランザクションのコンテキストで発行されていない場合は、メッセージ フラグメントを MessageBox データベースに書き込む新しい MSDTC トランザクションが作成されます。 このシナリオでは、次の考慮事項が適用されます。
[大きなメッセージ フラグメント サイズ] の値を増やして、大きなメッセージがフラグメント化される頻度を減らし、関連する MSDTC トランザクションを作成する頻度を減らします。 MSDTC トランザクションを使いすぎるとパフォーマンスの観点で無駄が多いため、この操作を実行する必要があります。 この値を大きくすると使用できるメモリの量も増える可能性があるので注意してください。
メッセージ ボックスにメッセージを書き込むのに許容される最大 MSDTC トランザクション タイムアウトが 60 分を超える場合、トランザクションはタイムアウトし、エラーが発生し、メッセージの書き込みの試行は失敗し、ロールバックされます。 非常に大きなメッセージを処理するときにこの問題を回避するには、 大きなメッセージ フラグメント サイズ の値を十分に大きくする必要があります。 使用できるメモリの量に応じて、この値を最大値 1000000 バイトに設定する必要があります。
メッセージの各フラグメントは、メッセージ ボックス データベースに対して 1 つ以上の SQL Server データベース ロックを作成します。 ロックの数が数十万を超えると、SQL Serverが "ロック解除" エラーを生成する可能性があります。 この問題が発生した場合は、[大きいメッセージ フラグメント サイズ] の値を増やしてフラグメントの数を減らすか (MessageBox データベースに対して行われるSQL Serverデータベース ロックの数を減らす)、または 64 ビット バージョンのSQL Serverに MessageBox データベースを格納することを検討してください。 使用可能なロックの数は、64 ビット バージョンのSQL Serverでは、32 ビット バージョンのSQL Serverよりも大幅に多くなります。 次の式を使用すると、MessageBox データベースが 32 ビット バージョンのSQL Serverに格納されている場合に、インターチェンジあたりのメッセージの最大数を見積もることができます。
200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)
大きなメッセージを処理するためのガイドラインなど、大きなメッセージBizTalk Server処理する方法の詳細については、「大きなメッセージを処理BizTalk Server方法 (https://go.microsoft.com/fwlink/?LinkID=154680)」を参照してください。
メッセージの種類に関する考慮事項
メッセージは、XML ファイルまたはフラット ファイルの 2 つの主な形式のいずれかでBizTalk Serverに受信されます。 XML およびフラット ファイル メッセージのリソース要件が異なるため、メッセージの種類は常にメッセージ配布プロファイルに組み込む必要があります。
XML ファイルBizTalk Serverがパススルー ルーティング以外のメッセージに対して処理を実行するには、メッセージが XML ファイル形式である必要があります。
フラット ファイルフラット ファイルは、パススルー ルーティング以外の処理を実行BizTalk Server前に XML 形式に解析する必要があります。 XML ファイルでフラット ファイルを解析すると、ファイルのサイズが非常に大きくなる可能性があります。 フラット ファイルには、データに関する説明情報を持つ XML タグが含まれません。 一方、XML ファイルは、説明的な XML タグにすべてのデータを格納します。 一部のシナリオでは、ファイルの XML タグに含まれる記述データの量に応じて、解析によってフラット ファイルのサイズが 10 倍以上増加する可能性があります。
XML ドキュメント内の単一の CDATA セクション ノードにラップされたフラット ファイル ドキュメントこの種類のドキュメントは XML とフラット ファイルの両方の組み合わせであり、多くの場合、メモリ負荷が高くなります。これは、ラップされたフラット ファイル ドキュメント全体BizTalk Server処理する前にメモリに読み込む必要があるためです。
オーバーロードに関する考慮事項
ほとんどのBizTalk Serverアプリケーションは、特定の一定の速度でメッセージを受信しません。 通常、メッセージ処理はピークと谷の影響を受けます。 たとえば、オンライン バンキング アプリケーションでは、大量のメッセージを最初に朝、次に日中、1 日の終わりに処理する場合があります。 BizTalk Serverソリューションをテストして、これらのオーバーロード シナリオを確実に処理できるようにする必要があります。 BizTalk Server ソリューションがオーバーロード シナリオにどの程度適切に対処できるかを判断するには、BizTalk Server ソリューションの最大持続可能なスループット (MST) を決定する必要があります。 MST は、運用環境でシステムが無期限に処理できるメッセージ トラフィックの最大負荷です。 MST の詳細については、「持続的なパフォーマンスの計画 (https://go.microsoft.com/fwlink/?LinkID=158065)」および「持続可能なパフォーマンスとは」を参照してください。(https://go.microsoft.com/fwlink/?LinkID=132304) BizTalk Serverドキュメントに記載されています。
スキーマの複雑さ
メッセージ解析 (特にフラット ファイル解析) のスループットは、スキーマの複雑さの影響を受けます。 スキーマの複雑さが増すにつれて、全体的なパフォーマンスが低下します。 スキーマを設計するときは、ノード名の長さを減らし、昇格されたプロパティをスキーマの先頭に移動します。 これにより、取得時間が短縮され、パフォーマンスが向上します。
マップの複雑さ
マップの複雑さに応じて、マップ変換はリソースを大量に消費する可能性があります。 マップの複雑さが増すにつれて、全体的なパフォーマンスが低下します。 全体的なパフォーマンスを向上させるには、マップで使用されるリンクと Functoid の数を最小限に抑えます。特に、DB Lookup Functoid などの外部リソースを呼び出す Functoid。
フラット ファイルの解析に関する考慮事項
フラット ファイル解析のパフォーマンスに最も大きい影響を与える 2 つの要因は、ファイル サイズとスキーマの複雑さです。 あいまいなスキーマは、多くの省略可能なフィールドを含むスキーマです。 大きなファイル サイズを使用する場合、多くの省略可能なフィールドを持つスキーマでは、大きなファイルがスキーマの異なるブランチと一致する可能性があるため、パフォーマンスが低下する可能性があります。 スキーマの複雑さは、大きなファイルよりも小さいファイルに与える影響が少なくなります。