この章の内容は次のとおりです。
トピック:
親トピック: JMSメッセージの取得
パーサーの役割は、JMSテキスト・メッセージ・データとヘッダー・プロパティを適切なトランザクションと操作のセットに翻訳し、VAMインタフェースに渡すことです。これを行うために、パーサーは必ず特定のデータを検出する必要があります。
構成で必要とされる場合、他のデータが使用されます。
パーサーは、このデータをJMSヘッダー・プロパティ、システム生成値、静的な値から、またはパーサー固有の方法で取得できます。これは、情報の性質によって異なります。
Oracle GoldenGateメッセージ取得アダプタでは、3種類のパーサーがサポートされます。
固定 - メッセージは、連続したテキストに固定幅フィールドとして表されるデータを含みます。
区切り - メッセージは、フィールドとレコード終端文字で区切られたデータを含みます。
XML - メッセージは、XPath式でアクセスされるXMLデータを含みます。
パーサーがメッセージを翻訳するには、次の情報が必要です。
シーケンス識別子(seqid
)によって、各操作が内部で識別されます。これはリカバリ処理時に使用され、Oracle GoldenGate証跡に書込み済の操作が識別されます。シーケンス識別子は、操作ごとに増分される一意の値です。長さは固定です。
プロバイダのメッセージ識別子が増分され、一意の場合、JMSメッセージIDをシーケンス識別子として使用できます。ただし、(クラスタリングの使用や失敗したトランザクションなどのため)JMSでメッセージの順序が保証されない場合やIDは一意ではあるが、増分されない場合があります。システム生成のシーケンスIDを使用できますが、リカバリの状況によってはメッセージが重複する場合があります。推奨される方法は、メッセージをキューに追加するJMSクライアントでメッセージID、ヘッダー・プロパティまたはデータ要素をアプリケーションで生成される一意の増分値に設定することです。
表名を使用して、列データが属する論理表が識別されます。アダプタは、SCHEMA_NAME.TABLE_NAME
形式の2つの部分で構成される表名を必要とします。これは、個別に(schemaおよびtable
)定義するか、スキーマと表の組合せとして(schemaandtable
)定義します。
1つのフィールドにスキーマ名と表名の両方が含まれることも、スキーマ名と表名が別々のフィールドに含まれることも、スキーマがソフトウェア・コードに含まれ、表名のみが必要なこともあります。スキーマ名と表名の指定方法は、パーサーによって異なります。いずれの場合も、2つの部分で構成される論理表名を使用してOracle GoldenGate証跡にレコードが書き込まれ、証跡を表すソース定義ファイルが生成されます。
操作タイプ(optype
)を使用して、Oracle GoldenGate証跡への書込み時に操作が挿入、更新、削除のいずれであるかが決定されます。特定の操作の操作タイプ値は、各操作タイプに定義された値と照合されます。
各操作タイプについてOracle GoldenGate証跡に書き込まれるデータは、Extractの構成によって異なります。
挿入
すべての列のアフター値が証跡に書き込まれます。
更新
デフォルト - キーのアフター値が書き込まれます。ビフォア値が存在し、比較可能な場合、変更された列のアフター値が書き込まれます。ビフォア値がない場合、すべての列が書き込まれます。
NOCOMPRESSUPDATES
- すべての列のアフター値が証跡に書き込まれます。
GETUPDATEBEFORES
- ビフォア値が存在し、比較可能な場合、変更された列のビフォア値とアフター値が証跡に書き込まれます。ビフォア値がない場合、アフター値のみが書き込まれます。
NOCOMPRESSUPDATES
とGETUPDATEBEFORES
の両方が含まれ、ビフォア値が存在する場合、すべての列のビフォア値とアフター値が証跡に書き込まれます。
削除
デフォルト - すべてのキーのビフォア値が証跡に書き込まれます。
NOCOMPRESSDELETES
- すべての列のビフォア値が証跡に書き込まれます。
キーのビフォア値が存在し、アフター値と一致しない場合、主キー更新操作も生成されます。
すべてのパーサーは列データをメッセージ・テキストから取得し、Oracle GoldenGate証跡に書き込みます。列は、ソース定義で定義されている索引順に読み取られる場合もあれば、名前でアクセスされる場合もあります。
構成および元のメッセージ・テキストに応じて、列データのビフォア・イメージとアフター・イメージの両方が使用可能な場合とアフター・イメージのみが使用可能な場合があります。更新の場合、更新されていない列が使用可能な場合と使用可能でない場合があります。
すべての列データはテキストとして取得されます。ソース定義に基づいて、その列の正しいデータ型に内部で変換されます。変換に問題があるとエラーになり、プロセスは異常終了します。
次のデータを含めることができますが、必須ではありません。
各メッセージに1つのトランザクション
これは、メッセージのスコープによって自動的に決定されます。
各メッセージに複数のトランザクション
これは、トランザクション・インジケータ(txind
)によって決定されます。トランザクション・インジケータがない場合、XMLパーサーは、対応するトランザクション・ルールに基づいてトランザクションを作成できます。
各トランザクションに複数のメッセージ
操作がトランザクションの先頭か、中間か、末尾かトランザクション全体かを指定するために、トランザクション・インジケータ(txind
)が必要です。特定の操作のトランザクション・インジケータ値は、各トランザクション・インジケータ・タイプに定義された値と照合されます。インジケータ値が先頭または全体の場合はトランザクションが開始され、中間の場合は続行されます。末尾または全体の場合は終了されます。
固定幅解析は、各フィールドの位置と長さを定義するデータ定義に基づきます。この形式は、Cobolコピーブックの形式です。プロパティのセットで、コピーブックをOracle GoldenGate証跡およびソース定義ファイルの論理レコードにマップするためのルールを定義します。
受信データは、標準形式のヘッダーとその後に続くデータ・セグメントで構成されます。両方とも固定幅のフィールドを含みます。データは、コピーブックのPIC定義に基づいて解析されます。「ヘッダーとレコード・データ型の翻訳」の説明のように翻訳されて証跡に書き込まれます。
ヘッダーは、次の情報を含むコピーブック01レベル・レコードによって定義される必要があります。
Oracle GoldenGateヘッダー・フィールドにマップされないヘッダー・レコードのフィールドは列として出力されます。
次の例では、必須ヘッダー値を含むコピーブック定義を示します。
例5-1 ヘッダーの指定
01 HEADER. 20 Hdr-Timestamp PIC X(23) 20 Hdr-Source-DB-Function PIC X 20 Hdr-Source-DB-Rec-ID PIC X(8)
前述の例に対して次のプロパティを設定します。
fixed.header=HEADER fixed.timestamp=Hdr-Timestamp fixed.optype=Hdr-Source-DB-Function fixed.table=Hdr-Source-DB-Rec-Id
この場合の論理名表出力は、Hdr-Source-DB-Rec-Id
という値になります。
複数のフィールドを表名に使用できます。たとえば、次のような静的プロパティを介して論理スキーマ名を定義できます。
fixed.schema=MYSCHEMA
コピーブック・ヘッダー定義から複数フィールドのデータ・レコードを定義するプロパティを追加できます。
例5-2 複合表名の指定
01 HEADER. 20 Hdr-Source-DB PIC X(8). 20 Hdr-Source-DB-Rec-Id PIC X(8). 20 Hdr-Source-DB-Rec-Version PIC 9(4). 20 Hdr-Source-DB-Function PIC X. 20 Hdr-Timestamp PIC X(22).
前述の例に対して次のプロパティを設定します。
fixed.header=HEADER fixed.table=Hdr-Source-DB-Rec-Id,Hdr-Source-DB-Rec-Version fixed.schema=MYSCHEMA
フィールドが連結されて、次のような論理スキーマと表名になります。
MYSCHEMA.Hdr-Source-DB-Rec-Id+Hdr-Source-DB-Rec-Version
ヘッダーのデータとレコード・データは、翻訳されたデータ型に基づいて証跡に書き込まれます。
日付形式のコメントが前に付いたフィールド定義は、指定されたサイズのOracle GoldenGate日時フィールドに翻訳されます。日付形式のコメントがない場合、フィールドは基になるデータ型によって定義されます。
PIC X
フィールドは、指定されたサイズのCHAR
データ型に翻訳されます。
PIC 9
フィールドは、定義された精度と位取りのNUMBER
データ型に翻訳されます。符号付きの数値、符号なしの数値、小数部のある数値、小数部のない数値がサポートされます。
次の例では、様々なPIC
定義に対する翻訳を示します。
入力 | 出力 |
---|---|
PIC XX |
CHAR(2) |
PIC X(16) |
CHAR(16) |
PIC 9(4) |
NUMBER(4) |
* YYMMDD PIC 9(6) |
DATE(10) YYYY-MM-DD |
PIC 99.99 |
NUMBER(4,2) |
この例で、入力YYMMDD
日付の100522は、2010-05-22に翻訳されます。指定されたPIC 9(5)V99
形式の数値1234567は、小数部が2桁の7桁の数値12345.67に翻訳されます。
Oracle GoldenGateソース定義ファイルから取得されるデータ定義に基づいて、固定幅解析を使用できます。これは、COBOLコピーブックに類似しています。ソース定義ファイルには、参加している表の各フィールドの位置と長さが含まれているからです。ソース定義ファイルを使用するには、次のプロパティを設定する必要があります。
fixed.userdefs.tables=qasource.HEADER fixed.userdefs.qasource.HEADER.columns=optype,schemaandtable fixed.userdefs.qasource.HEADER.optype=vchar 3 fixed.userdefs.qasource.HEADER.schemaandtable=vchar 30 fixed.header=qasource.HEADER
次の例では、全長が33文字のヘッダー・セクションを定義しています。最初の3文字は操作タイプで、最後の30文字は表名です。解析されるすべてのレコードのレイアウトは、fixed.userdefs
プロパティで定義されている完全なヘッダー・セクションで始まる必要があります。各レコードでは、ヘッダー・セクションの直後に、対応する表のすべての列データの内容が続きます。列データは、ソース定義ファイルで定義されているそのオフセットと長さに従って厳密にレイアウトする必要があります。具体的に言うと、オフセット情報は列定義の4番目のフィールド(Fetch Offset)であり、長さ情報は列定義の3番目のフィールド(External Length)です。GG.JMSCAP_TCUSTMERの定義の例を次に示します。
Definition for table GG.JMSCAP_TCUSTMER Record length: 78 Syskey: 0 Columns: 4 CUST_CODE 64 4 0 0 0 1 0 4 4 0 0 0 0 0 1 0 1 0 NAME 64 30 10 0 0 1 0 30 30 0 0 0 0 0 1 0 0 0 CITY 64 20 46 0 0 1 0 20 20 0 0 0 0 0 1 0 0 0 STATE 0 2 72 0 0 1 0 2 2 0 0 0 0 0 1 0 0 0 End of definition
GG.JMSCAP_TCUSTMERの固定幅データは、次のようになります。ここでは、わかりやすくするためにオフセット・ガイドが各セクションに追加されています。
0 1 2 3 0 1 2 3 4 5 6 7 8 012345678901234567890123456789012012345678901234567890123456789012345678901234567890123456789012345678901234567890 I GG.JMSCAP_TCUSTMER WILL BG SOFTWARE CO. SEATTLE WA I GG.JMSCAP_TCUSTMER JANE ROCKY FLYER INC. DENVER CO I GG.JMSCAP_TCUSTMER DAVE DAVE'S PLANES INC. TALLAHASSEE FL I GG.JMSCAP_TCUSTMER BILL BILL'S USED CARS DENVER CO I GG.JMSCAP_TCUSTMER ANN ANN'S BOATS SEATTLE WA U GG.JMSCAP_TCUSTMER ANN ANN'S BOATS NEW YORK NY
より短いデータ・レコードを指定できます。つまり、前の一部の列のみが存在することになります。これを行うには、次の要件が満たされている必要があります。
欠落した列または省略された列がキーの一部になっていない
それぞれのExternal Lengthの情報に応じて、存在するすべての列に完全なデータが含まれる
区切り解析は、既存のソース定義ファイルとプロパティのセットに基づきます。プロパティで、使用するデリミタ、および列名とビフォア値があるかどうかなどの他のルールが指定されます。ソース定義ファイルによって、処理される有効な表、および表内の列の順序とデータ型が決まります。
METACOLSn[,COLNAMES]m[,COLBEFOREVALS]m,{COLVALUES}m\n
説明:
メタデータ列はn個含めることができ、各メタデータ列の後に形式文に示すカンマなどのフィールド・デリミタが続きます。
列値はm個含めることができます。各々、カンマなどのフィールド・デリミタがその前に付きます。
列名とビフォア値はオプションです。
各レコードは、\n
などの行末デリミタで終わります。
渡されるメッセージには、少なくともヘッダーとメタデータ列が含まれている必要があります。列の数が、ヘッダーおよびメタデータの列の数より少ない場合には、取得プロセスが終了し、エラー・メッセージが生成されます。
ヘッダーおよびメタデータ列より後の残りの列は、対応する表の列データで、解決されるメタデータの列の順序で指定されます。メッセージに存在する表の列の数は、メタデータに従って想定される列の数と完全に一致しているのが理想的です。ただし、メッセージの終わりのほうでメッセージの列が不足していても構わず、パーサーはこの最後のほうの列(メッセージの残りには存在しない)を列データの欠落としてマークします。
データの欠落は、パーサーでは許可されますが、キー@列が不足している場合は、取得プロセスが終了します。
Oracle GoldenGateの主キーの更新および統一更新は、サポートされていません。サポートされている操作は、挿入、更新、削除、切捨てのみです。
メタデータ列はヘッダーに相当し、特別な意味を持つフィールドを含みます。メタデータ列には、次の情報が含まれます。
optypeには、レコードが挿入か、更新か、削除かを示す値が含まれます。デフォルト値は、I
、U
およびD
です。
timestampは、レコードのコミット・タイムスタンプに使用する値の型を示します。タイムスタンプの形式のデフォルトは、YYYY-DD-MM HH:MM:SS.FFF
です。
schemaは、レコードのスキーマ名です。
txindは、レコードがトランザクションの先頭か、中間か、末尾か、唯一のレコードかを示す値です。デフォルト値は、0、1、2、3です。
idは、レコードのシーケンス番号(RSNまたはCSN)として使用される値です。トランザクションの最初のレコード(操作)のidは、トランザクションのシーケンス番号に使用されます。
デリミタ、値および日時の形式を表すプロパティを設定できます。
次のプロパティは、レコードを区切るための解析ルールを決定します。
fielddelimは、1つ以上のASCIIまたは16進文字をフィールド・デリミタの値として指定します。
recorddelimは、1つ以上のASCIIまたは16進文字をレコード・デリミタの値として指定します。
quoteは、引用符付きの値に使用する1つ以上のASCIIまたは16進文字を指定します。
nullindicatorは、NULL
値に使用する1つ以上のASCIIまたは16進文字を指定します。
デリミタのエスケープ文字を定義し、その文字がテキスト内にあった場合に置き換えられるようにすることができます。たとえば、バックスラッシュとアポストロフィ(\')が指定されている場合、入力"They used Mike\'s truck" は"They used Mike's truck"に翻訳されます。また、2つの引用符("")が指定されている場合、"They call him ""Big Al"""は"They call him "Big Al""に翻訳されます。
レコード内に引用符なしのデータ値が存在することがありますが、引用符付きの値内のエスケープ文字のみシステムで削除されます。nullインジケータと一致する引用符なしの文字列は、nullとして処理されます。
次のプロパティで詳細情報が提供されます。
hasbeforesは、各レコードにビフォア値が存在することを示します。
hasnamesは、各レコードに列名が存在することを示します。
afterfirstは、列のアフター値がビフォア値の前に来ることを示します。
isgroupedは、すべての列名、ビフォア値およびアフター値が列ごとに順にではなく、3つのブロックにまとめられることを示します。
XML解析は、既存のソース定義ファイルとプロパティのセットに基づきます。プロパティによって、トランザクション、操作および列に対応するXML要素および属性を決定するルールが指定されます。ソース定義ファイルによって、処理される有効な表、およびそれらの表内の列の順序とデータ型が決まります。
XMLメッセージは動的または静的なXMLにフォーマットされます。実行時、動的XMLのコンテンツは、サンプルXMLまたはXSDドキュメントを使用してあらかじめ決定できないデータ値です。表および列の要素または属性名を決定する静的XMLのコンテンツは、それらのサンプル・ドキュメントを使用してあらかじめ決定できます。
次の2つの例には同じデータが含まれています。
例5-5 静的XMLの例
<NewMyTableEntries> <NewMyTableEntry> <CreateTime>2010-02-05:10:11:21</CreateTime> <KeyCol>keyval</KeyCol> <Col1>col1val</Col1> </NewMyTableEntry> </NewMyTableEntries>
NewMyTableEntries
要素は、トランザクション境界をマークします。NewMyTableEntry
は、MY.TABLE
への挿入を表します。タイムスタンプは要素テキスト値内にあり、列名は要素名で表されます。
XPathに似た形式のプロパティのセットを介してこれらの2つのスタイルのXMLを解析するルールをプロパティ・ファイルに定義できます。プロパティの目的は、XPath照合を介してあらかじめ定義されたソース定義ファイルにXMLをマップすることです。
例5-6 動的XMLの例
<transaction id="1234" ts="2010-02-05:10:11:21"> <operation table="MY.TABLE" optype="I"> <column name="keycol" index="0"> <aftervalue><![CDATA[keyval]]></aftervalue> </column> <column name="col1" index="1"> <aftervalue><![CDATA[col1val]]></aftervalue> </column> </operation> </transaction>
各表に対する各操作は、トランザクション、操作および列の各要素で構成される同じ基本的メッセージ構造を持ちます。表名、操作タイプ、タイムスタンプ、列名、列値などは属性または要素テキスト値から取得されます。
XMLのスタイルに関係なく、解析プロセスは次の事項を決定する必要があります。
トランザクション境界
次のような操作エントリとメタデータ
次のような列エントリとメタデータ
列名または索引のいずれか。両方が指定されている場合、システムは、指定されたデータを含む列の名前が指定された名前かをチェックします。
列のビフォア値またはアフター値(両方の場合も)。
これは、相互に関係のあるルールのセットを介して行われます。処理される各タイプのXMLメッセージに対して、必要なデータの取得に使用されるルールを指定します。指定されたこれらの各ルールに対し、次の目的のプロパティを追加します。
トランザクション、操作または列ルール・タイプとしてルールを指定します。どのタイプのルールも、指定された名前とタイプが必要です。
処理されるドキュメントに対してルールがアクティブかどうかを確認するために照合するXPath式を指定します。これはオプションです。定義されていない場合、パーサーは親ルールのノードを照合し、これが最初のルールの場合はドキュメント全体を照合します。
リストされた順で処理される詳細ルール(subrules
)をリストします。有効なsubrules
は、ルール・タイプによって決まります。Subrules
はオプションです。
次の例では、最上位レベルのルールはgenericrule
と定義されています。これは、transaction
タイプ・ルールです。そのsubrules
はoprule
で定義され、このタイプはoperation
です。
xmlparser.rules=genericrule xmlparser.rules.genericrule.type=tx xmlparser.rules.genericrule.subrules=oprule xmlparser.rules.oprule.type=op
XMLパーサーでは、要素およびExtractデータの照合に必要なXPath式のサブセットがサポートされます。式は、特定の要素の照合またはExtractデータに使用されます。
データ抽出の際、パスの大部分が照合に使用されます。式の末尾が抽出に使用されます。
サポートされるコンストラクト | 説明 |
---|---|
/e |
ドキュメントのルートからの絶対パスを使用して |
./e or e |
処理対象の現在のノードからの相対パスを使用して |
../e |
現在のノードの親に基づいたパスを使用して(繰返し可能) |
//e |
ドキュメント内の任意の場所にある |
* |
任意の要素に一致します。注意: 部分的にワイルドカードが使用された名前はサポートされません。 |
[n] |
式のn番目の出現に一致します。 |
[x=v] |
xが値vに等しい場合、一致します。ここで、xは次のいずれかです。
|
サポートされる式 | 説明 |
---|---|
ルート要素に一致 |
/My/Element |
現在のノードのサブ要素に一致 |
./Sub/Element |
n番目の要素に一致 |
/My/*[n] |
n番目のSome要素に一致 |
/My/Some[n] |
任意のテキスト値に一致 |
/My/*[text() ='value'] |
Some要素のテキストに一致 |
/My/Some[text() = 'value'] |
任意の属性に一致 |
/My/*[@att = 'value'] |
Some要素の属性に一致 |
/My/Some[@att = 'value'] |
パスの照合以外に、XPath式は、データ値の取得にも使用できます(絶対または処理対象の現在のノードとの相対)。データ値の式には前の表のパス要素を含めることができますが、後述のいずれかの値アクセッサで終わる必要があります。
値アクセッサ | 説明 |
---|---|
@att |
属性値。 |
text() |
要素のテキスト・コンテンツ(値)。 |
content() |
任意の子XMLノードを含む、要素のフル・コンテンツ。 |
name() |
要素の名前。 |
position() |
親内の要素の位置。 |
例5-7 データ値の抽出の例
相対要素テキスト値を抽出する場合:
/My/Element/text()
絶対属性値を抽出する場合:
/My/Element/@att
照合を使用して要素テキスト値を抽出する場合:
/My/Some[@att = 'value']/Sub/text()
注意:
ancestor、descendent、selfなどのパス・アクセッサはサポートされません。
XMLパーサーによって抽出される値は、列値、またはトランザクションまたは操作のプロパティ(表、タイムスタンプなど)です。これらの値はXPathを使用するか、JMSメッセージのプロパティ、システム値またはハードコードされた値を介してXMLから取得されます。XMLパーサー・プロパティは、これらのオプションのうち、そのプロパティの値を取得するために有効なオプションを指定します。
次の例では、timestamp
は、XPath式、JMSプロパティまたはシステム生成タイムスタンプであることを指定します。
{txrule}.timestamp={xpath-expression}|${jms-property}|*ts
次の例では、table
は、XPath式、JMSプロパティまたはハードコードされた値であることを指定します。
{oprule}.table={xpath-expression}|${jms-property}|"value"
最後の例では、name
は、XPath式またはハードコードされた値であることを指定します。
{colrule}.timestamp={xpath-expression}|"value"
トランザクションの境界を指定するルールが最上位です。メッセージには、1つのトランザクション、複数のトランザクションまたは複数メッセージにわたるトランザクションの一部を含めることができます。これらは次のように指定されます。
single - トランザクション・ルール照合は定義されません。
multiple - 各トランザクション・ルール照合は新規トランザクションを定義します。
span - トランザクション・ルールは定義されません。かわりに、トランザクション・インジケータが操作ルールに指定されます。
トランザクション・ルールの場合、XPathまたは他の式を介して次のルールのプロパティも定義できます。
timestamp - トランザクションが発生した時間。
txid - トランザクションの識別子。
トランザクション・ルールは複数のsubrules
を持つことができますが、各サブルールは操作タイプのルールである必要があります。
次の例では、メッセージ全体であるトランザクションを指定し、JMSプロパティから取得されるタイムスタンプを含めます。
例5-8 JMSタイムスタンプ
singletxrule.timestamp=$JMSTimeStamp
次の例はルート要素トランザクションに一致し、ts
属性からタイムスタンプを取得します。
例5-9 tsタイムスタンプ
dyntxrule.match=/Transaction dyntxrule.timestamp=@ts
操作ルールはトランザクション・ルールのサブルールまたは最上位ルール(トランザクションが操作のプロパティの場合)のいずれかです。
標準ルール・プロパティ以外に、操作ルールは、XPathまたは他の式を介して次のものも定義します。
timestamp - 操作のタイムスタンプ。トランザクション・ルールが定義されている場合、これはオプションです。
table - この操作の対象の表の名前。これをスキーマと組み合せて使用します。
schema - 表のスキーマの名前。
schemaandtable - SCHEMA.TABLE
の形式のスキーマ名と表名の両方。これは、個々の表およびスキーマのプロパティのかわりに使用できます。
optype - optype
値に基づいて、これが挿入、更新、削除のいずれの操作かを指定します。
optype.insertval - 挿入を表す値。デフォルトは、I
です。
optype.updateval - 更新を表す値。デフォルトは、U
です。
optype.deleteval - 削除を表す値。デフォルトは、D
です。
seqid - 操作の識別子。txid
がトランザクション・レベルで定義されていない場合、これがトランザクション識別子になります。
txind - この操作がトランザクションの先頭か、中間か、末尾か、操作全体かを指定します。このプロパティはオプションで、操作ルールがトランザクション・ルールのサブルールの場合、無効です。
操作ルールは、操作タイプまたは列タイプの複数のサブルールを持つことができます。
次の例では、/Transaction
の/Operation
要素から操作情報を動的に取得します。
例5-10 操作
dynoprule.match=./Operation dynoprule.schemaandtable=@table dynoprule.optype=@type
次の例は、/NewMyTableEntry
要素をMY.TABLE
表に対する挿入操作に静的に対応付けます。
例5-11 操作例
statoprule.match=./NewMyTableEntry statoprule.schemaandtable="MY.TABLE" statoprule.optype="I" statoprule.timestamp=./CreateTime/text()
列ルールは、操作ルールのサブルールである必要があります。標準ルール・プロパティ以外に、列ルールは、XPathまたは他の式を介して次のものも定義します。
name - 表定義内の列の名前。
index - 表定義内の列の索引。
注意:
name
、index
のいずれか一方のみが定義されている場合、他方が決定されます。
before.value - 列のビフォア値。これは、削除の場合必須ですが、更新の場合オプションです。
before.isnull - 列のビフォア値がnullかどうかを示します。
before.ismissing - 列のビフォア値が欠落しているかどうかを示します。
after.value - 列のビフォア値。これは、削除の場合必須ですが、更新の場合オプションです。
after.isnull - 列のビフォア値がnullかどうかを示します。
after.ismissing - 列のビフォア値が欠落しているかどうかを示します。
value - 特定のビフォア値またはアフター値でオーバーライドされない場合にbefore.value
とafter.value
の両方に使用する式。これは、更新に対する異なるビフォア値をサポートしないことに注意してください。
isnull - オーバーライドされない場合にbefore.isnullとafter.isnullの両方に使用する式。
ismissing - オーバーライドされない場合にbefore.ismissingとafter.ismissingの両方に使用する式。
次の例では、/Operation
の/Column
要素から列情報を動的に取得します。
例5-12 列情報の動的抽出
dyncolrule.match=./Column dyncolrule.name=@name dyncolrule.before.value=./beforevalue/text() dyncolrule.after.value=./aftervalue/text()
次の例は、/KeyCol
および/Col1
要素をMY.TABLE
の列に静的に対応付けます。
例5-13 要素の列との静的対応
statkeycolrule.match=/KeyCol statkeycolrule.name="keycol" statkeycolrule.value=./text() statcol1rule.match=/Col1 statcol1rule.name="col1" statcol1rule.value=./text()
次の例では、前述のXMLサンプルおよび適切なルールを使用して、MY.TABLE
に対する同じ結果の操作を生成します。
動的XML | 静的XML |
---|---|
<transaction id="1234" ts="2010-02-05:10:11:21"> <operation table="MY.TABLE" optype="I"> <column name="keycol" index="0"> <aftervalue> <![CDATA[keyval]]> </aftervalue> </column> <column name="col1" index="1"> <aftervalue> <![CDATA[col1val]]> </aftervalue> </column> </operation> </transaction> |
NewMyTableEntries> <NewMyTableEntry> <CreateTime> 2010-02-05:10:11:21 </CreateTime> <KeyCol>keyval</KeyCol> <Col1>col1val</Col1> </NewMyTableEntry> </NewMyTableEntries> |
動的 | 静的 |
---|---|
dyntxrule.match=/Transaction dyntxrule.timestamp=@ts dyntxrule.subrules=dynoprule dynoprule.match=./Operation dynoprule.schemaandtable=@table dynoprule.optype=@type dynoprule.subrules=dyncolrule dyncolrule.match=./Column dyncolrule.name=@name |
stattxrule.match=/NewMyTableEntries stattxrule.subrules= statoprule statoprule.match=./NewMyTableEntry statoprule.schemaandtable="MY.TABLE" statoprule.optype="I" statoprule.timestamp=./CreateTime/text() statoprule.subrules= statkeycolrule, statcol1rule statkeycolrule.match=/KeyCol |
INSERT INTO MY.TABLE (KEYCOL, COL1) VALUES ('keyval', 'col1val')
デフォルトでは、JMS取得プロセスは生成される証跡ファイルにメタデータ情報を書き込むので、証跡ファイルのコンシューマは、外部定義ファイルを利用しなくても、証跡レコードの構造を理解することができます。
証跡機能のメタデータが無効な場合は、証跡ファイルのコンシューマは証跡レコードを正しく解析するために、引き続き定義ファイルを必要とします。このため、Java用Oracle GoldenGateには、プロパティ・ファイルに定義されているプロパティからOracle GoldenGateソース定義ファイルを生成するgendef
ユーティリティが含まれています。プロパティ設定および他のパーサー固有のデータ定義値に基づいて、表の標準化された定義を作成します。
このユーティリティを実行する構文は次のとおりです。
gendef –prop {property_file} [-out {output_file}
これは、デフォルトではソース定義を標準出力に送信しますが、-out
パラメータを使用してファイルに仕向けることができます。次に例を示します。
gendef –prop dirprm/jmsvam.properties -out dirdef/msgdefs.def