| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > ATMI アプリケーションでの Tuxedo TOP END Domain Gateway の使用 > 高信頼性キューのプログラミング |
|
ATMI アプリケーションでの Tuxedo TOP END Domain Gateway の使用
|
高信頼性キューのプログラミング
ここでは、次の内容について説明します。
高信頼性キューを TEDG と使用する
BEA Tuxedo システムと BEA TOP END システムは、コンポーネント間でメッセージをやり取りするための高信頼性キューをサポートしています。BEA Tuxedo の /Q 機能および BEA TOP END の回復可能トランザクション・キューイング (RTQ: Recoverable Transaction Queuing) 機能では、処理前にメッセージを格納しておくための手段としてキューを使用できます。/Q および RTQ では、キューに正常に登録されたメッセージは必ずサーバに送信されます。メッセージのキュー登録とメッセージ処理のどちらでも、完全なトランザクション・セマンティクスがサポートされます。
TOP END Domain Gateway (TEDG) は、BEA Tuxedo システムと BEA TOP END システム間でメッセージのキュー処理をサポートしています。トランザクションに関与するメッセージのキュー処理もサポートしています。キュー自体は、それを作成したネイティブ・システムの一部です。メッセージのキュー処理に対する管理機能も、ネイティブ・システムに含まれます。
/Q と RTQ の機能およびインターフェイスはメッセージの取り出し処理に関してかなり異なるため、TEDG はリモート・システムのキューからのメッセージ取り出しはサポートしていません。BEA Tuxedo の /Q には、キューからのメッセージ取り出しを明示的に実行する tpdequeue(3c) 関数が用意されていますが、RTQ にはそれと同等の関数はありません。RTQ ではメッセージは自動的に取り出され、目的の BEA TOP END サービスに送信されます。宛先サービスのアドレスは、メッセージをキューに登録する処理の一部として指定されます。『BEA TOP END Programmer’s Reference Manual』の tp_rtq_put(3T) を参照してください。
キューとサービスの関係は任意です。/Q は、システムで提供されるサービス TMQFORWARD(5) によって自動的にメッセージをキューから取り出し、tpcall(3c) 関数を介して標準 BEA Tuxedo サーバに転送することができます。宛先サービス名はキュー名と一致しなければなりません。TEDG 環境では、自動的に取り出されたメッセージは、TEDG コンフィギュレーションおよびサーバのプログラミングに応じて、同じシステム内のサーバ、またはリモート・システムのサーバに送信されます。
ここでは、BEA Tuxedo の /Q または BEA TOP END の RTQ キュー、およびキューに関連する管理ツールおよびサーバが既にシステムに存在すると想定しています。キュー処理の値、キューを使用するシステムの設計、およびキューのコンフィギュレーションと管理の方法については、『BEA Tuxedo /Q コンポーネント』
および『BEA TOP END Recoverable Transaction Queuing Guide』を参照してください。TEDG でサポートされる共通のキュー処理機能
/Q と RTQ の基本的な機能は似ていますが、それぞれに固有の機能もいくつかあります。TEDG で提供される機能は次のとおりです。これらの機能は、2 つのシステムの機能に対する共通のサブセットです。
サポートされていない BEA Tuxedo の /Q 機能
TEDG でサポートされていない BEA Tuxedo の /Q 機能は次のとおりです。
サポートされていない BEA TOP END の RTQ 機能
TEDG でサポートされていない BEA TOP END の RTQ 機能は次のとおりです。
関連項目
BEA Tuxedo クライアントから RTQ へのメッセージ登録
BEA Tuxedo クライアントは、tpenqueue(3c) を呼び出してメッセージを BEA TOP END の RTQ キューに登録することができます。呼び出しで指定されたキュー・スペース (QSPACE) パラメータに基づいて、BEA Tuxedo アプリケーションは要求を TEDG にルーティングします。BEA Tuxedo クライアントに関して、TEDG は TMQUEUE(5) サーバの機能を果たします。
BEA TOP END 管理者は RTQ キューを BEA TOP END システムで作成する必要があります。RTQ キューの作成については、『BEA TOP END Recoverable Transaction Queuing Guide』を参照してください。RTQ キューを BEA Tuxedo のキュー・スペースとして宣言するには、TEDG の DMCONFIG ファイルの DM_REMOTE_SERVICES セクションに、そのキュー・スペースの QSPACE エントリが定義されていなければなりません。BEA TOP END システムの RTQ キューのステータス、つまりキューに対する RTQ サーバが利用可能かどうかは、接続がアクティブの間はトラッキングされません。TEDG でサポートされているキュー・スペースは qmadmin では定義されません。 キュー・スペースは BEA Tuxedo の /Q キューに対して定義されます。
TEDG はキュー・スペースエントリの TE_RTQGROUP、TE_RTQNAME、およびオプションの TE_TARGET パラメータを使って、対応する BEA TOP END キューを決定します。RTQ 要求のサービス名を決定するには、tpenqueue() 関数のキュー名 (qname) パラメータを使用します。キュー名に一致する QNAME エントリを DM_REMOTE_SERVICES セクションで検索します。関連する 4 つのパラメータ (TE_PRODUCT、TE_FUNCTION、TE_TARGET、および TE_QUALIFIER) の値を取得し、BEA TOP END システムに送信するメッセージに指定します。BEA TOP END システムに対して、TEDG は tp_rtq_put 要求と同じ処理を行います。
キュー・スペースが正常にマッピングされないと、TEDG は TPENOENT を返します。qname がマッピングされないと、tpenqueue() の戻りコード TPEDIAGNOSTIC および診断値 QMEBADQUEUE が返されます。BEA TOP END システムによって返されるステータスは BEA Tuxedo 戻り値にマッピングされ、BEA Tuxedo クライアントに送信されます。
RTQ キューに登録されるメッセージは RTQ によってスケジューリングされ、受信側サーバは通常の方法でメッセージにアクセスします。要求に関連するクライアント識別子は TEDG ローカル・ドメイン ID です。ほかの RTQ メッセージ同様、サーバは終了時に RTQ に応答しますが、データを返すことはできません。サーバの応答が必要な場合は、クライアントとサーバが応答キュー情報を実際のクライアント・メッセージ内で送信し、BEA Tuxedo システムの /Q 機能による応答処理をエミュレートすることが必要です。
TEDG と BEA Tuxedo クライアントの動作
BEA Tuxedo クライアントでは、TEDG を介してメッセージを BEA TOP END の RTQ キューに登録するために tpenqueue() 関数を使用します。
BEA Tuxedo クライアントのプログラマは次の情報を把握している必要があります。
BEA TOP END サービスが FML32 による入力をサポートしている場合、BEA Tuxedo クライアントは BEA Tuxedo の FML32 バッファ・タイプを使用します。FML32 は、TEDG と異なるタイプの BEA TOP END ノード間を送信される場合、TEDG と BEA TOP END システムでデータ・マーシャリングがサポートされているため有用です。
BEA TOP END サービスはこれらのバッファ・タイプの 1 つ以上をサポートしています。
BEA TOP END の RTQ メッセージは 30,000 バイトに制限されているため、クライアント要求はこのサイズを超えることはできません。FML32 メッセージに対しては、FML インデックスを除いたメッセージにこの制限が適用されます。
TEDG によるクライアント要求のマッピング
クライアント要求にはトランザクションに関与するものとしないものがあります。次の表は、BEA Tuxedo クライアントの tpenqueue のフラグおよび関連するパラメータが BEA TOP END の RTQ 要求にどのようにマッピングされるかを示しています。これらのフラグおよびパラメータのマッピングにより、通常 BEA Tuxedo システムで行われるタスクを TEDG で実行することができます。
ほかの tpenqueue() のオプションのフラグは次のとおりです。これらのフラグは TEDG でサポートされていません。TPQCTL の urcode フィールドもサポートされていません。
tpenqueue() 呼び出しで BEA Tuxedo クライアントに返される tperrno 値は標準の値です。TEDG は TMQUEUE サーバとして機能するので、TEDG および RTQ 関連のエラーは TPEDIAGNOSTIC tperrno と TPQCTL 診断フィールドの対応する値の両方にマッピングされます。
エラー値
TEDG、BEA TOP END システム、または BEA TOP END サーバに問題がある場合、次のエラー値が BEA Tuxedo クライアントに返されます。1 つのエラー値は、複数の原因のうちの 1 つにしかすぎない場合があることに注意してください。
TEDG が宣言する QSPACE は、キュー処理を行う実際の BEA TOP END の RTQ サーバの可用性に基づくわけではないので、実際にはそのキュー・スペースを利用できない BEA TOP END ノードにメッセージがルーティングされることもあります。その場合、ほかのルーティング決定では要求は正常に行われても、tperrno に TPENOENT が設定されます。キュー・スペースを複数のノードで利用できる場合、BEA Tuxedo アプリケーション、BEA TOP END アプリケーション、および TEDG の設計ではこの種の障害が発生する可能性を考慮する必要があります。複数の再起動可能なサーバを定義したアプリケーションであれば、このようなエラーが発生する可能性は低くなります。
関連項目
BEA TOP END クライアントから /Q へのメッセージ登録
BEA TOP END クライアントは、tp_rtq_put(3T) を呼び出してメッセージを BEA Tuxedo の /Q キューに登録します。BEA TOP END システムが要求を TEDG または別の RTQ サーバにルーティングするには、queue_info パラメータを使用します。queue_info パラメータは RTQ グループ、RTQ キュー名、および RTQ ターゲットを指定します。
BEA Tuxedo の管理者は qmadmin(1) を使用して /Q キュー・スペースを作成し、その QSPACE 内で利用できるキュー名を作成する必要があります。BEA TOP END システムで BEA Tuxedo の /Q キュー・スペースを利用するためには、キュー・スペースに対する QSPACE エントリを DMCONFIG ファイルの DM_LOCAL_SERVICES セクションで定義し、TE_RTQGROUP、TE_RTQNAME、および TE_TARGET パラメータを指定しなければなりません。TEDG は BEA TOP END システムとの接続時にこれらのパラメータを宣言します。BEA Tuxedo ドメイン内の個々のキュー・スペースの可用性は、接続がアクティブの間はトラッキングされません。
TEDG は要求を受信すると、(RTQ グループ、キュー名、およびターゲットを定義する) queue_info パラメータを使用して、キュー・スペースを決定します。ターゲットが指定されていない場合、ルックアップではターゲットなしが使われます。tp_rtq_put サービス・パラメータによって /Q キュー名が決定されます。TEDG はメッセージのプロダクト、関数、ターゲット、および関数修飾子と一致する QNAME エントリを DM_LOCAL_SERVICES セクションで検索します。取得したキュー・スペースおよびキュー名パラメータを使用し、tpenqueue(3c) と同等の関数を呼び出してメッセージをキューに登録します。デフォルト値が tpenqueue のオプションのパラメータに使用されます。たとえば、RTQ 要求から優先順位はマッピングできません。したがって、デフォルトが使用されます。メッセージがキューに登録された後、BEA Tuxedo の管理者は qmadmin を使って /Q キューの属性およびその中のメッセージを変更できます。
TEDG は TMQUEUE(5) サーバによって返されるステータスをマッピングし、BEA TOP END クライアントに返します。要求をキューに登録すると、TEDG はクライアントに返すための一意の RTQ request_id を割り当てます。request_id は要求のステータスをトラッキングする目的でのみ提供されます。ほかの管理目的に使用することはできません。
/Q キューに登録されたメッセージの受信側では、tpdequeue(3c) を呼び出すか、または TMQFORWARD(5) でメッセージをサービス要求に変換して、通常の方法でメッセージにアクセスします。受信するバッファ・タイプは、送信されるメッセージ型および DMCONFIG パラメータで決まります。TPQCTL 構造体のフィールドには適切な値が設定されますが、優先順位、相関識別子、応答キュー、異常終了キュー、ユーザ戻りコードなどの機能は TEDG ではサポートされていません。これらの機能に対しては値が設定されないか、またはデフォルト値が設定されます。appkey および cltid フィールドには、メッセージを送信したクライアントの BEA Tuxedo ユーザ ID (リモート・ドメインの DOMAINID) が設定されます。
TEDG と BEA TOP END クライアントの動作
BEA TOP END クライアントでは、TEDG を介してメッセージを BEA Tuxedo の /Q キューに登録するために tp_rtq_put(3T) 呼び出しを使用します。
BEA TOP END クライアントのプログラマは次の情報を把握していることが必要です。
CARRAY および X_OCTET タイプのバッファでは、異なるタイプの BEA TOP END ノードによって TEDG に送信される場合、データ・マーシャリングはサポートされていません。BEA Tuxedo サービスが FML32 入力をサポートしている場合、BEA TOP END クライアントは BEA Tuxedo FML32 バッファ・タイプを使用します。FML32 は、TEDG と異なるタイプの BEA TOP END ノード間を送信される場合、TEDG と BEA TOP END システムでデータ・マーシャリングがサポートされているため有用です。
BEA TOP END サービスはこれらのバッファ・タイプの 1 つ以上をサポートしています。
tp_rtq_put 要求を行うには、目的の BEA Tuxedo キュー名に関連するプロダクト、関数、MSR ターゲット (オプション)、および関数修飾子 (オプション) を service パラメータに指定することが必要です。
TEDG によるクライアント RTQ 要求のマッピング
クライアント要求にはトランザクションに関与するものとしないものがあります。次の表は、BEA TOP END クライアントの RTQ フラグおよびパラメータがどのようにマッピングされるかを示しています。これらのフラグおよびパラメータのマッピングにより、通常 BEA TOP END システムで行われるタスクを TEDG で実行することができます。TP_RTQ_HELD フラグと TP_RTQ_NON_TRANSACT_SCHED フラグ、トランザクション・キー機能、およびパラメータ tag_length、tag_text、input_format、attach_info は TEDG ではサポートされていないため、TEDG への要求では使用しないでください。
エラー値 TEDG、BEA Tuxedo システム、または BEA Tuxedo TMQUEUE サーバに問題がある場合、通常の BEA TOP END エラー・ステータス・メッセージおよびその他のステータス・メッセージが BEA TOP END クライアントに返されます。1 つのエラー・ステータス・メッセージは、複数の原因のうちの 1 つにしかすぎない場合があることに注意してください。 TEDG が宣言する RTQ キューは実際の BEA Tuxedo キュー・スペースの可用性に基づくわけではないので、実際にはそのキュー・スペースが利用できない BEA Tuxedo ノードにメッセージがルーティングされることもあります。その場合、ほかのルーティング決定では要求は正常に行われても、エラー・ステータス TP_RTQ_UNAVAIL が返されます。RTQ キューを複数のノードで利用できる場合、BEA Tuxedo アプリケーション、BEA TOP END アプリケーション、および TEDG の設計ではこの種の障害が発生する可能性を考慮する必要があります。複数の再起動可能なサーバを定義したアプリケーションであれば、このようなエラーが発生する可能性は低くなります。
関連項目
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
