Commerce Server Blog

In the previous post, I explains the core CS staging concepts and if you have not yet viewed , click below link for more detail.
Introduction to Commerceserver staging

In this article, we will learn how staging works. When you install commerce server staging (Note: staging is part of CS enterprise version), a service named “Commerce Server Staging” is installed and you can see it in services MMC. When ever we start a staging project, the replication (during transit, CS encrypts data using SHA algorithm) will happen under this account credentials. So, make sure you don’t run this service under network or local account instead run it under domain account. Apart from the service, three groups are created on the server and each group has it’s own significance.

• CSS_SG: commerce server staging service group have operator access to all projects. So, the service account under which the staging service runs is to be part of this group.
• CSS_Operators: commerce server operator group have operator access to manage projects.

• CSS_Administrators: commerce server administrators group have administrative access.

The below table explains security permissions between the groups.

The users can able to access projects and routes in Staging MMC only if they are part of CSS_Operators or CSS_Administrators and make sure proper access to databases. I will explain more about sql security in my upcoming articles.

The below diagram explains how stage data is moved from source CSS server to destination CSS server.

• The staging operation starts when the user trigger project execution. Project execution can be done manually either through staging MMC or staging command line utility (CSS.EXE) or the execution process can be scheduled to run on a particular time/date.

• Based on the project name, CSS process loads information from configuration settings and initiates the process.
• Based on the destination settings, the source CSS informs all destination CSS systems about the execution so that they are aware and do the necessary imports.
• Based on setting, the data is extracted from commerce server or web folder or IIS.
• Once extract is done, the extracted data is moved to destination folders. Here Staging encryptions data using SHA algorithm so that the data transferred happens securely.
• Once the files are copied to the destination folder, the destination CSS loads the configuration and start importing data.

If you like this post, please click on our sponsor advertisement.

Commerce server staging (in short CSS), helps us to transfer and update business data and web site content from one environment to another environment.  In the nutshell, CSS provides following functionality.

• Remotely administer servers and projects.
• Replicate web site content or business data over LAN and through firewalls (TCP port 507).
• You can deploy content or data manually or on pre-determined schedule.
• Replicate IIS metadata
• Configure scripts and/or batch files to run before or after content or data is replicated.

Few things to make note of:

• Business data includes catalog schema and data, Marketing data, site terms, order configuration.
• You can’t stage/ replicate profile schema, profile data, inventory schema, order data, direct mailer job, lists and confirguration.
• All business data types supported by CSS can refresh site cache.
• Web Content, includes HTML, images, ASP.NET pages, commerce server pipelines and other files, IIS metadata.
• IIS meta data includes information about the files in the website and its configuration.
• Make sure TCP port 507 is open in order staging site work.
• Roll back feature is applicable to web content deployment only.

The below diagram explains how staging works. In CSS, we have three types of servers.

• Source staging server – this is the server from where the content & data is deployed.
• End point server – this is the server to which the content & data is deployed.
• Way point server – this server is used to relay the content & data from source staging server to end point server.

In the below diagram demonstrates how the data is moved from one environment to another environment. The CSS service can be installed on dedicated box or on all environment servers.

In order to understand CSS, you have to learn two concepts – one is project and another one route. A CSS project defines the properties of a CSS deployment and it takes few key properties like, name, type (content deployment or business data deployment) and project source (path where the data is staged). Some of the points we have to remember while creating a project.

• A project needs to be created in each CSS server involved in staging. (The above diagram, we are using single CSS server for all deployments).
• Project name should be same for all CSS servers (this will not accept special characters including space) and the properties may differ from one project to other.
• Project properties tells the purpose of staging.
• Project type must be same for the same projects across CSS servers. For example, if the project at source staging server is “web deployment” then the end point server project type should be the same.

A route in CSS signifies a path by which the data is moved from source to destination. A route will hold few properties such as route name, local directory to store the data and the destination server. As CSS project, route is also required to have few mandatory settings in order to work and they are

• A route needs to be created in each CSS server involved in staging.
• Route name should be same for all CSS servers .

Note: Defining a route is not compulsory for a given deployment. In majority of the deployments, I have seen, we have created CSS projects without routes. This is applicable if the source server can’t access the destination server directly.

In coming posts, I will try to explain how commerce server staging works, command line tools and how can we write scripts to make the deployment easier.

If you like this post, please click on our sponsor advertisement.