Master Series: Interactive Dojo Dialog Form

Adam Kewley Davalenby Adam Kewley

Over the last couple of years I’ve had the need to create a Dojo Form Dialog in WEF that interacts with the end user. The dialog is expected to update itself without refreshing the entire page. By utilizing custom refresh features within WEF we can construct such a dialog that will behave more like a popup window. The sample can be downloaded here.


For this sample we had the following requirements:

  1. Create a wizard-like dialog that included multiple steps that a user could follow to complete a form.
  2. Allow the user to navigate back and forth between the steps.
  3. Use an existing dialog and avoid full page refreshes.
  4. Utilize a small framework that could be utilized in real-world applications.

We’ll first dissect the model by looking at the dialog itself. Out of the box WEF ships with a robust Dojo Form Dialog builder that automates the generation of input forms. The builder also includes OK / Cancel buttons to process such a dialog. This is suitable for a good deal of applications, but you’ll need to build your own if you wish to fully customize the dialog itself. For this reason we will instead opt to write our own Dialog in HTML. This turns out to be a pretty easy undertaking provided the developer has a basic understanding of Dojo.

The first requirement is to add a Dojo Enable builder. This builder will tell a given Page in WEF to import Dojo artifacts. The “Requires Package List” input will contain all of the dojo imports that are needed for the particular page. For the moment this input includes the dijit.Dialog feature.


The next portion is the main model page. The page1 page contains the content for the dialog and the navigational pieces. You’ll notice that the page html is split into two main sections. The main form for the model is named “mainForm”. This is where your general model or portlet content would reside. It’s important to note that the html for the dojo dialog is external to the main form. Our field experience has lead us to determine that the best location for a custom dojo dialog is outside of a form tag within a portlet. For that reason I’ve always put custom Dojo dialogs external to the main form. Each dojo dialog in a portlet or model should reside outside of the main form and include its own form if the dialog is interactive. For message dialogs you can skip the additional form.


In addition to the form there are a couple of other elements that should be noted. The DialogContent span tag is a wrapping tag that encapsulates a couple of additional span tags. This tag is targeted by the navigation buttons (back,next, finish) in the Post-Action behavior portion of the builder. More on this later..

The insertedPage tag is where the main contents for the dialog will appear. The inserted page builder is using a variable to determine which page to insert into the dialog. This variable is driven by the wizard framework in the LJO attached to the model. The dialog itself is contained within a Div wrapper with a given ID and dojoType. The next piece of our demo is the navigation framework. The framework is a collection of builders, java code and an Xml variable which handles navigation and validation within the form itself. The navigation variable contains the individual wizard steps using the following xml syntax:


This variable can be upgraded to include additional features necessary for building a more complex dialog as well. The currentStep variable within the model contains a copy of the currently selected step element that is in use. The navigation builders rely on this variable for the step instance data.

The next builder of interest is the Inserted Page builder. This builder inserts an arbitrary page into the the dialog portion of the main page. This is driven by the Page node of the currentStep variable.

Each step has an individual page, UI and datapage variable. It’s important to note that while you could probably get away with using a single xml datapage variable for all of the steps, it was far easier to divide each wizard step up into individual xml variables. This prevented us from having to use multiple datapage builders to hide the majority of the input form and only show the portions needed for a particular wizard step. At the end of the dialog process the xml variables are combined together into a target variable. The information is presented in a summary datapage for viewing.

The heart of the Dialog magic lies within the navigation builders. Smart Refresh is the default rendering behavior for WEF. This feature dynamically updates the page for you without incurring a full browser page reload. Unfortunately if we used this default feature, the dialog would close every time we processed a back / next step within the dialog. WEF provides additional mechanisms for handling the post-action behavior of html action builders (button, link, image button etc..)

We will be using the custom refresh location feature, that is provided by WEF, to get around the page refresh issue. This can be found in the Post Action Behavior section.


In the figure above you can see we are setting the post-action behavior to Refresh specified page location after running action. This tells WEF to only update a small portion of the page instead of the majority of the page. The DialogContent tag is a separate span tag that wraps the inserted page within the Dojo Dialog itself. You’ll also notice that this works cross forms. The button lies in the mainForm and the result is updating content within a separate form. The refresh specified page location option is a pretty nifty feature.

Note that the Execute Embedded Scripts checkbox is checked. If you’ve ever done any AJAX work you’ll know that any Javascript embedded within the response of an Ajax call does not automatically get executed once the page is updated. Using this checkbox we can ensure any internal javascript will get invoked appropriately. Lastly the Load Event Prefix is given a custom value for each button. Truth be told I’m not sure this is entirely needed but I’ve used it in the past to ward off random IE browser bugs. Since the back and next buttons are both targeting the same tag it couldn’t hurt.

The finish button simply utilizes the default smart refresh behavior since we may need to update the main page after exiting the dialog.

The next portion is the DojoDialogLJO class. This class contains the logic for switching dialog steps as well as handling validation and processing of inputs.

The back / next / finish buttons require additional visibility logic depending on the wizard step. This is defined in the navigational XML variable.

When running the model you’ll notice two buttons appear on the page: launch and launch reset. Both of these buttons will launch the dojo dialog, however launch reset will reset the dialog before the contents are rendered. The launch reset button includes an additional attribute setter which prepends javascript to the onclick event.


The onclick javascript performs the following steps:

  1. Hide the contents inside of the dialog. For slow dialogs this prevents the user from seeing the previous state (if one exists) before the dialog itself returns to a reset state.
  2. Displays the dialog before the request is sent to the server
  3. Sends a request to the server to reset the dialog visually and re-load step1 inside the dialog
  4. Once the request completes the non-hidden step is rendered in the dialog and shown to the user.

For simplicity sake we chose to show the dialog before the request is sent to the server. While it is possible to get the dialog to show only after the page is loaded, it takes a bit more effort and would further complicate the demo. This route was chosen for a clean and simple transition.

In demonstration you’ll notice that the dialog can navigate forward and backwards through the wizard, as well as display datapage validation errors on the first step. The navigational behavior is handled by the processStep methods within the LJO. On the summary page the separate xml variables from the datapage input forms are combined into a summary xml variable. Additional java logic is required due to how the inputs are rendered on the page.


This section includes a few notes, caveats, customization suggestions and other bits that may be useful to the end user.

#1 As mentioned before, the dialog does not need to be a multi-stepped dialog with a wizard framework. You can simply use a single button and re-process the current page if you’re looking for a simple datapage form with validation on it.

#2 If your dojo form has a lot of information or takes a while to process, you may want to consider a deferred load approach. This would involve having inserted page insert a blank page until the user clicked on the launch button to launch the UI. Not only would it allow the page to load sooner, but would cut down on the amount of html and javascript content on the page. This may help with performance issues with multiple (or large) dialogs.. especially ones in older browsers.

#3 Always keep your dojo dialogs outside of the main form for the portlet. In addition, if multiple portlets are creating multiple dialogs, consider adding a header portlet (visible or not) to the top of your page. Add the dialogs to the header portlet, and simply rely on javascript or external methods to launch the dialogs. By keeping them in a common portlet you can easily make changes on them in the future.

#4 It is possible to modify the sample so that the dialog is only shown after the request to the server is made and the content is updated on the page. This however requires temporary javascript to be executed on the page that will render the dialog. It’s a bit difficult to turn this javascript off after the dialog has been launched.

#6 It is easily possible to update the main page once the dialog closes. The finish button will re-render the main page, so any updated content should be reflected in the current page.


About the Author: Adam Kewley has been working with Web Experience Factory (WEF) for 12 years. He began his career working with the WEF development team itself. Over time he moved from software QA to Development, L3 support lead (assisting the IBM customer support team), and finally on to consulting.   Adam is currently employed at Davalen as the WEF lead.  He is a resident of southern New Hampshire.
This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth O’Keefe and request to be added to our E-Newsletter list. You can also view the Master Series Archives.

Master Series: A Developer’s Guide to Adding IBM HTTP Server (IHS) to IBM WebSphere Portal

David Wilkerson CTO

David Wilkerson

by David Wilkerson

This article will demonstrate how to install and configure the IBM HTTP server for WebSphere environments.

Portlet and portal developers will often benefit from an installation of the IBM HTTP server. They will do so to test an application or theme they have written by using a conventional HTTP server instead of the HTTP server embedded in WebSphere Application Server. One benefit of this is to evaluate the behavior of an application when various caches are implemented. Installation of the IBM HTTP Server is not complicated and this article should provide the necessary assistance to enable developers to easily succeed.

The first step is to determine what version of WebSphere Application Server is installed. This is important because installing the correct version of the IBM HTTP server depends on knowing the installed version of the WebSphere Application Server. To do this on a Windows computer you can use the IBM Installation Manager “View Installed Packages” webpage. This utility is available from the start menu by choosing Start and then locating a program group labeled IBM installation manager. Expand the program group and you will find a utility for viewing installed packages.


Launching the utility will cause an internet browser to open a file named “installed.xml”. This file will be displayed as a webpage. Scroll through the list of installed packages and locate the package group named “IBM WebSphere Application Server Network Deployment V8.0”.

Check version using IIM

On a base install of portal the version of the WebSphere Application Server installed should be Version ( This information is important. If the application server is found to be at a higher level you will need to not only install the web server but you will also need to apply patches. Fortunately, the IBM installation manager can assist in both regards.

The next step will be to locate the appropriate parts for installation of the web server. This can be done through PartnerWorld (for business partners) or Passport Advantage (for customers).

Locating the WebSphere Application Server eAssembly for the edition of WebSphere Portal you will see parts for the IBM HTTP Server.


After you have downloaded the appropriate parts, expand the compressed files into a single folder structure such that subfolders for each disk image are listed. Then in the IBM Installation Manager locate the File menu and update the preferences to reflect the repository location for disc one.

After setting the revised repository preferences, select the install option of the IBM installation manager. In the list of available packages select the checkbox for the IBM HTTP server for WebSphere Application Server, the WebSphere Plug-ins and the WebSphere customization toolbox.


After clicking next you will be presented with the page to accept the licensing of these products.


After clicking next you must select the appropriate features for the products being installed. In my example I am using a 64-bit operating system therefore I have selected the checkbox for the IBM 64-bit runtime environment for Java Version 6.


And, after clicking next, additional configuration is required. On this panel indicate the port number and the account that will be used if the IBM HTTP server is intended to run as a Windows service (there is a similar option for Linux).


After clicking next pad launching the install process the IBM installation manager will proceed with installation.  Conclusion of the installation, or at a later time, you may launch the WebSphere customization toolbox.


Once the tool has completed its launch, a list of provided tools will appear. Select the tool labeled “WebServer Plug-ins Configuration Tool”. Next, click the button labeled “Launch Selected Tool”.


A panel will display labeled “WebServer plug-in Runtime Locations”. To the right of the panel is a list of buttons. Click the button labeled “Add…”


After clicking the add button the first step in configuring the Webster plug-in will be to select the Web server type. In this example the IBM HTTP Server V8 is selected.


The next button on the panel labeled “Web Server Configuration File Selection” click the browse button and select the file HTTPD.conf also specify the Web server port. In this example the port number is port 80. Once these settings are complete, click the button labeled Next.


On the next page labeled “Setup IBM HTTP Server Administration Server” decide whether or not to setup the IBM HTTP Server Administration Server. Checking the box labeled “Setup IBM HTTP Server Administration Server” will enable remote administration of the IBM HTTP Server using the IBM WebSphere Integrated Solutions Console. If configuring the IBM HTTP server administration server, enter a port number for the administration port. In this example we have used 8008. Finally, we have enabled creation of an ID for the administration server and specified the name and password. When the decision and settings are complete, click the button labeled Next.


Indicate whether to configure the Adminstration Server as a Windows Service and with what type of account to launch the service. Also, indicate the startup type for the service.  Then, click the button labeled Next.


A Web Server Definition Name must be provided. A unique name entered into the text box will be used when later updating the WebSphere Application server console. Click the button labeled Next.


On the Configuration Scenario Selection page select the radio button for remote or local references to the WebSphere Application Server. In this example the server is remote. The directory to select in the local input should reference the application server binaries, In this example the location of the binaries is C:\IBM\WebSphere\AppServer directory.  Click the button labeled Next.


The profile selection page requires selection of the profile to which the HTTP server  will be bound. In this example we are configuring the web server for a portal deployment. The wp_profile is selected. Click the button labeled Next.


The summary page should be reviewed and, when settings are confirmed, click the button labeled Configure.


At this point configuration is complete. However some additional changes should be made to the configuration of the HTTP server. Specifically it is important to enable the rewrite module and to create at least one rewrite rule. In this example we want to rewrite incoming requests so that requests addressed to the qualified host name will be rewritten to include the portal home page, “/wps/portal”.

Locate the httpd.conf file.  In this case, the path is C:\IBM\HTTPServer\conf.

Review the file and locate the LoadModule line for the rewrite module and remove the remark character to enable the rewrite module:

LoadModule rewrite_module modules/

Now, activate the rewrite rules:

RewriteEngine on

And then enter a rule such as this on the line immediately after the statement “RewriteEngine on”:

RewriteRule ^/$ /wps/portal/home [R=301,L]

In the example rewrite rule we are filtering, or handling, a browser request URL by rewriting any incoming requests and routing them to the internal application server HTTP service. For example, if a user typed the qualified hostname such as they would land on the Davalen home page.

You will need to update the plugin-cfg.xml file. This is a task performed in the solutions console and is perfromed to ensure all mappings are properly configured to include the web server as well as the application server in module mappings.


About the Author:  David’s professional career spans multiple disciplines with a consistent emphasis on discovery and implementation of solutions geared towards achieving objectives of strategic importance. In 1993 David established his consulting practice providing automation of business processes. In 1996 he joined Jacob Solutions, Inc., predecessor to Davalen, LLC where he served as Principal Application Architect and Solutions Engineer. His project management and implementation skills have been put to work in sectors such as manufacturing, health care, banking, and insurance. The tools he employs include Microsoft DCOM (now known as .NET) and J2EE. His practice is to prefer technologies that leverage international standards. For this reason much of his development and implementation has been based, since 2001, on Java-related technologies. David’s professional accreditations including a certifications as a Microsoft Certified Systems Engineer and an IBM Advanced Developer. A popular orator, David has been asked to speak across the United States on a variety of topics, including many java related topics, document management and web content management. His academic background includes a BA in History from The Citadel, an MDiv from Southern Baptist Theological Seminary, and post-graduate studies in data communications at Boston University.

This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth O’Keefe and request to be added to our E-Newsletter list. You can also view the Master Series Archives.

Master Series: IBM Sametime 9: An Overview

AHigginsby Andy Higgins

This article takes a look at version 9 of IBM Sametime, released at the end of September 2013. We will examine the product and provide an overview of the features and functions that have changed and those that are new. Much has changed in the look of the new Sametime with a new GUI refresh. It’s easier to install than before allowing cleaner, more understandable installs. Some of the new functionality requires new or updated servers. Finally, IBM has improved the product packaging from before allowing it to be sold in a simpler format.

The GUI Refresh

The first noticeable change in Sametime V9 is the totally refreshed graphical user interface (GUI). Among the updates are a new look to the client window, a more user-friendly meeting interface, additional functionality in the web proxy, and new features that make Sametime Advanced a more integral part of the product.

The Sametime Client

Figure 1 provides a side-by-side comparison of the new and old Sametime clients (stand-alone).

Figure 1

Figure 1. Comparison of the new and old Sametime client GUIs

As the figure shows, some items have been moved in the new GUI to make them more accessible and give the window an open look:

  • The Add User button (shown by green arrow in the figure) is now all alone in the bottom left, thus accentuating its requirement. It is no longer lost in a row of several options as seen on the right.
  • The additional Sametime “panels” (shown by orange annotation in the figure) no longer take up valuable screen real estate but are iconized on the left side.
  • The user’s business card is now displayed with a personal photo at the top to confirm to contacts that they are communicating with the intended person.
  • The settings option is one-click on the icon to left of the search bar on the top.

Altogether, the changes make the client look more modern than its predecessor and save space.

The chat windows have also changed, as shown in a side-by-side comparison in Figure 2.

Figure 2. Comparison of new and old Sametime chat windows

Figure 2. Comparison of new and old Sametime chat windows

The main change is the modernization of the client, including the updated icons. Additional changes include:

  • Tabbed windows for multiple chats is the default now, although users can change this in their preferences.
  • Instant Share works right out of the box in this release. This is a Sametime Advanced function, but because it is now included in the general license, it is deployed by default and works well.

Sametime Meetings

The Meeting server has changed its look too. Figure 3 shows a meeting in Sametime V9.

Figure 3. Sametime V9 Meeting server

Figure 3. Sametime V9 Meeting server

The colors have changed to match those of the new client, and the overall feeling is much more professional than it was in the previous version. All the functionality works out of the box, and remote control has been much improved over that in version 8.5.2.

The screenshot in Figure 3 shows the new Meeting Stream tab, under which is a list of activity for the meeting. The tabs on the left side can be minimized if necessary to make more space for the meeting and screen sharing.

The panel on the left side allows users to open and close different sets of view panels in the meeting so that they can see a variety of information.

The Sametime Web Client (Proxy Server)

The web client has received a small makeover this version, gaining some new functionality. A side-by-side comparison of the new and old clients is shown in Figure 4.

Figure 4. Comparison of new and old Sametime web clients

Figure 4. Comparison of new and old Sametime web clients

The new Sametime V9 client on the left looks much more like the hard client. The great new functionality available for the web client is in the preferences, most of which didn’t exist in Sametime 8.5 and is shown in Figure 5.

Figure 5. Sametime web proxy preferences

Figure 5. Sametime web proxy preferences

The Preferences allow for a number of options to be set:

  • My favorite new option is that I can now choose not to display the offline contacts. In Sametime V 8.5.2 this was not possible so you ended up seeing all contacts in your list regardless of their online status.
  • You can choose whether to save your expanded groups on exit. This means that when you exit, upon logging back in with the web client, your personal groups will be expanded showing all the users.
  • You can choose between displaying the photos or just the name in the multi window tabbed chat interface
  • You can now choose to play a sound or not when chatting and you can receive a notification when your chat partner leaves the chat

All these new preferences were NOT available in Sametime 8.5

Sametime Advanced

The Sametime Advanced product has always seemed to be an afterthought by IBM. Even though the actual functionality provided is extremely cool and useful, it has been difficult to sell because of the packaging. In Sametime V9, however, most of the features are included in the basic Sametime license for IBM Sametime Communicate and all the features are included in IBM Sametime Complete. It is also presented in the deployment wiki much as all the other Sametime servers are. It installs the same way, incorporating a little extra DB2 add-on (DB2 Net Search Extender) that allows smart text search capabilities in the Sametime Advanced database.

In the end, Sametime Advanced provides a whole new set of features for Sametime:

  • Group persistent chat. This feature is similar to a multi-way chat, but it does not disappear when the last person quits. It is persistent such that people can go back into the chat room at a later time, see what was discussed, and even conduct searches. Additionally, users can turn on live search capabilities in the chat room that inform them if people are discussing specified topics even when they are not there. Users are alerted when their set criteria are met and can join the chat to listen and participate. Persistent chat rooms have been very popular in the financial services industry but also bring great value in worldwide support groups.
  • Instant Share. This feature enables users to instantly share their screens and give control to another person; thus, it has become a powerful support tool. Note that this feature is ONLY available in Sametime Complete.
  • Broadcast communities. This hugely powerful set of collaborative tools in the Sametime environment allows broadcasts, polls, and announcements to be made to defined groups in an enterprise.

The New Packaging

The Sametime packaging and product marketing was somewhat complicated in past versions. Customers who wanted a feature that was included in the Sametime Advanced pack, such as Instant Share, had to buy the whole Advanced package. Additionally, IBM leveraged an extra license cost per server for extranet Sametime servers.

Fortunately, the extranet server cost has been dropped from the product, and users can now run intranet and extranet Sametime servers however they want without paying additional license costs. This is probably the biggest news for customers who want to utilize their Instant Messaging outside their enterprise.

With Sametime V9, the view of the product is much simpler than it was before: one main product and two sub-products. Customers can buy the entire IBM Sametime Complete or buy one of the sub-products known as IBM Sametime Communicate and IBM Sametime Conference. See Figure 6 for a graphic of the product taken from the Sametime Blog, which describes the options in more detail.

Figure 6. Views of Sametime V9 packaging

Figure 6. Views of Sametime V9 packaging

The New Audio/Video

The major backend change to the Sametime product is in the audio/video server setup. Sametime V9 has an actual Multipoint Control Unit (MCU), which is a departure from the older Packet Switcher approach.

In Sametime 8.5, the Audio/Video was divided into three components, the SIP Proxy/Registrar, the Conference Manager and the Packet Switcher. All three of these components ran on Windows or Linux.

In Sametime 9, the Audio/Video is divided into 4 components, the SIP Proxy/Registrar, the Conference Manager, the Video Manager and the Video MCU. Only the SIP Proxy/Registrar and the Conference Manager run on Windows or Linux. The Video Manager and the Video MCU run on Linux only.

Even though the IBM Sametime Media Manager is available for installation on either Linux or Windows platforms, the Video Manager and Video MCU components run only on Linux and can be used only with the Sametime Conference or Sametime Complete offerings. The Sametime Communicate offering does not come with multi-point videoconferencing but it does support point-to-point Audio/Video between two users.

An important note on nomenclature here – the fact that we are referring to Video Manager and Video MCU actually means that these pieces handle BOTH Audio AND Video. I would argue that they perhaps could be called the Audio/Video manager and MCU but current technical terminology assumes the Audio when talking about Video.

The Bad News

Unfortunately, it is not possible to upgrade from previous versions to Sametime V9. The current recommendation from IBM is to create a new environment beside the existing Sametime environment and migrate users from one to the other. This new version of Sametime sits on a new version of WebSphere (V8.5.5), and upgrading from WebSphere V7 to V8.5.5 is tricky.

In an “upgrade” from a Sametime V8.5 deployment to Sametime V9, probably the most important thing is to keep is the database information in the Sametime Console (just the policies), Sametime Meetings and Sametime Advanced DB2 databases. Sametime V9 uses a newer version of DB2 (V9 moves to V10.1 because DB2 V9 went to “end of support” on April 30, 2012), so the databases will need to be upgraded and moved onto a DB2 V10.1 server. IBM’s technote covers this DB2 upgrade, so you can keep your old DB2 version for the moment, but you still have to upgrade the DB2 databases as specified in the technote.


In conclusion, Sametime 9 is a well-rounded advanced product with a good new look. IBM have looked at the deficiencies of the previous product and addressed them in this new version. I like the new look of the GUI. I need to state here that I haven’t stress tested the product or run it in a world-wide business environment, so I would highly recommend testing especially the new Audio/Video functionality before deploying. Due to the fact that you have to effectively build a completely new Sametime 9 environment (no upgrade path), you might as well take the opportunity and stress test the new environment before allowing users on it.


About the Author: Andy Higgins has worked with Lotus Notes and Domino on a professional basis since 1996. As a senior consultant at Davalen, Andy is dedicated to providing Lotus Notes, Domino, and Sametime services and applications. Andy has worked for Bank of America as its lead collaboration architect and has also had two stints with IBM as a consultant in both post- and pre-sales technical roles. Having worked with Sametime since its arrival at IBM, Andy concentrates most of his efforts on that product, providing architectural and technical support and consulting. Throughout his career he has also worked on many email migration projects and is an expert on both email and instant messaging interoperability and coexistence. Andy is currently working on a large Smart Cloud for Notes migration.

This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth O’Keefe and request to be added to our E-Newsletter list. You can also view the Master Series Archives.

Master Series: Planning your Linked Java Object (LJO) strategy in IBM Web Experience Factory (WEF)

kevin-wilmeth by Kevin Wilmeth

One of the things we love about IBM Web Experience Factory (WEF), as a development tool, is its friendliness to plugging in custom Java code.  And by this we mean optionally plugging in code, only where it is truly needed, not being covered natively by the builder set.  You can do this in…a lot of places, including places people wouldn’t necessarily even think to look.  (Ironically, the full extent of this capability often eludes the highly experienced Java programmer, who may be mentally wired in to a different way of organizing code, and not intuitively “see” how WEF presents itself for such extension.)

And so we have the humble “Ell Jay Oh” as part of the toolkit—we teach its basic mechanics within the first five days of training—but we don’t talk a lot about the strategy of how to organize the LJOs that you do create.  As you might imagine, there is value in putting a little thought into this, and the following ideas have evolved into a pretty useful strategy that I like more the more I use it.

LJO layers that work together

The big inspiration for my strategy came some years ago now, when the Domino builder set first became available and I worked on a number of projects that needed it.  As a longtime Domino developer before I discovered the Factory, I understood that really getting value out of Domino meant going beyond (way beyond) the limited capacity of the builder set.  And so lots of core Domino functions wound up as Java methods in LJOs.  Enough so, that I had to do something to organize them!

At some point, it dawned on me to look at my LJOs in layers, much like you’d think of SOA layers.  It turns out that there are two very clear separation points that you can lean on to do this:  IXml, and WebAppAccess.  This implies three layers of LJOs in your project architecture.

External APIs (no IXml)

The first layer is the one that is “most distant” from Factory models, and “closest” to purely standalone code—code that would be useful completely outside of WEF.  It is distinguished by the absence of either IXml or WebAppAccess imports (or anything else specific to the Factory).

Using the example of my Domino integrations, this was code which had inputs and outputs that all belonged to the Domino API.  It spoke Views, and DocumentCollections, and RichTextItems;  internally it ran @Formula code and called Agents.  In fact, much of it was code that I could have used in Domino Designer, to build things like Domino Java Agents.

The idea works for other external APIs, too.  Just recently I started doing some work with XSLT transforms and PDF generation, and so built a definable layer to house that code, based upon this same idea.  Housed neatly in its own layer from the beginning, my overall project progress was noticeably faster than what I’d seen before the Domino example evolved, despite my being new to both those APIs.

In short:  this is the implementation layer.  The code that does the meaningful API work.  In SOA terms, think of this layer as the black box of your service operation’s implementation.

Middleware code (to/from IXml)

This layer might be called middleware.  It sits between the API code layer and the layer that touches Factory models.  It uses IXml, but not WebAppAccess.  Its purpose is nearly exclusively to transform API objects to and from IXml (and other Factory-friendly formats).  Many transforms can be done at this level (e.g., sorts, reorganizing XML, etc.), but not anything that requires WebAppAccess.

In my Domino integrations, this layer featured methods that took Domino objects as inputs and returned IXml, and other methods that took IXml inputs (and simple types, of course) and returned Domino objects.  Method bodies would simply make calls to the “external API” layer for the Domino objects, push them into and out of IXml format, and be done.  Transforms supported this core mission.

This is the layer that is at once the easiest to overlook, and the most valuable.  Once I really committed to the practice,  I noticed that I started to change the way I wrote my transforms.  In a nutshell, I re-wrote a number of transforms specifically to avoid using WebAppAccess just to commit to the idea…you know, just because I’m a geek…and boy, if the transforms themselves didn’t become notably more useful and usable as portable code after the switch!

So, in short:  this is your integration layer.  The translator.  In SOA terms, this is where you define your service input and output schemas, and do internal service transforms against the black box.

Model code (makes use of WebAppAccess)

This is the layer that is “closest” to Factory models, and “farthest away” from external systems.  It makes use of both IXml and WebAppAccess.  This means it knows about model variables, and model actions, and Data Service names, etc.  And here’s the funny part:  this is the only layer that you actually use as LJOs in your WEF models.

Because of how the request chains outward from here (first to middleware layer then to API), this code is usually highly readable:  in general, outward-facing methods in this layer simply assemble inputs, invoke middleware layer calls, and make any result transforms that are uniquely specific to the consuming model.  This makes them much friendlier to read, when they are sitting next to inward-facing methods that set model variable values, interpose a complex branching structure in front of a named service call, or other very WEF-specific things.

And, of course, when things are set up this way, the model-specific LJOs can share code from the middleware layer.  More often than not, this proves useful as a project develops, in ways that weren’t obvious when the project started.  Having the core architecture already in place usually makes for much happier developers at that time!

In short:  this is the invocation layer.  The kickoff point.  In SOA terms, this is the Consumer.  Transforms done here can be thought of as true pre- or post-processing transforms, not internal to the service operation but fully independent of it.

General practice notes

This layout seems to make all the Java code (the code at each layer) much more readable, since it’s “siloed” more appropriately according to its function.  There are more files to keep track of, of course, and sometimes the architecture can seem a little cumbersome, but it expands very elegantly, and with separate files it has been notably friendly to separating work between multiple project developers.

Note that this layer system does not necessarily impose anything on your practice of Java package naming.  You can certainly set up a simple packaging practice based on those layers, but it isn’t necessary.  In general, my own practice has been to make a separate LJO class for each model that needs an LJO, packaged under app.models, and named according to the model name.  This makes it obvious that it’s tied to the model, and since it’s simply consuming the middleware layer for anything outward-facing, that tight coupling really doesn’t bother anything.

Having things separated like this, too, does make it notably easier to swap out one external API for another, if that need arises—and sometimes it does.  Similarly, with a well-constructed external API and middleware layer, it is not difficult to bolt that on to a new set of WEF models that might need the same integration.  Certainly in my Domino work I leaned heavily on the evolved two “outer” layers;  tying a new project’s models into the existing core was extremely simple, and I did it a lot.

Global tools

A more recent practice I’ve started is to seriously consider an LJO inheritance hierarchy, for the project, and using the same general strategy.  For any project that uses a lot of Java code, this can be very useful.  Consider the following two classes in this project, AppBase and LJOBase:


AppBase is at the top of the hierarchy, and its purpose is to provide an inheritance chain back to things that are of interest to the entire project:  constants, utility methods, etc.   In general, my intention here is that there is no IXml in this class, but the jury may still be out on that.  There’s a huge comment in this file, for the benefit of other developers (and of course reminding myself).

LJOBase extends AppBase, and adds things that are of interest to models in the project:  IXml, WebAppAccess, model-specific constants and utility methods, etc.  One thing I like to put in here are constants for working with schemas that are shared across multiple models.

With these in place, then, each time I go to create an LJO for a given model, I extend LJOBase and immediately get access to all the things that are “global” across the project for WEF models.  When I’m creating the “external API” layer classes, extending AppBase gives me access to project-level items without the extra WEF model clutter.  This is a simple idea that is commonly done outside WEF, but which we tend to overlook when we think of our Java code as “I just need a quick LJO for this model”.

Some specific thoughts about global artifacts:


I like listing global constants either in AppBase or LJOBase, depending on how coupled they are with models.  Things like the application name (for the purpose of logging), logging messages, critical folder paths and URLs in the project, global date formats, file size thresholds, constants for generating code, etc.  Again, in LJOBase I like listing schema element names for any schemas that are used by multiple models.  And so on.  I’ve been happy to be able to reach upstream in the hierarchy for these things, once I’ve located them in the right place.


One thing I’ve been really happy about is the use of a global logging class, offering a full range of static methods for logging messages throughout the application.  My AppLogger class lives alongside AppBase and LJOBase in the app.util package, and provides a global framework for logging messages.

AppLogger, itself, is tied into AppBase in that AppBase specifies the logger output setting:


Internally, it defines a consistent vocabulary and textual signature for logged messages (e.g., supplies the application name, extracts message content from a supplied exception object, accepts a further unique message, etc.), and then wraps a generic Logger object’s methods with that:


With static methods available from this logging class available in the project, logging a message in LJO code is very compact and simple.  And consistent. And enhanceable.  Here is an example in the project’s PDF generator LJO:


And meanwhile, over in some service transforms:


And so on.  In my experience, the return on investment for setting up that logger class has been huge, and I have had occasion to tweak or enhance the way messages get logged, here and there—and it’s nice to be able to do it in once place, and have it “cascade down” immediately.

Run with it!

Keep in mind that the above are ideas, and there’s no possible way they’re exhaustive.  And, really, they’re nothing more than the outgrowth of a little attention to designing how you use custom Java in your WEF project.  You may well find even more efficient ways to handle things yourself.

What many WEF developers forget is to look at their LJO strategy in the first place.  By all means, design one.  Agonize over the names, packaging, and breakout.  It’s worth the effort!


About the Author:  Kevin Wilmeth has been working with IBM Web Experience Factory (WEF) since 2001 as a field developer, trainer, coursewriter, mentor, and architect.  He came to the Factory from a prior career with Lotus Notes/Domino, where he served the same roles in much the same depth, and for a while specialized in integrating the two technologies.  Kevin has also spent some time in the education technology industry, bringing both the technology and the education to people and places that just didn’t have it before.  He lives on Alaska’s Kenai Peninsula, where the fish laugh at him and musical instruments shudder at his very approach.

This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth O’Keefe and request to be added to our E-Newsletter list. You can also view the Master Series Archives.

Davalen Welcomes Daniel Jacob to the Dallas Team

Davalen is happy to announce the new addition of Daniel Jacob to our sales team!

Daniel Jacob Client Executive

Daniel Jacob
Client Executive

Daniel Jacob returns to Davalen to serve our customer base in the southwest. His Dallas roots run deep as a long-time resident, a graduate of Southern Methodist University and a founding member of the Dallas Mavericks ManiAAC team. His ability to build trust quickly with clients is evident of his eighteen years’ experience in client service roles focusing on finding the best solution for each individual.

The Dallas office provides support for a variety of services including application development, migrations, staffing, and agile implementation assistance. Specific expertise within the IBM Collaboration Solutions brand include Web Experience Factory, WebSphere Portal and Notes/Domino allowing for local support to our current clients as well as new relationships.

Daniel, as well as several other Davalen team members will be attending IBM Connect 2014 in a few short weeks. We hope you’ll take the time to stop by our Pedestal #116 or schedule a time to get together.

 Contact Daniel

linkedin  (800) 827-8451 ext 114

Showcase Hours Announced for IBM Connect 2014

Showcase Hours: IBM Connect 2014

The showcase is located on the bottom floor of the Walt Disney World Dolphin hotel in the Atlantic Hall.


SUNDAY, January 26, 2014

6:30 PM – 8:00 PM Welcome Reception

7:30 PM- 8:00 PM Showcase Grand Opening

MONDAY, January 27, 2014

10:00 AM – 3:45 PM Solutions Showcase Open

6:00 PM – 8:00 PM Showcase Reception

TUESDAY, January 28, 2014

9:15 AM – 3:30 PM Solutions Showcase Open

5:30 PM – 7:00 PM Solutions Showcase Open

WEDNESDAY, January 29, 2014

9:15 AM – 3:30 PM Solutions Showcase Open

Find Davalen at Booth #116

Davalen at Connect Booth116

Meet the Davalen IBM Connect 2014 Team

Twitter-thumbnail_Connect2014_2As a proud IBM Collaborative Solutions (ICS) enthusiast, Davalen will be participating in all things IBM Connect for the seventh year in a row. Our team of professionals will be participating in a number of ways at the event this year and hope to have a chance to speak with you. Feel free to reach out to one of our team members directly or fill out the form below to plan a time to chat at IBM Connect 2014. As always, you can plan to stop by our showcase pedestal #116 during open hours.

 AHiggins Andy Higgins, Senior Consultant

Andy Higgins has worked with Lotus Notes and Domino on a professional basis since 1996. As a senior consultant at Davalen, Andy is dedicated to providing Lotus Notes, Domino, and Sametime services and applications. Andy has worked for Bank of America as its lead collaboration architect and has also had two stints with IBM as a consultant in both post- and pre-sales technical roles. Having worked with Sametime since its arrival at IBM, Andy concentrates most of his efforts on that product, providing architectural and technical support and consulting. Throughout his career he has also worked on many email migration projects and is an expert on both email and instant messaging interoperability and coexistence.

(linkedin512) 426-6142

 AWhorley Art Whorley, Client Executive

As a Client Executive, Art helps companies grasp the business value of becoming a Social Business. In addition, he partners with clients to determine the specifics of a solution and then leads the effort to drive adoption. Before Davalen, Art’s career with IBM spanned 33 years and incorporated experience cooperatively working with customers to identify and meet their specific business needs, promote solution adoption and assist with problem resolution. Recently, Art has focused primarily on Social Business Networking, Messaging and Collaboration, IBM SmartCloud, Mobile solutions, and Web Experiences. Art lives in North Carolina with his wife of 39 years and their Wheaten Terrier, Riley. He has four grown children, one grandson and one granddaughter. He is also eagerly anticipating the birth of his second grandson in early 2014.

linkedin(800) 827-8451 ext 113

 DanielJacob Daniel Jacob, Client Executive

Daniel Jacob returns to Davalen to serve our customer base in the southwest. His Dallas roots run deep as a long-time resident, a graduate of Southern Methodist University and a founding member of the Dallas Mavericks ManiAAC team. His ability to build trust quickly with clients is evident of his eighteen years’ experience in client service roles focusing on finding the best solution for each individual.

linkedin(800) 827-8451 ext 114

 DJacob Dave Jacob, Managing Partner

Dave has been a successful businessman, pilot and professional bowler over his varied career. He spent 18 years at EDS, a worldwide systems integration public company, in technical development, management and sales in the healthcare and manufacturing sectors. He was the CEO of Data Solutions Corporation, a subsidiary of Data General, before founding one of Davalen’s predecessors, JSI, in 1993. He continues today as a managing partner. Earlier in his career, Dave entered the Naval Flight program and served as the maintenance officer at the US Navy Test Pilot school before his honorable discharge in 1972. He entered his bachelor degree in Applied Math and Physics from Florida State University. Dave serves on the board of various charities and currently lives in Massachusetts with his wife and dotes on his three grandsons and one granddaughter.

linkedintwitter(800) 827-8451 x104


 DCorcoran Deborah Corcoran, National Director for Resource Deployment Services

As the National Director for Resource Deployment Services to IBM at Davalen, Deborah brings significant experience in sales, marketing, recruiting and management of contractor services, for enterprise accounts across the U.S. and internationally. Prior to joining Davalen, she supported the IBM Software Services teams, across all the IBM Software portfolios as the Director of IT Staffing for other IBM Software and Services Business Partners; in addition, she has worked on numerous IBM dedicated vendor teams building and managing strong, long-term relationships. Using a consultative sales approach to articulate IT consulting services and solutions product offerings to Fortune 500 -1000 companies, she successfully grew her sales territory in not only notable yearly revenue specific to IBM Software Services for Collaboration and WebSphere brands, but also in developing long standing client relationships. Over the past ten+ years, she has held the position as the Director of IT Staffing, at several well-known IBM Business Partners. Deborah has solid experience in establishing and maintaining a recruiting and consultant staffing services division for IBM Business Partners, who want to focus on contract staffing services support specific to IBM Collaboration software.

linkedintwitter (800) 827-8451 x103

 LBarker Len Barker, Managing Partner

Len spent 15 years in the nuclear industry managing complex, multiple system projects before founding one of Davalen's predecessors, Barker Consulting, in 1998.  He is a certified IBM instructor and is well versed in web technologies, system administration and collaborative technologies.  Responsible for the operations side of the house at Davalen, Len makes sure that our employees have the resources they need to provide the service our clients expect.  He holds an Electrical Engineering degree from the United States Naval Academy, an MBA from Auburn University and is a licensed professional engineer.

linkedintwitter (800) 827-8451 x101

Master Series: Tracking Portal Page States with IBM Web Experience Factory (WEF)

Adam Kewley Davalen

 by Adam Kewley

Once in a while during product development we run into scenarios where we need to extend the functionality of IBM Web Experience Factory (WEF) & IBM WebSphere Portal above and beyond what’s supported out of the box. The product goes a long way to make things easier to develop with but it’s impossible (and impractical) to expect it to cover every scenario. Fortunately we can usually rely on custom API and sample workarounds to get us through. This article will discuss one such scenario: Tracking Portal Page states with WEF.

In general a portlet isn’t supposed to know (or care) which page it is placed on. It also shouldn’t worry which page the user was on previously. Due to this construct, it’s not always easy to tell when a portlet is being reloaded or when it’s processing a request from a form action.

In some instances however, a project may require a portlet to refresh itself when a user navigates back to that page. A client may wish that an input form resets itself despite what the JSR specification may state. IBM provides a few API classes that expose the page structure. We’ve used them in the past to get the unique page name as well as generate a portal navigation menu inside of a portlet. In this segment we will discuss how to implement your own portlet page tracker which will not only be able to tell when  page changed, but also track whether or not a portlet has registered this page change.

The WebSphere Portal API provides the ModelUtil and NavigationNode classes to gain access to the page models within the portal. Using the following sample code, we can obtain the unique name of the current portal page:

ModelUtil util = ModelUtil.from( webAppAccess.getHttpServletRequest(), webAppAccess.getHttpServletResponse() );

NavigationNode node = ( NavigationNode ) util.getNavigationSelectionModel().getSelectedNode(); 

String uniquePageName = node.getContentNode().getObjectID().getUniqueName().trim();

If we know which page we are currently on we can also keep track of the prior page we were on. This requires a bit of planning. One key aspect of this solution is assuring that the page tracking logic exists on all portal pages. If you only apply the tracker portlet to a few key pages your tracker will lose its state and you may end up missing page state changes. Every page that’s visible within the portal will need to contain the tracker portlet. There are a couple of ways to handle this.

Some Portals may contain a header portlet which exists on all pages. This header portlet can be modified to include the page tracking logic as well. Optionally if you have no use for a common header/footer/filter portlet, you can create a hidden portlet that is placed on the page but uses a Portal Theme skin which hides the portlet altogether. This allows the portlet to execute without visually impacting your portal project.

The Page tracker also needs a bit of custom logic to track the current state. A shared variable of type String named currentPage will contain the last registered page name for the session. An event handler that is setup for “OnRequest” events will use the portal page logic to determine whether or not the API pageName differs from the value stored in the currentPage variable. Using this logic we can now identify when a user switches portal pages.

public void updatePageTracker( WebAppAccess webAppAccess ) {

final String newPage = getCurrentPage( webAppAccess );

final String currentPage = webAppAccess.getVariables().getString( “currentPageVar” );


if ( currentPage == null || newPage.equals( currentPage ) ) {

    Vector<String> pageRegistry;

    pageRegistry = (Vector)webAppAccess.getVariables().getObject( “pageRegistryVar” );


    if ( pageRegistry == null ) {

        pageRegistry = new Vector<String>(); // Initialize

        webAppAccess.getVariables().setObject( “pageRegistryVar”, pageRegistry );


    webAppAccess.getVariables().setString( “currentPageVar”, newPage );

    pageRegistry.clear(); // remove registered portlets.



The Page Tracker solution isn’t as useful however if the portlets on the page are not able to individually discern whether or not this page change took place. We can get around this by using a bit of java and a second shared variable (Object) called pageRegistry. This xml variable should include multiple elements that contain the name of registered portlet instances for a given page. We don’t care which portlets should be on a given page, only that the portlet adds itself to the registry.

The additional java code would include a method:

public boolean hasPageChanged( WebAppAccess webAppAccess ) {


Vector<String> pageRegistry;

pageRegistry =(Vector)webAppAccess.getVariables().getObject(“pageRegistryVar” );


boolean isRegistered = false;

final String portletID = webAppAccess.getInstanceID();


if (  pageRegistry.contains( portletID ) )


    isRegistered = true;




    pageRegistry.add( portletID );


return isRegistered;


This method should be called in an onRequest event handler by each portlet which wishes to make use of the page tracking logic. The method can be used in a conditional check to see if the portlet should update itself.

So now that we have the basic solution for tracking page changes and portlets that can identify when a page change has occurred, we’ll outline a couple uses for this solution.

#1 Updating Portlet on Page Change

When switching portal pages, initialized portlets are simply given render requests. It is assumed that the portlet will render its last known state. By using the page tracking logic, an event handler can be triggered to make a service operation call and obtain new data. If you need to update the portlet, then be sure to call the webAppAccess.resetCurrentPage( String page ) method which will force the portlet to update the page during a render request.

#2 Filtering Events

WEF events are broadcast events that will trigger event handlers in portlets that exist on any accessible page in the portal. This means that if you have a global filter event, every portlet that listens to this filter event will act when the filter event is fired regardless of whether or not they are on the current page. This will only occur if the portlet has been initialized for that session. Portlets residing on pages that you have not yet visited will not listen for the event. This of course can cause performance issues because you now have any portlet listening to this event acting during a single request. The page tracking logic can be inserted in the event handler to determine whether the event handler should execute or not. Example:

public boolean isValidPageEvent( WebAppAccess webAppAccess )


Vector<String> pageRegistry

pageRegistry = (Vector)webAppAccess.getVariables().getObject( “pageRegistryVar” );

return ( pageRegistry.contains( webAppAccess.getInstanceID() ) );                       



Adding a conditional logic to your event handler will prevent this portlet form executing if it doesn’t need to.

#3 Returning to an Initial Portlet State.

If you have a portlet that you wish to return to an original page after navigating away and back to this portal page, you can use the event handler to swap pages. Just use the webAppAccess.resetCurrentPage method to change the active page during a render request.

#4 Resetting a Portlet.

This is a bit tricky, and there are other ways to accomplish this, but you can also reset session data for a given portlet as well.

In conclusion it is possible to track the state of portlets as well as the page that the portal is being rendered on. By using some java and a few builders you can add a framework which can aid in performance tuning of WEF events as well as handling data refreshes and portlet resets.

Closing Thoughts:

  1. The code in this segment is provided as a sample and not production ready.
  2. The solution assumes that portlets are rendering individually and not using parallel portlet rendering.
  3. The sample also assumes that the portlet tracking the page changes renders before the other portlets render. The “page tracker” portlet should be the first portlet (top most) rendered on the page, and the portlets that make use of the page tracker should come after.
  4. This sample utilizes the public_spi.jar Jar file.
  5. The java source code for this sample can be downloaded here.

About the Author: Adam Kewley has been working with IBM Web Experience Factory (WEF) for over 10 years. He began his career working with the WEF development team itself. Over time he moved from software QA to Development, L3 support lead (assisting the IBM customer support team), and finally on to consulting. He has led several engagements and has been pulled in the past to put out fires and address deliverable roadblocks ensuring success for a client. Adam is currently employed at Davalen as the WEF lead and architect and is a resident of southern New Hampshire.

This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth O’Keefe and request to be added to our E-Newsletter list. You can also view other articles in the Master Series by clicking here.

Master Series: Changing the Fully Qualified Host Name (fqhn) in IBM WebSphere

VToalby Victor Toal

Over the last few years many of IBM’s products have begun to include WebSphere as a component to a greater or lesser degree, depending on  which software package you are dealing with. IBM Connections, IBM Sametime, IBM Docs … all of them require that you sharpen your WebSphere skills and learn – at the very least – how to install WebSphere and the product on top of it.

But now that you have WebSphere in your environment you will be tasked not just with starting it, but maintaining, migrating, updating, moving, merging it … all those things that you also have to be able to do with any other software suite.

If, for instance, you need to install Connections, the documentation will cover the base install. When it comes to actually running the system you are left to your own devices, therefore I am starting an article series to help you learn some additional skills in WebSphere that will help you deal with some more unusual scenarios involving WebSphere.

Why Would I Want to Ever Change Host Names in WebSphere?

Moving servers or whole environments from one DNS realm to another is not that unusual. Recently I had to help a client create a new Sametime environment to replace an existing one and do an upgrade at the same time. We decided to build in parallel on the same hardware but to use different host names for the new servers.

We installed, configured and tested without impacting the existing environment. When the time came to cut over, all that was left to do was to change the host names of the WebSphere servers and make sure that our Sametime components all start up listening on the correct IP addresses. This allows the cut-over to be invisible to the end user and we did not have to change a lot of rather complicated firewall rules.

Changing the Host Name – It All Happens on the Deployment Manager

The one thing you have to get used to when dealing with WebSphere is that ALL configuration steps always happen on the Deployment Manager (most often referred to as Dmgr or DM). Changing the host name of any WebSphere Node or WebSphere application sever all happened on the deployment manager and not on the actual node itself. To change the settings you have to utilize both the IBM console (a web based administration interface) and the wsadmin configuration tool.

First you need to change the fqhn of the Node and Application Server using wsadmin, then you change the port settings for the application server(s) and the virtual host settings.

wsadmin – The Command Line Interface into WebSphere

I work most often with servers running on Linux, so my examples below will all reflect the Linux command line. The only difference to Windows is the folder structure and the fact that you would execute a batch file to start wsadmin instead of a .sh file as in Linux. Once inside the wsadmin tool all commands are the same.

Start wsadmin:

Open a command line interface to the WebSphere deployment manager either over putty or from the server directly.

Go to the /bin folder of the dmgr profile and execute wsadmin:

./wsadmin -lang jython -username wasadmin -password ****

Once in the wsadmin shell enter the following command to get a listing of all Nodes and Servers on your system:


In that list identify the Node/AppServer combination that you wish to change, in my case it is


To change the hostname of this Nodes and Server  to my new host name enter the command:


Now, to verify the command took, enter the command‘(cells/Cell01/nodes/Node01|serverindex.xml#ServerIndex_1)’,’hostName’)

And verify the results, then enter “” to save the results permanently


Now all that is left is to make some port changes using the IBM console in your browser and to sync the changes and restart the Application server and you are done!

About the author: Victor Toal is a messaging and collaboration architect and engineer with more than 15 years experience with Domino (since R 4.1), Sametime, Quickr, IBM Connections, and WebSphere. Victor’s clients include the Pentagon, US Army, banks, as well as manufacturing, tourism, and medical companies. He has worked in the US and overseas (Japan, Austria, Great Britain, Germany, France, Italy, Hungary, Poland, and Czech Republic) and speaks fluent German and Japanese. He is certified in Domino R4 – R8.5 and Sametime 7.5 and 8.0. Email Victor directly.

Early Bird Pricing Extended through December 13 for IBM Connect 2014


Register before December 13 and take advantage of the Connect 2014 early bird rate!

Use Code: BP5013

When: January 26 – 30, 2014

Where: Walt Disney World Swan and Dolphin
Epcot Resorts Blvd, Lake Buena Vista, FL 32830

No matter what you do in life, it should energize you, fulfill you, engage you and give you purpose each day.  IBM Connect 2014 will feature the IBM solutions that are ‘Energizing Life’s Work’ – enabling and empowering employees and clients, and ultimately driving real business results.Join us January 26 – 30 in Orlando, Florida for IBM Connect 2014, our biggest and best event yet.  It includes the Lotusphere Technical Program, the Kenexa World Conference, and a host of insights to help IT leaders, HR professionals and business leaders from around the world transform  the way you work.

Industrconnect2014_reg-now-save-Dec13_125x65y pioneers and clients representing industries around the world will share game-changing technology and strategies in workforce management, social business, smarter commerce, business analytics, cognitive systems, mobile and cloud that are propelling their companies to competitive heights.

Connect 2014 will be here before you know it. Register now and make plans to join this informative and engaging event.

Registration Instructions:

When  registering for IBM Connect 2014, there is a section asking “How did you hear about IBM Connect?”.  When you respond to this question, please select “Other” and then in the open field, enter the code “BP5013″ so we will be able to track your registration and keep you updated on how you can get the most out of the conference.

Quick Links
Stay Connected
Like us on Facebook   Follow us on Twitter   View our profile on LinkedIn   Visit our blog