Customizing the WebSphere Commerce schema
In this lesson, you are customizing the physical layer by adding tables to contain store warranty and care instruction information to the WebSphere Commerce schema.
About this task
The following diagram outlines the changes to the WebSphere
Commerce schema:
The preceding
diagram shows the new XWARRANTY and XCAREINSTRUCTION tables, and how
they relate to the existing WebSphere Commerce tables, CATENTRY and
CATENTDESC.
- The XWARRANTY table has a foreign key to the CATENTRY table. The key allows the Data Service Layer (DSL) to populate data from the XWARRANTY table in the user data element of the CatalogEntry noun.
- The XCAREINSTRUCTION table has a foreign key to the CATENTDESC table to allow DSL to populate data in the attribute element of the CatalogEntryDescription noun part.
- The XCAREINSTRUCTION table has a foreign key to the CATENTRY table to provide support to the DSL search function.
To take advantage of the Data Service Layer user data
(and attribute) support, the following restrictions apply when adding
custom database tables:
- The custom tables must have a foreign key to the base table for the noun or noun part that contains the data. A base table is a table that contains the unique key for the noun or noun part. For example, the CATENTRY table is the base table for the CatalogEntry noun. These relationships are used when fetching or updating a noun or noun part to access the custom data.
- The relationship between the custom table and the base table must be a one-to-one relationship. User data is a map of name-value pairs. Each name represents a database column name and each value is the value in that database column. One-to-many relationships are not supported as each name in the map would collide.
Note: To enable this customizations in workspaces,
you must complete the following tasks after completing this tutorial:
- Run the CM_updateWorkspacesSchema script to enable your modified database tables. For more information about updating the Workspaces schema, See Ant target: CM_updateWorkspacesSchema.
- Run the following SQL statement to register the custom access
profile in the cmdreg; this SQL statement returns the locking information:
insert into cmdreg (storeent_id, interfacename, classname) values (0, 'com.ibm.commerce.catalog.facade.server.commands.InsertMoreCatalogEntryDataCmd+MyCompany_All.0', 'com.ibm.commerce.foundation.server.command.bod.bom.InsertMoreNounChangeControlMetaDataCmdImpl');
Note: Ensure that all foreign key relationships in the
custom tables specify ON DELETE CASCADE