WebSphere Commerce shopping flow URLs are organized by subsystem.
The Trading subsystem includes all logic and data relevant to negotiating or determining the price and associated quantity of an individual product or set of products. In particular, this area deals with the auctioning of goods and services, contracts, and RFQs (Requests for quotes).
A Request for Quote (RFQ) is a type of trading mechanism available in WebSphere Commerce. You can maintain and administer RFQs using the WebSphere Commerce Accelerator. When you publish the Deprecated featureadvanced B2B direct starter store provided with WebSphere Commerce, you get the RFQ request tool.
The following URLs are related to RFQ.
Data beans are grouped into several component groups.
URL commands, controller commands, task commands, view commands and tables are related to each other.
Use this information when you are customizing a command and you want to know which tables are affected. You should also use this topic if you are modifying a table and want to know which commands and beans are affected.
Legacy API classes can be browsed via Javadoc. New API classes are exposed using the REST interface.
Catalog subsystem URLs include all logic and data relevant to a catalog, including categories, products and their attributes, items, and groupings of each, and any associations or relationships among them.
Each IBM Gift Center action is a Struts action that calls the service interface for the gift registry to perform a requested action. If you are developing a store using the gift registry feature (for example, creating JSP files), you should be familiar with the actions. The actions are executed from a browser.
The Marketing subsystem includes all logic and data relevant to marketing concepts for your site, such as campaigns, Web activities, customer segments, email activities, and collaboration.
The Member subsystem includes all logic and data relevant to registration, authentication, and grouping of all members. A member can be a user, an organization or organizational entity, or a member group.
The following URLs relate to the Messaging system.
The Order Management subsystem includes all logic and data relevant to placing, processing, and managing orders. The Order Management subsystem also deals with returns.
WebSphere Commerce supports the following auction URLs:
WebSphere Commerce generates RFQ notification messages.
The following URLs are related to personal dictionary.
Invoked by a scheduled job. Activates (submits) RFQs that are in the future state when the specified date and time are reached.
Adds a category to group the items in the RFQ.
Invoked by a scheduled job. Closes all active state RFQs according to the closing rule. The RFQ closing rule is specified in the column RULETYPE of the WebSphere Commerce table RFQ.
Closes the RFQs and sets all corresponding responses to the in-evaluation state.
Cancels the specified RFQ requests and their corresponding responses.
Copies an RFQ.
Creates an RFQ.
Creates a next round RFQ.
Adds items to the RFQ.
Adds a product comment to an item in the RFQ.
Removes product comments from an item in the RFQ.
Updates product comments to an item in the RFQ.
Removes an item from the RFQ.
Adds a product specification to an item in an RFQ.
Removes a product specification from an item in an RFQ.
Updates product specification to an item in an RFQ.
Updates product information in an RFQ.
Invoked by a scheduled job. Marks canceled or completed RFQs for deletion after the specified period.
Updates the general information of the RFQ.
Adds a price adjustment on a category in the RFQ.
Removes a price adjustment on a category in the RFQ.
Updates a price adjustment on a category in the RFQ.
Sets the specified list of RFQ responses to the Won state.
Accepts products in the RFQ.
Sets the specified list of RFQ responses to the Lost state.
Rejects products in the RFQ response.
Submits the RFQ.
Adds terms and conditions to an RFQ.
Removes terms and conditions from an RFQ.
Converts an RFQ to a contract.
Updates terms and conditions in an RFQ.
Adds stores to the target list of the RFQ.
Removes stores from the target list of the RFQ.
Converts an RFQ to an order.
Invoked by the WebSphere Commerce scheduler to process pending notifications for any closed RFQs. This URL is called by scheduler. No display page will return.
Invoked by the WebSphere Commerce scheduler to process pending notifications for any completed RFQs. This URL is called by scheduler. No display page will return.
Invoked by the WebSphere Commerce scheduler to process pending notifications for any submitted RFQs. This URL is called by scheduler. No display page will return.
The trading subsystem provides URLs for accounts, contracts and policies.
The server subsystem consists of functions that are associated with URLs that are run by the scheduler.
The starter stores consist of pages that are associated with URLs that are run by WebSphere Commerce search. You can use the following URLs to invoke various WebSphere Commerce search tasks.
The WebSphere Commerce database model was designed for data integrity and optimal performance. WebSphere Commerce provides several hundred tables that store WebSphere Commerce instance data. To maintain data integrity, and to ease maintenance referential integrity, constraints are widely used in the database model. Indexes are used carefully on tables to avoid over-indexing and to provide a good balance between data retrieval and data manipulation activities (insert and update). The business rules are implemented at the application level rather than by using database trigger. Triggers, however, are used to facilitate data staging and optimistic locking. A limited number of SQL-based database stored procedures are used for data intensive activities.
Any given database data model displays the relationship among database tables in the schema.
During installation, WebSphere Commerce sets up the caching system with the default values.
The root element of the cachespec.xml file, <cache>, contains <cache-entry> elements. The WebSphere dynamic cache service parses the cachespec.xml file during startup, and extracts a set of configuration parameters from each <cache-entry> element.
A WebSphere Commerce instance can be created from the command line. The command-line utility uses Apache Ant to create the objects required. The targets are divided into several high-level groups that correspond to the environment that is to be configured.
The extension points listed on this page are provided by IBM and used in the IBM Sales Center.
WebSphere Commerce REST services are JAX-RS REST services that are built on top of Apache Wink. The implementation classes contain JAX-RS annotations such as @Path, @Produces, @Consumes, @QueryParam, and @PathParam.
In WebSphere Commerce Version 6.x the Payments subsystem was introduced. Payment processing using the WebSphere Commerce Multipayment Framework (used in version 5.x) and payment processing using the Payments subsystem is fundamentally different.
Parameters for the commands described here apply to the framework only. Note that in most cases, WebSphere Commerce Payments does not check for duplicate parameters. If more than one instance of a parameter is specified, then the last instance will be used.
The Data Load utility contains several configuration files. You can use the configuration file schema to understand and customize the data load configuration files.