A Look at Sitecore Commerce 8.2.1
Sitecore announced the release of their new Commerce offering, Sitecore Commerce 8.2.1 in January of this year. In this article I take a look at what this step means, some of the architectural changes involved, and some of the features of the SDK (Software Development Kit).
Beyond “Powered By”
When Sitecore acquired Commerce Server in 2013, they obtained a commerce product with a considerable pedigree and customer base, and an experienced leadership and engineering team. Indeed, much of the technical personality of the future Sitecore Commerce product can be seen in this 2009 presentation on the “Mojave” release of Commerce Server, especially the emphasis on a unified “CommerceEntity” class and a consistent persistence and API mechanism. In bringing this engine to Sitecore, “Sitecore Commerce powered by Commerce Server” (an unwieldy name, with an unwieldy acronym, “SCpbCS”), and its Microsoft Dynamics sibling (SCpbMD) gained a clean SPEAK interface, and the ability to update product content through the Experience Editor, as well as integrations with the xDB to power engagement plans and personalization. Still, it had some clear signs of age, such as numerous editing components built in pre-.Net COM+ technology.
With this release, the Sitecore commerce team has rebuilt the Orders and Marketing engines, using Microsoft’s new .Net Core technology, itself a leaner, faster rewrite of the .Net framework. This is Sitecore’s second use of .Net Core, also used by the recently released “Publishing Service”, and shows Sitecore’s investment to keep at the leading edge of the .Net platform. Significant parts of the system are still implemented behind the scenes by Commerce Server, such as the catalog and inventory systems, but these will be moved over to the new .Net Core system in future releases.
The redesign draws inspiration from the same spirit of modularization and dependency management that animates the Helix design guidelines, with a tightly-managed set of foundational code supplemented by a large collection of plugins. These plugins manage specific, and tightly-constrained, areas of responsibility, such as inventory or pricing.
"At the recent Sitecore Symposium in New Orleans, Senior Product Architect Kerry Havas explained that isolating modules allowed you to limit the dependencies you took on. For example, if you are building a site that sells digital entitlements for online content, you don’t need inventory functionality, so you don’t need to import that module."
This significantly simplifies the system you are building on top of, since there is a large amount of Sitecore code that simply does not enter into your solution. Additionally, this opens the door to releasing upgrades at a module level, allowing for shorter release cycles, with the underlying foundation remaining stable. Small chunks promote agility.
The User Guide is a good overview of the capabilities of Sitecore Commerce, but I will call out a few noteworthy highlights:
- Support for physical and virtual products (entitlements), including in the same shopping cart. So, for example, one could order a physical book and get access to an online version of it.
- List and dynamic pricing, including pricing based on date, quantity, or currency, and the ability to run and manage promotions.
- Ability to organize products in base and custom catalogs, allowing control over how products are organized for different audiences.
- Order capture and order management through SPEAK applications and an OData API.
- Support for rich B2B user to account relationships, as authentication is managed through Sitecore Membership Provider, and order accounts are managed through the Commerce back end.
- BizTalk support for integration with back-office ERP systems.
- OData RESTful APIs for managing customers, orders, products, catalogs, and promotions.
The feature set is rich, but the real power comes from the fact that any of these behaviors is extensible and customizable through plugins and custom policies. Although the extensibility model is somewhat different from the pipelines and events that Sitecore developers are used to extending, the emphasis on the ability to extend any piece of functionality, to take apart the Lego set and swap in a different brick, should be very familiar to Sitecore developers.
Plugins and Policies
The extensibility mechanism centers around Policy objects, which I admit, took me a little bit to wrap my head around. Policies are kind of like tags, and kind of like services. Like tags, they can be attached to commerce entities (such as carts, customers, products), but they can contain data. For example, the EntityStoreSqlPolicy can hold a user name, password, and connection string. They are like services in the Dependency Injection sense of the term in that a class can request a Policy of a certain type, but you have the ability, through plugins, to change the type of object returned to a custom subclass, thereby extending system behavior. This approach nicely follows the open/closed principle, as policies can be modified without the underlying code being changed. For example, you could create a plugin that registers a subtype of the EntityStoreSqlPolicy that queries an enterprise Password Manager for the SQL credentials; this extension of functionality will be invisible to the rest of the system. In other words, the object design is architected for seamless extensibility.
Policies also make business logic code very expressive and readable, as this snippet from the sample Plugins included with the SDK illustrates:
We see the dependency injection-like behavior with the GetPolicy statement, which could return the default “KnownEntitlementTags” or an extended one we’ve registered in a plugin. We also see how policies can store data, as for example, this policy stores a collection of tags. And we see how a policy can be used as a simple flag to define behavior, as the AvailabilityAlwaysPolicy does here.
Finally, shopping behavior, such as adding products to carts, completing or abandoning an order, or indicating an interest in a sold-out product, can all trigger goals and launch engagement plans in the xDB. The wiring together of shopping activities to the xDB is done through a standard series of pipelines packaged as “Commerce Connect”, which means that this functionality is available to other commerce providers, such as uComerce and InsiteCommerce (in fact, I worked on the Insite implementation, and gave a talk on it last year). By building the xDB integration on a common module, Sitecore has made the xDB commerce building blocks available to all commerce systems, including custom built ones.
Commerce Connect has two major features, a Product Sync mechanism for importing products into Sitecore, and a series of pipelines for all commerce actions, with dummy processors for commerce system actions such as adding a product to a cart or completing an order. Sitecore Commerce does not make use of the Product Sync mechanism, implementing instead a customer data provider for reasons of scale, speed, and flexibility, but Sitecore Commerce does implement the pipeline processors to capture shopping activity in the xDB. And now Commerce Connect provides this information in a new “Commerce” tab in the Experience Profile, allowing shopping activity to be viewed alongside other xDB information.
Missed sales opportunities: You’ve got my email, and you know I didn’t buy those boots I was thinking about. Engagement plans are awaiting!
Unboxing the SDK
There’s clearly a lot for developers to wrap their heads around with this release, but the process is greatly assisted by a well fleshed-out Software Development Kit (SDK) and a reference storefront implementation. In addition to containing a sample solution with two sample custom plugins, the SDK contains Postman samples for all OData API calls, and a wizard for creating plugin projects, built with the Yeoman scaffolding tool.
Yeoman Sitecore Commerce Plugin generator
Postman API sample
There was a little bit of discovery effort for me to get Yeoman working and to build the solution with .Net Core, but having actual detailed samples was very helpful. Finally, there is a console app that runs a long series of automated tests, which serve as additional API documentation. As a proponent of Test Driven Development, I appreciate being able to “go to the tests” to figure out how functionality works.
To Learn More
The best resources for getting an understanding of Sitecore Commerce is the Technical Overview talk by Mark Demeny on the predecessor Sitecore Commerce product SCpbCS; fortunately the catalog integration and some of the SPEAK interfaces have not changed. He has also given a series of talks on Commerce Connect, and is hopefully planning to do one on the new release of Sitecore Commerce.