BizTalk Server には、メッセージの送信、受信、変換、および処理のための広範な機能セットが用意されています。 これらには、次のような機能があります。
HTTP、SMTP、FTP/FTPS、WCF などの複数の業界標準トランスポートを使用してメッセージを送受信する機能。 メッセージの送受信に関するトランスポート レベルのサポートは、BizTalk Server アダプターを使用して実現されます。 BizTalk Server メッセージ処理をさまざまな "基幹業務" (LOB) アプリケーションと統合するには、BizTalk Server アクセラレータまたはアダプター (BizTalk Accelerator for HIPAA、BizTalk Accelerator for SWIFT、BizTalk SAP アダプターなど) のいずれかを使用します。 これらのアクセラレータとアダプターは業界標準に準拠しており、BizTalk Server と特定の業界標準に準拠したシステムとの簡単な統合に対応します。
プレーン テキスト、XML、バイナリなどの複数のメッセージ形式を処理する機能。 この機能は、BizTalk Server と広範な取引先との統合を実現するために不可欠です。
メッセージ変換またはドキュメント マッピングのサポート。 マッピングは、異なるスキーマ間のデータ変換に対応します。 たとえば、マッピングを使用して、受け取った顧客の発注書の内容を、顧客に返送する出荷通知を含むレシートに変換できます。
BizTalk Server オーケストレーションは、時間、組織、アプリケーション、およびユーザーにまたがるビジネス プロセスを作成するための機能を提供します。 BizTalk Server には、トランザクションのサポート (従来の "アトミック" MSDTC の種類と実行時間の長い両方)、例外処理、デバッグ、追跡、および外部コードの呼び出しの拡張性を含むビジネス プロセスを開発するためのオーケストレーション デザイナーのグラフィカル インターフェイスが用意されています。
注
BizTalk Server で オーケストレーションを 使用する場合のベスト プラクティスに関するガイダンスについては、「オーケストレーションパフォーマンスの最適化」を参照してください。 オーケストレーション デザイナーの使用方法の詳細については、BizTalk Server ドキュメントの 「オーケストレーション デザイナー (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 分) より長い時間がかかる場合、トランザクションはタイムアウトし、エラーが発生し、メッセージの書き込み試行は失敗し、ロールバックされます。 非常に大きなメッセージを処理するときにこの問題を回避するには、大きなメッセージ フラグメント サイズの値を十分に増やす必要があります。 使用可能なメモリに応じて、この値を最大値の 10000000 バイトまで増やす必要があります。
メッセージ内の各メッセージ フラグメントは、メッセージ ボックス データベースに対して 1 つ以上の SQL Server データベース ロックを作成します。 ロックの数が数十万を超えると、SQL Server で "ロック解除" エラーが生成される可能性があります。 この問題が発生した場合は、[ 大きいメッセージ フラグメント サイズ ] の値を増やしてフラグメントの数を減らすか (MessageBox データベースに対して行われる SQL Server データベース ロックの数を減らす)、または 64 ビット バージョンの SQL Server に MessageBox データベースを格納することを検討します。 使用可能なロックの数は、64 ビット バージョンの SQL Server では、32 ビット バージョンの SQL Server よりも大幅に多くなります。 次の式を使用すると、メッセージ ボックス データベースが 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 の詳細については、BizTalk Server のドキュメント内の「持続的なパフォーマンスの計画 (https://go.microsoft.com/fwlink/?LinkID=158065)」および「持続可能なパフォーマンスとは (https://go.microsoft.com/fwlink/?LinkID=132304)」を参照してください。
スキーマの複雑さ
メッセージ解析のスループット (特にフラット ファイル解析) は、スキーマの複雑さの影響を受けます。 スキーマの複雑さが増すにつれて、全体的なパフォーマンスが低下します。 スキーマを設計するときは、ノード名の長さを減らし、昇格されたプロパティをスキーマの先頭に移動します。 これにより、取得時間が短縮され、パフォーマンスが向上します。
マップの複雑さ
マップの複雑さによっては、マップ変換がリソースを大量に消費する場合があります。 マップの複雑さが増すにつれて、全体的なパフォーマンスが低下します。 全体的なパフォーマンスを向上させるには、マップで使用されるリンクと Functoid の数を最小限に抑えます。特に、DB 参照 Functoid などの外部リソースを呼び出す Functoid。
フラットファイルを解析する際の考慮点
フラット ファイル解析のパフォーマンスに最も大きく影響する 2 つの要因は、ファイル サイズとスキーマの複雑さです。 あいまいなスキーマは、多くの省略可能なフィールドを含むスキーマです。 大きなファイル サイズを使用する場合、オプションフィールドが多いスキーマでは、大きなファイルがスキーマの異なるブランチと一致する可能性があるため、パフォーマンスが低下する可能性があります。 スキーマの複雑さは、サイズの大きいファイルよりも小さいファイルに与える影響が少なくなります。