WebSphere Commerce portlet action handler

+

Search Tips   |   Advanced Search

 

To create a new customized version of the WebSphere Commerce Portlet action handler, the new code must implement the com.ibm.commerce.foundation.client.portal.handlers.PortletActionHandler interface.When coding a new WebSphere Commerce portlet action request handler, be aware of a number of things. There is additional runtime information that needs to be gathered for use with the WebSphere Commerce service client library. When calling a client library, two mandatory objects are required - a business context object and the authentication callback handler.

Business context object

A BusinessContextType object is used to represent the business contextual information defined for the portlet. This contextual information should be set into this object for synchronizing with WebSphere Commerce services.

There are two types of business contextual information - sticky and non-sticky. Sticky business contextual information is session information that lasts for the entire Portal session. The business context object for this sticky contextual information is stored in the portlet session, using a contextKey as the identifier, so that it can be shared and re-used for future access.

Non-sticky contextual information lasts only for the duration of a request. An example of this type is the additional context data provided on the JSP page using the getData tag. Although it is processed in the same way when sending over to the client library, after the response comes back the non-sticky contextual information is discarded and is therefore not available for future uses.

The following two business context values must be present in the business context object:

langId

A numeric constant that represents the language used for WebSphere Commerce service

storeId

A numeric identifier that represents the WebSphere Commerce store

In order to retrieve an existing business context object from the portlet session, you can write the following code to call a special helper class using a contextKey:

BusinessContextType businessContextType = SessionHelper.getBusinessContextType(portletRequest, contextKey);

If you are planning to create or manage these business context objects at runtime, a business context plug-in is provided with the MVC Portlet. For more information about this business context plug-in, see the Business context plug-in topic.

Authentication callback handler object

Regardless of which authentication method the portlet chooses to use, the client library and WebSphere Commerce services should not be aware of the method when interacting with the portlet in the Portal environment. A callback handler is therefore used to generate an identity token for use in calling a WebSphere Commerce service client library.

The idea is to have the underlying service binding layer to process the single sign on request against the WebSphere Commerce server on behalf of the client without knowing the technical details. The service binding sets empty callback objects according to the portlet authentication configuration, into the callback handler, AuthenticationCallbackHandler, which implements the javax.security.auth.callback.CallbackHandler interface. Its handle() method handles all the required operations to obtain the identity token for use in the service binding layer. If authentication is successful, the callback array is populated with the following callback objects, depending on the authentication type defined in the portlet:

Simulated:

IdentityTokenCallback, NameCallback, PasswordCallback

Basic:

IdentityTokenCallback, NameCallback, PasswordCallback

If the credential plug-in configuration defines the authentication type to be Simulated SSO or Basic Authentication, then the user name and password are set into the PasswordCallback object.

In order to retrieve an existing authentication callback handler object from the portlet session, you can write the following code to call a special helper class using a contextKey

CallbackHandler callbackHandler = SessionHelper.getCallbackHandler(portletRequest, contextId);

A credential plug-in is one that helps generate the authentication callback handler mentioned above. It leverages the MVC plug-in framework so that you can specify a customized version instead. The credential plug-in must implement the PortletCredentialPlugIn interface which can be initialized and destroyed along with the WebSphere Commerce portlet. A default implementation has been provided, com.ibm.commerce.foundation.client.portal.services.MVCPortletCredentialService.

Here is an example of how to create the authentication callback using the MVCPortletCredentialService credential plug-in:

 PortletCredentialPlugIn portletCredentialPlugIn = (PortletCredentialPlugIn) MVCPortletServiceRegistry.singleton().getPortletService(iPortlet.getPortletName(), PortletPlugIn.TYPE_CREDENTIAL);
 CallbackHandler callbackHandler = portletCredentialPlugIn.getCallbackHandler(getActionRequest());

Here is an example of how to call the client library, passing the business context object and authentication callback as arguments:

 CatalogFacadeClient client = new CatalogFacadeClient(businessContext, callbackHandler);
 CatalogType catalog = client.findCatalogByCatEntryId(new Long("10001").longValue());

Related concepts

WebSphere Commerce integration with WebSphere Portal

Use WebSphere Commerce services in portlets

WebSphere Commerce services functional architecture

WebSphere Commerce Portal integration event handlers

Related tasks

Calling a WebSphere Commerce service using the MVC portlet configuration file

Related reference

Client library exceptions

Last updated: 25 November 2009