Add file transfer capabilities to the CollaborationDialog

The CollaborationDialog widget in the WAS CEA feature pack provides capability that is leveraged during cobrowsing sessions. Part of the function in the widget consists of sending data between the participants in a cobrowse session. This enables function like highlighting, following, and sending a page. It's this, the capability to send data back and forth between participants, that can be leveraged to produce very useful extensions to the base CollaborationDialog widget.

Take for example the previous scenario I blogged about. In that case, a few extensions to some of the CEA widgets provided an enhanced, online communications experience between a customer and an insurance company customer service representative. What if during the course of that communication the policy was updated and the customer service representative wanted to send the new policy to the customer? Well, it could be sent via email and the customer could check it at some later time. However, a simple extension to the CollaborationDialog widget to provide file transfer capabilities will allow the customer service representative to send and the customer to receive the updated policy right away.

To do this we can leverage the CollaborationDialog widget's existing ability to send data back and forth between cobrowse participants. Your first thought may be that we actually use the data sending capability to directly send file contents back and forth, but that's not what the data sending infrastructure was designed for. Rather, it was designed to send small, chatty messages. With that in mind, we use simple AJAX functionality to post a form containing a file attachment to a backend file server. Then, we leverage the data sending infrastructure to notify the other cobrowse participant that they are being sent a file, and we provide the location of that file so it can be downloaded.

We also make some changes to the HTML and CSS files for the CollaborationDialog, and combined with the necessary JavaScript additions mentioned above, we can now choose and send files as seen below:

We can also receive files from our cobrowsing partner:

The capability to send and receive files while in a cobrowse session can significantly enhance the experience of both participants. If you are interested in how you can add this extension into your WAS CEA environment, drop a comment right here and we'll be happy to set you up with some examples.

Extending the Cobrowse widget

I'm still looking at and experimenting with the WebSphere CEA Feature Pack widgets. In my last two posts I took a look at scenarios that lead to extending the WebSphere CEA ClickToCall widget. In my latest project, I took a look at the Cobrowse and CollaborationDialog widgets.

It's clear that there are many scenarios where users would want to employ and maybe even extend these two widgets. For instance, check out the demonstration below for one such scenario.



There are a few things to note about the sample as far as the extensions go. First of all, I did a very simple extension to the ClickToCall widget along the same lines of my previous posts, so I won't go into much detail about that particular piece.

Other than the ClickToCall extension, I extended both the Cobrowse (cea.widget.Cobrowse) and CollaborationDialog (cea.widget.CollaborationDialog) widgets to provide the function you see in the sample. With the Cobrowse widget, I added functionality such that when the customer service representative creates the collaboration link, a resource representing that link and the customer it is intended for is created on the backend. That was easy to do by overriding the Cobrowse widget's _convertToWaitingState method and providing custom function to create the necessary resource.

When a customer logs into the Insurance Company's home page, JavaScript running on the page checks the backend for any resources that would indicate a customer service representative has invited that particular customer to a collaboration session. In the sample video, this is shown when the customers logs into the Insurance Company's site.

Next, I needed to extend the CollaborationDialog widget in a couple of ways. First, I added the Send Policy Data button to the dialog's toolbar. All that was required to add the button was a small update to the widget's JavaScript. No HTML or CSS changes were necessary.

After that, I added a function that allows the customer service representative to send the retrieved policy information from his window to the customer's window. This was done by piggy-backing on the ability of the CollaborationDialog widget to send data back and forth between the collaboration participants. There was a nifty Dojo function that came into play when implementing this capability. Once the data was received by the CollaborationDialog instance on the customer side, the contents of the content pane in the CollaborationDialog needed to be updated. This was done by using dojo.withDoc as seen below:

dojo.withDoc(iframeDoc,
function() {
          var data = this.receivedPolicyData;
          dojo.style(dojo.byId("policyTable"), "display", "block");
          dojo.byId("policyNumText").innerHTML = data['policyNum'];
          dojo.byId("policyHolderText").innerHTML = data['policyHolder'];
          dojo.byId("policyTypeText").innerHTML = data['policyType'];
          dojo.byId("policyAmountText").innerHTML = data['policyAmount'];
          dojo.byId("policyPremiumText").innerHTML = data['policyPremium'];
          dojo.byId("policyPaymentScheduleText").innerHTML =                                                   
                     data['policyPaymentSchedule'];
          dojo.byId("policyDeductibleText").innerHTML =
                     data['policyDeductible'];
          },
          this
);

The dojo.withDoc method allowed me to update the DOM of the source HTML page for the content pane, and in this case it was extremely helpful.

The required changes to implement these widget extensions were fairly minimal considering the capabilities that were added. In fact, the backend data services for the various resources used by this sample took most of my time. If you are interested in seeing more of the code for the sample above just drop a reply to this blog post. I'd be happy to share more of the extension implementation.

More use cases for CEA widget extension

Just a few days ago I documented my first example with extending the WebSphere CEA click-to-call widget to provide a customized experience between a customer and customer service representative.That experience opened my eyes to the tons of use cases for extending the click-to-call widget (or any of the WebSphere CEA widgets for that matter).

For instance, a growing trend among restaurants is to offer food ordering online. You can go online, place your order, and either have it delivered or pick it up at some later time. So, I thought about the employee back at the restaurant monitoring these orders, and in particular I thought about how they may benefit from embedding communication capabilities in that online ordering system.

Consider my fictional pizza company, The Acme Pizza Company, and the back-end to their online ordering system. The employee back at the restaurant may view a list of the pizza orders and confirm each of those orders for the kitchen team.

When the restaurant employee clicks the Confirm Order it is probably necessary to show more information about the order and the customer who placed the order. But wouldn't it also be nice to allow the restaurant employee to simply click a button to call the customer that placed the order when it was necessary?

An easy extension to the WebSphere CEA click-to-call widget gives us both the information about the order and the embedded communication capabilities that allow the restaurant employee to connect with the customer directly from the web page.

The panel you see above is a simple dijit.Dialog widget that contains an extended version of the cea.widget.ClickToCall widget. The Acme Pizza Company employee has all the information they need to confirm the order, and they can even call the customer directly from the web page if necessary.

The possibilities for extending the WebSphere CEA widgets are endless. I hope to post more scenarios of interest involving different widgets soon. In the meantime, if you're interested in the JavaScript and HTML involved in building up this extension, you can download it here.

Extending WebSphere CEA widgets

Since it’s my first time posting here, I guess a quick introduction is in order. My name is Dustin Amrhein and I’m a technical evangelist for emerging technologies (cool stuff) in WebSphere. I do not work on the WebSphere CEA development team, but I have been experimenting with the new CEA Feature Pack for the WebSphere Application Server lately.

The first thing I did after installing the CEA Feature Pack was install and play around with the PlantsByWebSphere sample application that is included in the install. The cool features provided by the CEA Feature Pack, like co-browse, click-to-call, and call notification immediately jump out through the sample.

With the introduction to some of the features of the CEA Feature Pack behind me, I decided to peek under the covers a bit. In particular, I was interested in the Dojo widgets that provided the interface to the functionality on display. If you are familiar with Dojo, you’re well aware that one of the benefits of Dojo widgets is that they can be easily extended to deliver custom function and interfaces. With that in mind, I decided to look into extending one of the widgets delivered by the CEA Feature Pack, the click-to-call widget.

If you look at the Contact Us page of the PlantsByWebSphere, you will see an example of the click-to-call widget:

Suppose I wanted to extend this widget just a bit. I want to give my users the option to select from a list of specialist in the different areas of my site (flowers, trees, vegetables, accessories), and once they select a particular specialist I'd like to display information about the person with whom they will be in contact. After all, it's always nice to know who's on the other end!

To do this, I first start by extending the provided cea.widget.ClickToCall JavaScript:

dojo.provide("extension.ClickToCall");
dojo.require('cea.widget.ClickToCall');

dojo.declare("extension.ClickToCall", [ dijit._Widget, dijit._Templated,
  cea.widget.ClickToCall ], {

templatePath : dojo.moduleUrl('extension', 'ClickToCall/ClickToCall.html'),
templateString : "",

handleSpecialistSelect : function(item) {
 var url = "/proxy/bpp?specialist=" + item;
 var responseHandler = dojo.hitch(this, "handleContactResponse");
 var errorHandler = dojo.hitch(this, "handleContactError");
 dojo.xhrGet( {
    url : url,
  handleAs : "json",
  timeout : 5000,
  load : responseHandler,
  error : errorHandler
 });
},

handleContactResponse : function(response, ioargs) {
 this.returnedInfoRow.style.display = "block";
 this.callInfoRow.style.display = "block";
 this.contactInfoFromGet.innerHTML = "Click the Call Me button to be contacted
    by " + response['firstName'] + " " + response['lastName'] + " in "
  + response['city'] + ". Alternatively you may email "
  + response['firstName'] + " at " + response['email'] + ".";
  this.widgetNumber = response['phone'];
},

handleContactError : function(response, ioargs) {
 console.error("error getting contact info " + response + " status " +
    ioArgs.xhr.status);
}
});

The above contains the dojo declaration of my custom widget that extends the existing cea.widget.ClickToCall. The handleSpecialistSelect above will send an HTTP GET request when a user selects the particular type of specialist with whom they wish to talk. In my case, the GET request is sent to an Ajax proxy that then forwards the request for contact information along to the appropriate service. This allows us to use data in our JavaScript that is provided by a service in a different domain. The handleContactResponse populates the page with the contact information returned from the GET request.

The JavaScript above also references a new HTML template via the templatePath variable. The new template can be seen here:

<div>
<table class="clickToCallWidget">
  <tr id="contactInfoRow">
     <td>
        <table>
           <tr dojoAttachPoint="getContactRow">
              <td>I want to contact a  
               <select
                   dojoType="dijit.form.ComboBox"
                   dojoAttachEvent="onChange:handleSpecialistSelect" id="specialist"
                   name="specialist">
                   <option value="none">-- Make Selection --</option>
                   <option value="flowers">Flowers Specialist</option>
                   <option value="trees">Trees Specialist</option>
                   <option value="vegetables">Vegetables Specialist</option>
                   <option value="accessories">Accessories Specialist</option>
               </select></td>
           </tr>
           <tr dojoAttachPoint="returnedInfoRow" style="display: hidden">
              <td><span dojoAttachPoint="contactInfoFromGet"></span></td>
           </tr>
        </table>
      </td>
   </tr>
   <tr dojoAttachPoint="callInfoRow" style="display: none">
      <td>
         <table dojoAttachPoint="callInfoTable">
            <tr>
               <td><label dojoAttachPoint="phoneNumberLabel"
                  title="${myNumberString}"><input name="phoneNumber"
                  dojoType="dijit.form.TextBox" dojoAttachPoint="phoneNumber"
                  class="clickToCallWidgetTextBox" value="${myNumberString}"></input></label>
               </td>
               <td>
                  <button dojoType="dijit.form.Button" dojoAttachEvent="onClick:call"
                   dojoAttachPoint="callButton"
                   iconClass="clickToCallWidgetIcon clickToCallWidgetCallIcon"
                   class="clickToCallWidgetButton">${callButtonString}
                  </button>
               </td>
               <td>
                  <button dojoType="dijit.form.Button"
                   dojoAttachEvent="onClick:hangup" dojoAttachPoint="hangupButton"
                   iconClass="clickToCallWidgetIcon clickToCallWidgetEndCallIcon"
                   class="clickToCallWidgetButton" style="display: none">${hangupButtonString}
                  </button>
               </td>
               <td>
                  <button dojoType="dijit.form.Button"
                   dojoAttachEvent="onClick:cobrowse" dojoAttachPoint="cobrowseButton"
                   iconClass="clickToCallWidgetIcon clickToCallWidgetCollaborateIcon"
                   class="clickToCallWidgetButton" style="display: none">${cobrowseButtonString}
                  </button>
               </td>

            </tr>
            <tr>
               <td colspan="4" dojoAttachPoint="status" class="clickToCallWidgetStatus" style="display: none">
               </td>
            </tr>
         </table>
      </td>
   </tr>
</table>
<div dojoAttachPoint="collaborationDialog"
   dojoType="cea.widget.CollaborationDialog"
   canControlCollaboration="${canControlCollaboration}"
   defaultCollaborationUri="${defaultCollaborationUri}"
   highlightElementList="${highlightElementList}"
   isHighlightableCallback="${isHighlightableCallback}"
   isClickableCallback="${isClickableCallback}">
</div>
</div>

To get my extended click-to-call widget in the PlantsByWebSphere sample application I need to do a couple of things. First I need to add my new files to the application. I'll add them in the PlantsByWebSphere.war file within the PlantsByWebSphere.ear. Relative to the root of the WAR file, I'm adding the following:

• /ceadojo/cea/extension/ClickToCall.js (JavaScript file above)


• /ceadojo/cea/extension/ClickToCall/ClickToCall.html (HTML above)

I'm also going to modify the contactus.html at the root level of the PlantsByWebSphere.war to use my custom widget instead of the normal one. To accomplish this, I first add the following to the HTML head section:

<script type="text/javascript">
 ceadojo.registerModulePath("extension","../cea/extension");
 ceadojo.require("extension.ClickToCall");
 ceadojo.require("dojo.parser");
</script>

After that is taken care of, I change the value of the ceadojoType attribute. Before it referenced the cea.widget.ClickToCall widget shipped with the CEA Feature Pack. As seen below, I change the ceadojoType attribute's value to extension.ClickToCall.

<TD>

<h2>Click To Call</h2>

<div id="clickToCallWidget">

<!-- Replace 'CSR@localhost' with the user and address to be contacted when a clickToCall call is initiated -->

<div ceadojoType="extension.ClickToCall" widgetNumber="sip:CSR@localhost" enableCollaboration="true"

canControlCollaboration="true" defaultCollaborationUri="index.html">

</div>

</TD>

Now I'm ready to test out my changes. When I visit the contactus.html page, I'm greeted by a different view:

Once I select a particular specialist I want to contact, I then see information about the person who will be contacting me:


This is just one example of how the widgets provided by the WebSphere CEA Feature Pack can be extended to deliver customized function and behavior. I hope this helps give you a glimpse into the basic pattern for customizing the WebSphere CEA widgets. By the way, you can download a PDF of the JavaScript and HTML displayed above here.

Extending the CEA Cobrowsing feature

The widgets in our Communications Enabled Applications Feature Pack are very extendable. When we first created it, we thought of many ways to extend those widgets. Below is one example I have...


In that video, I talked about adding basic instant messaging to the cobrowsing window. Inserted in that interview was a recorded usage of our WebSphere Commerce sample we showed at Impact where our WebSphere Commerce team integrated the CEA cobrowsing functionality into their sample store and then extended the cobrowsing Web 2.0 widget with instant messaging support. For a javascript developer, adding this function on top of our existing cobrowsing function would take just a couple of days.

Over time on our blog here we plan to post descriptions and sample code as to how you would do these sorts of extensions to help further a rich communications experience over multiple modalities. For now, if you have some great ideas on what else we could be adding into the cobrowsing scenario please comment here, tweet @burckart, or send me an email to ejburcka at us dot ibm dot com. We will consider these for future blogs or releases!