With a solid understanding of exactly what Commerce Server is – and more importantly is not – one can then come up with a somewhat logical methodology to build production grade application architectures based upon the product. This section will attempt to outline the most expeditious thought process possible to get from here to there.

The most important consideration, however, comes before the technology – and that is business requirements. No two businesses run alike. In most cases, businesses will not adapt their business processes to work the way the product most naturally does. To get around this, one should generally not view Commerce Server as an out-of-box solution, but rather a toolset that can be utilized to build a solution around business requirements.

Hence, having an exceptionally solid understanding of the business requirements is the most important first step. As this book is about Commerce Server and not requirements analysis, that will not be discussed here.

The principal considerations that need thinking – beyond intrinsic idiosyncracies within Commerce Server (which will be covered in a separate post) – include:

• Tenancy
• Single versus Multi-Environment
• Interactions by Business Users
• Interactions with Back-End Systems

 

Tenancy
The first consideration in a Commerce Server deployment is the expected business deployment topology – specifically how many sites and how should data be shared amongst them. In the simplest scenario, one will have a single site (e.g. – http://www.companyx.com) and a single set of Catalog, Inventory, Orders, Profiles, Marketing, and optionally Analytics.

Rarely is life that simple. Let’s consider a few common situations:
•    Multiple Brand Subsidiaries (e.g. – http://www.companyx-1.com, http://www.companyx-.com and so forth – all belonging to the same parent)
•    International Sites (e.g. – http://www.companyx.ca, http://www.companx.com, http://www.companyx.co.uk and so forth – all providing the same site for different locales)
•    Mix of both!

The business requirements around this have significant impact on how Commerce Server 2007 is deployed – and which edition of the product can be utilized. The principal deciding factor is whether Catalog, Inventory, Orders, and Marketing data should be shared between end-sites – or not.

If Catalog, Orders, and Marketing data can or must be shared amongst end-site instances, an application architecture of the following must be implemented as follows… A single Commerce Server Site must be provisioned, with single instances of Site Resources such as Catalog, etc. Each end-site (e.g. – http://www.companyx-1.com, http://www.companyx-1.ca, http://www.companyx-2.com, http://www.companyx-2.ca, and so forth) must be configured as a Commerce Server Application within the site. This configuration requires Commerce Server 2007 Enterprise Edition, as the limit of one Application per Site in Standard Edition has been exceeded.

In another scenario, Catalog, Inventory, Orders, and Marketing data should not be shared between sites. But perhaps it is still desirable to leverage the same physical infrastructure. In this case, an application architecture must be implemented as follows… Each end-site must be configured as a separate instance of a Commerce Serve Site, with one set of Site Resources and Application per Site. In this scenario, up to 10 instances like what is described here can be implemented on a single physical server running Commerce Server 2007 Standard Edition; if more than 10 is required – Enterprise Edition must be utilized.

Although other permutations exist, these represent the two principal Commerce Server 2007 tenancy scenarios that can be accommodated by the product. Commerce Server itself is not truly multi-tenant (at least in this release) – so it cannot differentiate between tenants within a single Site or Application instance.

In EITHER scenario, the Profiles and Analytics resources can either be shared amongst everything or affinity established with one of the deployments – as they are global resources. Likewise, in either scenario – single or multiple physical deployments can be utilized – but databases will be shared as noted based on the chosen application deployment scenario. Besides the obvious sharing (or not) of customer data, this has impact on which business users can change and access what data as well.

 

Single versus Multi-Environment
The next consideration is how many environments are needed. If a single physical Web farm can be utilized, then Commerce Server 2007 Standard Edition can be utilized. However, this means that all business data changes for pricing and such will be made LIVE to the production environment. This has several potentially negative ramifications, specifically:

•    Data Inconsistency – Any data entry mistake or flakiness caused by changes as data is being updated will be immediately represented to the customer – and potentially reflect negatively.
•    Performance – Making changes to the live site will indeed negatively impact runtime performance. It’s as simple as that.
•    Security – This will require that the Web Services are exposed to the Internet on the production Web farm – which could potentially represent a point of vulnerability for a hacker.

If any of these factors are deal breakers, then Enterprise Edition must be utilized and business data changes made in a physical environment separate to production.

 

Interactions by Business Users
Commerce Server 2007 was designed for all business user maintenance to go through the Windows-based business user tools, specifically Catalog Manager, Marketing Manager, and Customer and Order Manager. (Or at least like approximation of those tools making similar calls to the Commerce Server Web services.)

From an architecture perspective, the first consideration is whether or not these tools should be customized. If yes, one must consider ongoing maintenance – as these tools are being revised at least as often as every Service Pack of Commerce Server. Microsoft will release DIFFs of source code between versions with Service Packs to facilitate making changes, but this must be planned and accounted for in the event that customizations are indeed made.

From a utilization perspective, these tools can tend to be somewhat processor intensive and/or destructive (given that they are modifying the underlying data upon which Commerce Server operates). They are not ever meant to be utilized on a live site. If they are to be utilized on a live site, the following considerations must be adhered to:

•    Perform maintenance in off-peak hours only – as some degree of performance degradation can generally not be avoided
•    Utilize caching as such that the site changes will not be noticed – and then refresh the cache utilizing some other means after changes have been made
The best practice, of course, is to perform changes in a separate environment and then stage them to production utilizing Commerce Server Staging, the BizTalk Adapters, or some other convenient means.

 

Interactions with Back-End Systems

When running an operational e-commerce system, there will generally be two streams of data inbound and outbound from the system. On the inbound side will be business user changes – with updates to Catalog, Inventory, Marketing, and Orders (for order status). On the outbound side will be Profiles (for customer data), Inventory (to reflect quantities purchased on the site), and Orders (to send off for fulfillment).

Commerce Server 2007 provides the BizTalk Adapters, which leverage the data management Web services, as its out-of-box mechanism for affecting line of business data updates of this nature. The data interchanges will generally have a BizTalk hub attached to Commerce Server, with at least one (if not more) Send and Receive Adapters flowing in and out of the Order, Profile, Catalog, and Inventory systems of Commerce Server.

BizTalk in general represents a good integration strategy, as data interchange can be configured within the BizTalk toolset with minimal coding to any system that can already interface with BizTalk. At the time of writing, support for BizTalk connectivity (and ergo Commerce Server connectivity via BizTalk) from Microsoft can be obtained from http://www.microsoft.com/biztalk/en/us/adapters.aspx.

Alternatively, any other SOA-broker can connect to the Commerce Server Web Services to perform the same functions as the BizTalk adapters – there are no special hidden capabilities.

Some of the best practices to consider when utilizing the BizTalk adapters (or any other integration broker) are:
•    Operate on a reasonable polling schedule for pulling data – this is generally business requirement driven but there is an artistic balance to be achieved between not enough and too much. Once per hour typically meets the needs of most customers and is generally unobtrusive. During extreme peak times, it may be best avoided and handled during off-peak times. Business rules typically need to be adjusted in this case, such as additional inventory stock-out thresholds on hot items, etc.
•    For areas where SQL indexes can be customized, tweak the SQL indexes to optimize for the queries generated by the polling operations. If one is unsure what the polling operations are doing, this can be easily discovered by utilizing SQL Profiler and indexes then adjusted accordingly. (Be careful though – especially with clustered indexes – to not inversely create a bottleneck for updating data or the runtime site.)
•    For updating data, try to keep the operations as infrequent as possible. Additionally, one must be respectful of indexes that already exist – and the impact that updating can have (especially with clustered indexes). Separately, there may be additional operations required – such as refreshing site cache – these may need to be triggered also at the time of updating.