Set up a File System Connector with the Delta engine feature enabled. Have it iterate over a simple XML document that we can easily modify in a text editor. For example:
<?xml version="1.0" encoding="UTF-8"?>
<DocRoot>
<Entry>
<Telephone>
<ValueTag>111-1111</ValueTag>
<ValueTag>222-2222</ValueTag>
<ValueTag>333-3333</ValueTag>
</Telephone>
<Birthdate>1958-12-24</Birthdate>
<Title>Full-Time TDI Specialist</Title>
<uid>jdoe</uid>
<FullName>John Doe</FullName>
</Entry>
</DocRoot>
Be sure to use the special map-all attribute map character, the asterisk (*). This is the only Attribute we need in your map to ensure that all Attributes returned are mapped in to the Work Entry object.
Now add a Script Component with the following code:
// Get the names of all Attributes in work as a String array
var attName = work.getAttributeNames();
// Print the Entry-level delta op code
task.logmsg(" Entry (" +
work.getString( "FullName" ) + ") : " +
work.getOperation() );
// Loop through all the Attributes in work
for (i = 0; i < attName.length; i++) {
// Grab an Attribute and print the Attribute-level op code
att = work.getAttribute( attName[ i ] );
task.logmsg(" Att ( " + attName[i] + ") : " + att.getOperation() );
// Now loop through all the Attribute's values and print their op codes
for (j = 0; j < att.size(); j++) {
task.logmsg( " Val (" +
att.getValue( j ) + ") : " +
att.getValueOperation( j ) );
}
}
The first time we run this AL, your Script Component code will create this log output:
12:46:31 Entry (John Doe) : add 12:46:31 Att ( Telephone) : replace 12:46:31 Val (111-1111) : 12:46:31 Val (222-2222) : 12:46:31 Val (333-3333) : 12:46:31 Att ( Birthdate) : replace 12:46:31 Val (1958-12-24) : 12:46:31 Att ( Title) : replace 12:46:31 Val (Full-Time TDI Specialist) : 12:46:31 Att ( uid) : replace 12:46:31 Val (jdoe) : 12:46:31 Att ( FullName) : replace 12:46:31 Val (John Doe) :
Since this Entry was not found in the previously empty Delta Store, it is tagged at the Entry-level as new. Furthermore, each of its Attributes has a replace code, meaning that all values have changed (which makes sense because the Delta is telling us that this is new data).
Make the following changes to our XML file:
Your resulting Config should look like this:
<?xml version="1.0" encoding="UTF-8"?>
<DocRoot>
<Entry>
<Telephone>
<ValueTag>111-1111</ValueTag>
<ValueTag>222-2222</ValueTag>
<ValueTag>333-4444</ValueTag>
</Telephone>
<Title>Full-Time TDI Specialist</Title>
<uid>jdoe</uid>
<FullName>John Doe</FullName>
<Address>123 Willowby Lane</Address>
</Entry>
</DocRoot>
Run your AssemblyLine again. This time your log output should look like this:
13:53:22 Entry (John Doe) : modify 13:53:22 Att ( Telephone) : modify 13:53:22 Val (111-1111) : unchanged 13:53:22 Val (222-2222) : unchanged 13:53:22 Val (333-4444) : add 13:53:22 Val (333-3333) : delete 13:53:22 Att ( Birthdate) : delete 13:53:22 Val (1958-12-24) : delete 13:53:22 Att ( uid) : unchanged 13:53:22 Val (jdoe) : unchanged 13:53:22 Att ( Title) : unchanged 13:53:22 Val (Full-Time TDI Specialist) : unchanged 13:53:22 Att ( Address) : add 13:53:22 Val (123 Willowby Lane) : add 13:53:22 Att ( FullName) : unchanged 13:53:22 Val (John Doe) : unchanged
Now the Entry is tagged as modify and the Attributes reflect what the modifications for each of them. As we can see, the Birthdate Attribute is marked as delete and Address as add. That's the reason we used the special map-all character for our Input Map. If you had mapped only the Attributes that existed in the first version of this XML document, we would not have retrieved Address when it appeared in the input.
Pay special attention to the last two value entries under the Telephone Attribute, marked as modify. The change to one of the values of this Attribute resulted in two Delta items: a value delete and then add.
To build a data synchronization AssemblyLine in earlier versions of Tivoli Directory Integrator, you had to script in order to handle flow control. Although you may receive adds, modifies and deletes from your change component or feature, a Connector could only be set to one of the two required output modes: Update or Delete.
So either we need two Connectors pointing to the same target system and put script in the Before Execute Hook of each to ignore the Entry if its operation code did not match the mode of this component; or you could have a single Connector (either Update or Delete mode) in Passive state, and then control its execution from script code where you checked the operation code. This still meant that even though you knew what had changed in the case of a modified Entry, your Update Mode Connector would still read in the original data before writing the changes back to the data source. This can lead to unwanted network or data source traffic when you are only changing a single value in a multi-valued group-related Attribute containing thousands of values.
Go to the root_directory/examples/ directory of the IBM Tivoli Directory Integrator installation.
Parent topic: Deltas