Here is a short summary of what issues I saw during my last migration from IBM Connections 4.0 to 4.5:

Activities: Name of default content store has been changed

The Activities content store in Connections 4.0 was named “filesystem”.  However, in Connections 4.5 the content store has been renamed to “filestore”. Our migration strategy was to set up a new Connections 4.5 environment and just migrate the databases from 4.0 to 4.5.  So we did not migrate the configuration files in the LotusConnections-config folder but just used the new ones. In this case you need to make sure that you rename the content store to the name of Connections 4.0. Otherwise you will not be able to retrieve files stored in Activities after migration.

If you try to do so you will see messages like that in your log files:

CLFRA0839E: The content store type : filesystem was not found. Check the configuration file (oa-config.xml) under the <objectStore> attribute to verify that it includes a valid <id> attribute and directory mapping for this store type.
CLFRA0091E: Internal error com.ibm.openactivities.exception.OpenActivitiesException: com.ibm.openactivities.objectstore.ObjectStoreException: CLFRA0547E: No default content store has been defined.

To resolve the problem, change the following lines in OA-CONFIG.XML in the LotusConnections-config folder:

Original line:

<store default=”true” class=”com.ibm.openactivities.objectstore.filesystem.ContentStore”>
<id>filestore</id>

Updated line:

<store default=”true” class=”com.ibm.openactivities.objectstore.filesystem.ContentStore”>
<id>filesystem</id>

Thanks to Klaus for documenting this in his blog.

 

Some issues with database upgrade scripts for Oracle 

We found two problems with the Oracle database scripts for migrating the data.

  1. In the script “upgrade-40-45.sql” for the Homepage database there are some statements which create an index which already exists but it does not drop them before. You will see two errors “ORA-00955: name is already used by an existing object” while running the script. So we added the following lines (marked in RED color):

    — DROP UNIQUE AND CREATE CONSTRAINT AND INDEXES
    DROP INDEX HOMEPAGE.PERSON_EXID;
    COMMIT;

    ALTER TABLE HOMEPAGE.LOGINNAME DROP CONSTRAINT LOGINNAME_UNIQUE;
    COMMIT;

    ALTER TABLE HOMEPAGE.EMD_TRANCHE DROP CONSTRAINT SEQ_NUMBER_UNIQUE;
    COMMIT;

    DROP INDEX HOMEPAGE.LOGINNAME_UNIQUE;
    COMMIT;

    DROP INDEX HOMEPAGE.SEQ_NUMBER_UNIQUE;
    COMMIT;

    CREATE UNIQUE INDEX HOMEPAGE.PERSON_EXID
    ON HOMEPAGE.PERSON (EXID,ORGANIZATION_ID) TABLESPACE “HPNTINDEXTABSPACE”;
    COMMIT;

    CREATE UNIQUE INDEX HOMEPAGE.LOGINNAME_UNIQUE
    ON HOMEPAGE.LOGINNAME (LOGINNAME, ORGANIZATION_ID) TABLESPACE “HPNTINDEXTABSPACE”;
    COMMIT;

    CREATE UNIQUE INDEX HOMEPAGE.SEQ_NUMBER_UNIQUE
    ON HOMEPAGE.EMD_TRANCHE (SEQ_NUMBER, ORGANIZATION_ID) TABLESPACE “NEWSINDEXTABSPACE”;
    COMMIT;

  2. We created a script which does run all the necessary SQL scripts by calling them via the SQLPLUS command. Unfortunately the script “clearScheduler.sql” for Profiles did not include a “QUIT” command at the end which means that SQLPLUS will not finish and the following scripts will not be executed. So just add the command “QUIT;” as the last line in that script (after the “COMMIT;” statement).
Use 32-bit Installation Manager to install Websphere Application Server and IBM Connections

Just as a reminder: You should install and use the 32-bit version of IBM Installation Manager to install Websphere Application Server and IBM Connections 4.5 although you are installing the 64-bit version of WAS. You will get a warning message during the installation of WAS (but it does work)  but you will be unable to install Connections later. You will end up with the error “The install executable launcher was unable to locate its companion shared library.”

In the case you have used the 64-bit version of IM to install WAS you can switch back to 32-bit by just reinstalling Installation MAnager with the 32 bit code and the command “install -reinstallIM”.

Use double backslashes for Windows path names in WSADMIN commands

Windows path names in WSADMIN command need to be written with double backslahes, otherwise the backslash will be ignored and a wrong path name will be used. E.g.

SearchService.startBackgroundIndex("D:\\IBM\\Connections\\data\\local\\search\\backgroundCrawl", "D:\\IBM\\Connections\\data\\local\\search\\backgroundExtracted", "D:\\IBM\\Connections\\data\\local\\search\\background\\backgroundIndex", "all_configured")

 

Tagged with:  

Leave a Reply

© 2000-2015 Michael Urspringer