Adventures with IBM TDI

Can an Eclipse Plug-in be loaded into the SDI Config Editor?

2015-11-24T10:06:00.003-06:00

In the past I've had customers ask how to use SDI with other code repository clients. CVS is the supported client supplied with the SDI Config Editor, though others could be more desirable by the client.. Over the past week I looked into this and found the SDI Config Editor fails to loaded the SVN client if installed though the Eclipse 'Install New Software' menu.

I will use the concept of “Links” to add an Eclipse Plug-in to the SDI Config Editor. Instead of using the Eclipse Update Manager or copying resources into the <TDI>/ce/eclipsece directory structure, this third option is available.

This is a step by step procedure. I believe these steps will work on TDI 7.1.1 also.
(In the example, we will use the Subversive Plug-in with SDI 7.2)

1. Install SDI 7.2 and upgrade to at least 7.2.0-ISS-SDI-FP0003

2. Download the desired plug-in. Be sure the plug-in supports the Eclipse being used.

Tivoli Directory Integrator 7.1.1 (TDI) is build on Eclipse Helios SR1(v3.6.1)
Security Directory Integrator 7.2 (SDI) is built on Eclipse Juno SR1(v4.2.1)

3. Create a folder named links inside the <SDI_Install_Directory>/ce/eclipsece folder

4. Create a new file inside this folder and name it as 'svn.link'. Note the file name can be any valid string, but the extension has to be link.

5. Assume that I have unarchived the plug-in into the <TDI_Solution_Directory>/eclipseDropins directory as shown below.

NOTE: I found I had to create the eclipse subdirectory and copy all plugin content into the eclipse directory.

6. The contents of svn.link (from step 4) will be:

For unix/linux:
path=/opt/IBM/TDI/SolV72/eclipseDropins/Subversive-2.0.4.I20150123-1700

For Window:
path=C:/IBM/TDI/SolV72/eclipseDropins/Subversive-2.0.4.I20150123-1700
or
path=C:\\IBM\\TDI\\SolV72\\eclipseDropins\\Subversive-2.0.4.I20150123-1700

7. Start the TDI Config Editor.

8. Verify that the SVN Plug-in has been loaded. Reviewing the Perspective and Properties should validate this.

Windows > Open Perspective > Other

Windows > Preferences

Points to Note:

The string should always start with “path=” keyword.
The path should point to a directory which has a “eclipse” folder which in turn has “features” and “plugins” as sub-folders. For the svn plug-in, all content of the plug-in had to be moved into a sibling 'eclipse' directory. This is shown in the image found in Step 5 above.
It is recommended to use forward slash ‘/’ in the path (If you want use Backslash, see that you use the escape character i.e. in Windows it should be “\”)
The file extension should end with “link“
The file (i.e svn.link in our example) should exist in the “links” folder.
It is recommended to create link files only for big plugins/applications. For small plugins you can create just one link file, say misc.link and copy all the small plugins to the path referred by this link.

Using the SDI Dashboard

2015-02-27T10:09:00.001-06:00

Sending SMS via Twilio with TDI

2014-10-08T13:52:00.001-05:00

I recently had a conversation with Chris.E on the topic of using services provided by Twilio.com to send SMS/MMS messages from IBM TDI. In the future, I might look into reading messages from the service.

Here's a summary on implementing the send call within TDI.

First, follow the Twilio Java information on where to obtain the pre-built jar for 'twilio-java-sdk-*.*.*-jar-with-dependencies.jar'. Once downloaded, place the jar in the <TDI711_Install_Directory>\jvm\jre\lib\ext directory. Placing the jar in the default <TDI711\jars\3rdparty\others directory will cause the following invocation exception when the Assemblyline runs.

java.lang.reflect.InvocationTargetException
...
...
Caused by: java.lang.VerifyError: org.apache.http.params.BasicHttpParams

Second, with the jar added to the <TDI711_Install_Directory>\jvm\jre\lib\ext directory, start the TDI Config Editor. From here, you can instantiate the TwilioRestClient and start sending SMS/MMS messages from TDI.

Here's an example of a simple implementation

Create custom functions:

/**
 * Functions created from examples provided at www.Twilio.com
 * https://www.twilio.com/docs/quickstart/java/sms/sending-via-rest
 * http://twilio.github.io/twilio-java/
 */

function createTwilioSession(ACCOUNT_SID, AUTH_TOKEN ){
 twclient = new com.twilio.sdk.TwilioRestClient(ACCOUNT_SID, AUTH_TOKEN);
 return twclient
}

function sendSMS(client, to, from, body){
 messageFactory = client.getAccount().getMessageFactory();
 params = new java.util.ArrayList();
 params.add(new org.apache.http.message.BasicNameValuePair("To", to));
 params.add(new org.apache.http.message.BasicNameValuePair("From", from));
 params.add(new org.apache.http.message.BasicNameValuePair("Body", body));  
 message = messageFactory.create(params);
 return message.getSid()
}

function sendMMS(client, to, from, body, image){
 messageFactory = client.getAccount().getMessageFactory();
 params = new java.util.ArrayList();
 params.add(new org.apache.http.message.BasicNameValuePair("To", to));
 params.add(new org.apache.http.message.BasicNameValuePair("From", from));
 params.add(new org.apache.http.message.BasicNameValuePair("Body", body));
 params.add(new org.apache.http.message.BasicNameValuePair("MediaUrl", image));  
 message = messageFactory.create(params);
 return message.getSid()
}

Instantiate the connection on the start of the AL:

Iterate data in the AL Flow:

Call custom function:

Result:

API Documentation Browsing

2013-10-31T15:29:00.001-05:00

I'd recently been looking for one location to find all references to API documentation. After doing a quick search, I came across Dash. The UI layout, snippet manager, and integration into IDE's make a nice feature set...although it's only available on the Mac.

As a close alternative, there's 'Zeal'...It lacks the Snippet manager, and IDE support...although seems to make a good app for localizing offline documentation.

You can find both apps at the following links:

Generate docsets for TDI

For instructions on putting your own docsets together follow this link.

Zeal doesn't support doc feeds like Dash does. So you have to download the docset archive and extract it to $HOME/.local/share/zeal/docsets/ or C:\Users\[your username]\AppData\Local\zeal\docsets\.

Setup of a secure JDBC Connector to Oracle

2013-06-11T09:39:00.000-05:00

I've seen a few post on the TDI forum in regards to this subject, so here are my notes I've pulled together when setting up TDI with a secure Oracle jdbc connection.

Setup of the Oracle Wallet

To enable SSL in Oracle, a Certificate for the Oracle Server signed by a Certificate Authority(CA) is required. In my environment, I created a Self Signed CA which will issue the certificate to the Oracle Server.

If you already have a CA to process your Certificate Request, then ignore steps 1, 4, 5 & 6 steps

1. Download and unpack the ssl helper scripts named ssl.ca-0.1.tar.gz from the OpenSSL > Contributions page.

2. Open Oracle Wallet Manager and create a new wallet and certificate request.

3. Export the certificate request to a file. Give it a .csr extension

4. Move the certificate request to the directory containing the openSSL certificate authority scripts (e.g. /usr/src/crytpo/openssl/apps/ssl.ca-0.1) from Step 1.

5. Create a self-signed root certificate by running the new-root-ca.sh script. (You only need to run this command once). This will create a file called ca.crt

6. Use the CA to sign the certificate request... e.g.

# sign-server-cert.sh <certificate-request-filename>. This will create a file called <certificate-request-filename>.crt

7. Import the ca.crt into the Oracle wallet as a trusted certificate. Import the <certificate-request-filename>.crt as a user certificate.

8. Enable auto-login and save the wallet. It is now ready for use.

Setting Up Oracle Server to use the SSL/Wallet.

I found it easier to use the Oracle GUI (item b), then modifying the files directly (item a).

Both sets of instructions are provided, although I used the instructions in item b to setup my test environment.

a. Modify Oracle ORA files to point to the Wallet. (wp-oracle-jdbc-thin-ssl-130128.pdf)

b. Using the Network Configuration Manger to setup SSL:

Configuring the LISTENER

ALSO review the following...

Make sure the WALLET is mentioned in the sqlnet.ora & listener.ora files.
If the SSL_CLIENT_AUTHENTICATION parameter is not set, the default setting is TRUE and clients are required to present a certificate during the SSL handshake. For my test environment I did not need client authentication, so I disabled it with the following parameter.

Add the following line to the end of both files..$TNS_ADMIN/listener.ora and $TNS_ADMIN/sqlnet.ora

SSL_CLIENT_AUTHENTICATION=FALSE

Verifying the SSL Connection outside of TDI, with the 'Oracle SQL Developer'

a. The 'Oracle SQL Developer' GUI uses a JVM on the system. For the JVM, it uses "C:\app\administrator\product\11.2.0\dbhome_1\jdk\bin\java.exe", so you'll need to add the CA Certificate to the jvm\jre\lib\security\cacerts jks file. Other wise you'll receive a connection error regarding an untrusted certificate. The default password for cacerts is 'changeit'

b. Create the JDBC URL

jdbc:oracle:thin:@(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcps)(HOST = <hostname>)(PORT = <sslport>))) (CONNECT_DATA = (SERVICE_NAME = <service_name>))(SECURITY=(SSL_SERVER_CERT_DN=\"CN=<.......>\")))

Verifying the JDBC URL

I had issues getting the correct url...the 'Service Name' gave me problems when trying to test the connection via the 'Oracle SQL Developer'. Here's a few screen shots of the 'Net Manager' which I reviewed to help me correct my URL.

Compare these 3 files on the Oracle Server if you are having problems with the connection.

C:\app\administrator\product\11.2.0\dbhome_1\NETWORK\ADMIN

Successfully connect to the database using the secure jdbc url in the Oracle SQL Developer client before proceeding to setup the TDI JDBC Connector.

TDI Server Side Configuration

In this environment, I used the Oracle Thin JDBC client.

For TDIv6.1.1(JRE 1.5) use the Oracle Thin Client (ojdbc5.jar)
For TCIv7.0 or 7.1(JRE 1.6) use the Oracle Thin Client (ojdbc6.jar)
No additional Oracle files are on the TDI machine

TDI SSL Configuration

We must update the jks file used by the TDI Server to include the CA which signed the certificate for the Oracle Server.

Obtain the public certificate of the CA. Contact the CA for this process.
Use the ikeyman tool (<TDI_HOME>/jre/bin/ikeyman) to import the CA public certificate into the jks file defined in your solution.properties file.
To determine which JKS file you need to update, you can find the name of the file by reviewing the following section in the solution.properties file.

## server authentication
javax.net.ssl.trustStore=serverapi/testadmin.jks
javax.net.ssl.trustStorePassword=
javax.net.ssl.trustStoreType=jks
## client authentication
javax.net.ssl.keyStore=serverapi/testadmin.jks
javax.net.ssl.keyStorePassword=
javax.net.ssl.keyStoreType=jks
After you have updated the jks with the CA public certificate, restart TDI so the updated jks is used by the JVM.

TDI JDBC Connector Setup:

First, setup the connector to use a non-secure connection to make sure you can connect to the database.

JDBC URL
jdbc:oracle:thin:@<HOST>:<PORT>:<service_name>
Second, use the following url skeleton to build your url:
SECURE JDBC URL
URL : jdbc:oracle:thin:@(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcps)(HOST = <hostname>)(PORT = <sslport>))) (CONNECT_DATA = (SERVICE_NAME = <service_name>))(SECURITY=(SSL_SERVER_CERT_DN=\"CN=<.......>\")))

(SECURITY=(SSL_SERVER_CERT_DN=\"CN=<.....>\")) is optional and is used only for server DN matching.

I found this link discussing Oracle Thin connection to be informative.
http://docs.oracle.com/cd/E12839_01/web.1111/e13737/third_party_drivers.htm#i1050126

Example:

jdbc:oracle:thin:@(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcps)(HOST = hostname)(PORT = 2484))) (CONNECT_DATA = (SERVICE_NAME = orcldb)))

Extra Provider Parameters

oracle.net.ssl_version:3.0

//The following two parameters were optional when connecting to my Oracle Server. These two plus additional parameters maybe required depending on your Oracle Server configuration.

oracle.net.ssl_cipher_suites:SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_AES_128_CBC_SHA

oracle.net.ssl_server_dn_match:FALSE

Possible Connection Errors:

------

ERROR: CTGDIS266E Error in InitConnectors. Exception occurred: java.sql.SQLException: The Network Adapter could not establish the connection java.sql.SQLException: The Network Adapter could not establish the connection

FIX: The OracleOraDb11g_home1TNSListener service on the Oracle Service must be running.

FIX: The oracle.net.ssl_version:3.0 was missing from the TDI JDBC Connector configuration.

------

ERROR: CTGDIS266E Error in InitConnectors. Exception occurred: java.sql.SQLException: Listener refused the connection with the following error: ORA-12514, TNS:listener does not currently know of service requested in connect descriptor

FIX: The <service_name> given in the JDBC URL is incorrect.

------

ERROR: CTGDIS266E Error in InitConnectors. Exception occurred: java.sql.SQLException: IO Error: Remote host closed connection during handshake java.sql.SQLException: IO Error: Remote host closed connection during handshake

FIX: The 'Import User Certificate' process had to be completed in the Oracle Wallet for the Oracle Server Certificate.

Experience with the TDI CDE

2013-05-21T11:17:00.002-05:00

I've ran into problems when attempting to use the CDE, so I wanted to post incase it helps anyone else.

TDI Component Development Environment (CDE) is a tool that enables an effective, efficient and consistent way of creating TDI components. It abstracts and automates functions, tasks and complexities of developing TDI components. TDI CDE can be used by a customer to quickly develop new custom components with minimal effort. This helps build better TDI solutions enabling creation of custom TDI components by the customer for easy use. -- Source url: http://www.ibm.com/software/brandcatalog/ismlibrary/details?catalog.label=1TW10DI0R#tab-pinfo

Video:

Discussion on connector development: http://www.youtube.com/watch?v=4aiqj7lhbrg

Known Issues I've seen with CDE:

Start Eclipse with the 'Run as Administrator' option, else when you use the 'File / Export / IBM Tivoli Directory Integrator / Deployable Connector' function in Eclipse to move the resource to TDI, the export windows will complete..although the resource will not be found in the TDI/jars directory. The Export windows seems to flash to quick to see if any error is given during the export.
In Eclipse, I found the 'Java' not 'Java EE' perspective should be used. If the 'Java EE' perspective is used, then the error 'The selected resource is not a valid IBM Tivoli Directory Integrator project' is seen when attempting to export the developed resource.
I could not find it documented in the CDE documentation on which JDK is required.
Unexpected behavior was seen when using a non-IBM JDK.
- The 'Finish' button had to be pressed multiple times to confirm completion.
- The Project structure was random and incomplete.

Google Voice (SMS) with TDI

2012-08-29T14:56:00.000-05:00

Recently I've been working on an Assemblyline line which needed to send sms notification. As most know, TDI already provides a sendMail() method in its UserFunction class to send email. Using this method allows messages to be sent to phone numbers which have a service provider email address (e.g. 5552224444@txt.att.net).

However some providers like Google Voice(GV), do not provide this number@email option.
So with this limitation it took a little searching to find another option.

I found by using the google-voice-java API (api docs) we can send sms messages via TDI directly to a phone number, instead of relying on a phonenumber@email address.

JARs are available at:
http://code.google.com/p/google-voice-java/downloads/list

At the time of this posting, there were 5 jars (google-voice-java-1.14-java6.jar, dom4j-1.6.1.jar,
jaxen-1.1.3.jar, json.jar, jtidy.jar).
Simply add the jars to the <TDI>\jars\3rdparty\others\GoogleVoice directory

You can then use the following function from your Resource/Script library to to send sms from TDI by the way of Google Voice.

/*
* sendGVsms uses the api made available at
* http://code.google.com/p/google-voice-java/w/list
*/
function sendGVsms(dst,txt){
    try{
        destinationNumber = dst;
        txt = txt;
        username = system.getTDIProperty("gvuserName")
        pass = system.getTDIProperty("gvpass")
        var gvoice = Packages.com.techventus.server.voice.Voice(username,pass);
        gvoice.sendSMS(destinationNumber,txt);
        } catch (e) {
            task.logmsg(">>sms error " +e);
    }
}

NOTE: You will need to add Google's public certificate to the TDI truststore, otherwise you'll receive a 'java.lang.reflect.InvocationTargetException' when calling the class.

I used the following information to obtain and add the certificate to the TDI truststore.

1. Obtaining the Google certificate
a.

b.

c.

d. Choose a 'Save as type' of DER when exporting the certificate.

2. Adding the certificate into the default TDI truststore.
By default, a TDI 7.x installation uses the serverapi/truststore.jks as its truststore.
This file location may vary depending on if you have a specific Solution Directory, or if the TDI Install directory is the Solution directory. You can refer to the contents of the <TDI_Install>/bin/defaultSolDir.bat to determine the default Solution directory.

The TDI Component as a Client section in the TDI Infocenter discusses the importation of a certificate.
Here's an example of the command to import the google certificate into the testadmin.jks file.

<TDI>/jvm/jre/bin/keytool -import -trustcacerts -file google.der -keystore testadmin.jks -storepass administrator -alias googleCert

Passing Initialization Parameters via tdisrvctl

2011-11-17T10:44:00.001-06:00

I found the following process to work if you want to pass initialization parameters to a connector, via the command line.

For further details on parameters used for the 'tdisrvctl' command, refer to the docs.
Due to an APAR with the 'tdisrvctl' utiltity, you will need to be at TDIv7.1 FP0006 for the '-alop' parameter to parse correctly.

1. Use the 'op-entry' object in the connector's configuration to access the passed in value.
All initialization attributes are to be prefixed with $init

2. When calling the 'tdisrvclt' utility, use the '-alop' parameter to pass the value pairs to the server.
You can refer to the documentation link above for further details about this parameter.

Syntax:
bin\tdisrvctl -p 1099 -K serverapi\testadmin.jks
-P administrator -T testserver.jks -W server -op start -c config.xml -r SampleAL -alop $initialize {parameter:value;parameter:value}

Windows Exmaple:
\bin\tdisrvctl -p 1099 -K serverapi\testadmin.jks -P administrator -T testserver.jks -W server -op start -c config.xml -r SampleAL-alop $initialize {$init.oraId:oradmin;$init.oraPwd:abc123}

Linux Example:
./bin/tdisrvctl -p 1099 -K serverapi/testadmin.jks -P administrator -T testserver.jks -W server -op start -c config.xml -r SampleAL -alop \$initialize '{$init.oraId:oradmin;$init.oraPwd:abc123}'

------
Passing Initialization Parameters to the startAL() method via the tdisrvctl utility:
Here's a simple AL with the following in the AL Prolog.

//------------------------------------------------//
var stats;
var error;
var num;
var adds;
var result;

var OpEntry = task.getOpEntry();
var tcb = system.newTCB();

tcb.setConnectorParameter ( "JDBCconnector", "jdbcLogin", OpEntry.getString("$init.oraId"));
tcb.setConnectorParameter ( "JDBCconnector", "jdbcPassword", OpEntry.getString("$init.oraPwd"));

task.logmsg("**** Check Emp Status ******");
var check = main.startAL("AL1",tcb);
check.join();
result = check.getResult();
stats = task.getStats();
error=stats.getError();
num=stats.numErrors();

if (num == 0 ){
task.logmsg("**** Running Emp Update ******");
var empUpdate = main.startAL("AL2",tcb);
empUpdate.join();
result = empUpdate.getResult();
stats = task.getStats();
error=stats.getError();
num=stats.numErrors();
adds=stats.numAdd();

task.logmsg("stats are: "+stats);
task.logmsg("error is "+error);
task.logmsg("numerrors is "+num);
task.logmsg("**** Run complete ******");
}else{
task.logmsg("**** Run ended ******");
task.exit
}
//------------------------------------------------//

Commandline Command:

bin\tdisrvctl -p 1099 -K serverapi\testadmin.jks
-P administrator -T testserver.jks -W server -op start -c config.xml -r SampleAL -alop $initialize {parameter:value;parameter:value}

TDI - detect changes (delta)

2011-11-09T09:52:00.000-06:00

TDI - detect changes (delta) - YouTube:

'via Blog this'

Solution Portability

2011-09-19T15:58:00.001-05:00

In addition to a great post by Eddie at http://tdiingoutloud.blogspot.com/2011/02/portable-solutions.html

Here's an additional option of making a solution easily portable/testable between QA, Dev, and Production environments.

When developing within the TDI Config Editor we want to make the most of the flexibility provided in Eclipse. In this example we want to create a Property store for each environment which you'll be testing your Assemblyline against.

Here's an example of my Property Stores:

-- Script References:

When referencing an property from a Property Store...reference the Property Name only.
Not the Property Store Name. With out declaring the Property Store Name, the TDI Server will pull the value from the Default Property Store. Use setParam(string), not setParam(String,String) when referencing the property.

-- 'Use Property' Reference:

When setting the value of a Connector's Field, there's many different ways to do this.
I believe the easiest approach is the 'Use Property' option.

When using the 'Use Property' option of a Field definition you'll see it automatically adds the Property Store Name to the Property Name. This occurs when you select the property from your available properties.

By removing the Property Store Name (in the above example it would be 'Customer_Test:') the server will pull the Property Name from the Default Property Store.

-- Setting the Default Property Store
Now that we've set the solution to read the values from the Default Property Store, and not a particular Property Store we can easily and quickly redirect the direction of an AL just by selecting which Property Store we indicate as the Default Property Store.

To set the Default Property Store, just right click any of your Property Stores and select 'Default Property Store'.

On your next AL execution, the AL will read all it's property values from this particular Property Store.

-- Required Environment:

TDIv7.1.0.4

TDIv7.0.0.7

TDI Sandboxing

2011-08-15T15:12:00.000-05:00

I've been looking over the use of the Sandbox feature.

It's been around for sometime, although I'm not aware of many people using it.

Here's some scenarios of use:

Someone encounters a problem while developing an assemblyline in a closed environment. They need your help in debugging the Assemblyline, although aren't able to give you network access to the backend systems which the connectors are communicating with.
You have a resource which isn't always available on the network.
You want to debug the Assemblyline without having to connect to the Company's network, while at home in the evening.

By using the Sandbox feature included with the TDI Config Editor, we're able to create a repository of the sources which the Assemblyline interacts with. With the Sandbox and the Assemblyline, you can run the solution in another TDI CE & Server and debug the Assemblyline without the connectivity to the backend sources.

To Sandbox an Assemblyline, do the following:

NOTE: The Sandbox facility is not supported in AssemblyLines containing a Connector in Server mode, or an Iterator Connector with Delta enabled. The server will abort the running of the AssemblyLine if this is discovered.

Setup:

Define which resources you want captured in the Sandbox

The 'Database' name, used to store the Sandbox, will be the name of the directory created in the Solution directory. In this panel we also define which resources we want available to Record and to Playback.

Record Mode:

On the first initial run, you will have the Assemblyline in Record Mode.

This is done in the 'Specify Run Option' panel.

You'll see the following statement on the 'Record' run of the Assemblyline.

CTGDIS256I AssemblyLine AssemblyLines/'AL_Name' is started, recording to: 'Sandbox_Database_Name'.
You'll see the 'Database name' defined in the 'Sandbox Settings' panel appear as a directory in the Solution Directory.

Playback Mode:

Now set the Run Mode of the Assemblyline to 'Playback'.

Instead of the Assemblyline accessing the Active Directory as defined in the connector...the connector is simulated during playback.

The Active Directory system could be offline..or on a closed network....It just doesn't matter anymore..now we have a copy of the source and we can test this Assemblyline in any environment we want.

When the Assemblyline starts, you'll see the following line at the beginning of the ibmdi.log file.

CTGDIS257I AssemblyLine AssemblyLines/'AL_Name' is started, playing back from: 'Sandbox_Database_Name'.

Portability of the Sandbox:

As on of the benefits of the Sandbox, you're able to hand a few resources to another person and they're be able to run the Assemblyline without any of the backend resources/repositories. To move the Sandbox, you need to

Place a copy of the 'Sandbox' directory into the 'Solution_directory' on the other machine.
Import a copy of the TDI Eclipse Project or TDI Config XML into the other machine.

FYI: The table/view created in the Derby database held in the Sandbox directory is tied to the name of the Assemblyline. I discovered this when renaming an Assemblyline. So don't rename the Assemblyline, unless you want to dig into the database and do some modifications.

CTGDIS084I Initialization of ActiveDirectoryChangeDetectionConnector failed: java.lang.Exception: [ActiveDirectoryChangeDetectionConnector] CTGDIS025E Exception while loading configuration: java.lang.RuntimeException: CTGDIS593E Internal IDI proxy object exception: Table/View 'ASSEMBLYLINES_AD_DOMINOA_ACTIVEDIRECTORYCHANGEDETECTIONCONNECTOR' does not exist. ..

Syncing UserPhoto to jpegPhoto

2011-08-08T14:24:00.000-05:00

A situation occurred when a customer wanted to know how they could pull a Domino RichText 'UserPhoto' field from Domino (names.nsf)...and sync that object to the 'jpegPhoto' attribute in the Domino Directory.

The main work here comes to convert from the RichText object to the byte stream we need for the jpegPhoto. In the example we did the conversation in an AttMap.

The AttMap had the following code to convert the UserPhoto object.

var someobj = work.getObject("UserPhoto");

if (someobj!=null) {

var objs = someobj.getEmbeddedObjects();

if ((objs != null) && (objs.size() > 0))

{

var em = objs.firstElement();

var fin=em.getInputStream();

var bytes = new byte[em.getFileSize()];

fin.read(bytes);

work.setAttribute( "jpegPhoto", bytes );

em.recycle();

}else{

task.logmsg("## NO UserPhoto for user: " +work.ShortName)

system.exitFlow()

}

Misunderstanding of Initial DeltaStore Load

2011-08-04T11:43:00.000-05:00

While working with a colleague we found the initial load of the DeltaStore to behave different then I initially expected.

On the initial load of the DeltaStore, if an skipEntry() occurs in the flow of the Entry it was my impression that the Entry would be ignored when the commit process to the DeltaStore occurred. I found I was wrong.

The skipEntry() method only makes the processing of data move to the next Entry. So even though the Entry is skipped, the note of the Entry is made on each successful read of the Entry. The sequence ID will be committed as defined in the Delta configuration(After every db operation, On end of AL cycle, On Connector Close, no autocommit).

For those entries where we do skipEntry() and do NOT want the Entry recorded in the DeltaStore, then a rollback of the sequence ID will need to be performed before the skipEntry() call.

A simple test iterated 2 entries...

The first entry was null and was recorded to the DeltaStore. The second iteration is notnull and expected to be skipped. Without the .rollbackDeltaState() the entry would still be recorded in the DeltaStore.

if (done1 == null)

{

done1 = "notnull";

thisConnector.rollbackDeltaState();

system.skipEntry();

}

Server API inaccessible on SUSE

2011-04-14T16:52:00.000-05:00

Through the process of working with TDI v7.1.0.3 and SUSE 10 today, I found that I had to enable the api.remote.bind.address= in the TDI's Solution.properties file.

By default the parameter is commented out. When commented out, the TDI CE wasn't able to connect to the TDI Server running on the SUSE 10 server.

Behavior seen between TDI and Domino

2010-11-11T22:43:00.000-06:00

These's have been a few of the error messages I've come across using the Domino User Connector.

Error: CTGDKC065E Unable to execute Domino Action. NotesException occurred: ID=4,005, Error Text=Notes error: You are not allowed to update the certifier log (Smith)

Cause: 'REG_RegistrationServer' value is wrong

Error: CTGDKC065E Unable to execute Domino Action. NotesException occurred: ID=4,000, Error Text=Notes error: The prompt for password was aborted by user

Cause: 'REG_CertPassword' value is wrong

Error: CTGDKC002E Failed to execute the command. NotesException occurred: Notes error: Unable to find path to server. Check that your network connection is working. If you have a working connection, go to Preferences - Notes Ports and click Trace to discover where it breaks down. (adtdi/ibm!!mail\msmith.nsf)

Cause: 'REG_Server' value is wrong

Derby Access Denied Error - TDIv7.x

2010-11-04T11:54:00.001-05:00

Solution:

1. Stop ALL running processes of the Derby instance associated with TDI. By default this instance runs on port 1527

ps -ef | grep 1527

kill -9

2. Locate the Directory Path specified in the 'com.ibm.di.store.database' parameter found in the solution.properties file.

Example: com.ibm.di.store.database=jdbc:derby://localhost:1527//opt/IBM/TDI/V7.1/TDISysStore;create=true

3. Modify the 'derby.properties' file found in the [TDI_InstallDir]/etc & [TDI_SolutionDir]/etc

Add the following parameter to the files.

derby.system.home=

Example: derby.system.home=/opt/IBM/TDI/V7.1

Can TDIv7.1 be Installed on Ubuntu?

2010-11-03T12:51:00.001-05:00

I've recently come accross colleagues looking to install IBM Tivoli Directory Integrator v7.1 on Ubuntu. Ubuntu isn't in the list of supported platforms for this product, although I believe we should be able to make this work.

TDI v7.0 - Ubuntu 9.05

As a reference, here's my past experience with TDIv7.0 and Ubuntu 9.10

I started with a fresh installation of Ubuntu 9.10 with the latest patches.

1.) Log on as a normal user.

2.) Install the libstdc++5 dependency by running the following from a command prompt:

sudo dpkg -i libstdc++5_3.3.6-17ubuntu1_i386.deb

3.) Launch the TDI installer as the current user. Do not use sudo:

./install_tdiv71_linux_x86.bin

4.) Install to some location within the current users home directory such as /home/jamie/opt/IBM/TDI/V7.1

5.) Keep all other options as default in the installer.

6.) Fix the known issue with GTK by modifying ibmditk (Found in /home/jamie/opt/IBM/TDI/V7.1 on my system) and modify it as follows:

# CMDFINDER holds the command which is used to find other commands

# depending on the platform.

CMDFINDER=which

export GDK_NATIVE_WINDOWS=1

UNAME_OS=`uname`

7.) Launch ibmditk and as the currently logged in user without using sudo and it should run fine.

TDI v7.1 - Ubuntu 10.10

1. I have a fresh copy of Ubuntu 10.10

2. Check to make sure Ubuntu has the latest patches applied.

3. Have to install an old library -- The original libstdc++5 package is no longer available with the Ubuntu 9.10 or 10.x repos. So for 32 bit system you would have to get it from Jaunty Repository.

a. Add the repository

`deb http://cz.archive.ubuntu.com/ubuntu jaunty main universe` to the Repository list in Synaptic Package Manager.

b. At a terminal window run 'sudo apt-get install libstdc++5'

Note: If this package is not installed. The 'ibmdisrv -d' command will receive the following error in the ibmdi.log

"CTGDIS958E The system cannot find an enrolled product license."

If you've hit this error, you'll need to uninstall TDI, install the libstdc++5, then reinstall TDI.

c. You also need to run the following command, to rebuild the cache in order for the installer to find the library.

/sbin/ldconfig -v

4. Launch the TDI Installer (linux_x86/install_tdiv71_linux_x86.bin) as the current user. I am not installing with sudo. This installation is being done as a non-root user.

a. I selected a directory under my home directory for the install location.

b. I selected the Typical Install Set, whether then Custom

c. Pre-Installation Summary appeared.

d. The install completed successfully.