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.