CS2007 Software Architecture Series Part 5: IT Professional & Business User Component Overview

Commerce Server provides a number of application tools on top of the Development Platform to aid in the deployment. These tools can be principally broken into two categories:

•    IT Professional Tools – aimed at allowing technical users to manage the operational aspects of the Commerce Server deployment.
•    Business User Tools – aimed at allowing non-technical business users to manage aspects of the Commerce Server deployment on a day-to-day basis without IT professional involvement.

These are all described in detail in the remainder of this post, and comprise the remainder of the components included with Commerce Server 2007. 

 

Business User Tools

Commerce Server provides four business user applications. They are all implemented as Windows Forms applications utilizing the product’s Agent API and calling the Web Services. A question often comes up as to why Windows Forms applications were utilized in lieu of a Web-based application. The answer is that given the technology available at the time Commerce Server 2007 shipped (mid-2006 calendar-year) – it was the only means of providing completely acceptable usability and performance for the most demanding customer scenarios.

Previous versions of Commerce Server utilized the Business Desk, which was in effect an early AJAX-style application. It was one of the most panned aspects of Commerce Server 2000 and 2002; the performance and usability when managing large amounts of data were atrocious. Web pages are simply not suited to streaming and managing multi-million item catalogs or accommodating other such challenging scenarios.

Silverlight represents a long-term answer and future direction, but that is a discussion for another day…

Source code is provided for the business user application s to facilitate customization. However, in the event that changes are made – it then becomes the developer’s responsibility to download and merge in fixes to the code-base as the Commerce Server product itself is revised (if the Microsoft out-of-box binaries and resultant user experience are not utilized).

Given that the applications are written in .NET, they will run natively on either x86 or x64 processor architectures without issue. Because they consume the Web Services, they can be utilized either over the Internet or in an Intranet scenario. They can utilize either NTLM or Basic+SSL for authentication. Microsoft Authorization Manager (AzMan) technology is utilized to provide customizable role-based security.

The tools themselves that are provided include:
•    Catalog Manager – Utilized for managing all data entities stored in the Catalog and Inventory systems.
•    Catalog Schema Editor – Utilized for defining and managing the property and entity definitions in a configured instance of the Catalog system.
•    Marketing Manager – Utilized for managing all data entities represented by the Marketing system.
•    Customer and Order Manager – Utilized for querying and – in some cases – managing the data entities stored in the Profiles and Order systems.

Separately, a Profile Schema Manager is provided – but this is as a Web application that is based on a subset of the old Business Desk technology. Why? Because this component is shared with BizTalk Server 2006 and is embedded within it for the trading partner management feature-set and compatibility would be broken if it were updated to Windows Forms.

 

IT Professional Tools Overview

Commerce Server 2007 provides a number of components to facilitate physical deployment. These all work separately but somewhat depend upon one another, and include:
•    Admin APIs and PuP
•    Management Console
•    Operations Manager 2005 Management Pack
•    Staging

 

Admin APIs, PuP, and Management Console

All of Commerce Server’s physical deployment configuration is stored in a SQL Server database called MSCS_Admin. Living on top of this data store is the Admin API, which is effectively a set of APIs that are used internally by Commerce Server (as well as callable by end developers) to configure itself at runtime as well as provision instances of the product.

Several distinct entities are managed by the Admin API, including:
•    Global Resources – A global resource is an instance of a Commerce Server system entities that can be shared amongst multiple configured instances of the product. There are only two systems in Commerce Server that can be configured in such a manner: Profiles and Analytics. What does this mean in English? One can have multiple, separately configured instances of Commerce Server (e.g. – for completely different sites for CompanyX.com and CompanyY.com) that share Profile and Analytics data.
•    Sites – A site is a single configured instance of Commerce Server. It is a collection of the Catalog, Inventory, Orders (split as Transactions and TransactionConfig to be precise), and Marketing systems that are all interrelated together. Each instance of these entities is called a Site Resource. Typically a Site has affinity with a single organization, such as CompanyX.com. Catalog, Inventory, Orders, and Marketing data cannot be shared across sites. Commerce Server 2007 Standard Edition supports up to 10 sites on a particular physical server. Commerce Server 2007 Enterprise Edition supports an unlimited number of sites – and is bounded only by physical hardware limitations.
•    Applications – A subset of a Site. It represents an ASP.NET application in IIS that has affinity with a site in Commerce Server. Each Web Service instance (Catalog, Marketing, Orders, and Profile) + each ASP.NET site built on top of a configured Commerce Server 2007 Site counts as an application. By default, there will be one instance of each Web Service + one single ASP.NET application per site (for the end Web site). Commerce Server 2007 Standard Edition supports only one application beyond the Web Services per Site. Commerce Server 2007 Enterprise Edition supports an unlimited number of Applications per Site.

The Admin API allows the provisioning and reading of configuration at runtime for all of the aforementioned entities. It also enforces the limits imposed by Commerce Server 2007 Standard Edition. In addition, it can be utilized to create custom Site Resources to allow ISVs or site developers to create new entities that can be managed as part of the Commerce Server management tools.

The PuP utility leverages the Admin API to create a single binary package of Global Resources, Sites, Site Resources, and Applications for easy deployment to a system (or a subset thereof). It can create a new binary package based on a configured deployment – or deploy an existing binary to provision a new deployment. Like the Admin API, it is extensible to handle any custom actions required needed to facilitate changes/extensions made by site developers or ISVs.

The Commerce Server Management Console is simply a Microsoft Management Console (MMC) snap-in that allows configuration of the runtime properties of all of Commerce Server’s global resources, Sites, Site Resources, and Applications.

 

Operations Manager 2005 Management Pack
The name of this feature could not possibly be more self-descriptive. It allows Microsoft Operations Manager (MOM) 2005 to be utilized to monitor the operational health of a Commerce Server 2007 deployment, aggregating all system events and performance counters raised by Commerce Server.

It is comprised of the Health Monitoring Service, which lives on each system utilizing Commerce Server – and the Management Pack itself (which resides on the system running MOM) – which communicates with the Health Monitoring Service to expose data inside of MOM.

If one wishes to utilize Systems Center Operations Manager 2007 (SCOM), the tools provided therein can be utilized to convert the MOM pack provided with Commerce Server 2007 for MOM.

 

Staging
Commerce Server 2000 and Commerce Server 2002 egregiously operated under the assumption that changes were made live to production sites. Although this may have worked sufficiently for small organizations, it caused significant operational pain for large organizations.

Most large organizations desire to make changes in one or more content development environments, copy that to a single preview environment – and then once validated as good – flip it over to production. Commerce Server 2002 Feature Pack 1 was the first release of Commerce Server to address this scenario. It did so by providing drivers to leverage Microsoft Application Center 2000 to stage Catalog and Marketing plus some Profile data.

Unfortunately, the Application Center product was not continued by Microsoft, leaving no direct successor. Enter Commerce Server Staging – a system that provides the ability to replicate between environments:
•    Content and Code
•    Catalog and Inventory Data
•    Marketing Campaign data
•    Profile Site Term Data

The Staging Service runs as its own Windows service on a machine running Commerce Server. It runs over it’s own TCP/IP protocol (leveraging the old CRS protocol from Site Server days – and the resultant IP port).

Utilizing its own MMC snap-in, a bill-of-materials can be defined, deployment targets identified, replication schedule established, and data transfer mode defined (for either full or incremental since last update).
Once defined in the MMC, the Staging service will then deploy the identified assets to the requisite deployment targets as an ACID transaction. It will do so ensuring that the operation is a single unit of work – and that if a failure occurs, a rollback will also occur to leave configuration in a consistent state.

The system is quite flexible – as multiple sourcs can be consolidated onto a single destination – or vice versa. If the source and destination cannot see each other directly – multiple relay points can be identified as interim replication steps – with the only requirement being that each relay point be running the Commerce Server Staging service and that each previous relay point can speak over TCP port 507 to the next relay point.

The Staging System provides its own event definitions and the ability to define custom pre- and post- event handlers (for both success and failure). It also provides its own COM (for use from Windows Scripting Host) and .NET API for further extensibility. Most operations can also be scripted through the command line. In short – it can be easily extended to handle most replication deployment scenarios. 

The Staging service is featured only in Commerce Server 2007 Enterprise Edition; it is not available in Standard Edition.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s