アダプターのデザインの問題点

アダプターの構成は、ユーザーがデザイン時に構成を変更すると、シングル サインオン (SSO) データベースに格納されます。 実行時に、メッセージング エンジンはアダプターの構成を取得し、その構成をアダプターに送信します。 アダプターには、次の 4 種類の構成情報が送信されます。

• 受信ハンドラーの構成

• 受信場所 (エンドポイント) の構成

• 送信ハンドラーの構成

• 送信場所 (エンドポイント) の構成

受信ハンドラーと送信ハンドラーの構成

アダプターのハンドラー構成は、オプションの IPersistPropertyBag の実装時にアダプターに配信されます。インターフェイスを読み込みます 。 ハンドラー構成は一度しか送信されないため、アダプダのハンドラー構成が BizTalk サービスの開始後に変更された場合、アダプターは更新されません。 一般的なモデルでは、アダプターはハンドラー構成を既定の構成として処理します。エンドポイント構成は、エンドポイントごとにハンドラー構成をオーバーライドします。

次のコードは、構成の解析例を示します。 アダプターの構成は、String プロパティ AdapterConfig の Load 呼び出しに渡されるプロパティにあります。 このプロパティ値には、アダプターの構成を表す XML ドキュメントが含まれています。 アダプターはこの構成をドキュメント オブジェクト モデル (DOM) または XML リーダーに読み込み、XPath を使用して個々のプロパティを取得する必要があります。

public class MyAdapter : IBTTransport,   
 IBTTransportConfig,   
 IBTTransportControl,  
 IPersistPropertyBag,   
 IBaseComponent  
{  
...  
// Handler configuration properties...  
private int defaultBatchSize = 0;  
private string defaultHeader;  
  
// IPersistPropertyBag.Load() implementation...  
public void Load(IPropertyBag pb, int pErrorLog)  
{  
// The adapter configuration is in the property  
 // “AdapterConfig” in the form of an Xml blob...  
object obj = null;  
pb.Read("AdapterConfig", out obj, 0);  
  
// Create a DOM and load the Xml blob...  
XmlDocument dom = new XmlDocument();  
string adapterConfig = (string)obj;  
dom.LoadXml(adapterConfig);  
  
// XPath the individual properties...  
XmlNode node =   
 document.SelectSingleNode(“/Config/batchSize”);  
defaultBatchSize = int.Parse(node.InnerText);  
  
node = document.SelectSingleNode(“/Config/header”);  
defaultHeader = node.InnerText;  
}  
}  

受信場所の構成

受信場所の構成情報は、 IBTTransportConfig の実装時にアダプターに配信されます。 このインターフェイスには、 AddReceiveEndpoint、 UpdateEndpointConfig、 RemoveReceiveEndpoint の 3 つのメソッドが含まれています。 メッセージング エンジンは、メッセージを受信するために受信待ちする必要があるエンドポイントをアダプターに通知します。 個々のエンドポイントの構成が変更されると、アダプターはそのエンドポイントの変更について通知を受けます。 これは、ハンドラーの構成が変更されてもアダプターは通知を受けないのとは対照的です。 同様に、BizTalk Server はサービス ウィンドウがアクティブまたは非アクティブになるとエンドポイントを追加、削除するため、アダプターはサービス ウィンドウを処理する必要はありません。

AddReceiveEndpoint

アダプターがエンドポイントでリッスンを開始する必要がある場合、エンジンは IBTTransportConfig.AddReceiveEndpoint を呼び出して、受信場所の URI、そのエンドポイントのアダプターの構成を含むプロパティ バッグ、およびそのエンドポイントのBizTalk Server固有の構成を含む 2 つ目のプロパティ バッグを渡します。 アダプターは、メッセージ コンテキストに、BizTalk Server システム プロパティ InboundTransportLocation として URI を書き込む必要があります。

アダプターのプロパティ バッグから受信場所のプロパティを読み取るのは、上記で説明したハンドラー構成を読み取るのと同じことです。 アダプターに渡されるBizTalk Server構成には、単一のプロパティ TwoWayReceivePort が含まれています。これは、ポートが一方向か双方向かを示します。 次のコードは、受信ポートが一方向と双方向のどちらであるかを BizTalk Server のプロパティ バッグから評価する方法を示しています。

public void AddReceiveEndpoint(  
 string  url,   
 IPropertyBag adapterConfig,   
 IPropertyBag bizTalkConfig )  
{  
...  
  
// The property "TwoWayReceivePort" in the BizTalk Config  
// property bag indicates whether the port is one or two  
 // way...  
  
 // Add receive location to config cache (not shown here)  
  
object obj = null;  
bizTalkConfig.Read("TwoWayReceivePort", out obj, 0);  
  
if ( null != obj )  
this.twoWay = (bool)obj;  
}  

UpdateEndpointConfig

アクティブな受信場所の構成が変更されると、エンジンは UpdateEndpointConfig API を使用して、別の構成を使用する必要があることをアダプターに通知します。 BizTalk Server 固有の構成を含め、すべての構成がアダプターに送信されます。

RemoveReceiveEndpoint

受信場所がアクティブではなくなった場合、アダプターは RemoveReceiveEndpoint を介して通知されます。 アダプターが RemoveReceiveEndpoint から戻ると、その URI を使用してエンジンにメッセージを送信することはできなくなります。

送信ポートの構成

メッセージング エンジンは送信ポートの構成をアダプターのメッセージ内のメッセージ コンテキストに書き込んでから、メッセージをアダプターに送信します。 アダプターは、構成の読み取りや検証を実行した後に、その構成を使用してメッセージの送信を制御します。 バッチ化された送信をサポートする送信アダプターの場合は、別の送信ポートを宛先とするメッセージが同じバッチ内に存在する可能性があるため、アダプターはこれらの "混在" バッチを処理する必要があります。

次のコード フラグメントは、送信ポートの URI である OutboundTransportLocation を読み取る方法を示しています。 また、アダプターの構成を含む XML BLOB を読み取ってから、個々のプロパティを読み取る方法も示します。

...  
 private static readonly PropertyBase UriProperty =   
 new BTS.OutboundTransportLocation();  
  
 private string propertyNamespace =   
  "http://schemas.mySchemas.com/MyAdapter/myadapter-properties";  
private string uri;  
private string headers;  
private int timeOut = 1000;  
  
private void ReadSendPortConfig(IBaseMessage msg)  
{  
// Read the OutboundTransportLocation,   
 // i.e. the send port uri....  
uri = (string)msg.Context.Read(  
 UriProperty.Name.Name, UriProperty.Name.Namespace);  
  
// Read the adapters configuration Xml blob from   
 // the message...  
XmlDocument locationConfigDom = null;  
object obj = msg.Context.Read(  
 "AdapterConfig", this.propertyNamespace);  
  
// If this is a dynamic send there will not be   
 // any configuration...  
if ( null != obj )  
{  
locationConfigDom = new XmlDocument();  
locationConfigDom.LoadXml((string)obj);  
  
this.headers = Extract(  
 locationConfigDom, "/Config/headers", true);  
  
 this.timeOut = ExtractInt32(  
 locationConfigDom, "/Config/timeOut", true);  
}  
}  
  
 // Helper method to XPath string properties...  
private static string Extract(  
 XmlDocument document, string path, bool required)  
{  
XmlNode node = document.SelectSingleNode(path);  
if (!required && null == node)  
return String.Empty;  
if (null == node)  
throw new ApplicationException(string.Format(  
 "No property was found at {0}", path));  
return node.InnerText;  
}  
  
  // Helper method to XPath int32 properties...  
private static int ExtractInt32(  
 XmlDocument document, string path, bool required)  
{  
string s = Extract(document, path, required);  
return int.Parse(s);  
}   

実装のヒント: アダプターでは、通常、 OutboundTransportLocation メッセージ コンテキスト プロパティを使用して、メッセージの送信先のアドレスを決定する必要があります。 この方法を実行すると、静的送信と動的送信に対する送信を一貫して処理できます。 また、この方法を使用すると、実稼動のバインド ファイルのアドレスを簡単に変更できます。

[XSD]

SDK ファイル アダプター サンプルに含まれる 4 つの XSD ファイルは、主にアダプター構成を処理します。ReceiveHandler.xsd、ReceiveLocation.xsd、TransmitLocation.xsd、TransmitHandler.xsd です。

次のトピックでは、これらの各ファイルと、それらのファイルの変更方法について説明します。

このセクションの内容

• アダプターの構成情報の検証

• アダプターの登録

• アダプター フレームワーク構成スキーマの拡張機能

• サポートされているアダプターの XSD 要素の型

• アダプターの XSD Element-Attribute コンストラクター

• アダプターの XSD Data Type-Facet コンストラクター

• アダプターの詳細構成コンポーネント