Store data information model viewed by data type

Data in WebSphere Commerce stores conforms to the types depicted in the following diagram. Each of the store data assets in the list of the Store data information model can be classified as belonging to one or more of the types of store data that is illustrated in the following diagram.

Transaction Server instance

The basic level of data is contained in the Transaction Server instance. When an instance is created, the bootstrap files, which are loaded in XML format, populate the database with information. The bootstrap files create the following types of data:

• Calculation usage types, device types (browsers, email, I-Mode), message types, roles, and addresses

• The default administrative ID, WCSADMIN

• The default commands, views, and URLs

• The default business policies

• The default access groups and access control policies

• The languages and currencies that are supported by the instance

• The default quantity units and quantity unit conversions

• The default scheduled jobs and state codes

• The default terms and conditions

• The default organization, which is an organizational entity used when a user registers and does not identify an organizational entity. In addition, guest customers are created under the default organization.

• The default store group

• The default information for staging

This information is available to all stores that exist in that instance.

Core data

The next level of store data is the core data. Core data is divided into two levels:

• Organization

• Store

The organization core data creates the minimum data for a business model-specific environment, including:

• The organization structure.

• Predefined user roles.

• Access control policies.

Organization core data is available in both the sample composite store archives, and the sample organization structure component store archives.

In WebSphere Commerce all assets, such as catalogs, stores, and orders are owned by an organization. Each organization (or its parent, or grandparent) can subscribe to a set of access control policies. Hence the organization structure determines the access control that is allowed to the assets owned by these organizations. The WebSphere Commerce organizations can also be used for other purposes such as B2B buyer organizations, company departments, and business units.

In the B2C business model, only the predefined organizations are required. However, in B2B environments, buyer organizations are created at runtime, when the B2B buyers register on the site. Part of the determination of a high-level organization structure is to decide where the buyer organization is to be created.

For extended sites and hosted business models, when a new store is created, an additional organization can be created as well, which owns the new store.

The core data creates the minimum data for a store within that environment, including:

• The store identifier in the STOREENT table. This entry creates a store in the database.

• The default contract.

• The store identifier in the contract database tables.

• The member identifier for the organization that owns the store in the contract database tables.

• The store directory in the STORE table. The store directory is the directory on the file system in which the store web assets are located.

• The nickname or identifier for the store address in the STADDRESS table. The nickname is unique for each store.

Store core data is available in both the sample composite store archives and the sample component store archives.

If you published any of the starter store archives indicated previously using the Publish wizard, this information was created for you. With the Publish wizard, we can select the default organization that can act as the store owner, or we can create another organization to act as the owner using the Organization Administration Console. If we did not publish a sample composite store archive to use as the basis of the store, we must load this information into the database by using the loading utilities, or edit the database directly.

The Stores data is classified as core data.

Configuration data

Configuration data controls the commerce server runtime. The commerce server runtime provides a framework in which the commerce applications are deployed and executed. The framework consists of command execution, exception handling, transaction control, data access, and persistence. The commerce server runtime uses the runtime services provided by WebSphere Application Server to support Transaction Server applications. Configuration data determines which commands and JSP files the store uses to display store pages.

The following data assets are classified as Configuration data:

• Command Registry Entries

Managed data

Managed data is data which the seller creates, and is read-only for customers of the seller site. Since the seller is in complete control of the state of this data, managed data can be managed through a content management system.

The following data assets are classified as managed data:

• Business policies

• Campaigns

• Catalog

• Contract and account assets

• Coupons

• Currencies

• Customer segments and collaboration

• Email activities

• Experiments

• Fulfillment centers

• Inventory (configuration information for catalog items)

• Jurisdictions

• Languages

• Members

• Payment

• Prices

• Promotions

• Sellers

• Shipping

• Tax

• Units of measure

• Vendors

• Web activities

Operational data

Operational data is data which is created or changed (directly or indirectly) by customers (users and buyer organizations) of the site as a result of their interactions with the site. For example, customer orders are considered operational data, as are inventory levels, which go up and down as the store operates. Customers are also considered operational data. Data that are created by the seller can also be operational.

Since changes to operational data are not under the complete control of the seller, this data is not managed by using a content management system.

The following data assets are classified as operational data:

• Contracts

• Customers

• Email activity

• Fulfillment

• Inventory (receipts, expected receipts, inventory allocation)

• Orders

• Request for quotes (RFQ)

Note: In some instances, the line between operational and managed data can be hard to determine. For example, in one store, customer and contract data can be considered managed data. In another store, the same type of data can be considered operational. The first store can manage their customer data and related contracts because they have a specific set of customers (that is, customers cannot register online). However, the second store allows customers to register online, and create contract information online.

A second example involves catalog data. In a single seller site, the catalog is considered managed data. In a B2B indirect site, catalog data that is maintained by business partners can be considered operational.

In some sites, certain records of the same data type can be considered managed while other records are considered operational. For example, the default contract can be managed data, but the specific contracts negotiated online are operational data. Another example is email activity. Email activity information and templates are considered managed data. The actual email activities that are generated from the templates and sent to customers are considered operation data. Any of the events that result from the mailing are also considered operational. For example, a customer that opens the email, or clicks any of the content in the email that can be clicked.

Store data types and the starter stores

The sample business models and starter stores provided with WebSphere Commerce include most of the types of store data in store data architecture. A Transaction Server instance must exist before a store can be created by using a starter store, or a starter store can be published. Then when creating a business model and stores that are based on one of the available business models and starter stores, using the tools in the Publish wizard, the core data is created. The business models and starter stores include all the necessary configuration, and most of the managed data required for a functional store.

Related concepts
Store data information model