Staging environment
WebSphere Commerce application environment
A WebSphere Commerce staging environment is a runtime environment where business and technical users can update and manage store data and preview changes. The changes can then be propagated to the production environment.The staging environment is a close replica of the production environment, with some allowable differences..
Setup Staging Production Hardware (non-Docker containers) same same Software version same same Operating system version same same Configuration same same Nodes The staging environment does not have to have the same number of nodes as the production environment. For example, a production environment can have multiple Transaction server Docker containers while the staging environment can have a single Transaction server Docker container. Components same same Transaction server Docker image same same IBM HTTP server Docker image same same search-app Docker image only search-master search-repeater and search-slaves Store server Docker image (needed if not migrated from WebSphere Commerce Version 8) same same Customization server Docker image same same Utility server Docker image same same Database server same same Database same same
Staging environment data
There are two types of data...
- Configuration tables
Contain data such as stores, catalogs, catalog entries, languages, taxes, and discounts. These tables are under Site Administrator control.
- Operation tables
Data such as customer information, address, and orders data.
The staging environment manages only configuration tables. Data in operation tables is not published or copied between the staging and production databases.
Ensure that tables managed by the staging environment do not contain any foreign key references to operation tables. Otherwise, the publication could fail due to a potential primary key deletion from the production database. Before using the staging environment, ensure that only the organization owns the operational data, not the individual user, such as a catalog administrator.
Delta data capture function
The staging environment uses a delta data capture function to determine which database data changed and needs to be propagated to the production environment. This function is used internally by the staging environment, and no manual intervention is required.
The delta data capture function does not capture all changed data on the staging environment:
- Delta data capture does not cover content files. Content is managed in Watson Content Hub and published to the production environment by promoting assets from authoring to delivery.
- The staging environment covers configuration data, not operational data.
The data capture function consists of two parts, the staging triggers and the STAGLOG table.
Assets such as currency, language, product, and catalog, are controlled by the administrator. Configuration tables containing content data are staging-enabled. Three staging triggers are created on each staging-enabled table to capture the INSERT, UPDATE, and DELETE actions on the staging-enabled table.
These staging triggers log the data changes that happen on the staging tables to the STAGLOG table. Changes are written to the STAGLOG table that is read by the stagingprop command. With the information in the STAGLOG, the staging utility command can propagate the delta data from the production-ready data to the production database.
See
- Create a staging environment
- Stage environment utilities
- Stage environment limitations
- WebSphere Commerce staging-enabled tables
Related tasks
Configure databases for use with the staging utilities
Create a staging environment
Create triggers for custom tables
Copy data to the staging database
Publish data to the production database
List managed tables
Test the site in a staging environment
Reuse custom staging triggers
Related reference
stagingcopy utility