TDI, when data needs to be somewhere else

We'll get to bidirectional and more complex data flows later, but let's start with something as simple as:

How do you copy and transform data from a source to a target?

This is a deceptively simple statement, but it quickly leads to a number of interesting side conversations:

  • What sources and targets are supported?

  • What formats can be handled? This is usually not so much a problem with i.e. a database – although there are some good exceptions, but a file or a HTTP body can contain any format!

  • How to detect changes in a source since you last checked?

  • And.. talking about changes, how do you detect that something is not there that used to be there? This will often require a delete in the target

  • How flexible is the transformation capabilities? Can you access custom APIs as part of the transformation?

  • Can data from the source be augmented with data from other sources before it's driven to the target

Typical use cases

  • Data extraction from all sorts of systems (such as: databases, SAP, Service Desk, Lotus Domino, Web Services, files, and many more)

  • Data load into all sorts of systems

When these capabilities are combined you can solve most integration challenges. For example, customers have built solutions such as:

  • Hourly extraction of data from a point-of-sale infrastructure into a large data warehouse

  • Events in Netcool Omnibus create tickets in Tivoli Service Request Manager. When tickets are updated in TSRM, their status is changed accordingly in Omnibus

  • Automatically create new users in Lotus Domino based on new employees defined in SAP. Similarly, when employees change status in SAP, they are deactivated or modified in Domino.

  • Large single sign-on projects often require standalone identity repositories that both scale massively and can be locked down in a secure fashion. Tivoli Access Manager is often used with Tivoli Directory Server, but all management happens in the enterprise Microsoft Active Directory. TDI handles all propagation and transformation so that an entirely customized security service can be established independently of the Active Directory.

  • An existing mainframe application communicates through MQ. TDI listens to messages on the queue, then turns around and looks up data in the distributed infrastructure and replies back to MQ so that the mainframe application didn't have to be modified.

(Back to the main page)