Test 000-563: IBM Tivoli Directory Integrator V7.1

Tab navigation

Section 1-1: IBM Tivoli Directory Integrator Concepts

Given an understanding of IBM Tivoli Directory Integrator V7.1(TDI), describe the components that comprise TDI, as well as a TDI solution so that there is a clear understanding of the tools available for building integrations by using TDI.
With emphasis on performing the following tasks:
1. Describe the architecture of TDI. TDI is made up of:
  1. The TDI Server, used to execute AssemblyLines(ALs) and provide a library of components and integration features, as well as API access to these ALs.
  2. ALs, which are implementations of integration data flows, and which run on the TDI Server.
  3. One or more configuration files containing details of ALs to be run on a TDI Server.
2. Describe the components used to build ALs.
  1. Connectors abstract away the details of APIs, protocols and transports, harmonizing access to CRUD (Create, Read, Update & Delete) operations.
  2. Functions encapsulate a broad range of service calls like:- Starting other ALs- Invoking a Parser on data in the AL- Sending email- Calling Java functions- Invoking Web Services- Converting between Java and XML/SOAP representations.
  3. Parsers simplify reading and writing formatted bytestreams. (e.g. XML, CSV, Fixed format, etc.)
  4. Attribute Maps are used to transform data values.
  5. Scripts provide points in the AL execution where built-in functionality can be extended or overridden by custom logic.
  6. Flow Control components, including Branches, Loops and Switch-Case, are for articulating processing logic and controlling when (and which) components participate in AL execution.
3. Describe TDI Entry-Attribute data model.
  1. Data values are stored as Java objects.- It is the role of the Connector, or the driver or library it uses to reach the endpoint, to convert between native types and comparable Java objects.
  2. All the values for a single field or attribute are stored in a TDI collection object called an Attribute (class com.ibm.di.entry.Attribute).- Each Attribute has a name, for example "FirstName", "SOAPHeader" or "LastModified".- An Attribute can hold zero or more values, each of these being some type of Java object. This includes any TDI Java object as well, like Attribute or Entry.- It can also have a delta operation code that describes change information about this Attribute, as well as operation codes for the values it carries.- Attributes may be hierarchical in order to represent hierarchical data. (e.g. XML)
  3. Attributes for a single record or entry are stored in a TDI collection object called an Entry (class com.ibm.di.entry.Entry).- Entries are unnamed.- An Entry can hold zero or more Attributes, and no two Attributes may have the same name (case insensitive, so "firstname" is the same as "FirstName".- Entries also carry a delta operation code, describing the change information related to the data it contains.- If an Entry contains a hierarchical Attribute then it also provides DOM-like features for searching and returning Attributes.- And Entry can also hold property values which are access through the entry.getProperty() and entry.setProperty() methods.
Given knowledge of the TDI product and Java documentation, explain the common Java objects main, system, task, and work, so that they can be leveraged to build TDI solutions.
With emphasis on performing the following tasks:
1. Main: The main object is the top-level thread. It implements the interface com.ibm.di.server.RSInterface and has methods for manipulating TDI ALs.
2. System: The system object contains lots of handy methods for scripting within TDI. It is of class com.ibm.di.function.UserFunctions.
3. Task: The task object implements the interface com.ibm.di.server.TaskInterface. It represents the current thread of execution; an AL thread within a TDI solution.
4. Entry: The Entry Object is the data container in TDI and holds zero or more Attributes. It is a type com.ibm.di.entry.Entry.
  1. The Work Object is the data container object of the AL. It is accessible in every component of an AL.
  2. The Conn Object is the local storage object in Connectors. It only exists from the Attribute Mapping phase of the Connector's operation. See "Attribute Mapping" in the Ref Guide.
  3. The current object is available only in Connectors in Update and Delete mode. Stores the Entry that the Connector read from the data source to determine whether this is an Add or Modify operation.
5. Attribute: The attribute object is used in conjunction with the Entry Object to store information about an attribute and is of type com.ibm.di.entry.Attribute. The attribute has a name and a list of zero or more values. Each value can be any type of Java object so you can add values of any kind to the attribute.
Given a working knowledge of TDI, describe the various files that make up a TDI solution and describe the differences between TDI 6.x and TDI 7.1, so that a TDI solution can be supported on both versions 6 and 7 of TDI.
With emphasis on performing the following tasks:
1. Describe the default installation locations.
  1. Windows platforms: C:\Program Files\IBM\TDI\V7.1
  2. Linux and UNIX platforms (AIX, HP-UX, Solaris): /opt/IBM/TDI/V7.1
  3. i5/OS: /QIBM/ProdData/TDI/V7.1
2. Describe what the Workspace is in TDI 7.1.
  1. With the advent of the Eclipse-based Configuration Editor (CE), development of solutions in TDI is not, as in pre-V7.0 versions, based upon the development of plain configuration files, but upon a Project model, and Workspaces. Using the Project model and the Workspace, you can do your development work; once you are ready to deploy the solution, you extract a configuration file from the Workspace and send it to a suitable TDI Server: the runtime environment.
3. Describe what the Project Model is in TDI 7.1.
  1. When you start the CE, you will be prompted to select a workspace directory. The workspace directory is where the CE stores all your TDI projects and files. This is different from the Solution Directory, though the workspace directory may very well be contained inside the Solution Directory. From the workspace, the CE gathers files to form a runtime configuration file (rs.xml) that can be executed on a TDI Server. Files and projects in the workspace can be thought of as the source for various runtime configuration files.
4. Describe the differences in the Install Directory, Solution Directory and the Working Directory.
  1. The workspace directory belongs to the CE where the project files are stored. The install and solution directories belong to the TDI Server when it executes. The working directory should not be confused with the workspace. The workspace is the area where the project files are stored; the working directory is the position in the filesystem that defines all non-fully qualified filenames. This is by default the Solution Directory.
5. Describe the composite XML configuration file and the changes in this file from 6.x to 7.x.
  1. In 6.x, the composite XML file contained the entire solution in which ALs, Connectors and so forth are all part of the same document.
  2. In 7.x, The configuration file (Config) run by a server is a composite XML document in which ALs, Connectors and so forth are all part of the same document. In the TDI Eclipse CE each of these components are allocated their own physical file. These files only contain one configuration object. One of the reasons for splitting the configuration file into separate files during solution development was to make sharing of components easier. Also, having each component in its own file lends itself nicely to source control systems like CVS and also to multi-user development where different people work on different parts of the solution at the same time.
6. Describe how to import older XML files into the CE.
  1. Configurations prior to this version can be imported by using an import wizard. The imported configuration splits into individual configuration files as a result of this process. Another way is to use the File -> Open Directory Integrator Configuration File option, which will import the pre-7.0 configuration into a new project.
7. Describe the runtime configuration file and the difference in its use in TDI 7.x vs. TDI 6.x.
  1. Hidden from normal view is the runtime configuration file. This is the file that TDI servers use to run the solution and also the file that previous versions (pre-7.0) would work directly on. Whenever you save a configuration file in the CE, it will cause an update to the runtime configuration file as well. This file is also the one that is transferred to a TDI Server for execution. This file is maintained by the Project Builder and should not be modified by the end user.
8. Describe the use of the Project Builder.
  1. A custom project builder is associated with the project whose purpose is to assemble all artifacts into a runnable configuration file.
  2. This builder can be run automatically whenever a resource changes, or manually through the standard Project -> Build menu item. Either way, the TDI project builder maintains a configuration file that is updated when it is invoked. When a resource has been changed (modified, added or removed) the builder will update the runnable configuration file with that resource update. Only recognized configuration files will be acted upon; that is, ALs but not .gif files for example. The runnable configuration file is usually hidden since the file name starts with a dot (.). The file is named .tdi.xml, located under the project folder. This is the compiled configuration file that is sent to a TDI Server for execution.
  3. The builder will relocate and rename components in the target configuration. If the Resources folder contains both properties and Connectors, they will be relocated to their standard folders in the target configuration (that is, Properties and Connectors folder).
  4. The project builder also checks all modified components for obvious errors and potential problems. These problems are logged into the standard Eclipse Problems view. Each problem item contains a description of the problem as well as the location so you can double-click and activate the editor where the problem was identified.
9. Describe the use of server Property Stores, shared Property Stores, and how to edit key/value pairs.
  1. Every TDI project is associated with a TDI Server. The associated server is the server that will be used to execute the ALs in the project. Since the server may be located on a different machine, the project model must provide access to properties through local copies of chosen Property Stores.
  2. Property Stores can be downloaded from the server as needed where the local copy contains two values for each property. One value is what was downloaded from the server (remote value), and the other is the value set by the user (local value). This is done so as to be able to see which properties are in possible conflict, as well as being able to extract the set of properties in use by the solution. There is no requirement to download a Property Store before adding properties to it though; however, when you run the solution any properties with a local value will be checked against the value on the server to prevent unintentional overwrites of existing properties.
Given a working knowledge of TDI, describe the System Store and the System Queue, so that a TDI solution can utilize these features.
With emphasis on performing the following tasks:
1. Describe the System Store and its objects.
  1. TDI supports persistent storage (that is, storage of objects that survive across JVM restarts), by means of a tightly-coupled relational database, the System Store. The product deployed by default to implement the System Store is a relational database implemented fully in Java™, known as Apache Derby, and previously known as Cloudscape.
  2. The System Store supports the following objects:- Delta Tables- User Property Store- Password Store- Any tables defined by the user
2. Describe the Password Store.
  1. The Password Store is a Property Store for externalizing passwords used in the TDI solution. If a default Password Store is configured, a unique property name is generated the first time a protected/password parameter is saved. This key is used as the key in the Password Store. The same property name is written to the configuration file as a standard property reference. When the value is later retrieved, standard property resolution takes place to retrieve the actual value from the Password Store.
  2. If a Password Store is specified, a unique key is generated for the password and the password is saved encrypted in the Password Store under that key. In the configuration file, the password is referenced only by that key.
3. Describe the User Property Store.
  1. The User Property Store is a System Store table used for maintaining serialized Java™ objects associated with a key value. This is where persistent component parameters and properties (such as the Iterator State Store) are maintained, as well as any data you store. The System Store implements User property stores as one of its three types of persistent stores for TDI components.
4. Describe by using a third-party RDBMS as a System Store.
  1. The System Store can also be configured to use other multi-user RDBMS systems, as opposed to using the bundled database, Apache Derby. This is done by specifying appropriate SQL Data Definition Language (DDL) statements and driver parameters as system properties in global.properties or solution.properties.
5. Describe by using Derby to hold your System Store.
  1. Derby can run in either of two modes: embedded and networked. By default, as specified in the global.properties file, Derby runs in networked mode.
  2. The System Store used by TDI releases before V7.0 was Derby (then called Cloudscape) in embedded mode. There are drawbacks to the way Derby runs in embedded mode. In embedded mode, Derby runs as a separate thread within the same JVM as the TDI server is running. Startup and shutdown of Derby is automatic in embedded mode. However, when run this way, this Derby thread claims exclusive access to the database files. This can become problematic when different JVMs, each with its own Derby thread, try to access the same System Store.
  3. In networked mode, Derby start-up and shut-down must be done manually. Note that automatic start-up can be configured through a properties setting (solution or global properties).
Given an understanding of the customers data source(s), required data target(s), and needed data transformations, along with knowledge of the various TDI development methods, determine if the use of Easy Extract, Transform and Load data(EasyETL) is appropriate for the problem, so that the customer situation has been defined and the use of EasyETL has been accepted or rejected.
With emphasis on performing the following tasks:
1. Define EasyETL.
  1. The EasyETL perspective in the CE is a highly specialized way of looking at your TDI configurations, dedicated to get you up and running fast with projects that revolve around simple tasks to ETL into some form of database.
2. Determine whether EasyETL is applicable for the integration:
  1. Determine whether more than 2 Connectors are required to solve the integration, since EasyETL supports only a single source and single target Connector.
  2. Determine the types of Connector required for the integration, since not all Connectors work with EasyETL.
  3. Determine if data manipulations can be implemented by using EasyETL transformations.
Given an understanding of TDI, describe and then apply the components and features for Delta Handling in TDI so that there is a clear understanding of how data synchronization is accomplished.
With emphasis on performing the following tasks:
1. Describe the tasks involved in Delta Handling.
  1. Delta Detection, in other words discovering changes in source data. Part of this operation is capturing information about the change so that it can be used in the next step: Delta Application. Change information is captured as �delta operation codes' apply to the Entry Object (for example, work and Conn), the Attributes it contains, as well as Attribute values.
  2. Delta Application, which involves updating targets so that source and target are synchronized. This is typically done by using the delta operation codes captured during Delta Detection.
2. Describe the components and features used for Delta Detection.
  1. Change Detection Connectors, for example for AD, Domino, RDBMS's and for LDAP Changelog (e.g. IBM Tivoli Directory Server).
  2. Delta Engine, which is used in conjunction with a Connector in Iterator mode. It works by storing snapshots of data read and comparing these with snapshots taken during the previous run of the AL. Snapshots are stored in the System Store, and provide a way of discovering changes in practically any data source, include flat files.
  3. LDAP Parser, which can read incremental LDIF files. Incremental LDIF files contain information about the type of change for each entry listed in the file, as well as which fields/values that have been added, deleted or modified.
  4. (optional) Change information can also be carried in data read from a message queue, or received in an HTTP POST. In these cases, delta operation tagging is not automatically handled, and the user is responsible for either correctly tagging the Entry, Attributes and values based on values received, or by using the embedded change-info to apply delta.
3. List the possible delta operation codes.
  1. For an Entry possible tags are 'generic' (not tagged), 'unchanged', 'add', 'delete' or 'modify'.
  2. For an Attribute possible tags are 'replace' (not tagged), 'unchanged', 'add', 'delete' or 'modify'.
  3. For an Attribute value possible tags are 'add' or 'delete'.
4. Outline how you use Delta Handling components and features to create an AL that performs one-way synchronization.
  1. A typical synchronization AL starts with a Change Detection Connector in the Feed section configured to return only changed entries.
  2. The Flow section implements Delta Application by using a Branch that checks if work.getOperation() returns the value �delete'. Under this IF-Branch would be a target Connector in Delete mode. An ELSE-Branch would ensure that other entries (e.g. tagged as �add' or �modify') are passed to a different target Connector, this one set to Update mode.
  3. Alternatively, the Flow section could have a single target Connector set to Delta mode. This mode uses delta operation codes to apply changes as efficiently as possible. Note that Delta mode operation assumes that delta operation codes correctly express the difference between the entry read from the source and the current state of the target. Note also that Delta mode is only available for the LDAP and JDBC/Database Connectors.

Section 1-2: IBM Tivoli Directory Integrator Concepts

Given a working knowledge of TDI 7.1 , explain all of the different Connector modes and how they effect the flow of data through an TDI AL, so that the Connector modes and data flow has been explained.
With emphasis on performing the following tasks:
1. Explain Add-Only mode.
  1. Connectors in Add-Only mode, commonly referred to as Add-Only Connectors, are used for adding new data entries to a data source.
2. Explain Delete mode.
  1. Connectors in Delete mode, often referred to as Delete Connectors are used for deleting data from a data source.
  2. Delete mode provides (surprisingly) an Input Map so that values can be read from the entry to be deleted and used as Link Criteria to related items also to be deleted.
3. Explain Iterator mode.
  1. Connectors in Iterator mode are used to scan a data source and extract its data. The Connector in Iterator mode actually iterates through the data source entries, reads their attribute values, and delivers each entry to the AL Flow section components, one at a time.
  2. Iterator mode uses Connection parameters to build its search criteria, typically doing this only when the Connector first initializes. The resulting data set is retrieved one entry at a time each time the Iterator's Get Next operation is performed. If attached to a Connector Loop, Iterator mode will drive the Loop once for each entry in the result set, up to the maximum number defined in the Connector's Read Limit setting.
4. Explain Look-up mode.
  1. Look-up mode enables you to join data from different data sources by using the relationship between attributes in these systems.
  2. Look-up mode (as well as Update mode) uses Link Criteria to build its search criteria, doing this each time the Connector is executed during AL operation. Look-up mode furthermore collects a number of the resulting entries (determined by the Connector's Look-up Limit setting), providing access to this collection via scripted calls. If attached to a Connector Loop, Look-up mode will drive the Loop once for each entry found, up to maximum number defined in the Look-up Limit.
5. Explain Update mode.
  1. Connectors in Update mode, usually referred to as Update Connectors, are used for adding and modifying data in a data source. For each entry passed from the AL, the Update Connector tries to locate a matching entry from the data source to modify with the values of the entry attributes received. If no match is found, the Update mode Connector will add a new entry.
  2. This mode provides a Compute Changes feature. If enabled, existing data values discovered by a successful look-up operation are compared with those mapped out (Output Map). If no differences are detected then the write operation is skipped.
6. Explain Delta mode.
  1. The Delta mode is designed to simplify the application of changes to data by providing incremental modifications to the connected system, based on delta operation codes.
7. Explain Call/Reply mode.
  1. Call/Reply mode is used to make requests to data source services, such as Web services, that require you to send input parameters and receive a reply with return values. Unlike most other modes, the Call/Reply mode gives access to both Input and Output Attribute Maps.
8. Explain Server mode.
  1. The Server mode, available in a select number of Connectors, is designed to provide the functionality of waiting for an incoming event, dispatch a thread dealing with the event, and send a reply back to the originator.
9. Explain Data Source.
  1. Data enters the AL from connected systems by using Connectors in some sort of input mode, such as Iterator or Look-up.
10. Explain Data Target.
  1. Data leaves the AL to connected systems by using Connectors in some sort of output mode, such as, Add-Only or Update.
11. Describe how an AL flow can be controlled.
  1. The flow of an AL can be controlled in many ways. A few methods are:- Connectors- Function Components(FCs)- Branch and Loop components- Scripts- Hooks
Given knowledge of the TDI product, Hooks Scripts, and null behaviour, define all places where JavaScript can be used and data can be manipulated, so that how JavaScript can be used in TDI has been defined.
With emphasis on performing the following tasks:
1. Script library:
  1. The script library contains a collection of Scripts that can be used by any component within TDI. These Scripts can be used to manipulate data at any point of the process flow. Scripts can also be tied to Hooks and Attribute mapping rules, and can also be executed as 'Global Prologs' of an AL - i.e. Script that is executed before the AL's own Prolog Hooks.
2. Script components:
  1. The script components can be placed in a TDI feed or data flow and can be used to manipulate attributes (data) at any point.
3. Scripted components:
  1. For example, Scripted Connectors, Functions and Parsers. These types of components can be implemented by using JavaScript and used/shared like standard components.
4. Scripting in the Connection Form of a component:
  1. The Connection form can contain Scripts to control button behavior and field population, as well as changes to parameter state.
5. Hooks:
  1. The hooks of a TDI AL or AL Connector can be scripted and used to manipulate data when the hook is invoked. Different data sets are available to the scripting environment in the hook based on the invocation context and/or Connector state.
6. Attribute mapping and null behavior:
  1. The attribute mapping in the component, Input Map, and Output Map can be scripted and used to manipulate attribute data. In addition, these components allow for the definition of null behaviour which is used for the automated transformation of data within TDI.
7. Control flow components:
  1. The control flow components allow for the scripting of various types of conditions which will control the data flow of the AL. The Scripts in these components have access to all the data present in the AL, manipulation of the data for use outside of this component is discouraged.
8. Link Criteria:
  1. The Link Criteria for various TDI Connectors can be scripted. The Scripts in these components have access to all the data present in the AL, manipulation of the data for use outside of this component is discouraged.
Given software systems that store user passwords, explain the concepts and capabilities of TDI password synchronization, so that a clear understanding of the TDI password synchronization capabilities have been defined.
With emphasis on performing the following tasks:
1. Provides an infrastructure and a number of ready-to-use components for implementing solutions that synchronize user passwords.
2. Provides a method to intercept user password changes and propagate to same software systems or a different software system.
3. Provides components to build a custom solution for password interception and propagation.
4. Provides password synchronizers and Password Stores of user passwords.
5. Password Synchronizers:
  1. Windows platform - to intercept the Windows login password changes.
  2. Sun Directory Server platform - to intercept the Sun Directory password changes.
  3. IBM Directory Server platform - to intercept the IBM Directory Server password changes.
  4. IBM Domino Server platform - to intercept IBM Domino Server HTTP password changes for Lotus Notes users.
  5. UNIX and Linux platforms - to intercept UNIX and Linux password changes.
6. Password Stores:
  1. LDAP Password Store - to store the intercepted user password in LDAP Directory Servers.
  2. JMS Password Store - to store the intercepted user passwords in JMS Provider's Queue.
  3. Log Password Store - to log any actions that a normal Password Store would take.
7. Specialized Connectors:
  1. JMS Password Store Connector - the function to retrieve password update messages from a JMS Password Store and forward to a TDI solution.
Given knowledge of TDI, describe how AL operations can be monitored, for example Administration and Monitoring Console(AMC), Action Manager(AM), etc, so that the method used to start, stop, and manage TDI ALs remotely have been explained.
With emphasis on performing the following tasks:
1. AMC
  1. The TDI 7.1 AMC user interface is deployed into the Integrated Solutions Console (ISC).
2. AM
  1. The AM(Action Manager) is a stand-alone Java application that interacts with the AMC database and uses the Remote Server API to manage remote ALs. It is typically used to implement failure-response behaviors in a TDI solution.
3. Using JMX notifications
  1. This is the JMX(Java Management Extension) standard that most monitors support.
4. Using the command line utility: tdisrvctl
  1. tdisrvctl is a standalone Java application for querying TDI operations, as well as starting and stopping ALs and modifying property values.
5. Using logging and/or alerts to communicate health and progress to the monitoring process e.g SNMP, HTTP, log/audit files, etc.
Given an understanding of TDI ALs, describe the AL lifecycle and the various operation modes when starting an AL so that there is a clear understanding of how an AL operates.
With emphasis on performing the following tasks:
1. Describe AL lifecycle phases. An AL has three phases:
  1. Initialization, when the AL is instantiated and (by default) all components initialized.
  2. Cycling, when components are executed in order and data is read, transformed and written by the AL.
  3. Shutdown, when cycling is complete or an unhandled exception occurs. This is when components (and connections) are closed and terminated.
2. Describe AL operation modes. An AL can be started in one of two execution modes:
  1. Standard run mode, which causes a new thread to be spawned. The AL FC shows this as two options: �Run in background' and �Run and wait for completion', the difference being that the latter option performs a join() on the spawned thread so that processing pauses until the child thread terminates.
  2. Manual mode, also called Cycle mode. In this case the thread of the calling AL is shared with that of the called AL. Furthermore, the Feed section of the called AL is skipped and the Flow section components are executed as though they were part of the calling AL. In other words, like a sub-AL.
Given an understanding of TDI ALs, describe the Initial Work Entry (IWE) and the Task Call Block(TCB), so that how IWE and TCB are used in TDI has been explained.
With emphasis on performing the following tasks:
1. Define the IWE and how it is used.
  1. The IWE is an Entry which is passed into an AL when it is started. The presence of an IWE will cause the Feed section Iterator to skip reading on the first AL cycle. The IWE is used to pass data into an AL so that it can be operated on, or used to control the behavior this AL.
2. Define the TCB and how it is used.
  1. The TCB is a special kind of object used to do any or all of the following when launching a new AL:- Passing in an IWE- Specifying Connector parameter values to use- Defining an Accumulator
Given a thorough understanding of TDI, describe the use of Connectors in ALs, so that Connectors are used appropriately in an AL.
With emphasis on performing the following tasks:
1. Define Connector.
  1. Connectors are used to access and update information sources. The job of a Connector is to level the playing field so that you do not have to deal with the technical details of working with various data stores, systems, services or transports.
2. Define the features of Connectors:
  1. Management of the connection to some target System Store or object
  2. Modes setting to control how the Connector performs in an AL
  3. Attribute Maps for transforming data as it flows into or out from the AL
  4. Automatic reconnection
  5. Delta Engine for detecting changes during iteration
  6. Hooks to provide scripting way points in the built-in workflow of each Connector mode
  7. Inheritance of any or all of the above aspects from another component
  8. Configurable Connection form
  9. Support for Connector pooling
  10. Support for connection reuse within the same AL
Given the need to build a solution aligned with loosely coupled, service oriented architecture and Interoperability standards, describe Server Mode and how it is used, so that there is a clear understanding of its features and applications.
With emphasis on performing the following tasks:
1. Describe Server Mode:
  1. Server Mode Connectors bind to some resource (like an IP port), accept client connections, process incoming data and return a response to the client.
  2. Server Mode is only available for Server Connectors - i.e. those that have �Server' in their name.
  3. An AL by using a Server Mode Connector gains a pooling feature to enhance performance and service availability. At startup, a specified number of Flow sections are instantiated and their Connectors/connections are initialized. These 'AL segments' are managed in a pool that can dynamically grow to accommodate growth in client traffic.
  4. Server Mode is also incorporates both Iterator and Reply modes as well, switching between these as follows:- The SMC (Server Mode Connector) uses Server mode first to bind to a resource (e.g. an ip port) and accept client connections.- Upon client connection, the SMC spawns a new thread/process to service that Client, switching this copy of itself to Iterator mode in order to receive data from the client. This Iterator mode version of the SMC is then paired with an available Flow section from the pool. This newly constructed AL processes iterated data.- When this AL terminates (e.g. End-of-data or an unhandled exception), Reply mode is used to send a response back to the client. Instead of closing/terminating Connectors, the Flow section is returned to the pool.
2. Describe how Server Mode is used:
  1. A Server Mode Connector can only be used in the AL Feed section, in contrast to Iterator mode which can also appear in the Flow section.
  2. Server Mode is used to implement request-response services like HTTP (HTML, REST, ATOM/RSS, OSLC, etc.), as well as for intercepting and handling other types of protocol traffic (e.g. the LDAP Server Connector).
  3. The Input Map is used for receiving client data, while the Output Map is for formulating the response to the client.
  4. Typical uses for Server Mode are:- Implementing a simple web server- Service enabling a data store or system- Bridging protocols- Extending authentication services

Section 2: Planning and Architecture

Given an understanding of IBM Tivoli Directory Integrator V7.1 (TDI), outline what information you should know about the client's IT environment so that you can design a compatible TDI solution.
With emphasis on performing the following tasks:
1. What information is pertinent for installing and configuring TDI.
  1. Review the availability of ports and resources that TDI needs to operate properly.- Server API port (1099 by default)- Note that each TDI Server on the same machine needs its own port.- Derby port (default System Store)- Does the client have a preference for RDBMS to be used for SysStore?- MQe port (default System Queue)- Does the client have a preference for the MQ system used for SysQ?- If Administration and Monitoring Console(AMC) and Action Manager(AM) are deployed, then these ports as well.
  2. Identify the systems TDI will be integrating.- Are there available Connectors, or are custom components required?- Confirm data availability.- Clients often do not have a clear picture of their data.
  3. Review security requirements.- Security zones of all endpoints, and of the TDI Server(s)- Where must the TDI Server reside to reach all endpoints?- Sometimes multiple TDI servers must be used to cross security boundaries.- What credentials, keys and certificates are needed by TDI to carry out its work?- Are there special requirements, e.g. FIPS or particular security library.- Identify data privacy issues/requirements. What needs to be encrypted, and when?
  4. Resolve data ownership and governance.- Confirm that data owners provide the sufficient access to their information.- If data is shared then identify the authoritative source for each item.- Remind the client that with data ownership comes the responsibility of data availability and security. This often helps settle disputes between stakeholders vying for the same information.
  5. Auditing requirements- What reports and logs are required of the solution?- What are the auditing requirements?- Interfacing to Auditing systems, if any (e.g. TSIEM)
  6. Solution metrics- Performance and throughput- What is the expected number of transactions per second/hour/day?- What is the required minimum latency for each type of data flow?- Availability- Service enablement? If so, will Server Mode features be sufficient?- Is Restart-on-fail sufficient? Is there a scheduling service in place that can be used?- Is there a transport available for implementing loosely coupled AssemblyLines(ALs), thereby improving availability?
  7. Other- Are there any other client requirements that put constraints or otherwise strongly influence solution design?- Does the client require specific protocols, transports or formats to be used?- Language/localization support required?- When will endpoints and/or client libraries/services be available?- This will influence which part of the task is tackled first.- Service and outage schedules that will affect the project- Milestones and deadlines
Given TDI product knowledge and an understanding of the need to manage changes to deployed solutions, explain how change management can be implemented, so that how to manage various versions of a solution in TDI has been provided.
With emphasis on performing the following tasks:
1. Solution Export:
  1. The export feature of the TDI development console packages all files of a solution into a single XML file or archive file. Use this feature to create packages that can be stored and managed in external repositories (CVS).
2. Eclipse plug-in:
  1. The TDI development console is developed as a Eclipse plugin. Additional eclipse plugins can be used to provide the change management and version control as a component of eclipse.
Given a running production environment and completed solution, export the solution, modify appropriate configuration files, stage the files and monitor the start of the solution, so that the solution has been moved into the production environment.
With emphasis on performing the following tasks:
1. Export Solution:
  1. From within the Configuration Editor(CE), select the solution to be exported. Export the solution as a TDI runtime configuration.
  2. The config XML is also exported automatically each time you save or run your solution. The copy is located in the subfolder of your Workspace project directory.
2. Modify the properties files:
  1. Change all project related properties files to the values needed in the target environment. Note that property files can also be edited directly on the deployment server by using a text editor.
3. Transfer files:
  1. Transfer the solution XML file and any related properties files to the target system. Place the files on the target server as determined by filepathes used in the solution. Remember that the Solution Directory is the base folder for resolving relative paths.
  2. Note also that each Property Store may have a path setting that prerequisites a specific location for the file. By default, new Property Stores use the Text with Sub-sitution token �config.$directory' which evaluates to the same folder path as where the TDI Server loaded the Config XML from.
4. Modify deployment configuration:
  1. Update the start Scripts or daemon configurations files to load the new solution file and start appropriate ALs. Update any AMC configurations if needed.
5. Check logs:
  1. Check log files and validate that the solution started without errors.
Given an understanding of TDI, define the different uses and ramifications of sharing a central data store between multiple ALs so that there is a clear understanding of both the advantages and special considerations this technique entails.
With emphasis on performing the following tasks:
1. Describe the uses for a shared data store.
  1. Scaling up performance by having multiple ALs reading or updating the same data source.
  2. Passing data between different ALs via a shared store.
  3. Orchestrating the execution of related ALs by reading/writing state data in a shared store. Note that message queues provide persistence as well as controlled and customizable distribution of data to subscribers, making it ideal for building loosely coupled, robust integrations.
2. Describe the ramifications of using a shared data store.
  1. If multiple ALs are using the same store then steps must be take to avoid conflict - for example, through record locking features in the data store.
  2. If multiple ALs are detecting changes in the same data store, then they must coordinate their processing to avoid duplicate transactions. For example, by using a shared Delta Engine database, or employing filtering logic so that each AL works on a subset of the total input data.
  3. Share data stores must be configured to support access from multiple clients - for example, Derby must be started in networked mode.
  4. Some data stores are shared via federation or replication services of multiple instances. In these cases it is important that ALs working in concert across different instances are designed to deal with discrepancies that can arise between their data content. For example, caused by latency or disruption in replication/federation services. Also note that transactional data, like LDAP change log numbers and Last Modified timestamps, are likely to differ between instances.
Given an understanding of TDI, briefly describe how to plan for availability and performance, as well as exception/error reporting and auditing so that there is a clear understanding of how to build robust, scalable solutions with TDI.
With emphasis on performing the following tasks:
1. Describe the characteristics of a robust, scalable TDI solution.
  1. Error Handling - Using the Error Hooks in components and defensive code (for example, try-catch blocks) in Scripts to keep ALs from terminating due to executions. Note that sometimes you will want an AL to stop, so error handling logic must distinguish between situations that can be recovered from or ignored, and those that require operator intervention and should therefore stop the AL.
  2. Reconnection - Transient problems can cause a Connector to lose its connection. TDI provides Auto-Reconnect features in the Connection Errors tab that allow for periodic re-connection attempts in the case that these types of errors occur. Keeping connections alive and well is an important step in keeping ALs �in flight'.
  3. Logging/Auditing/Alerting - Adequate logging and alerting not only captures errors and unexpected situations, but can also provide information to monitoring processes about the health and performance of a solution. Note that alerting can include sending �heartbeat' messages to your monitoring process, as well as notifications of exceptional situations: e.g. SNMP, HTTP, queue messages, etc.
  4. Monitoring - The first step in recovering from an error situation is detecting it. As noted above, some success/health checks could be implemented directly in ALs themselves. However, to mitigate the risk of a single point of failure, it is advisable to provide external monitoring of your solution.
  5. Restart - If an AL terminates unexpectedly you need some process that ensures it is restarted again. Providing this functionality may even be preferable to using ALs that never terminate (for example, by disabling timeout for Iterators like Change Detection Connectors). Restart can be achieved in a number of ways:- Using the Timer Connector in another AL to periodically launch your integration AL;- Most operating environments provide scheduling features that can be leveraged to (re)launch your ALs. These are processes that also support monitoring;- AMC and AM provide features for checking solution health and restarting ALs as required;- A secondary TDI solution and/or Server can be configured to control the health of your solution and restart it upon failure.
  6. Redundancy - Continuously restarting the same AL may not be enough to ensure availability of your solution. Systemic errors like broken network links and HW/SW failures on the server running TDI may prevent your ALs from functioning properly. Redundancy means that if an AL fails (or fails to restart successfully), another can take over its responsibility. There are a number of ways to achieve this, although the most straightforward approach is loosely coupling ALs by using a transport (MQ) or shared data store. For example, one AL picks up changes from a directory and posts them to the queue. Then multiple ALs can subscribe to the queue, applying these changes to targets. If a subscriber AL stops for any reason, the integration service continues to work, albeit with reduced bandwidth. AMC and AM can also be used to coordinate fail over between ALs and TDI servers. This can also be done by using an external monitoring service and utilizing API calls or the tdisrvctl command line utility.- Note also that Server mode Connectors facilitate redundancy through their pooling of AL Flow sections. If the AL that is processing input from a particular client fails, it is returned to the pool. The request may have to be re-issued by the client, but the service itself remains available.
  7. Transactioning, where applicable/available - For example, relational database systems provide transactioning features that are leveraged by the JDBC and Database Connectors. The simplest approach is to configure these components to commit changes at End-of-cycle. - Note that the System Store utilizes an RDBMS and therefore offers the same commit/rollback features, which are also inherited by components and features that use the System Store: Change Detection Connectors, System Store Connector and System Properties.

Section 3: Installation and Configuration

Given a server with supported operating system and IBM Tivoli Directory Integrator V7.1 (TDI) installable images, use the TDI Launchpad to access the install GUI to install TDI, so that installation is completed successfully.
With emphasis on performing the following tasks:
1. Determine the TDI Edition to be installed.
  1. TDI: General Purpose Edition - is solely for integrating non-identity data.
  2. TDI: Identity Edition - Identity Edition is specifically for integration of identity information, but also entitles usage for other scenarios. This edition (IE) also includes the password synchronization components and features.
2. Validate the system requirements for the given server.
  1. Identify the system hardware and operating system.
  2. Review the TDI Installation and Administrator Guide document provided in TDI info center.
  3. Validate the system requirements.
3. Review the base TDI architecture from the Quick start guide.
4. Access the installer from TDI Launchpad.
  1. Insert the product installation DVD for your operating system: there is one DVD for all supported operating systems except i5/OS, and a separate one for i5/OS. On Windows operating systems, the Launchpad launches automatically.
  2. For all other platforms, run the TDI Launchpad executable; for example, Launchpad.- From the Launchpad menu, select Install IBM Tivoli Directory Integrator.- On the installation panel, click IBM Tivoli Directory Integrator Installer and follow the installation instructions.
5. Install TDI and its components.
  1. Install IBM Tivoli Directory Integrator by using a Typical or Custom installation:- A Typical installation installs the Server, Config Editor, JavaDocs, the Administration and Monitoring Console(AMC) (installed into the Integrated Solutions Console Standard Edition (ISC SE)), Action Manager(AM) and examples.
  2. Custom installation allows you to choose individual components to install. Note: Password Interceptor Plug-ins are installed by using the Custom Install option, of the standard installer.
6. Verify the installation.
  1. Verify the results panel of the installer.
  2. Verify the installation logs.
Given a running environment and a fixpack file, stop the server, extract the files and apply the fixpack to patch the environment to the desired TDI version, so that the TDI Server has been migrated to the desired fixpack level.
With emphasis on performing the following tasks:
1. Download and stage files:
  1. Download the desired fixpack from the IBM support website.
  2. Place the file on the TDI Server and extract to a temporary location.
2. Follow the instructions in the readme file.
3. Verify installation:
  1. After the fixpack is installed, verify the TDI fixpack version installed on your system.
  2. UNIX/Linux: TDI_install_dir/bin/applyUpdates.sh -queryreg
  3. Windows: TDI_install_dir/bin/applyUpdates.bat -queryreg
4. Fixpack rollback:
  1. Use the following commands to rollback any update installs.
  2. UNIX/Linux: TDI_install_dir/bin/applyUpdates.sh -rollback
  3. Windows: TDI_install_dir/bin/applyUpdates.bat -rollback
Given a working knowledge of TDI, encryption protocols, customer requirements, and solution details, use security features supported by TDI to create a secure solution, so that the customers solution is secured.
With emphasis on performing the following tasks:
1. If necessary configure Directory Integrator to run in FIPS mode:
  1. The Federal Information Processing Standard (FIPS) Publication 140-2, FIPS PUB 140-2, is a U.S government computer security standard used to accredit cryptographic modules.
  2. You can run TDI and the TDI Server in a secure way by using FIPS. You can also configure additional properties when you want to operate TDI in a specific mode.
2. Configure SSL and/or PKI certificates.
  1. TDI uses both Secure Socket Layer (SSL) and Public Key Infrastructure (PKI) encryption methods. SSL and PKI provides an important foundation for many of the TDI and TDI server features. SSL provides for encryption and authentication of network traffic between two remote communicating parties. Similarly, PKI (public key infrastructure) enables users of unsecured networks to securely and privately exchange data by using a public and a private cryptographic key pair that is obtained and shared through a trusted authority.
3. Encrypt Property Files, etc.
  1. Encrypting and decrypting by using CryptoUtils
4. Encrypt individual property values.
  1. Note that individual property values can be encrypted by either toggling their 'protected' property in the Configuration Editor(CE), or by preceding the property value in the file with {protect}-.
5. Maintain keys, certificates, keystores. truststores, and encrypted files.
  1. Public/private keys and certificates
  2. Secret keys
  3. Keystores
  4. Keys for SSL
  5. Keys for encryption
6. Establish SSL communications for required components (Connectors, function components, etc.)
  1. Server SSL- When a TDI component is used as a server (for example a Server mode Connector) SSL mandates that a truststore to be used by TDI must be defined.
  2. Client SSL- When a TDI component is used as a client (for example the LDAP Connector) SSL mandates that a keystore to be used by TDI must be defined.
7. Establish SSL communications for remote API (Remote CE, AMC, tdisrvctl).
  1. The Server API provides two sets of interfaces - local and remote. It is only the remote interfaces that can use SSL. The local interfaces do not use SSL as the access is within the boundaries of the Java Virtual Machine. TDI can act as a server, as a client; as well as both as a client and as a server in a Server API access scenario. When SSL is used with the Server API, then a keystore and a truststore must be configured.
Given an understanding of TDI, define the use of the ibmdisrv and tdisrvctl command line utilities , so that how to manage TDI by using the command line have been explained.
With emphasis on performing the following tasks:
1. ibmdisrv - the TDI Server
  1. - c to specify configuration file(s) to load
  2. - r to specify AssemblyLine(AL)(s) to run
  3. -s to specify the Solution Directory
  4. -d for daemon mode
  5. -D to disable auto-started ALs
  6. -e run the server in secure mode
  7. -f to specify property files
  8. Running this command with no arguments displays full usage
2. tdisrvctl - the TDI command line utility
  1. -h host name of the TDI server to connect to
  2. -p port of the TDI server to connect to
  3. -K the key file of the TDI server
  4. -P password to the key file
  5. -op to specify the operation to run (start, stop, status)
  6. Running this command with no arguments displays full usage
3. ibmditk - the TDI CE
  1. -s to specify the Solution Directory
  2. -data for selecting the workspace
  3. -nl for selecting a national language
  4. Eclipse options can be entered here as well.
4. Command line arguments for Java JVM must be entered by updating the Script/batch file (ibmdisrv, ibmditk, tdisrvctl).
Given a running production environment and completed solution, create an instance directory and copy/modify all files as needed, using the system commands, so that the TDI Server is registered as a windows server or UNIX daemon and starts/stops with the system.
With emphasis on performing the following tasks:
1. Solution Directory:
  1. Create a directory and copy all required solution files to that directory. One Solution Directory per server instance is required.
2. Solution configuration:
  1. Modify the properties files for each server's Solution Directory with the required name, server names, ports, etc. These values must be unique for each server.
3. Server registration:
  1. Register the solution server as a Windows service by using the command line tool or modify the UNIX /etc/inittab or /etc/rc.d files.
  2. On AIX, also register TDI as a system service.
4. Stop and start:
  1. Using the windows service panel or the Unix rc.XX commands to manage the TDI server instances.
5. Check logs:
  1. Check log files and validate that the solution started without errors.

Section 4: AssemblyLine Development

Given a working knowledge of IBM Tivoli Directory Integrator V7.1 (TDI), a customer requirements document, use TDI constructs to create a solution (loops, branches, Parsers, function, etc), so that a solution is created.
With emphasis on performing the following tasks:
1. Use Loops in a solution.
  1. The Loop component provides functionality for adding cyclic logic within an AssemblyLine(AL). Loops can be configured for three modes of operation: based on Conditions, based on a Connector or based on the values of an Attribute.
2. Use Branches in a solution.
  1. The Branch allows you to define Conditions based on any data in the TDI Server: Attribute values, parameters settings, externally accessible properties, and any information available by using JavaScript, such as operating system calls for disk or memory usage. Multiple Conditions are ANDed or ORed, depending on the Match Any check box setting. This simplest form of Branch component also supports three subtype settings, IF, ELSE-IF and ELSE, that you can select.
3. Use Switches in a solution.
  1. Unlike expressions used in the Conditions of Branches and Loops, the Switch expression can result in more values than just true or false. For example, you could Switch on the value of an Attribute, or the operation requested when this AL was called from another AL or process. Under the Switch component, you add a Case for each constant value of the Switch expression that you want to handle. So for example, if you set up the Switch to use the delta operation code in the Work Entry, your Cases would be for values like "add", "delete" and "modify." In an AL Switch-Case construct, multiple cases can be active at the same time. TDI checks each case, just as it would a series of standard IF Branches.
4. Use Scripts in a solution.
  1. The Script Component (SC) is a user-defined block of JavaScript code that you can drop any place in the AL data Flow list, alongside your Connectors and Function Components, causing the script code within to be executed for each cycle at this point in the AL workflow.
5. Use Parsers in a solution.
  1. Parsers are used in conjunction with a byte stream component, for example, a FileSystem Connector, to interpret or generate the structure of content being read or written.
  2. Note that Parser can be used to parse byte streams being read or written by a Connector, or to interpret/encode bytestreams already in the AL by using the Parser Function Component(FC).
6. Use Attribute Maps in a solution.
  1. Attribute Maps are pathways for data to flow into or out of the AL. Attribute Maps appear in Connectors and Functions as Input and Output Maps, and are also available as stand-alone components in the AL.
  2. Attribute Map components can be used to transform data already in the assembly.
Given an understanding of TDI, describe the advantages of inheritance in TDI, as well as how to use it, so that there is a clear understanding of how to build TDI solutions that facilitate maintenance, enhancement and reuse.
With emphasis on performing the following tasks:
1. Describe where inheritance features can be used in TDI.
  1. Components (including Script components) in an AL can inherit settings and behaviors from those defined in the Resources library of the Project. Inheritance can be for all aspects (e.g. setting a �parent' for a component), or for individual ones. In addition to component parenting, inheritance can be applied to the following:- Attribute Maps and individual Attribute mapping rules- Schema and individual Schema items- Connection and initialization parameters- Hooks- Auto-Reconnect configuration (i.e. the Connection Errors tab)- Delta settings- Parser selection- Link Criteria- NOTE: For Attribute Maps and Schema, as well as Link Criteria, inherited items may be overridden or disabled, but not removed.
  2. Components can be inherited by other Resource library components.
  3. Scripts in the Resources library can be inherited by individual Hooks.
  4. Scripts in the Resources library can be inherited by individual Attribute map rules.
2. Describe how you tell if a component or aspect is inherited.
  1. For components (including Script components) in an AL, you can examine the Inherit From button to see if there is a parent defined.
  2. For Connectors and Functions you can examine the More� -> Select Inheritance settings.
  3. Mouse-over tips provide inheritance information.
  4. Inherited components, Connection parameters and Attribute mapping rules are displayed in blue.
3. Describe how you override and restore inheritance.
  1. For components, you change inheritance settings by using the Inherit From button.
  2. For Connector and Functions you can also use the More� -> Select Inheritance button to change and restore inheritance of component aspects.
  3. Connection parameters can be overridden by either editing that input field or by changing the Parameter evaluation settings. To restore inheritance to the parent you open the Parameter dialog (e.g. by clicking on the label of the parameter, or the question mark button in the right margin next to input field), select �Reset field to default' and press OK.
  4. You override an Attribute mapping rule by editing it in the Configuration Editor(CE), dragging a resource Script onto it or adding a new rule mapping to the same target Attribute. You can restore inheritance by deleting the rule, whereby removing the overriding instance, or by right-clicking and selecting �Revert to inherited value'.
  5. You override a Hook by editing it or dragging a Resources library Script onto it. To restore inheritance you right-clicking on the Hook in the tree view and selecting �Revert to inherited value'.
Given a working knowledge of TDI, a customer requirements document, configure null behavior, so that situations are handled properly when data values are null.
With emphasis on performing the following tasks:
1. Describe why null behavior is important.
  1. Occasionally, attributes or attribute values are missing from source data. Null Behavior functionality allows the user to define how missing data is handled. For example, if an optional telephone number is not present in the input data source, or an attribute in an Output Map is removed from the Work Entry. Other times although an attribute is present, it has no values - like a nullable column in an database table. With data sources like files, missing attributes can appear as empty string values.
  2. By default, an attribute map will delete missing attributes from the target entry. This behavior can be customized by using Null Behavior settings.
  3. Null Behavior could also used to send other values than NULL to the Connector within the Output Map. For example, deleting attributes/value in an LDAP entry.
2. Describe how Null Behavior is configured.
  1. Different data sources treat missing values in different ways (null value, empty string) and the feature described in this section provides a way of customizing how missing attributes - or attribute values - are treated. This feature is called Null Behavior and with it you can define both what a "null value" is as well as how it is to be handled.
  2. Null behavior can be specified at a number of levels: system, Config, AL, Attribute map and Attribute. - System-level- Config level- AL level- Attribute map level- Attribute level- However, since Null Behavior is highly data source-specific, it makes most sense to set this system property at the Attribute map level (for example, for all Attributes handled by a Connector's Input or Output Maps).
  3. Null Behavior supports five different settings for defining what a null value is, as shown below.- Attribute is missing (AbsentAttribute).- Attribute contains an empty string value (EmptyString).- Value (a specified string value)- Default Behavior (to inherit from the next level above)
  4. The Null Behavior feature also lets you define the action to be taken in case a null value is detected:- Empty String (return an empty string value)- Null (to return the attribute with no values)- Delete (to delete the named attribute from the target entry)- Value (return the attribute with the specified string value)- Default Behavior (to inherit from the next level above)
Given a working installation of TDI and a need to create an AL with reusable components, use the resource library to store reusable components, so that these components can be reused and inherited.
With emphasis on performing the following tasks:
1. To enable reuse, define components and Scripts in the Resources Library and inherit them into ALs.
2. To enable pooling of a Connector, you must add it to the Resource Library before adding it to an AL.
  1. The pool definition for a Connector is visible in the Pool tab of the Connector in the Resource Library. Specific instance configuration is done in the Pool tab of an Inherited Connector in an AL.
3. To enable the customization of a component's Connection Forms, you must add the component to the Resource Library before adding it to an AL.
  1. The forms editor is used to customize the connection parameters form for a component. This can only be applied to components in the Resources folder (except properties files). To customize a form, you must open the component with the Forms Editor.
Given a working installation of TDI and a need to create an AL, use JavaScript to enable TDI objects to perform work, so that a functioning AL can be created.
With emphasis on performing the following tasks:
1. Manipulate the Entry Object to store Attributes.
  1. Looking in detail at when a data value is received by a component, a corresponding TDI Attribute object is created by using the name of the attribute being read. The data value itself (or values, if it is a multi-valued attribute) are converted to appropriate Java objects–like Java.lang.String or java.sql.Timestamp –and assigned to the Attribute. If you take a look in the TDI API documentation, you will see that the Attribute object provides a number of useful methods, like getValue(), addValue() and size(). This allows you to create, enumerate and manipulate the values of an Attribute directly from Script. You can also instantiate new Attribute objects as needed.
  2. Attributes themselves are collected in a data storage object called an Entry Object. The Entry is the primary data carrier object in the system and TDI gives you access to important Entry Objects by registering them as script variables. A prime example is the Work Entry Object in the AL, used to pass data between AL components (as well as between ALs). This Entry Object is local to each AL and available as the script variable work.
  3. Looking at the Javadocs, you will see that the Entry Object offers various functions for working with Entries and their Attributes and values, including size(), getAttributeNames(), getAttribute() and setAttribute().
  4. Entry Objects can also contain properties. Properties are data containers like Attributes, except that they are only single-valued. While Attributes are used to store data content, properties hold parametric information, allowing you to keep this information separated. Properties do not show up for attribute map selection or in the Work Entry list, but can be accessed much like Attributes from Script. Entry functions like getProperty() and setProperty() are used for this, and these work directly with Property values, which can be any type of Java object, just like Attribute values. There is no intermediate Property object as there is when you work with Attributes.
2. Use hierarchically structured data in hierarchical Entry Objects.
  1. The Entry Object represents the root of the hierarchy and each Attribute represents a node in that hierarchy. Following this logic the values of every Attribute are leafs in the hierarchy. An API for traversing the hierarchy exists as well. This API is a partial implementation of the DOM 3 specification.
  2. Only a few classes from that specification have been implemented:- Org.w3c.dom.Document - implemented by the Entry class.- Org.w3c.Element - implemented by the Attribute class.- Org.w3c.Attr - implemented by the Property class.- Org.w3c.Text and org.w3c.CDATASection - implemented by the AttributeValue class.
  3. In order to maintain backward compatibility with previous releases of TDI when implicitly working with hierarchical Entries, all the old methods exposed by both the Attribute and the Entry classes have changed slightly.
  4. For example, the Entry.getAttributeNames() method will return an array of full paths to the leafs that are available in the tree.
  5. Access Attributes directly by name. The TDI Script Engine enables you to easily access the attributes of an entry just by referring to them by name; for example, entry.attrName returns the attribute with name attrName. The JavaScript Engine resolves names based on the context object the name was requested on. For example, if the call entry.a is performed, the entry name is the context object and a is the name of the child object to resolve. The JavaScript Engine uses left-to-right interpretation to evaluate each context object until the final one is resolved.
  6. Flattening hierarchical structures. When working with hierarchical data it is sometimes necessary to flatten the nodes of the hierarchy. To do that you can either write a Script for traversing the tree, or use one of the methods:- getElementsByTagName(String namespace, String localName);- getElementsByTagName(String tagName);
  7. These methods traverse the tree and search for elements with the specified name and namespace. The DOM API allows these methods to accept the character "*" for both names and namespaces. That character represents a wildcard, which is used to match any element name/namespace. Using that character for name flattens the tree by returning all the Attribute nodes in a NodeList. It should be noted that the structure of the hierarchy has not been changed. The returned NodeList is just a container for the Element nodes that were found in the tree.
3. Use scripting in Attribute Maps
  1. The logical place to do the attribute transformations is in your Attribute Maps, both Input and Output. If you're required to compute a new attribute that is required by scripted logic or other Connectors downstream in the AL, best practice is to do this in an Input Map if possible. Alternatively, if you must transform attributes for the sake of a single output source, then you can avoid cluttering the Work Entry Object with output-specific transformations by putting these in the Output Map. of the relevant Connector.
4. Use scripting in Hooks
  1. The other category of custom logic, flow control, is best implemented in the Hooks that are invoked at that point in the automated workflow where the logic is needed. These control points are easily accessed from the Config Editor. Implementing custom processing is simply a matter of identifying the correct control point and adding your Script in the appropriate edit window.
5. Use Script Components
  1. AL Script Components, independent blocks of scripted code, also provide you with a place to create your own custom processing, and then enable you to reposition your code within the AL. Although Script Components are frequently used during test and debugging, they can also serve an important role in a production Config. Just remember to name your components clearly and to include some documentation in the Script itself to explain 8 why you implemented this logic in a Script Component, and not in an Attribute Map or Hook.
Given a running production environment and completed solution, enable and perform logging in a TDI solution, so that output information is saved to the specified log files.
With emphasis on performing the following tasks:
1. Create logger:
  1. In the "Log & Settings" panel for the TDI AL create a new logger and specify the following:- Logger type- File name- Pattern- Log Level
2. Enabling detailed logging:
  1. AL settings as well as component Connection tabs provide a detailed log check-box which causes debug information to be included in the log.
3. Enable script logging:
  1. In any script location use the following code snippet to create a log entry at the specific level:- task.logmsg ("Message to be logged");- main.logmsg ("Message to be logged").
  2. This logs the message at the INFO level. Specifying a different log level can be done by using a snippet such as this:- task.logmsg("DEBUG","Message to be logged");- main.logmsg("WARN","Message to be logged").
4. Displaying the contents of an Entry in the log:
  1. For example, to list the contents of the Work Entry use one of these scripted calls:- task .dumpEntry(work);- main.dumpEntry(work).
5. Custom logging:
  1. This can be done by using a FileSystem Connector or direct manipulation of Java File and Writer Classes, or scripting directly with the log4j or JLog classes.
Given an operational understanding of TDI, describe the End-of-Cycle behaviors of AL and AL Components, so that a basic understanding on what a cycle is, in terms of TDI, and how to make use of them has been defined.
With emphasis on performing the following tasks:
1. Describe what the purpose of End-of-Cycle behaviors is.
  1. End-of-Cycle behaviors exploit the transactioning functionality found in some types of Connectors, in particular relational databases. They permit the implementation of ALs that either successfully make a series of related updates to all target endpoints, or to none at all.
2. List the phases of the AL lifecycle.
  1. Initialization- TDI creates an AL Object from the provided configuration.- All configured AL Components are created, including Task Call Block(TCB) processing.- Start of Script Engine- All components configured with "initialization at startup" gets initialized, which causes the run of each configured Prolog Hook
  2. Cycling- After AL hook "on start of cycle" the AL work - flow starts serial processing of each active component.- Current active feeds Connector reads in data and creates the Entry Object "work".- "Work" object will be passed to the Flow section where it is passed from component to component until either an unhandled exception occurs, or the end of the Flow section is reached.- When Flow section processing is complete:- End-of-Cycle behaviors are carried out (if any).- Control is returned to the Feed section to retrieve the next Entry.- Or if no active Feed component is available, then the AL shutdown processing begins.
  3. Shutdown- The AL processing has completed.- Normally, due end of input data-flow.- Accidentally due an unhandled exception or terminated with an JS call like task.shutdown() or task.terminate(), or by throwing an exception by using the JS �throw' command.
3. Describe what End-of-Cycle behaviors are.
  1. These are operations carried out at the end of Flow section processing for each cycle of the AL.
  2. End-of-Cycle behaviors include:- Commit change written to an RDBMS (JDBC, Database, System Store Connectors)- If they are configured for End-of-Cycle commit- Commit current Iterator State Key for Change Detection Connector - If it is configured for End-of-Cycle peristence of the State Key- Releasing MemQ lock (MemoryQueue Connector)- Server Mode Connectors make reply to the client request.- User-defined behaviors- These are implemented with a Script at the bottom of the Flow section to do things like acknowledging messages read from a queue, etc.
4. Describe how to control End-of-Cycle behaviors.
  1. Connector configuration, for example setting the Commit or State Key Persistence option.
  2. Manually invoking Connector End-of-Cycle behaviors:- The JDBCConnector, DatabaseConnector and PESConnector (System Store) classes provide a public .commit() method, as well as .rollback() that can be called from JavaScript: DB2.getConnector().commit()- Change Detection Connector provide the public .saveStateKey() method that can be called from JavaScript: LDAPChangelog.getConnector().saveStateKey()- Ending the current cycle and performing End-of-Cycle behaviors- Using the system.exitFlow() or system.exitBranch("Flow") calls- Ending the current cycle and skipping End-of-Cycle behaviors- Using the system.skipEntry() call
Given an operational TDI installation and an AL, describe the usage of properties to influence the AL behavior, so that how to use Property Stores to change the behavior of AL's logic and the ability to show how to basically take use of them have been explained.
With emphasis on performing the following tasks:
1. List the types of properties used by TDI.
  1. TDI Server properties- These are defined in the global.properties file found in the /etc folder.- If a Solution Directory is specified and it contains the solution.properties file, then properties defined here override those in global.properties
  2. User-define Properties (Property Stores)- These are used to externalize parameter settings, private information like passwords and other configuration information used to control the connectivity and behavior of ALs.
  3. Various logging properties, e.g. *log4j.properties and jlog.properties
  4. derby.properties for configuring the Derby RDBMS
  5. mqeconfig.props for configuring MQe
  6. Plus the following, if installed and used:- Administration and Monitoring Console(AMC) and Action Manager(AM) properties;- lwi properties.
2. What are Property Stores and how are they used?
  1. Property Stores are named resources that contain property definitions as name-value pairs.- These can leverage most TDI Connectors to persist/retrieve properties- The default is the Properties Connector, which is a FileSystem Connector - As a result, properties are written to human readable files that can be modified by using a text editor - i.e. not requiring knowledge of the TDI CE.
  2. By default, each Project gets a Property Store named .properties.- The File Path/Collection parameter for the Property Store is set as a TDI Expression that uses a special sub-situation token: {config.$directory}/name_of_project.properties- This token resolves to the location on disk where the TDI Server loaded the Config xml.- By default, both the .properties file and Config xml are stored in the �runtime' folder.
  3. Property Stores are created and edited by using the TDI CE.- When changes are made to properties in the CE, the �Send properties to server' button is used to transfer these values to the properties file.- When changes have been made to the properties file itself, the �Read properties from server' button is used to update these to the Property Store in the CE.
  4. Properties can be tied to component Connection parameters through the Parameter Dialog which is opened by either:- Clicking on the label of the parameter.- Or clicking on the question mark button at the right of the parameter input field.- This dialog allows you to assign a property as the run-time source for a parameter's value.
  5. Properties can be accessed from Script by using the following methods of the com.ibm.di.function.UserFunctions class:- system.getTDIProperties() which returns the TDIProperties manager object. This object allows you to retrieve individual Property Stores so that they can be refreshed or changes commited to disk.- system.getTDIProperty() for retrieving a specific property value.- system.setTDIProperty() for changing the value of an existing property, or adding a new one.
3. Evaluation order and value precedence
  1. Property requests in TDI Expressions or system.getTDIProperty() calls that are qualified by a Property Store name must be present in the specified Property Store or null is returned.
  2. Unqualified requests cause TDI to search through defined Property Stores for the property name. The first occurrence found is returned. Note that the order Property Stores are searched is indeterminate and not related to the alphabetical listing on screen in the CE.
Given an operational TDI solution, describe how to submit AL parameters via command line, so that how to use command line parameters to dynamically change an AL's connectivity and behavior have been explained.
With emphasis on performing the following tasks:
1. Start a AL from the command line and provide parameters for usage within the AL logic.
  1. The command line is limited to the amount of 9 different AL command line parameters
  2. The Syntax is like:- /ibmdisrv -s -c -r -0 "first parameter" -1 "second parameter"
2. Check if the expected parameters are provided and retrieve there values
  1. The parameter values are part of the com.ibm.di.server.RS class- TDI provides automatically access to the class via the "main" object
  2. The values are accessible via the method "commandLineParam()"- It expects one parameter of type String, the possible values goes from "0" to "9".- It returns the:- Value of the requested user defined command line parameter as String;- Null if the parameter was not provided.
3. Use the provided parameters within your AL.
  1. Sample code:// sample 1 main.logmsg("Param 0: " + main.commandLineParam("0"))//sample 2; to be placed in the connectors hook "prolog before init" var lu = main.commandLineParam("0"); thisConnector.connector.setParam("ldapUrl", lu);
  2. Can be used at all places where JavaScript statements are allowed.
4. What can command line parameters be used for?
  1. Dynamically change the behavior of AL's without the need of starting CE or edit property files.
Given an operational TDI installation and a configuration file with multiple ALs, describe how to start AL's at runtime from an different AL's Logic, so that there is an understanding of how to deal with multiple AL's from a single configuration file.
With emphasis on performing the following tasks:
1. Give examples why to start AL(s) from another AL.
  1. Ensure order of AL execution.
  2. Do AL execution in parallel.
  3. Schedule periodic execution of ALs.
2. Starting an AL by using JavaScript code
  1. Can be done at any location which allows JavaScript code.
  2. Initial Workentry can be provided:// Create a new entry objectvar myIWE = system.newEntry(); // Add an attribute to myIWEmyIWE.setAttribute("name","John Doe");
  3. TCB information can be provided/retrieved:// Create a new TCBvar tcb = system.newTCB();// Set the IWE and parameterstcb.setInitialWorkEntry ( myIWE );tcb.setConnectorParameter ( "MyConnectorName", "ldapUrl", "ldap:\\1.2.3.4:389");
  4. Starting AL:// start an named Assembly linevar al = main.startAL("ALName");
  5. Accessing the AL Object:// retrieve potential tcb informationvar tcb = al.getTCB();// retrieve some informationmain.logmsg("AL run mode: " + tcb.getRunMode()); main.logmsg("AL operation: " + tcb.getALOperation());main.logmsg("AL settings: "); main.dumpEntry(tcb.getALSettings());// optional waiting for AL to finish al.join();
3. Starting an AL by using AL Connector:
  1. Mode setting of the connector must correspond to Operations defined for the AL.
4. Starting an AL by using AL Function component:
  1. The AL Operation settings can be specified.
  2. Available "Execution Modes" for the called AL. - Run and wait for result.- Run in background.- Manual (cycle mode)
  3. Usage of FC Attribute mapping- Input Map- Used to retrieve information from the AL.- Output Map- Used to provide information to the AL.
Given an understanding of TDI and the TDI Entry-Attribute data model, describe how to work with Attributes and Attribute values, so that a clear understanding of how TDI carries data values is shown.
With emphasis on performing the following tasks:
1. What is a multi-valued Attribute?
  1. This is an Attribute with more than one value.- A common example is a person's �mail' attribute, since many people have multiple addresses.
2. How do you use a multi-valued Attribute in TDI?
  1. Proceeding the Attribute name of a Link Criteria with the at-symbol (@) will cause the match to be made to any of the values of that Attribute.
  2. The Attribute Value Loop can be used to cycle once for each value in a specified Attribute.
  3. The work.getString() method will only return the first value of an Attribute, and it will convert it to a Java String representation.
  4. The TDI JavaScript Engine allows you to use shorthand notation to access values in an Attribute.
  5. Script access to Attribute values is provided through JavaScript shorthand notation, as well as a number of public methods:- Attribute.size() returns the number of values carried by the Attribute.- The shorthand notation, work.attributename[n], returns the nth value of the Attribute as the Java object used to store this value; This is only true if n is greater or equal to 0 and less than the number of values held by the Attribute: 0 < n < attribute.size()- Attribute.getValue() which returns the first value of the Attribute as a Java String.- Attribute.getValue(n) returns the nth value of the Attribute as the Java object used to carry this data value.- Attribute.addValue() methods allow for new values to be added.- Attribute.getValueOperation(n) returns the delta operation code for the nth value.- Attribute.hasValue() returns true if the specified string value is carried by the Attribute, otherwise false is returned. There is also a case-insensitive search method: attribute.hasValueIC().- Attribute.merge() merges all values from another Attribute.- Attribute.removeValue() and attribute.removeAttributeAt() for removing a value from an Attribute.- Attribute.setValue(), attribute.setValueAt() and attribute.setValues() for changing values.- Attribute.setValueOperation() to set the delta operation code of a value.
  6. It is important to note that in order to use Attribute methods then the correct calls must be used to retrieve the Attribute object itself, for example, not its values.- The shorthand notation, e.g. work.attributename, returns the Attribute object itself and can be used as described above.- Note that when used for simple Attribute mapping Scripts, or when used in JavaScript string expressions (e.g. concatentation), then only a Java String is returned that represents the first value of the Attribute.- work.getAttribute("attributename") returns the Attribute object itself and can be used as described above.- work.getString("attributename") returns the first value of the Attribute as a String, and not the Attribute itself.- work.getObject(n) returns the nth value of the Attribute as the Java object used to carry that data value.

Section 5: Problem Determination

Given the IBM Tivoli Directory Integrator V7.1(TDI) manuals and installation location, use the console log, update log, and standard log files to locate the various types of logs.
With emphasis on performing the following tasks:
1. Standard TDI log
  1. The default TDI log (ibmdi.log) is located in the "logs" folder under the TDI Solution Directory if one is defined otherwise it is located in the TDI install directory. It is the default log location for TDI and any running AssemblyLines(ALs). The behavior for this default log can be modified by changing the properties in the log4j.properties file.
2. AL specific logs
  1. TDI allows for the definition of custom logging. For example, the type of logging as well as log file locations can be specified in the AL settings. The information logged depends on these settings along with custom log script added to any scripting within the AL.
3. Management Console log
  1. The management console log is located in the logs folder under the Administration and Monitoring Console(AMC) install location. This log contains information related to the operation of the AMC and any TDI ALs running in the AMC.
4. Update Installer log
  1. The update installer log is located in the logs folder under the TDI install location. It contains information related the installation or removal of updates to the TDI installation.
Given a TDI log file and IBM documentation resources, use log analysis and exception stack traces to locate and identify key messages to isolate the problem source to interpret the root case of the exception.
With emphasis on performing the following tasks:
1. ibmdi.log - A starting place for the TDI error messages.
  1. Note that ALs may also have their own log files.
2. Extracting salient information from a logged exception
  1. Either view the login the Configuration Editor(CE) run window, or view/edit the logfile.
  2. Navigate to the first Java stack trace.
  3. Locate the name of the component which is failing. This value is surrounded by square brackets, e.g. [componentName], and will appear one or two lines above the top of the stacktrace; ie. on the last log line with a timestamp.
  4. Locate the TDI Message ID appearing after the component name.- Message IDs can be used in searches, both on the Internet and in the TDI Message Guide.- TDI provides error messages in a message ID format of:- a 5-character product identifier- a 1-character component or subsystem identifier- a 3-digit serial number- a 1-character type code indicating the severity of the message- Just after the Message ID is the related message text.
  5. Locate the operation that failed, which appears after a comma (,) following the message text.
  6. Locate the problem-specific error message on the next line.- Examples are syntax errors encountered by the JS Engine, exceptions thrown by drivers or libraries that a Connector or Function is uses, or by the underlying connected system.
3. How can log be made more informative?
  1. By setting the Detailed Log option for an AL.
  2. By enabling the Detailed Log option for Connectors, Functions and Parser.
  3. By using task.logmsg() and main.logmsg() to provide custom log details to aid in troubleshooting.
  4. By using enabling tracing when starting the TDI Server by using the command line argument -T to specify JLOG options, as described in the TDI Installation and Administrator Guide.
Given a fully configured and runnable TDI installation, explain the TDI debugging features, so that the function of them has been defined.
With emphasis on performing the following tasks:
1. List the TDI debugging and test features
  1. Data stepper- Allows the user to step through the execution of an AL, from Connector to Connector.- Provides an interactive JavaScript command field where snippets of JavaScript can be dynamically executed in the context of the running AL.
  2. Debugger- Allows the user to step through the execution of an AL, including all types of components, Hooks, Attribute Maps and JavaScript code.- Provides a columnar view of all Conn Entries used by Connectors in the AL- Supports setting breakpoints for components, as well as in Scripts.- Breakpoints can be made conditional by assigning a Boolean JavaScript expression to a breakpoint.- Provides a Watch List where all objects, attributes and script variables are displayed, including custom JavaScript expressions added by the user.- Provides an interactive JavaScript command field where snippets of JavaScript can be dynamically executed in the context of the running AL.- Allow for dispatched ALs to be debugged (e.g. invoked by another TDI process, or external system, like IBM Tivoli Identity Manager). Also known as Server Debug mode.
  3. Sandbox- Enables the recording of one or more Connectors in an AL for later replay, for example while TDI is disconnected from these endpoints.
  4. AL Simulation Mode- ALs can be tested without actually exchanging data with connected systems. Only the metrics of which operations would have been performed, and how many times, is displayed.

Register for a test

IBM at Prometric

Test 000-563: IBM Tivoli Directory Integrator V7.1

Tab navigation

Register for a test

Content navigation

Related links