I am pleased to announce that we now have available a Hyper-V VHD release of the SharePoint 2010 Template Pack for Commerce Server 2009. This is a 64-bit Hyper-V image – as SharePoint 2010 requires a 64-bit operating system. Hence, Windows Server 2008 with Hyper-V is required to run the VM along with at least 4 GB of RAM for the virtual machine.

To obtain this, please:

• Navigate to http://connect.microsoft.com/
• Sign in or create a profile using your Windows LiveID
• Join the Commerce Server Feedback program (if you are not already a member)
• Fill out the survey to request the VHD – and you will be granted access once your request has been submitted and approved (generally takes 1 business day)

Hope this helps – and enjoy!

Today is the next step in evolving Commerce Server. As of this morning, the Commerce Server 2009 Template Pack for SharePoint 2010 has released and can be downloaded at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cfd0c459-5a11-4de6-9085-52d59e8d38e6.

What this release provides is an updated version of the existing Contemporary Site for both Web and Mobile devices that runs on SharePoint 2010, along with the requisite source code for customization. It also updates the Profile system to support the new claims-based authentication mechanism in SharePoint 2010.

I would highly encourage anyone starting a new deployment to start here. For those with existing sites, the Profile update (and associated site code, to be used as a reference) are absolute must-haves to get an existing Commerce Server 2009/SharePoint 2007 site to run on SharePoint 2010 (there is no way to actually get it to work without these fixes).

Hope this helps!

Now that I’m done, I just wanted to quickly summarize the mini-series I just finished looking back at CS2009:

• CS2009 Overview: http://blogs.msdn.com/rdonovan/archive/2010/04/07/commerce-server-2009-a-look-back-at-the-one-year-anniversary.aspx
  
• A Deeper Look @ SharePoint Commerce Services: http://blogs.msdn.com/rdonovan/archive/2010/04/12/commerce-server-2009-a-look-at-sharepoint-commerce-services.aspx
  
• A Deeper Look @ Multi-Channel Commerce Foundation: http://blogs.msdn.com/rdonovan/archive/2010/04/14/commerce-server-2009-a-look-at-the-multi-channel-commerce-foundation.aspx

I hope this helps with your journeys with CS2009; time does indeed fly when you’re having fun!  

The biggest job in modernizing Commerce Server is most definitely that of replacing its programming surface. Achieving API consistency – and removing legacy components – has been one of the most oft-requested features in Commerce Server from a developer audience. However, the trick is achieving this – without causing egregious customer pain.

So, this journey started out by establishing a few hardcore tenets, including:

· Creating a consistent pattern – for both runtime and data management operations

· Creating a flexible pattern – that can accommodate any entity today, any future needs, or any custom needs as part of a complex deployment

· Establishing a forward-migration story for versions beyond CS2009

· Establishing an a la carte migration story from CS2007 so that no big-bang re-platforms are needed

· Playing well in a message-based world – such that request batching can be used for performance reasons and the new API can be easily integrated into any SOA environment

· Having an API that will work outside of a Web server, in any environment

The journey began by creating a simple, message-based pattern that works by:

1. Creating a request comprising one or more operations on a specified item.

2. Submitting the request to a broker.

3. Parsing the result returned by the broker.

Oh, and the specified items have to be able to have relationships with each other – even if they are totally disparate.

Under the hood, pluggable providers and operation sequences do the real work. In the case of CS2009, this pattern has, out-of-the-box, been wired up to talk to the existing Core Systems of Commerce Server 2007 lineage and SharePoint Lists. In CS2009, it limited to working within a Web server process and covers site runtime scenarios only, but that will be expanded in due course in subsequent versions.

It can just as easily talk to any 3^rd party system as well. And it lays a foundation for being able to add new systems or replace existing ones in the future – all while not breaking the actual application(s) written on the API itself. Imagine a world where one can interface directly to an ERP programmatically – or swap systems in and out at will (e.g. – Dynamics AX in one country, Dynamics GP in another).

Conceptually, it looks like this:

The CS2009 implementation lays the foundation of the tenets set forth at the beginning of the post – and shall continue to be expanded upon in subsequent releases up to the point that the underlying core systems in Commerce Server are re-written and replaced – under-the-hood without impacting applications on top.

All of this flexibility probably seems great at this point – but what’s the catch? There is a tad more coding involved in doing this – versus using an in-process, purpose-built, strongly typed API that only does one thing. This is the small price of consistency, simplicity, and flexibility. So – what does it look like?

One starts with a CommerceEntity – which is a single generic class that is the gateway to the API. Different entities (of those offered) are distinguished by the “ModelName” property on the class. Hence, an example query looks like:

What is shown here is the extent of what it takes to use the new API – versus just say – calling the Catalog. A tad more code, but one is no longer tied to a fixed implementation (and tomorrow the ties to a Web server will be cut as well).

Each CommerceEntity has its PropertyCollection, which allows individual properties to be managed. Properties are retrieved and set with the GetPropertyValue() and SetPropertyValue() methods – continuing the example above it looks like this:

Relationships are also returned in the Properties collection, and manipulated simply by setting properties. For example, relating Product and Variant queries is as simple as:

To wrap up, we can put it into context by looking at the CommerceEntity’s shipped with Commerce Server 2009:

· Foundational Entities – used internally in constructing other entities, but fully customizable.

o CommerceEntityDefinition

o AuthorizationDefinition

o RelationshipDefinition

o RelationshipTypeDefinition

o PropertyDefinition

o EntityMapping

o DefinitionMapping

o ConstraintBase

o EnumerationEntry

o EntityMetadata

o CommerceCache

· Commerce Entities – where the actual interaction typically occurs.

o Site

o Solution

o Channel

o CommerceLogEntry

o Catalog

o Product

o Variant

o Image

o InventoryItem

o Category

o UserProfile

o StoreProfile

o Address

o CreditCard

o TargetingContext

o SiteTerm

o SiteTermElement

o Basket

o ShopperList

o Discount

o LineItem

o PurchaseOrder

o CashCard

o GiftCertificate

o RequestedPromoCode

o Shipment

o Payment

o PaymentAccount

o PaymentMethod

o ShippingMethod

o HierarchicalCatalogEntry

o Advertisement

o ContentSelector

o ContentSelectorCollection

o EventRecord

o DiscountDefinition

o DiscountFilter

o Region

o StateProvince

o BasketOrderSearch

o ImageGalleryFile

o ImageGallery

And all of these are easily customizable – both in their definitions and in what happens under the hood. And they are easily callable from either ASP.NET or non-Web page scenarios, such as using a PowerShell script – too!

And that – really is it – unless one needs to dive deep into the annals of request batching or extending the underlying operations to make the API talk to something else beyond Commerce Server or SharePoint.

Hope this helps!