WebSphere Commerce Developer

Building metadata and data objects to reflect Data Service Layer schema changes

The WebSphere Commerce Data Service Layer Wizard generates the physical service data objects (SDO) Java classes for a customization. This Wizard also generates the required object-relational metadata and configuration for business object mediators. If you create a database table or develop new service modules, you must build the required object-relational metadata and physical SDOs with the Data Service Layer Wizard to reflect your schema changes.

Before you begin

The schema contains the new tables for which the physical SDO Java classes and object-relational mapping are needed.

About this task

This task describes how to use the Data Service Layer Wizard to add object-relational metadata and generate the physical SDO classes for a customized schema. The XML assets that you generate are stored in the service module configuration extension directories. The custom physical SDO Java classes that you generate are stored inside the WebSphereCommerceServerExtensionsLogic project. With this wizard, you can perform the following tasks:
  • Creates an extension configuration folder for your service module if one does not exist. The directory path is WC_eardir\xml\config\servicemodulepackagename-ext, where servicemodulepackagename is the package name of the service module you are working with, for example com.ibm.commerce.catalog.
  • Creates object-relational metadata that handles the mapping between the custom physical SDOs and the database customization. The file path is WC_eardir\xml\config\servicemodulepackagename-ext\wc-object-relational-metadata.xml.
  • Creates physical SDO Java classes for the new tables in the WebSphereCommerceServerExtensionsLogic project.
  • Creates a utility Java class to return the physical SDO root class for the service module. This root class ensures that all WebSphere Commerce physical SDOs for the Service Module, and any additional physical SDOs for the customization, are available at runtime.
  • If the service module is a WebSphere Commerce component, create an extension service module configuration file that instructs WebSphere Commerce to use the newly created physical SDO class. Create this configuration file in the following directory: WC_eardir\xml\config\servicemodulepackagename-ext\wc-component.xml. For custom service modules, this file is already created by the JET pattern when you create the service module.
  • If the service module is a WebSphere Commerce component, create an extension business object mediator configuration file for the service module. Ensure that the file you create can configure the business object mediator to include data from the custom tables in the user data area of a noun. Create this file in the following directory: WC_eardir\xml\config\servicemodulepackagename-ext\wc-business-object-mediator.xml. For custom service modules, this file is already created by the JET pattern when you create the service module.
Note: You must use supported database column data types in your custom tables. Supported data types are described in ../../com.ibm.commerce.database.doc/refs/rdbrdatatype.html. If you use unsupported data types, tools such as the Data Service Layer Wizard and the staging server can encounter errors.

Reading the log file that is generated by the Data Service Layer Wizard

The Data Service Layer Wizard .log file is in the RAD_INSTALL/workspace/.metadata directory. The size of this file can be large due to the generation of many lines of information into the log file by the eclipse plug-ins. While this file can contain a large amount of information, you can determine the relevance of each message by observing the Plugin ID. This ID serves as a prefix to all messages contained in the log.

To determine which messages are relevant to the Data Service Layer Wizard, observe all messages which are prefixed by the Plugin ID com.ibm.commerce.toolkit.internal.dataaccess in the log file.


Use the Data Service Layer wizard to generate object-relational metadata and physical data objects that represent the customized schema.
  1. If your development environment uses an Apache Derby database, ensure that there is no existing connection to it. For example, ensure that the WebSphere Commerce Server is stopped).
  2. Select File > New > Other > WebSphere Commerce > Data Service Layer .
  3. Click Next.
  4. Select Extend a default WebSphere Commerce service module or Work with a custom service module.
  5. Enter the required information. In Service module , select the name of the module for which you are building SDOs. In Extension class prefix, enter a string that is used to prefix all classes that are generated. In Extension Java package name, enter the name of the package that contains the SDOs.
    For example, if we are extending the catalog schema, the values would be as follows:
    • Service module: Select com.ibm.commerce.catalog
    • Extension class prefix: MyCompany
    • Extension Java package name: com.mycompany.commerce.catalog
  6. Click Next.
  7. Select the custom tables that you added to the schema.
  8. Under each table you have selected, select the columns you want to include in the SDO class. Primary key columns, non-nullable columns, and the optcounter column are automatically selected. Primary key columns are not available, because you must include them in the SDO.
  9. Click Next.
  10. On the Metadata Editing panel, you can choose what columns you want to include in the UserData area of the logical schema. Click the UserData column to set the value to true or false for the columns you want to include.
  11. OracleIf you use the Oracle NUMBER data type in a custom table, you must choose a more granular data type to map to. The Oracle NUMBER data type can represent different multiple types, including integer, float, and double. Using the drop-down list in the Datatype column, choose the appropriate mapping.
  12. Click Finish.