WebSphere Commerce Accelerator architecture
The WebSphere Commerce Accelerator is a collection of tools designed to facilitate the day-to-day business operations of your site. That is, it is intended as an interface for business people to create and modify any number of aspects of the site's operations without having to continually contact the IT staff responsible site. As such, there are numerous components that comprise the WebSphere Commerce Accelerator, each targeting a key aspect of the business. While every effort has been made to make these tools universal, this same goal means that some users may find that certain requirements are not met. If you extended the database during your site's creation, and these extensions relate to any of the tools listed in this document, the data will be invisible to the WebSphere Commerce Accelerator until you customize the relevant tool.
The components that make up the WebSphere Commerce Accelerator are built using interface building blocks known as the Tools Framework. The widgets defined in this toolset are designed to simplify any customization efforts by providing an extensible and customizable framework allowing you to quickly implement a fully featured user interface while maintaining a common appearance.
The framework consists of a server runtime component, and a collection of common user interface elements. The server component primarily acts to enforce security policies. The WebSphere Commerce Accelerator displays different menu options and pages depending on the user, and determining which content to display to which user is done by the WebSphere Commerce Server.
WebSphere Commerce Accelerator runtime model
This section provides an overview of how the pieces that comprise the WebSphere Commerce Accelerator interact at runtime. For the purposes of explanation, assume that a business user has just clicked Change on the content list page, after selecting an existing content. The following figure illustrates the programming model for the WebSphere Commerce Accelerator runtime:
- Beginning at the top with the data bean, the JSP file corresponding to the content General definition page requests that the CampaignCollateralDataBean populate a JavaScript object in the JSP. This step is optional, since the requested JSP may not require data from the database. For example, if the business user in our example had clicked Create, instead of Change, the JSP file would not access the data bean since there would be no existing information for the new content. Generically, refer to the component XML file to determine which data bean that the JSP files access.
- The user further populates the JavaScript object by entering or changing data using HTML forms elements, which is transferred to the JavaScript object using JavaScript functions.
- When finished, the JavaScript object is converted to an XML string, and passed as part of the URL, to the Tools Controller Command, which converts the XML string into a hashtable.
- The Controller Command (a subclass of the Tools Controller Command) then sets a data bean or Server Command which updates the database.
Constituent assets
The WebSphere Commerce Accelerator is made up of numerous assets, as illustrated in the preceding image. These assets include the following:
- JSP files
- JSP files are used to display dynamic information.
- JavaScript files
- The WebSphere Commerce Accelerator uses JavaScript to perform numerous client-side functions. Also, the data gathered during these client-side interactions is stored as a JavaScript object, then converted to XML, before being passed back to the server.
- XML files
- XML files define the various components of the WebSphere Commerce Accelerator. Also, data transmitted between the client and the server is encoded as an XML string.
- Java classes
- Java classes are used to create commands, data beans, and access beans since WebSphere Commerce is a J2EE compliant application.
- Properties files
- Properties files are used as resource bundles. Separating the strings into properties files facilitates maintainability, and language flexibility. WebSphere Commerce is designed for use by multinational clients whose customer base often requires multiple languages.
- Struts configuration files
- This is an important piece of the WebSphere Commerce Accelerator, and it is important to understand how it fits in to the tool. The Struts configuration files are the by-products of implementing a flexible architecture. Views are all registered in the struts-config.xml files. While this flexibility is less applicable to a customized WebSphere Commerce Accelerator, it is still the framework in which the tools are defined. For details about Struts configuration files, see WebSphere Commerce Struts framework. As reference, you can also refer to the WC_installdir/CommerceAccelerator/WebContent/WEB-INF/struts-config.xml and search for a view (for example, CampaignInitiativeListView), to view details about registering a view.
Common file assets
The WebSphere Commerce Accelerator depends upon common files to help render the various components. These JSP files are located in a common location, available to all of the WebSphere Commerce Accelerator components. Note, these generic files should not be touched. These files control how the elements function, and changes to these files can easily break the WebSphere Commerce Accelerator.
To understand how the WebSphere Commerce Accelerator uses these files, consider the following example, in which a business user has clicked the menu item to create a new product in the Product Management tool.
When a business user clicks on the menu to initiate the ProductCreate wizard, it calls a URL command, which in this case, would be the ProductCreateWizardView command. The ProductCreateWizardView command opens the wizard.jsp file. This JSP initializes a databean, which accesses and parses the ProductCreateWizard.xml file. Based on the contents of the component's XML file, the wizard's table of contents can be obtained, and displayed using the WizardTOC.jsp. Similarly, the XML file governs the wizard's navigation panel. Once this is obtained, it is displayed using the wizardNavigation.jsp. For more information about how these elements display, refer to User interface elements. Each of the user interface elements has a corresponding generic file, and in some cases like the wizard, more than one.
Other special files in this category include the ToolsUI.jsp, which acts as the overall, top level container in which the WebSphere Commerce Accelerator displays. It contains the ToolsUIBanner, the ToolsUIMenu, and ToolsUIMain JSP files, which display the aspect of the WebSphere Commerce Accelerator to which their file name refers.
Once again, the files in this category should not be touched. This information is shared to provide some context.
Data persistence
Any work done while using the WebSphere Commerce Accelerator has to be saved to the WebSphere Commerce system. While all data generated using the WebSphere Commerce Accelerator is stored in the database, depending on the nature of the information, it might be stored in one of two formats. The first format in which data is stored is as simple flat data. This storage method is used for data that generally does not require additional processing before being used by the Commerce system. For instance, catalog data is stored in the database directly. This is also true of names and descriptions associated with any number of constructs, including for example campaigns, discounts, content, and so on. The idea is that if the data can be obtained from the database, and used directly, then it should be stored in its most simple format.
The second format in which data is stored is as an XML representation of the data in question. This format is used to store the more complex data constructs generated by user interaction with the WebSphere Commerce Accelerator. The data stored in the database as an XML file typically requires some additional processing between when it is obtained from the database, and when it is used by the Commerce system. An example of this kind of data would be the data associated with a rule-based promotion, which must be processed by the rule engine within the Commerce system before its use in the external site.