One of the many people I follow on Twitter had this to say about Commerce Server the other day. He’s not alone. I’ve had many customers ask me this type of thing in the past but the truth is, this is the beauty of Commerce Server – its extensibility.
Let’s take a look at the idea of storing non-products in the catalog. There has always been a need to manage static, non-product information on eCommerce websites and before the native integration with SharePoint we’re seeing with Commerce Server 2009, we still needed a way to manage this type of content. Enter the Service Catalog. The Service Catalog was a really good way to manage content without implementing a full-blown CMS, something customers couldn’t/didn’t always want to do. It made sense from a management perspective, but what about the technology? The Catalog System already had an extensive API, caching and a way to persist and maintain the data. Why would I rewrite a complete system from scratch to store this new content, when I have all of the components already in place? Certainly one drawback is that all of the data, product or not, looks the same in the Catalog Manager, which likely adds fuel to the fire that is this question. My suggestion here was always to use the provided Catalog Manager source code to make the necessary changes in order to make a distinction between editing product data or other static content. What about products you provide as downloadable content or warranty products you sell associated to other products? You can create special product definitions that define these types of products, so logically, why not extend that to include other types of associated data.
If you’ve ever heard me give a presentation on Commerce Server, I always make a point to mention that the Profile System isn’t just for storing things like emails, addresses and credit cards. Why not store point balances for a loyalty program, or your store locations for a store locator? I once architected a solution for a customer that needed to use Commerce Server to maintain store credits. The solution involved some clever customizations of the Profile System, using only out-of-the-box components, API calls and some integration using BizTalk. Again, Commerce Server supplies us with tools to completely customize what a Profile looks like, so why not use it to store more than just user data?
There are many more good examples of Commerce Server extensibility, but this gives you an idea of what can be done using only what the platform provides. If the product provides the tools and the capability to customize different entities, then why not take advantage of this.
Note: I haven’t even touched on extensibility using the new Multi-Channel Commerce Foundation. That’s another post altogether.
#1 by Colin Coller - May 21st, 2009 at 11:22
I have numerous objections to the practice, some philosophical, others experiential. :)
1. It puts additional load on something that you want to be really fast.
2. It puts additional load on something that’s relatively expensive to license on a per-processor basis.
3. It makes it more difficult to partition and distribute your data and your processing.
4. It makes it more difficult to size and tune your caches.
5. It causes you to think about data in terms of the catalog API and the catalog structures, which is good for some things and absolutely terrible for many other things.
6. It makes it easier to make bad decisions about how and where you manage your content.
7. It makes it more likely that you’ll have to extend and maintain your own version of the out-of-the-box tools.
If I were architecting a medium or larger e-commerce website on Commerce Server, I’d have serious reservations about storing non-product data in the catalog. I’d head toward other pre-packaged or custom components and stores, and only come back to the catalog if absolutely necessary.
My $0.02,
Colin
#2 by rishi girdhar - September 14th, 2009 at 04:28
Hi Kelly,
I am trying to implement for an insurance firm where we need to store non-product data such as
Proposer Details – User name, address, spouse name, age etc
and Product specific details like incase of travel insurance
Travel dates, source and destination,etc
based on these inputs I need to calculate the premium also.
What do you suggest for it?
#3 by Kelly - September 14th, 2009 at 05:05
This type of data is a little more challenging to store in the catalog as it is always changing with customers. You don’t want to be creating one-off products every time you get a new customer. There are probably a few ways you could do this, but one way would be to create some additional fields at the order level (form and line item) and persist the customer specific data when the item gets added to the basket. This data will then get persisted to your completed Purchase Order. Another way might be, if the customer data you’re capturing is similar enough you could create a profile for the customer and store the data in some custom profile attributes. As for calculating the premiums, this will involve some custom logic regardless of how you do it.
Another way might be to create custom properties on your insurance products in the catalog. These custom properties would only serve as a sort of “list” of the type of details you need to capture. Each new property could also have an associated “cost” as well that could be used to calc the total premium.
Hope this helps a little!
#4 by Stanislava - January 12th, 2010 at 00:59
Hi,
In fact I have such systems with content implemented in Commerce server and such with content in Share Point and CMS. Commerce only systems are faster. Relation between product and content in Commerce only system is easier and faster, and such relation is always required, because the content is about the products. Retrieving of the contend related to product and products related to content is easier and faster and Commerce only systems.
You have objections, but you do not provide alternative? What is you suggestion for Content mamagent system with Commerce server?