Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

Creating solutions on the extended sites framework in WebSphere Commerce

Part 1: Using the command layer

Michael DJ Shields (mshields@crossview.com), Solution Architect, CrossView, Inc.
Photo of Michael Shields
Michael Shields works for CrossView®, Inc. He has over a decade consulting and developing strategies to best leverage WebSphere Commerce to match client business requirements. He also has over twelve years of developing interactive web solutions using J2EE, PHP, Zend Framework, Adobe products, HTML, CSS, AJAX, jQuery, DOJO and JavaScript. Michael holds 5 patents, published over 12 tutorials on the WebSphere Commerce Information Center, and 10 tutorials on the developerWorks WebSphere Commerce zone. He holds over 12 technical certifications and a designation as a project manager (PMP).
Quan Nguyen (qnguyen@crossview.com), Solution Architect, CrossView, Inc.
Photo of Quan Nguyen
Quan Nguyen has been working for CrossView, Inc., since 1999, consulting and developing e-business solutions by leveraging WebSphere Commerce. As a Solution Architect, he has over a decade of experience, working with major B2C and B2B companies to implement robust WebSphere Commerce strategies, fulfilling their business requirements.
Raj Sanghvi (rsanghvi@crossview.com), Solution Architect, CrossView, Inc.
Photo of Raj Sanghvi
Raj Sanghvi is a Solution Architect for CrossView, Inc. He has over 6 years of experience consulting in WebSphere Commerce working for different sub systems. He also has over 10 years of experience doing software development using J2EE, Oracle, HTML, XML, and SOAP. He holds over 8 technical certifications and a designation as a project manager (CAMP). He has a Master's degree in Computer Science.
Amar Desai (amar.desai@atech.com), Solution Architect, Ascendant Technology
Photo of Amar Desai
Amar Desai is a Solution Architect at Ascendant® Technology. He has helped many top retail, banking, and dining companies materialize their vision in the e-commerce space using WebSphere Commerce. He has a penchant for applying the latest web application trends such as social commerce, precision marketing, and mobile commerce. He is a certified WebSphere Commerce developer and administrator.

Summary:  The purpose of extended sites in WebSphere® Commerce is to ensure sharable assets among different stores. This tutorial provides insight into different ways to use the store path resource that is an available-to-market framework in WebSphere Commerce. A new concept is introduced in this tutorial that provides provide granular levels of sharing with a sub-set of assets. Also, this tutorial describes how to properly extend an EJB to use the BeanFinderObject for your findBy methods to incorporate sharing queries. You will learn how to better ensure that your store's conglomerate is fully capable to share all of the integral assets to make your business successful, while keeping your software reusable and easy to maintain.

Date:  20 Oct 2010
Level:  Intermediate PDF:  A4 and Letter (143 KB | 53 pages)Get Adobe® Reader®

Activity:  23828 views
Comments:  

Extending new assets with BeanFinderObject

Prerequisites

If you already have a newly created entity bean, there will be a review step in this section to update that Entity Bean with a new UserFinderDescriptor finder type FinderHelper method. If you do not yet have an entity bean to incorporate a BeanFinderObject class, review the previous section to create a new entity bean.

This tutorial introduced the concept of affiliates as a way to customize extended site behavior through the use of store relationships and store relationship types. In this section, you will incorporate a custom store path relationship query into a newly created asset. If the Entity Bean you are working with has a UserFinderDescriptor finder type FinderHelper method, then the BeanFinderObject class using the same naming convention as the entity bean is automatically executed. For example, XCatentryExtBeanFinderObject will be the name of the class if the entity bean is called XCatentryExt.

Adding a new UserFinderDescriptor finder type FinderHelper method

To update an existing entity bean, for example, XCatentryExt:

  1. In Rational Application Developer, switch to the Enterprise Explorer view.
  2. Expand EJB Projects > WebSphereCommerceServerExtensionsData.
  3. Double-click Deployment Descriptor : WebSphereCommerceServerExtensionsData.
  4. In the EJB Deployment Descriptor editor, click the Bean tab.
  5. In the Beans pane, select the XCatentryExt bean.
  6. Click Add next to the Finders text box.
  7. Select the Bean tab.
  8. Add a UserFinderDescriptor finder type FinderHelper method to the XCatentryExtHome interface.

    With this FinderHelper method in place, you can extend the Entity Bean FinderHelper method. By extending, this means you will incorporate a BeanFinderObject. This is the essential step in this tutorial that will link the Entity Bean to the extended site behavior. The BeanFinderObject enables a special store path relationship query.

    Add a findByCatentryIdVendorIdStorePathId FinderHelper method to the XCatentryExtHome interface:

    1. In the EJB Deployment Descriptor editor, click the Bean tab.
    2. In the Beans pane, select the XCatentryExt bean.
    3. Click Add next to the Finders text box.
    4. In the Name field, enter findByCatentryIdVendorIdStorePathId.
    5. Click Add next to the Parameters text box:
      1. In the Name field, enter catentryId.
      2. In the Type field, enter java.lang.Long.
      3. Click OK.
      4. In the Name field, enter storeentId.
      5. In the Type field, enter java.lang.Long.
      6. Click OK.
      7. In the Name field, enter vendorId.
      8. In the Type field, enter java.lang.Long.
      9. Click OK.
    6. From the Return Type list, select Enumeration, then click Next.
    7. From theFinder type list, select UserFinderDescriptor. In this field, you specify the where clause for a select statement in a finder.
    8. In the Finder statement field, it should be disabled for any entry.
    9. Save your work.

Now that you have create a UserFinderDescriptor finder type FinderHelper method, you will later create a BeanFinderObject and call it XCatentryExtBeanFinderObject.java in order to be picked up by the finder method findByCatentryIdVendorIdStorePathId.


Adding the BeanFinderObject

Now that the Entity Bean, XCatentryExt, has the new UserFinderDescriptor finder type FinderHelper method, the Entity Bean is looking for a class called XCatentryExtBeanFinderObject. Along with this tutorial is some code that you can include that will fulfill the requirements of a XCatentryExtBeanFinderObject class, along with the special logic to incorporate the store path relationship type query.

Link to the Download section of this tutorial to get the zip package corresponding to the code for this tutorial, ensure to install the classes XCatentryExtBeanFinderObject.java and XCatentryExtSqlHelper.java into the WebSphereCommerceServerExtensionsData project under the ejbModule directory, build the project, restart the server.

Open the code for the XCatentryExtBeanFinderObject class. Notice that this class is extending the JDBCFinderObject, which is assumed to extend VapEJSJDBCFinderObject and with that, the WHERE clause requirements for the entity bean are fulfilled. The XCatentryExtBeanFinderObject class will call the VapEJSJDBCFinderObject methods to assist in creating an extended SQL that the entity bean will use to pull data from the XCATENTRY_EXT table. Specifically, the method getMergedPreparedStatement is invoked from the VapEJSJDBCFinderObject class, which includes the full SQL statement to which the entity bean uses to pull data. The XCatentryExtBeanFinderObject class creates the WHERE clause, while the entity bean itself handles the rest of the SQL statement.

As a special addition to this tutorial, the XCatentryExtBeanFinderObject includes some additional logic to support parametric SQL. Since the XCatentryExtBeanFinderObject is appending parameters to the WHERE clause, it might as well be a parametric SQL statement if it is going to include those parameters. If you are going to do it, do it all right. When a new parameter is added to the query, an ArrayList, arList, appends that parameter. All of the parametric parameters are massaged and delivered to the PreparedStatement where the SQL statement belongs.

The SQL Helper class that is associated with XCatentryExtBeanFinderObject has most of the coding. You will look at each of the methods involved.


Table 2. SQL Helper class associated with XCatentryExtBeanFinderObject
MethodInputReturningDescription
getStorePathInteger storeId, String storePathTypeInteger[]The storePathType is the store relationship type, in this case: com.dw.commerce.storepath.affiliate. The utility class and method is called: com.ibm.commerce.common.helpers.StoreUtil.
getStorePath(storeId,storePathType)
, which will return all stores related to the input storeId for that particular store relationship type value.
toInQueryClauseint (number of parameters)Returns a parameterized SQL IN clause (for example, "IN(?,?)")The beautiful method is called from CatalogSqlHelper.
toInQueryClause(nParameters)
. It is quite clean, as it returns the query using ? as markers for the parametric SQL statement.
setParametersInWhereClausePreparedStatement ps, int (1), ArrayListPreparedStatementThe input is a PreparedStatement and returns that same PreparedStatement with the additional parameters set correctly so as to represent a parametric SQL. This ensures the entity bean handles the SQL statement as a parametric SQL statement.

Granular design approach

With the XCatentryExtBeanFinderObject picked up, you can easily invoke the XCatentryExtAccessBean and call the UserFinderDescriptor finder type FinderHelper method, findByCatentryIdVendorIdStorePathId. This is considered a more granular level of sharing data since the CatentryId is already assumed to go through sharing filtering through the store relationship type com.ibm.commerce.catalog. So, the affiliate store relationship type, com.dw.commerce.storepath.affiliate, is called upon to filter shared assets after the store relationship type com.ibm.commerce.catalog has already filtered the catentry object. In some ways, this is beneficial assuming you only want to deal with catalog assets that a particular hosted store is able to share. If you need to filter both catalog assets and affiliate assets simulaneously, you can easily incorporate another sub-query in the where clause within the XCatentryExtBeanFinderObject class, where the findByCatentryIdVendorIdStorePathId method resides.

Invoke the findByCatentryIdVendorIdStorePathId Method from a Test command

If you have not worked with entity beans before, follow the tutorial in WebSphere Commerce Information Center, Creating new business logic, where you learn how to include new entity beans into your WebSphere Commerce environment.

The code segment in Listing 11 is an example of how to instantiate and pull data from the XCatentryExtAccessBean into your controller command.


Listing 11. Invoke the XCatentryExtAccessBean findByCatentryIdVendorIdStorePathId

XCatentryExtAccessBean xcatExt = new XCatentryExtAccessBean();
Long longCatEntryId = new Long(catEntryId);
Long longVendorId = new Long(vendorId);
Long longStoreentId = new Long(storeentId);
try { 
	XCatentryExtAccessBean prodAB = null;
	for(Enumeration productList = 
	  xcatExt.findByCatentryIdVendorIdStorePathId(
	    longCatEntryId,longStoreentId,longVendorId); 
		productList.hasMoreElements(); )
	{
		prodAB = 
		  (XCatentryExtAccessBean)productList.nextElement();
		if (prodAB!=null)
		{
			// trace out prodAB.getXXX();
		}
	}
}
catch (FinderException e) {
	// trace exception and throw
}

Section conclusion

In this section, you have taken additional steps to include the new entity bean into your WebSphere Commerce environment. The intention of affiliate marketing is to provide a commission to a third party as in incentive to drive traffic to your store's products. This table you have created has some extendable fields: FIELD1, FIELD2 and FIELD3. You can use those fields to clarify the commission agreement on a product level that the affiliate uses as motivation to sell the product. For example, for a given product, you can designate that the affiliate gets a 5% commission on the price of the product that they sell for all stores in an extended site environment. But, for a particular hosted store, you can override that commission and set it to an even higher incentive. The store relationship table, STOREREL, has a sequence column to allow you to give precedence over which store relationships have sharing priority over another. You can use this column in different ways for different requirements, still keeping the code common to all stores.

Using the store path relationship queries embedded in the entity bean, those shared and hosted level commissions can easily be realized, keeping one common code to power the engine. You can even go further and find an invasive approach to reusing the Replenishment Advisement tables (RA and RADETAIL) as a way to keep track of an affiliates sales activity selling your products. Thus, the design details require requirement and gap analysis since there are many ways to realize this in a particular business scenario.

This new asset, affiliate networking, has been customized easily into WebSphere Commerce reusing the extended site framework via the store path relationship types. Instead of being so defensive when approaching world class software such as WebSphere Commerce, this tutorial not only illustrates how to reuse the extended site framework, it also finds ways to reuse all components of the software to fit the needs of future business niches. Affiliate networking is the next step in the growth of organization behavior, which may be your next step in evolving your e-commerce strategies. Regardless of what your new assets may be, now you know how to integrate them into the extended site framework.

6 of 11 | Previous | Next

Comments



static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=551401
TutorialTitle=Creating solutions on the extended sites framework in WebSphere Commerce
publish-date=10202010
author1-email=mshields@crossview.com
author1-email-cc=dwu@us.ibm.com
author2-email=qnguyen@crossview.com
author2-email-cc=dwu@us.ibm.com
author3-email=rsanghvi@crossview.com
author3-email-cc=dwu@us.ibm.com
author4-email=amar.desai@atech.com
author4-email-cc=dwu@us.ibm.com