メタオブジェクトの構成

Connector for JMS は、2 種類のメタオブジェクトを認識および読み取ることができます。

動的な子メタオブジェクトの属性値は、静的なメタオブジェクトの属性値と重複し、それらをオーバーライドします。メタデータ、および静的メタオブジェクトと動的メタオブジェクトとの比較の概要については、メタデータおよびメタオブジェクトを参照してください。

どのメタオブジェクトが使用しているインプリメンテーションに最適かを判別するには、以下のことを検討してください。

メタオブジェクト・プロパティー

表 11 は、メタオブジェクトでサポートされるプロパティーの完全なリストです。メタオブジェクトをインプリメントする場合は、これらのプロパティーを参照してください。

両方のオブジェクトですべてのプロパティーを使用できるわけではありません。メッセージ・ヘッダーとの間で、すべてのプロパティーが読み取り可能または書き込み可能であるわけでもありません。コネクターが特定のプロパティーをどのように解釈および使用するかを確認するには、Adapter for JMS の概要の、イベントおよび要求の処理に関する該当セクションを参照してください。


表 11. JMS メタオブジェクト・プロパティー
プロパティー名 静的メタオブジェクトで定義可能 動的メタオブジェクトで定義可能 説明
DataHandlerConfigMO
 
はい はい 構成情報を提供するために、データ・ハンドラーに渡されるメタオブジェクト。静的なメタオブジェクトに指定された場合、この値は DataHandlerConfigMO コネクター・プロパティーに指定された値をオーバーライドします。さまざまなビジネス・オブジェクト・タイプを処理するために各種のデータ・ハンドラーが必要な場合は、この静的なメタオブジェクトのプロパティーを使用します。データ形式が実際のビジネス・データに依存する可能性がある場合は、要求処理には動的な子メタオブジェクトを使用します。指定されたビジネス・オブジェクトはコネクター・エージェントによりサポートされていることが必要です。コネクター固有プロパティーの構成 の説明を参照してください。
DataHandlerMimeType
 
はい はい 使用すると、特定の MIME タイプに基づいたデータ・ハンドラーを要求できます。静的なメタオブジェクトに指定された場合、この値は DataHandlerMimeType コネクター・プロパティーに指定された値をオーバーライドします。さまざまなビジネス・オブジェクト・タイプを処理するために各種のデータ・ハンドラーが必要な場合は、この静的なメタオブジェクトのプロパティーを使用します。データ形式が実際のビジネス・データに依存する可能性がある場合は、要求処理には動的な子メタオブジェクトを使用します。DataHandlerConfigMO に指定されたビジネス・オブジェクトは、このプロパティーの値に対応する属性を含める必要があります。コネクター固有プロパティーの構成 の説明を参照してください。
DataHandlerClassName
 
はい はい コネクター固有プロパティーの構成 の説明を参照してください。
InputFormat
 
はい はい インバウンド (イベント) メッセージのフォーマットまたはタイプ。この値は、メッセージ内容の識別を支援します。メッセージを生成したアプリケーションによって指定されます。メッセージ・フォーマットの定義でコネクターが考慮するフィールドは、コネクター固有プロパティー MessageFormatProperty によって、ユーザーが定義できます。
OutputFormat
 
はい はい アウトバウンド・メッセージで読み込まれるフォーマット。OutputFormat が指定されていない場合、使用可能であれば入力フォーマットが使用されます。
InputDestination はい はい このプロパティーは、着信メッセージをビジネス・オブジェクトとマッチングする目的のみで使用されます。対照的に、InputDestination のコネクター固有のプロパティーは、アダプターがポーリングする宛先を定義します。これはポーリングする宛先を判別するためにアダプターが使用する唯一のプロパティーです。MO 内では、InputDestination プロパティーおよび InputFormat プロパティーは、アダプターが任意のメッセージを特定のビジネス・オブジェクトにマップする基準として機能します。この機能をインプリメントするためには、コネクター固有のプロパティーを使用して複数の入力宛先を構成し、オプションで、着信メッセージの入力フォーマットに基づき異なるデータ・ハンドラーをそれぞれにマップします。


このプロパティーは、デフォルトの型変換プロパティーを使用して設定しないでください。値は以下で使用されます。

OutputDestination
 
はい はい アウトバウンド・メッセージが書き込まれる宛先。
ResponseTimeout
 
はい はい 同期要求処理の応答を待機した状態で、タイムアウトになるまでの時間をミリ秒で表します。このプロパティーが定義されていないかまたはゼロより小さい値が設定されている場合、コネクターは応答を待機せずにすぐに SUCCESS を戻します。
TimeoutFatal
 
はい はい 同期要求処理において、応答が受信されない場合にコネクターにエラー・メッセージを戻させるために使用されます。このプロパティーが True の場合、応答が ResponseTimeout で指定した時間内に受信されなければ、コネクターはブローカーに APPRESPONSETIMEOUT を戻します。このプロパティーが未定義か、または False にセットされている場合、応答がタイムアウトになるとコネクターは要求をエラーにしますが、終了はしません。デフォルト = False
JMS メッセージ・ヘッダーに限定してマッピングされるフィールドを以下に示します。説明、値の解釈などについては、JMS API 仕様を参照してください。JMS プロバイダーは、一部のフィールドについて、異なった解釈をする場合があります。それらの違いについて、JMS プロバイダーの資料も確認してください。
ReplyToDestination
はい 要求の応答メッセージが送られる宛先。
Type
はい メッセージのタイプ。JMS プロバイダーによって異なりますが、一般には、ユーザーによる定義が可能。
MessageID
はい メッセージの固有 ID (JMS プロバイダーに固有)。
CorrelationID はい はい この応答を開始した要求メッセージの ID を示すために、応答メッセージで使用されます。
Delivery Mode はい はい MOM システムでメッセージを永続させるかどうかを指定します。許容値は以下のとおりです。
1=非永続
2=永続
JMS プロバイダーによっては、その他の値を使用できます。
Priority
はい メッセージの優先順位 (数値)。許容値は、0 から 9 です (数値が小さいほど優先順位は高くなる)。
Destination
はい MOM システムでの、メッセージの現在または最後の (削除された場合) 場所。
Expiration
はい メッセージの存続時間。ゼロが指定されると、有効期限がゼロに設定されます。ゼロを指定すると JMS プロバイダーは、メッセージを有効期限切れにしません。
Redelivered
はい JMS プロバイダーが以前にクライアントへのメッセージ配信を試みた可能性は高いが、受取が確認されなかったことを示します。
Timestamp
はい 時間メッセージが JMS プロバイダーに渡されました。
UserID
はい メッセージを送信するユーザーの ID。
AppID
はい メッセージを送信するアプリケーションの ID。
DeliveryCount
はい 配信を試みる回数。
GroupID
はい メッセージ・グループの ID。
GroupSeq
はい グループ ID で指定されたメッセージ・グループにおける、このメッセージの順序。
JMSProperties
はい JMS プロパティーを参照してください。

静的メタオブジェクトの構成

JMS 構成の静的なメタオブジェクトには、さまざまなビジネス・オブジェクトに定義された変換プロパティーのリストが含まれます。静的メタオブジェクトのサンプルを参照するには、Business Object Designer Express を起動し、アダプターと一緒に出荷される、次のサンプルを開きます。connectors¥JMS¥Samples¥Sample_JMS_MO_Config.xsd

コネクターは、いつでも、最大で 1 つの静的メタオブジェクトをサポートします。静的メタオブジェクトは、コネクター・プロパティー ConfigurationMetaObject で名前を指定してインプリメントします。

静的メタオブジェクトは、ビジネス・オブジェクトと動詞の単一の組み合わせ、およびそのオブジェクトの処理に関連したすべてのメタデータを、各属性が表す構造になっています。各属性の名前は、Customer_Create のように、ビジネス・オブジェクト・タイプと動詞の名前を下線で区切ったものです。属性のアプリケーション固有情報は、セミコロンで区切られた 1 つ以上の名前と値のペアで構成され、この固有なオブジェクトと動詞の組み合わせに指定するメタデータ・プロパティーを表します。


表 12. 静的メタオブジェクトの構造
属性名 アプリケーション固有のテキスト
<business object type>_<verb>
 
property=value;property=value;...
 
<business object type>_<verb>
 
property=value;property=value;...
 

以下のメタオブジェクトを例にとります。

表 13. 静的メタオブジェクト構造のサンプル
属性名 アプリケーション固有情報
Customer_Create
 
OutputFormat=CUST;OutputDestination=QueueA
 
Customer_Update
 
OutputFormat=CUST;OutputDestination=QueueB
 
Order_Create
 
OutputFormat=ORDER;OutputDestination=QueueC
 

このサンプルのメタオブジェクトは、コネクターが、タイプ Customer に動詞 Create が付いた要求ビジネス・オブジェクトを受け取った場合、それをフォーマット CUST の メッセージに変換し、宛先 QueueA に置くことを知らせます。 カスタマー・オブジェクトが動詞 Update を持つ場合、メッセージは QueueB に置かれます。オブジェクト・タイプが Order であり、動詞 Create を持つ場合、コネクターは、そのオブジェクトを、フォーマット ORDER で変換し、QueueC に配信します。コネクターに渡されるその他のビジネス・オブジェクトは、アンサブスクライブされているものとして処理されます。

オプションで、1 つの属性 Default を指定し、それに ASI の 1 つ以上のプロパティーを割り当てることができます。メタオブジェクトに含まれるすべての属性で、デフォルト属性のプロパティーは、特定のオブジェクトと動詞属性のプロパティーに結合されます。これは、全体に適用する 1 つ以上のプロパティーがある (オブジェクトと動詞の組み合わせに関係なく) 場合に便利です。以下の例の場合、コネクターは、Customer_Create および Order_Create のオブジェクトと動詞の組み合わせが、それらの個別のメタデータ・プロパティー以外に、OutputDestination=QueueA を持つとみなします。


表 14. 静的メタオブジェクト構造のサンプル
属性名 アプリケーション固有情報
Default
 
OutputDestination=QueueA
 
Customer_Update
 
OutputFormat=CUST
 
Order_Create
 
OutputFormat=ORDER
 

メタオブジェクト・プロパティー表 11 では、静的メタオブジェクトで、アプリケーション固有情報として指定できるプロパティーについて説明しています。

静的メタオブジェクトをインプリメントするには、以下のようにします。

  1. Business Object Designer Express を起動します。詳細については、「ビジネス・オブジェクト開発ガイド」を参照してください。
  2. サンプルのメタオブジェクト connectors¥JMS¥Samples¥Sample_JMS_MO_Config.xsd を開きます。図 3 に Business Object Designer Express 内のサンプルの静的メタオブジェクトを示します。

    図 3. 静的メタオブジェクトのサンプル


  3. 表 11 を参照して、要件に適合するように 属性および ASI を編集してから、メタオブジェクト・ファイルを保管します。
  4. このメタオブジェクト・ファイルの名前を、コネクター・プロパティー ConfigurationMetaObject の値 として指定します。

入力宛先へのデータ・ハンドラーのマッピング

静的メタオブジェクトのアプリケーション固有情報で InputDestination プロパティーを使用することにより、データ・ハンドラーと入力宛先を関連付けることができます。この機能は、異なる書式や変換要件を持つ複数の取引先と取り引きする場合に役立ちます。

データ・ハンドラーを入力宛先にマップするには、以下のようにします。

  1. Connector Configurator Express を起動します。詳細については、付録 B, Connector Configurator Expressを参照してください。
  2. コネクター固有プロパティー (InputDestinationを参照) を使用して、1 つ以上の入力宛先を構成します。複数の宛先名はセミコロンで区切る必要があります。
  3. それぞれの入力宛先ごとに、宛先 (PTP メッセージング・スタイルをインプリメントしている場合は キュー・マネージャー) および入力宛先名を指定し、またアプリケーション固有情報にデータ・ハンドラーのクラス名および MIME タイプを指定します。

例えば、次に示す静的メタオブジェクトの属性は、データ・ハンドラーと、CompReceipts という名前の InputDestination を関連付けています。

[Attribute]
 Name = Customer_Create
 Type = String
 Cardinality = 1
 MaxLength = 1
 IsKey = false
 IsForeignKey = false
 IsRequired = false
 AppSpecificInfo =
 InputDestination=//queue.manager/CompReceipts;DataHandlerClassName=com.crossworlds.
 DataHandlers.MQ.disposition_notification;DataHandlerMimeType=message/
 disposition_notification
 IsRequiredServerBound = false
 [End]
 

動的子メタオブジェクトの構成

静的なメタオブジェクトに必要なメタデータを指定することが困難または実行不可能な場合、コネクターは、ビジネス・オブジェクト・インスタンスごとに実行時に配信されたメタデータをオプションで受け入れることができます。

動的メタオブジェクトを使用すると、要求処理のときに、要求ごとに、コネクターが使用するメタデータを変更してビジネス・オブジェクトを処理できます。また、イベント処理のときに、イベント・メッセージの情報を検索することができます。

動的メタオブジェクトは、各属性が、次のような単一のメタデータのプロパティーと値を表す構造になっています。meta-object property name =meta-object property value

動的メタオブジェクトをインプリメントするには、それを子としてトップレベル・オブジェクトに追加し、トップレベル・オブジェクト ASI に 名前と値のペア cw_mo_conn=<MO attribute> を組み込みます。<MO attribute> は、動的メタオブジェクトを表すトップレベル・オブジェクトの属性名です。以下に例を示します。

Customer (ASI = cw_mo_conn=MetaData)
   |-- Id
   |-- FirstName
   |-- LastName
   |-- ContactInfo
   |-- MetaData
         |-- OutputFormat = CUST
         |-- OutputDestination = QueueA
 

上記のように指定された要求を受け取ると、コネクターは、Customer オブジェクトを CUST というフォーマットを持ったメッセージに変換してから、メッセージをキュー QueueA に置きます。

ビジネス・オブジェクトは、同じ動的メタオブジェクトでも、異なった動的メタオブジェクトでも使用できます。また、まったく使用しないことも可能です。

注:
すべての標準 IBM WebSphere データ・ハンドラーは、 cw_mo_ タグを認識することによって、この動的メタオブジェクト属性を無視するように設計されています。アダプターに使用するカスタム・データ・ハンドラーを開発する場合、同じようにする必要があります。

コネクターは、コネクターに渡されるトップレベル・ビジネス・オブジェクトに子として追加される動的なメタオブジェクトから、変換プロパティーを認識し、読み取ります。この動的な子メタオブジェクトの属性値は、コネクターの構成に使用される静的なメタオブジェクトに指定可能であった変換プロパティーと重複します。

動的な子メタオブジェクトのプロパティーは静的なメタオブジェクトから検出されるプロパティーをオーバーライドするため、動的な子メタオブジェクトを指定する場合は、静的なメタオブジェクトを指定するコネクター・プロパティーを組み込む必要はありません。したがって、動的な子メタオブジェクトは、静的なメタオブジェクトとは無関係に使用することができ、その逆もまた同様です。

メタオブジェクト・プロパティー表 11 では、動的メタオブジェクトで、アプリケーション固有情報として指定できるプロパティーについて説明します。

動的メタオブジェクトを構成するには、以下のようにします。

  1. Business Object Designer Express を起動します。詳細については、「ビジネス・オブジェクト開発ガイド」を参照してください。
  2. サンプルのメタオブジェクト connectors¥JMS¥Samples¥Sample_JMS_DynMO.xsd を開きます。図 4 に Business Object Designer Express 内のサンプルの動的メタオブジェクトを示します。

    図 4. 動的メタオブジェクトのサンプル


  3. このビジネス・オブジェクトの要件に適合するように属性およびプロパティーを編集し、保管します。
  4. 動的メタデータ・オブジェクトを子としてトップレベル・オブジェクトに追加し、トップレベル・オブジェクト ASI に名前と値のペア cw_mo_conn=<MO attribute> を組み込みます。<MO attribute> は、動的メタオブジェクトを表すトップレベル・オブジェクトの属性名です。

ポーリング中の動的な子メタオブジェクトの含まれるデータ

ポーリング中に検索されたメッセージについてさらに詳しい情報をコラボレーションに提供するため、コネクターは、作成されたビジネス・オブジェクトに動的なメタオブジェクトが定義済みである場合、その特定の属性に値を取り込みます。

表 15 に、動的な子メタオブジェクトがポーリング用に構造化される方法を示します。

表 15. ポーリング用の JMS 動的子メタオブジェクト構造
属性名 サンプル値
InputFormat
 
CUST_IN
 
InputQueue
 
MYInputQueue
 
OutputFormat
 
CxIgnore
 
OutputQueue
 
CxIgnore
 
ResponseTimeout
 
CxIgnore
 
TimeoutFatal
 
CxIgnore
 

表 15 に示すように、動的子メタオブジェクトで追加の属性 Input_Format および Inputdestination を定義できます。 Input_Format は検索したメッセージのフォーマットで読み込まれ、InputDestination 属性には特定のメッセージの検索先となる宛先の名前が含まれます。子メタオブジェクト内にこれらのプロパティーが定義されていない場合、これらには値が取り込まれません。

シナリオ例:

JMS ヘッダーおよび動的子メタオブジェクト属性

動的メタオブジェクトに属性を追加すると、メッセージ・トランスポートの詳細情報を取得したりメッセージ・トランスポートを詳細に制御したりすることができます。このセクションでは、これらの属性、およびそれらがイベント通知と要求処理にどのような影響を与えるかについて説明します。

JMS プロパティー

動的メタオブジェクトの他の属性と異なり、JMSProperties は単一カーディナリティー子オブジェクトを定義する必要があります。この子オブジェクトの各属性は、以下のように JMS メッセージ・ヘッダーの可変部分で読み取り/書き込みを行う単一プロパティーを定義する必要があります。

  1. 属性の名前はセマンティック値を持ちません。
  2. 属性のタイプは、JMS プロパティー・タイプに無関係に 必ず String でなければなりません。
  3. 属性のアプリケーション固有情報は、属性をマップする JMS メッセージ・プロパティーの名前と形式を 定義する 2 つの名前と値の組を含まなければなりません。名前はユーザー定義可能です。値の型は、以下のいずれかでなければなりません。

以下の表に、JMSProperties オブジェクトの属性に対して定義する必要があるアプリケーション固有情報プロパティーを示します。


表 16. JMS プロパティー属性のアプリケーション固有情報
属性 指定可能な値 ASI コメント
Name 有効な JMS プロパティー名 (有効 = ASI で定義されたタイプと互換性がある) name=<JMS プロパティー名>;type=<JMS プロパティー・タイプ> ベンダーによっては、拡張機能を提供するために特定のプロパティーを予約している場合があります。一般に、ユーザーはベンダー固有の機能にアクセスする場合以外は、JMS で開始するカスタム・プロパティーを定義してはなりません。
Type String type=<コメントを参照> これは JMS プロパティーのタイプです。JMS API は、JMS メッセージに値を設定するための多くの メソッドを提供します (例: setIntPropertysetLongPropertysetStringProperty)。ここで指定する JMS プロパティーのタイプによって、どのメソッドを使用してメッセージのプロパティー値を設定するかが決まります。

下の例では、メッセージ・ヘッダーのユーザー定義フィールドにアクセスできるように、Customer オブジェクトに JMSProperties 子オブジェクトが定義されています。

Customer (ASI = cw_mo_conn=MetaData)
   |-- Id
   |-- FirstName
   |-- LastName
   |-- ContactInfo
   |-- MetaData
         |-- OutputFormat = CUST
         |-- OutputDestination = QueueA
         |-- JMSProperties
              |-- RoutingCode = 123 (ASI= name=RoutingCode;type=Int)
              |-- Dept = FD (ASI= name=RoutingDept;type=String)
 

別の例を示すために、図 5 に、動的メタオブジェクトの 属性 JMSProperties および JMS メッセージ・ヘッダーの 4 つの プロパティー (ID、GID、RESPONSE、および RESPONSE_PERSIST) の定義を示します。属性のアプリケーション固有情報はそれぞれの名前およびタイプを定義します。例えば、属性 ID はタイプ String の JMS プロパティー ID に マップされます。

図 5. 動的メタオブジェクトの JMS プロパティー属性


Copyright IBM Corp. 2004