Kevin Griffith on building solutions with IBM software
I'm starting this blog to share my experiences with the implementations of IBM software that I participate in at the numerous customers that I see. I get involved with a lot of portal projects which often lead to integrations with other software, from IBM or other editors. In addition to portal, recently I've been involved with Lotus Quickr, Lotus Connections, WebSphere Commerce, Process Server and Omnifind from IBM. Others software that I've worked wih on portal integrations: Siebel, SAP, Oracle.
So as I go forward on the different projects I thought it would be valuable to document what I come across: both the good and the bad, whether it be cool new features and integrations, or challenges that come up as they always do. No two projects are ever the same and each come with unexpected surprises.
kevinG 270001Y61H 402 Visits
This week I'm doing an OmniFind Enterprise Edition install and integration into a portal. OmniFind will have crawlers to search WCM, the file system, Lotus Quickr, and Lotus Connections. I will do an integration into portal using the supplied OmniFind portlet.
First a few comments about the install. I have the latest version of OmniFind, 8.5 for a 32bit Windows Server 2003 OS.
The install program will install both WebSphere Application Server and IBM HTTP Server if not already installed on the OS. I got the binaries together and started the install on an empty VM image. The latest fixpack of OmniFind allows you to install on WAS 7.0. The other WebSphere components in the environment are at 6.1 level so to stay consistent I used the same WAS ND 6.1 binaries that came with portal.
Trying to install with WAS ND turned out to be a poor choice. At least this is what I concluded after the install programs (WAS, OmniFind, IHS) finished. The Enterprise Search applications did not start correctly. I did some debugging actions to see what may be the problem: deleting the profile, re-running the install, etc. I rechecked the pre-reqs and saw that the WAS Base edition is what should be used. I'm guessing that it should be possible to make it work with an ND eventually, but thought it would take less time just to uninstall everything and start fresh with a WAS Base version. So that's what I did and everything went smoothly.
Next step was applying the fixpacks. Usually fixpacks are cumulative, but for some reason the instructions say to first install fixpack 1, and then fixpack 4. It goes rather quickly: less than an hour. After the restart, all components were functionning correctly: the http server, the WAS and the OmniFind applications were all up and running.
The next step was to configure a collection and a localhost file system crawler. This went well with no surprises. The crawler crawled, the parser parsed, the indexer indexed and the sample search application returned documents for my search queries.
The next step was configuration of Quickr, WCM, and Connections crawlers. To be continued in my next post.
This post continues the report on the Omnifind install.
I configured WAS security with a Domino LDAP and imported a LTPA key generated from the WAS where portal runs.
This customer needs to search WCM, Quickr, Connections, and the file system. I created one collection containing the WCM, Quickr, and file system crawlers. Configuring the Connections 2.5 crawler will have to wait for the release of an upcoming Omnifind fixpack 5.
To get the WCM crawler to work with Portal Server the ESPACServer application needs to be installed on the Portal Server. To do this, a script that is supplied by Omnifind needs to be run on the portal server. This is a portal server cluster so on each node there is a script that copies resources, then another script that installs and configures the ESSearchPortlet.ear and the ESPACServer.ear applications. Jars that are put in place: es.search.provider.jar, es.security.jar, esapi.jar, ESPortalUtils.jar. The web server plug-in is also updated. All of this is described in the OmniFind infocenter.
The portal search center also needs to be configured. I created a new portal search service and configured it with the host name of the search server, the admin userid/password, and SSO cookie name. See infocenter for the procedure.
To use the standard portal search bar that is in the theme header there is a detailed description in the Omnifind infocenter of what needs to be done. Basically, you replace the standard banner_searchControl.jspf in your theme with the code that is given in the infocenter. Our theme at this customer does not use the standard IBM search bar and control so I had to adapt our search form using the infocenter code as a guide. The important part is making sure the search form action and text input name are correct so that the new omnifind/portalSearchBar.jsp (which was also installed by the script mentioned earlier) is called and receives the search parameter. The jsp passes the parameter to the Omnifind portlet and triggers the search. The user can then enter a search text in the theme’s search bar from anywhere in the portal, click the search button and have the results displayed in the Omnifind portlet.
The next step is to configure the portlet to meet the customer’s requirements: both graphical and functional. There are many configuration parameters available in the portlet to do this. For example, there is a config parameter to identify the WCM fields that are to be displayed in the search results. There are many GUI parameters available to configure as well.
The Omnifind portlet can be customized in several ways:
Portlet configuration parameters
The Top Results section of the portlet was deactivated with these parameters. Also the value of the parameter having the standard background image was deleted.
The portlet has a resource bundle with labels. Some of these labels were changed.
The JSP that displays the list of results (searchResultsTable.jsp) was modified to launch a DOJO dialog when the user clicks on a search result.
Here is the script:
This post continues with the Omnifind install and configuration.
The customer needs to search Quickr and WCM content. There is one collection having each type of crawler.
I had some problems configuring WCM search. When the collections had both pre and post filtering security activated there were no WCM results displayed. This was traced to a problem with the Distinguished Names of WCM objects in the collection. During the course of the project the LDAP structure evolved. I used the WCM member fixer tool to update the DNs and this corrected the problem.
Another minor issue occurred concerning the use of disk space. I had the delta build indexer scheduled to run every night while the main build indexer was not scheduled. Eventually data in the delta index directory filled up the available disk space. The solution is to regularly run the main build indexer. When it runs it initializes the delta index directory, deleting old files and freeing up disk space.
IBM support helped identify and correct both these issues.
I'm currently working on a project that is deploying a portal (LifeRay), Quickr 8.2, Connections 2.5, Sametime 8.5, iNotes 8.5 as the main components. My part is the install and integration of Sametime. The install consists of a pre-production environment, and a production environment spread over two geographies: Europe and Asia Pacific.
The pre-production environment has a ST Community server, a ST Proxy server, a ST Media Manager server, and a ST Gateway server. The ST Meeting server is not required.
In the production environment, for each geography (Europe and Asia Pacific), there is a cluster of 2 ST Community servers, a cluster of 2 ST Proxy servers, a ST Media Manager, and a ST Gateway.
The ST System Console that will manage the servers is installed in Europe.
The challenges we've seen so far have been related to the network. I will write up a separate post once we have some networking issues worked out.
To follow-up on the previous post about Sametime install, I went back thru my notes.
We set up a WebSphere cluster with 2 ST Proxy servers in Europe and 2 ST Proxy servers in Asia Pacific. The ST Console was installed in Europe. We wanted to manage servers from one single ST Console.
When we started the members of the cluster we saw errors in the log saying the members in AP failed to join or establish a view with the dmgr in Europe. After analysis and testing we concluded that network delays between geographies were the cause. To get around this we deactivated the HA Manager. Doing this had the side-effect of losing session failover because session tokens where no longer replicated between cluster members. When a user is sent to another server they get a message saying the session had expired. By activating sticky sessions with the load balancer we were able to keep the user on the same server, so under normal operating conditions sessions are not lost. In cases where a server goes down, there is still a loss of session when the user is switched to another server, but this is a rare occurence fortunately.
A better ST deployment architecture across distant geographies would be to set up a separate cluster in each geography. It is possible to have a single ST Console govern servers that are not in the same cluster. In our case this means having a cluster in Europe with the dmgr, the ST Console, and 2 ST Proxy servers. And in AP, set up a cluster with a dmgr, but without a ST Console, plus the 2 ST proxy servers. These servers would be registered with the ST Console in Europe. This allows managing policies from one ST Console.
My current project involves setting up WAS 8 environments for the enterprise. Multiple environments need to be installed: training, qualification, integration, pre-prod, prod with many application servers in each environment. Eventually there will probably be hundreds of application servers installed. Servers must be physically located at several geographic locations.
The install is scripted so that the basic installations will be identical. In the diagram below you see the components.
An install proceeds as follows:
I'm on a Websphere Portal migration from v126.96.36.199 to v188.8.131.52. I'm starting with the pre-prod cluster which has 2 nodes. New VMs are being used for v7 nodes.
I installed WAS/Portal, IHS, and the plugin without any problems on each of the nodes. Following the infocenter guide I used defaults.isBinaryInstall="true" parameter to install only the binary code. With this option no profiles are created during the install process. Profiles and nodes are created later using manageprofiles as part of the migration prodecure of each node, using WAS 7 migration tools.
I installed WAS fixpack 19 and portal fixpack 184.108.40.206. The pre-requisites say that WAS FP 13 is the minimum required for portal 220.127.116.11. I went ahead and installed WAS FP 19 to take advantage of the latest fixes.
The deployment manager migration went ok using the WASPreUpgrade and WASPostUpgrade tools.
The primary and secondary nodes ran into a problem on the WASPostUpgrade task, with the following error thrown
After doing a quick forum & web search to see if this is a known problem and if there is a workaround, I found that the source portal needs to be at 18.104.22.168 level.
Here is the technote : http://www-304.ibm.com/support/docview.wss?uid=swg21497724
kevinG 270001Y61H 265 Visits
A secure file resource adapter is needed to consolidate file serving and centralize access for WebSphere deployed applications.
Useful references for developing a RA according to JCA 1.5 specification:
A useful example for JCA 1.6: Building, Packaging,Deploying and Running the Resource Adapter Example.
Based on above examples a secure file RA is being developed which uses the JCIFS client library to implement secure access to a file server via SMB protocol.
At the moment, I'm going thru unit testing, then I'll but an application on the bench and do some load testing to make sure connections are handled properly.
kevinG 270001Y61H 197 Visits
I'm working on a project to improve deployment processes using Deployit from XebiaLabs.
The customer has several objectives:
I will add more detailed posts concerning the different aspects of the project, the extensions and plugins that are required, the integration with existing tooling etc.
kevinG 270001Y61H 253 Visits
Deployit servers are installed on Windows 2008 servers along with ALM5 agents.
Packages (DAR files) are imported into Deployit from a file server. Packages are either generated by ALM5 or constituted from package templates.
Deployit uses an Oracle database.
The Deployit repository between the two server rooms is synchronized via Windows DFS-R.
During maintenance of the primary Deployit server, the F5 Load Balancer configuration is switched to redirect traffic to the alternate server.
Various types of resources are deployed to target servers (Windows or Unix): JEE applications and configurations, SQL to databases, files, web server configurations, etc.
The Deployit servers are configured with Active Directory as the LDAP server (not shown on this diagram).