To use audits in the exchange module

The audit server logs all database actions that change the contents of a table in so-called audit files. These audit files can be used by the Exchange module. Audit files are useful in a multisite environment because the databases on all sites must have identical data. They can also be used in data conversions.

Only the updates in a specific period are exchanged, leading to an improvement in performance. Specify this period in the Export Data (Non-Regular) (daxch0233m000), Export Data (on a Regular Basis) (daxch0234m000) sessions. Changes like insert, update and delete are processed and written into the ASCII files. Actions like drop, clear and create tables are ignored.

Audit control data is added to the resulting ASCII file, consisting of a batchline-id, transaction-id, sequence-id and an indicator. The control data is added at the beginning of each line and is formatted like other data fields like the enclosing and separator characters.

An update writes two lines to the ASCII file. One line contains the keyfields and old values of the updated fields. The other line contains the new values of the keyfields and updated fields, even if a keyfield does not change.

The batchline-id is used for recognition when processing the ASCII files. The transaction- and sequence-id are used to make sure that the transactions are replayed in the same order as on the exporting site. The indicator defines the type of action that is executed on the table. Use the letter I for inserting, the letter D for deleting, U for updating with old values and the letter N for updating with new values.

Select the Based on Audit check box in the Exchange Schemes (daxch0101s000) session to enable this functionality.

Audit configuration

If you use audit files for data exchange make sure to:

Audit all involved export tables by defining an audit profile. The audit profile can be generated for an exchange scheme using the Generate Audit Configuration (daxch1201m000) session, which is available from the appropriate menu of the Exchange Schemes (daxch0501m000) session.
Have enough space in the $BSE_TMP directory because all ASCII files are merged into one file during an import. This file contains the audit control data and is sorted on transaction-id and sequence-id.

To be sure that all changes made in the database are audited, a transaction notification is created in the database for each database transaction being audited. The transaction notification is inserted within the user transaction, and used by Exchange to collect the audit data. This way we are always sure that all changes are processed.

Limitations of the Exchange (XCH) module based on audit

When exchanging based on audit it is important that the sequence in which the database actions are imported is the same as the sequence in which those database actions were executed on the original database by the end users. the Exchange module based on audit guarantees that the sequence of the transactions and the sequence of the database actions within each transaction are preserved. This is also the case for transactions in which multiple tables are involved.

Restrictions on exchange models

The batchline-ids have to be identical on the export and import sites. Do not use conditions for updates that integrate two fields into one field. The audit server only logs keyfields and changed fields, therefore if only one field changes the other value will not be present in the ASCII-field.

Be careful when using conditions in the import part of exchange models that are used for auditing. They can create unsolvable problems. For example, a condition that integrates two fields into one field cannot be used for updates. The audit server only logs keyfields and changed fields, therefore if only one field has changed, the other value will not be present in the ASCII field.

Export

The table and ASCII file definition do not have to match. Table fields that are not attached to an ASCII field are ignored and ASCII fields that are not attached to a table field are left empty.
The names do not have to match anymore (as in earlier releases), the data maintained in session is used to link table fields with ASCII fields.
Conditions cannot be used.
Constants cannot be used (at this moment).

Import

The names do not have to match anymore (as in earlier releases), the data maintained in session is used to link table fields with ASCII fields.
For inserts the full functionality is available, like constants, conditions and relations.
Idem for overwrite (inserting an already existing record), as long as the Overwrite Condition field returns true.
The same for deletes, but note that only the keyfields are assigned their values (thus conditions, that are attached to non-keyfields, having side-effects, probably won't work correctly).
Note that relations based on Increment are meaningless for deletes.

It is difficult for updates to provide the full functionality:

Relations for which the Based on field is defined as Default, Fixed value, or increment are ignored, because they are not useful.
Relations based on Field value or Conv. table can be used without any restrictions. But they will only be applied on keyfields (old values) and changed fields (new values).
As the audit server only logs keyfields and changed fields for an update the other fields are not known. Thus many fields in the ascii file will remain empty. If conditions are used it is not known whether all accessed fields have valid values. If not, the condition should probably not be executed. To provide you with the flexibility of conditions, even in case audit is used, you can guard conditions by the Update Condition field condition. It is assumed that this condition decides whether the condition (at field value level) can return a proper value. For this the function changed (<ascii_file>_<field>) can be used in your condition.
Note that, by the introduction of parameters by condition, all accessed ASCII fields are known and thus it can be decided whether all ASCII fields have valid values. However this knowledge has not been explored in the current version.
The old value of the ascii field can be accessed via: not.curr(<ascii_file>_<field>) old.value = <ascii_file>_<field> not.curr(<ascii_file>_<field>) | restore new value! The old value of the tablefield is in the tablefield itself (first the condition is executed, and only on returning the value is assigned to the tablefield.