Secret Agent Man

For most of 2010 – and so far all of 2011 – I have been working on special projects as my primary focus day-to-day. A lot of the details of which will never be known – except to a select few involved. It has provided for a vexing and at times lonely corporate existence. And not a lot of interesting things to blog or tweet about.

Hence, my focus on photography and travel – and a break from technology. This in and of itself has proven to be a fun interlude. As I have accomplished a lot of my personal goals with respect to improving my photography from the last five years. Low-light and well-composed landscapes no longer represent the challenge that they once did. Hopefully you agree! 🙂

Now, I have to set even higher bar for my photography. And in a few months hopefully I will be out of special project mode and back into the kind of customer or engineering focused action that I truly enjoy. Be seeing you.

Demo Hell – thank you SharePoint 2010

I just built a demo system for presenting Commerce Server 2009 R2 CTP on top of SharePoint 2010 at the Microsoft MVP Summit. The experience was NOT fun, hampered by two major gotchas:

  • SP2010 will not configure unless you are connected to the network. And the domain controller of the domain to which the machine belongs is accessible. The error will complain about configuring the database, but this is the real root cause.
  • CS2009 R2 CTP – leaving authorization disabled caused – of all things – an authorization error. Configuring the XML files for Authorization Manager rectified the problem.

Many, many hours killed – if you run into these – hopefully they help!

Commerce Server 2009 w/ SharePoint 2010 Template Pack Hyper-V VHD Now Available

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
  • 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!

Commerce Server on SharePoint 2010

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

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!

Summary: Looking back at CS2009

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

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

Commerce Server 2009: A Look at the Multi-Channel Commerce Foundation

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 3rd 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!