Pro2 is written completely in ABL and has been designed for scalability and customization. You can customize auditing, source changes capturing, record maintenance, datatype, and name transformation.

Capture source changes by SQL clients

The standard Pro2 replication triggers capture changes made by ABL clients. Pro2 can also capture changes made to the source OpenEdge database by SQL clients. To do this, java triggers can be implemented in the OpenEdge source database.

Audit database

Pro2 can be extended to write to a second target database to maintain audit records. Whereas each row is unique in the primary replication database (via PRROWID column), the audit database has multiple rows corresponding to each source database record, with a new row created for each change made to the source record. Auditing is implemented by having a second pass through the repl queue by a separate replication processor designated for the audit database. Typically, when auditing is implemented, a subset of the replicated tables is audited, however, it is possible to audit all tables.

Logical deletes

There are times when auditing is not required however it is desired to maintain records in the target database after they are deleted from the source database. In this case, instead of being deleted, rows are designated as logical deletes (via PRROWID modification) and the data is kept in the source database.

Data type and name transformation

Data types on the target side can be the same as on the source database or they can be different. For example, precision of decimal types can be decreased, logical fields can be changed to character, and integers can be changed to logical.

If you do not need the default conversion of datatypes, enable the TGT_DATATYPE_OVERRIDE property. This property retains the value of a datatype as is and does not convert it to meet the target schema requirements. However, you must recheck the validations as they may fail.

Table and column names on the target database can be the same or different from those on the source database(s). If they are the same, the Pro2 Auto-map function is used. Otherwise, the tables are manually mapped, however, mapping needs to be done once only and saved for use in subsequent implementations.

If you want to use literal table and column names for your target database (SQL only), you can enable the TGT_USE_LITERAL_NAMES property. This property allows you to use the same naming convention as the source database for tables and columns without modifying them to meet the requirements of the target database. Another property GEN_SQL_DEC_FORMAT, is used to set the format for decimal fields in both schema and differential files. If the property is set to YES, the format is same as in the source database. If it is set to NO then the default format [decimal(17,2) null] is used. The default value for this property is NO.