WebSphere Portal

These are the articles I really like. Just enough sample code and lots of configuration completely and extensively documented to the last custom property that is needed (with screenshots).

Resource Environment Providers are very useful. It's a good help in configuring your application, for one reason because it's more dynamic than using deployment descriptors. Oh, just read the introduction of the article. I wanted to use one myself and then I came across this article. And yes, I made one, my very own Resource Environment Provider, well, I almost completely copied the example with the names changed to protect... All worked quite well, but when you look at the code in the article, there are two things that you might notice to be a bit strange.

First of all, the sample ConfigFactory in listing 1 only generates one static Config object. It fills it, and reuses that same object every time the function is called. Some sort of smart caching eh? I'm sure that reading those attributes must take forever. But not likely. So I changed that to create a new object each time the function is called.

Secondly, you might notice that there is something strange going on with the value of the custom property. It's casted to a String in the ConfigFactory, but the Config object stores it as an Object and also returns it as an Object. And as you can see further on in figure 18, a custom property can be of a couple of types (like string, integer etc). So why do we need to cast? It only seems to limit the possibilities, because obviously it can also return other objects. So I changed that too.

What you would expect now is that you can use any type of custom property and if you change them those changes are immediately reflected in your application. Right? Maybe I should send the author of the article my improved code.

But what makes life interesting is that things are not always what you expect them to be. Very often sample code is just the only way it can work. When I used my resource environment provider I had to restart the application before I could see the changes I made to the custom properties. Before that, it just returns the old values. And when you set a custom property to type Integer, it still returns a String object with that value. Actually it always returns strings, so I can't see any need for that type field...

Also, if you have any of those field names contain the word 'password', it becomes a password and WebSphere encrypts it. If you try to get those properties they will look something like this: {xor}LDo8LTor. I found out can decrypt those with this function:

com.ibm.ws.security.util.PasswordUtil.decode("{xor}LDo8LTor")

The resource environment providers are very flexible object factories. I think there are a lot of uses for them other than just return those custom properties. But I will stick to this one for now.

For something I was working on I needed to replace URLs in a body of text. I wanted to do that in a JSP so I used a BodyTagSupport for that. The text contained URLs in the form of "/uniqueName", in which uniqueName is the unique name of a content node. I had to create a portal url to a node for each of those unique names. Of course I used Java's powerful regular expression routines to replace them (very useful if you know how they work). And for creating the URLs I could have settled with just the CreateUrlCommand, but I gave it an extra touch by adding a title attribute to the <a> element containing the title of the content node the URL is pointing to. Nice huh? I think you should always give the stuff you make an extra touch. Anyway, here's the code!

Continue reading "Portal URLs and a regular expression"

Where will this end? Looking at SystemOut.log for any problems after the installation of the WebSphere Portal 6.0.0.1 fix pack, there were some exceptions I could easily fix. Let's start with those.

The first one was CWLAG0450W, which I could safely ignore.

The second problem was a bit more tough. IBM named them CWSIV0954E and CWSIP0301E which both relate to the Workflow application. I have been struggling with the process server some time ago, and it didn't surprise me at all that it causes problems now that I finally start to use it. The problem seemed to be a simple authentication issue. The easy solution to that is to disable global security, but I won't settle for that.

The thing that doesn't work is a SCA module. You can find those under the menu item Applications in the WebSphere Administrative Console. In my configuration there was only one, the workflow stuff. To make it work you need to go to JAAS Configuration at the Global Security page of the Admin Console and select J2C Authentication data. There you'll find the SCA_Auth_Alias, and you have to provide a name and password with sufficient rights. I used wasadmin and his password.

The third thing portal started complaining about was that it couldn't find DefaultUserCalendarHome in the JNDI (javax.naming.NameNotFoundException). This involves nothing more than installing SchedulerCalendars.ear from the <WAS>/installableApps directory. You can do that from the admin console. During step 2 make sure the Calendars module maps to WebSphere_Portal. Leave everything as default (you'll notice that it picks com/ibm/websphere/scheduler/calendar/DefaultUserCalendarHome as its default JDNI name). Click finish and check if the application has started.

At this point I really felt like I was installing way too many things to make this work in a simple development environment. Was I on the correct path? Especially now the whole setup is beginning to need loads of cpu power.

Moving forward and trying to actually use the workflow I quickly ran into this one:

java.lang.IncompatibleClassChangeError:
class com.ibm.task.core.CallContextImpl does not implement interface com.ibm.task.core.CallContext.

Ok, that's it. That expection sounds like really freaked out installation. Maybe I did something wrong somewhere. Luckily I documented every single step. Maybe I'll start over or maybe I'll have a go with classfinder to get to the root of this.

Two weeks ago I did an upgrade of WPS 6 on Solaris to 6.0.0.1 at work. And now I'll apply this fixpack on my linux box. I use Kubuntu edgy and earlier I documented how to install WPS 6 on ubuntu. I think that upgrades on other platforms will go the same way for the most part. Continue reading "Installing WebSphere Portal fix pack 6.0.0.1 on Ubuntu"

We're getting close. Ok, I tested it, and the things I did weren't enough. Looking into it a bit further I learned I had to do some additional stuff. In the admin console of the AppServer I saw that the business process choreographer and the human task manager were not installed. I had to run their installation wizard to manage that. I also read somewhere that you have to run this command:

ulimit -n 10240

...before going ahead, otherwise it'll stop with a 'Too many files open' exception eventually.

I did that and started server1, then started the wizard in the admin console. To get there select Servers/Application servers and select WebSphere Portal, then select Business process container settings/Business process container and then click the wizard.

On the first page, I selected Cloudscape 5.1. On the second page I selected the default messaging provider and these settings:
Queue manager: BPECF
JMS user ID: <wasadmin>
JMS password: <password>
JMS API User ID: <wasadmin>
JMS API password: <password>
Administrator security role mapping: wpsadmins
System monitor security role mapping: wpsadmins
Leave everything as it is on page 3, check the summary on page 4, and GO!

Next thing.. the human task container. Select it from the page you were before, the settings page of the WebSphere Portal application server. If you go there, you can select the wizard. Use the same settings as described above (the same settings as on the second page of the business process container wizard). Check the e-mail option on the second page, and finish.

Don't forget to save to the master configuration. If you made a mistake and want to start again, read this.

You must create the Cloudscape database and the tables yourself. After the business process container was installed, I went to <WAS>/profiles/wp_profile/databases and ran this command:

java -Djava.ext.dirs=<WAS>/cloudscape/lib -Dij.protocol=jdbc:db2j: com.ibm.db2j.tools.ij <WAS>/ProcessChoreographer/createDatabaseCloudscape.ddl
(<WAS> is the WAS installation directory)

You can find a description of this step in the createDatabaseCloudscape.ddl file itself.

Now that I'm diving a bit more into WebSphere Portal 6, I found out that the process server wasn't installed. You can check this by running versionInfo.sh and if it's not there then it's not there. And it wasn't there. And I think either I did something wrong (which I doubt of course) or something didn't go well during the install. I checked the log files again if there was anything about a failed install in there, and they didn't shed any light on this. In the end there wasn't much else to do than try to install the process server manually (or try a complete re-install of course, but I can always try that if everything fails).

In the documentation it said: “When running the WebSphere Process Server installation manually from CD *-2, users should run the install.bat or install.sh script instead of running the executable”. So for this I needed the IL-2 disk and go to the linux/ia32/WBI directory. I ran install.sh and half way I selected 'Use an existing installation of WebSphere Application Server Network Deployment, Version 6', and selected the WAS of portal.

Then this profile creation wizard popped up (after I agreed that it was ok to run it), and I didn't know exactly what to fill in. So I made a backup of the wp_profile first. Then I chose to augment the existing profile, and left all check boxes unchecked. I filled in the credentials of the WAS admin when the wizard asked for MQ credentials. That should work fine.

The wizard made the changes to the profile. I can see the process server when I run versionInfo.sh now, portal still functions and hopefully, I can use the process server from portal. I'll have to test that.

Update: part 4

Now that I have WebSphere Portal 6 running on my laptop, I can go ahead and do something with it. Unfortunately I have the problem that I don't have a proper test environment of portal 6 in RSA 7 (as do others), but I won't let that stop me. I want to build one of those composite applications that IBM is raving about. I'm going to try and create a sample application just to see what the possibilities and limitations of this new thing are. And of course I will write on this blog about my progress with it.

I'll be creating a bar application. That's right, an application for a business that sells beer, whiskey, and coffee (and maybe some sandwiches or something). It won't be useful at all when it is been created, but hopefully I will learn a lot during the making of it.

First off, I created an application template. Templates can be found right from the welcome page of portal. I saved it as 'Bar template' and by using 'Manager roles' on the template I added three roles: Customers, Bar tenders and Bar managers. Then I created a page in the template and called it 'First page', just to test, and I put three (almost at random) portlets on it. So now I could assign how users with specific roles can use those portlets. You can do that again by 'Manage roles'. I made some of the portlets accessible and not accessible to some of the roles, just to test again.

(I ran into a couple of exceptions (CLYAF0024E: Could not find key null
for CDO_CDO and CLFFC0074E: CDO ERROR: {0}. com.ibm.workplace.cdo.exception.CdoException at this point. The reason was that I logged in twice and had another browser window open to see if that link to those templates were really there on the front page. In firefox those sessions will interfer.)

Then I created three users (Jake Jackson, Mike Jackson and Steve Jackson) and I wanted to assign them to the roles in a new Bar application. Before I did that, I assigned to them user access to the application template and template category using the Resource Permissions portlet (in Administration). Then I needed an application and I created one using the Bar template (called it Jake's Bar). I clicked on it, and that took me to the 'First page'. The page has a lot of options in the drop down box, and I needed to select the 'Assign application members'. Then I could add the user I wanted as Bar manager (Jake), Bar tender (Steve) and Customer (Mike). B.t.w. for some ridiculous reason, the pop up for searching users was case-sensitive.

Well, the only thing left to do was to make sure that all the three users could access the Applications portlet as a user. After that I logged in as each of those users, put the Applications portlet on the welcome page, and saw that it all worked just as I thought it would. I think I'm getting the hang of it.

Nice thing about this is that when you make changes to the application, you can save those changes back to a template again. Quite useful when you are developing something.

Yesterday I learned that it's not possible to install WebSphere Portal 6 on a Ubuntu Edgy 6.10 box. But today I managed to get around it! I found out that the failure with the creation of the profile was due to a malfunctioning wsadmin.sh. In the logs it said that it gave a syntax error, and that's really strange, because that would mean somebody at IBM has been writing bad code.

It turns out that that is exactly the case. The people at Ubuntu have changed the default link of sh. In Ubuntu Edgy it doesn't point to bash anymore, but it points to dash. That means that code written specifically for bash doesn't run correctly anymore with the #/bin/sh prefix. IBM assumes that sh is always bash, so IBM does not follow the standards.

There are several ways to solve this, but the easiest way to do it is to change the sh link back to bash:
rm /bin/sh ; ln -s /bin/sh /bin/bash

And then install all the WebSphere stuff you want. After that you can leave it like that (shouldn't give any problems) or you can make sh point to dash again. In that case also run this:
sudo perl -p -i -e "s/\/sh$/\/bash/" /opt/IBM/WebSphere/AppServer/bin/*
sudo perl -p -i -e "s/\/sh$/\/bash/" /opt/IBM/WebSphere/PortalServer/bin/*

But then keep in mind that every time you install fixes or fixpacks, you have to have sh point to bash again during the install. And you have to change the script files again too.

Update: part 3

Yesterday seemed to me the perfect day to install IBM's new Rational Software Architect 7 on my Kubuntu Edgy laptop. Version 7 had been out for a couple of weeks (I'm not sure when it came out exactly though). The fact that I had nothing to do anyway and the prospect of a boring long christmas made me switch on IBM's very own download manager to download IBM's bloated Eclipse variant. The download of RSA 7 was larger than 5GB(!), so I was in for a long wait. It looks like they made a version that contains every single file for every single platform. Nice, I don't have to download it again when I want to put it on my Windows box.

After the wait the installation went like a breeze. No problems whatsoever. I clicked through it quickly, ran a good old WPS 5.1 server configuration, and everything seemed fine. Oh no.. and christmas hadn't even started yet! What was I to do?

Well.. Portal 6 was on the shelf too. I already installed the beta without any (installation) problems a few months ago, so I was fairly optimistic about this one. Although WPS 5.1 did give me some problems after the updrage from Dapper to Edgy, there weren't any problems with the WPS 6 beta. No LinuxThreads are necessary like in WPS 5.1. So with the assumption that everything would go well, I boldly removed portal 6 beta. I wouldn't be needing that one anymore, now would I?

I started the installation process this morning and got back to my newspaper and coffee. In the background I heard my laptop blowing hot air into the room and a quick look told me that it was busy installing the application server. The installation process of portal isn't quick, but at least you know what it is doing. You can do a tail on the log file which tells you exactly what it is doing, but I passed on that one. What on earth could possibly go wrong?

After the sudden stop of the hot air flow I quickly got to know that. The thing that goes wrong is the creation of the Portal profile on the application server. The message was this:

EJPIC0217E: The Portal profile creation step failed with WebSphere Application Server.

Right.. after trying three times with different settings it still came with that message. Changing the .WASRegistry and the vpd.properties files didn't work either. I was seriously stuck. And that's where I am now. I know that Ubuntu is not supported by IBM but that hasn't stopped me in the past. Today I will install WAS 6 that comes with the RSA installation and I'll try to put WPS on that one. Maybe that'll work.

Update: part 2