| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| 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 システムでは異なるスタイルの会話型メッセージ送信がサポートされています。
TEDG では、BEA TOP END の擬似会話を BEA Tuxedo 会話型モデルにマッピングすることができます。これにより、BEA Tuxedo クライアントは BEA TOP END サーバとのマルチステップ対話のコンテキストを保持できます。また逆に、BEA TOP END クライアントが BEA Tuxedo サーバとのコンテキストを保持することもできます。マルチステップの対話は、会話が終了するまで、同じサーバにルーティングされます。会話型コンポーネント間ではシングルステップの対話も行われます。同じサーバでシングルステップとマルチステップの両方の対話を処理する必要がある場合は、会話型メッセージングを使用しなければなりません。
関連項目
BEA Tuxedo クライアントから BEA TOP END サーバへのメッセージの送信
BEA Tuxedo クライアントは TEDG を介して BEA TOP END サービスと会話型通信を行います。BEA Tuxedo クライアントに対し、TEDG はローカル会話型サーバの機能を果たします。TEDG は、DMCONFIG ファイルの DM_REMOTE_SERVICES セクションの SERVICE エントリで定義されるサービスを宣言します。BEA TOP END サーバが擬似会話をサポートしている場合、BEA Tuxedo の管理者は DMCONFIG ファイルの DM_REMOTE_SERVICES セクションの SERVICE エントリに CONV=Y を指定して、そのサーバで提供されるサービスを会話型サービスに設定する必要があります。TEDG サービスに対する SERVICE エントリに CONV=Y が指定されている場合、BEA Tuxedo クライアントはそのサービスと会話モードでのみ通信できます。BEA Tuxedo クライアントは、tpconnect(3c)、tpsend(3c)、tprecv(3c)、および tpdiscon(3c) 関数を使用します。
TEDG は要求されているサービス名から DM_REMOTE_SERVICES セクションの SERVICE エントリを検索し、マッピングされる BEA TOP END 要求に対し、対応する BEA TOP END プロダクト、関数、MSR ターゲット、および関数修飾子を決定します。必要に応じて、メッセージが BEA TOP END システムに送信される前に、TEDG でデータ・マーシャリングが行われます。次に、BEA TOP END システムはメッセージを受信した BEA TOP END ノード上のサーバに要求をルーティングします。必要に応じて、BEA TOP END サーバの応答はマーシャリング解除されます。TEDG は要求のステータスをマッピングし、応答を BEA Tuxedo クライアントに送信するためのバッファを準備します。
BEA TOP END サーバは、アプリケーション・コンテキストを使用して、BEA Tuxedo クライアントとの会話を継続するかどうかを決定します。アプリケーション・コンテキストが存在する限り、会話は保持されます。アプリケーション・コンテキストが存在しなければ、会話は終了します。
TEDG と BEA Tuxedo クライアントの動作
BEA Tuxedo クライアントのプログラマは、tpconnect(3c) を使用して BEA TOP END サーバとの会話を確立します。サーバは会話型応答を行うか、または 1 つの応答を送信して会話を終了します。通常の BEA Tuxedo の会話に参加するクライアントと異なり、BEA TOP END システムにアクセスするクライアントは、各メッセージに対する応答を受け付けなければなりません。クライアントが各要求の応答を受け取るよう準備するには、tpconnect() 呼び出しおよび以降の tpsend(3c) 呼び出しで TPRECVONLY フラグを設定します。このフラグを設定すると、クライアントはメッセージを受信してから次のメッセージを送信します。BEA TOP END システムから応答を受信するには、BEA Tuxedo の tprecv(3c) 関数を使用します。TPRECVONLY を指定しないか、または TPSENDONLY を設定すると、TEDG は要求を拒否してエラーを記録し、TPEV_SVCERR イベントをクライアントに返します。tpconnect() および tpsend() 呼び出しは、データがあるかどうかに関係なく、同等の BEA TOP END tp_client_send(3T) 呼び出しにマッピングされます。データがない場合は、サーバは長さゼロのメッセージを受信します。
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 メッセージは 30K バイトに制限されているため、クライアント要求はこのサイズを超えることはできません。FML32 メッセージに対しては、FML インデックスを除いたメッセージにこの制限が適用されます。
TEDG によるクライアント要求のマッピング
クライアント要求にはトランザクションに関与するものとしないものがあります。次の表は、BEA Tuxedo クライアントのフラグが BEA TOP END 要求にどのようにマッピングされるかを示しています。ほかのすべてのフラグ (TPNOBLOCK、TPNOTIME、TPSIGRSTRT) は、アプリケーションにローカルであるか、または BEA Tuxedo システム内のクライアントと TEDG 間対話にのみ影響します。次のフラグを処理することにより、通常 BEA Tuxedo システムで行われるタスクを TEDG で実行することができます。
次の表は、tpconnect(3c) および tpsend(3c) のフラグがどのようにマッピングされるかを示しています。
BEA Tuxedo クライアントは、tprecv(3c) を会話における通常の方法で呼び出して、サーバの応答および TEDG エラーを受信します。TEDG は、会話のステータスおよびエラーを、tprecv() で返される tperrno 値またはイベントにマッピングします。 BEA TOP END サーバは raw バッファか FML32 バッファの応答を送信します。raw バッファは、管理者が X_OCTET バッファにマッピングするように設定しない限り、通常は TEDG で CARRAY バッファにマッピングされます。管理者は応答バッファのタイプを CARRAY、X_OCTET、または FML32のいずれかに制限できます。BEA TOP END サービスが互換性のないバッファを返すと、TEDG は TPEOTYPE が設定された tperrno を返します。 TP_APPL_CONTEXT がサーバ応答で設定されない場合、TEDG は TPSUCCESS フラグを設定して tpreturn(3c) と同等の関数を呼び出し、BEA Tuxedo クライアントとの会話を終了します。クライアントは会話の終了を、サーバから返されたデータを伴う TPEV_SVCSUCC イベントと解釈します。TP_APPL_CONTEXT がサーバ応答で設定されると、TEDG は TPRECVONLY フラグを設定して tpsend() の同等関数を呼び出し、BEA Tuxedo クライアントとの会話を保持します。クライアントはこの tpsend() 呼び出しを、サーバから返されたデータを伴う TPEV_SENDONLY イベントと解釈します。 サーバが TP_RESET ステータスとしてエラーを返すと、TEDG は TPFAIL フラグを設定して tpreturn() と同等の関数を呼び出し、BEA Tuxedo クライアントとの会話を終了します。クライアントはこの呼び出しを TPEV_SVCFAIL イベントと解釈します。ほかのエラーは TPEV_SVCERR イベントとして返されます。 注記 tpurcode は TEDG ではサポートされていません。 TPEV_SVCERR または TPEV_SVCFAIL エラーが返されると、会話は終了します。サーバがコンテキストを保持している場合、TEDG は BEA TOP END の対話を切断します (TP_DISCONNECT)。 TEDG と BEA TOP END サーバの動作 BEA TOP END サーバに対し、TEDG は BEA TOP END クライアントの機能を果たします。つまり、マッピングされた BEA Tuxedo クライアント会話型要求を通常の方法で tp_server_receive(3T) を介して受信します。受信されるバッファは、BEA Tuxedo クライアントでサポートされているメッセージに応じて、raw バッファか FML32 バッファのいずれかになります。BEA TOP END サーバは、メッセージを新しい要求か、または BEA Tuxedo クライアントと継続している会話の一部 (TP_APPL_CONTEXT フラグ) として解釈します。BEA TOP END サーバは、標準の BEA TOP END プログラミング要件に従って両方のタイプの要求を処理します。 マップされる BEA Tuxedo クライアント要求に対し、function_qualifier フィールドを使用してマルチステップ会話のステップを示すことはできません。その情報はクライアント・メッセージに埋め込む必要があります。 クライアント要求にはトランザクションに関与するものとしないものがあります。 TEDG による BEA TOP END サーバ送信フラグのマッピング BEA TOP END サーバは通常の方法で、tp_server_send(3T) を使ってクライアント要求に応答します。BEA TOP END システム、TEDG コンフィギュレーション、および BEA Tuxedo クライアントでのサポートに応じて、応答バッファは raw バッファか FML32 バッファのいずれかになります。このバッファは BEA Tuxedo クライアントのバッファにマッピングされます。サーバは TP_APPL_CONTEXT フラグを設定せずに tp_server_send(3T) 応答を送信して、会話を終了します。 サーバがコンテキストを保持する場合、そのサーバで TP_APPL_CONTEXT フラグが tp_server_send(3T) 応答に設定されます。このフラグは、会話を継続して対話をコンテキスト・モードで保持するよう TEDG に指示します。BEA TOP END システムは、それ以降の対話で TEDG から送られる会話メッセージを同じサーバにルーティングします。サーバは、対話をリセットするかまたは応答バッファにアプリケーション定義のフィールド値を設定して応答することにより、エラーを示します。BEA Tuxedo クライアントは、エラーに対処するようにプログラムされなければなりません。 次の表は、BEA TOP END の tp_server_send(3T) フラグがどのようにマッピングされるかを示しています。TEDG への応答で output_format および attach_info パラメータを使用しないでください。これらのパラメータはサポートされていません。
TPEV_SVCERR または TPEV_SVCFAIL エラーが返されると、会話は終了します。サーバがコンテキストを保持している場合、TEDG は BEA TOP END の対話を切断します (TP_DISCONNECT)。 エラー値 TEDG、BEA TOP END システム、または BEA TOP END サーバに問題がある場合、次のエラー値が BEA Tuxedo クライアントに返されます。1 つのエラー値は、複数の原因のうちの 1 つにしかすぎない場合があることに注意してください。 TEDG が宣言するサービスは実際の BEA TOP END サービスの可用性に基づくわけではないので、実際にはそのサービスを利用できない BEA TOP END ノードにメッセージがルーティングされることもあります。その場合、ほかのルーティング決定では要求は正常に行われても、TPEV_SVCERR エラーが返されます。サービスを複数のノードで利用できる場合、BEA Tuxedo アプリケーション、BEA TOP END アプリケーション、および TEDG の設計ではこの種の障害が発生する可能性を考慮する必要があります。複数の再起動可能なサーバを定義したアプリケーションであれば、このようなエラーが発生する可能性は低くなります。
関連項目
BEA TOP END クライアントから BEA Tuxedo サーバへのメッセージの送信
BEA TOP END クライアントは、要求/応答モードと同じように、会話モードで要求を BEA Tuxedo サーバに送信します。TEDG は 以下の表に基づいてサーバとの会話を管理します。
TEDG と BEA TOP END クライアントの動作 クライアントの動作は任意の BEA TOP END クライアントで使用する関数と同じ関数でプログラミングされます。
これらの関数を通常の方法で使用し、TEDG を介して BEA Tuxedo サーバにサービス要求を行います。 BEA TOP END クライアントのプログラマは次の情報を把握していることが必要です。
BEA Tuxedo サービスが FML32 による入力をサポートしている場合、BEA TOP END クライアントは FML32 メッセージ・タイプを使用する必要があります。FML32 は、TEDG と異なるタイプの BEA TOP END ノード間を送信される場合、TEDG と BEA TOP END システムでデータ・マーシャリングがサポートされているため有用です。
BEA Tuxedo サービスはこれらのバッファ・タイプの 1 つ以上をサポートしています。
TEDG によるクライアント要求のマッピング
クライアント要求にはトランザクションに関与するものと関与しないものがあります。応答は必ず必要です。次の表は、BEA TOP END クライアントのフラグがどのようにマッピングされるかを示しています。これらのフラグのマッピングにより、通常 BEA TOP END システムで行われるタスクを TEDG で実行することができます。TEDG への要求では、input_format および attach_info パラメータを使用しないでください。これらのパラメータはサポートされていません。
BEA TOP END クライアントに返されるステータス値および拡張されたステータス値は、標準の値です。エラー値のマッピングについては、エラー値を参照してください。 TEDG は BEA Tuxedo システムまたはサーバの応答を、tp_client_receive(3T) 呼び出しを介して BEA TOP END クライアントがアクセスする応答にマッピングします。BEA Tuxedo サーバは、CARRAY、X_OCTET、FML32 のいずれかのバッファ・タイプで応答を送信する必要があります。CARRAY または X_OCTET バッファは、TEDG によって raw メッセージにマッピングされます。FML32 バッファは BEA TOP END FML32 メッセージにマッピングされます。管理者は応答バッファのタイプを CARRAY、X_OCTET、または FML32のいずれかに制限できます。BEA Tuxedo サービスが互換性のないバッファを返すと、TEDG は TP_RESET ステータスを返します。 TEDG と BEA Tuxedo サーバの動作 BEA Tuxedo サーバに対し、TEDG は会話型 BEA Tuxedo クライアントの機能を果たします。つまり、マッピングされた BEA TOP END クライアント要求を通常の方法で受信します。TEDG はメッセージを送信した後、常に制御権を放棄します。その結果、
受信するバッファのタイプは CARRAY、X_OCTET、または FML32 のいずれかであり、クライアントから送信されるメッセージに依存します。BEA Tuxedo サーバは要求を通常の方法で処理します。クライアント要求にはトランザクションに関与するものとしないものがあります。
BEA Tuxedo サーバはクライアント要求に対し通常の方法で応答します。会話を継続する場合、TPRECVONLY フラグおよびデータとともに tpsend(3c) を呼び出します。この場合、サーバはさらに tprecv(3c) を呼び出して、次のクライアント・メッセージ、エラー表示、または会話が終了したことの通知 (TPEV_DISCONIMM) を受信しなければなりません。会話の最後のメッセージを送信するには、TPSUCCESS フラグを設定して tpreturn(3c) を呼び出します。会話を終了してエラーを示すには、TPFAIL フラグを設定して tpreturn() を呼び出します。応答メッセージは tpsend または TPSUCCESS でのみサポートされます。アプリケーション定義の戻りコード rcode は TEDG ではサポートされていません。
BEA TOP END システム、TEDG コンフィギュレーション、および BEA TOP END クライアントでサポートされているバッファ・タイプに応じて、BEA Tuxedo サーバのバッファは CARRAY、X_OCTET、または FML32 バッファのいずれかになります。このバッファは、TEDG によるクライアント要求のマッピング で説明するとおり BEA TOP END メッセージにマッピングされます。サーバは、TPFAIL を呼び出すかまたは応答バッファにアプリケーション定義のフィールド値を設定して応答することにより、エラーを示します。BEA TOP END クライアントはそれに従ってプログラミングされなければなりません。会話を終了するには、クライアントは tp_client_signoff(3T) を呼び出すか、または別のサービスを呼び出す関数スイッチを実行して、対話を終了します。
BEA TOP END メッセージは 30K バイトに制限されているため、BEA Tuxedo サーバの応答はこのサイズを超えることはできません。FML32 メッセージに対しては、FML インデックスを除いたメッセージにこの制限が適用されます。
TEDG による BEA Tuxedo サーバのフラグのマッピング
次の表は、フラグが BEA Tuxedo サーバ応答を送信する関数 tpsend(3c) にどのようにマッピングされるかを示しています。ほかのすべてのフラグ (TPNOBLOCK、TPNOTIME、TPSIGRSTRT) はアプリケーションにローカルであるか、または BEA Tuxedo システム内のサーバと TEDG 間対話にのみ影響します。
エラー値 TEDG、BEA Tuxedo システム、または BEA Tuxedo サーバに問題がある場合、通常の BEA TOP END エラー・ステータス・メッセージおよびその他のステータス・メッセージが BEA TOP END クライアントに返されます。1 つのエラー・ステータス値は、複数の原因のうちの 1 つにしかすぎない場合があることに注意してください。 TEDG が宣言するサービスは実際の BEA Tuxedo サービスの可用性に基づくわけではないので、実際にはそのサービスが利用できない BEA Tuxedo ノードにメッセージがルーティングされることもあります。その場合、ほかのルーティング決定では要求は正常に行われても、TP_SERVICE エラーが返されます。サービスを複数のノードで利用できる場合、BEA Tuxedo アプリケーション、BEA TOP END アプリケーション、および TEDG の設計ではこの種の障害が発生する可能性を考慮する必要があります。複数の再起動可能なサーバを定義したアプリケーションであれば、このようなエラーが発生する可能性は低くなります。
関連項目
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
