Pages

Sunday, June 14, 2009

The Migration Story : Migrating from Websphere Portal 5.1 to 6.1 Part 3

Click here for part 2

After testing the migrated portal to 5.1, we're ready now to migrate to 6.1. Since the servers are located in different environment, I have to dump the 5.1 and then import it to the 6.1 server.

First of all, do the following first BEFORE migrating :

  1. Install Portal 6.1.0.1
  2. Enable your security to the same backend LDAP of which your previous server is authenticating. If it's a different LDAP, make sure that the LDAP branches (usersand groups) are the same as your previous LDAP.
  3. Install your target database server.
  4. Do the database transfer.
  5. Install the following fixes on your 5.1 environment : PK27753 PK28148 PK29999 PK30718 PK31425 PK32194 PK32211 PK32556 PK32626 PK34624 PK39530 PK42729 PK44723 PK47799 PK48653 PK53001 PK62044 PK63553 PK64160 PK40171
  6. If there's any RSS Portlet for 5.1, update it with the latest version.
  7. If portal 5.1 has deleted pages, ensure that you use the deleted cleanup service. Check the information center.
  8. If you have deleted users or groups, Deregister the users and group. Follow the procedures in Websphere Portal 5.1information center.
  9. stop and start your portal 5.1 to test.
  10. Considering that you have installed an HTTP Server, kindly change back the WpsHostPort to port 9081 instead of 80.
  11. Edit the file soap.clients.props and change the settings of com.ibm.SOAP.requestTimeout to a higher number than 180. (Suggests is to increase to 1800).
  12. Run WPmigrate with the portal-pre-upgrade task on Websphere Portal 5.1 from the CD_root/migration/portal_migration directory on the WebSphere Application Server Network Deployment Version 6.1 Supplements CD. This CD comes with WebSphere Portal and can be used on either Windows or UNIX. Run by executing below :

    WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword -DGroupExport="true"

    Where :

    backupDirectory - The directory where data from the earlier server will be stored for subsequent use with the portal-post-upgrade task. If this directory does not exist, the portal-pre-upgrade task creates it. For example, if you specify mybackup, the migration task stores the data under the mybackup directory.

    currentPortalDirectory - The directory where the earlier portal server is installed.

    currentPortalAdminId - The administrator ID for the earlier portal server. This value is not required if it is already specified in the wpconfig.properties file on the earlier portal server.

    currentPortalAdminPwd - The administrator password for the earlier portal server.

    DbPassword - The DBMS user password for the earlier portal server. Specify this property value in the command line only if the property is not already specified as follows :

    In WebSphere Portal V5.1.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, or 5.1.0.5, the property value is specified in the wpconfig.properties file, next to the property name DbPassword.

    In WebSphere Portal V6.0.1.1 or later, the property value is specified in the wpconfig_dbdomain.properties file, next to the property name release.DbPassword.

    All other database properties must be specified in the properties file.

    GroupExport - This is optional. On my part, since it's integrated with LDAP, I didn't need to export the group. No errors occurred. This exports groups from the earlier version when the value is set to true. This property is set by default to false.

  13. Once run, check the allout.xml file to see the results.
If an Out of Memory condition occurs during the export process, see Technote 1299190 for additional instructions.

That's it for exporting. Next will be importing to the 6.1 environment

Saturday, June 6, 2009

Google Wave. A true unified communications model ?

This is what I call a true Unified Communications Model. For me, a unified communications model allows someone using an email to respond to a message triggered from an I.M., while another party to the conversation also received the same message from a social networking site. This is what is supposed to be called a Unified Communications Model.

Apparently, most of the U.C. solutions in the market now are half-baked, and is geered towards telecommunications and I.M. only. Given that, I have yet to see a solution which integrates I.M. communication with an email communication, other than the S.S.O, which actually just gives us presence awareness and nothing else. Some vendors are even guilty of calling their produce U.C. when in-fact, it only offers chat and Telephony and given that, there's not even a single integration between the two functionality. Some are guilty of providing everything that a communication platform can offer yet there's no single integration between them.

Anyway, here's the video of what Google Wave can offer and tell me if this is not truly a unified communications model. I, for one, particularly wanted to see how this will integrate with audio and video.


Configuring a new folder as a common shared library to deploy your shared libraries instead of using PortalServer/Shared or PortalServer/config

Article from : Websphere Portal Wiki by yours truly.


If you are a developer on a company who has a strong development process in-place, you are normally asked to deploy the shared jar files on the PortalServer/shared or PortalServer/config directory. You may have wondered, if you can actually deploy your jar files and property files in a separate folder(s) instead of those above given directory. The answer is YES. Though, this is not documented anywhere I believe.

While on the course of the portal migration project, I encountered all custom portlets to have 3 shared libraries configured on each of them. The funny thing is that all of the shared libraries configured are the same for all of the portlets. This is actually a headache for me during migration as there are more than 100 portlets deployed and I don't expect myself to configure them one by one. So, what I did was to configure 3 new shared libraries BUT configure my Portal Server to see this Shared Libraries, rather than deploying my libraries under PortalServer/shared or PortalServer/Config. I didn't deploy the shared library on the PortalServer/shared or PortalServer/config folder as what IBM manuals normally says.

But instead, this JAR files are stored on a different directory, but whenever Portal loads, it knows that this jar files are to be loaded as shared library that is to be shared by all portlets. How ? Follow the below instructions. Note that this instruction is for WAS 6.1, but the same can be found on 5.1 and 6.0 though in a different way of doing it.

  1.  Logon to the Websphere Application Server console.
  2. Go to Environment -> Shared Libraries
  3. Create your own Shared Library. Add the classpath pointing to your JAR files.
  4. Apply and save this configuration.
  5. Now, this is the fun part. Go to Servers -> Application Servers -> Websphere_Portal -> Java and Process Management -> ClassLoader.
  6. Class loader may vary but it should only contain one link. Click on that class loader.
  7. Click on the Shared Library References
  8. You will notice all the shared libraries that are used by Websphere Portal. Click on Add.
  9. Add your shared library.
  10. Save and restart Websphere Portal.
  11. Enjoy!!!