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!  

Advertisements

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:

clip_image002

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:

clip_image004

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:

clip_image006

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:

clip_image008

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!

Commerce Server 2009: A Look Back at the One Year Anniversary

Time flies when you are having fun. It is hard to believe, but this month marks exactly one year since Commerce Server 2009 became commercially available.

One of the things been long overdue is an in-depth, guided tour of Commerce Server 2009. Especially one that provides some behind-the-scenes insight into the functionality provided – and “why” things were implemented in the way that they are. So, without further adieu – here it is…

As a software product release, Commerce Server 2009 was approached with three principles in mind:

·     Deliver more capabilities to end-users

·   Modernize the technology within Commerce Server

·  Minimize migration pain from Commerce Server 2007

The challenge in that is that these principles – especially the latter two – are somewhat diametrically opposed to one another. Each of these points shall be spoken to over this and the subsequent two postings in this series, the second and third of which shall provide more specific in-depth looks at:

·         SharePoint Commerce Services

·         Multi-Channel Commerce Foundation

For the balance of this post, a quick look at the usually boring component of Setup and Configuration is warranted. Commerce Server upgrades have traditionally been a painful and destructive process. You could never just install it and have things work. With CS2009, we elected to change that – as part of delivering upon the tenet of minimizing migration pain.

Functionality delivered in Commerce Server 2009 is a super-set of Commerce Server 2007. The release was exhaustively backward compatibility tested to ensure that Commerce Server 2007 applications would run without any tweaking or modification – by purpose of very strict design. Hence, CS2007 customers can be assured that their stuff “will just work” without modification. All new capabilities can be leveraged a la carte on top of an existing installation.

A la carte deployments are probably one of the most overlooked virtues of Commerce Server 2009. Imagine having a large investment in CS2007 that is not in a place to be changed – and then leveraging CS2009’s new capabilities to add, say, Mobility or a promotion/event-specific site – all without touching the original site. Imagine the possibilities…

Hence, to deliver as friction-free a setup experience as possible, CS2009 is easily installable over an existing Commerce Server 2007 installation. It can simply configure the latest and greatest bug fixes (including those post-Commerce Server 2007 Service Pack 2) and the new functionality – all without breaking anything in CS2007.

Hopefully this helps provide some context. Next up – a look at SharePoint Commerce Services.

Commerce Server Deployment Series – Wrap-Up

I have now concluded the series of material constituting the Deployment Series of blog posts – and thus my brain-dump of the answers to all of the questions I find myself repeatedly answering. For quick access, please refer to:

Hope this helps!