オーケストレーションのパフォーマンスの最適化

2023-07-21

このトピックでは、BizTalk Server ソリューションでオーケストレーションを使用するためのベストプラクティスについて説明します。これには、次の推奨事項が含まれます。

オーケストレーションを使用する BizTalk Server ソリューションの待機時間の短縮
- メッセージのみのパターンにおけるオーケストレーションを除去する
- オーケストレーションからのインライン送信の利用
- オーケストレーション永続化ポイントの最小化
オーケストレーションのネスト
オーケストレーションの設計パターン
オーケストレーション例外処理ブロック

低待機時間のシナリオに合わせてオーケストレーションを最適化するための推奨事項

オーケストレーションを使用する BizTalk Server ソリューションの待機時間を短縮するには、次の手法を使用できます。

メッセージング専用のパターンに対するオーケストレーションを排除する

可能であれば、オーケストレーションの使用を最小限に抑えて全体的なスループットを向上させ、ビジネスプロセスの待機時間を短縮します。実行時間の長いトランザクションを実行する必要がなく、要求ごとに複数のシステムを呼び出す必要がない場合は、オーケストレーションを排除し、ビジネスロジックを受信ポートと送信ポートに移動して BizTalkMsgBoxDb へのラウンドトリップの合計量を減らし、データベースアクセスによる待機時間を短縮することを検討してください。この場合は、カスタムパイプラインを実装し、以前にオーケストレーションから呼び出されたヘルパークラスを再利用します。オーケストレーションは、Scatter and GatherやConvoyなどの設計パターンを実装するために厳密に必要な場合にのみ使用します。オーケストレーションデザインパターンの詳細については、BizTalk Server ドキュメントの「オーケストレーションでのデザインパターンの実装 (https://go.microsoft.com/fwlink/?LinkId=140042)」を参照してください。

オーケストレーションからのインライン送信を使用して待機時間の短いシナリオに対応する

可能な限り、オーケストレーションの使用を最小限に抑え、メッセージングのみのパターンを優先して全体的なスループットを向上させ、ビジネスプロセスの待機時間を短縮します。実行時間の長いトランザクションが不要で、ビジネスロジックで複数のシステムを呼び出す必要がない場合は、ポートを受信して送信するビジネスロジックを移動し、オーケストレーションの使用を排除することを検討してください。この方法は、カスタムパイプラインを使用して実装でき、以前にオーケストレーションから呼び出されたヘルパークラスを再利用します。待機時間の短いシナリオでパフォーマンスを向上させるには、次のいずれかの方法を採用します。

不要なオーケストレーションを排除し、メッセージングのみのパターンを採用して、BizTalk MessageBox データベースへのラウンドトリップの合計量を減らします。インライン送信は BizTalk メッセージングエンジンと関連するオーバーヘッドをバイパスするため、この方法では待機時間が短くなります。オーケストレーションインライン送信機能は、BizTalk Server 2006 以降で提供されています。
オーケストレーション内で、物理ポートにバインドされている論理ポートを排除し、その場所でインライン送信を使用します。たとえば、インライン送信を使用して、ダウンストリーム Web サービスを呼び出す WCF プロキシクラスのインスタンスを作成したり、SQL Server データベースにアクセスするための ADO.NET コンポーネントを作成したりできます。次の図では、オーケストレーションがビジネスコンポーネントをインスタンス化するときにインライン送信が実行されます。このコンポーネントは、内部的に WCF プロキシオブジェクトを使用してダウンストリーム Web サービスを直接呼び出します。

注

オーケストレーションからのインライン送信を使用すると待機時間が大幅に短縮されますが、この方法には制限があります。インライン送信は BizTalk メッセージングエンジンをバイパスするため、メッセージングエンジンに付属する次の機能は使用できません。

トランザクションパイプライン
- 回復可能なパイプライン
- BAM インターセプター API を呼び出すパイプライン
- BizTalk Server アダプターのサポート
- バッチ処理
- 再試行
- 関連付けセットの初期化
- 宣言型の構成
- 二次輸送
- トラッキング
- BAM の宣言的な使用

オーケストレーション内から実行できないパイプラインの種類の詳細については、BizTalk Server 2010 ドキュメントのトピック「式を使用してパイプラインを実行する方法 (https://go.microsoft.com/fwlink/?LinkId=158008)」の「制限」セクションを参照してください。

永続化ポイントの数を減らすことでオーケストレーションの待機時間を最適化する (可能な場合)

オーケストレーションスコープは、補正またはスコープタイムアウトを使用する場合にのみ、"実行時間の長いトランザクション" としてマークする必要があります。実行時間の長いトランザクションスコープでは、スコープの最後に追加の永続化ポイントが発生するため、補正やスコープのタイムアウトを使用する必要がない場合は避ける必要があります。アトミックスコープでは、スコープの末尾に永続化ポイントが発生しますが、アトミックスコープ内で永続化ポイントが発生することも保証されません。このスコープ内では永続化が行われないという特性は、永続化ポイントをバッチ処理する際に（たとえば、複数回送信する場合など）、有用に活用できることがあります。ただし、一般に、可能であればアトミックスコープを回避することをお勧めします。オーケストレーションエンジンは、さまざまな時点で実行中のオーケストレーションインスタンスの状態全体を永続的ストレージに保存し、インスタンスを後でメモリに復元して完了まで実行できるようにします。 オーケストレーション内の永続化ポイントの数は、オーケストレーションを通過するメッセージの待機時間に影響を与える重要な要因の 1 つです。エンジンが永続化ポイントに達するたびに、実行中のオーケストレーションの内部状態がシリアル化され、MessageBox に保存され、この操作には待機時間コストが発生します。内部状態のシリアル化には、オーケストレーションでインスタンス化され、まだ解放されていないすべてのメッセージと変数が含まれます。メッセージと変数が大きいほど、これらの数が多いほど、オーケストレーションの内部状態を保持するのに時間がかかります。永続化ポイントの数が多すぎると、パフォーマンスが大幅に低下する可能性があります。このため、トランザクションスコープと送信図形の数を減らすことで、オーケストレーションから不要な永続化ポイントを排除することをお勧めします。このアプローチにより、オーケストレーションの退避やリハイドレーションによって発生するメッセージボックスの競争を軽減し、全体的なスケーラビリティを向上させ、オーケストレーションの遅延を短縮することができます。もう 1 つの推奨事項は、オーケストレーションの内部状態を常にできるだけ小さくすることです。この手法により、永続化ポイントの場合にオーケストレーションの内部状態をシリアル化、永続化、および復元する XLANG エンジンが費やす時間を大幅に短縮できます。これを実現する 1 つの方法は、可能な限り遅れて変数とメッセージを作成し、できるだけ早く解放することです。たとえば、オーケストレーション内に非トランザクションスコープを導入し、最上位レベルで宣言するのではなく、これらの内部スコープ内で変数とメッセージを宣言します。オーケストレーションの永続化ポイントの最小化の詳細については、BizTalk Server 2010 ドキュメントの次のトピックを参照してください。

昇格されたプロパティを使用してオーケストレーションからメッセージタグまたは属性にアクセスするためのガイドライン

プロパティを昇格する必要がある場合は、メッセージのルーティング、フィルター、およびメッセージの関連付けに使用されるプロパティのみを昇格します。各プロパティの昇格には、逆アセンブラーコンポーネント (XML、フラット、カスタム) がドキュメントの種類を認識し、ドキュメントの種類を定義する XSD に含まれる相対注釈から XPath 式を使用してメッセージからデータを取得する必要があります。さらに、メッセージエージェントがメッセージボックスデータベースにメッセージを発行するときに、各プロパティの昇格によって、bts_InsertProperty ストアドプロシージャが個別に呼び出されます。オーケストレーションが XML ドキュメントに含まれる特定の要素または属性にアクセスする必要がある場合は、次のいずれかの手法を使用します。

書き込まれたプロパティと昇格されたプロパティの数を減らし、厳密に必要のないプロパティを排除します。
不要な識別フィールドを削除します。識別フィールドは書き込まれたコンテキストプロパティであり、名前がデータの取得に使用される XPath 式と等しいため、大きなスペースを簡単に占有できます。識別プロパティは、ドキュメントの種類を定義する XSD の注釈として定義されます。逆アセンブラーコンポーネントは、昇格されたプロパティに採用されているのと同じアプローチを使用し、識別フィールドを定義する XPath 式を使用して受信ドキュメント内で検索します。その後、逆アセンブラーコンポーネントは、次のコンテキストでプロパティを書き込みます。
- 名前: 注釈で定義されている XPath 式。
- 値: 受信ドキュメント内の XPath 式によって識別される要素の値。
  
  XPath 式は非常に長い場合があります。特に、対象の要素がドキュメントスキーマに非常に深い場合です。したがって、フィールドの識別が多いほど、コンテキストサイズが大きくなります。これは、全体的なパフォーマンスに悪影響を及ぼします。
オーケストレーションランタイムによって提供される XPath 組み込み関数を使用します。
メッセージが非常に小さく (数キロバイト)、XML 形式の場合は、メッセージを .NET クラスインスタンスに逆シリアル化し、パブリックフィールドとプロパティを操作できます。 .NET クラスのインスタンスによって公開されるプロパティを使用してデータにアクセスする複雑な詳細 (カスタムコード、ビジネスルールエンジンポリシーなど) がメッセージに必要な場合は、XPath 式を使用する方がはるかに高速です。オーケストレーションによって呼び出されたビジネスロジックが完了したら、エンティティオブジェクトを BizTalk メッセージにシリアル化し直すことができます。 XML スキーマから .NET クラスを作成するには、XSD ツール (.NET Framework 2.0) または SVCUTIL (.NET Framework 3.0) のいずれかを使用します。
オーケストレーションからヘルパーコンポーネントを有効にします。この手法には、識別フィールドを使用するよりも優れた利点があります。実際、オーケストレーションは構成ストア (構成ファイル、SSO Config Store、カスタム Db など) から XPath 式を読み取る可能性があるため、XPath 式を変更する必要がある場合は、昇格されたプロパティと識別フィールドに対して行うように、スキーマを変更して再デプロイする必要はありません。次のコードサンプルでは、ヘルパーコンポーネントの例を示します。コンポーネントは、BizTalk ランタイムによって提供される XPathReader クラスを使用します。これにより、XPath 式が見つかるまで、コードはドキュメントストリームを読み取ることができます。

#region Copyright
//===
//Microsoft Windows Server AppFabric Customer Advisory Team (CAT)
//
// This sample is supplemental to the technical guidance published on the community
// blog.
//
// Author: Paolo Salvatori.
//===
// Copyright © 2010 Microsoft Corporation. All rights reserved.
//
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
// EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. YOU BEAR THE RISK OF USING IT.
//===
#endregion
#region Using Directives
using System;
using System.Collections.Generic;
using System.IO;
using System.Xml;
using System.Linq;
using System.Text;
using System.Globalization;
using Microsoft.XLANGs.BaseTypes;
using Microsoft.BizTalk.Streaming;
using Microsoft.BizTalk.XPath;
#endregion
namespace Microsoft.AppFabric.CAT.Samples.DuplexMEP.Helpers
{
public class XPathHelper
{
#region Private Constants
private const string MessageCannotBeNull = "[XPathReader] The message cannot be null.";
#endregion
#region Public Static Methods
public static string GetValue(XLANGMessage message, int partIndex, string xpath)
{
try
{
if (message == null)
{
throw new ApplicationException(MessageCannotBeNull);
}
using (Stream stream = message[partIndex].RetrieveAs(typeof(Stream)) as Stream)
{
XmlTextReader xmlTextReader = new XmlTextReader(stream);
XPathCollection xPathCollection = new XPathCollection();
XPathReader xPathReader = new XPathReader(xmlTextReader, xPathCollection);
xPathCollection.Add(xpath);
while (xPathReader.Read())
{
if (xPathReader.HasAttributes)
{
for (int i = 0; i < xPathReader.AttributeCount; i++)
{
xPathReader.MoveToAttribute(i);
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.GetAttribute(i);
}
}
}
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.ReadString();
}
}
}
}
finally
{
message.Dispose();
}
return string.Empty;
}
#endregion
}
}

オーケストレーションの複雑さを最小限に抑えてパフォーマンスを向上させる

オーケストレーションの複雑さは、パフォーマンスに大きな影響を与えます。オーケストレーションの複雑さが増すにつれて、全体的なパフォーマンスが低下します。オーケストレーションは、ほぼ無限のシナリオで使用でき、各シナリオにはさまざまな複雑さのオーケストレーションが含まれる場合があります。モジュール方式を優先して、可能な場合は複雑なオーケストレーションを回避します。つまり、ビジネスロジックを複数の再利用可能なオーケストレーションに分割します。

複雑なオーケストレーションを実装する必要がある場合は、ルートレベルではなく、可能な限りメッセージと変数を内部スコープに定義します。この手法では、変数とメッセージが定義されたスコープからフローが離れると変数とメッセージが破棄されるため、オーケストレーションごとにメモリ内のフットプリントが小さくなります。この方法は、オーケストレーションが永続化ポイントで MessageBox に保存される場合に特に便利です。

呼び出しオーケストレーション形状を使用することで、開始オーケストレーション形状よりもパフォーマンスを向上させることができます。

開始オーケストレーション図形を避け、呼び出しオーケストレーション図形を使用して入れ子になったオーケストレーションを実行します。実際、 呼び出しオーケストレーション 図形を使用して、別のプロジェクトで参照されているオーケストレーションを同期的に呼び出すことができます。この方法では、BizTalk プロジェクト間で一般的なオーケストレーションワークフローパターンを再利用できます。別の入れ子になったオーケストレーションをコールオーケストレーションシェイプを使って同期的に呼び出すと、外側のオーケストレーションは、入れ子になったオーケストレーションが完了するまで待機してから続行します。入れ子になったオーケストレーションは、呼び出し元のオーケストレーションを実行するのと同じスレッドで実行されます。

[オーケストレーションの開始] 図形は [オーケストレーションの呼び出し] 図形に似ていますが、この場合、入れ子になったオーケストレーションは非同期的に呼び出されます。呼び出されたオーケストレーションの処理が完了するのを待たずに、呼び出し元のオーケストレーションの制御フローは呼び出しを超えて続行されます。呼び出し元と呼び出されたオーケストレーションの間でこの分離を実装するために、 オーケストレーションの開始 は、BizTalk メッセージボックスへのメッセージの発行によって実装されます。このメッセージは、インプロセスの BizTalk ホストインスタンスによって処理され、入れ子になったオーケストレーションが実行されます。可能な場合は、 呼び出しオーケストレーションを使用します。特に、呼び出し元オーケストレーションが処理を続行するために入れ子になったオーケストレーションからの結果を待機する必要がある場合に使用します。呼び出しオーケストレーション図形の使用の詳細については、BizTalk Server 2010 ドキュメントの次のトピックを参照してください。

XmlReader と XLANGMessage を使用する方法と、XmlReader と XmlDocument を使用する方法を比較して、オーケストレーションのパフォーマンスを向上させる

オーケストレーションから呼び出される .NET メソッドのオーケストレーションパフォーマンスを向上させるには、XmlDocument ではなく XLANGMessage で XmlReader を使用します。次のコード例は、この機能を示しています。

// As a general rule, use XmlReader with XLANGMessage, not XmlDocument.
// This is illustrated in the parameter passed into the following code.
// The XLANG/s compiler doesn't allow a return value of XmlReader
// so documents must be initially constructed as XmlDocument()
public static XmlDocument FromMsg(XLANGMessage old)
{
    //get at the data
    XmlDocument ret = new XmlDocument();

    try{
        XmlReader reader = (XmlReader)old[0].RetrieveAs(typeof(XmlReader));
        //construct new message from old
        //read property
        object msgid = old.GetPropertyValue(typeof(BTS.MessageID));
    }
    finally {
        // Call Dispose on the XLANGMessage object
        // because the message doesn't belong to the
        // .NET runtime - it belongs to the Messagebox database
        old.Dispose();
    }
    return ret;
}

もう 1 つの方法は、スキーマに基づいて .NET クラスを作成することです。これにより、 ドキュメントを XmlDocument オブジェクトに読み込むよりもメモリが少なくなり、.NET 開発者はスキーマ要素に簡単にアクセスできます。 BizTalk スキーマに基づいてクラスを生成するには、Visual Studio で提供される xsd.exe ツールを使用できます。たとえば、ItemA、ItemB、ItemC という名前のフィールドを含む単純なスキーマに対して xsd.exe < schema.xsd> /classes を実行すると、次のクラスが生成されます。

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:2.0.50727.1433
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

using System.Xml.Serialization;

//
// This source code was auto-generated by xsd, Version=2.0.50727.42.
//

/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true, Namespace="http://Schemas.MySchema")]
[System.Xml.Serialization.XmlRootAttribute(Namespace="http://Schemas.MySchema", IsNullable=false)]
public partial class MySchemaRoot {

    private string itemAField;

    private string itemBField;

    private string itemCField;

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
    public string ItemA {
        get {
            return this.itemAField;
        }
        set {
            this.itemAField = value;
        }
    }

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
    public string ItemB {
        get {
            return this.itemBField;
        }
        set {
            this.itemBField = value;
        }
    }

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
    public string ItemC {
        get {
            return this.itemCField;
        }
        set {
            this.itemCField = value;
        }
    }
}

このクラスは、メッセージ要素にアクセスするために .NET アセンブリ内で参照でき、返されたオブジェクトをメッセージに直接割り当てることができます。上記で生成されたクラスの使用例を次に示します。

public static Root SetValues(Microsoft.XLANGs.BaseTypes.XLANGMessage msg)
{
   try
   {
   MySchemaRoot rootObj=(MySchemaRoot)msg[0].RetrieveAs(typeof(MySchemaRoot);
   rootObj.ItemA="value a";
   rootObj.ItemB="value b";
   rootObj.ItemC="value c";
   }
    finally {
        msg.Dispose();
            }

   return rootObj;
}

この手法を使用すると、メッセージを処理するときにオブジェクト指向のアプローチを使用できます。この手法は、主に比較的小さなメッセージで使用する必要があります。これは、この手法では 、XmlDocument オブジェクトにメッセージを読み込む場合よりもかなり少ないメモリを使用する場合でも、メッセージ全体がメモリに読み込まれるためです。より大きなメッセージを処理する場合 は、XmlReader クラスを使用してメッセージを読み取り、 XmlWriter クラスを使用してメッセージを書き込みます。 XmlReader と XmlWriter を使用する場合、メッセージは VirtualStream オブジェクトに含まれます。メッセージのサイズが、BizTalk グループのプロパティの構成ページで公開されている 大きなメッセージのしきい値 (バイト) に指定された値を超えた場合、メッセージはファイルシステムに書き込まれます。これにより、全体的なパフォーマンスは低下しますが、メモリ不足の例外は回避されます。

物理ポートにバインドされた論理ポートの使用を最小限に抑えることで、パフォーマンスを向上させる

次のアダプターを使用する物理ポートにバインドされた論理ポートの使用を最小限に抑えることで、パフォーマンスを向上させることができます。

SQL Server、Oracle
WSE、HTTP、WCF
MSMQ、MQSeries

BizTalk Server 2010 では、Microsoft.XLANGs.Pipeline.dllに含まれる XLANGPipelineManager クラスを使用して、オーケストレーションから直接送受信パイプラインを呼び出すことができます。したがって、パイプラインの処理はポートからオーケストレーションに移動できます。オーケストレーション内の論理ポートを式図形に置き換えることができます。式図形は、特定の .NET クラスのインスタンス (たとえば、ADO.NET を使用したデータアクセスコンポーネント) を呼び出します。この手法を採用する前に、アダプターと物理ポートを使用しないと、バッチ処理、再試行、宣言型構成、セカンダリトランスポートなどの機能を利用できなくなることに注意する必要があります。

オーケストレーションの設計パターン

オーケストレーションデザイナーを使用すると、開発者はさまざまなエンタープライズ統合パターンを実装できます。一般的なパターンとしては、アグリゲーター、例外処理と補正、メッセージブローカー、散布と収集、シーケンシャルコンボイと並列コンボイなどがあります。これらのパターンを使用して、BizTalk Server を使用して、複雑なエンタープライズアプリケーション統合 (EAI)、Service-Oriented アーキテクチャ (SOA)、ビジネスプロセス管理 (BPM) ソリューションを開発できます。オーケストレーションの設計パターンの詳細については、「BizTalk Server のドキュメントおよびパターンとエンタープライズ統合のベストプラクティス (https://go.microsoft.com/fwlink/?LinkId=140043)」の「オーケストレーションでのデザインパターンの実装 (https://go.microsoft.com/fwlink/?LinkId=140042)」を参照してください。

オーケストレーションで .NET クラスを適切に使用してパフォーマンスを最大化する

一般に、オーケストレーション内で使用される .NET クラスは、次の 2 つの異なるカテゴリに分けることができます。

ヘルパーとサービス - これらのクラスは、トレース、エラー処理、キャッシュ、シリアル化/逆シリアル化などのオーケストレーションに共通のサービスを提供します。これらのクラスのほとんどは、内部状態と複数のパブリック静的メソッドを持たない静的クラスとして実装できます。この方法では、異なるオーケストレーションで同じクラスの複数のオブジェクトが同時に実行されるのを回避し、ホストプロセスの作業領域を減らし、メモリを節約するのに役立ちます。ステートレスクラスは、オーケストレーションが停止された際に BizTalk メッセージボックスにシリアル化して永続化する必要がある内部状態の全体的なサイズを小さくするのに役立ちます。
エンティティとビジネスオブジェクト - これらのクラスを使用して、注文、注文品目、顧客などのエンティティを管理できます。 1 つのオーケストレーションで、同じ種類の複数のインスタンスを内部的に作成および管理できます。通常、これらのクラスはステートフルであり、オブジェクトの内部状態を変更するメソッドと共にパブリックフィールドやプロパティを公開します。これらのクラスのインスタンスを動的に作成するには、 XmlSerializer クラスまたは DataContractSerializer クラスを使用するか 、XLANGPart.RetrieveAs メソッドを使用して、XLANGMessage パーツを .NET オブジェクトに逆シリアル化します。ステートフルクラスのインスタンスができるだけ遅く作成され、不要になったらすぐにリリースされるように、非トランザクションスコープを使用してオーケストレーションを構成する必要があります。この方法により、ホストプロセスの作業領域が縮小され、オーケストレーションが退避されたときにメッセージボックスデータベースにシリアル化および永続化される内部状態の全体的なサイズが最小限に抑えられます。 BizTalk Server でのオーケストレーションの使用の詳細については、BizTalk Server オーケストレーション (https://go.microsoft.com/fwlink/?LinkID=116886) に関する FAQ に関する記事を参照してください。

注

この記事は BizTalk Server 2004 および BizTalk Server 2006 向けに書かれていますが、提示される概念は BizTalk Server 2010 オーケストレーションにも適用されます。

オーケストレーション例外ハンドラーブロック群

オーケストレーション例外ハンドラーブロックを使用する場合は、すべてのオーケストレーション図形を 1 つまたは複数のスコープ (可能な限り非トランザクションスコープ) に含め、少なくとも次の例外ハンドラーブロックを作成します。

一般的な System.Exception エラーを処理するための例外ハンドラーブロック。
一般的な例外を処理するための例外ハンドラーブロックは、COM例外などのアンマネージドエラーを捕捉して処理することを目的としています。

オーケストレーション例外処理ブロックの使用の詳細については、次の記事を参照してください。
BizTalk Server 例外処理の使用 (https://msdn.microsoft.com/library/aa561229.aspx)。
Charles Young ブログ、BizTalk Server 2006: 補正モデル (https://go.microsoft.com/fwlink/?LinkId=158017)。

注

このブログは BizTalk Server 2006 を念頭に置いて作成されましたが、ブログで説明されている原則は BizTalk Server にも適用されます。

オーケストレーションでマップを使用する場合の考慮事項

オーケストレーションでマップを使用する場合は、次の考慮事項が適用されます。

マップを使用してオーケストレーションのビジネスロジックで使用されるプロパティを抽出または設定する場合は、識別フィールドまたは昇格されたプロパティを使用します。マップを使用して値を抽出または設定する場合、ドキュメントはメモリに読み込まれますが、識別フィールドまたは昇格されたプロパティを使用する場合、オーケストレーションエンジンはメッセージコンテキストにアクセスし、ドキュメントをメモリに読み込まないため、この方法に従う必要があります。
マップを使用して複数のフィールドを 1 つのフィールドに集計する場合は、オーケストレーション変数で識別フィールドまたは昇格されたプロパティを使用して結果セットを累積します。

こちらもご覧ください

パフォーマンスの最適化