How Does Staging Work?

Article
01/18/2011

You use the Commerce Server Staging (CSS) system to deploy Web content and Commerce Server business data from one source server to any number of destination servers. CSS supports staging deployments that include simple and complex network topologies.

Note

In this staging guide, we use the terms replicate and stage interchangeably.

CSS uses the TCP/IP protocol and Microsoft Windows authentication to help create secure connections among CSS servers. CSS provides sophisticated data validation for reliable deployment across Internet or intranet networks. CSS uses staging, endpoint, and optionally waypoint servers. The staging server transmits the content. The waypoint server(s) receive and transmit the content. The endpoint server(s) receive the content.

To learn more about how staging works, review the following sections:

CSS Servers and Server Roles
CSS Service
Projects
Routes
Staging Sequence
CSS System Dependent Components

For information about CSS authentication and security, see Configuring Security for Commerce Server Staging.

CSS Servers and Server Roles

A CSS server is a server on which a CSS service is running. CSS servers deploy and retrieve content as instructed in their project and route definitions. CSS is highly flexible in how you can configure it. Although you can use a single server to deploy content between directories, most CSS installations are more complex where multiple servers are involved and each server performs a different function.

CSS servers are assigned one of the following three roles in the staging and deployment process:

Source Staging Server. These servers provide the source content or data that is deployed.
Endpoint. These servers receive content.
Waypoint. These servers receive content and transmit it to one or more waypoint or endpoint servers.

All CSS servers operate in the Microsoft® Windows environment and should have a network or Internet connection to other CSS servers.

Source Staging Server

The source staging server is a CSS server that has the content or data that you want to deploy to the endpoints. The staging server is where you test or stage the content or data before you deploy it to endpoint servers. Testing is an important part of the process because it enables you to review the content or data that is being deployed and make sure all links are functioning correctly. As soon as the testing is complete, the staging server deploys the content to the waypoint or endpoint servers.

Each staging server can contain multiple project directories for storing staging projects. When you perform a Web content deployment, CSS searches the project directories for all relevant content files, directories, and sub-directories. This search is based on filters that have been applied and then deploys those files to the next server.

Endpoint

The endpoint server is a CSS server that receives content from the staging server or a waypoint.

Within the endpoint server is a destination directory. The destination directory receives the deployed content. The staging administrator identifies the destination directory when they create the project.

Waypoint

For complex network topologies, one or more servers may sit between a staging server and the endpoint servers. In these cases, you must install CSS on these servers and configure them in the project. These servers perform a relay function and are referred to as waypoints.

CSS Service

The CSS service is a Microsoft Windows deployment engine that runs as a Windows Server 2003 service and provides core stage and deployment functionality. The CSS service runs on each CSS server and communicates with other CSS waypoint and endpoint servers.

The CSS service starts automatically when your server starts. You can start, pause, resume, or stop the service at any time from the CSS MMC or through the command-line interface.

Projects

A staging project defines the properties of a staging deployment. Projects define the following information:

The name of the project.
The type of staging project: Web content, IIS metabase, or business data.
The source server that provides the data to be staged.
The location of the directory that contains the content to be deployed. For Web content, the location is known as the project directory. For business data, in addition to specifying the Project Local Directory, the site name associated with the business data to be exported from and imported to is also specified at the source and endpoint servers, respectively.
The destination for the content. The destination can be a local directory, route, or endpoint server(s) that will receive the content.
The data to be staged and the staging mode that will be used. These options vary according to the staging project type.
(Optional) The schedule for staging. The scheduling options vary according to the staging project type.
(Optional) Scripts and batch files to run before or after content is staged or received.
(Optional) Project-level staging operators and authentication.
(Optional) Who to send e-mail messages to and for which events as staging occurs.
Additional options depending on the type of staging project and data selected to be staged. For information about staging options, see What are the Staging Project Options?

A project with the same name must be created on each server that is involved in the staging deployment.

For a staging project to be well defined, it must follow these rules:

The project must be defined on all the CSS servers from which or to which data is deployed for that project.
The project name must be the same on all the CSS servers. However, the properties of the project are potentially not the same for each CSS server.
The project properties could differ among the CSS servers depending on where the server is in the staging network topology and what elements are valid for that server. For example, schedule replication is defined for the source staging server because that is where the staging deployment starts. Schedule replication is not defined for endpoint servers. However, for Web content projects, schedule apply may be defined.
The project type must be the same on all the CSS server from which or to which data is deployed for that project.

For more information about projects, see Creating Projects for Staging.

Routes

You configure routes to deploy and receive content during a replication. A route is a predetermined path from one point to another point or from one point to multiple points. A route specifies one or more waypoints or one or more endpoint servers. A chain of routes can be configured to stage content across multiple hops through multiple waypoints.

The route can be very simple, listing only the destination directories in a single server. Or, it can be complex, involving multiple waypoint and endpoint servers. You define routes when you must route content through a waypoint, or when you want to reference the same network route paths in other staging projects. You can use routes together with several staging projects. Routes are especially useful when you use the same source and destination servers for multiple staging projects.

Important Note:
You must create the route with the same name on every server in the route.

For a route to be well defined, it must follow these rules:

The route must be defined on all the CSS servers from which or to which data is deployed for that route.
The route name must be the same on all the CSS servers. However, the route properties may differ for each CSS server.
For the source-staging server, the route configuration specifies one or more waypoint servers or one or more endpoint servers as the destination.
The route configuration must specify one or more waypoint servers or one or more endpoint servers as the destination.
The route configuration leaves the destination servers (end point servers) as undefined.

For more information about routes, see Configuring Routes for Staging.

Staging Sequence

When staging content or data, CSS performs the operations listed in the following sequence:

A project is started either from CSS Microsoft® Management Console (MMC) or according to a set schedule that is started from the Windows Task Scheduler.
The CSS service on the source-staging server reads the project configuration information.
The CSS service starts replication based on the project properties. For business data projects, data is exported from the database associated with the source staging server into XML files before the replication starts.
CSS transmits the files from the source-staging server to waypoint servers or endpoint servers. CSS uses keyed Secure Hash Algorithm (SHA) for maintaining the integrity of files that are sent.
On the CSS servers that are receiving the files, the CSS service reads the project configuration information and places the files based on project properties. For business data projects, at the endpoint servers, data is imported from the received XML files into the database associated with the endpoint server.
- For Web content projects, files are copied to the destination directory when staging is completed. If rollback and transactions is enabled on the endpoint server, all content files are stored under the CSSTemp folder before actually being copied to the destination directory. For timed-release projects, files are stored in the CSSTemp folder and copied to the destination directory only when an Apply command is received.
- For ISS metabase projects, a single binary formatted file is transmitted in a non-transactional manner.
- For business data projects, XML files are written to the Project Local Directory that you specify for the project.

CSS System Dependent Components

The CSS system depends on the following components:

Commerce Server Catalog System, Marketing System, Profiles System, and Orders System import and export APIs are used to stage business data.
Data protection application programming interfaces (DPAPI) provide information confidentiality by applying password-based cryptographic protection at the local operating system level.
IIS and Active Server Pages (ASP) display the status reports for projects.
Integrated Windows authentication (formerly named NTLM, and also known as Windows NT Challenge/Response authentication), is used to authenticate users.
Secure Hash Algorithm (SHA) is used to maintain the integrity of any file that CSS transmits.
Microsoft Access file stores CSS event and logging information.
SMTP Server sends e-mail notifications.

Share via