Extending the WebSphere Commerce object model with entity beans

One situation that merits an extension to the existing WebSphere Commerce object model is addition of attributes to the application.

This can be accomplished in one of the following ways:

Without modifying an existing WebSphere Commerce public entity bean

Create a new database table, then create a new entity bean for that table. Add fields and methods to the entity bean to manipulate the new attribute, as required. Generate deployed code and an access bean for the new entity bean. When the application requires the new attribute, it instantiates an access bean object and uses its methods to retrieve, set, or manipulate the attribute.

By modifying an existing WebSphere Commerce public entity bean

Create a new database table, and create a table join between the new table and the existing table that corresponds to the existing enterprise bean that you are modifying. Create new fields in the existing WebSphere Commerce public entity bean and map the fields to their corresponding columns in the new table, using a secondary table map. Add any methods required. Regenerate the deployed code and access bean for the existing entity bean. The new attributes are available when the application instantiates the access bean object.

There are trade-offs between these two approaches. In general, the trade-offs relate to performance and effort for code maintenance.

 

Extension example

Consider an example in which the application requires you to capture the type of home that a customer has. You create a table called USERRES that contains the customer's ID and type of residence, where residence type (resType) may be a freehold home, a condominium, or an apartment. This type of information is demographic information, and as such, is related to the existing WebSphere Commerce USERDEMO table. In examining the WebSphere Commerce code repository, you find that the Member-MemberManagementData EJB module contains a "Demographics" enterprise bean. This bean has the getters and setters for demographic information stored in the USERDEMO table.

To perform your customization, there are two options. You can either create a new entity bean that interacts with the USERRES table, or you can add a new field (plus appropriate getter and setter methods) to the Demographics bean.

Use the first approach (creating entirely new code), you create a new Userres entity bean and map its fields to the columns of the USERRES table. When the application requires the customer's residence type, it must instantiate a Userres access bean object and retrieve the data. If the application requires other demographic information at the same time, it must also instantiate a Demographics access bean object and retrieve any other required attributes. Any parts of application logic that attempt to retrieve a complete set of demographic information for a customer must be modified to instantiate the new access bean as well as the original one. The following diagram displays this approach to extending the object model:

From a display template perspective, a data bean must be able to access the new attribute, so that the information is available to JSP pages. In order to present a unified view to the Web developer creating the JSP pages, you should create a new data bean that extends the access bean for the original, existing entity bean. The data bean should also use delegation to populate the attributes from the new access bean. The following diagram displays this data bean implementation scenario:

Use the second approach (modifying existing code), you add a new field to the Demographics entity bean and create a secondary table map between the new field and the appropriate column in the USERRES table. When the application requires the customer's residence type, it instantiates a Demographics access bean object and retrieves the residence type. If the application requires any other demographic information about the customer, it is available in the same call to the bean. The following diagram displays this approach to for enterprise bean modification:

From a display template perspective, the new attribute (resType) is automatically available in the data bean, as soon as the DemographicsAccessBean is regenerated.

Note that when you are extending the object model, not add new columns to existing WebSphere Commerce database tables. You must create a new table for the new attribute. If you do attempt to add new columns to existing tables, the new attribute will be lost when you migrate to future releases of WebSphere Commerce.

 

Performance and code maintenance implications

The second approach has better runtime performance. This is a result of the fact that getting or setting the new attribute only requires the instantiation of a single entity bean and a single fetch is used to retrieve all required attributes.

Due to the fact that the second approach modifies existing WebSphere Commerce code, a migration issue arises when a new version of WebSphere Commerce is released. You must merge your customized code with the new code, but when importing the new WebSphere Commerce workspace, the mapping information between the fields you added to the enterprise bean and the new table is not preserved. As a result, when migrating to a new release of WebSphere Commerce code, the following steps must be performed:

  1. Install the version of WebSphere Commerce Developer.

  2. Compare the the customized version of code to the new release of WebSphere Commerce code. Merge your customized code back into your workspace.

  3. Manually remap any attributes you added to WebSphere Commerce public enterprise beans to the appropriate columns in your database.

  4. Regenerate deployed code and access beans for the enterprise beans you modified in step 3.

In order to make this migration simpler, it is important to fully document your object model extensions at development time.

You may select to use a mix of the two approaches when making many extensions to the object model. Use the first approach for areas of the system that are less susceptible to a degradation in performance and use the second approach were performance is an issue. In this manner, you can minimize effort for future migration, while still maintaining good system performance levels. If the table has generic fields that are meant for customization, use the generic fields whenever possible

Related concepts

Extending the WebSphere Commerce object model
Extending the WebSphere Commerce object model with session beans
Flush remote method for entity beans
Extending public entity beans

Related tasks

Create new entity beans
Tutorial: Adding a finder to an existing entity bean