Overview

Providing effective and consistent service to customers across a broad range of channels improves your customer's experience. Customers interacting with your company's Web site should have easy access to support, and advice from customer service representatives (CSRs) such as financial analysts (FAs), directly over the Web, without having to pick up the telephone.

A customer browsing the Web site of a financial institution may decide he or she needs to get some investment advice. Rather than dialing an 800 number, the customer could press a button on the Web page and be connected with a service representative in a live online chat session. Having already logged in to the Web site, the customer's identity is known when the service request is made. The customer's information can be retrieved before the service session begins, and the customer is connected to a representative with the right set of skills to help this particular customer. The representative can then be prepared with the customer's history, and the available business offerings that may be of interest to that customer. Behind the scenes, it should be easy for representatives to consult one another privately to provide the best advice to the customer. Capturing the advice provided to the customer during a service interaction can also prove to be a valuable business asset for the customer's history.

You can support online chats between your customers and service representatives, by adding just a few custom components. The primary component required is the collaboration manager, which can be implemented in WebSphere Portal Server as a portlet service. A few applets built with the Sametime toolkit, together with some simple portlets, provide the user interface.

This article discusses how to build the custom components, based on work my IBM System House team did to test this scenario, but first I'll describe the architecture and prototype walk-thru to give a visual context about what we were trying to achieve when we tested this scenario.

Back to top

Architecture

Figure 1 shows the basic solution architecture. The left side shows customers and representatives accessing the company Web site through their browsers. Each sees the public portal as well as their personal portal pages.

Lotus Sametime server provides the services needed to host the online chat sessions among customers and CSRs. WebSphere Application Server (Application Server) hosts the enterprise applications, including WebSphere Portal Server (Portal Server). Portal Server provides the infrastructure for defining the company Web site in terms of public and personalized Web pages, called portals. Each portal contains a set of portlets that provide the content displayed to the end user. Specialized portlets (FA/CSR collaboration portlet and customer collaboration portlet, for example) let customers request online chats, and let representatives accept those requests and chat with customers online. The collaboration manager, implemented as a portlet service, manages the queue of customers waiting for online chats, knows which representatives are online and available to service customers, and matches customers to representatives.

Sametime server and Application Server share a single User Repository. This configuration facilitates single sign-on (SSO) to Sametime using a Lightweight Third Party Authentication (LTPA) token generated by Application Server. (For more information on configuring SSO for WebSphere and Domino see the WebSphere Application Server InfoCenter, installed with the product.)

The components in orange in Figure 1 are the custom-built parts under the scenario prototype.

Back to top

Prototype walk-through

The prototype user interface gives some context for the details of the system. In the prototype we invented a fictitious bank called CL Financial. The customer, named andrew navigates to the bank's public page and logs in to his personal portal. The Welcome panel in Figure 2 includes the following portlet:

The Consult an FA online... button lets customers request an online chat session with a representative. In the prototype, we put the button on the Welcome panel, but it could be replaced with a simple notice telling the customer to look for the button on other panels. When the user clicks the button, an applet is launched that performs a login to the Sametime server. Figure 3 shows the customer applet has completed its login to Sametime and is now waiting for a representative to join the chat.

Customers can leave this window in the background and browse the Web site while they wait.

The representative (Dave Stokes, in this example) also logs in to the bank's Web site and navigates to the "Collaboration Center" portal place. In the Collaboration Center, the representative can see the queue of customers waiting to be served. The queue in Figure 4 shows four chat sessions in progress and one chat that was just accepted by another representative, Paul Sims.

Two other requests are waiting to be served. The request at the top, submitted by the customer elizabeth, has just been submitted and the collaboration manager is currently waiting for the customer applet to complete its Sametime login.

Before serving customers the representative must register. Pressing Register launches an applet that performs a Sametime login for the representative, and displays an awareness list of all the representatives currently logged in, as shown in Figure 5. The awareness list lets representatives easily launch private chat sessions among themselves in case they need to consult on a customer's question.

Now that the representative is registered, the Collaboration Center portlet looks like Figure 6.

The request issued by elizabeth is now in a waiting state, meaning the customer applet has completed its login to the Sametime server. A new request has also been issued by the customer mario.

The representative can now serve a customer chat request by pressing Serve Next. When he or she presses this button, several things happen. First, the collaboration manager will match the representative to a customer request (in this case, the request issued by andrew). When the representative's Collaboration Center portlet is redrawn it will look like Figure 7.

The collaboration manager has matched this representative with the request issued by andrew. That request is now marked as "Request accepted," and will be changed to "Chat in progress" when both the representative and the customer have entered the chat place.

Next, the collaboration manager will create a place name for the chat session, and send that name to the waiting customer's applet and to the CSR's applet. The CSR's applet will launch a secondary window to host the chat session on the CSR side; on the customer side, the chat will take place within the main applet window. Finally, the CSR and the customer enter the chat place and begin the chat. The CSR's chat window looks similar to Figure 8.

Note that the customer's ID is shown in the window title bar. This lets the representative remember which window applies to which customer in case he or she is serving several customers simultaneously.

The customer's chat window looks like Figure 9.

The customer does not see the representative's real name. In the prototype we use csr as the identity that is displayed to the customer.

The representative answers the customer's questions online, and when both are satisfied they can close their applet windows. On the customer side, the applet shutdown includes a logout from Sametime that is detected by the collaboration manager which, in turn, closes the chat request. On the CSR side, closing the window simply causes the representative to leave the chat place. Sametime will automatically remove the place when all parties have left it.

Back to top

Design and development tasks

The following sections describe the parts that were designed and developed under the prototype.

Chat logging

The text of an online chat session between a representative and a customer might be valuable business information. You can capture and save this text using the Sametime chat logging facility. In our prototype we used the Sametime Directory and Data Access Toolkit. The implementation consists of a library (.dll) that is linked into the Sametime server runtime. We didn't encounter any specific problems during prototyping. The chat text could also be captured in memory before being persisted.

Sametime programming

The collaboration manager is implemented as a portlet service, and is built using the Sametime Community Server Toolkit. The CSR and customer applets are built using the more basic Sametime Java Toolkit. All three of these components must start a Sametime session and use some Sametime services. Invocation of Sametime service operations is asynchronous; method calls return void and you must set up a listener to be notified of the operation completion and result.

Below is a simple example that includes a Sametime user login using loginByToken().

import com.lotus.sametime.core.comparch.STSession;
import com.lotus.sametime.core.comparch.DuplicateObjectException;

import com.lotus.sametime.community.CommunityService;
import com.lotus.sametime.community.ServiceListener;
import com.lotus.sametime.community.ServiceEvent;
import com.lotus.sametime.community.LoginListener;
import com.lotus.sametime.community.LoginEvent;

public class CustomerApplet extends Applet implements LoginListener {
	private STSession sametimeSession = null;
	private CommunityService communityService = null;
	private static final String[] COMPONENT_NAMES = {
		CommunityService.COMP_NAME,
		// other Sametime components as needed
	};

	// ... other applet code

	protected void initSametimeServices() throws 
	   DuplicateObjectException {
		int sysId = System.identityHashCode(this);
		String uniqueName = "CustomerApplet " + sysId; 
		// make up a unique name
		// The following constructor may throw 
		// DuplicateObjectException
		this.sametimeSession = new STSession(uniqueName);
		this.sametimeSession.loadComponents(COMPONENT_NAMES);
		this.sametimeSession.start();
		getCommunityService().addLoginListener(this);
		doLogin();
	} // initSametimeServices()

	protected STSession getSametimeSession() {
		return this.sametimeSession; 
		// must be constructed during initialization
	} // getSametimeSession()

	protected CommunityService getCommunityService() {
		if (this.communityService == null) {
			this.communityService = (CommunityService)
				getSametimeSession().getCompApi(
					CommunityService.COMP_NAME);
		} // endif
		return this.communityService;
	} // getCommunityService()

	protected void doLogin() {
		// The arguments to the login should be supplied to the 
		//  applet as parameters
		getCommunityService().loginByToken(
					getSametimeServerName(),
					getUserDN(),
					getLtpaToken() );
		System.out.println("Waiting for login event");
	} // doLogin()

	public void loggedIn(LoginEvent loginEvent) {
		System.out.println("User login was successful");
		...
	} // loggedIn()

	public void loggedOut(LoginEvent logoutEvent) {
	// If you receive this message while you're trying to login
	//  then the login failed
	// Otherwise your logout operation was successful
	} // loggedOut()

} // CustomerApplet

Collaboration manager

The collaboration manager serves four primary roles:

• Maintains the queue of customers waiting to engage in a chat with a representative
• Maintains the set of representatives registered to accept customer chat requests
• Matches waiting customers to available representatives
• Creates the chat place and notifies the customer and CSR applets to enter it.

The implementation of the queue in the prototype was a simple in-memory member field in the collaboration manager implementation class. The queue was defined using a Java interface definition called RequestQueue, and supported basic functions including add, remove, find, and list. We also defined a QueueEntry class to store information about the customer requests, such as the requestor's ID, creation time, and status. The QueueEntry also stores the Sametime user instance (STUserInstance) values for the customer. This value is obtained when the customer's applet completes its login operation. It is used by the collaboration manager to facilitate the notification process when the chat place is created.

The CSR registry is also implemented as a simple in-memory member field in the collaboration manager. It is defined by a CsrRegistry interface that supports register, unregister, and find operations. An entry in the registry is defined by the RegisteredCsr type, which stores the CSR's user ID and Sametime user instance.

To match a customer chat request to an available representative, a representative presses the Serve Next button and the collaboration manager must invoke some matching algorithm to find a suitable waiting customer. The matching algorithm may be very simple or arbitrarily complex. For example, the customer might have a history of dealing with a certain representative, or might need help in a certain area of expertise. The simplest matching algorithm, and the one implemented in the prototype, is to store all customers in a single queue and allow any representative to service the next waiting customer. In the prototype, the matching implementation was delegated to the queue; the queue simply returned the next entry.

The chat session will occur inside a Sametime place. A place is preferred over a one-on-one instant messaging session because the former can contain many participants, whereas the latter must be "upgraded" to allow additional participants, such as other representatives or supervisors. It is simpler to start with a place than to upgrade a simple instant messaging session. The collaboration manager implementation can use the Sametime Community Services toolkit to create the place. Places like the ones created by the collaboration manager are automatically destroyed by the Sametime Server when the last person has left it.

There are two options to consider when deciding the timing of the Sametime place creation. You can create the place:

• When the customer requests service, which puts a much heavier burden on the system because a place must exist for every waiting customer.
• When the representative accepts the chat request, which means only one place for each ongoing chat session. To ease the burden on the system, we used this option in the prototype.

One-on-one instant messaging instances are more lightweight than places. However, with the number of places being proportional to the number of representatives (not nearly as many as the number of waiting customers), the benefit of reduced system burden is offset by the ease of implementation.

The collaboration manager implements the following Java interface:

QueueEntry requestChat(String customerUid)

• Issued when the customer requests an online chat.
• Customer's user identity is obtained from the request, and the chat request is added to the queue.
• Based on the customer identity (saved as part of the chat request in the queue), the collaboration manager may prioritize the request.

QueueEntry serveNextChatRequest(String csrUid)

• Issued when the representative clicks Serve Next.
• The matching algorithm is used to determine which request should be served.

QueueEntry getQueueEntryFor(String customerUid)

• Used to acquire the queue entry for a customer user ID; if no queue entry exists, null is returned.
• Issued to determine whether the customer should see the button for issuing a chat request. If no entry exists for a customer, then Consult an FA online... is displayed. If a queue entry exists, but the customer's Sametime login has not yet been detected, the customer chat applet is launched instead. If a queue entry exists and the customer is already logged in to Sametime, nothing is displayed.

QueueEntry[] listAllInQueue()

Used to acquire a list of all queue entries. We used this in the prototype to display the queue.

void registerCsr(String csrUid)

• Issued when the representative clicks Register in the Collaboration Center.
• Enters the representative in the CSR registry so he or she can serve customer chat requests.

RegisteredCsr getRegisteredCsrFor(String csrUid)

• Used to acquire a registration entry for a representative. If no entry exists, null is returned.
• Used to determine how to display the buttons in the Collaboration Center. If no entry exists, Register is displayed. If an entry exists but the representative's Sametime login has not yet been detected, then the CSR chat applet is launched. Whenever the entry exists, Serve Next is displayed.

String getSametimeServerName()

Returns the host name of the Sametime server. This value is acquired by the customer and CSR portlets, and passed on to their respective applets to let them perform a Sametime login.

String getSametimeBaseURL()

Returns the base URL used to access the Sametime server. This value is acquired by the customer and CSR portlets, and passed on to their respective JavaServer Pages (JSP) components to allow the applet code to be accessed.

String getSametimePort()

Returns the host name of the Sametime server. This value is acquired by the customer and CSR portlets, and passed on to their respective applets to let them perform a Sametime login.

The QueueEntry datatype implements the following Java interface:

String getRequestorUserId()

Returns a user ID of the customer represented by the queue entry.

long getCreatedAt()

Returns the creation timestamp of the queue entry.

int getStatus()

Returns an integer representation of the queue entry status. One of:

• WAITING_FOR_CUSTOMER_LOGIN
• CUSTOMER_LOGGED_IN
• CSR_ACCEPTED
• CHAT_IN_PROGRESS
• CHAT_COMPLETE

void setCustomerUserInstance(STUserInstance customerSametimeUserInstance)

• Assigns the customer's Sametime user instance to the queue entry.
• Issued when the customer's Sametime login is detected.

STUserInstance getCustomerUserInstance()

Returns the customer's Sametime user instance object.

void setPlaceName(String placeName)

• Assigns the name of the Sametime place that will host the chat session.
• Issued when the collaboration manager creates the place.

String getPlaceName()

• Returns the name of the Sametime place that hosts the chat.
• Can be used to allow other representatives or supervisors to enter the chat place.

The collaboration manager delegates management of customer requests to a separate RequestQueue entity, which implements the following Java interface:

QueueEntry getFromQueue(String userUid)

Returns a queue entry for the given user ID. If no entry exists in the queue, null is returned.

QueueEntry addToQueue(String userUid)

Adds a queue entry for the given user ID. The new queue entry is returned.

void removeFromQueue(String userUid) throws NoSuchEntryException

Removes the queue entry for the given user ID. If no entry exists in the queue, NoSuchEntryException is thrown.

QueueEntry getMatchFor(STUserInstance csrSametimeUserInstance)

• Finds a matching customer request to be served by the specified CSR.
• The representative's Sametime user instance is stored in the queue entry so that the collaboration manager can contact the representative's Sametime login instance and tell it to enter the chat place.

The collaboration manager is implemented as a portlet service deployed in the Portal Server, allowing the customer and CSR portlets easy access to the collaboration manager interface through APIs provided by Portal Server.

You can easily create a portlet service by following these steps:

1. Define a CollabManService Java interface that extends CollaborationManager and the PortletService interface defined by Portal Server.
2. Define the CollabManServiceImpl Java class implementing the CollabManService interface.
3. Add the following to the portlet services properties file:

   #Collaboration manager service com.ibm.test.collabman.CollabManService = com.ibm.test.collabman. CollabManServiceImpl com.ibm.test.collabman.CollabManServiceImpl.factory = org.apache. jetspeed.portletcontainer.service.PortletServiceCacheFactory

   
   

You can also define initialization parameters for the service here. The parameter values can be read by the portlet service during initialization. In the prototype, we used an initialization parameter to define the location of the Sametime server.

The collaboration manager must log in to the Sametime server so that it has the authority to interact with customer and CSR Sametime user instances. Using the Sametime Community Server toolkit, the collaboration manager can log in to Sametime as a server application. This requires a change to the Sametime configuration to specify the host name on which the collaboration manager executes as a trusted host. Below is some sample code for this type of login.

import com.lotus.sametime.community.ServerAppService;
import com.lotus.sametime.community.LoginListener;
import com.lotus.sametime.community.LoginEvent;

// Other code...

	protected ServerAppService getServerAppService()
		if (this.serverAppService == null) {
			this. serverAppService = (ServerAppService)
				getSametimeSession().getCompApi(
					ServerAppService.COMP_NAME);
		} // endif
		return this. serverAppService;
	} //getServerAppService()

	protected void doLogin() {
		getServerAppService().loginAsServerApp(
					getSametimeServerName(),
					STUserInstance.LT_SERVER_APP, 
					// login type
					"Collaboration Manager",
					null);
		System.out.println("Waiting for login event");
	} // doLogin()

	public void loggedIn(LoginEvent loginEvent) {
		System.out.println("Collaboration Manager login was 
		   successful");
		...
	} // loggedIn()

	public void loggedOut(LoginEvent logoutEvent) {
	// If you receive this message while you're trying to login
	//  then the login failed
	// Otherwise your logout operation was successful
	} // loggedOut()

To configure Sametime to allow the collaboration manager login to be successful, you must change the sametime.ini file in the Domino root directory and add the following:

VPS_TRUSTED_IPS="yourhost.yourdomain.com"

Where yourhost.yourdomain.com is the name of the host on which the collaboration manager will execute.

CSR and customer collaboration portlets

The CSR and customer collaboration portlets are built using the Portal Server portlet libraries portlet-api.jar, wps.jar, and wpsportlets.jar. These libraries can be found in the WPS/lib/app directory; in Application Developer these libraries must be added to the Java Build Path. The Portlet Development Guide has in-depth guidelines and details for portlet design and deployment. Building a portlet is both simple and well documented, so I won't go into the details here.

CSR user interface

The Collaboration Center contains a Register button that allows representatives to indicate to the collaboration manager that they're online and ready to serve customer chat requests. This operation launches a separate applet that displays an awareness list of representatives who are currently online. The representative can initiate chat sessions with other representatives by double-clicking on a name in the awareness list. The representative remains logged in to Sametime until this awareness applet is closed. Figure 10 shows the flow that occurs when the representative clicks Register.

When the CSR applet is launched, it attempts to login to the Sametime server using the CSR's user ID and Lightweight Third Party Authentication (LTPA) token. The same applies to the customer chat applet. The user ID is acquired initially by the portlet, from the request object, and passed through to the applet. The LTPA token is extracted by the applet's JSP code from the request cookies.

Subsequent displays of the CSR portlet display a Serve next button to let the representative indicate to the collaboration manager that they want to serve a customer chat request. This operation causes the collaboration manager to send an announcement to the CSR's applet that launches a separate window containing the chat session with the customer. Similarly, an announcement is sent to the customer applet that causes it to enter the chat place. The representative remains logged in to Sametime until the applet is closed. Closing the separate chat window does not log the representative out of Sametime, it simply ends the chat. Figure 11 shows the flow when the CSR clicks Serve Next.

You can display an applet inside a portlet. Because an applet manages its own display (paints itself as necessary), there is no need to refresh the browser page to update the applet display. However, it is not possible, strictly speaking, to predict an applet's lifecycle when it is contained in the portal page rather than launched in a separate window. The lifecycle of an applet goes like this:

• When the applet is loaded by the browser, the browser constructs the applet and then calls the applet's init() method followed by its start() method.
• When the user navigates the browser away from the panel containing the applet, the browser calls the applet's stop() method followed by its destroy() method. There is no guarantee or requirement that the browser must unload the applet at that time. In fact, most browsers will not unload the applet until the browser runs low on memory.
• When the user navigates back to the browser panel containing the applet, the browser simply calls the applet's start() method, provided the applet has not been unloaded.

It is possible to code the customer or CSR applet so it does not log out of Sametime when destroy() is called, and it does not reinitialize its state when start() is called. In this way, the applet could reside inside a portlet and let the representative browse to other panels without disrupting chat sessions or losing the Sametime login session. The problem that arises, however, is that the Sametime login must remain active while the representative is chatting with the customer.

Because the lifecycle of an applet is not predictable when the applet panel is not showing (the browser could decide to unload the applet when it is not showing on the current panel), the Sametime login could be lost at unpredictable times. Taking all this into account, it is a more robust design to launch the applet in a separate window.

Customer user interface

The prototype implementation of the UI for requesting a chat consists only of the Consult with an FA online... button. The applet that contains the chat session is also simple, and is similar to the window you would normally see when using a Sametime chat. Figure 13 shows the flow when the customer clicks Chat Request.

Back to top

Software used in the prototype

We used the following software for this prototype, installed and configured in the order listed below. It's possible to use other combinations of software, of course.

1. DB2 UDB EE V7.2 + fixpack 5
2. IBM HTTP Server V1.3.19.2
3. Java runtime V1.3.1
4. Global Security Toolkit (GSK) V5.0.4.67
5. IBM Secureway Directory (LDAP) v3.2.2
6. WebSphere Application Server V4.0.3
7. WebSphere Portal Server V4.1.2
8. Domino Server V5.0.10
9. Sametime Server V3.0

Back to top

Setting up and operating Sametime Server

Sametime Server v3.0 operates under Lotus Domino server, which also provides an HTTP server. This causes a conflict with the IBM HTTP server required by other products used in the scenario. You must either install Sametime on a separate machine, or change the port number on which the Domino HTTP server listens. I have tried both and either works adequately, although if you change the port number for the Domino HTTP server you must reference the Sametime Web interface (stcenter.nsf) by specifying the port in the URL.

During installation of Sametime you must specify the LDAP server that will be used as the user repository; the LDAP server must be installed, configured, and active. After installation you must go to the Sametime administration Web page and change the LDAP configuration to allow Sametime to access the LDAP directory and use it as the user repository. The necessary changes are described in the Sametime Administration Guide. Apart from defining LDAP as the user repository for Sametime, no other special configuration is needed. Both the CSR and customer applets are deployed to and served from the Sametime server.

Back to top

Setting up and operating collaboration manager

The collaboration manager is deployed as a portlet service as described in Prototype walk-through. Along with the specified additions to the portlet service properties files, the collaboration manager classes must be deployed to the application server's app library, such as WAS\lib\app.

Back to top

About the IBM System House team

The WebSphere System House Business Scenario Development (BSD) team is an integral part of an IBM Software Group initiative to ensure cross-product integration across IBM's family of software products. The BSD team identifies real business scenarios based on our customer experiences, business objectives, use cases, and the technology needed to fulfill the scenario requirements. We then implement a prototype of the scenario to discover problem areas, help IBM product teams recognize and resolve cross-product deficiencies, and ultimately deliver working solutions that satisfy the business requirements.

Our project was derived from the WebSphere System House BSD Customer Loyalty business scenario, which focuses on the financial industry and banking aspects of a B2C, or extranet, environment. This work could easily be leveraged to address requirements of industries such as retail, telecommunications, or insurance, and could be adapted to business-to-employee or B2B models.

The business objectives of the Customer Loyalty scenario are to provide:

• Consistent customer treatment over all channels -- Web, telephone, in-person, and so on.
• The ability to tailor services based on customer profile (gold, silver, and bronze).
• Personalized, secure customer access anywhere and anytime.

The implementation described in this article addresses all of the objectives.

Resources

• Participate in the discussion forum.
  
  
• The IBM Redbook Working with the Sametime Client Toolkits is a good reference for Sametime information.
  
  
• The Portlet Development Guide has plenty of detail about creating portlets.
  
  
• Sametime Administration Guide
  
  
• Get information on installing and administering WebSphere Application Server from the WebSphere Application Server InfoCenter, including information on setting up Single Sign-on with the Domino server.
  
  
• Many of the products described in this article are included in a developerWorks Toolbox subscription.
  
  
• You can find more information designed for developers on Lotus Developer Domain and on WebSphere Developer Domain.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Overview
• Architecture
• Prototype walk-through
• Design and development tasks
• Software used in the prototype
• Setting up and operating Sametime Server
• Setting up and operating collaboration manager
• About the IBM System House team
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Lotus Sametime
• Buy: Lotus Sametime

Dig deeper into Web development on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers