- Creating an authoring environment
You can run an authoring environment on a separate system or machine partition from your production environment.
- Synchronizing an authoring environment with a production environment
If you create your authoring environment after creating a production environment, you must synchronize your production and authoring environment to ensure that the authoring environment accurately reflects your production environment. You should also synchronize your authoring environment and production environment if at any point your production-ready data on the authoring environment does not accurately reflect your production environment. This can be caused by changes made directly on the production environment, either one large change or a series of smaller, incremental changes that cause the information about the authoring environment and production environment to no longer be synchronized.
- Authoring environment schema update tool
The content management solution in HCL Commerce introduces multiple database schemas on the authoring environment that require each and every table to have a definition within each schema. The definition within the workspaces schemas differ depending on whether the table is considered to be one of the following resources:
- Enabling quick publish
If database information for your production environment changes, you must update the quick publish target.
- Enabling e-mail notification for workspaces
Enabling e-mail notification in workspaces allows HCL Commerce to send e-mail automatically in certain situations.
- Enabling shopping flow preview for workspaces
Enabling shopping flow preview in workspaces allows users to preview how their changes affect the experience of a customer when the customer is completing a shopping flow.
- Changing workspaces locking policy
Do not change the workspaces locking policy if you have uncommitted data in any of your workspaces. This can cause undefined behavior with the uncommitted data.
- Configuring retry for committing approved task group changes
You can configure the task group approval process to automatically retry committing task group changes to the database. By configuring this setting, you can avoid having the commit of approved task group changes fail when a database timeout error occurs.
- Enabling the change history for approved and canceled task groups
To maintain the change history for approved or canceled task groups, configure how the change history is recorded for changes that are made within a task group.