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!