Tutorials > Program model > Web services > Create a new WebSphere Commerce BOD service module
Implement the persistence layer for the WebSphere Commerce BOD programming model
The BOD programming model provides a Data Service Layer that is independent of the actual physical schema.
Each service module (for example, Catalog and Marketing) has an independent data service implementation that contains the following assets:
- Static physical service data objects (SDO) that provide a Java representation of the service models view of the WebSphere Commerce schema. Each service module has a physical SDO for those tables that the service module will read, update, or delete. For example the Catalog service module contains a physical SDO for the CATALOG table but does not contain a physical SDO for the ORDER table.
These physical SDOs are independent of the SDOs used to represent the logical model of a service module.
- Object-relational metadata that maps a physical SDO to the actual physical table in the WebSphere Commerce schema.
- Query templates that map WebSphere Commerce extended XPath notation expressions to one or more SQL template queries. These SQL template queries are used to fetch the physical data from the database. This data is represented as physical SDOs.
- A logical SDO (noun) to physical SDO mapping. For each logical SDO, this mapping defines the physical SDO that contains the unique ID of the noun.
- Business object mediators that build logical SDOs from physical SDOs and physical SDOs from logical SDOs.
- Read Mediators: Read mediators build a logical SDO out of the physical SDO defined in the logical SDO to physical SDO mapping.
- Change Mediators: Change mediators take a logical SDO as input and either create, update, or delete the appropriate physical SDOs. The modified physical SDOs are then saved back to the database.
- Read Mediators: Read mediators build a logical SDO out of the physical SDO defined in the logical SDO to physical SDO mapping.
WebSphere Commerce provides a tool called the Data Service Layer Wizard that automatically generates the service data objects and object-relational metadata mentioned previously. The wizard takes a list of the database tables as input and generates the object-relational mapping information and the static physical SDOs representing these tables. In the diagram below, you can see the physical SDOs:
Procedure
Use the Data Service Layer wizard to generate object-relational metadata and physical data objects representing the customized schema.
- If the 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 Work with a custom service module.
- Enter the following information:
- Service module: Select com.mycompany.commerce.bodtutorialstore
- Ensure that you have completed Step 8 of the Generate the TutorialStore service module projects tutorial. If this step is not completed, we will receive the following error: No custom service module is available.
- If you do not see this service module, delete the .internal file in the com.ibm.commerce.toolkit.internal.dataaccess_7.0.0.0.jar plugin. Or, copy the com.mycompany.commerce.project from WCDE_INSTALL\workspace\Project-Server\sampleConfig\xml\config to WCDE_INSTALL\xml\config.
- Click Next.
- Select the following tables:
- STORE
- STOREENT
- STOREENTDS
- STORELANG
- STORE
- Click Next.
- Click Finish.
Lesson Checkpoint
Review the assets created by the Data Service Layer wizard.
The following assets were generated:
- The physical SDOs are generated in the BODTutorialStore-Server project under ejbModule/com.mycompany.commerce.bodtutorialstore.facade.server.entity.datatypes.
These SDOs provide a Java view of the database for the TutorialStore service.
- The Storeent physical SDO contains get/set methods for each database column, for example, getStoreentId().
- The Storeent physical SDO contains get/set methods for each one-to-one relationship between the STOREENT table and another table included in the TutorialStore services view of the database. Methods are generated only for those tables that the TutorialStore service will use, all other relationships are ignored.
- The Storeent physical SDO contains get methods for each one-to-n relationships between the STOREENT table and another table included in the TutorialStore services view of the database. These methods return a list of SDOs representing the other table. For example, the getStoreentds() method returns a list of SDOs representing the STOREENTDS. One-to-n relationships are represented as a list as a store entity may have many descriptions, each in a different language.
- The Storeent physical SDO contains get/set methods for each database column, for example, getStoreentId().
- An object-relational metadata file that describes the relationship between the physical SDOs and the database. This file is stored in the TutorialStore service module's configuration folder under WC_EAR/xml/config/com.mycompany.commerce.bodtutorialstore/wc-object-relational-metadata.xml .