Developing with Commerce Server 2009 – Learn Multi-Channel Commerce Foundation – Part I

Introduction

Whether you’re currently running a Commerce Server 2007 or previous installation, and looking to upgrade to Commerce Server 2009, or you’re considering investing into Microsoft’s e-Commerce solution by going straight to Commerce Server 2009, one of the things that you should familiarize yourself with is the Multi-Channel Commerce Foundation. On MSDN, MCCF is defined as a unified operator-commerce entity calling model for the run-time and an entirely new programming framework.

If you want to read up some good old MSDN documentation on MCCF (which is what I’ll call Multi-Channel Commerce Foundation for the remainder of this article), you can find it here and here.

However, it’s easy to quickly get lost in the information and still not come out with a clear idea of how things works together allowing you to become a productive developer faster. Ironically, one of the things, MCCF is supposed to help you with.

So the remainder of this document will describe the different components of the MCCF and how they all work together in Commerce Server 2009.

Commerce Server 2009 Overlies Commerce Server 2007

One last thing to point out before we venture into the details of MCCF is that Commerce Server 2009 is, at its simplest, just a layer that lies on top of the existing Commerce Server 2007. What this means is that behind the scenes, Commerce Server 2007 is still doing whatever it was doing previously. So the orders and marketing pipelines are still doing their magic as is the rest of the Commerce Server 2007 system. This notion is important to understand in working with Commerce Server 2009.

Commerce Entities

In previous versions of Commerce Server, you needed to have intimate knowledge of the respective API for each of the areas. So the way you worked with the Orders system was substantially different than the way things worked in say Profiles, or Catalog or Marketing. Each of these systems is still meant to perform the tasks that are specific to that area e.g. Checkout in Orders, or User Profile management in Profiles, etc.

However, from a MCCF perspective, now everything is a Commerce Entity. What that means is that conceptually, and even physically, a Basket or a LineItem (Orders system) Commerce Entity looks exactly like a User Profile or an Address (Profiles system) Commerce Entity.

Any Commerce Entity is defined by three things.

• Model Name
• Property Bag
• Relationship to other Commerce Entities

A Model Name is what identifies a Commerce Entity from other entities. For instance, the commerce entity that holds user information has a model name of “UserProfile”. The entity that holds credit card information has a model name of “CreditCard”. Same for “LineItem”, “Basket”, “Advertisement”, and so on.

In addition to this, each Commerce Entity has a property bag, which contains a list of weakly typed properties that belong to that Commerce Entity. As an example, a CreditCard commerce entity will have in its property bag things like Account Number, Expiry Month, Expiry Year, etc. All these properties can be accessed using the Commerce Entity’s Property collection object.

Lastly, a Commerce Entity may have relationships to other entities. For example, a UserProfile commerce entity has two relationships; one to an Address commerce entity, and the other to a CreditCard commerce entity. This way, if you retrieved a User Profile entity, you would have the opportunity to also retrieve any associated addresses and credit cards that are stored as part of that user’s profile information. Another example of this could be a Product commerce entity having a relationship to a Variant commerce entity.

As an aside, it should be noted that some Commerce Entities cannot exist by themselves. They only make sense in the context of other Commerce Entities. For instance, a LineItem only makes sense in the context of a Basket. A Variant only makes sense in the context of a Product. An Address only makes sense in the context of either a UserProfile or an Order. In this last example, you would notice that Commerce Entities can also be shared amongst different Commerce Entities. More on this later.

At this point, it should be mentioned that it is possible to create your own Commerce Entities. This is out of the scope of this article, but it’s one of the possible extension points in Commerce Server 2009.

Commerce Server 2009 provides an interface called ICommerceEntity that you can implement to create your own entities. A base class called CommerceEntity that implements this interface is also provided. You can read more about it here.

And that’s basically all there is to Commerce Entities. So to recap, in Commerce Server 2009:

• Entities across different Commerce Server areas all share the same physical object appearance
• Entities are identified by a unique Model Name
• Entities have a property bag for accessing properties that define instances of the entity
• Entities can possibly have relationships to other Commerce Entities
• You can define and create your own Commerce Entities

Commerce Server Operations

Next we are going to look at Commerce Server Operations. There are four top level operations that are available in Commerce Server 2009, one for performing each of the CRUD operations against Commerce Entities. These are

• CommerceQuery
• CommerceCreate
• CommerceUpdate
• CommerceDelete

Any time you wish to do something with the underlying Commerce Server system, you use one of these operations against one of the available Commerce Entities.

Each one of these operations comprises of four main parts:

• Model
• Search Criteria
• Related Operations (Optional)
• Operation Specific Options (Optional)

First thing you need to specify when you wish to execute an operation against a Commerce Entity is a Model name. This is where you specify which Commerce Entity you are targeting. For instance, you will specify UserProfile as the model if you were querying for an existing user.

Secondly, you need to specify the search criteria for finding the correct instance of the Commerce Entity you are targeting. For example, you will likely pass in a GUID or an email address that uniquely identifies the specific user you wish to query for.

Thirdly, you may optional wish to retrieve the user’s addresses. So you will need to specify a related operation. Remember how we mentioned that some Commerce Entities only make sense in the context of other Commerce Entities. This is where that relationship comes into play. For instance, if you wanted to retrieve a user, and also query for any addresses that might be associated with his user profile, you will need to specify a related operation to do so.

Let’s elaborate that third step a bit more here. For these commerce entities that exist in the context of other commerce entities, you use CommerceRelatedOperations which can be thought of as sub-level or second-degree operations. These are operations like CommerceQueryRelatedItem, CommerceCreateRelatedItem, CommerceUpdateRelatedItem, etc. You can read up more on this here. Also, there are some rules around the kinds of things you can and can’t do with related items. As an example, if you wanted to delete an address of a user, you would execute a CommerceUpdate operation against the UserProfile, and a CommerceDeleteRelatedItem against the associated Address entity. More on this in a following article.

Lastly, you may want to specify operation specific options. These would include things like sorting order, whether you want to return the delete count in a delete operation, and things of that nature.

To Follow

In the next part of this article we’ll look at Operation Sequences and Translators. Stay tuned …