Wednesday, September 28, 2016

Docs 2.0 CR1 iFix 001 - Conversion app will not update.

Has anyone had issues with upgrading Docs CR1 to the CR1 iFix1?
This is the log error:

INFO This iFix is not for your current DocsConversion version. Please double check.

DocsApp and ViewerApp is updated fine, but not the conversion App.
I have gone through the file, and managed to figure out that the script looks for the file “conversion-config.json” in the IBMDocs-Config folder on the DMGR server. (D:\IBM\WebSphere\AppServer\profiles\Dmgr01\config\cells\appsrv1Cell01\IBMDocs-config)

It looks for the string “ifix_version” with a value >=6
This is a value that does not exist in the conversion-config.json file.

So I manually edited the conversion-config.json file on the dmgr server, to include the “ifix_version” part. I set the value to 6:
It´s located under the "build-info" section and the format is:
    "ifix_version": 7, 

After I did this, the applypatch procedure worked fine, and the conversion app was upgraded sucessfully.

I now see that the upgrade process has set the value to “7”.

"build-info": {    "build_version": "",     "build_description": "IBM Connections Docs 2.0.0",     "ifix_version": 7,     "product_name": "IBM Connections Docs",     "build_timestamp": "20160824-1613"  },

The upgrade history of the server is: Docs 2.0. Then CR1 and then CR1 iFix 001.

I did not install Docs 2.0 ifix 001, 002, 003, 004, 005 first, since the CR1 package should include all of those.

Is this a bug in the upgrade process? Should the "ifix_version" string have been inserted into the conversion-config.json file in one of the previous Docs 2.0 iFix´es? 001? 002? 003?....
I don´t know. But this worked as a nice workaround.

Tuesday, September 6, 2016

Connections 5.5 Rich Text widget loops the community - a third option to fix the issue

I do not know if this is the correct way to fix the issue (changing the rteJAASAuth user). I have not verified this with IBM yet!!

When doing a migration to 5.5 CR1, there´s an issue with the Rich Text widget.

Adding the widget in a community makes the browser go into a loop of refreshing the page.

Previously, this has helped me fix the issue (thanks you guys!):

And there´s also a technote on this:

In previous migrations, the above mentioned links has worked for me. (Deleting the "conn-rte" entry in OH2P_CLIENTCFG table, located in the HOMEPAGE database, deleting the message stores and switching to a LDAP user + set "everyone" as the reader of the Websphere Application named "RichTextEditors".)

But this time, I discovered another approach that allows me to still use the local "wasadmin" user, and not an LDAP user as the ConnectionsAdmin user.

There is a JAAS - J2C Authentication data called "rteJAASAuth" which I was not aware of.
This one was just laying there with no username and password set.

So I set it to match my ConnectionsAdmin user.

I then shut down the servers, deleted the messageStores, synced the nodes and deleted "temp" and "wstemp" and then started the servers up again.

After this, I had no browser "loopage" in the Community anymore. Problem fixed!

Is this a new role introduced in CR1? Why is it not set during installation of Connections?

In my next migration, I will attempt on setting this JAAS role only, and see if this is enough for the issue to be fixed. I might end up doing all the other stuff as well... we´ll see :-)

Tuesday, August 9, 2016

IBM Connections Docs 2.0 CR1 upgrade failure. Here´s the fix.

I attempted my first Docs 2.0 CR1 upgrade today, on a fresh Docs installation.

It failed.

I got the same error as Roberto Boccadoro did as described here:

Roberto, thanks for this solution.
Although I ran into a new issue in step 4 of your solution.

I was not able to run the command:
upgrade_node.bat -installroot D:\IBM\ConnectionsDocs\Conversion -symcount 8

This is the error I got:

Traceback (most recent call last):  File "", line 5, in
    from config import CONFIG  File "D:\temp\docs_remote_installer\installer\", line 46, in
    CONFIG=Config()  File "D:\temp\docs_remote_installer\installer\", line 38, in __init__    self.get_input()  File "D:\temp\docs_remote_installer\installer\", line 17, in get_input    if(not os.path.exists(options.install_root)):  File "d:\Python27\lib\", line 18, in exists    os.stat(path)TypeError: coercing to Unicode: need string or buffer, NoneType found

I then opened up the "upgrade_node.bat" file, and I noticed that the only thing it does is run python on the "" script.

After searching the net, I noticed a comment about the fact that python does not accept arguments unless they are defined with 2 hyphens, aka "--"

So I ran this command, which has 2 hyphens on the "installroot" and the "symcount" argument.

python --installroot d:\IBM\ConnectionsDocs\Conversion --symcount 8

This worked for me and Step 4 of Robertos guide worked.

Monday, August 1, 2016

Using TDI/SDI to populate Profile Tags in IBM Connections 5.

I have created this simple AssemblyLine to automatically populate tags on profiles in IBM Connections.

This one works in IBM Connections 5.0, but haven´t tested it on version 5.5 yet.

The AL does the following:

  1. The iterator is a CSV file, with the following structure:


    For example:;tdideveloper;NominateThisGuyForChampion

    The location of the CSV file is:

  2. A JDBC connector in Lookup mode, which connects to the PEOPLEDB table named EMPINST.EMPLOYEE.

    The Link Criteria is the mailaddress from the CSV file. If this one matches with the PROF_EMAIL_LOWER field in the SQL Table, one work attribute is fetched from the table.
    This is the PROF_KEY attribute.
  3. Then a TAG_ID is generated using this random UUID4 script:
  4. Then I write 4 fields into the EMPINST.PEOPLE_TAG table in the PEOPLEDB database.

    -PROF_SOURCE_KEY (this is normally the prof_key value of the user who tags)
    -PROF_TARGET_KEY (the prof_key value of the person beeing tagged)
    -PROF_TAG_ID (the value generated in step 3 above)
    -PROF_TAG (the tag-value itself, from the CSV file)
There are 2 other fields, which are disabled in the "write_entry" connector. The fields are "PROF_TYPE" and "TENANT_KEY".
Those two fields auto-populate in the DB. This means that the AL does not have to worry about them.

This AL is easy to customize to fit your needs. Switch out the iterator with an ldap connector, perhaps? :-)


Here´s the iterator:

Here´s the side-lookup I do into the EMPLOYEE table, to fetch the PROF_KEY value:

IF branch that checks if the PROF_KEY actually was fetched:

Script where I generate the UUID4 value for the PROF_TAG_ID field:

Here´s the JDBC Connector that writes the tag to the profile.
The author of the tag is the user itself, which means that when TDI writes this tag, it says that I, myself created the tag. That´s where the field "PROF_SOURCE_KEY" and "PROF_TARGET_KEY" comes into play. The value of the fields are equal.

As you can see, the connector is in "AddOnly" mode, and not in "Update" mode. I tested it, and running the same AL on the same csv file, where all the same tags are attempted inserted once more, only produces a small error message. I had no interest in running it in "Update" mode, checking to see if the tag already exists, and tagged by the user itself. This way the user gets a tag, by him- /herself, only.

Before running the Assembly line:

After running the AL:

The Assembly Line can be downloaded here:
Import it into your Connections tdisol project and test it out :-)

Hope this was useful to you, and yes, keep me in mind when the IBM Champions nomination is due :-D

Tuesday, April 26, 2016

Kudos Boards - error message "Unable to retrieve Members"

After installing Kudos Boards, I had this error message:

I went over all the config parameters, and encountered that I had the wrong path to the "" file.

So if you get this error, check the path and correct it if it´s wrong.

The documentation says that the file should be on the path:

But my data directory lies directly on "/opt/IBM/data" so I had to correct the environment variable to: