Master Series: Essentials for Delivering Empowering Digital Experiences with IBM Web Experience Factory

David_Wadeby David Wade

IBM ExperienceOne solutions aim to “Deliver real-time flow of insights and interactions—at scale.”   IBM Web Experience Factory is a part of the IBM Customer Experience Suite. With Release 8.5 the product continues to evolve as a framework that can build a solid application that integrates with the many layers in the Digital Suite. The ultimate goal is to deliver solutions that empower the customer across the digital experience.

A lot of what we discuss around Web Experience Factory is about the technical aspects and that is very important. There are times new (or old) developers hit road blocks in the learning curve and need technical guidance. IBM and the WEF community have some great information available and at Davalen we have the Master series along with our consulting experiences. Once you begin to “master” building applications, I believe that Web Experience Factory’s strength is not just the first time you develop a digital experience. It’s the second, third, and later times that you come back to update the application and how it maintains all of the integration points with other applications.

For those of you that travel, you reach a time where you know exactly what you need to pack for four days away from home and generally pack it the same way. When I unpack at the hotel there is confidence that I have everything I need.  For this article I would like to summarize some essentials that I believe are important to “pack” for your solution. The emphasis will be on Web Experience Factory with the mindset no application is an island to itself. My challenge to you is to give feedback some of your experiences in these areas and some essentials that you may have in your WEF suitcase. Together we can help Web Experience Factory as it continues to mature into a world-class framework.

Essential: Coding Standards

Even though a large part of Web Experience Factory is builder based, we still need to establish coding standards. The table below is a list of some standards we have used in the past.   In Agile fashion, our standards can and have changed as we worked through their implementation. Some examples are:

  • Project Names and Project Folder Structure
  • Model Names and Folder Structure
  • Builder Names / Setting
  • Java Objects
  • Custom JavaScript

Besides the naming conventions, you need to establish what patterns are required. We came into one project where there were no output variables in the providers. It turns out that the developers were new to WEF and they used Shared Variables in the provider and consumer models to pass data. It worked but it broke the standard separation of layers that the provider / consumer pattern provides. Another important area is the balance between using a WEF builder and custom JavaScript. Our policy is to always try to use a builder first and then resort to custom JavaScript if the builder did not fit the requirement.

The standards established above should be published. You could use a wiki or a document, but the developers and leads need to know the standards.

Essential: Code Reviews

Standards are of no use unless they are followed and that leads to code reviews. Depending on the size of the team, the review can be very formal or just having a peer review. Code should be reviewed as it is being released to the Development environment so that it will be corrected before moving up to higher environments.

Note that you need to review not just the models and builders, but you also will have Java code, JavaScript, and Html to review.

Essential: Application Documentation

Documentation has many different levels and layers. This article is about documentation located in the WEF project

One common way to document models is using Comment Builders to organize builders.   We have established a basic outline of comments for our service provider and consumer models. A shell model is used for each one in our common folder. This allows the developer to just copy and paste the comments into a new builder. You also can create your own builder based on the Comment builder where you formatted the comment pane based on the type of Comment.

Experience Factory has a “Model Report” that can be run from the Eclipse designer. The information is good, but we want to pull out key information that can help us analysis or debug our application. For example we want to know all of the “Post-Action Behavior” selections in a model since one incorrect selection can affect the whole page. Peter Wilkerson (Davalen) has done some great work in this area.   He has created documentation of the model directly from the generated XML.

Any decision made in the project that is not a “normal” setting should be documented. For example if it is decided in a Service Consumer builder to check the “Use Request-Scoped Result Variables”, this is something that needs documented for future developers. One way to do this is to put a short comment in the builder itself and then use the technique in the previous paragraph to pull out the comments into a summary document.

One other area of documentation to mention is any integration points with other applications. That would include products of the Digital Experience Suite such as IBM Connections and IBM Web Content Management. Those “integration points” will be important for the next essential.

Essential: Testing

Testing is also one of the essential items in the success or failure of your digital experience. An application with many integration points becomes a challenge for the developer to test as changes and updates are made. Those often become “points of truth” when the application has errors. You may be told “Portal is down” when it turns out that the “point of truth” is that the Connections server is down or the Web Services have been changed.

One tool that we use is Selenium for automating our application. Using the tool we were able to automate the successful “happy path” and over time add alternate paths. This allows the developer to quickly regression test the latest changes.

For applications that use SOAP services we use SoapUI to setup the valid requests to the services. As we setup the application we can test the services and then later if something is down then we can first test the service and then work up if it is working.

Overall for testing, we try to maintain the loose coupling of layers so that each layer can have its own set of tests.

This has been a brief look at some essentials for your application. They each have much more depth. It’s the customer and the solution that are the focus. The essentials help us to “deliver exceptional customer experiences.”

————————————————————————————————————————————

About the author: David Wade is a Portal / Web Experience Factory Consultant with expertise as a developer, team lead, and architect. Before joining Davalen, David was an employee of IBM as a Senior Specialist and as the Portlet Factory Lead for GBS and recently an independent consultant. He has worked on major Portal projects across the United States.  David’s Portal / Portlet Factory background began as a consultant at a manufacturing company in SC. After IBM purchased Portlet Factory from Bowstreet in 2005, he developed and implemented a complete production line system using Portlet Factory on WebSphere Portal connecting with the iSeries. Prior to his Portal experience David spent 20+ years as an iSeries Applications consultant delivering solutions in the manufacturing, education, and media industries.

————————————————————————————————————————————
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.

Come Discuss Your “Kneads” with Davalen at IBM Digital Experience 2014

digital_exp2014We all know a full day on your feet going from presentation to presentation can be invigorating for your mind but sore on the body! As 7 time sponsors and attendees of the IBM Digital Experience event, Davalen is all too familiar.

 

How will you combat your fatigue? With a free massage and thinking putty of course!

For the third year in a row Davalen will be providing free chair massages (and the massage therapists to go along with them) to all attendees during open expo hours!

First come, first serve you won’t want to miss this chance to grab a bite to eat, get some relaxation, and discuss your business and technology needs! It’s a win-win!

Don’t have time for a 5-10 minute chair massage? Come grab some Thinking Putty and let your fingers work out during your sessions!

photo

 

 

 

 

 

Look for the complimentary ticket in your conference bag OR simply show up to our Booth #101 – It’s the big one in the expo hall, it should be hard to miss!

 

Massage/Booth Hours:

MONDAY, JULY 21: 5:30 PM – 7:30 PM Welcome Reception and Solutions Expo

TUESDAY, JULY 22: 12:15 PM – 1:45 PM Lunch and Solutions Expo

TUESDAY, JULY 22: 5:30 PM – 7:30 PM Reception and Solutions Expo

WEDNESDAY, JULY 23: 12:15 PM – 1:45 PM Lunch and Solutions Expo

 

And don’t miss the Davalen Presentations:

How ANICO Brought Subsidiary Systems Together to Communication with Policyholders & Claimants in IBM WebSphere Portal

BUS-S05

Tuesday, July 22, 2014

11:15 AM – 12:15 PM

Pacific Ballroom A, Hilton Anaheim

Learn how this organization developed the business case and implemented the project to build an integration solution between disparate systems to more effectively communicate with policyholders and external claimants in their Property and Casualty subsidiaries of American National Insurance Company.  Understand the achievements of this multi-channel solution, best practices and lessons learned, and future directions.  Read more.

 

PDF Generation and Linked Java Object Management in IBM Web Experience Factory

TECH-D23

Tuesday, July 22

03:15 PM – 04:15 PM

Pacific Ballroom B, Hilton Anaheim

This session will use an example scenario to illustrate multiple best practices and general approach to two development problems: generating PDF documents from application data, and how to manage Linked Java Objects (LJOs) in a Web Experience Factory application. The session’s primary focus will be more at the architecture level than at the coding leve, but we’ll certainly be looking at code directly as well. There should be plenty to get your idea factory churning! (Level: Intermediate). Read more.

 

Davalen – Your Platinum Sponsor
800-827-8451
http://www.davalen.com

Booth #101

Come Discuss Your “Kneads” with Your Award-Winning and Trusted Solutions Advisor of 20+ Years

Come visit us at Booth #101 for a complimentary chair massage and thinking putty to help work out the kinks and discuss your business needs.

Award-winning, certified staff, IBM Business Partner for more than twenty years, and a reputation for excellence, Davalen is recognized for leadership among advanced IBM technologies and the practical application of that technology in a business environment.

Davalen takes burdensome business processes and replaces them with a modern Digital Experience that creates competitive advantage. This transformation is facilitated by a service layer design that exposes business Big Data to user experience designers in a way that makes new approaches to online business processes possible.

Specializing in Web Content Management, external and internal portal implementations, mobile solutions, Web Experience Factory development, search and analytics, and SmartCloud for Social Business integrations, when it comes to IBM technology, Davalen’s consultants and contractors have been project managers, architects, mentors and developers on the largest projects cross-industry.

Senior Consultant, Kevin Wilmeth, to Present at IBM Digital Experience 2014 on PDF Generation and Linked Java Object (LJO) Management in IBM Web Experience Factory (WEF)

kevin-wilmethKevin Wilmeth is a senior consultant and instructor at Davalen and 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.

 

Tuesday, July 22

03:15 PM – 04:15 PM

Pacific Ballroom B

 

Track 5: Developing Exceptional Digital Experiences

TECH-D23 PDF Generation and Linked Java Object Management in IBM Web Experience Factory

This session will use an example scenario to illustrate multiple best practices and general approach to two development problems: generating PDF documents from application data, and how to manage Linked Java Objects (LJOs) in a Web Experience Factory application. We will look at how to push application data through XSL-FO stylesheets to generate PDFs dynamically, how to render generated documents in the application, and how to delegate different component tasks to the service and UI application layers. We’ll also take a look at how to construct a friendly and understandable LJO architecture to support integrations that use lots of LJOs. The session’s primary focus will be more at the architecture level than at the coding leve, but we’ll certainly be looking at code directly as well. There should be plenty to get your idea factory churning! (Level: Intermediate).

Master Series: Improve User’s Digital Experience by Extending Their Profile

DWilkerson by David Wilkerson

WCM and portlet developers can benefit from a sandbox where the LDAP configuration matches that of their production environment. This is especially true when the LDAP schema of a production system has been extended.  This article explains why and how to implement an enhanced LDAP configuration on a sandbox portal environment. 

 

In IBM WebSphere Portal a user’s experience can be driven by many factors. Among these is their profile. A user’s profile consists of data known about them through attributes defined and populated in the user repository. One extraordinarily popular repository is an LDAP server. The Lightweight Directory Access Protocol provides a standardized schema by which each member can be identified. The simplest use of LDAP is for authentication in which the user’s name and password attributes are evaluated through a challenge mechanism managed by the IBM WebSphere Application Server. 

 

Name and password are just two of many attributes that describe a user and these attributes are members of the user’s profile. Other attributes may include email address, department, country, state, etc. As members of a portal, these attributes can be employed in personalization rules to drive content to the user and further enrich their experience. 

 

Sometimes an organization may choose to extend their LDAP schema to include additional attributes. A company, for example, may decide to add a new attribute in order to describe each user’s testing id. Another example might be an organization’s decision to capture a user’s auto registration for the purpose of managing parking permits. 

 

When an LDAP schema is extended it isn’t automatically recognized by IBM WebSphere Application Server or by IBM WebSphere Portal. In order for personalization rules to have access to these new profile attributes the configuration of the application server and the portal must be updated. 

 

When IBM WebSphere Portal is installed an application for adding attributes was delivered but not installed. The first step in configuring support for the new LDAP attribute is to execute a ConfigEngine script to install it.  The application, wimsystem.ear, is installed by opening a command prompt or terminal, navigating to the ConfigEngine directory, and executing the following command:

 

./ConfigEngine.sh wp-la-install-ear -DWasUserid=<youradminuser> -DWasPassword=<youradminpassword>

 

On Windows the command would be:

ConfigEngine.bat wp-la-install-ear -DWasUserid=<youradminuser> -DWasPassword=<youradminpassword>

 

You should inspect the console and confirm that the message, “BUILD SUCCESSFUL” appears. If not, examine the ConfigEngine logs located in the log folder of the ConfigEngine directory and determine the root cause of the failure. Typically it is due to incorrect or missing credentials. 

 

Next you will need to confirm that the application started. You can do this by logging in to the IBM Integrated Solutions Console. The URL will vary but on a stand alone system it will be https://localhost:10032/ibm/console.  Search for the wimsystem application and, if it is not started, start it.

 

Next you will need to prepare a property file for execution of another ConfigEngine task. Locate the wkplc.properties file and make a backup copy. The file is located in the profile root ConfigEngine properties folder. On my Windows system this is C:\IBM\WebSphere\wp_profile\ConfigEngine\properties.

After making a backup, open the file with a text editor and locate the following properties: la.providerURL=corbaloc:iiop, la.propertyName, la.entityTypes=PersonAccount, la.dataType.

In my example I updated them to match my environment goals. The first property identifies the SOAP port for the configuration interface. The second is a list of new attributes (in this case I have one-TESTINGID), the type of entity being modified PersonAccount. Finally, the data type is String.

 

Once the wkplc.properties file is updated you need to run another ConfigEngine task, wp-add-property.  As with the earlier example, you will need to include credentials for the application server administrator. In order for the changes to be effective you will need to restart the portal. 

 

The configuration work is complete but it is important to confirm that the changes were successful. Run another ConfigEngine task to obtain a list or available attributes and verify that the TESTINGID attribute is in the list. No parameters are needed for wp-query-attribute-config. The script will simply provides an output of the current state of the configuration in the logs directory of the ConfigEngine directory.

 

Now you can proceed to develop solutions such as JSP components for WCM, custom portlets using the PUMA (Portal User Management API) with RAD or WebAppAccess with Web Experience Factory.

 

————————————————————————————————————————————

About the Author:  David Wilkerson’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 accreditation’s 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.

Davalen Managing Partner to Present at IBM Digital Experience Conference

 

Davalen is proud to announce that IBM has invited Davalen managing partner, Dave Jacob, to present at the upcoming IBM Digital Experience event in Anaheim, California July 21-24, 2014.

 

DJacobIn his 21 years at Davalen, Dave has managed numerous IBM WebSphere Portal projects. Most recently he was the Davalen architect and Project Manager on the American National Insurance Company (ANICO) project coordinating the Davalen development effort with the ANICO team.

 

AbrahamFarrisAlongside Dave, Abraham “Abe” Farris, Lead WEF/Portal Developer of Field Systems at ANICO will present. Abraham has been in the tech industry since 1998 and joined ANICO in 2001.  In 2010, ANICO brought in WebSphere Portal and Web Experience Factory.  Abraham is responsible for the portal architecture and WEF best practices.

 

 

Tuesday, July 22, 2014

11:15 AM – 12:15 PM

Pacific Ballroom A, Hilton Anaheim

 

BUS-S05 How ANICO Brought Subsidiary Systems Together to Communication with Policyholders & Claimants in IBM WebSphere Portal

Learn how this organization developed the business case and implemented the project to build an integration solution between disparate systems to more effectively communicate with policyholders and external claimants in their Property and Casualty subsidiaries of American National Insurance Company.  The presenters will share details including requirements to implement a secure integration strategy to authenticate through and communicate with third party systems, including Guidewire ClaimCenter® and IBM Resource Access Control Facility (RACF).   Moving forward, specific design considerations included Single Sign On (SSO) capabilities from the P&C systems to IBM WebSphere Portal. Additional considerations required use of claims system data via web services to capture all relevant data about the claim, and an imaging system, CM8, to store the relevant claim information and documents as the source of record.   Understand the achievements of this multi-channel solution, best practices and lessons learned, and future directions.

Master Series: Integrating Active Server Pages (ASP) Applications with WebSphere Portal using IBM Web Application Bridge

Len Barker Davalen

by Len Barker

Portal technology is used to aggregate data from many sources behind a single “pane of glass’. This is done by creating portlets to retrieve the data from several data sources and then massaging the data so it can be presented in a way that is useful and attractive to the user. The architect of a new portal project must decide what combination of new pages and portlets must be created to best meet the needs of the customer.

In some cases it may be best to integrate an existing web application into the portal rather than building a new one. This choice may be made for a variety of reasons: the cost of re-writing the existing application is too high, the old application must continue to be maintained and you don’t want to maintain two systems, or the project schedule would not accommodate a re-write. After the decision has been made to integrate the application into portal, the question of how must be answered.

Web pages or web applications can be integrated into IBM WebSphere Portal using standard iFrames or the IBM Web Application Bridge (WAB). In a recent project, I’ll refer to as the Insurance project, our client elected to use WAB because of the additional security that it provides. In this article, I will show you how to create a framework to allow the application that resides in the web dock portlet (a WAB component) to communicate with WebSphere Portal.

The WAB is an integral part of IBM WebSphere Portal 8.0 and above. Prior versions of Portal required the components to be downloaded from Greenhouse. There is an excellent article (http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Integrating_the_Web_Application_Bridge_(WAB)_with_IBM_WebSphere_Portal_8.0_A_step-by-step_guide) on the IBM Portal Wiki that explains what WAB is and how to configure it.

Critical to the decision about whether to use WAB as a method of integrating an existing application into a Portal site is whether or not you can make the contained application look the same as any other portlet on the site and whether or not the application can participate in Portal communications.

Styling of the contained application can be handled by importing Portal theme files into the contained application. The contained application cannot make direct reference to the Portal theme because the application resides on another server and therefore wouldn’t understand the reference to Portal artifacts.

Selecting a method of communicating between Portal and the application contained in WAB must take into account the needs of the application. It is possible that there is no communications required. In the case of my Insurance project, the contained application needed a “publish and subscribe” framework where either Portal or the application could request or receive information at any time. I conducted a proof of concept to test various ideas for accomplishing this. One idea was to use the Portal event support that is built into WAB. This method was not able to handle all of my required use cases. The second method was to use some sort of javascript pub/sub framework. I selected a jquery framework (https://gist.github.com/cowboy/661855) as starting point. Since I needed a framework that needed to be able to listen for events published in the past, I ended up using the slightly modified version suggested by Sam Tsvilik:

 

Figure 1

Figure 1

To make this all work I created a utility portlet that I called the Communications portlet and put it on the same page as the Web Dock Portlet. All of the javascript and logic needed to enable communication between the contained application and Portal resided in the Communications portlet. IBM Web Experience Factory was used to create the Communications portlet.

Both Portal and the application had data or action requests that they listened for. For example, the contained application in Figure 2 listened for client data from Portal when the page loaded so that the input fields could be prepopulated with client data in memory:

Figure 2

Figure 2

 

The code in Figure 3 resides in the Communications portlet. Its function is to retrieve the client information from a server side variable and publish it when the page loads. The application in the Web Dock Portlet uses code like: parent.$.subscribe(“ClientAttributes”,handleClientData(‘clientdata’)) to listen for changes to ClientAttributes and update the UI when that happens.

Figure 3

Figure 3

The contained application in my Insurance project has buttons that launch dialog boxes in Portal (portlets) and return data back to the contained application. For example, the button onclick event calls parent.$.publish(‘showBenefitCalculator’). The Communications Portlet in Portal subscribes to this event and when it sees it triggered opens the dialog box and calls its own publish to send back the results. This is accomplished using the code in Figure 4.

Figure 4

Figure 4

Portals aggregate information from many different sources, usually by creating custom portlets. Web Application Bridge provides an option for adding an entire existing application to your portal. This has been a high level look at using WAB to expose an ASP application inside of WebSphere Portal illustrating just how seamless this integration can be.

————————————————————————————————————————————

About the Author: Len Barker spent 15 years in the nuclear industry managing complex, multiple system projects before founding Davalen’s predecessor, 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.

————————————————————————————————————————————
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 Archive feed here.

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.

pic1

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.

 pic2

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.

 pic3

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:

<Step>
               <BackButton>false</BackButton>
               <NextButton>true</NextButton>
               <FinishButton>false</FinishButton>
               <Page>step1</Page>
</Step>

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.

 2

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.

pic5

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.

Notes:

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.

Attachment: DojoDialogForm.zip

————————————————————————————————————————————
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
CTO

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.

2014-01-28_07-20-27

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 8.0.0.5 (8.0.5.20121022_1902). 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.

2014-01-22_11-06-31

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.

2014-01-22_15-46-18

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

2014-01-22_12-02-15

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.

2014-01-22_12-05-38

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).

2014-01-22_12-05-56

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.

2014-01-22_15-46-19

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”.

2014-01-22_15-46-36

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…”

2014-01-22_15-49-03

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.

2014-01-22_15-49-15

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.

2014-01-22_15-49-43

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.

2014-01-22_15-50-15

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.

2014-01-22_15-50-45

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.

2014-01-22_15-51-03

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.

2014-01-22_15-52-56

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.

2014-01-22_15-53-10

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

2014-01-22_15-53-26

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/mod_rewrite.so

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 http://www.davalen.com 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.

Conclusion

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:

1

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:

Constants

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.

Logging

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:

2

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:

3

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:

4

And meanwhile, over in some service transforms:

5

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.