11 Administer

• Automatic Heartbeat for Oracle GoldenGate for Distributed Applications and Analytics
  This article describes how to enable Heartbeat for Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA) and how to manage and modify heartbeat across the replication environment.
• Parsing the Message
  
• Message Capture Properties
  

11.1 Automatic Heartbeat for Oracle GoldenGate for Distributed Applications and Analytics

This article describes how to enable Heartbeat for Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA) and how to manage and modify heartbeat across the replication environment.

• Overview
  Oracle GoldenGate for Distributed Applications and Analytics supports automatic heartbeat tables that monitors the replication lag and connectivity across distributed environments. These heartbeat table records can be processed in two different modes based on your system architecture and target configuration.
• Automatic Heartbeat Tables
  

11.1.1 Overview

Oracle GoldenGate for Distributed Applications and Analytics supports automatic heartbeat tables that monitors the replication lag and connectivity across distributed environments. These heartbeat table records can be processed in two different modes based on your system architecture and target configuration.

Prerequisites and Initial Setup

To enable heartbeat table functionality in Oracle GoldenGate for Distributed Applications and Analytics, perform the following steps:

1. Define the Oracle GoldenGate schema in the GLOBALS file.

   GGSCHEMA GGADMIN

2. Enable heartbeat table support by adding the following directive in the GLOBALS file:

   ENABLE_HEARTBEAT_TABLE

3. Apply the changes:
   • For Classic Architecture:
     1. Restart the Oracle GoldenGate Software Command Interface (GGSCI).
     2. Restart the Manager.
   • For Microservices Architecture (MA):
     1. Stop the Oracle GoldenGate for Distributed Applications and Analytics deployment.
     2. Restart the Service Manager.
     3. Start the deployment again.

Mode 1: Passthrough Mode

The Passthough mode, allows heartbeat table records to be sent directly to non-Oracle targets, such as Kafka, without any transformation or internal processing by Oracle GoldenGate.

Configuration Steps

1. Create the GLOBALS file as outlined in the Prerequisites and Initial Setup.

   Note:

   • Do not run the ADD HEARTBEATTABLE command for this mode.
   • No need to define MAP statements for heartbeat tables in the Replicat parameter file.
2. Ensure that the GGSCHEMA and ENABLE_HEARTBEAT_TABLE directives are correctly set in the GLOBALS file.
3. Restart Oracle GoldenGate services as required based on your architecture.

Mode 2: Heartbeat as User Data

In the Heartbeat as User Data mode , the heartbeat table records are treated like regular user data. The Replicat process writes these records to the .json files.

File Locations

Architecture{}	GG_HEARTBEAT File{}	GG_HEARTBEAT_HISTORY File{}
Classic	dirtmp/<replicat_name>-hb.json	dirtmp/<replicat_name>hb-<date>.json
Microservices Architecture	<deployment_home>/var/temp/<replicat_name>-hb.json	<deployment_home>/var/temp/<replicat_name>hb-<date>.json

Configuration Steps

1. Create the GLOBALS file as outlined in the Prerequisites and Initial Setup.
2. Run the following Oracle GoldenGate Software Command Interface (GGSCI)Admin Client command to create the heartbeat table.

   ADD HEARTBEATTABLE

   Note:

   No need to define the MAP statements for heartbeat tables in the Replicat parameter file.
3. Ensure that the GGSCHEMA and ENABLE_HEARTBEAT_TABLE directives are correctly set in the GLOBALS file.
4. Restart the Oracle GoldenGate services according to the architecture type.

11.1.2 Automatic Heartbeat Tables

• ADD HEARTBEATTABLE
  
• ALTER HEARTBEAT TABLE
  
• INFO HEARTBEATTABLE
  
• LAG
  
• DELETE HEARTBEATTABLE
  

11.1.2.1 ADD HEARTBEATTABLE

ADD HEARTBEATTABLE
[, RETENTION_TIME number in days] |
[, PURGE_FREQUENCY number in days]

RETENTION_TIME

Specifies when heartbeat entries older than the retention time in the history table are purged. The default is 30 days.

PURGE FREQUENCY

Specifies how often the purge scheduler is run to delete table entries that are older than the retention time from the heartbeat history. The default is 1 day.

Example:

GGSCI > ADD HEARTBEATTABLE
HEARTBEAT is now enabled:
HEARTBEAT configuration file in dirprm\heartbeat.properties
heartbeat.enabled=true
heartbeat.frequency=60
heartbeat.retention_time=30
heartbeat.purge.frequency=1
heartbeat.db.name=BigData

Note:

Ensure to run the ADD HEARTBEATTABLE command before processing the trail file through the replicat.

11.1.2.2 ALTER HEARTBEAT TABLE

ALTER HEARTBEATTABLE

[, RETENTION_TIME number in days] |

[, PURGE_FREQUENCY number in days]

RETENTION_TIME

Update heartbeat.retention_time in dirprm/heartbeat.properties; will take affect on the next restart.

PURGE_FREQUENCY

Specifies how often entries older than the retention time are purged from the GG_HEARTBEAT_HISTORY. The default is 1 day.

11.1.2.3 INFO HEARTBEATTABLE

Example

HEARTBEAT configuration file dirprm\heartbeat.properties
heartbeat.enabled=true
heartbeat.frequency=60
heartbeat.retention_time=30
heartbeat.purge.frequency=1
heartbeat.db.name=BigData

11.1.2.4 LAG

LAG <replicat name>

Example

GGSCI> LAG rtpc
Lag Information From Heartbeat Table
LAG                 AGE                 FROM       TO         PATH
5.77s               10m 22.87s          ORCL       BIGDATA    ETPC ==> PTPC ==> RTPC

LAG <replicat name> HISTORY

GGSCI> LAG rtpc HISTORY

Example

Lag Information From Heartbeat Table 
LAG      AGE          FROM       TO      PATH 
5.77s   10m 22.87s    ORCL       ORCL    ETPC ==> PTPC ==> RTPC 
Lag History 
DATE         MIN        AVG        MAX
2018-07-01   5.77s      5.90s      6.20s 
2018-07-02   6.77s      6.90s      7.20s 
2018-07-03   7.77s      7.90s      8.20s 
2018-07-04   8.77s      9.90s      9.20s

11.1.2.5 DELETE HEARTBEATTABLE

DELETE HEARTBEATTABLE

Example

GGSCI> DELETE HEARTBEATTABLE

11.2 Parsing the Message

• Parsing Overview
  
• Fixed Width Parsing
  
• Delimited Parsing
  
• XML Parsing
  
• Source Definitions Generation Utility
  

11.2.1 Parsing Overview

The role of the parser is to translate JMS text message data and header properties into an appropriate set of transactions and operations to pass into the VAM interface. To do this, the parser always must find certain data:

• Transaction identifier

• Sequence identifier

• Timestamp

• Table name

• Operation type

• Column data specific to a particular table name and operation type

Other data will be used if the configuration requires it:

• Transaction indicator

• Transaction name

• Transaction owner

The parser can obtain this data from JMS header properties, system generated values, static values, or in some parser-specific way. This depends on the nature of the piece of information.

• Parser Types
  
• Source and Target Data Definitions
  
• Required Data
  
• Optional Data
  

11.2.1.1 Parser Types

The Oracle GoldenGate message capture adapter supports three types of parsers:

• Fixed – Messages contain data presented as fixed width fields in contiguous text.

• Delimited – Messages contain data delimited by field and end of record characters.

• XML – Messages contain XML data accessed through XPath expressions.

11.2.1.2 Source and Target Data Definitions

There are several ways source data definitions can be defined using a combination of properties and external files.

There are several properties that configure how the selected parser gets data and how the source definitions are converted to target definitions.

11.2.1.3 Required Data

The following information is required for the parsers to translate the messages:

• Transaction Identifier
  
• Sequence Identifier
  
• Timestamp
  
• Table Name
  
• Operation Type
  
• Column Data
  

11.2.1.3.1 Transaction Identifier

The transaction identifier (txid) groups operations into transactions as they are written to the Oracle GoldenGate trail file. The Oracle GoldenGate message capture adapter supports only contiguous, non-interleaved transactions. The transaction identifier can be any unique value that increases for each transaction. A system generated value can generally be used.

11.2.1.3.2 Sequence Identifier

The sequence identifier (seqid) identifies each operation internally. This can be used during recovery processing to identify operations that have already been written to the Oracle GoldenGate trail. The sequence identifier can be any unique value that increases for each operation. The length should be fixed.

The JMS Message ID can be used as a sequence identifier if the message identifier for that provider increases and is unique. However, there are cases (for example, using clustering, failed transactions) where JMS does not guarantee message order or when the ID may be unique but not be increasing. The system generated Sequence ID can be used, but it can cause duplicate messages under some recovery situations. The recommended approach is to have the JMS client that adds messages to the queue set the Message ID, a header property, or some data element to an application-generated unique value that is increasing.

11.2.1.3.3 Timestamp

The timestamp (timestamp) is used as the commit timestamp of operations within the Oracle GoldenGate trail. It should be increasing but this is not required, and it does not have to be unique between transactions or operations. It can be any date format that can be parsed.

11.2.1.3.4 Table Name

The table name is used to identify the logical table to which the column data belongs. The adapter requires a two part table name in the form SCHEMA_NAME.TABLE_NAME. This can either be defined separately (schema and table) or as a combination of schema and table (schemaandtable).

A single field may contain both schema and table name, they may be in separate fields, or the schema may be included in the software code so only the table name is required. How the schema and table names can be specified depends on the parser. In any case the two part logical table name is used to write records in the Oracle GoldenGate trail and to generate the source definitions file that describes the trail.

11.2.1.3.5 Operation Type

The operation type (optype) is used to determine whether an operation is an insert, update or delete when written to the Oracle GoldenGate trail. The operation type value for any specific operation is matched against the values defined for each operation type.

The data written to the Oracle GoldenGate trail for each operation type depends on the Extract configuration:

• Inserts

  • The after values of all columns are written to the trail.

• Updates

  • Default – The after values of keys are written. The after values of columns that have changed are written if the before values are present and can be compared. If before values are not present then all columns are written.

  • NOCOMPRESSUPDATES – The after values of all columns are written to the trail.

  • GETUPDATEBEFORES – The before and after values of columns that have changed are written to the trail if the before values are present and can be compared. If before values are not present only after values are written.

  • If both NOCOMPRESSUPDATES and GETUPDATEBEFORES are included, the before and after values of all columns are written to the trail if before values are present

• Deletes

  • Default – The before values of all keys are written to the trail.

  • NOCOMPRESSDELETES – The before values of all columns are written to the trail.

Primary key update operations may also be generated if the before values of keys are present and do not match the after values.

11.2.1.3.6 Column Data

All parsers retrieve column data from the message text and write it to the Oracle GoldenGate trail. In some cases the columns are read in index order as defined by the source definitions, in other cases they are accessed by name.

Depending on the configuration and original message text, both before and after or only after images of the column data may be available. For updates, the data for non-updated columns may or may not be available.

All column data is retrieved as text. It is converted internally into the correct data type for that column based on the source definitions. Any conversion problem will result in an error and the process will abend.

11.2.1.4 Optional Data

The following data may be included, but is not required.

• Transaction Indicator
  
• Transaction Name
  
• Transaction Owner
  

11.2.1.4.1 Transaction Indicator

The relationship of transactions to messages can be:

• One transaction per message

  This is determined automatically by the scope of the message.

• Multiple transactions per message

  This is determined by the transaction indicator (txind). If there is no transaction indicator, the XML parser can create transactions based on a matching transaction rule.

• Multiple messages per transaction

  The transaction indicator (txind) is required to specify whether the operation is the beginning, middle, end or the whole transaction. The transaction indicator value for any specific operation is matched against the values defined for each transaction indicator type. A transaction is started if the indicator value is beginning or whole, continued if it is middle, and ended if it is end or whole.

11.2.1.4.2 Transaction Name

The transaction name (txname) is optional data that can be used to associate an arbitrary name to a transaction. This can be added to the trail as a token using a GETENV function.

11.2.1.4.3 Transaction Owner

The transaction owner (txowner) is optional data that can be used to associate an arbitrary user name to a transaction. This can be added to the trail as a token using a GETENV function, or used to exclude certain transactions from processing using the EXCLUDEUSER Extract parameter.

11.2.2 Fixed Width Parsing

Fixed width parsing is based on a data definition that defines the position and the length of each field. This is in the format of a Cobol copybook. A set of properties define rules for mapping the copybook to logical records in the Oracle GoldenGate trail and in the source definitions file.

The incoming data should consist of a standard format header followed by a data segment. Both should contain fixed width fields. The data is parsed based on the PIC definition in the copybook. It is written to the trail translated as explained in Header and Record Data Type Translation.

• Header
  
• Header and Record Data Type Translation
  
• Key identification
  
• Using a Source Definition File
  

11.2.2.1 Header

The header must be defined by a copybook 01 level record that includes the following:

• A commit timestamp or a change time for the record

• A code to indicate the type of operation: insert, update, or delete

• The copybook record name to use when parsing the data segment

Any fields in the header record that are not mapped to Oracle GoldenGate header fields are output as columns.

The following example shows a copybook definition containing the required header values

Example 11-1 Specifying a Header

01 HEADER.
20 Hdr-Timestamp            PIC X(23)
20 Hdr-Source-DB-Function PIC X
20 Hdr-Source-DB-Rec-ID    PIC X(8)

For the preceding example, you must set the following properties:

fixed.header=HEADER
fixed.timestamp=Hdr-Timestamp
fixed.optype=Hdr-Source-DB-Function
fixed.table=Hdr-Source-DB-Rec-Id

The logical name table output in this case will be the value of Hdr-Source-DB-Rec-Id.

• Specifying Compound Table Names
  
• Specifying timestamp Formats
  
• Specifying the Function
  

11.2.2.1.1 Specifying Compound Table Names

More than one field can be used for a table name. For example, you can define the logical schema name through a static property such as:

fixed.schema=MYSCHEMA

You can then add a property that defines the data record as multiple fields from the copybook header definition.

Example 11-2 Specifying Compound Table Names

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).

For the preceding example, you must set the following properties:

fixed.header=HEADER
fixed.table=Hdr-Source-DB-Rec-Id,Hdr-Source-DB-Rec-Version
fixed.schema=MYSCHEMA

The fields will be concatenated to result in logical schema and table names of the form:

MYSCHEMA.Hdr-Source-DB-Rec-Id+Hdr-Source-DB-Rec-Version

11.2.2.1.2 Specifying timestamp Formats

A timestamp is parsed using the default format YYYY-MM-DD HH:MM:SS.FFF, with FFF depending on the size of the field.

Specify different incoming formats by entering a comment before the datetime field as shown in the next example.

Example 11-3 Specifying timestamp formats

01  HEADER. 
* DATEFORMAT YYYY-MM-DD-HH.MM.SS.FF
    20  Hdr-Timestamp       PIC X(23)

11.2.2.1.3 Specifying the Function

Use properties to map the standard Oracle GoldenGate operation types to the optype values. The following example specifies that the operation type is in the Hdr-Source-DB-Function field and that the value for insert is A, update is U and delete is D.

Example 11-4 Specifying the Function

fixed.optype=Hdr-Source-DB-Function
fixed.optype.insert=A
fixed.optype.update=U
fixed.optype.delete=D

11.2.2.2 Header and Record Data Type Translation

The data in the header and the record data are written to the trail based on the translated data type.

• A field definition preceded by a date format comment is translated to an Oracle GoldenGate datetime field of the specified size. If there is no date format comment, the field will be defined by its underlying data type.

• A PIC X field is translated to the CHAR data type of the indicated size.

• A PIC 9 field is translated to a NUMBER data type with the defined precision and scale. Numbers that are signed or unsigned and those with or without decimals are supported.

The following examples show the translation for various PIC definitions.

Input	Output
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)

In the example an input YYMMDD date of 100522 is translated to 2010-05-22. The number 1234567 with the specified format PIC 9(5)V99 is translated to a seven digit number with two decimal places, or 12345.67.

11.2.2.3 Key identification

A comment is used to identify key columns within the data record.

In the following example Account has been marked as a key column for TABLE1.

01 TABLE1
* KEY
20  Account      PIC X(19)
20  PAN_Seq_Num PIC 9(3)

11.2.2.4 Using a Source Definition File

You can use fixed width parsing based on a data definition that comes from an Oracle GoldenGate source definition file. This is similar to Cobol copybook because a source definition file contains the position and the length of each field of participating tables. To use a source definition file, you must set the following properties:

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

The following example defines a header section of a total length of 33 characters; the first 3 characters are the operation type, and the last 30 characters is the table name. The layout of all records to be parsed must start with the complete header section as defined in the fixed.userdefs properties. For each record, the header section is immediately followed by the content of all column data for the corresponding table. The column data must be strictly laid out according to its offset and length defined in the source definition file. Specifically, the offset information is the fourth field (Fetch Offset) of the column definition and the length information is the third field (External Length) of the column definition. The following is an example of a definition for 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

The fixed width data for GG.JMSCAP_TCUSTMER may be similar to the following where the offset guides have been added to each section for clarity:

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

You can choose to specify shorter data records, which means that only some of the earlier columns are present. To do this, the following requirements must be met:

• None of the missing or omitted columns are part of the key and

• all columns that are present contain complete data according to their respective External Length information

  .

11.2.3 Delimited Parsing

Delimited parsing is based a preexisting source definitions files and a set of properties. The properties specify the delimiters to use and other rules, such as whether there are column names and before values. The source definitions file determines the valid tables to be processed and the order and data type of the columns in the tables.

The format of the delimited message is:

METACOLSn[,COLNAMES]m[,COLBEFOREVALS]m,{COLVALUES}m\n

Where:

• There can be n metadata columns each followed by a field delimiter such as the comma shown in the format statement.

• There can be m column values. Each of these are preceded by a field delimiter such as a comma.

• The column name and before value are optional.

• Each record is terminated by an end of line delimiter, such as \n.

The message to be parsed must contain at least the header and metadata columns. If the number of columns is fewer than the number of header and meta columns, then the capture process terminates and provides an error message.

The remaining number of columns after the header and metadata columns are the column data for the corresponding table, specified in the order of the columns in the resolved metadata. Ideally, the number of table columns present in the message is exactly the same as the expected number of columns according to the metadata. However, missing columns in the message towards the end of message is allowed and the parser marks those last columns (not present in the rest of the message) as missing column data.

Although missing data is allowed from parser perspective, if the key @ column(s) is/are missing, then the capture process will also terminate.

Oracle GoldenGate primary key updates and unified updates are not supported. The only supported operations are inserts, updates, deletes, and truncates.

• Metadata Columns
  
• Parsing Properties
  
• Parsing Steps
  

11.2.3.1 Metadata Columns

The metadata columns correspond to the header and contain fields that have special meaning. Metadata columns should include the following information.

• optype contains values indicating if the record is an insert, update, or delete. The default values are I, U, and D.

• timestamp indicates type of value to use for the commit timestamp of the record. The format of the timestamp defaults to YYYY-DD-MM HH:MM:SS.FFF.

• schemaandtable is the full table name for the record in the format SCHEMA.TABLE.

• schema is the record's schema name.

• table is the record's table name.

• txind is a value that indicates whether the record is the beginning, middle, end or the only record in the transaction. The default values are 0, 1, 2, 3.

• id is the value used as the sequence number (RSN or CSN) of the record. The id of the first record (operation) in the transaction is used for the sequence number of the transaction.

11.2.3.2 Parsing Properties

Properties can be set to describe delimiters, values, and date and time formats.

• Properties to Describe Delimiters
  
• Properties to Describe Values
  
• Properties to Describe Date and Time
  

11.2.3.2.1 Properties to Describe Delimiters

The following properties determine the parsing rules for delimiting the record.

• fielddelim specifies one or more ASCII or hexadecimal characters as the value for the field delimiter

• recorddelim specifies one or more ASCII or hexadecimal characters as the value for the record delimiter

• quote specifies one or more ASCII or hexadecimal characters to use for quoted values

• nullindicator specifies one or more ASCII or hexadecimal characters to use for NULL values

You can define escape characters for the delimiters so they will be replaced if the characters are found in the text. For example if a backslash and apostrophe (\') are specified, then the input "They used Mike\'s truck" is translated to "They used Mike's truck". Or if two quotes ("") are specified, "They call him ""Big Al""" is translated to "They call him "Big Al"".

Data values may be present in the record without quotes, but the system only removes escape characters within quoted values. A non-quoted string that matches a null indicator is treated as null.

11.2.3.2.2 Properties to Describe Values

The following properties provide more information:

• hasbefores indicates before values are present for each record

• hasnames indicates column names are present for each record

• afterfirst indicates column after values come before column before values

• isgrouped indicates all column names, before values and after values are grouped together in three blocks, rather than alternately per column

11.2.3.2.3 Properties to Describe Date and Time

The default format YYYY-DD-MM HH:MM:SS.FFF is used to parse dates. You can use properties to override this on a global, table or column level. Examples of changing the format are shown below.

delim.dateformat.default=MM/DD/YYYY-HH:MM:SS
delim.dateformat.MY.TABLE=DD/MMM/YYYY
delim.dateformat.MY.TABLE.COL1=MMYYYY

11.2.3.3 Parsing Steps

The steps in delimited parsing are:

1. The parser first reads and validates the metadata columns for each record.
2. This provides the table name, which can then be used to look up column definitions for that table in the source definitions file.
3. If a definition cannot be found for a table, the processing will stop.
4. Otherwise the columns are parsed and output to the trail in the order and format defined by the source definitions.

11.2.4 XML Parsing

XML parsing is based on a preexisting source definitions file and a set of properties. The properties specify rules to determine XML elements and attributes that correspond to transactions, operations and columns. The source definitions file determines the valid tables to be processed and the ordering and data types of columns in those tables.

• Styles of XML
  
• XML Parsing Rules
  
• XPath Expressions
  
• Other Value Expressions
  
• Transaction Rules
  
• Operation Rules
  
• Column Rules
  
• Overall Rules Example
  

11.2.4.1 Styles of XML

The XML message is formatted in either dynamic or static XML. At runtime the contents of dynamic XML are data values that cannot be predetermined using a sample XML or XSD document. The contents of static XML that determine tables and column element or attribute names can be predetermined using those sample documents.

The following two examples contain the same data.

Example 11-5 An Example of Static XML

<NewMyTableEntries> 
  <NewMyTableEntry> 
    <CreateTime>2010-02-05:10:11:21</CreateTime> 
    <KeyCol>keyval</KeyCol> 
    <Col1>col1val</Col1>
  </NewMyTableEntry>
</NewMyTableEntries>

The NewMyTableEntries element marks the transaction boundaries. The NewMyTableEntry indicates an insert to MY.TABLE. The timestamp is present in an element text value, and the column names are indicated by element names.

You can define rules in the properties file to parse either of these two styles of XML through a set of XPath-like properties. The goal of the properties is to map the XML to a predefined source definitions file through XPath matches.

Example 11-6 An Example of Dynamic 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>

Every operation to every table has the same basic message structure consisting of transaction, operation and column elements. The table name, operation type, timestamp, column names, column values, etc. are obtained from attribute or element text values.

11.2.4.2 XML Parsing Rules

Independent of the style of XML, the parsing process needs to determine:

• Transaction boundaries

• Operation entries and metadata including:

  • Table name

  • Operation type

  • Timestamp

• Column entries and metadata including:

  • Either the column name or index; if both are specified the system will check to see if the column with the specified data has the specified name.

  • Column before or after values, sometimes both.

This is done through a set of interrelated rules. For each type of XML message that is to be processed you name a rule that will be used to obtain the required data. For each of these named rules you add properties to:

• Specify the rule as a transaction, operation, or column rule type. Rules of any type are required to have a specified name and type.

• Specify the XPath expression to match to see if the rule is active for the document being processed. This is optional; if not defined the parser will match the node of the parent rule or the whole document if this is the first rule.

• List detailed rules (subrules) that are to be processed in the order listed. Which subrules are valid is determined by the rule type. Subrules are optional.

In the following example the top-level rule is defined as genericrule. It is a transaction type rule. Its subrules are defined in oprule and they are of the type operation.

xmlparser.rules=genericrule
xmlparser.rules.genericrule.type=tx
xmlparser.rules.genericrule.subrules=oprule
xmlparser.rules.oprule.type=op

11.2.4.3 XPath Expressions

The XML parser supports a subset of XPath expressions necessary to match elements and Extract data. An expression can be used to match a particular element or to Extract data.

When doing data extraction most of the path is used to match. The tail of the expression is used for extraction.

• Supported Constructs:
  
• Supported Expressions
  
• Obtaining Data Values
  

11.2.4.3.1 Supported Constructs:

Supported Constructs	Description
/e	Use the absolute path from the root of the document to match e.
./e or e	Use the relative path from current node being processed to match e.
../e	Use a path based on the parent of the current node (can be repeated) to match e.
//e	Match e wherever it occurs in a document.
*	Match any element. Note: Partially wild-carded names are not supported.
[n]	Match the nth occurrence of an expression.
[x=v]	Match when x is equal to some value v where x can be: @att - some attribute value text() - some text value name() - some name value position() - the element position

11.2.4.3.2 Supported Expressions

Supported Expressions	Descriptions
Match root element	/My/Element
Match sub element to current node	./Sub/Element
Match nth element	/My/*[n]
Match nth Some element	/My/Some[n]
Match any text value	/My/*[text() ='value']
Match the text in Some element	/My/Some[text() = 'value']
Match any attribute	/My/*[@att = 'value']
Match the attribute in Some element	/My/Some[@att = 'value']

11.2.4.3.3 Obtaining Data Values

In addition to matching paths, the XPath expressions can also be used to obtain data values, either absolutely or relative to the current node being processed. Data value expressions can contain any of the path elements in the preceding table, but must end with one of the value accessors listed below.

Value Accessors	Description
@att	Some attribute value.
text()	The text content (value) of an element.
content()	The full content of an element, including any child XML nodes.
name()	The name of an element.
position()	The position of an element in its parent.

Example 11-7 Examples of Extracting Data Values

To extract the relative element text value:

/My/Element/text()

To extract the absolute attribute value:

/My/Element/@att

To extract element text value with a match:

/My/Some[@att = 'value']/Sub/text()

Note:

Path accessors, such as ancestor/descendent/self, are not supported.

11.2.4.4 Other Value Expressions

The values extracted by the XML parser are either column values or properties of the transaction or operation, such as table or timestamp. These values are either obtained from XML using XPath or through properties of the JMS message, system values, or hard coded values. The XML parser properties specify which of these options are valid for obtaining the values for that property.

The following example specifies that timestamp can be an XPath expression, a JMS property, or the system generated timestamp.

{txrule}.timestamp={xpath-expression}|${jms-property}|*ts

The next example specifies that table can be an XPath expression, a JMS property, or hard coded value.

{oprule}.table={xpath-expression}|${jms-property}|"value"

The last example specifies that name can be a XPath expression or hard coded value.

{colrule}.timestamp={xpath-expression}|"value"

11.2.4.5 Transaction Rules

The rule that specifies the boundary for a transaction is at the highest level. Messages may contain a single transaction, multiple transactions, or a part of a transaction that spans messages. These are specified as follows:

• single - The transaction rule match is not defined.

• multiple - Each transaction rule match defines new transaction.

• span – No transaction rule is defined; instead a transaction indicator is specified in an operation rule.

For a transaction rule, the following properties of the rule may also be defined through XPath or other expressions:

• timestamp – The time at which the transaction occurred.

• txid – The identifier for the transaction.

Transaction rules can have multiple subrules, but each must be of type operation.

The following example specifies a transaction that is the whole message and includes a timestamp that comes from the JMS property.

Example 11-8 JMS Timestamp

singletxrule.timestamp=$JMSTimeStamp

The following example matches the root element transaction and obtains the timestamp from the ts attribute.

Example 11-9 ts Timestamp

dyntxrule.match=/Transaction
dyntxrule.timestamp=@ts

11.2.4.6 Operation Rules

An operation rule can either be a sub rule of a transaction rule, or a highest level rule (if the transaction is a property of the operation).

In addition to the standard rule properties, an operation rule should also define the following through XPath or other expressions:

• timestamp – The timestamp of the operation. This is optional if the transaction rule is defined.

• table – The name of the table on which this is an operation. Use this with schema.

• schema – The name of schema for the table.

• schemaandtable – Both schema and table name together in the form SCHEMA.TABLE. This can be used in place of the individual table and schema properties.

• optype – Specifies whether this is an insert, update or delete operation based on optype values:

  • optype.insertval – The value indicating an insert. The default is I.

  • optype.updateval – The value indicating an update. The default is U.

  • optype.deleteval – The value indicating a delete. The default is D.

• seqid – The identifier for the operation. This will be the transaction identifier if txid has not already been defined at the transaction level.

• txind – Specifies whether this operation is the beginning of a transaction, in the middle or at the end; or if it is the whole operation. This property is optional and not valid if the operation rule is a sub rule of a transaction rule.

Operation rules can have multiple sub rules of type operation or column.

The following example dynamically obtains operation information from the /Operation element of a /Transaction.

Example 11-10 Operation

dynoprule.match=./Operation
dynoprule.schemaandtable=@table
dynoprule.optype=@type

The following example statically matches /NewMyTableEntry element to an insert operation on the MY.TABLE table.

Example 11-11 Operation example

statoprule.match=./NewMyTableEntry
statoprule.schemaandtable="MY.TABLE"
statoprule.optype="I"
statoprule.timestamp=./CreateTime/text()

11.2.4.7 Column Rules

A column rule must be a sub rule of an operation rule. In addition to the standard rule properties, a column rule should also define the following through XPath or other expressions.

• name – The name of the column within the table definition.
• index – The index of the column within the table definition.

  Note:

  If only one of name and index is defined, the other will be determined.
• before.value – The before value of the column. This is required for deletes, but is optional for updates.
• before.isnull – Indicates whether the before value of the column is null.
• before.ismissing – Indicates whether the before value of the column is missing.
• after.value – The before value of the column. This is required for deletes, but is optional for updates.
• after.isnull – Indicates whether the before value of the column is null.
• after.ismissing – Indicates whether the before value of the column is missing.
• value – An expression to use for both before.value and after.value unless overridden by specific before or after values. Note that this does not support different before values for updates.
• isnull – An expression to use for both before.isnull and after.isnull unless overridden.
• ismissing – An expression to use for both before.ismissing and after.ismissing unless overridden.

Dynamic Extraction of Column Information

The following example dynamically obtains column information from the /Column element of an /Operation

dyncolrule.match=./Column
dyncolrule.name=@name
dyncolrule.before.value=./beforevalue/text()
dyncolrule.after.value=./aftervalue/text()

Static Matching of Elements to Columns

The following example statically matches the /KeyCol and /Col1 elements to columns in MY.TABLE.

statkeycolrule.match=/KeyCol
statkeycolrule.name="keycol"
statkeycolrule.value=./text()
statcol1rule.match=/Col1
statcol1rule.name="col1"
statcol1rule.value=./text()

11.2.4.8 Overall Rules Example

The following example uses the XML samples shown earlier with appropriate rules to generate the same resulting operation on the MY.TABLE table.

Dynamic XML	Static 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>

Dynamic	Static
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')

11.2.5 Source Definitions Generation Utility

By default, the JMS capture process writes metadata information in the produced trail files, allowing trail file consumers to understand the structure of the trail records without any help from an external definition file.

The output source definitions file can then be used in a pump or delivery process to interpret the trail data created through the VAM.

11.3 Message Capture Properties

• Logging and Connection Properties
  
• Parser Properties
  

11.3.1 Logging and Connection Properties

The following properties control the connection to JMS and the log file names, error handling, and message output.

• Logging Properties
  
• JMS Connection Properties
  
• JNDI Properties
  

11.3.1.1 Logging Properties

Logging is controlled by the following properties.

• gg.log
  
• gg.log.level
  
• gg.log.file
  
• gg.log.classpath
  

11.3.1.1.1 gg.log

Specifies the type of logging that is to be used. The default implementation is the JDK option. This is the built-in Java logging called java.util.logging (JUL). The other logging options are log4j or logback. The syntax is:

gg.log={JDK|log4j|logback}

For example, to set the type of logging to log4j:

gg.log=log4j 

The log file is created in the report subdirectory of the installation. The default log file name includes the group name of the associated Extract and the file extension is log.

11.3.1.1.2 gg.log.level

Specifies the overall log level for all modules. The syntax is:

gg.log.level={ERROR|WARN|INFO|DEBUG}

The log levels are defined as follows:

• ERROR – Only write messages if errors occur

• WARN – Write error and warning messages

• INFO – Write error, warning and informational messages

• DEBUG – Write all messages, including debug ones.

The default logging level is INFO. The messages in this case will be produced on startup, shutdown and periodically during operation. If the level is switched to DEBUG, large volumes of messages may occur which could impact performance. For example, the following sets the global logging level to INFO:

# global logging level
gg.log.level=INFO

11.3.1.1.3 gg.log.file

Specifies the path to the log file. The syntax is:

gg.log.file=path_to_file

Where the path_to_file is the fully defined location of the log file. This allows a change to the name of the log, but you must include the Replicat name if you have more than one Replicat to avoid one overwriting the log of the other.

11.3.1.1.4 gg.log.classpath

Specifies the classpath to the JARs used to implement logging.

gg.log.classpath=path_to_jars

11.3.1.2 JMS Connection Properties

The JMS connection properties set up the connection, such as how to start up the JVM for JMS integration.

• jvm.boot options
  
• jms.report.output
  
• jms.report.time
  
• jms.report.records
  
• jms.id
  
• jms.destination
  
• jms.connectionFactory
  
• jms.user, jms.password
  

11.3.1.2.1 jvm.boot options

Specifies the classpath and boot options that will be applied when the JVM starts up. The path needs colon (:) separators for UNIX/Linux and semicolons (;) for Windows.

The syntax is:

jvm.bootoptions=option[, option][. . .]

The options are the same as those passed to Java executed from the command line. They may include classpath, system properties, and JVM memory options (such as maximum memory or initial memory) that are valid for the version of Java being used. Valid options may vary based on the JVM version and provider.

For example (all on a single line):

jvm.bootoptions= -Djava.class.path=ggjava/ggjava.jar
-Dlog4j.configuration=my-log4j.properties

The log4j.configuration property could be a fully qualified URL to a log4j properties file; by default this file is searched for in the classpath. You may use your own log4j configuration, or one of the pre-configured log4j settings: log4j.properties (default level of logging), debug-log4j.properties (debug logging) or trace-log4j.properties (very verbose logging).

11.3.1.2.2 jms.report.output

Specifies where the JMS report is written. The syntax is:

jms.report.output={report|log|both}

Where:

• report sends the JMS report to the Oracle GoldenGate report file. This is the default.

• log will write to the Java log file (if one is configured)

• both will send to both locations.

11.3.1.2.3 jms.report.time

Specifies the frequency of report generation based on time.

jms.report.time=time_specification

The following examples write a report every 30 seconds, 45 minutes and eight hours.

jms.report.time=30sec
jms.report.time=45min
jms.report.time=8hr

11.3.1.2.4 jms.report.records

Specifies the frequency of report generation based on number of records. The syntax is:

jms.report.records=number

The following example writes a report every 1000 records.

jms.report.records=1000

11.3.1.2.5 jms.id

Specifies that a unique identifier with the indicated format is passed back from the JMS integration to the message capture VAM. This may be used by the VAM as a unique sequence ID for records.

jms.id={ogg|time|wmq|activemq|message_header|custom_java_class}

Where:

• ogg - returns the message header property GG_ID which is set by Oracle GoldenGate JMS delivery.

• time - uses a system timestamp as a starting point for the message ID

• wmq - reformats a WebSphere MQ Message ID for use with the VAM

• activemq - reformats an ActiveMQ Message ID for use with the VAM

• message_header - specifies your customized JMS message header to be included, such as JMSMessageID, JMSCorrelationID, or JMSTimestamp.

• custom_java_class - specifies a custom Java class that creates a string to be used as an ID.

For example:

jms.id=time
jms.id=JMSMessageID

The ID returned must be unique, incrementing, and fixed-width. If there are duplicate numbers, the duplicates are skipped. If the message ID changes length, the Extract process will abend.

11.3.1.2.6 jms.destination

Specifies the queue or topic name to be looked up using JNDI.

jms.destination=jndi_name

For example:

jms.destination=sampleQ

11.3.1.2.7 jms.connectionFactory

Specifies the connection factory name to be looked up using JNDI.

jms.connectionFactory=jndi_name

For example

jms.connectionFactory=ConnectionFactory

11.3.1.2.8 jms.user, jms.password

Sets the user name and password of the JMS connection, as specified by the JMS provider.

jms.user=user_name
jms.password=password

This is not used for JNDI security. To set JNDI authentication, see the JNDI java.naming.security properties.

For example:

jms.user=myuser
jms.password=mypasswd

11.3.1.3 JNDI Properties

In addition to specific properties for the message capture VAM, the JMS integration also supports setting JNDI properties required for connection to an Initial Context to look up the connection factory and destination. The following properties must be set:

java.naming.provider.url=url
java.naming.factory.initial=java_class_name

If JNDI security is enabled, the following properties may be set:

java.naming.security.principal=user_name
java.naming.security.credentials=password_or_other_authenticator

For example:

java.naming.provider.url= t3://localhost:7001
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.security.principal=jndiuser
java.naming.security.credentials=jndipw

11.3.2 Parser Properties

Properties specify the formats of the message and the translation rules for each type of parser: fixed, delimited, or XML. Set the parser.type property to specify which parser to use. The remaining properties are parser specific.

• Setting the Type of Parser
  
• Fixed Parser Properties
  
• Delimited Parser Properties
  
• XML Parser Properties
  

11.3.2.1 Setting the Type of Parser

The following property sets the parser type.

• parser.type
  

11.3.2.1.1 parser.type

Specifies the parser to use.

parser.type={fixed|delim|xml}

Where:

• fixed invokes the fixed width parser

• delim invokes the delimited parser

• xml invokes the XML parser

For example:

parser.type=delim

11.3.2.2 Fixed Parser Properties

The following properties are required for the fixed parser.

• fixed.schematype
  
• fixed.sourcedefs
  
• fixed.copybook
  
• fixed.header
  
• fixed.seqid
  
• fixed.timestamp
  
• fixed.timestamp.format
  
• fixed.txid
  
• fixed.txowner
  
• fixed.txname
  
• fixed.optype
  
• fixed.optype.insertval
  
• fixed.optype.updateval
  
• fixed.optype.deleteval
  
• fixed.table
  
• fixed.schema
  
• fixed.txind
  
• fixed.txind.beginval
  
• fixed.txind.middleval
  
• fixed.txind.endval
  
• fixed.txind.wholeval
  

11.3.2.2.1 fixed.schematype

Specifies the type of file used as metadata for message capture. The two valid options are sourcedefs and copybook.

fixed.schematype={sourcedefs|copybook}

For example:

fixed.schematype=copybook

The value of this property determines the other properties that must be set in order to successfully parse the incoming data.

11.3.2.2.2 fixed.sourcedefs

If the fixed.schematype=sourcedefs, this property specifies the location of the source definitions file that is to be used.

fixed.sourcedefs=file_location

For example:

fixed.sourcedefs=dirdef/hrdemo.def

11.3.2.2.3 fixed.copybook

If the fixed.schematype=copybook, this property specifies the location of the copybook file to be used by the message capture process.

fixed.copybook=file_location

For example:

fixed.copybook=test_copy_book.cpy

11.3.2.2.4 fixed.header

Specifies the name of the sourcedefs entry or copybook record that contains header information used to determine the data block structure:

fixed.header=record_name

For example:

fixed.header=HEADER

11.3.2.2.5 fixed.seqid

Specifies the name of the header field, JMS property, or system value that contains the seqid used to uniquely identify individual records. This value must be continually incrementing and the last character must be the least significant.

fixed.seqid={field_name|$jms_property|*seqid}

Where:

• field_name indicates the name of a header field containing the seqid

• jms_property uses the value of the specified JMS header property. A special value of this is $jmsid which uses the value returned by the mechanism chosen by the jms.id property

• seqid indicates a simple incrementing 64-bit integer generated by the system

For example:

fixed.seqid=$jmsid

11.3.2.2.6 fixed.timestamp

Specifies the name of the field, JMS property, or system value that contains the timestamp.

fixed.timestamp={field_name|$jms_property|*ts}

For example:

fixed.timestamp=TIMESTAMP
fixed.timestamp=$JMSTimeStamp
fixed.timestamp=*ts

11.3.2.2.7 fixed.timestamp.format

Specifies the format of the timestamp field.

fixed.timestamp.format=format

Where the format can include punctuation characters plus:

• YYYY – four digit year

• YY – two digit year

• M[M] – one or two digit month

• D[D] – one or two digit day

• HH – hours in twenty four hour notation

• MI – minutes

• SS – seconds

• Fn – n number of fractions

The default format is "YYYY-MM-DD:HH:MI:SS.FFF"

For example:

fixed.timestamp.format=YYYY-MM-DD-HH.MI.SS

11.3.2.2.8 fixed.txid

Specifies the name of the field, JMS property, or system value that contains the txid used to uniquely identify transactions. This value must increment for each transaction.

fixed.txid={field_name|$jms_property|*txid}

For most cases using the system value of *txid is preferred.

For example:

fixed.txid=$JMSTxId
fixed.txid=*txid

11.3.2.2.9 fixed.txowner

Specifies the name of the field, JMS property, or static value that contains a user name associated with a transaction. This value may be used to exclude certain transactions from processing. This is an optional property.

fixed.txowner={field_name|$jms_property|"value"}

For example:

fixed.txowner=$MessageOwner
fixed.txowner="jsmith"

11.3.2.2.10 fixed.txname

Specifies the name of the field, JMS property, or static value that contains an arbitrary name to be associated with a transaction. This is an optional property.

fixed.txname={field_name|$jms_property|"value"}

For example:

fixed.txname="fixedtx"

11.3.2.2.11 fixed.optype

Specifies the name of the field, or JMS property that contains the operation type, which is validated against the fixed.optype values specified in the next sections.

fixed.header.optype={field_name|$jms_property}

For example:

fixed.header.optype=FUNCTION

11.3.2.2.12 fixed.optype.insertval

This value identifies an insert operation. The default is I.

fixed.optype.insertval={value|\xhex_value}

For example:

fixed.optype.insertval=A

11.3.2.2.13 fixed.optype.updateval

This value identifies an update operation. The default is U.

fixed.optype.updateval={value|\xhex_value}

For example:

fixed.optype.updateval=M

11.3.2.2.14 fixed.optype.deleteval

This value identifies a delete operation.The default is D.

fixed.optype.deleteval={value|\xhex_value}

For example:

fixed.optype.deleteval=R

11.3.2.2.15 fixed.table

Specifies the name of the table. This enables the parser to find the data record definition needed to translate the non-header data portion.

fixed.table=field_name|$jms_property[, . . .]

More than one comma delimited field name may be used to determine the name of the table Each field name corresponds to a field in the header record defined by the fixed.header property or JMS property. The values of these fields are concatenated to identify the data record.

For example:

fixed.table=$JMSTableName
fixed.table=SOURCE_Db,SOURCE_Db_Rec_Version

11.3.2.2.16 fixed.schema

Specifies the static name of the schema when generating SCHEMA.TABLE table names.

fixed.schema="value"

For example:

fixed.schema="OGG"

11.3.2.2.17 fixed.txind

Specifies the name of the field or JMS property that contains a transaction indicator that is validated against the transaction indicator values. If this is not defined, all operations within a single message will be seen to have occurred within a whole transaction. If defined, then it determines the beginning, middle and end of transactions. Transactions defined in this way can span messages. This is an optional property.

fixed.txind={field_name|$jms_property}

For example:

fixed.txind=$TX_IND

11.3.2.2.18 fixed.txind.beginval

This value identifies an operation as the beginning of a transaction. The defaults is B.

fixed.txind.beginval={value|\xhex_value}

For example:

fixed.txind.beginval=0

11.3.2.2.19 fixed.txind.middleval

This value identifies an operation as the middle of a transaction. The default is M.

fixed.txind.middleval={value|\xhex_value}

For example:

fixed.txind.middleval=1

11.3.2.2.20 fixed.txind.endval

This value identifies an operation as the end of a transaction. The default is E.

fixed.txind.endval={value|\xhex_value}

For example:

fixed.txind.endval=2

11.3.2.2.21 fixed.txind.wholeval

This value identifies an operation as a whole transaction. The default is W.

fixed.txind.wholeval={value|\xhex_value}

For example:

fixed.txind.wholeval=3

11.3.2.3 Delimited Parser Properties

The following properties are required for the delimited parser except where otherwise noted.

• delim.sourcedefs
  
• delim.header
  
• delim.seqid
  
• delim.timestamp
  
• delim.timestamp.format
  
• delim.txid
  
• delim.txowner
  
• delim.txname
  
• delim.optype
  
• delim.optype.insertval
  
• delim.optype.updateval
  
• delim.optype.deleteval
  
• delim.schemaandtable
  
• delim.schema
  
• delim.table
  
• delim.txind
  
• delim.txind.beginval
  
• delim.txind.middleval
  
• delim.txind.endval
  
• delim.txind.wholeval
  
• delim.fielddelim
  
• delim.linedelim
  
• delim.quote
  
• delim.nullindicator
  
• delim.fielddelim.escaped
  
• delim.linedelim.escaped
  
• delim.quote.escaped
  
• delim.nullindicator.escaped
  
• delim.hasbefores
  
• delim.hasnames
  
• delim.afterfirst
  
• delim.isgrouped
  
• delim.dateformat | delim.dateformat.table | delim.dateform.table.column
  

11.3.2.3.1 delim.sourcedefs

Specifies the location of the source definitions file to use.

delim.sourcedefs=file_location

For example:

delim.sourcedefs=dirdef/hrdemo.def

11.3.2.3.2 delim.header

Specifies the list of values that come before the data and assigns names to each.

delim.header=name[,name2][. . .]

The names must be unique. They can be referenced in other delim properties or wherever header fields can be used.

For example:

delim.header=optype, tablename, ts
delim.timestamp=ts

11.3.2.3.3 delim.seqid

Specifies the name of the header field, JMS property, or system value that contains the seqid used to uniquely identify individual records. This value must increment and the last character must be the least significant.

delim.seqid={field_name|$jms_property|*seqid}

Where:

• field_name indicates the name of a header field containing the seqid

• jms_property uses the value of the specified JMS header property, a special value of this is $jmsid which uses the value returned by the mechanism chosen by the jms.id property

• seqid indicates a simple continually incrementing 64-bit integer generated by the system

For example:

delim.seqid=$jmsid

11.3.2.3.4 delim.timestamp

Specifies the name of the JMS property, header field, or system value that contains the timestamp.

delim.timestamp={field_name|$jms_property|*ts}

For example:

delim.timestamp=TIMESTAMP
delim.timestamp=$JMSTimeStamp
delim.timestamp=*ts

11.3.2.3.5 delim.timestamp.format

Specifies the format of the timestamp field.

delim.timestamp.format=format

Where the format can include punctuation characters plus:

• YYYY – four digit year

• YY – two digit year

• M[M] – one or two digit month

• D[D] – one or two digit day

• HH – hours in twenty four hour notation

• MI – minutes

• SS – seconds

• Fn – n number of fractions

The default format is "YYYY-MM-DD:HH:MI:SS.FFF"

For example:

delim.timestamp.format=YYYY-MM-DD-HH.MI.SS

11.3.2.3.6 delim.txid

Specifies the name of the JMS property, header field, or system value that contains the txid used to uniquely identify transactions. This value must increment for each transaction.

delim.txid={field_name|$jms_property|*txid}

For most cases using the system value of *txid is preferred.

For example:

delim.txid=$JMSTxId
delim.txid=*txid

11.3.2.3.7 delim.txowner

Specifies the name of the JMS property, header field, or static value that contains an arbitrary user name associated with a transaction. This value may be used to exclude certain transactions from processing. This is an optional property.

delim.txowner={field_name|$jms_property|"value"}

For example:

delim.txowner=$MessageOwner
delim.txowner="jsmith"

11.3.2.3.8 delim.txname

Specifies the name of the JMS property, header field, or static value that contains an arbitrary name to be associated with a transaction. This is an optional property.

delim.txname={field_name|$jms_property|"value"}

For example:

delim.txname="fixedtx"

11.3.2.3.9 delim.optype

Specifies the name of the JMS property or header field that contains the operation type. This is compared to the values for delim.optype.insertval, delim.optype.updateval and delim.optype.deleteval to determine the operation.

delim.optype={field_name|$jms_property}

For example:

delim.optype=optype

11.3.2.3.10 delim.optype.insertval

This value identifies an insert operation. The default is I.

delim.optype.insertval={value|\xhex_value}

For example:

delim.optype.insertval=A

11.3.2.3.11 delim.optype.updateval

This value identifies an update operation. The default is U.

delim.optype.updateval={value|\xhex_value}

For example:

delim.optype.updateval=M

11.3.2.3.12 delim.optype.deleteval

This value identifies a delete operation. The default is D.

delim.optype.deleteval={value|\xhex_value}

For example:

delim.optype.deleteval=R

11.3.2.3.13 delim.schemaandtable

Specifies the name of the JMS property or header field that contains the schema and table name in the form SCHEMA.TABLE.

delim.schemaandtable={field_name|$jms_property}

For example:

delim.schemaandtable=$FullTableName

11.3.2.3.14 delim.schema

Specifies the name of the JMS property, header field, or hard-coded value that contains the schema name.

delim.schema={field_name|$jms_property|"value"}

For example:

delim.schema="OGG"

11.3.2.3.15 delim.table

Specifies the name of the JMS property or header field that contains the table name.

delim.table={field_name|$jms_property}

For example:

delim.table=TABLE_NAME

11.3.2.3.16 delim.txind

Specifies the name of the JMS property or header field that contains the transaction indicator to be validated against beginval, middleval, endval or wholeval. All operations within a single message will be seen as within one transaction if this property is not set. If it is set it determines the beginning, middle and end of transactions. Transactions defined in this way can span messages. This is an optional property.

delim.txind={field_name|$jms_property}

For example:

delim.txind=txind

11.3.2.3.17 delim.txind.beginval

The value that identifies an operation as the beginning of a transaction. The default is B.

delim.txind.beginval={value|\xhex_value}

For example:

delim.txind.beginval=0

11.3.2.3.18 delim.txind.middleval

The value that identifies an operation as the middle of a transaction. The default is M.

delim.txind.middleval={value|\xhex_value}

For example:

delim.txind.middleval=1

11.3.2.3.19 delim.txind.endval

The value that identifies an operation as the end of a transaction. The default is E.

delim.txind.endval={value|\xhex_value}

For example:

delim.txind.endval=2

11.3.2.3.20 delim.txind.wholeval

The value that identifies an operation as a whole transaction. The default is W.

delim.txind.wholeval={value|\xhex_value}

For example:

delim.txind.wholeval=3

11.3.2.3.21 delim.fielddelim

Specifies the delimiter value used to separate fields (columns) in the data. This value is defined through characters or hexadecimal values:

delim.fielddelim={value|\xhex_value}

For example:

delim.fielddelim=,
delim.fielddelim=\xc7

11.3.2.3.22 delim.linedelim

Specifies the delimiter value used to separate lines (records) in the data. This value is defined using characters or hexadecimal values.

delim.linedelim={value|\xhex_value}

For example:

delim.linedelim=||
delim.linedelim=\x0a

11.3.2.3.23 delim.quote

Specifies the value used to identify quoted data. This value is defined using characters or hexadecimal values.

delim.quote={value|\xhex_value}

For example:

delim.quote="

11.3.2.3.24 delim.nullindicator

Specifies the value used to identify NULL data. This value is defined using characters or hexadecimal values.

delim.nullindicator={value|\xhex_value}

For example:

delim.nullindicator=NULL

11.3.2.3.25 delim.fielddelim.escaped

Specifies the value that will replace the field delimiter when the field delimiter occurs in the input field. The syntax is:

delim.fielddelim.escaped={value|\xhex_value}

For example, given the following property settings:

delim.fielddelim=-
delim.fielddelim.escaped=$#$

If the data does not contain the hyphen delimiter within any of the field values:

one two three four

The resulting delimited data is:

one-two-three-four

If there are hyphen (-) delimiters within the field values:

one two three four-fifths two-fifths

The resulting delimited data is:

one-two-three-four$#$fifths-two$#$fifths

11.3.2.3.26 delim.linedelim.escaped

Specifies the value that will replace the line delimiter when the line delimiter occurs in the input data. The syntax is:

delim.linedelim.escaped={value|\xhex_value}

For example, given the following property settings:

delim.linedelim=\
delim.linedelim.escaped=%/%

If the input lines are:

These are the lines and they
do not contain the delimiter.

Because the lines do not contain the backslash (\), the result is:

These are the lines and they\
do not contain the delimiter.\

However, if the input lines do contain the delimiter:

These are the lines\data values
and they do contain the delimiter.

So the results are:

These are the lines%/%data values\
and they do contain the delimiter.\

11.3.2.3.27 delim.quote.escaped

Specifies the value that will replace a quote delimiter when the quote delimiter occurs in the input data. The syntax is:

delim.quote.escaped={value|\xhex_value}

For example, given the following property settings:

delim.quote="
delim.quote.escaped="'"

If the input data does not contain the quote (") delimiter:

It was a very original play.

The result is:

"It was a very original play."

However, if the input data does contain the quote delimiter:

It was an "uber-original" play.

The result is:

"It was an "'"uber-original"'" play."

11.3.2.3.28 delim.nullindicator.escaped

Specifies the value that will replace a null indicator when a null indicator occurs in the input data. The syntax is:

delim.nullindicator.escaped={value|\xhex_value}

For example, given the following property settings:

delim.fielddelim=,
delim.nullindicator=NULL
delim.nullindicator.escaped=$NULL$

When the input data does not contain a NULL value or a NULL indicator:

1 2 3 4 5

The result is

1,2,3,4,5

When the input data contains a NULL value:

1 2 4 5

The result is

1,2,NULL,4,5

When the input data contains a NULL indicator:

1 2 NULL 4 5

The result is:

1,2,$NULL$,4,5

11.3.2.3.29 delim.hasbefores

Specifies whether before values are present in the data.

delim.hasbefores={true|false}

The default is false. The parser expects to find before and after values of columns for all records if delim.hasbefores is set to true. The before values are used for updates and deletes, the after values for updates and inserts. The afterfirst property specifies whether the before images are before the after images or after them. If delim.hasbefores is false, then no before values are expected.

For example:

delim.hasbefores=true

11.3.2.3.30 delim.hasnames

Specifies whether column names are present in the data.

delim.hasnames={true|false}

The default is false. If true, the parser expects to find column names for all records. The parser validates the column names against the expected column names. If false, no column names are expected.

For example:

delim.hasnames=true

11.3.2.3.31 delim.afterfirst

Specifies whether after values are positioned before or after the before values.

delim.afterfirst={true|false}

The default is false. If true, the parser expects to find the after values before the before values. If false, the after values are before the before values.

For example:

delim.afterfirst=true

11.3.2.3.32 delim.isgrouped

Specifies whether the column names and before and after images should be expected grouped together for all columns or interleaved for each column.

delim.isgrouped={true|false}

The default is false. If true, the parser expects find a group of column names (if hasnames is true), followed by a group of before values (if hasbefores), followed by a group of after values (the afterfirst setting will reverse the before and after value order). If false, the parser will expect to find a column name (if hasnames), before value (if hasbefores) and after value for each column.

For example:

delim.isgrouped=true

11.3.2.3.33 delim.dateformat | delim.dateformat.table | delim.dateform.table.column

Specifies the date format for column data. This is specified at a global level, table level or column level.The format used to parse the date is a subset of the formats used for parser.timestamp.format.

delim.dateformat=format
delim.dateformat.TABLE=format
delim.dateformat.TABLE.COLUMN=format

Where:

• format is the format defined for parser.timestamp.format.

• table is the fully qualified name of the table that is currently being processed.

• column is a column of the specified table.

For example:

delim.dateformat=YYYY-MM-DD HH:MI:SS
delim.dateformat.MY.TABLE=DD/MM/YY-HH.MI.SS
delim.dateformat.MY.TABLE.EXP_DATE=YYMM

11.3.2.4 XML Parser Properties

The following properties are used by the XML parser.

• xml.sourcedefs
  
• xml.rules
  
• rulename.type
  
• rulename.match
  
• rulename.subrules
  
• txrule.timestamp
  
• txrule.timestamp.format
  
• txrule.seqid
  
• txrule.txid
  
• txrule.txowner
  
• txrule.txname
  
• oprule.timestamp
  
• oprule.timestamp.format
  
• oprule.seqid
  
• oprule.txid
  
• oprule.txowner
  
• oprule.txname
  
• oprule.schemandtable
  
• oprule.schema
  
• oprule.table
  
• oprule.optype
  
• oprule.optype.insertval
  
• oprule.optype.updateval
  
• oprule.optype.deleteval
  
• oprule.txind
  
• oprule.txind.beginval
  
• oprule.txind.middleval
  
• oprule.txind.endval
  
• oprule.txind.wholeval
  
• colrule.name
  
• colrule.index
  
• colrule.value
  
• colrule.isnull
  
• colrule.ismissing
  
• colrule.before.value
  
• colrule.before.isnull
  
• colrule.before.ismissing
  
• colrule.after.value
  
• colrule.after.isnull
  
• colrule.after.ismissing
  

11.3.2.4.1 xml.sourcedefs

Specifies the location of the source definitions file.

xml.sourcedefs=file_location

For example:

xml.sourcedefs=dirdef/hrdemo.def

11.3.2.4.2 xml.rules

Specifies the list of XML rules for parsing a message and converting to transactions, operations and columns:

xml.rules=xml_rule_name[, . . .]

The specified XML rules are processed in the order listed. All rules matching a particular XML document may result in the creation of transactions, operations and columns. The specified XML rules should be transaction or operation type rules.

For example:

xml.rules=dyntxrule, statoprule

11.3.2.4.3 rulename.type

Specifies the type of XML rule.

rulename.type={tx|op|col}

Where:

• tx indicates a transaction rule

• op indicates an operation rule

• col indicates a column rule

For example:

dyntxrule.type=tx
statoprule.type=op

11.3.2.4.4 rulename.match

Specifies an XPath expression used to determine whether the rule is activated for a particular document or not.

rulename.match=xpath_expression

If the XPath expression returns any nodes from the document, the rule matches and further processing occurs. If it does not return any nodes, the rule is ignored for that document.

The following example activates the dyntxrule if the document has a root element of Transaction

dyntxrule.match=/Transaction

Where statoprule is a sub rule of stattxtule, the following example activates the statoprule if the parent rule's matching nodes have child elements of NewMyTableEntry.

statoprule.match=./NewMyTableEntry

11.3.2.4.5 rulename.subrules

Specifies a list of rule names to check for matches if the parent rule is activated by its match.

rulename.subrules=xml_rule_name[, . . .]

The specified XML rules are processed in the order listed. All matching rules may result in the creation of transactions, operations and columns.

Valid sub-rules are determined by the parent type. Transaction rules can only have operation sub-rules. Operation rules can have operation or column sub-rules. Column rules cannot have sub-rules.

For example:

dyntxrule.subrules=dynoprule
statoprule.subrules=statkeycolrule, statcol1rule

11.3.2.4.6 txrule.timestamp

Controls the transaction timestamp by instructing the adapter to 1) use the transaction commit timestamp contained in a specified XPath expression or JMS property or 2) use the current system time. This is an optional property.

txrule.timestamp={xpath_expression|$jms_property|*ts}

The timestamp for the transaction may be overridden at the operation level, or may only be present at the operation level. Any XPath expression must end with a value, accessor, such as @att or text().

For example:

dyntxrule.timestamp=@ts

11.3.2.4.7 txrule.timestamp.format

Specifies the format of the timestamp field.

txrule.timestamp.format=format

Where the format can include punctuation characters plus:

• YYYY – four digit year

• YY – two digit year

• M[M] – one or two digit month

• D[D] – one or two digit day

• HH – hours in twenty four hour notation

• MI – minutes

• SS – seconds

• Fn – n number of fractions

The default format is "YYYY-MM-DD:HH:MI:SS.FFF"

For example:

dyntxrule.timestamp.format=YYYY-MM-DD-HH.MI.SS

11.3.2.4.8 txrule.seqid

Specifies the seqid for a particular transaction. This can be used when there are multiple transactions per message. Determines the XPath expression, JMS property, or system value that contains the transactions seqid. Any XPath expression must end with a value accessor such as @att or text().

txrule.seqid={xpath_expression|$jms_property|*seqid}

For example:

dyntxrule.seqid=@seqid

11.3.2.4.9 txrule.txid

Specifies the XPath expression, JMS property, or system value that contains the txid used to unique identify transactions. This value must increment for each transaction.

txrule.txid={xpath_expression|$jms_property|*txid}

For most cases using the system value of *txid is preferred.

For example:

dyntxrule.txid=$JMSTxId
dyntxrule.txid=*txid

11.3.2.4.10 txrule.txowner

Specifies the XPath expression, JMS property, or static value that contains an arbitrary user name associated with a transaction. This value may be used to exclude certain transactions from processing.

txrule.txowner={xpath_expression|$jms_property|"value"}

For example:

dyntxrule.txowner=$MessageOwner
dyntxrule.txowner="jsmith"

11.3.2.4.11 txrule.txname

Specifies the XPath expression, JMS property, or static value that contains an arbitrary name to be associated with a transaction. This is an optional property.

txrule.txname={xpath_expression|$jms_property|"value"}

For example:

dyntxrule.txname="fixedtx"

11.3.2.4.12 oprule.timestamp

Controls the operation timestamp by instructing the adapter to 1) use the transaction commit timestamp contained in a specified XPath expression or JMS property or 2) use the current system time. This is an optional property.

oprule.timestamp={xpath_expression|$jms_property|*ts}

The timestamp for the operation will override a timestamp at the transaction level.

Any XPath expression must end with a value accessor such as @att or text().

For example:

statoprule.timestamp=./CreateTime/text()

11.3.2.4.13 oprule.timestamp.format

Specifies the format of the timestamp field.

oprule.timestamp.format=format

Where the format can include punctuation characters plus:

• YYYY – four digit year

• YY – two digit year

• M[M] – one or two digit month

• D[D] – one or two digit day

• HH – hours in twenty four hour notation

• MI – minutes

• SS – seconds

• Fn – n number of fractions

The default format is "YYYY-MM-DD:HH:MI:SS.FFF"

For example:

statoprule.timestamp.format=YYYY-MM-DD-HH.MI.SS

11.3.2.4.14 oprule.seqid

Specifies the seqid for a particular operation. Use the XPath expression, JMS property, or system value that contains the operation seqid. This overrides any seqid defined in parent transaction rules. Must be present if there is no parent transaction rule.

Any XPath expression must end with a value accessor such as @att or text().

oprule.seqid={xpath_expression|$jms_property|*seqid}

For example:

dynoprule.seqid=@seqid

11.3.2.4.15 oprule.txid

Specifies the XPath expression, JMS property, or system value that contains the txid used to uniquely identify transactions. This overrides any txid defined in parent transaction rules and is required if there is no parent transaction rule. The value must be incremented for each transaction.

oprule.txid={xpath_expression|$jms_property|*txid}

For most cases using the system value of *txid is preferred.

For example:

dynoprule.txid=$JMSTxId
dynoprule.txid=*txid

11.3.2.4.16 oprule.txowner

Specifies the XPath expression, JMS property, or static value that contains an arbitrary user name associated with a transaction. This value may be used to exclude certain transactions from processing. This is an optional property.

oprule.txowner={xpath_expression|$jms_property|"value"}

For example:

dynoprule.txowner=$MessageOwner
dynoprule.txowner="jsmith"

11.3.2.4.17 oprule.txname

Specifies the XPath expression, JMS property, or static value that contains an arbitrary name to be associated with a transaction. This is an optional property.

oprule.txname={xpath_expression|$jms_property|"value"}

For example:

dynoprule.txname="fixedtx"

11.3.2.4.18 oprule.schemandtable

Specifies the XPath expression JMS property or hard-coded value that contains the schema and table name in the form SCHEMA.TABLE. Any XPath expression must end with a value accessor such as @att or text(). The value is verified to ensure the table exists in the source definitions.

oprule.schemaandtable={xpath_expression|$jms_property|"value"}

For example:

statoprule.schemaandtable="MY.TABLE"

11.3.2.4.19 oprule.schema

Specifies the XPath expression, JMS property or hard-coded value that contains the schema name. Any XPath expression must end with a value accessor such as @att or text().

oprule.schema={xpath_expression|$jms_property|"value"}

For example:

statoprule.schema=@schema

11.3.2.4.20 oprule.table

Specifies the XPath expression, JMS property or hard-coded value that contains the table name. Any XPath expression must end with a value accessor such as @att or text().

oprule.table={xpath_expression|$jms_property|"value"}

For example:

statoprule.table=$TableName

11.3.2.4.21 oprule.optype

Specifies the XPath expression, JMS property or literal value that contains the optype to be validated against an optype insertval. Any XPath expression must end with a value accessor such as @att or text().

oprule.optype={xpath_expression|$jms_property|"value"}

For example:

dynoprule.optype=@type
statoprule.optype="I"

11.3.2.4.22 oprule.optype.insertval

Specifies the value that identifies an insert operation. The default is I.

oprule.optype.insertval={value|\xhex_value}

For example:

dynoprule.optype.insertval=A

11.3.2.4.23 oprule.optype.updateval

Specifies the value that identifies an update operation. The default is U.

oprule.optype.updateval={value|\xhex_value}

For example:

dynoprule.optype.updateval=M

11.3.2.4.24 oprule.optype.deleteval

Specifies the value that identifies a delete operation. The default is D.

oprule.optype.deleteval={value|\xhex_value}

For example:

dynoprule.optype.deleteval=R

11.3.2.4.25 oprule.txind

Specifies the XPath expression or JMS property that contains the transaction indicator to be validated against beginval or other value that identifies the position within the transaction. All operations within a single message are regarded as occurring within a whole transaction if this property is not defined. Specifies the begin, middle and end of transactions. Any XPath expression must end with a value accessor such as @att or text(). Transactions defined in this way can span messages. This is an optional property.

oprule.txind={xpath_expression|$jms_property}

For example:

dynoprule.txind=@txind

11.3.2.4.26 oprule.txind.beginval

Specifies the value that identifies an operation as the beginning of a transaction. The default is B.

oprule.txind.beginval={value|\xhex_value}

For example:

dynoprule.txind.beginval=0

11.3.2.4.27 oprule.txind.middleval

Specifies the value that identifies an operation as the middle of a transaction. The default is M.

oprule.txind.middleval={value|\xhex_value}

For example:

dynoprule.txind.middleval=1

11.3.2.4.28 oprule.txind.endval

Specifies the value that identifies an operation as the end of a transaction. The default is E.

oprule.txind.endval={value|\xhex_value}

For example:

dynoprule.txind.endval=2

11.3.2.4.29 oprule.txind.wholeval

Specifies the value that identifies an operation as a whole transaction. The default is W.

oprule.txind.wholeval={value|\xhex_value}

For example:

dynoprule.txind.wholeval=3

11.3.2.4.30 colrule.name

Specifies the XPath expression or hard-coded value that contains a column name. The column index must be specified if this is not and the column name will be resolved from that. If specified the column name will be verified against the source definitions file. Any XPath expression must end with a value accessor such as @att or text().

colrule.name={xpath_expression|"value"}

For example:

dyncolrule.name=@name
statkeycolrule.name="keycol"

11.3.2.4.31 colrule.index

Specifies the XPath expression or hard-coded value that contains a column index. If not specified then the column name must be specified and the column index will be resolved from that. If specified the column index will be verified against the source definitions file. Any XPath expression must end with a value accessor such as @att or text().

colrule.index={xpath_expression|"value"}

For example:

dyncolrule.index=@index
statkeycolrule.index=1

11.3.2.4.32 colrule.value

Specifies the XPath expression or hard-coded value that contains a column value. Any XPath expression must end with a value accessor such as @att or text(). If the XPath expression fails to return any data because a node or attribute does not exist, the column value will be deemed as null. To differentiate between null and missing values (for updates) the isnull and ismissing properties should be set. The value returned is used for delete before values, and update/insert after values.

colrule.value={xpath_expression|"value"}

For example:

statkeycolrule.value=./text()

11.3.2.4.33 colrule.isnull

Specifies the XPath expression used to discover if a column value is null. The XPath expression must end with a value accessor such as @att or text(). If the XPath expression returns any value, the column value is null. This is an optional property.

colrule.isnull=xpath_expression

For example:

dyncolrule.isnull=@isnull

11.3.2.4.34 colrule.ismissing

Specifies the XPath expression used to discover if a column value is missing. The XPath expression must end with a value accessor such as @att or text(). If the XPath expression returns any value, then the column value is missing. This is an optional property.

colrule.ismissing=xpath_expression

For example:

dyncolrule.ismissing=./missing

11.3.2.4.35 colrule.before.value

Overrides colrule.value to specifically say how to obtain before values used for updates or deletes. This has the same format as colrule.value. This is an optional property.

For example:

dyncolrule.before.value=./beforevalue/text()

11.3.2.4.36 colrule.before.isnull

Overrides colrule.isnull to specifically say how to determine if a before value is null for updates or deletes. This has the same format as colrule.isnull. This is an optional property.

For example:

dyncolrule.before.isnull=./beforevalue/@isnull

11.3.2.4.37 colrule.before.ismissing

Overrides colrule.ismissing to specifically say how to determine if a before value is missing for updates or deletes. This has the same format as colrule.ismissing. This is an optional property.

For example:

dyncolrule.before.ismissing=./beforevalue/missing

11.3.2.4.38 colrule.after.value

Overrides colrule.value to specifically say how to obtain after values used for updates or deletes. This has the same format as colrule.value. This is an optional property.

For example:

dyncolrule.after.value=./aftervalue/text()

11.3.2.4.39 colrule.after.isnull

Overrides colrule.isnull to specifically say how to determine if an after value is null for updates or deletes. This has the same format as colrule.isnull. This is an optional property.

For example:

dyncolrule.after.isnull=./aftervalue/@isnull

11.3.2.4.40 colrule.after.ismissing

Overrides colrule.ismissing to specifically say how to determine if an after value is missing for updates or deletes. This has the same format as colrule.ismissing. This is an optional property.

For example:

dyncolrule.after.ismissing=./aftervalue/missing