Develop > Presentation layer > WebSphere Commerce integration with WebSphere Portal > WebSphere Commerce Portal integration architecture
WebSphere Commerce and WebSphere Portal integration framework
WebSphere Commerce has provided an optional integration framework intended to reduce development effort when calling WebSphere Commerce services from the portlet. You do not need to use the framework to make use of the client libraries and the WebSphere Commerce foundation tag library in the portlet.
The following diagram depicts the interactions between the key pieces of WebSphere Commerce Server and WebSphere Portal Server:
The following section briefly describes each of the key pieces of the framework:
PortletA portlet is similar to a servlet, except that it has parts that contribute to the MVC design pattern. MVCPortlet is a generic implementation of the MVC pattern that allows portal administrators to set up one or more portlets, each with its own configuration, to call various WebSphere Commerce business services.
Portlets have multiple states and view modes, as well as event and messaging capabilities. Portlets run inside the Portlet Container of the WebSphere Portal Server, similar to the way a servlet runs on an application server. The portlet container provides a runtime environment where portlets are instantiated, used, and then destroyed. Portlets rely on the WebSphere Portal infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, look up credentials, and store persistent data.
Configuration registryThe portlet configuration registry is a cached version of configurations related to all portlet operations, such as portlet actions and portlet renders. These static configurations are defined in XML files that are packaged as part of the WebSphere Commerce Portlet application. You can find these files on the file system after you install the portlet application to the WebSphere Portal Server.
Event HandlersPortlets and servlets have different processing and rendering sequences. A servlet does all of its processing in the service() method. A portlet, on the other hand, uses a two-phase processing that is split between an action phase and a render phase. This split is necessary to accommodate communication between portlets before rendering output in the service stage. The action phase is guaranteed to be completed before a portlet is called to render. The WebSphere Commerce and WebSphere Portal integration framework is designed in a flexible way so that each portlet request can be handled differently using an event handler. For each action event and render event, you can define a corresponding event handler in the portlet MVC configuration file.
Note: although the render phase is always called, the action phase may not be called in certain circumstances.Although the MVC configuration allows you to define any customized event handler, the use of two generic event handlers is recommended:
- A generic portlet action handler, MVCPortletActionHandler, which calls client libraries through configurations specified in the MVC configuration file
- A generic portlet render handler, MVCPortletRenderHandler, which returns the proper portlet JSP page according to the current portlet mode
This programming pattern greatly reduces code redundancy as well as maintaining a consistent behavior across all WebSphere Commerce portlet events.
Similar to the way WebSphere Commerce resolves any given URL controller command from the Struts configuration file, an action name is used as the unique identifier for looking up the corresponding action definition from an MVC configuration file.
- If the action is found, then the class name defined in the parameter attribute, such as com.ibm.commerce.foundation.client.portal.handlers.MVCPortletActionHandler, is loaded and its execute() method is called.
- Once the action phase is completed, the WebSphere Portal server will redirect the request to the render phase, using the render name defined in the MVC configuration file or from a parameter defined in the action request.
- If no action is found, the action handler will simply take its input parameters and set them as render parameters. This is a typical scenario of a portlet refresh triggered by a cooperative portlet wire where only the render name is given. In general, for best practice programming, if a portlet only needs to be refreshed and its action phase is not required, then it is recommended to use the <portlet:renderURL> tag on the JSP instead to avoid an action request.
A similar idea applies to the portlet render request. The render name is used as the unique identifier for looking up the corresponding render definition from the MVC configuration file. If none is found, then the fallback render definition (with the "default" name) is used. (Even if there is a render definition for this given name, it is optional to have a view defined for each portlet mode.) In addition, the portlet developer can override the render behavior by specifying a different render name in the portlet request URL. Add "renderName" to the parameter list for overriding the name of the renderer.
Portlet Action HandlerThis handler, com.ibm.commerce.foundation.client.portal.handlers.MVCPortletActionHandler, retrieves two properties, clientLibrary and clientMethod, and then calls the method, passing a parameter map that is composed of name-value pairs given in the URL.
When the client library returns a response, this handler takes the response name-value pair that was returned from the client library and adds it to the URL as render parameters so that the context and core business data are not lost in an event of a page refresh. A page refresh issued from the portlet container does not involve processAction(), so certain business data might be lost as a result of a refresh request.
Portlet Render HandlerThe render generic handler, com.ibm.commerce.foundation.client.portal.handlers.MVCPortletRenderHandler, does not call WebSphere Commerce services. Instead, it simply checks for the current state and mode of the portlet to determine the appropriate JSP file path to be used when calling the request dispatcher for rendering.
Portlet JSP fileThe Portlet JSP file is a view template for displaying business data and getting inputs from the portal user. Special UI tags, such as Portlet tags and WebSphere Commerce foundation tags, are used on these pages to avoid inline JSP Java coding. Portlet tags are provided by WebSphere Portal to access information specific to the portal environment, whereas WebSphere Commerce foundation tag library tags are for retrieving populated service data objects from WebSphere Commerce services.
Client libraryA client library is a WebSphere Commerce Component Service interface for client side invocation. Client libraries should not be aware of any artifacts specific to WebSphere Portal, such as Portlet Session and Credential Service Vault. Upon each invocation, business objects, such as BusinessContextType and AuthenticationCallbackHandler, are passed to the interface so that it can hand over specific information to the service binding layer.
WebSphere Commerce foundation tag libraryA getData tag is provided as part of the WebSphere Commerce UI Runtime. It retrieves populated service data objects from WebSphere Commerce services.