Master Series: Digital Experience 2014

kevin-wilmeth by Kevin Wilmeth

After a few years of being away from the conference circuit, I got the happy chance not only to present at the 2014 IBM Digital Experience conference in Anaheim, but also simply to attend it.  I’ll fully admit to being a bit of a kid in a candy store with that sort of thing, but I still think there is a great deal of useful takeaway to discuss.  Here, I’ll highlight some of that which should be of interest to developers.

The value of Portal is going up

One thing I had to keep in mind, personally, is that being away from conferences for a few years means that what others have been seeing incrementally, I got all at once.  On one hand, I’d have to watch out not to confuse the revolutionary for the evolutionary, but on the other, having a bit of a gap does tend to illustrate more clearly which trends are lasting and which ones stall.  And the one that seemed biggest and starkest to me is that the business value of using Portal is going up noticeably.

The 8.5 releases illustrate this pretty neatly.  WCM continues to mature.  Forms Experience Builder should prove to be a very effective tool, making forms-based-app development accessible to an ever-larger universe of developer skills.  The new Script Portlet may prove even more revolutionary in that regard, even if its mechanics appear to be simple.  WEF solidifies much of what was new in 8.0, migrates to a better embedded test platform, and provides a convenient path to tap into the same embrace of the JavaScript Web developer as Script Portlet does.  And administratively, core Portal is moving to a much more streamlined update architecture.

I took all this to mean that 1) Portal skills are going to become even more valuable than they are now, and also that 2) they are probably going to change in a few significant ways.  Keep that in mind as we spin through a few of the development highlights.

Forms Experience Builder (FEB)

The new Web-based tool Forms Experience Builder 8.5 (wiki for both traditional IBM Forms and FEB is here) promises to be a very viable way to produce simple portlet apps centered around forms and built-in data capture, and its extension points (including a REST consumer interface) suggest that one could quickly get into non-trivial applications as well.  I got to go through a lab and put hands on it, and was suitably impressed.  I suspect that a whole lot of simple portlets are going to come from considered use of this resource.

Script Portlet – a new landscape for developers

FEB hints at this a bit, but Script Portlet veritably screams it:  Portlet development is now simply and viably available to the mainstream Web developer.  It’s a very clever and simple idea, really:  in each instance of the Script Portlet, a “single-page” application is captured (as configuration) using a JSFiddle-style interface, the application source is stored as a content object in WCM, and the view mode of the portlet runs it.  In coding, there are hooks and shortcuts for REST services known to Portal, and streamlined referencing to other WCM artifacts.  And it is designed to be friendly to whatever JS framework(s) you may wish to use.

The implications here are potentially huge.  Just consider, for starters, that the deployment model does not have to involve anything from administrators, other than allocating Script Portlet instances.  With application source stored as WCM content, the upgrade/enhancement/versioning model is nearly a tabula rasa of creative possibility. The separation between (REST) service development and consumer development is a by-the-book illustration of functional independence on both sides.  And the available universe of competent Web developers simply dwarfs the number of traditional, dedicated Java portlet developers.  Along with the support for existing and future JS frameworks, all this is going to add up to be an enormous help to R&D, PoC and prototyping/demo efforts at the very least, but I’d be surprised if it stopped there.  One could also envision a great deal of interest for mobile-Web apps as well, and others we haven’t even thought of yet.

WEF 8.5 and Liberty Profile

With all the excitement about everything else in the stable, there are still several significant things to report about WEF 8.5.  The “client-side application” builders are more robust now than in their first release in 8.0, as is mobile and responsive design support.  There are some significant new builders such as XSLT Transform, and even some (welcome) re-introduced builders from the old Dashboard Framework, now available in the core product.  The Samples directory grows more robust.  Updated Eclipse, of course, and now you can do WEF development on Mac!

The most significant change for everyone, though, is probably the switch from WASCE to Liberty Profile for the embedded development environment.  It really is luxuriously fast to start up, and all in all is much more what an embedded dev environment should be.  It’s definitely a bit different for someone long accustomed to WASCE, particularly in administration, and documentation can feel a bit sparse, but it certainly seems better aligned with where everything is going and should at least theoretically prove more migration-friendly to other WAS and Portal platforms.

One thing that really stuck out at me, and which I’m still on the fence about, was an important consideration for those of us who have settled in to certain WEF design patterns that deliberately avoid some of the highest-level builders such as View & Form, for their historic tendency to be inflexible when we need them to be flexible.  In short, I got the distinct impression that the improvements being made to the builder set, especially on the client-application side, are now happening fast enough that continuing to avoid these patterns now seems to carry a measurable risk.  (Nobody told me that–it just seemed obvious that a great deal of the new features seem to depend on some of the builders that have proven frustrating enough that we sometimes pattern around them.)  And some of these new features do seem conspicuously powerful, especially in the mobile space.  It’s something I intend to pay some close attention to for a while, and it may be that it is time to reassess some of what have become classic patterns.

WEF Script Application

New for WEF is a nifty builder called Script Application.  Essentially, it uses the Script Portlet’s approach of encapsulating a “single-page Web application” (source references for HTML, JS, CSS and libraries) and integrates that with available WEF service providers.  Especially given WEF’s profiling capabilities, this could be a very powerful way of integrating straight Web development into WEF projects, in much the same way that Script Portlet enables portlet development with basic Web skills.  WEF is already fairly well recognized as an effective rapid prototyping environment;  it can only be the moreso with the ability to integrate WEF services and function with framework-based front-ends.

What does all this mean for a developer?

In coming to grips with this “democratization of portlet development” idea, that Script Portlet so dramatically promises to achieve, I was strongly struck by a parallel I remember personally from (yeesh!) just about a generation ago.  This moment in time, now, seems very much to me like the moment when Lotus Notes really took off as a development tool–which it did for exactly the same reason as we’re seeing here.  Back then we talked about making application development available to the “power user”–folks that weren’t necessarily schooled in hard-core development, but who could assemble the patterns they needed and who also understood the business, and in the bargain they often turned out to be highly creative types as well.  Lots of people were horrified at this idea, but it worked so well that things just exploded, and a surprisingly robust set of business apps popped up out of nowhere, many lasting far beyond their expected obsolescence.  What’s happening now may be different in terms of the technology, but the mechanism for success seems just the same to me:  the stage is now open to a new and untapped creative mass, and I suspect that we’ll see dramatic things from it again.

Of course, this is a little foreboding if you’re looking at these events as having suddenly to compete with every JS/HTML/CSS Web developer out there for work.  Sure it is!  Probably, you’ll have to change at least some of your attitude or approach, but I don’t think that the valuation of portlet development skills is going to go down so much as it’s going to change.  One of the things I certainly hope happens with all this, is that Portal/portlet development actually starts to take off because of all the new possibilities.  (That’s exactly what happened with Notes, and the boom lasted for some time.)  In that event, I suspect that people who already understand traditional (or WEF) portlet development are going to become even more valuable than they are now, not only because they’ll need to advise and mentor this new group as they find ways and needs to tap further into Portal, but as applications get more complex and greater in number, there will actually be further need for complex portlets and apps that go beyond the limitations of Script Portlet, FEB, etc.  The net effect may well be that you don’t do as many simple portlets as you used to, but you may do more complex and interesting ones instead.

I suspect, too, that WEF developers in particular may find that they spend more time working on the service providing end than on the consuming end.  It may be that out of 100 apps that would previously have been done in WEF or RAD, now half of them (to pull a number out of the air) will migrate to Script Portlet (or WEF Script Application), or FEB, or something similar…but they’ll all still need service support.

Conferences are good for developers

Finally, I was reminded how much benefit there is for a developer to attend a conference.  In my own case, three self-observations stuck out in this regard.  First, I got specific information that will help me with my own work, and there is of course obvious value in this.  Next, I got re-introduced to what I call the wide.  It’s easy to get so involved with the specifics of what you’re doing, on a day-to-day basis, that for all the obvious and valuable expertise in that area, one can get lost in the deep at the expense of the wide.  A conference such as Digital Experience can do wonders for re-establishing the right balance for that.  Lastly, and perhaps because of the aforementioned, I also got recharged.  For the kind of personality that gravitates toward development, it is important to see new and shiny things, and to get excited about them.  Not only does it improve one’s general attitude, it also improves the creative process.  In hindsight of course I recall this pattern in myself and many others from a number of years ago, but we are forgetful creatures, and it is useful to have reminders.

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

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.

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.