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.

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

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