I was recently asked by IBM if we have integrated WebSphere Commerce and Lotus Connections. I don’t believe to date we have done this but it really got me thinking as to how exactly we would do it. Currently I have been leading an effort where we are integrating Commerce with a traditional J2EE / WebSphere application and the concepts are quite similar.
The key to a successful integration is understanding what is possible and what the pre-requisites are. First, this approach assumes you are running at least Commerce version 7 with feature pack 1. This provides a key feature called remote widgets which are at the heart of integrating with any social networking platform, or third party product with Commerce for that matter. The remote widgets are really just ATOM feeds which can be rendered in an external product. The ATOM feeds contain products which are driven by the Commerce product catalog and marketing segmentation rules which determine which products to deliver and what data about those products to send. The consumer of the ATOM feed, in this case Lotus Connections, can render the products in its own space with its own look and feel. Clicking on a product or adding it to a cart typically will then take you to the product catalog or shopping cart in Commerce.
Sound simple? Well, yes it is but if you really want to create a great user experience there is more you have to do. First, for an ideal and secure experience you should enable single sign on. To do this the first step will to connect Commerce and Connections both to a supported LDAP compliant directory server. Many Commerce installations use only its own member manager and do not rely on an LDAP directory so this could be a new step if you already have Commerce. Next, you need a way to handle single sign on. If you have a product like Tivoli Access Manager or Siteminder, you pretty much have what you need. If you don’t, there is an easier solution. WebSphere supports SSO through Light-weight Third Party Authentication (LTPA) so through WebSphere itself you can configure SSO between Connections and Commerce. This is critical as when you link between Commerce and Connections since you never want to challenge the consumer for credentials twice.
Now that you have SSO working, you will want to consider if you need to present personalized product recomendations through the remote widgets based on user attributes inside Commerce. If you want to do this, you need to make sure that Connections has access to the Commerce “Personalization ID.” This is different than the commerce user id or the logon id, but it is needed by commerce as an argument to the remote widget call if you expect personalized content to be returned. There are a few options to get the Personalization ID. For example, you could replicate it from Commerce to LDAP and read it from within Connections, call a custom service inside Connections to set it, or expose a service inside Commerce which Connections can call to retrieve the ID.
Next, for a truly ideal integration you will want to implement a common look and feel between Connections and Commerce and use the same metaphors for user interactions. To do this you will need to understand how to customize the interfaces on Connections and Commerce and the capabilities and limitations of those interfaces. Lotus Connections 3.0 has made great strides in making interface customizations easier and Commerce has always allowed interface customizations, but the models by which you customize are drasticaly different.
With these approaches, you can create a seamless user experience between Commerce and Connections which allow a user to see products inside Connections and only have to sign on once.
In Part 2 of this series, I will talk about how to integrate a shopping cart and account services.
Great article! Just a thought, wouldn’t Open Authority (OAuth) be a better solution for a single sign option? This way the server could request access to the various data needed to personalize the experience.
OAuth is definitely a possible SSO solution and can work quite well, especially if you are working with commerce and Connections instances on separate networks. In fact we are using OAuth on a project I am currently am working on which integrates Commerce with a J2EE web app on the services side. The LTPA solution is easily supported out of the box and requires very little (if any) custom code so if it is an option, it is probably the path of least resistance for SSO.
Good article. i am trying to figure out how to configure websphere commerce to use DB for user authentication and other J2EE apps accessing commerce with LDAP authentication. single singon would be best option where in other J2EE app authenticate against LDAP and set SSO token which then intercepted by commerce. could you through more light on this