It certainly surprised me last week when playing around with the Delta engine. Delta processing wasn't necessarily a new experience for me but requiring delta processing within a single Assembly Line for multiple data sources did present a challenge.
It is straightforward to write an Assembly Line and have the connection details for a connector be programmatically assigned at runtime. Take, for example, the following code:
This code will re-initialize my LDAPConnector using new connection parameters that I retrieve from my work entry.
However, I cannot use the same mechanism when attempting to set the Delta details! The reason was explained to me by Eddie Hartman who writes the excellent TDIing Out Loud. The Delta engine is initialised when the Assembly Line starts, not when the connector is initialised. So any attempts to programmatically set a DeltaDB parameter and re-initialise the connector is doomed to failure. (At least, this is true up to and including TDI v7.1 Fix Pack 4 though Eddie hinted that this "gap" may be "plugged" in the near future.)
So... what to do? The simple answer is to write two Assembly Lines! One of the Assembly Lines will determine the Delta DB table to be assigned (and presumably the target data source for your delta enabled connector). The other will be your main Assembly Line with the delta enabled connector.
The first Assembly Line - which I like to call the driver - would contain code like this:
Now, when my delta enabled connector starts up, a properly assigned Delta Store appropriate for the data source is assigned.
One word of warning though. The work.DeltaStore attribute used in the assignment of the Java property should NOT contain any funny characters of any shape or form. For example, if you wanted to assigned a Delta Store name which matched your data source name (which sounds like a mighty fine plan), you may find you have to translate one to the other as such: