With respect to delivering more capabilities to end-users, the decision was simple: integration SharePoint. With the 2007 generation of releases, using SharePoint technologies on the Internet is very real. This will only be furthered by significant, deeper investments forthcoming in the 2010-generation of SharePoint products – which Commerce Server 2009 shall support this summer.
SharePoint delivers an extremely robust framework for exposing end-user Web application functionality – with Web Parts, security, and so forth. As new technologies come online, this is where they are being surfaced on the Web within Microsoft – such as PerformancePoint, etc. SharePoint also delivers a number of capabilities Commerce Server customers have been seeking for some time – such as Web Content Management, site design experience (using SharePoint Designer), Search, community capabilities, etc. And there is a huge ecosystem of skilled talent and add-ons for SharePoint.
At the end of the day, it makes much more sense to leverage what is available than to invent comparable and competing functionality – especially at the expense of adding more e-commerce capabilities. Going forward, ASP.NET will continue to be supported and a huge priority from a developer perspective. But in terms of surfacing end-user-facing application capabilities, SharePoint will be center of action given all of the benefits derived.
With Commerce Server 2009 to integrate with SharePoint, we took an architecture approach based upon creating ASP.NET 3.5 Web Parts that work in both Windows SharePoint Services and Office SharePoint Server. The anchor point is the Product Provider Web Part, which is similar to the SharePoint Content Query Web Part. It queries the catalog, marshaling requests to conserve back-end calls. Conceptually, it looks like:
From a look-and-feel perspective, Commerce Server 2009 Web Parts are styled utilizing XSL Transforms. These are (where SharePoint inherent limitations are not present due to use of existing, external Web parts) stored in document libraries, to allow for easy versioning, workflow, and editing by business users. XSL was chosen simply because it is standards based and well-documented – and many other SharePoint Web Parts are also heading in this direction.
The actual end-user functionality is provided through a series of approximately 30 Web parts comprising industry standard B2C and site management capabilities. The list includes:
• Advertisements and Discounts
• Virtual Earth Store Locator
• Reviews and Ratings (2 web parts)
• Search Box
• Search Results and Paging (2 web parts)
• Address List
• Address Detail
• Credit Card List
• Credit Card Detail
• My Profile
• Registration Wizard
• Change, Forgot Password (2 web parts)
• Live ID
• Product Query
• Product Detail Display
• Images Viewer
• Site Map
• Add to Cart
• Shopping Cart
• Order Details
• Order History
• My Lists
• My List Details
• Channel Configuration
• Property List Selection
• Product Provider
• Inline Product Editing
Navigation is handled through a new Site Map Provider, which derives from SharePoint’s but adds additional capabilities for Commerce Server. Its most unique facet is the ability to merge Commerce Server and SharePoint data, caching, and Commerce Server authentication support.
And – speaking of authentication – the Commerce Server User Profile Management (UPM) membership provider has been made to work with SharePoint – such that Forms-based authentication can work against any UPM-profile/underlying data store – be it SQL, Active Directory, LDAP, or some combination thereof.
Hopefully this helps – and I’ll be back with a third/final installment next week, digging into the Multi-Channel Commerce Foundation.