(Developer)
Build 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 we create a database table or develop new service modules, we must build the required object-relational metadata and physical SDOs with the Data Service Layer Wizard to reflect your schema changes.
Before starting
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, we can perform the following tasks:
- Creates an extension configuration folder for our service module if one does not exist. The directory path is workspace_dir\xml\config\servicemodulepackagename-ext, where servicemodulepackagename is the package name of the service module we 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 workspace_dir\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: workspace_dir\xml\config\servicemodulepackagename-ext\wc-component.xml. For custom service modules, this file is already created by the JET pattern when creating 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: workspace_dir\WC\xml\config\servicemodulepackagename-ext\wc-business-object-mediator.xml. For custom service modules, this file is already created by the JET pattern when creating the service module.
Note: We must use supported database column data types in our custom tables. If you use unsupported data types, tools such as the Data Service Layer Wizard and the staging environment 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, we 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.
Procedure
Use the Data Service Layer wizard to generate object-relational metadata and physical data objects that represent the customized schema.
- 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).
- Select File > New > Other > WebSphere Commerce > Data Service Layer .
- Click Next.
- Select Extend a default WebSphere Commerce service module or Work with a custom service module.
- Enter the required information. In Service module , select the name of the module for which we are building SDOs. In Extension class prefix, enter a string used to prefix all classes that are generated. In Extension Java package name, enter the name of the package containing 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
- Click Next.
- Select the custom tables that you added to the schema.
- Under each table you have selected, select the columns we 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 we must include them in the SDO.
- Click Next.
- On the Metadata Editing panel, we can choose what columns we 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 we want to include.
(Oracle) If you use the Oracle NUMBER data type in a custom table, we 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.
- Click Finish.