1) WCS introduction.

A) Introduction to IBM WebSphere Commerce Server.

WebSphere commerce server is a product where in any business can sell their products
online. The latest versions of WCS is no longer simply about presenting and selling
products online. It is about delivering a smarter shopping experience.

B) Different editions of WCS.

IBM WebSphere Commerce can be used by companies of all sizes, from small businesses, to
large enterprises, and for many different industries. It provides easy-to-use tools for
business users to centrally manage a cross-channel strategy. Business users can create and
manage precision marketing campaigns, promotions, catalog, and merchandising across all
sales channels. WebSphere Commerce is a single, unified platform that offers the ability to
do business directly with consumers (B2C), directly with businesses (B2B), and indirectly
through channel partners (indirect business models). WebSphere Commerce is a
customizable, scalable, and high availability solution that is built to leverage open
standards.

You should use the edition of WebSphere Commerce that matches to your business:

There are three editions of WebSphere Commerce. Each edition provides an increasing set
of functionality:
 WebSphere Commerce - Express is an easily installed and affordable customer
interaction platform that is designed to jump-start your online presence.
 WebSphere Commerce Professional provides a powerful customer interaction
platform to help mid-size companies offer personalized, cross-channel shopping.
 WebSphere Commerce Enterprise provides a sophisticated platform for high-
volume B2C and B2B business models and multiple sites.

Features and benefits:

For example, Express edition does not have the following features B2B starter store, sales
center (Which improves the productivity of call center employees. Gives call center
representatives the functionality they need to service and up-sell cross-channel
customers.), extended sites feature, auctions, contracts and entitlement.

Develper : IBM WebSphere Commerce Developer provides an integrated development

environment in which you can build and test your customizations to extend the business
logic or change the appearance of your site. IBM WebSphere Commerce Developer Editions
are available for WebSphere Commerce Enterprise, Professional, and Express. Since
WebSphere Commerce is a highly customizable solution, IBM WebSphere Commerce
Developer includes everything that you need to develop and test end-to-end e-commerce
sites.

There are four main components to the WebSphere Commerce development environment:

1. The WebSphere Commerce workspace used within Rational Application Developer

2. The development database
3. WebSphere Commerce tools and plug-ins for Rational Application Developer
4. File system assets, such as WebSphere Commerce XML configuration and properties
files

In the WebSphere Commerce development environment, you can create customized code
and then test the code using the WebSphere Commerce Test Server.

2) WCS Architecture.

A ) WCS common architecture.

Before examining how the WebSphere Commerce Server functions, it is useful to look at the

larger picture of the software components that relate to WebSphere Commerce.

The following diagram shows a simplified view of these software products:

The Web server is the first point of contact for incoming HTTP requests for your e-commerce
application. In order to interface efficiently with the WebSphere Application Server, it uses
the WebSphere Application Server plug-in to manage the connections between the two
components.
The WebSphere Commerce Server runs within the WebSphere Application Server, allowing it
to take advantage of many of the features of the application server. The database server
holds most of your application's data, including product and customer data. In general,
extensions to your application are made by modifying or extending the code for
the WebSphere Commerce Server. In addition, you may have a need to store data that falls
outside of the realm of the WebSphere Commerce database schema within your database.

Developers use Rational Application Developer to perform the following tasks:

 create and customize storefront assets such as JSP and HTML pages
 create and modify business logic in Java
 create and modify access beans and EJB entity beans
 test code and storefront assets
 create and modify Web services

The WebSphere Commerce development environment uses a development database.

Developers can use their preferred database tools (including Rational Application Developer)
to make database modifications. WebSphere Commerce supports a one to one mapping
between the WebSphere Commerce instance and the WebSphere Commerce database.
Running multiple WebSphere Commerceinstances against the same database is not
supported.

New to this release is the further decoupling of the presentation tier from the business logic
tier to better enable support for multiple sales channels. A sales channel is a method that a
customer can use to purchase merchandise for example, in-store, from an online store, or
from a call center. As shown in the following diagram, requests can enter the WebSphere
Commerce Server from different types of clients such as a rich client, kiosk or as a browser
request.

WebSphere Commerce is multichannel-enabled, meaning that WebSphere Commerce can

support transactions across various sales channels. The framework enhancements in this
release support multiple presentation layers, responsible for displaying results, which
decouple control logic from business logic.

B ) WCS functional architecture.

WebSphere Commerce functional architecture is based on a loose coupling of the

presentation and business logic layers.

Controller layer

The conductor of operations for a request. It controls the transaction scope and

manages the session related information for the request. The controller first
dispatches to a command and then calls the appropriate view processing logic to
render the response.

Presentation layer
The presentation layer displays the result of command execution. The presentation
layer can use JSP pages, or other rendering technologies.

Business Context Service (BCS)

 A service that manages contextual information used by business components. The
contexts include such information as globalization and entitlement.

Business logic facade

This generic interface is implemented as a stateless session bean which the controller
calls to invoke controller commands.

Controller commands
A controller command business process logic such as OrderProcess. It invokes task
commands to accomplish different unit of work in the business process. By default,
access control is enabled for controller commands.

Task commands
A task command is an autonomous task that accomplishes a specific unit of
application logic such as check inventory. A task command usually works with other
task commands to complete processing of a controller command. By default, access
control is not enabled for task commands.

Access beans
Access beans are simple persistent objects with setters and getters. The access bean
behaves like a Java bean and hides all the enterprise bean specific programming
interfaces, like JNDI, home and remote interfaces from the clients. Rational
Application Developer provides tooling support to generate access beans from the
schema.

Entity beans
Entity beans are used in the persistence layer within WebSphere Commerce. The
architecture is implemented according to the EJB component architecture. The EJB
architecture defines two types of enterprise beans: entity beans and session beans.

C ) WCS run time architecture.

The runtime framework enhancements better enable support for multiple sales channels by
further decoupling the presentation tier from the business logic tier. A sales channel is a
method that a customer can use to purchase merchandise for example, in-store, from an
online store, or from a call center. Requests can enter the WebSphere Commerce Server
from different types of clients such as a rich client, kiosk or as a browser request.
WebSphere Commerce runtime framework
WebSphere Commerce is multichannel-enabled, meaning that WebSphere Commerce can
support transactions across various sales channels. The framework enhancements support
multiple presentation layers, responsible for showing results, which decouple control logic
from business logic.

Task commands, controller commands, access beans, and entity beans continue to function
as in previous releases.

WebSphere Commerce framework interaction

This section provides a summary of the interaction flow between components when
forming a response to a request.

This diagram is specific to a Web application that uses Struts. The IBM Sales Center
framework interaction is described in the topic IBM Sales Center architecture.

A description of each of the steps follows the diagram.

The following information corresponds to the preceding diagram.

1. The request is directed to the Presentation layer (Web container) in its own thread.
 2. The thread handling the request is dispatched to the WebSphere Commerce servlet
filter. The filter passes the request to the adapter framework.
3. The adapter manager determines which adapter can handle the request, then
returns that adapter to associate with the request. For example, if the request
originated from an Internet browser, the adapter manager associates the request
with the HTTP browser adapter. The adapter is passed back to the Dynacache
servlet container. The filter regains control and passes the request to the servlet
engine for processing. At this point, either of the following actions can occur:
a. The request can be cached and the cached response can be returned.
b. If the request is not cached, the Struts action invokes the business logic
facade by specifying the interface name of the business logic to invoke and
the associated parameters. The business logic facade queries the command
registry to determine the appropriate implementation for the store
associated with the request.
4. The business logic facade invokes the appropriate controller command.
5. The controller command begins execution:
a. The controller command can access the database using an access bean and its
corresponding entity bean.
b. The controller command can invoke one or more task commands. Then task
commands can access the database, using access beans and their
corresponding entity beans.
c. A combination of a and b.
6. The business logic facade returns a set of properties to the Struts action. One of the
elements that is part of the properties is the key to the global forward that will
represents the response.
7. The action looks up the global forward in the Struts configuration files. It resolves to
the right one based on the store configuration. The action forward implementation
that is selected is the appropriate one for the device of the request.
8. The Struts request processor executes the action forward which will execute the
appropriate JSP page. Within the JSP page, a data bean is required to retrieve
dynamic information from the database. The data bean manager is used to activate
the data bean.
9. The access bean from which the data bean is extended accesses the database using
its corresponding entity bean. Based on globalization information in the request, the
data bean formats the data.

3) Business models.

Before starting to develop your site with WebSphere Commerce, you need to determine the
business model supported by WebSphere Commerce that best represents the purpose of
your site. Usually sites created with WebSphere Commerce will be implemented based on
of one of these business models.

A business model provides a sample commerce solution which includes an organization

structure, default user roles and access control policies, one or more starter stores,
administration tools, and business processes that demonstrate best practices. A business
model can be customized to support business requirements and scenarios. Direct sales
support commerce transactions involving products, services, or information directly
between businesses and consumers or between two businesses or parties.

WebSphere Commerce supports the following types of direct sales business models:

A ) B2C business model.

A store that supports commerce transactions involving products, services, or information

directly between businesses and consumers.

A value of B2C in the STORE table STORETYPE column indicates a B2C direct store

B ) B2B business model.

A store that supports commerce transactions involving products, services, between two
businesses or parties.

The selling business can be a wholesaler, a distributor, a manufacturer, or a retailer who

sells to buyers from other businesses. A value of B2B in the STORE table STORETYPE
column indicates a B2B direct store

C ) Extended sites

WebSphere Commerce supports the Extended Sites business model, where a seller can
have many sites that are aimed at different audiences. For example, a seller might create
sites based on geographical regions, while some customized sites might be created for
individual large customers. These different sites can share assets such as the catalog,
whereby each site selects the subset of the catalog that is presented, and adjusts the prices
as necessary. A customer cannot share a shopping cart across multiple sites; a customer
has a shopping cart at each location. The business can customize sites by:
Geography
Brand
Market segment
Customer
Each site appears unique to the customers that access it, and each site can implement
business rules unique to that site. For example, different geographical areas might have
unique legal and tax regulations.

A site that allow your selling organization to provide unique storefronts for different
enterprise customers or showcase several branded storefronts. Creation and management
of the extended sites is through the hub in Commerce Accelerator. These extended sites
may share much of the data, such as master catalog and list prices, and presentation
information. An extended site store can be a B2B direct or Consumer Direct store.
Note: A value of B2C in the STORE table STORETYPE column indicates a consumer direct
store. MHS is for consumer direct hosted hub, B2C and B2B and so on.

4) Fulfilment centers and inventory models.

Fulfillment centers are used by stores as both inventory warehouses and shipping and
receiving centers. A fulfillment center represents a place from which products are shipped
to customers. Inventory counts are maintained separately for each fulfillment center . One
store can have one or many fulfillment centers that are associated with it. In the
WebSphere Commerce Accelerator, you must select one fulfillment center when you log on,
if you are assigned one or more roles that pertain to fulfillment.

Use the WebSphere Commerce Accelerator to create fulfillment centers.

Procedure

1) Open the WebSphere Commerce Accelerator.

2) From either the Store or Hub menu, click Fulfillment Centers. The Fulfillment Centers
list is displayed. If you do not see this menu, then your logon ID does not have the
appropriate authority to perform this task. Contact your Site Administrator.
3) Click New. The New Fulfillment Center dialog opens.

Maximum releases per pick batch

The maximum quantity of order releases contained in each pick batch when a pick batch is
generated.

Minutes delayed

The delay in minutes from the time an order is released to fulfillment until one of its
releases can be picked in batch.

Drop ship
Indicates whether the fulfillment center is a drop-ship fulfillment center. This involves
requesting a fulfiller to ship the items directly to the customer rather than from the seller's
own fulfillment center

4) Click OK to create the fulfillment center.

Inventory:

Inventory includes anything that can be physically accounted for a fulfillment center. There
are specific definitions of types of inventory that can be fulfilled, such as items, products,
SKUs, bundles, and prebuilt kits, but these are all considered inventory.

Inventory allocation

WebSphere Commerce supports five inventory systems: Available to promise (ATP), non-
ATP, no inventory, external inventory, and DOM inventory. The interface to inventory is
encapsulated by a single inventory task command, which in turn invokes the appropriate
task commands.

The five inventory systems apply to the following situations:

ATP inventory

Using the ATP inventory model, you can allocate stock from existing inventory or
backorder from expected inventory. You can also obtain an estimated availability time for
each order item after it is added into the shopping cart. The ATP also supports allocating
stocks for future order processing.

Non-ATP inventory

The non-ATP inventory model supports inventory operations that are only based on
existing on-hand inventory.

No inventory

The no inventory model assumes that all products have infinite quantities. When the
products in a store are virtual products, digital downloadable products, or electronic
assets, such as downloadable images or music, you can use this model.

The no inventory model has three typical characteristics that differentiate it from the other
inventory models:

All products have unlimited available quantities. Any check of inventory always returns a
positive result.
Since all products have infinite available quantities, all order items are successfully
allocated after an 'allocate inventory' operation. Specifically, the INVENTORYSTATUS
column of the ORDERITEMS table is always set to 'ALLC'.

The No inventory system does not support RTF (Release to Fulfillment), Pick batch, and
Ship Confirmation. Order management functions can be supported by custom integration
with an existing order management system.

External Inventory

External inventory is used to integrate WebSphere Commerce with external inventory

systems. External inventory is the legacy inventory implementation model where
WebSphere Commerce directly consumes the inventory information from an external
system.

DOM inventory system

DOM inventory is used for WebSphere Commerce distributed order management

integration. For the DOM inventory system, WebSphere Commerce calls outbound services
to allocate inventory externally. Integration with Sterling Order Management is based on
the DOM inventory model. The DOM inventory system differs from the external inventory
model in the following ways:

The DOM inventory model supports the local inventory cache in WebSphere Commerce.
The external inventory model does not support the use of the local inventory cache.

The DOM inventory model uses the new logical schema and outbound service interfaces.
The external inventory model uses the legacy inventory outbound service interfaces.

To set a store to use a specific inventory model, WebSphere Commerce uses a configuration
flag to determine which set of interfaces to use. You need to populate the corresponding
tables for inventory configuration and inventory availability of this inventory model. For
ATP, non-ATP, and DOM inventory models, refer to the corresponding data models. For No
inventory and External inventory models, there are no local tables for inventory. The tables
for these inventory models are not populated. The ALLOCATIONGOODFOR column in the
STORE database table, is used to define the expiration time of the inventory allocation. The
ALLOCATIONGOODFOR column is applicable only for the ATP inventory model. It is not
applicable for other inventory models. The INVENTORYSYSTEM column in the STORE
database has values: -1 for ATP inventory, -2 for Non-ATP inventory, -3 for No inventory, -4
for External inventory and -5 for DOM inventory system

5) Store publish.
Site is one in an organization and stores can be any number for an organization.

Starter Store: A fully functional sample online store, provided in store archive format with
WebSphere Commerce. Starter stores are samples designed to be used as a base from
which a customized online store can be created. Starter stores are translated into several
languages and support multiple Web browsers and platforms.

Aurora starter store is B2C starter stotre and Elite is B2B starter store

Publishing the Aurora starter store in the programming environment

The Aurora starter store can be used only as a storefront asset store in the Extended Sites
business model. It is not possible to deploy Aurora as a stand-alone B2B or B2C store.
The Aurora.sar archive contains the organization structure, predefined user roles, and
access control policies necessary to create either a B2C storefront asset store or a B2B
storefront asset store.

Follow this procedure to publish the Aurora starter store as a storefront asset store in an
existing Extended Sites organization.

Procedure

1. In your WebSphere Commerce Developer workspace, open the Administration

Console.
2. Select the Site option.
3. From the Store Archives menu, select Publish. The Store Archives page lists the
store archives available for publish. By default, the page displays composite store
archives.
4. In the View, select Extended Sites.
5. Select Aurora.sar.
6. Click Next. The Parameters page opens.
7. From the Store type list, select the business model for your store:

Option Description

Consumer direct storefront asset Select this option to publish a B2C storefront
store (MPS) asset store.
 Option Description

B2B direct storefront asset store Select this option to publish a B2B storefront
(BMP) asset store.

8. Complete the publish wizard parameters that apply to the business model you
selected:

Store directory
The name of the directory that you want to contain the storefront assets (such as JSP
files and images).

The default value is Aurora. If you are publishing more than one type of store from
the Aurora.sar store archive, consider changing to a more meaningful name, for
example, Aurora_B2C.

Important: As you are publishing your store, record the value that you set for
the Store directory field. You must specify this value as the value for your store
name when you set up your Store server in your customization workspace.

Store identifier

The name that uniquely identifies the published store.

The default value is Aurora. If you are publishing more than one type of store from
the Aurora.sar store archive, consider changing to a more meaningful name, for
example, Aurora_B2C.

Organization

The organization to which you want to publish the store archive.

The default value for B2C is Seller Organization (Root Organization).

The default value for B2B is Extended Sites Seller Organization (Root
Organization).

Catalog asset store

The catalog that you want to use. Select the name of the store that contains the
shared catalog data that you want to use.
 Example: Extended Sites Catalog Asset Store

Inventory Model

The choice of inventory model to be used in the store: ATP (available to

promise), Non-ATP, External inventory, No inventory, or DOM inventory.

The default value is ATP.

9. Click Next. The Summary page displays, listing the store archive and parameters

that are selected, and the location to which the store archive is published.
10. After you review the summary information, click Finish. A confirmation dialog
displays with the number of the publishing job. Note the job number for future
reference.
11. To check the publishing status, click Refresh.
12. When the Publish Status column displays Successful, select the corresponding job
number and click Details.

If you want to test whether you properly configured your WebSphere Commerce Developer

workspace before you continue with setting up your Externalized Customization
workspace, then complete the following steps.

13. Optional: Verify that you successfully completed a WebSphere Commerce

Developer workspace set up by testing a starter store and business user tools.
a. Run the setupSearchIndex utility if you enabled workspaces. If you did not
enable workspaces, then you can skip this step.
Note: When you set up the WebSphere Commerce search server in the
Externalized Customization workspace, you are prompted to disable
this WebSphere Commerce Developer workspace search server.
14.
a. Ensure that the Aurora starter store loads properly.
 For the default Aurora consumer direct
store: http://localhost/webapp/wcs/stores/servlet/auroraesite/
 For the default Aurora B2B direct

store: http://localhost /webapp/wcs/stores/servlet/aurorab2besite/

6) WCS Subsystems

A) Member Subsystem :
The Member subsystem is a component of the WebSphere Commerce Server that includes
data for participants of the WebSphere Commerce system. A member can be a user, a group
of users (also known as a member group), or an organization. Business logic in the Member
subsystem provides member registration and profile management services. Other services
which are closely related to the Member subsystem include access control, authentication,
and session management.
The Member subsystem allows its users and organizational entity members to be assigned
roles depending on the activities in which they choose to participate. Role assignment is the
responsibility of an administrator, such as a Site Administrator. Once a member is assigned
a role, access control component authorizes the member to participate in activities
associated with the role. For example, an organization can be a buyer or a seller, or both. A
user can also be assigned multiple roles.
The Member subsystem also allows you to create member groups, which are groups of
users categorized for various business reasons. The groupings can be used for access
control purposes, for approval purposes, as well as for marketing purposes, such as
calculating discounts, prices, and displaying products.
The following features are associated with the Member subsystem:
Registration information
Profile management
Access control or authorization : Access control determines what tasks users can perform
on specific resources
Security, authentication, and session management.

Membership hierarchy :
Users and organizational entities within the Member subsystem are organized into a
hierarchy. Generally this hierarchy mimics a typical organizational hierarchy, with entries
for organizations and organizational units, and entries for users in the leaf nodes. The
hierarchy includes artificial organizational entities created specifically to support access
control.
B2C organization structure:s

B2B Organization Structure:

Root Organization

The Root Organization is at the top level of the organization and is its own parent.
All organizations in WebSphere Commerce organization structure are descendants
of the Root Organization. The MEMBER_ID value for the Root Organization is -2001.
This value should not be changed.

Default Organization

Under the root is the Default Organization, and organizational entities that
represent the seller and buyer organizations in the WebSphere Commerce system.
When a user registers and does not identify an organizational entity to which the
user belongs, the Default Organization will be used. All guest customers and
customers in consumer direct businesses are created under the Default
Organization. It is recommended that when a business user (with profile type B)
registers that the business user identify the appropriate organizational entity that
he belongs to instead of defaulting to the Default Organization. The parent member
of a user is the immediate organizational entity to which the user belongs. A user
 can specify his parent organizational entity during registration. If he does not
specify his parent organizational entity, the Default Organization will be used the
parent. The MEMBER_ID value for the Default Organization is -2000. This value
should not be changed.

Note the following considerations about the Default Organization:

 OrgAdminConsole: This tool to manage business users and administrators does not
list users under the Org -2000 (Default Org), or allow users to be created under the
Default Org, since it assumes that is where B2C Shoppers (and guest users) are kept.
Accelerator can be used to manage B2C shoppers.
 Access Control: By default, Default Org (-2000) subscribes to
GuestShopperManagementPolicyGroup which allows for some administrators
(regardless of where they play their role) to manage the users under the Default
Org. Guest users are implicitly owned by the Default Organization (-2000), when an
access control check is done on this type of user, since guest users do not exist in
the MBRREL table.
 MemberRegistrationAttributes.xml: By default, it has configurations that assume the
Default Org DN.
 UserRegistrationAdd command: If no parentMember is specified (for example, the
B2C scenario), the use will be placed under the Default Org.
Sub-organizational entities

One or more other levels of organizational entities can exist beneath the parent
organizational entities. An administrator can add as many child organizational
entities as necessary to support their business.

Users

Each organizational entity can have multiple users. Each user can belong to only one
organizational entity.

The MBRREL table stores membership hierarchy information, and must be populated for
every user and organizational entity. The MBRREL table only contains entries for
registered users. Guest customers always have the Default Organization as their parent
organizational entity. The members that are above a user or organizational entity in the
membership hierarchy are referred to as the ancestors of that user or organizational entity.
The immediate ancestor is also referred to as the parent. The relationship of the user to its
parent organizations is defined in the MBRREL table and also mirrored in the DN for the
user.

Users
When a user first accesses an e-commerce site and is browsing product pages, the user is
running as a generic user. The generic user has a common user ID (-1002) that is used
across the entire system. The use of a common user ID on the site minimizes system
resource usage. Once the user performs an operation that requires a unique identity, for
example, adding a product to the shopping cart, the user is converted from a generic user to
a unique guest user. A guest user has a unique user ID, but no password. This user
implicitly belongs to the Default Organization and does not have any roles in the site.
Depending on the business model of the store, and the access control policies, the user may
be able to do other operations on the site, for example, placing an order. Both the generic
user and a unique guest user have the registration type of "G" (Guest user). If the guest user
registers to the current store, then the user is converted to a registered user, and any assets
that the guest user owned will now be owned by the registered user.
A registered user has a unique logon ID and password, and is required to provide some
profile data for registration purposes. This user has registration type of "R" (Registered
user). The user would typically have the Registered Customer role in the current store's
organization. Other roles can be automatically assigned during registration by configuring
the MemberRegistrationAttributes.xml file. If the user is later assigned the Site
Administrator role, its registration type would be changed to "S" (Site Administrator). If the
user is later assigned any other administrative role, for example, Customer Service
Representative, the user's registration type would change to "A" (Administrator). Approval
may be required for user registration, depending on the configuration of the parent
organization. If approval is not needed, the user will automatically be in approved state. If
approval is needed, the user will initially be in pending approval state. Once the
registration has been processed, the user will be in approved, or rejected state. Only
approved users can log into the site. If a user's registration is rejected, the user could try to
register again. Registered users can be classified according to their profile type; that is,
profile type B denotes a business user (or a B2B direct or value chain customer) and profile
type of C denotes a retail user (or a consumer direct customer). It is recommended that
business users belong to their appropriate organizational entity in the membership
hierarchy instead of the Default Organization. This means that, when a business user
registers, the organizational entity that the user belongs to should be specified. If it is not
specified, WebSphere Commerce will default to using the Default Organization.

Organization Type of role Role

Root Technical operations Site Administrator
Seller Seller
Logistics Manager
(Enterprise edition)
Operations Manager
Receiver
Returns Administrator
Operational Pick Packer
Organizational management Seller Administrator
Business relationship Account Representative
Sales Manager
Channel Manager
Organization Type of role Role
Product Manager (this role
might also be referred to as a
merchandising manager)
Product management and Category Manager
merchandising Buyer (seller side)
Marketing Marketing Manager
Marketing Director
Workspace Manager
Workspace Task Group
Approver
Workspace Content
Workspaces Contributor
Customer Service
Representative
Customer service Customer Service Supervisor
Buyer Administrator
Buyer Approver
Buyer (buy-side)
Organization Participant
Procurement Buyer
Administrator
Buyer Organizational management Procurement Buyer

Tables Involved in Member subsystem:

USERS
This table contains all users of the WCS that is registered users, guest users, and generic
users.
USERREG
This table stores user authentication information like username and password.
USERREPROF
This table contains basic registered user profile information.
USERDEMO
This table stores demographics information for users.
MBRGRP
This table stores member groups defined in the WCS. A member group is a group of
members.
MBRGRPDESC
This table contains locale specific information for the entries in the MBRGRP table.
BUSPROF
This table stores business profile information for a user. It is populated by the user
registration commands. It is intended to be populated for users with profile type
(USERS.PROFILETYPE) of "B", signifying that this is business user.
MEMBER
Stores the list of members of the WCS. A member is a user, an organizational entity or a
member group.
MBRATTR
This table contains the custom member attributes available to be assigned to users and
organizations.
MBRATTRVAL
This table contains the custom member attributes available to be assigned to users and
organizations.
ATTRTYPE
This table holds the type identifier for attributes.
MBRREL
This table stores member hierarchy relationships (ancestors and descendants) of
organizational entities and registered users. Note that member groups are not part of the
member hierarchy.
ROLE
This table stores the roles defined in WebSphere Commerce. Once a role is created, you
cannot change the name or description of a role using a graphical user interface tool.
MBRROLE
This table stores role assignment for members. Each member can play one or more roles in
the WebSphere Commerce system. When a member is assigned a role, the org Entity for
which the member plays that role can also be specified.
ORGENTITY
This table contains information on organizational entities (OrgEntities). An OrgEntity is
either an organization or an organization unit. Authorization domains are also stored in
this table.
ADDRESS
This table stores the addresses of users or organizations in the WebSphere Commerce
system. The addresses can be the members' own addresses or for their friends, associates,
or clients, and so on. Some columns here replace columns used in previous versions.

Important columns in ADDRESS table are as follows

1.ISPRIMARY - A user or organization can have multiple addresses of the same address
type (ADDRTYPE column). For example, a user may have multiple shipping addresses. The
isPrimary column can be used to mark one of these shipping addresses as being the
primary one. This may be useful when populating a drop down list of available shipping
addresses as one of them can be chosen as the default option in the drop down list. Valid
values are 1 (primary address) or 0 (non-primary address).
2.ADDRESSTYPE -Types of address are: S ( ship to), B ( bill to), and SB (both ship to and
bill to). If this is unspecified when creating a new address, the business logic will default to
SB.
3.SELFADDRESS- Specifies the address that is associated with the registration of the user
or organization. Valid values are 1 (the address is the registration address) or 0 (the
address is not the registration address). A user or organization can have only one
permanent self-address. An example of an address that is not a self-address would be an
alternate shipping address or an address of a friend or relative.
4.STATUS- Specifies the status of the address. Valid values are P (permanent or current)
and T (temporary or historical). 

Member Subsystem Commands

LogonCmdImpl
This command helps to login a user into a site or store. User should have role in current
stores organization and users account should be an approved one and is enabled.
If the user is authenticated successfully then user’s resources are migrated from guest to
register. MigrateUserEntriesCmd migrates resources owned by one user to another. The
mandatory resources that are migrated are Addresses, Current Orders, Interest Items,
Order Items, Orders, and Order templates. It migrates the guest user's shopping cart also.
There is a migrateOrder method in the MigrateUserEntriesCmdImpl class which does the
job. All that this method does in change the member id of the guest user's orders and
orderitems to the registered user's information. But it does not do anything if the logged in
user has a previous shopping cart. In that case user's past order has been deleted and order
items have been migrated to the new migrated order.

LogoffCmdImpl

LogoffcmdImpl will logs of current user .This command clears the session of the current
user, and begins a new session as the generic user. By default this commands deletes
persistent session while logs off(remember Me=false).If persistent session is enabled and
rememberme=true even after log off user will be able to see the shopping cart(but not
order history or address)

UserRegistrationAddCmdImpl
This command is used to register a guest or a generic user .If the parent organization of
user requires registration approval, user will be allowed to login only after getting the
approval. Default Organization (B2C business model) does not require user registration
approval. Information for new users is stored in the MEMBER, USERS, USERREG, MBRREL,
MBRROLE, USERPROF, BUSPROF, USERDEMO, ADDRESS, and ADDRBOOK database tables.

UserRegistrationUpdateCmdImpl
This command is used to update the registration information of a registered user. . If the
current user is a guest customer, this command will call the UserRegistrationAdd command
to register a new user. Information for users is stored in the MEMBER, USERS, USERREG,
ADDRESS, ADDRBOOK, MBRREL, USERPROF, BUSPROF, USERDEMO, and ADDRESS
database tables.

OrgEntityAddCmdImpl
This command registers a new organization or organizational unit.This command registers
a new organization or organizational unit. Information for new organizations or
organizational units are stored in the MEMBER, ORGENTITY, MBRREL, and ADDRESS
database tables.

OrgEntityUpdateCmdImpl
This command updates information about an organization or organizational unit.This
command updates information about an organization or organizational unit. If orgEntityId
parameter is not specified, OrgEntityAdd command will be called to add a new organization
or organizational unit. Information for the organizations or organizational units are stored
in the MEMBER, ORGENTITY, MBRREL, ADDRESS and ADDRBOOK database tables.

AddressAddCmdImpl

This command adds a new address entry for a user or organization.When an address is
created, its status is marked with a "P", meaning "permanent", and indicating the current
address. When an address is updated, a new record of the address is created with the
updates. The new record is marked with a "P" and the earlier record is marked with a "T",
meaning "temporary", and indicating the historical address.When an address is deleted
with the AddressDelete command, its status is marked with a "T".

AddressDeleteCmdImpl
This command deletes an address for a user.If address exists, the address is marked as
temporary or historical (that is, STATUS=T). The command then returns a success page
defined by the URL parameter. If the address already has status T, the success page is
returned regardless.

AddressUpdateCmdImpl 

This command updates the address entry for a user. If the addressId parameter is not
provided, the AddressAdd command is called to add a new address. The nickname cannot
be updated. Inserts a new address into the ADDRESS table with the specified nickname. The
old address is marked as temporary, and the new address is marked as permanent.

AddressCheckCmdImpl
This command determines whether a user has at least one permanent address.

ResetPasswordCmImpl
This command is used by Registered users and administrators to update their own
passwords. Registered users who want to log on but have forgotten their password. They
use this command to reset their password without logging in.A randomly generated
password is e-mailed to the guest customer.
.

MemberRegistrationAttributes XML
The MemberRegistrationAttributes.xml configuration file specifies attributes that should
automatically be assigned to users and organizations during user and organization
registration and some authentication scenarios (For e.g.: SSO). The XML files is located in
C:\IBM\WCDE_ENT70\workspace\WC\xml\member directory. This file might be
overwritten when a store is published, but a back file is kept in the same directory.

This file is divided into four main sections:

UserRoles
Defines the roles that a user would automatically receive in an organization during
registration.
OrganizationRoles
Defines defines the roles that an organization would automatically receive during
registration.
BusinessEntities
Defines which organizations should automatically be defined as business entities when
they are created. A business entity is an organization that can have business accounts.
RegistrationParents
Defines where to create new users or organizations for a registration type.

B ) Catalog subsystem

The catalog subsystem contains all logic and data relevant to an online catalog, including
catalog groups (or categories), catalog entries, and any associations or relationships among
them.

Master catalog & Sales catalog:

The master catalog is the central location to manage your store merchandise. Everything
that you need in your store is contained within the master catalog. It is the single catalog
that contains all products, items, relationships, and standard prices for everything that is
for sale in your store.
Every store in the WebSphere Commerce system must have a master catalog. You can share
the master catalog across stores and define as many stores as needed.
In addition to creating a master catalog for your catalog management, you might also
choose to create one or more sales catalogs for display purposes. A sales catalog can
contain the same entries as the master catalog, but the sales catalog has a flexible structure
for customer display purposes. You can have as many sales catalogs as you want.
Use the Management Centre Catalogs tool to view and manage your master catalog. If you
migrated from an earlier version of WebSphere Commerce, you can use the WebSphere
Commerce Accelerator Product Management tools to view and manage your master
catalog.
Master catalog example
The following diagram illustrates a section of a master catalog for a children's clothing
store:
We can create sales catalog from Accelerator.

Catalog groups
Catalog groups are generic groupings of online catalog entries within a catalog. A catalog
group may contain more than one catalog group or catalog entries. You can associate
catalog groups with any number of catalogs. For example, the "Men's Pants" catalog group
can be associated to the "Summer", "Winter" and "Spring" catalogs.

Although catalog groups can include catalog entries for any purpose, the main intent of
catalog groups is for catalog partitioning purposes. Catalog groups also determine
the navigational hierarchy of an online catalog.

Catalog entries
Catalog entries represent merchandise in an online catalog that often includes a name or
part number, a description, one or more offer prices, images, and other details. A catalog
entry can be a product, item, package, bundle, or dynamic kit.
Catalog entries can be a single item (atomic) or composed of several other catalog entries
(composite). When atomic, a catalog entry is an individually orderable entity that needs no
further SKU resolution. When composite, a catalog entry represents unresolved products,
packages, or bundles that may need additional information before becoming atomic
entities.
Packages and bundles
Packages and bundles are groupings of catalog entries used for promotional purposes.
A bundle is a collection of catalog entries that allow customers to buy multiple items with
one click. A bundle can be a grouping of items, or a combination of products, items, and
fully resolved packages. If you select a bundle which only contains items, the bundle is
decomposed into separate orderable SKUs that are added individually to the shopping cart.
However, if you select a bundle which contains products, these products need to be
resolved into items through SKU resolution before being added to a shopping cart. In either
case, once a bundle is decomposed and its component items are added to a shopping cart,
you can modify or remove each item. The bundle's price is the aggregate of the prices of all
the bundle components. For example, a computer bundle might be composed of a central
processing unit, a monitor, a hard drive, and a CD-ROM drive.

Unlike bundles, a package is an atomic collection of catalog entries. Viewed in similar ways
as a product, a package has defining attributes and is a container for fully resolved
packages. A fully resolved package is comparable to an item, with its own price, and can be
added to a shopping cart. You cannot decompose or modify a package during navigation or
after the package has been placed in the shopping cart. For example, a computer package
might contain a specific central processing unit, monitor, and hard drive that cannot be
sold separately.

Products and items

An item is a tangible unit of merchandise that has a specific name, part number, and price.
For example, a 15-inch hammer with a wooden handle (part number 15) is an item.
A product, however, is a group of items that exhibit the same attributes. For example, a
hammer is a product, while the 15-inch hammer with a wooden handle is an item. The
attributes of this product are "handle type" and "size," which are defined by the
corresponding attribute values, wooden and 15 inch.

Tables used in Catalog subsystem: 

CATALOG: This table holds the information related to a catalog.

CATALOGDSC:  This table holds language-dependent information related to a catalog.
STORECAT:  This table has relationship on store with catalog and also says that whether
the catalog which is referenced to the stores is master catalog or sales catalog.
CATGROUP:  This table hold the information related to a catalog group. A catalog group is
like a generic category that can contain both other catalog groups and catalog entries.

CATGRPDESC This table holds the language-dependent information related to a catalog

group.

STORECGRP This table holds the relationship between StoreEntities and the

CatalogGroups that they can display and process.
CATTOGRP This table has the information on relationship of CATALOG_ID and ROOT
CATGROUP [category]

CATGRPREL This table has the information on the relationship between the CATEGORY or
CATGROUP, like it says which is parent and which is child.

CATENTRY This table holds the information related to a catalog entry. Examples of catalog
entries include products, items, packages, and bundles.

CATENTDESC This table holds language-dependent information related to a catalog entry.

CATENTREL This table holds containment relationships between catalog entries. Examples

of these relationships are Product-Item, Bundle, and Package relationships. This table
should not be used for peer-to-peer catalog relationships, such as cross-sells.

CATGPENREL This table relates catalog groups (or categories) to the catalog entries that
are inside them. You can also use this table to dictate the navigational flow from catalog
groups to catalog entries. Each relationship is also qualified by a Catalog ID.

STORECENT This table holds the relationship between StoreEntities and the

CatalogEntries that they can display and process.

LISTPRICE Each row of this table represents a ListPrice in a particular currency for a

CatalogEntry.

ATTR: Stores attribute information

ATTRVAL: Stores attribute value information

Commands involved in Catalog subsystem:

TopCategoriesDisplayCmd
This command sets the view task that will display the root Categories in a specified Catalog.

StoreCatalogDisplayCmd
This command can be used as the first page of a shopping flow to display the catalogs of a
given store.

CategoryDisplayCmd
This command retrieves the configured display page for the specified category in the
specified catalog.

ProductDisplayCmd
This command retrieves the configured Display Page for the specified CatalogEntry which
will in turn be launched in order to display information about the CatalogEntry.This
 command first ensures that the CatalogEntry specified by the ProductId can be displayed in
the current store, if published, and is not marked for delete.

C ) Order Subsystem:

The Order Management subsystem is a component of the WebSphere Commerce Server

that provides shopping carts, order capture, order fulfilment, inventory, and payment
function support. In addition, the subsystem deals with order management capabilities
such as:
 quick order or buy
 scheduled orders
 multiple pending orders
 reorders
 future orders

What is Order?

A typical order includes one or more products, billing and shipping addresses, payment
details, and the total cost including shipping charges and taxes. Comments and price
adjustments can also be included in an order.

Order states:
A

Payment authorization requires review: Payment authorization has encountered an

unusual circumstance, such as an address verification warning. The payment authorization
should be reviewed and accepted, or the Order canceled, using the Order Management user
interface. If the authorization is accepted, then the user interface will change the Order
Status to either B or C as appropriate.

Backordered: An initial authorization has been performed. A re-authorization for the full
amount will be done when all backordered items are allocated.

Complete: Payment for the full amount has been authorized.

Deposited: Payment has been captured.

E
 CSR edit: A Customer Service Representative is working with the order.

Ready for remote fulfillment: The order is ready to be sent to a remote system for
fulfillment. This status is used by the MQAdapter feature and the TransferOrder task
command.

Waiting for remote fulfillment: The order has been sent to a remote system for
fulfillment. This status is used by the MQAdapter feature and the TransferOrder task
command.

Error in remote fulfillment: This status is associated with these conditions:

(1) An order has been submitted for transfer and the distributor responded with
a failed transfer confirmation. The failure may be due to an invalid user ID or
password. The error code for the transfer is stored in the ORDSTAT table OSCODE
column and the error status message can be located in the ORDSTAT table OSCMT
column.
(2) An empty quotation order arrived due to quotation failure.
I

Submitted: The customer has submitted the order, but has not yet initiated
payment.

Junk or Deleted Order

Low inventory: The customer has initiated payment. A previously allocated (or
backordered) order item has become unavailable.

Payment initiated: The customer has initiated payment. Authorization is pending.

Approval denied: Approval has been denied for some order items.

P
 Pending: The customer can modify this order.

Quick order profile: The order contains default information for a customer such as
shipping address and payment information that can be copied when creating a new
pending order.

Released: All order items have been released for fulfillment.

Shipped: All order items have been manifested.

Temporary: Used by the Order Management user interface to temporarily back up

an order.

Waiting for approval: Not all order items have obtained approval.

Canceled: The order has been canceled.

Private requisition list: The order is a private requisition list (ordering same items
frequently)

Shareable requisition list: The order is a shareable requisition list.

Tables in Order subsystem:

IITEMLIST
Each row in this table represents an InterestItemList.
IITEM
Each row of this table represents an IItem in an IItemList.
CIITEMLIST
Each row in this table represents the relationship between an IItemlist and a member to
which it is the current list.
ORDERS
Each row in this table represents an order in a store.

SUBORDERS
Each row of this table contains subtotals of amounts for all the OrderItems of an Order with
the same shipping address.

ORDERITEMS
Each row of this table represents an order item in an order.

ORDPROMOCD
This table contains promotion codes captured for an order.
              
CPENDORDER
Each row of this table indicates that an order is marked as current for a customer in a store,
if its status is "P" (Pending).

ORDPAYINFO
Each row in this table holds a name-value pair representing payment information for a
particular Order. Values added to this table are encrypted when the "Instance/PDIEncrypt"
configuration flag is "on".

ORDADJUST
Each row of this table represents an OrderAdjustment.

ORDIADJUST
Each row in this table represents an OrderItemAdjustment.

ORDADJTXEX
Each row of this table indicates that an OrderAdjustment is exempt from taxation of a
particular TaxCategory. For example, an "after tax rebate" can be represented as a negative
OrderAdjustment that is exempt from taxation of all TaxCategories.

ORDCALCD
Each row of this table indicates to the CalculationCodeCombineMethod that a
CalculationCode is directly attached to all OrderItems in an Order. The order
directCalculationCodeAttachment flag in ORDERITEMS.PREPAREFLAGS is 1.

ORDICALCD
Each row of this table indicates to the CalculationCodeCombineMethod that a
CalculationCode is directly attached to an OrderItem. The attachment is not effective unless
the directCalculationCodeAttachment flag in ORDERITEMS.PREPAREFLAGS is 1.

ORDTAX
Each row of this table represents the total of the tax amounts of a particular TaxCategory
for all the OrderItems in an Order.
SUBORDTAX
Each row of this table specifies the tax amount of a particular TaxCategory for all the
OrderItems with the same shipping address as the SubOrder.

ORDITAX
Each row of this table contains a tax amount of a particular TaxCategory, for an OrderItem.
By default, WebSphere Commerce does not save any data in this table. However tax
amounts are aggregated by TaxCategory in the SUBORDTAX and ORDTAX tables.

ORCOMMENT
The table stores the comments for an order entered by a customer service representative.

ORDERHIST
This table is used to save order snapshots in XML format.

Commands in Order subsystem:

InterestItemAddCmd
This command adds one or more products, or items, or both, to one or more interest item
lists.

InterestItemDeleteCmd
This command deletes catalog entries from one or more interest item lists.

InterestItemListDeleteCmd
This command deletes the specified interest item lists and all items in them.

InterestItemDisplayCmd
This command displays all the catalog entries and items in the specified interest item list or
lists.

SetInterestItemListCmd
This command sets or resets interest item lists as current. Invoking this command is the
only way to set or reset an interest item list as "current". Only registered users can execute
this command.

InterestItemListCopyCmd
This command creates or updates an interest item list by copying interest items from one
interest item list to another.
OrderItemAddCmdImpl
This command adds items or products to the shopping cart. OrderItemAddCmdImpl calls
the below commands in this sequence.
1)ResolveSkuCmdImpl
2)OrderCreateCmd
3)ResolveOrderItemPriceCmd
4)UpdateShippingAddressCmd
5)ValidateTradingPaymentCmd
6)DoInventoryActionCmd(CheckInventory)
7)UpdateShipInfoCmdImpl
8)RaiseOrderEventCmdImpl
9)OrderCalculateCmd
10)ExtendedOrderItemProcessCmd

1)ResolveSkuCmdImpl
This command finds the type of catalog entry. If it is a package then
PackageResolveSkuCmd is called. If it is a product then this command determines the
attributes required to resolve the product to an orderable item. If attributes are missing
then ErrorMissingAttributeErrorCmd or ErrorProductAttributeErrorCmd is called.

2)OrderCreateCmd
This order command is used to create an order container with no line items.

3)ResolveOrderItemPriceCmd
This command is used to resolve price for a group of order items from one order.This
command calculates the best price for the input OrderItems. It calls
GetContractUnitPriceCmd or GetContractSpecialPriceCmd task command to calculate the
price. If GetContractUnitPriceCmd/GetContractSpecialPriceCmd is not available, it calls
GetBaseUnitPriceCmd/GetBaseSpecialPriceCmd. If input trading agreements and/or offers
are specified, they will be used providing they are valid. Otherwise, eligible trading
agreements will be obtained.

4)UpdateShippingAddressCmd
This Order task command is used to update the shipping address for the passed order
items

5)ValidateTradingPaymentCmd
ValidateTradingPaymentCmd is called  to validate that the payment method is compatible
with the trading agreement

6)DoInventoryActionCmd(CheckInventory)
If doInventory = Y, call DoInventoryActionCmd to update the fulfillment centers and check
for available inventory

7)UpdateShipInfoCmdImpl
Call UpdateShipInfoCmd to update the shipping instructions, shipping account number and
shipping charge type

8)RaiseOrderEventCmdImpl
Call RaiseOrderEventCmd to raise ORDERITEM_CREATION_EVENT or
ORDERITEM_UPDATE_EVENT
9)OrderCalculateCmd
If the flag calculateOrder is set then Call OrderCalculateCmd to do calculations that are
based on the calUsageIds passed in

10)ExtendedOrderItemProcessCmd
Call ExtendOrderItemProcessCmd to execute any customization logic

OrderItemUpdateCmdImpl
OrderItemUpdateCmdImpl command updates order items in an existing
Order.OrderItemUpdateCmdImpl   calls the following commands in sequence

1)DoInventoryActionCmd(Reserve Inventory)
2)AddOrderItemComponentsCmd
3)ResolveOrderItemPriceCmd
4)UpdateShippingAddressCmd
5)ValidateTradingPaymentCmd
6)DoInventoryActionCmd(Check Inventory)
7)updateShipInfoCmdImpl
8)RaiseOrderEventCmdImpl
9)OrderCalculateCmd
10)ExtendedOrderItemProcessCmd

1)DoInventoryActionCmd(Action : Reserve Inventory)

In ATP inventory systems it calls the command ReserveInventoryCmd. In Non-ATP
inventory systems calls the UpdateInventoryCmd.

ReserveInventoryCmd
This command get the quantity available for the requested item, store, and fulfillment
center.This command check to make sure that the quantity available is greater or equal to
the quantity requested.If it is successful,obtain the ITEMFFMCTR row and increment the
itemffmctr.qtyreserved by the requested quantity,then insert a new row into the
INVRESERVE table.

UpdateInventoryCmd
UpdateInventory let you update inventory for items. There are two ways to update
inventory.Set one or list of order items by calling setOrderItem method.Set one catalog
entry by calling setCatEntryId, setQuantity and setStoreId methods. Method
setQuantityMeasure is optional.

2)AddOrderItemComponentsCmd
This command creates the components that are associated with a composite order item. It
derives the component list in one of two ways
1.    By making use of a  list of CatalogEntries that are passed in
2.    Get the list of components by finding all of the unassigned components through the
given configuration id.

3)ResolveOrderItemPriceCmd
This command is called to calculate the best price and update order total.

4)UpdateShippingAddressCmd
This Order task command is used to update the shipping address for the order items
passed in the request.

5)ValidateTradingPaymentCmd
ValidateTradingPaymentCmd is called to validate that the payment method is compatible
with the trading agreement.
6)DoInventoryActionCmd(Check Inventory)

Check Inventory allows us to check inventory for items. There are two ways to check
inventory.
1)      Set one or list of order items by calling setOrderItem method.
2)      Set one catalog entry by calling setCatEntryId, setQuantity and setStoreId methods.
Method setQuantityMeasure is optional.

7)updateShipInfoCmdImpl
Call UpdateShipInfoCmd to update the shipping instructions, shipping account number and
shipping charge type.

8)RaiseOrderEventCmdImpl
Call RaiseOrderEventCmd to raise ORDERITEM_CREATION_EVENT or
ORDERITEM_UPDATE_EVENT.

9)OrderCalculateCmd
If the flag calculateOrder is set Call OrderCalculateCmd to do calculations that are based on
the calUsageIds passed in.

10)ExtendedOrderItemProcessCmd
Call ExtendOrderItemProcessCmd to execute any customization logic.

OrderItemDeleteCmdImpl
This command delete order items based on orderItemId or catEntryId
specified.OrderItemDeleteCmdImpl calls below commands in sequence. 
1)DoInventoryActionCmd(ReserveInventory)
2)PrepareShipInfoCmd
3)ReolveOrderItemPriceCmd
4)OrderCalculateCmd

1)DoInventoryActionCmd(Action : Reserve Inventory)

In ATP inventory systems it calls the command reserveInventoryCmd. In Non-ATP
inventory systems calls the updateInventoryCmd.
ReserveInventoryCmd
Get the quantity available for the requested item, store, and fulfillment center.Check to
make sure that the quantity available is greater or equal to the quantity requested.If the
above edit is successful,obtain the ITEMFFMCTR row and increment the
itemffmctr.qtyreserved by the requested quantity,then insert a new row into the
INVRESERVE table.
updateInventoryCmd
UpdateInventory let you update inventory for items. There are two ways to update
inventory.Set one or list of order items by calling setOrderItem method.Set one catalog
entry by calling setCatEntryId, setQuantity and setStoreId methods. Method
setQuantityMeasure is optional.

2)PrepareShipInfoCmd
Perform a verification between the SHIPINFO table and the ORDERITEMS table and check
for orphaned SHIPINFO records. Any orphaned records will be removed.

3)ReolveOrderItemPriceCmd
This command is used to resolve price for a group of order items from one order.This
command calculates the best price for the input OrderItems.This command calls the
GetContractUnitPriceCmd/GetContractSpecialPriceCmd task command to calculate the
price.
If GetContractUnitPriceCmd/GetContractSpecialPriceCmd is not available, it calls the
GetBaseUnitPriceCmd/GetBaseSpecialPriceCmd. If input trading agreements and/or offers
are specified, they will be used providing they are valid. Otherwise, eligible trading
agreements will be obtained.

4)OrderCalculateCmd
If the flag calculateOrder is set Call OrderCalculateCmd to do calculations that are based on
the calUsageIds passed in.
  
OrderPrepareCmd (Controller Command)
Prepares an order by determining its prices, discounts, shipping charges, and taxes. If an
order reference number is not specified, all current pending orders will be prepared for the
current customer at the given store. The remerge, merge, check, allocate, backorder and
reverse parameters are applicable only if ATP inventory is enabled (STORE Table
INVENTORYSYSTEM column value -1).

OrderPrepareCmd  calls the following commands in sequence

1.PrepareOrderCmd(Task Command)
2.ValidateShippingAdjustmentCmd

PrepareOrderCmd(Task Command)
PrepareOrderCmd task command prepares an order by determine its prices, discounts,
shipping charges, and taxes for an order. This command will also lock the order to indicate
that it is ready for submission for the Order Process command. The lock can be reset either
by expiry, by changing the Order during update or delete operations or by calling
OrderUnlockCmd.The expiry period for a lock is stored in STORE table column
QUOTEGOODFOR.
This command removes generated order item based on the prepare flags setting (PREPARE
FLAG = 1 which means generated) in ORDERITEMS table. This command will also check if
all order items are buyable and throw exceptions if they are not buyable.
UpdateShippingAddressCmd is called to find the appropriate shipping address for all the
order items and update them for each order item. For a dynamic kit
ValidateDynamicKitConfigurationCmd is called to do validation.
ResolveOrderItemPriceCmd is called to calculate the best price and update order total.
DoInventoryActionCmd is called for inevntoy check and allocation .CalculateOrderCmd is
called for calculation of charges.

ValidateShippingAdjustmentCmd
This Order task command is used to find any inconsistencies in the order's shipping
adjustments. If new items have been added then the value returned from
hasShoppingCartChanged() will be true else it will be false.

OrderProcessCmd (Controller Command)

This command submits an order for processing. The order must be locked by the Order
Prepare command before calling this command.
 
OrderProcessCmd calls the following commands in the below sequence

1)PIAddCmd
This controller command is used to create a new payment method to an order.
2)ValidatePaymentMethodCmd
This command checks whether the payment method to be added comply with the Buy
Online Pick In Store (BOPIS) rules.
3)ProcessOrderCmd
The ProcessOrderCmd task command makes the ProcessOrder server request.
4)RaiseOrdereventCmd
The RaiseOrderEventCmd task command is used to raise an order related event

ProcessOrderCmd (Task Command)

ProcessOrderCmd makes the ProcessOrder server request.ProcessOrderTaskCmd calls

commands in sequence as shown below.

1)PreProcessOrderCmd
If Unified Business Flow is not enabled or is enabled and approval is needed then this
command is called.
2)DoInventoryActionCmd(getATPParameter)
Call DoInventoryActionCmd to update inventory.
3)UpdateSependingLimitCmd
Call UpdateSpendingLimitCmd to check the trading agreement spending limit and validate
the PO number.
4)PrimePaymentCmd
Call PrimePaymentCmd (EDP command) to guarantee that the customer has funds to pay
for the order.
5)RaiseOrderSubmitEventCmd
Call RaiseOrderSubmitEventCmd to raise the order submit event.
6)PersisitOrdersWithMemberGroupIdsForCurrentUserCmd
PersistOrdersWithMemberGroupIdsForCurrentUserCmd (Marketing command) is called If
OrdersMgpPersistListener is enabled in order to persist the orders_id with the member
group id.
7)ExtOrderProcesCmd
ExtOrderProcessCmd command is called  to execute  any customization logic during order
process flow.
8)TransferOrderCmd
This command confirms successful transfer of an order to an external system. This
command is called to generate the outbound Order Create Message.
9)OrderMessagingCmd
This command generates the outbound Order Create Message "Report_NC_PurchaseOrder".

Marketing subsystem
The Marketing subsystem is a component of the WebSphere Commerce Server, and
provides numerous marketing concepts to your site, designed to increase brand awareness,
and to attract and retain customers. Components of the marketing subsystem provide
functionality to create marketing campaigns, including customer segments and advertising;
and e-mail activities. All of these components can be extensively customized to ensure that
your site's marketing strategy matches that of your brick and mortar store.

Promotion groups
Promotion groups, as the name implies, group promotions according to their type. These
groups have no hierarchical structure, or priority. By default, each store has the following
promotion groups

1.ProductLevel Promotions  

2.Order Level Promotions 

3.Shipping Promotions
 
Product Level Promotions can be
1. Percentage off per item.
2. Fixed amount off per item.
3. Fixed amount off for all.
4. Buy X, get one or more items at a discount.
5. Free gift with purchase.
Order Level Promotions can be
1. Percentage off.
2. Fixed amount off.
3. Free gift with purchase.
Shipping Promotions can be
1. Free shipping.
2. Discounted shipping for an order using a selected ship mode.
3. Discounted shipping for all items using a selected ship mode.
4. Discounted shipping per item using a selected ship mode.
Promotion life cycle

A business user creates a promotion in the inactive state. From that point forward, the
promotion can be activated, modified, and deleted.When a promotion is first created, it
is inactive.When an inactive promotion is activated, a new version of that promotion is
created and marked active. The original promotion is then marked as obsolete.An active
promotion can be withdrawn, marking it as inactive.
Promotions are static. When changes are made to a promotion, a new revision is made.
The new revision inherits the state of the promotion before the change. The original
promotion is then marked as obsolete.Promotions in either active or inactive state can
be modified or deleted. The changes take effect immediately after they are made.

Promotion engine components

Promotion engine comprises a series of configurable components. All of these

configurable components are specified in a configuration XML file,
WCSPromotionEngineConfig.xml. The promotion engine is configured per Web Sphere
Commerce instance; it is not possible to have different configurations for stores in the
same instance.

The promotion engine evaluates promotions for customers while they shop on the
storefront. The evaluation process has several stages and involves different components of
the promotion engine (PromotionAgendaBuilder, PromotionSequenceBuilder)
The two commands that call the promotion engine are:
1. PromotionEngineOrderCalculateCmdImpl
2. PromotionEngineDiscountCalculationCodeCombineCmdImpl
When the promotion engine is called, it processes any promotions for the current order,
and returns a PromotionArgument.The order subsystem is then responsible for
interpreting the results (PromotionArgument) returned by the promotion engine and
storing the results the respective order and order item adjustment tables. Due to
limitations in the order subsystem, not all Adjustments are supported by the order
subsystem
PX_PROMOTION  -This table contains promotions.

PX_GROUP- This Table contains the promotion groups for the site.

PX_GRPPOLICY -This table contains relationships between promotion groups and

promotion policies.

PX_POLICY - This table contains promotion policies.

CATENCALCD -  A row in this table indicates that a CalculationCode is attached to a

CatalogEntry. And it is also attached to the CatalogEntry's PRODUCT_ITEM children (or all
CatalogEntries) for the specified Store. And also it is attached to TradingAgreement (or all
TradingAgreements).

CATGPCALCD – A row in this table indicates that a CalculationCode is attached to all

CatalogEntries (and their PRODUCT_ITEM children) in a CatalogGroup for the specified
Store and TradingAgreement (or all TradingAgreements).

CLCDPROMO -This table stores information about the relationship between the

Calculation Framework and the promotion standalone infrastructure. Each calculation code
matches one promotion in the PX_PROMOTION table.

PX_USAGE -This table tells about statistics the promotion usage. Also contains the
ORDERS_ID of the orders to which the promotion was applied.

PX_COUPON -This table contains all of the coupons issued to individual customers. Also
contains the ORDERS_ID of the orders to which the coupon was applied.

PX_DYNATTR -This table contains the details about any dynamic attributes that belong to
promotion entities, such as promotion groups, promotion policies, and others.

PX_PROMOARG- This table contains details about how promotions are applied to an order.
This table contains the history of promotions applied to an order.
PX_PROMPROM-Reserved for IBM internal use.

PX_TPLTGRP - Reserved for IBM internal use.

PX_TEMPLATE- Reserved for IBM internal use.

Enabling debug / Trace for promotion engine

Open WCSPromotionEngineConfig.xml

Change

<DefaultBehavior>
<StatelessInvocation>true</StatelessInvocation>
<CheckTargetingAtRuntime>true</CheckTargetingAtRuntime>
<SkipTargetingOnCodeEntered>true</SkipTargetingOnCodeEntered>
<PriceAdjustmentBasedOnStandardOfferPrice>true</PriceAdjustmentBasedO     
 nStandardOfferPrice>
 <Debug>false</Debug>
 </DefaultBehavior>

to

<DefaultBehavior>
<StatelessInvocation>true</StatelessInvocation>
<CheckTargetingAtRuntime>true</CheckTargetingAtRuntime>
<SkipTargetingOnCodeEntered>true</SkipTargetingOnCodeEntered>
 <PriceAdjustmentBasedOnStandardOfferPrice>true</PriceAdjustmentBasedOnStandardO
fferPrice>
 <Debug>true</Debug>
 </DefaultBehavior>

Save and Restart the server.

 
E-Marketing Spots

E-Marketing Spots reserve space on your store pages for displaying marketing information to
your customers. By using web activities, you can control the information that displays in e-
Marketing Spots without new development.

E-Marketing Spots can display the following types of marketing information:

Content, such advertisements for promotions
Category recommendations
Catalog entry recommendations, including merchandising associations

EMSPOT: This table contains registered e-Marketing Spots.

DMEMSPOTDEF: The default content to display in an e-Marketing Spot. Holds the unique
identifier of the content. For content of type MarketingContent, it holds the
COLLATERAL.COLLATERAL_ID. For content of type CatalogGroup, it holds the
CATGROUP.CATGROUP_ID. For content of type CatalogEntry, it holds the
CATENTRY.CATENTRY_ID.
COLLATERAL: This table contains data describing the advertisements used by marketing
campaigns.
COLLDESC: This table holds language-dependent information related to a Collateral.
WebActivities
Web activities control what to display in each e-Marketing Spot. Each e-Marketing Spot typically
has one or more web activities that are associated with it. Web activities can target different
types of customers with different advertisements or recommendations, so each customer
viewing the e-Marketing Spot might not see the same thing. In this way, the content of an e-
Marketing Spot is dynamic.

Web activities are managed by Marketing Managers. They are used to deliver brand or
promotional messages to customers through a variety of methods.

Tables Associated

DMACTIVITY: A definition of the interaction with a customer to market content.

DMELEMENT: Campaign elements associated with a marketing activity.
DMELEMENTNVP: Name value pairs associated with a campaign element.
DMELETEMPLATE: Template definitions of trigger, target, and action campaign elements. A
trigger is used to wait for a customer to do something, or to wait for a certain period of time to
elapse. When a trigger occurs, the activity flow can continue from where the trigger was
defined in the flow. A target is used to qualify customers for subsequent actions or continue
execution of the activity flow. Targets are usually based on a customer's behavior and
segmentation. An action is a step to perform as part of the activity flow. Actions are the "to do"
based on the previous sequence of triggers and targets. Most actions are for marketing
purposes, such as display content in an e-marketing spot, or send the customer an e-mail.
DMELEMENTTYPE: Types of trigger, target and action campaign elements for an activity.
DMTEMPLATETYPE: Types of marketing activity templates.

A static e-Marketing Spot, at any time, schedules only those activities that display the same
results to all customers. The activities do not contain targets, branches, or experiments. The
activities can have specific start and end dates.

A dynamic e-Marketing Spot, at any time, has one or more scheduled activities whose behavior
can depend on the current customer or the current context. These activities use targets,
branches, and experiments.

Caching in Marketing Subsystem

The marketing caching technique that is based on activity behavior allows for optimal caching
of e-Marketing Spots with no manual involvement. The marketing engine automatically detects
if the e-Marketing Spot is static or dynamic. If the e-Marketing Spot is static, then JSP caching
can be used for the e-Marketing Spot results. If the e-Marketing Spot is dynamic, then the
marketing engine determines the content to display. The marketing engine then uses the
dynacache command cache and distributed map cache entries to display the results.
Configuration is set in the e-Marketing Spot JSP snippets and the store cachespec.xml file, then
static e-Marketing Spots are automatically JSP cached.

In general, marketing objects can be cached within the following marketing-specific caches:
Marketing Business Objects Cache
Marketing User Behavior Cache
WCMarketingDistributeMapCache
DynaCache Marketing Command Cache
There are three aspects to gaining improvements in management center marketing:
Marketing JSP caching
Marketing command caching
Marketing business object caching

Marketing JSP Caching

We can improve performance by caching an e-Marketing Spot at the storefront based on the
activity behavior, which includes web activities and marketing content for which JSP snippet
caching based on activity behavior can be setup.

To set up this type of caching, dependency IDs are dynamically set to invalidate the cached JSP
when the e-Marketing Spot definition changes. These definition changes can be caused by
events such as web activity changes, default content changes, content changes, product
changes, and category changes. The page time limit is set to invalidate the page at the next
scheduled time that an activity is added or removed from the e-Marketing Spot. When the page
is reloaded, the new set of active activities for the e-Marketing Spot is in effect.

For each e-Marketing Spot JSP snippet in the store, include a cache entry similar to the
following code.
Ensure that the following are specified:

<cache-entry>
<class>servlet</class>
<name>/Madisons/Snippets/Marketing/ESpot/ContentAreaESpot.jsp</name>
<property name="do-not-consume">true</property>
<property name="do-not-cache">true</property>
<property name="save-attributes">false</property>
<cache-id>
<component id="emsName" type="parameter">
<required>false</required>
</component>
<component id="DC_storeId" type="attribute">
 <required>false</required>
</component>
<component id="DC_lang" type="attribute">
<required>false</required>
</component>
<metadatagenerator>com.ibm.commerce.marketing.cache.EMarketingSpotMetaData
Generator</metadatagenerator>
</cache-id>
</cache-entry>

For more information please visit the infocenter in the following link

http://www.ibm.com/support/knowledgecenter/en/SSZLC2_7.0.0/
com.ibm.commerce.admin.doc/tasks/tdcjspsnipcachactivbehav.htm

EMarketingSpotMetaDataGenerator
This class is used to assist in determining how an e-Marketing Spot can cache its results based
on the definition of the web activities and default content scheduled to the e-Marketing Spot.
The default value for do-not-consume should be true and for do-not-cache should be true. This
specifies to not cache the e-Marketing Spot JSP fragment. This class will dynamically set the e-
Marketing Spot JSP fragment to be cached if the e-Marketing Spot displays the same results to
all customers.

For more information about metadata generator please visit the below infocenter link

http://www.ibm.com/support/knowledgecenter/en/SSZLC2_7.0.0/
com.ibm.commerce.api.doc/com/ibm/commerce/marketing/cache/
EMarketingSpotMetaDataGenerator.html

<wcf:eMarketingSpotCache>

wcf:eMarketingSpotCache tag can be included within an e-Marketing Spot JSP fragment to

indicate that the JSP fragment is to be dynamically cached. This tag dynamically sets
dependency IDs for e-Marketing Spot cache entries. No variables are defined for the
wcf:eMarketingSpotCache tag.

When the wcf:eMarketingSpotCache tag is used, the class for this tag dynamically sets the
dependency IDs to invalidate the cached e-Marketing Spot JSP fragment when the e-Marketing
Spot definition changes. The e-Marketing Spot definition changes whenever the content
(marketing content, products, categories) or web activities that are associated with the e-
Marketing Spot changes. The dependency IDs are set for the e-Marketing Spot (ID or name).
Dependency IDs can also be set for the data (catalog entry, category, content) that is being
displayed within an e-Marketing Spot.
 If the parent page is being cached, the dependency IDs are set on the parent page cache
entry
If the parent page is not being cached, the dependency IDs are set on e-Marketing Spot JSP
cache entry
Sample Code

<wcf:eMarketingSpotCache marketingSpotData="${marketingSpotDatas}"
contentDependencyName="contentId" catalogEntryDependencyName="productId"
categoryDependencyName="categoryId"/>

Marketing Command Caching

The most resource-intensive part of evaluating a marketing rule is processing the query to
return the Service Data Object (SDO) business object. The SDO business object for categories,
catalog entries, and marketing content displays in an e-Marketing Spot. Command caching
stores the results of earlier queries in cache to take advantage of lower retrieval times in
comparison to retrieving results from main storage.

For marketing commands cache entries like the below has to be in place.

<!-- Cache Entry for Filter Marketing Content -->

<cache-entry>
<class>command</class>
<sharing-policy>not-shared</sharing-policy>
<name>com.ibm.commerce.marketing.commands.marketingspot.FilterContentTaskCmdIm
pl</name>
<cache-id>
<component id="getCacheKey" type="method">
<required>true</required>
</component>
<component id="getDataType" type="method">
<required>true</required>
</component>
<component id="getStoreId" type="method">
<required>true</required>
</component>
<component id="getLanguageId" type="method">
<required>true</required>
</component>
<component id="getActivityId" type="method">
<required>true</required>
</component>
<component id="getCatalogId" type="method">
<required>true</required>
 </component>
<component id="getExperimentId" type="method">
<required>false</required>
</component>
<component id="getTestElementId" type="method">
<required>false</required>
</component>
<!-- NEW: for e-Marketing Spot caching -->
<component id="getMarketingSpotBehavior" type="method">
<value>1</value>
</component>
</cache-id>
<!-- Invalidate when the associated marketing content or activity has changed. -->
<dependency-id>contentId
<component id="getCacheKey" type="method">
<required>true</required>
</component>
</dependency-id>
<dependency-id>activityId
<component id="getActivityId" type="method">
<required>true</required>
</component>
</dependency-id>
<dependency-id>dialogMarketingCommand</dependency-id>
</cache-entry>

To verify that cache is receiving data properly check the cache entries in the cache monitor.

Marketing object caching

Business object caching eliminates querying of marketing database tables when evaluating the
marketing rules for a customer. By managing the memory that is allocated to the cache we can
fine-tune marketing performance.

Marketing cache (DM_Cache)

The MarketingCache object cache instance is a location where a distributed map cache
(DM_Cache) stores data that pertains to a marketing business object.

The data that is stored in the MarketingCache includes:

Activity business objects
Element business objects
Trigger Listener business objects (which triggers are associated with each activity)
 Rules for detecting the occurrence of triggers and when something is to be recorded for a
target
Default content that is associated with an e-Marketing Spot
e-Marketing Spot ordering rules
The marketing commands to activate or deactivate activities, and to manage e-Marketing Spots,
maintain the appropriate data in the business object cache.

Note: Do not clear the DM_Cache with the WebSphere Application Server cache monitor. If the
entire DM_Cache is cleared with the WebSphere Application Server cache monitor, then the
marketing services do not detect the events that are associated with any behavior rules. As a
result, certain triggers and targets that are used in marketing activities to detect customer
behavior do not work properly. If you need to clear the DM_Cache, then update the Marketing
registry with the Administration Console.

Marketing user behavior cache (DM_UserCache)

The MarketingUserCache object cache instance is a location where a distributed map cache
(DM_UserCache) stores data about customers that participate in marketing activities.

Note: For the Display Recently Viewed action in a web activity, only the server stores the list of
recently viewed items in the marketing user behavior cache. The list is not stored in the
database by default. When the customer's user behavior cache entry is removed from the
cache, that customer's recently viewed list is lost. The user behavior cache entry of a customer
is removed from the cache when it is not modified for 30 minutes. The user behavior cache can
also be removed when the cache is full. The default size is 10,000 cache entries. You can
configure the user behavior cache to hold more entries by increasing the size of the cache and
by enabling disk offload.

Updating the registry

If the marketing information in the database is updated through SQL, massload, or stageprop,
then clear all cached information. Updating the registry through the Administration Console
clears the MarketingCache and MarketingUserCache, and the command and JSP caches.

Payment SubSystem:

The Payments subsystem contains three main parts:

Payment rules engine

The Payment rules engine determines which action to take based on the payment
instruction, payment method and the payment event.
Payment plug-in controller

The Payment plug-in controller is a component of the Payments subsystem. It determines

which plug-in to use (based on the payment method) and which plug-in API method to call
(based on the action).

Payment plug-ins

A payment plug-in is a self-contained software component that serves as a proxy for a

payment back-end system.

Payment Flow at a glance

The shopper or CSR completes an order. When the order is submitted, the OrderProcess
command runs, then invokes the PrimePayment payment task command.

The Payment rules engine determines the payment action that needs to be performed, for
example, Approve.

The payment action is wrapped into an event, which is passed to the Payment plug-in
controller. For example, for the approve action, the Payment plug-in controller API
Approve is called.

The Payment plug-in controller determines which plug-in to use.

The payment action is invoked against the plug-in. For example, for approve action, the API
approve of the corresponding plug-in is called.

The plug-in interacts with the Payment Service Provider.

The plug-in sets the transaction state according to the transaction execution results with
the Payment Service Provider. This transaction state will return to the Payment plug-in
controller.

The Payment plug-in controller updates the payment related records in the database
according to the state of transaction execution returned by the plug-in.

Payment Lifecycle

There are three stages to payment processing:

validation

reservation

finalization
The payment life cycle is related to the order life cycle stages:

order capture

release to fulfillment

shipping

validation

Ensures that a customer has enoughfunds to make the purchase. The payment action
depends on the customer's payment method. For instance, when a customer pays for a
purchase using a credit card, a credit card authorization is sent and if it is valid, the
transaction is approved. This process occurs during an order submission.This
authorization can be 1$ or full $ auth. It depends on the business needs.

reservation

Ensures that funds are available before shipment of the goods. The reservation amount is
the sum of all order release amounts. This process occurs during a release to fulfillment.

finalization

Payment finalization is typically driven by a shipment confirmation message from or on

behalf of the fulfiller. This process occurs when the goods are shipped for the order
release.

An order can have multiple releases if items in the order must be shipped from different
warehouses or use different carriers, or if some of the items need to arrive at different
times, such as for an expedited item. Additionally, a customer can group order items in the
same order to ship together, including backordered items or future shipments.

Order life cycle phase

PrimePaymentCmd

ReservePaymentCmd

FinalizePaymentCmd

Order and Payment Subsystem Flow

Once items are added to cart, an order is created in the ORDERS table with status as
pending “P”. Items in the shopping cart are added to ORDERITEMS table which has an
ORDER_ID reference to the ORDERS table. Correspondingly, a payment order record is
created in the EDPORDER table. Once the customer selects payment method and proceeds
for payment, for each payment method in the order, there is a payment instruction record
created in the EDPPAYINST.

Using the payment instruction returned, you can get the details like amount, payment
method, etc.

There is a PPCPAYINST table which stores the value object Payment Instruction in WCS
which contains information for payment plugins to process the final payments. Payments
for a specific payment method can only be charged upto a maximum specified by the
AMOUNT column in PPCPAYINST table. PPCEXTDATA contains non-standard data specific
to a payment method. For example, paymentexpress might have some non-standard
protocol data which is stored in here.

Tables

EDPOEDER is the part that handles the payments part only. Every order has an entry in
EDPORDERS.

EDPPAYINST contains the list of all payment instructions associated with an order. To
fetch ths list we have to come through EDPORDER.

PPCPAYINST contains the detailed information required to process financial transactions.

BACKPIID of EDPPAYINST points to PPCPAYINST.

PPCEXTDATA stores the non-standard protocol data required in the financial transaction
which goes beyond the standard attributes defined in the payment instruction

EDPPAYHIST keeps the payment activity history for all operations on payment
instructions and financial transactions.

Dataload:

Data can be loaded into WCS tables using data load utility.

There are three configurations files and a input source file required to complete the data
loader setup. WCS supports only CSV File Reader for other input source you should write
your own Reader Class. This means that if you are using OOB CSVReader then your input
file must be a CSV file. The three configuration files are listed below.

1.wc-dataload-env.xml
2.wc-dataload-loader.xml
3.wc-dataload.xml
wc-dataload-env.xml holds the environment settings such as database name, encrypted
password, database type, user name, schema name.

<?xml version="1.0" encoding="UTF-8" ?> 

<_config:DataLoadEnvConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" 
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/
config ../../../../xml/config/xsd/wc-dataload-env.xsd" 
xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config">
<_config:BusinessContext storeIdentifier="Madisons"
catalogIdentifier="Madisons" languageId="-1" currency="USD" />
<_config:Database type="derby" name="..\..\db\mall" />
<_config:DataWriter
className="com.ibm.commerce.foundation.dataload.datawriter.JDBCDataWriter" />
</_config:DataLoadEnvConfiguration>

wc-dataload-loader.xml holds the mapping between your input csv file and the WCS
tables.

<_config:DataMapping>
<_config:mapping xpath="CatalogGroupIdentifier/UniqueID" value="GroupUniqueId" />
<_config:mapping xpath="CatalogGroupIdentifier/ExternalIdentifier/GroupIdentifier"
value="GroupIdentifier" />
<_config:mapping xpath="ParentCatalogGroupIdentifier/UniqueID"
value="ParentGroupUniqueId" />
<_config:mapping
xpath="CatalogGroupIdentifier/ExternalIdentifier/StoreIdentifier/ExternalIdentifier/
NameIdentifier" value="StoreIdentifier" valueFrom="InputData" />
<_config:mapping
xpath="ParentCatalogGroupIdentifier/ExternalIdentifier/GroupIdentifier"
value="ParentGroupIdentifier" />
<_config:mapping
xpath="ParentCatalogGroupIdentifier/ExternalIdentifier/StoreIdentifier/
ExternalIdentifier/NameIdentifier" value="ParentStoreIdentifier"
valueFrom="InputData" />
<_config:mapping xpath="topCatalogGroup" value="TopGroup" />
<_config:mapping xpath="displaySequence" value="Sequence" />
<_config:mapping xpath="Description[0]/Name" value="Name" />
<_config:mapping xpath="Description[0]/ShortDescription" value="ShortDescription" />
<_config:mapping xpath="Description[0]/LongDescription" value="LongDescription" />
<_config:mapping xpath="Description[0]/Thumbnail" value="Thumbnail" />
<_config:mapping xpath="Description[0]/FullImage" value="FullImage" />
<_config:mapping xpath="Description[0]/Attributes/published" value="Published" />
<_config:mapping xpath="Description[0]/Keyword" value="Keyword" />
<_config:mapping xpath="Description[0]/Attributes/note" value="Note" />
<_config:mapping xpath="Attributes/field1" value="Field1"/>
<_config:mapping xpath="Attributes/field2" value="Field2"/>
<_config:mapping xpath="" value="Delete" valueFrom="InputData" deleteValue="1"/>
</_config:DataMapping>

wc-dataload.xml is the main xml that is passed as parameter to the dataload utility, this
file contains information about the environment file, loader file and input CSV file for the
loader.

Dataload file would like the one shown below.

<?xml version="1.0" encoding="UTF-8" ?> 

<_config:DataLoadConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" 
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/
config ../../../../xml/config/xsd/wc-dataload.xsd" 
xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config">
<_config:DataLoadEnvironment configFile="wc-dataload-env.xml" /> 
<_config:LoadOrder commitCount="100" batchSize="1" dataLoadMode="Replace">
<_config:LoadItem name="CatalogGroup" businessObjectConfigFile="wc-loader-catalog-
group.xml">
<_config:DataSourceLocation location="CatalogGroups.csv" /> 
</_config:LoadItem>
<_config:LoadItem name="CatalogEntry" businessObjectConfigFile="wc-loader-catalog-
entry.xml">
<_config:DataSourceLocation location="CatalogEntries.csv" /> 
</_config:LoadItem>
</_config:LoadOrder>
</_config:DataLoadConfiguration>

Running the Dataload Utility

To run  the dataload utility, just go to command prompt and navigate to WCS installation
folder and then open bin folder, by default it would be the one shown below.

C:\IBM\WCDE_INSTALL70\bin
Type dataload.bat <path of dataload file>
for e.g dataload C:/IBM/WCDE_INSTALL70/samples/DataLoad/Catalog/wc-dataload.xml

Custom Data Load -Load data into custom tables

Use the table object builder and table object mediator to load data directly into a table with
the Data Load utility when a component-based business object mediator does not exist. You
can use the TableObjectMediator and TableObjectBuilder to load your custom data directly
into your target database tables. This mediator and builder can ensure that the data is
loaded into the correct table and columns. You do not have to create a custom business
object mediator and builder or extend an existing mediator or builder.

You can use the table-based mediator to load data with the Data Load utility when the
following conditions exist:
You want to load data into a table when a component-based object mediator does not exist
for the object that you are loading.
You are loading data into a table that is updated and you do not want to customize or
extend the existing component mediator.
You are loading custom UserData into an extended table.You can add your UserData into a
default provided sample CSV or XML file. You can then load this file by using the
TableObjectMediator and TableObjectBuilder with the Data Load utility.

Table-based builder

The TableObjectBuilder business object builder works with the TableObjectMediator

business object mediator. The Data Load utility creates a list of extended table data objects,
which the table object builder populates with the column values that are included in the
input data. The builder class also populates the data objects with any fixed values that are
defined for the objects in the column definitions that are specified in the business object
configuration file. The Data Load utility passes the populated list of extended table data
object to the TableObjectMediator.

Table-based mediator

TableObjectMediator is used to convert the data objects into physical objects. To use a
table-based data load, you must know the physical tables that you want to load data into.
You also must know the foreign key relationships, how the keys generate, and how the
generated keys are resolved based on the unique index. The column values that the Data
Load utility can retrieve from the business contexts must also be known. This mediator
accepts the populated table data objects from the builder class. Any partially populated
table data object is populated with more values with this mediator to ensure that the data
object can be resolved. The mediator populates the data objects with values from the
business context. The data object IDs are resolved through the business context service or
through the ID resolver. After the data object is populated, the data object is sent to the
data writer to populate the data object into the appropriate database table.

I will try to explain the data load on custom tables using Table-based builder and
table object mediator by loading data into a custom table called EMPLOYEE.

Custom Data Load –Loading data into custom table EMPLOYEE

// Create Table  EMPLOYEE

CREATE TABLE  EMPLOYEE (
EMPLOYEE_ID BIGINT NOT NULL,
NAME VARCHAR(254),
TYPE  VARCHAR(254)
);

ALTER TABLE EMPLOYEE

ADD PRIMARY KEY (EMPLOYEE_ID);
  

//keep the table name in lower case letters

//Keys table entry will help to create primary key generation during Data load.

INSERT INTO KEYS (KEYS_ID, TABLENAME, COLUMNNAME, COUNTER, PREFETCHSIZE,

LOWERBOUND, UPPERBOUND, OPTCOUNTER)
VALUES ((SELECT MAX(KEYS_ID) + 1 FROM KEYS), 'employee', 'EMPLOYEE_ID', 0000, 1,
1000, 999999, 1);

Method 1: Loading data using CSV  Input

1. Define the CSV file (Employees.csv) with NAME, TYPE as header.

name,type
employeex,admin
employeeY,tester

Define the wc-dataload xml file as below.

This  file  defines the   environment file (wc-dataload-env.xml),Loader file (wc-loader-

employee.csv) and csvfile (Employees.csv) as below.

<_config:DataLoadConfiguration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/
config ../xsd/wc-dataload.xsd"
 xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config">
<_config:DataLoadEnvironment configFile="wc-dataload-env.xml" />
<_config:LoadOrder commitCount="100" batchSize="1" dataLoadMode="Replace" >
<_config:LoadItem name="employee" businessObjectConfigFile="wc-loader-
employee.xml" >
<!--Indicates the location of input csv files, can be overrided at runtime.-->
<_config:DataSourceLocation location="employees.csv" />
</_config:LoadItem>
</_config:LoadOrder>
</_config:DataLoadConfiguration>
Define the wc-dataload-env.xml as below

This  file  defines the storeIdentifier, catalogIdentifier and DB details.

<?xml version="1.0" encoding="UTF-8"?>

<_config:DataLoadEnvConfiguration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/
config ../../..
/xml/config/xsd/wc-dataload-env.xsd"
xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config">
<!-- Madisons Store in Toolkit -->
<_config:BusinessContext storeIdentifier="Aurora" catalogIdentifier="Aurora"
languageId="-1" currency="USD">
</_config:BusinessContext>
<!-- database setting for derby in Toolkit -->
<_config:Database type="derby" name="..\db\mall" schema="APP"/>
<!-- database setting for Oracle -->              
<!--
<_config:Database name="<database name>" user="<user>" password="<password>"
port="1521" schema="<schema name>" server="<server>" type="Oracle" 
dbDriverType="thin" />
 -->        
<!-- database setting for AIX/DB2 server -->
<!--
<_config:Database type="db2" name="<database name>" user="<user>" password="   
<password>" server="<server>" port="<port>" schema="<schema>" />
--> 
<_config:IDResolver
className="com.ibm.commerce.foundation.dataload.idresolve.IDResolverImpl"
cacheSize="10000000"/>
<_config:DataWriter
className="com.ibm.commerce.foundation.dataload.datawriter.JDBCDataWriter" />
</_config:DataLoadEnvConfiguration>

Define the wc-loader-employee.xml as below

<_config:DataloadBusinessObjectConfiguration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/config  
xsd/wc-dataload-businessobject.xsd"
xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config">
<_config:DataLoader
className="com.ibm.commerce.foundation.dataload.BusinessObjectLoader">

<_config:DataReader
className="com.ibm.commerce.foundation.dataload.datareader.CSVReader"
firstLineIsHeader="true" useHeaderAsColumnName="true" >
<_config:property name="keyColumns" value="Identifier" />
</_config:DataReader>

<_config:BusinessObjectBuilder
className="com.ibm.commerce.foundation.dataload.businessobjectbuilder.TableO
bjectBuilder" >  
<_config:Table name="EMPLOYEE">
<!-- System generated primary key-->
<_config:Column name="EMPLOYEE_ID" value="employee_id" valueFrom="IDResolve">
<_config:IDResolve tableName="EMPLOYEE" generateNewKey="true" />
</_config:Column>
<_config:Column name="NAME" value="name">
</_config:Column>
<_config:Column name="TYPE" value="type">
</_config:Column>
</_config:Table>  
<_config:BusinessObjectMediator
className="com.ibm.commerce.foundation.dataload.businessobjectmediator.Table
ObjectMediator">
</_config:BusinessObjectMediator>
</_config:BusinessObjectBuilder>
</_config:DataLoader>
</_config:DataloadBusinessObjectConfiguration>

This file defines the TableObjectBuilder(with

mapping  data ) and  TableObjectMediator.The reader used is CSVReader.

The Data Load utility creates a list of extended table data objects, which the table object
builder populates with the column values that are included in the input data. The builder
class also populates the data objects with any fixed values that are defined for the objects in
the column definitions that are specified in the business object configuration file. The Data
Load utility passes the populated list of extended table data object to the
TableObjectMediator. TableObjectMediator is used to convert the data objects into physical
objects.

Running the data load utitliy

Copy the files (employees.csv, wc-dataload.xml, wc-dataload-env, wc-loader-employee.xml

) in directory C:\IBM\WCDE_ENT70\samples\AuroraDataLoad\custom\CSV
Switch to C:\IBM\WCDE_ENT70\bin

Run the below command

Dataload C:\IBM\WCDE_ENT70\samples\AuroraDataLoad\custom\CSV\ wc-dataload.xml

Query the table to see the results 

Method 2: Loading data using  XML input

Define the employees.xml as below

<?xml version="1.0" encoding="UTF-8"?>

<employees>
<EMPLOYEE employee_id="" name="test1" type="admin"/>
<EMPLOYEE employee_id="" name="test2" type="csr"/>
</employees>

Define the wc-dataload xml file as below.

<?xml version="1.0" encoding="UTF-8"?>

<_config:DataLoadConfiguration
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/
config ../../..
 /../xml/config/xsd/wc-dataload.xsd"
 xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config">
 <_config:DataLoadEnvironment configFile="wc-dataload-env.xml" />
 <_config:LoadOrder commitCount="100" batchSize="1" dataLoadMode="Replace">
 <_config:property name="firstTwoLinesAreHeader" value="true" />
 <_config:LoadItem name="employees" businessObjectConfigFile="wc-loader-  
  employee.xml" >
 <_config:DataSourceLocation location="employees.xml" oldLocation="" />
 </_config:LoadItem>
 </_config:LoadOrder>
 </_config:DataLoadConfiguration>

Define the wc-dataload-env.xml as below

<?xml version="1.0" encoding="UTF-8"?>

<_config:DataLoadEnvConfiguration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/
config ../../..
/xml/config/xsd/wc-dataload-env.xsd"
xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config">
<!-- Madisons Store in Toolkit -->
<_config:BusinessContext storeIdentifier="Aurora" catalogIdentifier="Aurora"
languageId="-1" currency="USD">
</_config:BusinessContext>
<!-- database setting for derby in Toolkit -->
<_config:Database type="derby" name="..\db\mall" schema="APP"/>
<!-- database setting for Oracle -->              
<!--
<_config:Database name="<database name>" user="<user>" password="<password>"
port="1521" schema="<schema name>" server="<server>" type="Oracle" 
dbDriverType="thin" />
-->        
<!-- database setting for AIX/DB2 server -->
<!--
<_config:Database type="db2" name="<database name>" user="<user>" password="
<password>" server="<server>" port="<port>" schema="<schema>" />
--> 
<_config:IDResolver
className="com.ibm.commerce.foundation.dataload.idresolve.IDResolverImpl"
cacheSize="10000000"/>
<_config:DataWriter 
className="com.ibm.commerce.foundation.dataload.datawriter.JDBCDataWriter" />
</_config:DataLoadEnvConfiguration>

Define the wc-loader-employee.xml as below

<_config:DataloadBusinessObjectConfiguration
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/commerce/foundation/config 
xsd/wc-dataload-businessobject.xsd"
xmlns:_config="http://www.ibm.com/xmlns/prod/commerce/foundation/config">
<_config:DataLoader
className="com.ibm.commerce.foundation.dataload.BusinessObjectLoader">

<_config:DataReader
className="com.ibm.commerce.foundation.dataload.datareader.XmlReader" >
</_config:DataReader>

<_config:BusinessObjectBuilder
className="com.ibm.commerce.foundation.dataload.businessobjectbuilder.TableO
bjectBuilder" >  
<_config:Table name="EMPLOYEE">
<!-- System generated primary key-->
<_config:Column name="EMPLOYEE_ID" value="employee_id" valueFrom="IDResolve">
<_config:IDResolve tableName="EMPLOYEE" generateNewKey="true" />
</_config:Column>
<_config:Column name="NAME" value="name">
</_config:Column>
<_config:Column name="TYPE" value="type">
</_config:Column>
</_config:Table>
<_config:BusinessObjectMediator
className="com.ibm.commerce.foundation.dataload.businessobjectmediator.Table
ObjectMediator">
</_config:BusinessObjectMediator>
</_config:BusinessObjectBuilder>
</_config:DataLoader>
</_config:DataloadBusinessObjectConfiguration>

Running the data load utitliy

Copy the files (employees.csv, wc-dataload.xml, wc-dataload-env, wc-loader-employee.xml

) in directory C:\IBM\WCDE_ENT70\samples\AuroraDataLoad\custom\XML

Switch to C:\IBM\WCDE_ENT70\bin

Run the below command

Dataload C:\IBM\WCDE_ENT70\samples\AuroraDataLoad\custom\XML\ wc-
dataload.xml

Query the table to see the results