|
|
トランザクション管理では、トランザクションの成否に関係なく、トランザクション完了の調整が可能です。トランザクション内では、アプリケーション・プログラマによるリモート・サービス実行のリクエスト、またはリモート・ドメインのユーザーによるローカル・サービス実行のリクエストが可能です。Domainsトランザクション管理では、リモート・トランザクションのローカル・トランザクションへのマッピング、およびこれらのトランザクションの正常終了(コミットまたはロールバック)が調整されます。
Oracle Tuxedoシステムでは、トランザクション・ツリーは2レベルで構成されており、ルートはグローバル・トランザクションを調整するグループであり、ブランチはトランザクションに関連するその他のマシン上のグループです。各グループは他のグループからは独立してグローバル・トランザクションの一部を実行します。したがって、各グループは暗黙的にトランザクション・ブランチを定義します。このOracle Tuxedoトランザクション・ブランチがTMA OSI TPドメインによって制御される場合、実際のOSI TPトランザクション・ブランチが複数含まれる場合があります。TMA OSI TPゲートウェイでは単一のOracle Tuxedoトランザクション・ルートおよび多数のOSI TPトランザクション・ブランチが制御されます。Oracle Tuxedoシステムでは、トランザクション・マネージャ・サーバー(TMS)を使用してグローバル・トランザクションの完了を調整し、各ブランチが完了したことを確認します。
Domainsでのトランザクション管理は、次のようにまとめることができます。
Open Group DTPモデルのトランザクション・マネージャ(TM)は、リソース・マネージャ(RM)との密結合または疎結合関係を定義してトランザクション・ツリーを構築できます。関係の結合は、DMCONFIGファイルでのローカル・サービスの定義方法によって決定されます。
密結合関係では、1つのグローバル・トランザクションに参加し、1つのRMにアクセスするすべてのプロセスで同じトランザクション識別子(XID)が使用されます。この関係によってプロセス間のデータを最大限に共有できます。つまり、XA準拠のRMでは、同じXIDのプロセスによって使用されるリソースがロックを共有するとみなされます。
Oracle Tuxedoシステムでは、グループ・コンセプトによる密結合関係、つまり、同一トランザクション・ブランチに属する特定のグローバル・トランザクションのかわりに、グループによる処理を実現します。すべてのプロセスには同一のXIDが付与されます。疎結合関係では、TMはグローバル・トランザクションに参加する各作業に対してトランザクション・ブランチを生成します。RMは各トランザクション・ブランチを別々に処理します。トランザクション・ブランチ間ではデータやロックは共有されません。トランザクション・ブランチ間でデッドロックが発生する場合があり、そのためグローバル・トランザクションがロールバックされます。Oracle Tuxedoシステムでは、1つのグローバル・トランザクションに様々なグループが参加している場合、グループごとにトランザクション・ブランチが定義され、疎結合関係が確立されます。TMA OSI TPインスタンスはユーザーが構成可能であり、疎結合関係を確立することによって、2つのドメイン間の相互操作で必要なトランザクション・ブランチを最小限にし、デッドロック問題を解決できます。
次の図では、疎結合および密結合の統合を示し、これについて説明します。
図2-1に示す密結合の統合のトランザクション・ツリーでは、2つのドメイン間の相互操作に必要なトランザクション・ブランチ数を最小限にし、トランザクション間のデッドロックの可能性を排除します。アプリケーションAは3つのリクエスト(r1、r2、r3)をリモート・ドメインBに対して作成します。OSI TPは同じOSI TPトランザクション(T1)にマップされた3つのリクエストすべてを送信します。ドメインBでは、TMA OSI TPゲートウェイがリモート・サービスについてCOUPLINGフラグをチェックし、サービスBがCOUPLING=TIGHTであることを検出します。この場合、サービスBに対するすべてのリクエストは同一のOracle Tuxedoシステム・トランザクションに属しています。サービスBに対するそれぞれのリクエストは前述のリクエストに追加され、すべて同一のOracle Tuxedo XID(T2)が付与されます。グループG1のリソースは切り離されず、このトランザクションのためのサービスBのインスタンスに対する変更が他のグループに対して表示されます。リクエストr4はドメインBの識別子T2にマップされますが、Tuxedoドメインによって、このトランザクション・ツリー(r4: BからA')に対して新規ブランチが生成されます。これはドメインAの新規トランザクション・ブランチであるため、ゲートウェイによって新規マッピングT3が新規Oracle Tuxedoシステム・トランザクションに対して生成されます。ドメインAのゲートウェイ・グループでもグループG4が調整され、ドメイン間接続の階層構造はこのマッピングで完全に有効になります。グループG4はグループG1の後にコミットされます。
図2-2に示す疎結合の統合のトランザクション・ツリーでは、クライアントが開始したグローバル・トランザクションを調整するドメインAのグループG0を示しています。この場合、アプリケーションAは3つのリクエスト(r1、r2、r3)をリモート・ドメインBに送信します。密結合の場合と同様に、3つのブランチはすべて、OSI TPトランザクションT1に表示されます。ドメインBでは、TMA OSI TPゲートウェイでリモート・サービスのCOUPLINGフラグをチェックし、サービスBがCOUPLING=LOOSEであることを確認します。この場合、TMA OSI TPゲートウェイでは3つのOracle Tuxedoシステム・トランザクションT2、T3およびT4が生成されます。G1に対する変更は独立しています。たとえば、サービスBによる変更は、サービスB'には表示されません。BがA'をコールバックすると、新規トランザクションT5が生成されます。
単一のOracle Tuxedoアプリケーション内のグローバル・トランザクションは2レベル・トランザクション・ツリーに従いますが、ドメイン間のグローバル・トランザクションはより複雑なトランザクション・ツリーに従います。この理由は2つあります。
ドメイン間のコミット・プロトコルは、複雑なトランザクション・ツリー構造を処理できるように階層的である必要があります。たとえば、ループバック・サービス・リクエストはあるドメイン(ドメインA)から別のドメイン(ドメインB)に対して送信され、元のドメインでの処理用に戻されます。ドメインBのサービスは、ドメインAの別のサービスをリクエストします。トランザクション・ツリーには、ネットワーク・レベルの2つのブランチがあります。つまり、AからBへのブランチb1、およびBからAへのブランチb2です。ドメインAは、Bからコミットの指示を受けるまで、ブランチb2での作業完了をコミットできません。
TMA OSI TPのインスタンスは、オプションで密結合関係を実現することにより、GTRIDマッピングを最適化します。TMA OSI TPでは、同じグローバル・トランザクションから発行されたサービス・リクエストは、同じネットワーク・トランザクション・ブランチにマップされます。したがって、受信したサービス・リクエストは、1つのOracle Tuxedトランザクションにマップされます。ただし、ドメイン間通信の階層構造とドメイン間トランザクション・ツリーは保持される必要があります。密結合関係の例については、図2-1を参照してください。
TMA OSI TPによる最適化処理は、単一のドメインに対してのみ適用されます。トランザクションに複数のドメインが関係する場合、ネットワーク・トランザクション・ツリーには、ドメイン間の通信ごとに少なくとも1つのブランチが必要です。したがって、ドメインにまたがるネットワーク・トランザクション・ツリーは疎結合のままになります。トランザクション・ブランチの数は、トランザクション内のドメインの数になります。これは、すべてのブランチが同じリソース・マネージャ・インスタンスにアクセスしている場合も同じです。Domainsゲートウェイ・グループは、ドメイン間トランザクションについては異なるトランザクション・ブランチを生成するため、疎結合関係を実現します。
疎結合関係の例については、図2-2を参照してください。ここでも、ゲートウェイでは、Oracle Tuxedoトランザクションとネットワーク・トランザクションの間のマッピングを実行する必要があり、ドメイン間通信の階層構造も維持されている必要があります。図2-2では、リクエストr1、r2およびr3が1つのTMA OSI TPトランザクション・ブランチにマップされています。このため、ドメインBで生成される必要があるものは、1つのOracle Tuxedoトランザクションのみです。リクエストr4はドメインBの識別子にマップされますが、TMA OSI TPはそのトランザクション・ツリー(r4: BからA')に新規ブランチを生成します。これはドメインAの新規ブランチであるため、ゲートウェイは新規Oracle Tuxedoトランザクションに対する新規マッピングを生成します。グラフでは、ドメインAのゲートウェイ・グループGWが、グループG4も調整する様子を示します。このため、ドメイン間通信の階層構造はこのマッピングによって強化されます。グループG4はグループG1より先にコミットすることはできません。
OSI TPは2フェーズ・コミット・プロセスの第2フェーズでエラーが発生した場合に、個々のダイアログのトランザクション全体をリカバリすることができます。コミットの第2フェーズの前に発生したエラーについては、トランザクションは自動的にロールバックされます。コミットの第2フェーズの開始後に発生するエラーのタイプは3種類あります。このようなエラーのタイプについては、次のトランザクション・リカバリ・サービスのアクションが実行されます。
TMA OSI TPソフトウェアは型付きバッファを使用してデータを送受信します。次のバッファ・タイプでは、完全なバッファ変換がサポートされています。
| 注意: | Null X_OCTETバッファはサポートされていません。 |
次の項では、TMA OSI TPがデータ・バッファを処理する手順について説明します。
XATMI(X/Open Application Transaction Manager Interface)のOSI TPへのマッピングはXATMI ASE(アプリケーション・サービス要素)で定義されています。Oracle TMA OSI TPではこの組合せをサポートしています。TMA OSI TPを使用する相互運用性を実現するには、リモート・システムでXATMI ASEをサポートする必要があります。このため、STRING、VIEW、FMLおよびCARRAYなどのTuxedo固有のバッファ・タイプをXATMI標準タイプに変換する必要が生じます。Oracle TMA OSI TP Gatewaysでは、これらのレイアウト変換を暗黙的に実行します。
Abstract Syntax Notation 1(ASN.1)はバイト順、単語の長さ、文字セットなど、データ表現の違いを扱うための基準となる表現を示す国際規格です。ローカル・ゲートウェイ(GWOSITP)はローカル・クライアント・プログラムからの入力をエンコードします。これによって、リモート・サービスに送信するASN.1エンコード・レコードが作成されます。応答を受信すると、クライアントに戻す前にデコードされます。同様に、ローカル・サービスからのリモート・リクエストをローカル・ゲートウェイが受信すると、ASN.1形式からデコードされます。次に応答がエンコードされ、リモート・クライアントに戻されます。
次の用語は、入力データおよび出力データの説明に使用されます。
これらの用語は、TMA OSI TPによる入出力データの処理方法の理解を容易にするものです。
TMA OSI TPゲートウェイでは、次のようにローカル・プログラムからのバッファを処理します。
TMA OSI TP製品では、ローカル・クライアント・プログラムからリモート・サービスに送信された入力バッファが自動的に「型付き」にされます。
TMA OSI TP製品では、ローカル・サービスからリモート・クライアント・プログラムに戻された出力バッファが自動的に「型付き」にされます。
DMCONFIG)が参照され、バッファを別の形式に変換する必要があるかどうかが判別されます。 リモート・サービスに送信されたクライアント・リクエストは、これらのサービスで意味のあるレコード形式に変換する必要があります。
リモート・クライアント・プログラムに戻されたサーバー・レスポンスは、これらのプログラムで意味のあるレコード形式に変換する必要があります。
TMA OSI TPゲートウェイでは、次のようにリモート・プログラムからのレコードを処理します。
DMCONFIG)が参照され、レコード・タイプ、およびそのレコードを別の形式に変換する必要があるかどうかが判別されます。 リモート・クライアント・プログラムからのクライアント・リクエストは、ローカル・サービス・ルーチンで受入れ可能なバッファ形式に変換する必要があります。
リモート・サービスから戻されたサーバー・レスポンスは、ローカル・クライアント・プログラムで受入れ可能なバッファ形式に変換する必要があります。
TMA OSI TP製品では、バッファとレコードのマップに使用できる4つの構成パラメータが用意されています。これらのパラメータはオプションです。
次のバッファ構成パラメータは、ドメイン構成ファイル(DMCONFIG)で必要に応じてDM_LOCAL_SERVICESおよび/またはDM_REMOTE_SERVICESセクションで指定されます。
これらの4つのパラメータの定義は、サービス・リクエスト元がローカルかリモートかによって決まります。次の項では、これらのパラメータのサービス・リクエスト元について説明します。
この項では、直接のOracle Tuxedoリージョン内での、ローカルによるサービス呼出しのTMA OSI TPでの処理方法について詳しく説明します。また、ローカル・クライアント・プログラムとリモート・サービスの間のバッファおよびレコード変換の管理における、INBUFTYPE、INRECTYPE、OUTRECTYPEおよびOUTBUFTYPEパラメータの使用方法についても説明します。
次の図では、ローカルOracle Tuxedoクライアント・プログラムがサービス呼出しを発行し、TMA OSI TPゲートウェイがその呼出しをTMA OSI TPを介してリモート・サーバーにルーティングしています。
このような状況では、図に示す4つのパラメータは次のような意味を持ちます。
次の項では、ローカルによるサービス呼出し(ローカル・クライアント・プログラムからのリモート・サービスの呼出し)におけるINBUFTYPEおよびINRECTYPEパラメータの使用方法について詳しく説明します。
INBUFTYPEパラメータを使用して、ローカル・クライアント・プログラムがサービス・リクエストを発行する際にローカルTMA OSI TPゲートウェイに渡されるリクエスト・バッファ・タイプを指定します。Tuxedoではこの情報を使用して、ローカル・クライアントからのバッファ・タイプをINBUFTYPEパラメータで定義したタイプに限定します。
INRECTYPEパラメータを使用して、特定のリモート・サービスで必要とされるリクエスト・レコードのタイプ、および一部には形式を指定します。TMA OSI TPゲートウェイはこの情報を使用して、Oracle Tuxedoリクエスト・バッファを、リモート・サービスで処理可能なレコードに変換します。
INRECTYPEパラメータは、リクエスト・バッファのタイプと構造がリモート・サービスで想定されるリクエスト・レコードと同じ場合は省略されます。 次の表に示すケースに該当する場合は、INRECTYPEパラメータを指定する必要があります。
次の項では、ローカルによるサービス呼出し(ローカル・クライアント・プログラムからのリモート・サービスの呼出しおよびサービスからの出力の受信)におけるOUTRECTYPEおよびOUTBUFTYPEパラメータの使用方法について詳しく説明します。
OUTBUFTYPEパラメータを使用して、ローカル・クライアント・プログラムで想定される応答バッファのタイプ、および一部には構造を指定します。TMA OSI TPゲートウェイはこの情報を使用して、リモート・サービスからの応答レコードを、適切な応答バッファにマップします。TMA OSI TPは受信したレコードを、OUTBUFTYPEパラメータで定義したタイプとサブタイプにマップします。
OUTRECTYPEパラメータを使用して、特定のリモート・サービスがローカルTMA OSI TPゲートウェイに戻す応答レコードのタイプ、および一部には形式を指定します。TMA OSI TPは受信したレコードを、OUTBUFTYPEパラメータで定義したタイプとサブタイプにマップします。
OUTBUFTYPEパラメータは、リモート・サービスから戻される応答レコードのタイプと構造がローカル・クライアント・プログラムで想定される応答バッファと同じ場合は省略されます。 次の表に示すケースに該当する場合は、OUTBUFTYPEパラメータを指定する必要があります。
この項では、ローカルのOracle Tuxedoリージョン外での、TMA OSI TPによるリモート・コンピュータからのサービス呼出しの処理方法について詳しく説明します。また、リモート・クライアント・プログラムとローカル・サービスの間のバッファおよびレコード変換の管理におけるINRECTYPE、INBUFTYPE、OUTBUFTYPEおよびOUTRECTYPEパラメータの使用方法についても説明します。
次の図では、リモート・クライアント・プログラムがサービス・リクエストを発行し、TMA OSI TPゲートウェイがそのリクエストをローカルTMA OSI TPゲートウェイにルーティングしています。ゲートウェイはネットワークからリクエストを受け取り、それをローカルOracle Tuxedoサーバーに渡します。
このような状況では、図に示す4つのパラメータは次のような意味を持ちます。
この項では、リモート・システムからのサービス呼出し(リモート・クライアント・プログラムからのローカル・サービスの呼出し)におけるINRECTYPEおよびINBUFTYPEパラメータの使用方法について詳しく説明します。
INBUFTYPEパラメータを使用して、TMA OSI TPゲートウェイで想定されるローカル・サーバーからの応答バッファのタイプ、および一部には構造を指定します。このパラメータによって、このサービスで受け入れるデータ型のバッファ・タイプのネーミング・スペースが単一のバッファ・タイプに限定されます。ゲートウェイでは、実行時にバッファのタイプが自動的に判別されるため、ここでは概念的な補足としてこのパラメータについて説明します。
INRECTYPEパラメータを使用して、ローカルTMA OSI TPゲートウェイがリモート・クライアントに送信する応答レコードのタイプ、および一部には形式を指定します。ローカル・サーバー・プログラムから送信される応答バッファのタイプと構造が、リモート・クライアントで想定される応答レコードと同じ場合は、INRECTYPEパラメータを省略できます。
この項では、リモート・コンピュータよるサービス呼出し(リモート・クライアント・プログラムからのローカル・サービスの呼出しおよびサービスからの出力の受信)におけるOUTBUFTYPEおよびOUTRECTYPEパラメータの使用方法について詳しく説明します。
OUTBUFTYPEパラメータはローカルTMA OSI TPゲートウェイからローカル・サーバーに送信されるリクエスト・バッファを指定します。TMA OSI TPゲートウェイはこの情報を使用して、リモート・クライアントからのリクエスト・レコードをローカル・サーバーが処理可能なバッファに変換します。
OUTRECTYPEパラメータを使用して、特定のリモート・クライアント・プログラムがTMA OSI TPゲートウェイに送信するリクエスト・レコードのタイプ、および一部には形式を指定します。TMA OSI TPは受信したレコードを、OUTRECTYPEパラメータで定義したタイプとサブタイプにマップします。
OUTBUFTYPEパラメータは、ローカル・サービスのリクエスト・バッファのタイプと構造がリモート・クライアント・プログラムから送信されるリクエスト・レコードと同じ場合は省略されます。 次の表に示すケースに該当する場合は、OUTBUFTYPEパラメータを指定する必要があります。
次の図に、考えられるすべてのバッファのレコードへのマッピングを示します。TMA OSI TPゲートウェイは、TMA OSI TP構成にある情報に基づいて、バッファからレコードへマップします。このマッピングは、Tuxedoクライアント・リクエストとTuxedoサーバー・レスポンスについて行われます。
次では、上の図に示す、考えられるマッピングおよび推奨のINRECTYPEパラメータについて説明します。INBUFTYPEパラメータは検証にのみ使用されるため、ここでは説明しません。
CARRAY入力バッファはX_OCTET入力レコードにコピーできます。CARRAYバッファには、変換されないrawデータが含まれます。TMA OSI TPゲートウェイではCARRAY TuxedoバッファがX_OCTETとして自動的にリモート・システムに送信されるため、INRECTYPEパラメータを設定する必要はありません。 STRING入力バッファはX_OCTET 入力レコードにマップできます。データ変換は行われません。STRINGバッファは左から右に、最初のNULL文字に達する部分までコピーされます。ただし、ゲートウェイではデータを送信する前に終了文字が削除されます。TMA OSI TPゲートウェイでは、STRINGバッファがX_OCTETとして自動的に送信されるため、INRECTYPEパラメータを設定する必要はありません。X_OCTET入力バッファにマップできます。XMLバッファはX_OCTETバッファにコピーできます。データは変換されません。これは、XMLデータ型をサポートしていないシステムにXMLデータを渡す際に役立ちます。VIEW入力バッファはX_COMMONまたはX_C_TYPE入力レコードにマップできます。このVIEW定義に必要なレコード・タイプと名前をINRECTYPEパラメータで定義します。TMA OSI TPゲートウェイはVIEWを正しいX_COMMONまたはX_C_TYPE入力レコードに変換します。 VIEW、X_COMMON またはX_C_TYPE入力バッファは、X_COMMONまたはX_C_TYPE入力レコードに任意の組合せでマップできます。ただし、この場合はリモート・サービスで想定されるデータ構造(図3-3の考えられるX_COMMON `B'マッピング)は、クライアント・プログラムで使用するデータ構造(図3-3のVIEW `A')とは異なります。このため、次を実行する必要があります。 X_C_TYPEまたはX_COMMONのいずれかの入力レコード・タイプにマップする必要があります。また、リモート・サービスで想定される入力データ構造のVIEW定義を作成する必要があります。INRECTYPEをVIEW:viewnameに設定します。FML変換に関する詳細は、Oracle Tuxedoのオンライン・ドキュメントを参照してください。| 注意: | ソースとターゲットのVIEW名が異なる場合、TMA OSI TPで実行するすべてのVIEWからVIEWへの変換に、FMLフィールドを指定する必要があります(たとえば、VIEW=V10.V --> X_C_TYPE=V10.VではFMLマッピング・フィールドは不要です)。つまり、VIEWで使用するVIEWから別のVIEWへ、VIEWからFMLへ、またはFMLからVIEWへの 変換は、適切なFMLフィールドで定義する必要があります(VIEW定義のFNAME列に破線はありません)。FMLフィールドを一致させるには、-nオプションを指定せずにVIEWをコンパイルする必要があります。 |
VIEWバッファ・タイプがNATIVE A レコード・タイプに変換されます。この機能により、エンコード/デコード処理の大部分がA-SeriesからTuxedoシステムに移行されます。
次の図に、考えられるすべてのレコードのバッファへのマッピングを示します。TMA OSI TPゲートウェイは、TMA OSI TP構成にある情報に基づいて、レコードからバッファへマップします。このマッピングは、リモート・クライアント・リクエストとリモート・サーバー・レスポンスについて行われます。
次では、上の図に示す、考えられるマッピングおよび推奨の(ローカルからのサービス呼出しの)OUTBUFTYPEパラメータの設定について説明します。この推奨では、データ変換を制御するOUTBUFTYPEパラメータを使用します。
X_OCTET出力レコードはCARRAYまたはX_OCTET出力バッファにコピーできます。CARRAYバッファには、変換されていないrawデータが含まれます。OUTBUFTYPEはCARRAYまたはX_OCTETに設定しますが、OUTRECTYPEを設定する必要はありません。 X_OCTET出力はSTRING出力バッファにもコピーされます。これにより、変換対象にならない文字列が作成されます。X_OCTETからSTRINGへの段階で、Tuxedoアプリケーションの終わりにNULL値が追加されます。その結果、バッファは元のX_OCTETバッファの長さになります。すべての文字がコピーされるため、X_OCTETバッファにNULL文字がある場合は、後でSTRINGとして処理する際にバッファに影響します。OUTBUFTYPEはSTRINGに設定する必要があります。 X_OCTET出力レコードはXML出力バッファにマップされます。データは変換されません。これは、XMLバッファ・タイプをサポートしないシステムからXMLデータ型をサポートするTuxedoドメインへ、XMLバッファを渡す際に役立ちます。VIEW出力バッファにマップされます。この場合、リモート・サービスから戻されるすデータ構造は、ローカル・クライアント・プログラムで想定されるものと同じです。新規VIEW定義を作成する必要はありません。OUTRECTYPEパラメータをVIEW:viewnameに設定するとより大きなタイプのチェックに使用できますが、これは必須ではありません。X_C_TYPEおよびX_COMMON出力レコードは、任意の組合せでVIEW出力バッファにマップできます。ただし、このような状況では、リモート・サービスから戻されるデータ構造(図2-6に示す X_C_TYPE `B')は、クライアント・プログラムで想定されるデータ構造(図2-6のVIEW `A')のデータ構造とは異なります。変換プロセスを容易にするには、次のタスクを実行します。 X_C_TYPEの名前(またはX_COMMON)`B'をOUTBUFTYPEパラメータで指定します(これによって、TMA OSI TPリクエスタで自動検出された値をオーバーライドします)。 OUTBUFTYPEパラメータで指定されている既存ビュー(図のVIEW `A')の出力バッファ・タイプと名前を指定します。| 注意: | FMLフィールド定義はVIEW 'B'からVIEW 'A'にマップする場合があります。 |
X_COMMONまたはX_C_TYPE出力レコードは、FML出力バッファにマップされます。変換プロセスを容易にするには、次のタスクを実行します。 OUTBUFTYPEパラメータで指定します(これによって、TMA OSI TPリクエスタで自動検出された値をオーバーライドします)。 DMCONFIGファイルでOUTBUFTYPEをFMLまたはFML32を設定し、後にコロン(:)を付けます(例: OUTBUFTYPE=”FML32:”)。| 注意: | FMLフィールドは、TMA OSI TPで実行するFMLからVIEWへのすべての変換で指定する必要があります。つまり、FMLからVIEWへの変換に使用するVIEWはすべて、適切なFMLフィールドで指定する必要があります(VIEW定義のFBNAME列に破線はありません)。FMLフィールドを一致させるには、-nオプションを指定せずにVIEWをコンパイルする必要があります。 |
NATIVE A出力レコードはVIEW出力バッファにマップできます。
バッファ変換の特殊ケースおよび例について、次に例を示します。
(INBUFTYPE)または(OUTRECTYPE) = STRING、CARRAY、X-OCTET、 またはXMLの場合、変換タイプは STRING、CARRAY、X-OCTET またはXMLにする必要があります。INBUFTYPE = "FML"または"FML32":、あるいはリモート・サービスに送信されるバッファが"FML"または"FML32"のタイプである場合、次のようになります。 リモート・サービスのINRECTYPEは、それぞれ"VIEW"または"VIEW32"に設定する必要があります。
INRECTYPEおよびOUTRECTYPEは"FML"または"FML32"にできません。 INRECTYPE=”FML:”/* ERROR */
OUTRECTYPE=”FML32:”/* ERROR */
INBUFTYPEおよびOUTBUFTYPEについては、バッファ・タイプFMLを次のように設定します。 INBUFTYPE=”FML:”
OUTBUFTYPE=”FML32:”
| 注意: | キーワードFMLおよびFML32の終わりにはコロンが必要です。 |
INBUFTYPEおよびOUTRECTYPEは受信バッファ・タイプ/サブタイプと同じタイプ/サブタイプに設定する必要があります。 dec_tは、ソースまたは宛先バッファがFMLまたはFML32の場合、あるいはソースと宛先のビューが別のものである場合、変換に参加するビューには使用できません。dec_tはNATIVE Aバッファへの変換に参加するビューには使用できません。intのビュー・フィールドをタイプlongまたはshortに変更します。“NONE”を使用します。 次の例では、リクエストをサービスに送信する前の、受信バッファX_COMMON:v10のVIEW:v12への変換を示します。
*DM_REMOTE_SERVICES
TOUPPER12
RDOM=DALNT2
LDOM=DALNT19220
PRIO=66
RNAME=”TOUPPER12”
INBUFTYPE=”X_COMMON:v10”
INRECTYPE=”VIEW:v12”
次の例では、リクエストをローカル・サービスに送信する前の、受信バッファVIEW:v12 のFMLへの変換、応答をリモート・クライアントに戻す前のFMLのX_C_TYPE:v16への変換を示します。
*DM_LOCAL_SERVICES
OUTRECTYPE=”VIEW:v12”
OUTBUFTYPE=”FML:”
INBUFTYPE=”FML:”
INRECTYPE=”X_C_TYPE:v16”
FMLの詳細は、Oracle Tuxedoオンライン・ドキュメント( http://www.oracle.com/bea/support.html)を参照してください。
Oracle TMA OSI TPではTuxedo XMLバッファ・タイプをサポートしています。XMLバッファはネットワークを介してのみ渡されるため、X_OCTETバッファと同様に扱われます。データは変換されません。
XMLバッファはX_OCTETに変換されなければ、XMLデータ型としてリモート・ドメインに渡されます。リモート・ドメインでXMLデータ型をサポートしていない場合、リモート・ドメインでデコード・エラーが発生します。
  
|