Table of Contents

Search

  1. Preface
  2. Introduction
  3. Servers
  4. Console Client
  5. Search Clients
  6. Table Loader
  7. Update Synchronizer
  8. Globalization
  9. Siebel Connector
  10. Web Services
  11. ASM Workbench
  12. Cluster Merge Rules
  13. Forced Link and Unlink
  14. System Backup and Restore
  15. Batch Utilities

Transaction File / Table

Transaction File / Table

In the cases where MDM Registry Edition cannot create triggers on the USTs (for example, when the source database is not supported), or a flat file was used as input to the Table Loader, update transactions must be provided in either a "flat file" or an NSA Transaction Table.

Flat-File Layout

The "flat file" is a binary file containing fixed length records (with no newline separators). It must start with a Control Record. The Control Record is immediately followed Transaction Records. Each Transaction Record consists of a fixed length header followed by an IDT record.
Alternatively, the transaction file can be treated as a text file when the Synchronizer is started with the
-n
switch. In text mode, the Control Record and all Transaction Records must be separated by a newline character. Text mode is only suitable when the IDT records do not contain any binary data that may be confused with a newline. A binary input file is the preferred and safest option.

Control Record

Offset
Length
Description
0
4
Version
4
32
System Name
36
32
Time Stamp
68
64
Reserved for future use
Version
Defines the version of the Control Record. The only valid value is "0001".
System Name
Defines the System that these transactions belong to. Only one System per transaction file is permitted.
Time Stamp
An alphanumeric string containing the date and time when the file was created. The Synchronizer saves this field in its restart information. Format is
"YYYYMMDD HH:MM:SS"
without the quotes.
Reserved
This is not used currently.

Transaction Record

Offset
Length
Description
0
10
Sequence Number
10
1
Operation Code
11
32
IDT Name
43
variable
IDT Record
Sequence Number
The Transaction Sequence Number represented by printable decimal digits. The input file must contain ascending sequence numbers (right justified and zero filled) starting from
0000000001
, without any gaps in the sequence numbers.
Operation Code
Defines the operation to be applied. Valid values are ’A’ meaning add this IDT record, and ’D’ meaning delete this IDT record.
IDT Name
The name of the IDT that this record belongs to. This is the fully decorated table name as it appears on the target database. For example an IDT named
IDT-99
in the definition file stored on
dbid 01
, would be called
IDS_01_IDT_99
.
IDT Record
The IDT record in the MDM Registry Edition database format. Fields must be in the same order as defined in the UST-Definition Section of the SDF file. For more information about the field types, see
Informatica MDM Registry Edition Design Guide
.

Flat-File Rules

The transaction file must be closed by the creating application prior to being used as input to the Synchronizer. The content of the transaction file must not be changed once the update Synchronizer has started using it. Once all transactions have been processed successfully, as verified by inspection of the Update Synchronizer output, the file might be deleted.
The Synchronizer uses the Transaction File Name appended to the System Name to store restart information (like the Time Stamp). When the Synchronizer restarts, it checks the Time Stamp in the Control Record against the stored value. If they differ it reports a "loss of synchronization error" and aborts. This is because the contents of the input file has changed since it was first used.
Restart information is never removed. This is a safeguard against accidental reapplication of the same transaction file. If this were to occur, the Synchronizer will recognize that it has completed processing the file and ignore the transactions.
Since restart information is not removed, Transaction File Names can not be reused. The best approach is to generate file names from the current date and time such that each one is unique. This also helps to identify which one is to be applied next (as transactions must be applied in chronological order).
There is no operation code for an update. Updates are processed using the trigger paradigm. That is, an "update" consists of two transactions; a delete transaction (containing a copy of the IDT record prior to the "update"), followed by an add transaction (containing a copy of the IDT record after the "update").
Special handling is required for non-unique PKs. The Synchronizer will delete all records with the same PK value when processing a Delete transaction (as it does not distinguish between them). The user must re-add other records that should have not been deleted (if desired).
The IDT layout must be specified in the UST-Definition Section of the SDF file and not the Files- Definition. The latter is used for unsynchronized flat-file input. Refer to the
User Source Table
section of the
DESIGN GUIDE
.

NSA Transaction Table

NSA is an acronym for No Source Access. The NSA Transaction Table (NSATT) is used to store transactions pertaining to a source database to which we have no source access (non-SQL or unsupported DBMS).
The transaction data contained within the NSATT is similar to a Flat-File. It contains the following columns:
Column
Max Length
Description
SYSTEM
32
System Name
SEQ
32
Transaction Sequence
OP
1
Operation Code (’A’ or ’D’)
IDT_NAME
32
IDT Name
IDT_REC
DBMS
dependent IDT Record
The SystemName, Operation Code, IDT Name, and IDT Record are identical to those already described in the Flat-File Layout.
Transaction Sequence uses different semantics. In the
NSATT
it is not a number but an alphanumeric string. SEQ is implemented as a
VARCHAR
column and therefore its ordering is determined by the collation order of the DBMS.
It is critical that the sequence number of a newly added row is greater than the sequence number of all rows already in the table. Failing to do so may lead to incorrect synchronization results.
The
syncstop
script cannot be used to stop a Synchronizer that is processing the NSA TT. The only supported mechanism is the
Stop
button on the Console.

0 COMMENTS

We’d like to hear from you!