Operations Guide

10.1 HotFix 1
- 10.5 HotFix 2
- 10.5 HotFix 1
- 10.5
- 10.2 HotFix 1
- 10.2
- 10.1
- 10.0 HotFix 1
- 10.0

Back Next

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.

Update Synchronizer

Download Guide

Watch

Comments

Communities

Knowledge Base

Success Portal