Administer > Manage WebSphere Commerce features > Workspace Administration Tool
Workspaces best practices
When you use workspace, you should have strong business processes in place to prevent the situations outlined in Workspaces limitations and restrictions. These apply to workspaces managed in both the WebSphere Commerce Accelerator, and the Management Center.
To help guide the development of the workspaces related business processes, consider the following best practices:
Use task group comments to coordinate and track work and for communication
Workspace Content Contributors should use task group comments to keep other Workspace Content Contributors posted about their work and changes they have made. Task group comments are also useful for Workspace Managers to see how work is progressing and to tell Workspace Task Group Approvers what changes have been made that require approval.
Minimize the number of tasks assigned to a Workspace Content Contributor
Try to combine the work assigned to a Workspace Content Contributor into one task where possible. This prevents unnecessary task switching and improves the Content Contributor's efficiency when working on tasks.
For example, if you plan the following the workflow:
- Workspace Content Contributor A creates a catalog entry.
- Workspace Content Contributor B adds pricing information for the new catalog entry.
- Workspace Content Contributor A adds images for the catalog entry.
Put steps 1 and 3 into one task for Workspace Content Contributor A and create one task for Workspace Content Contributor B. The Workspace Content Contributors can coordinate their work using the task group comments.
Keep task groups independent of each other
A task group is the smallest unit of work that can be committed to the production-ready data on the authoring server. This means that all updates made in a task group will be committed to production-ready data together, but updates made in different task groups are not guaranteed to be committed in the same transaction. Interdependencies among task groups require you to commit the task groups in the correct order. Because resolving interdependencies among task groups is not automated, you should keep task groups independent of each other.
To keep task groups independent, you should carefully design the task groups and not use managed assets in more than one task group.
The task group locking policy does not completely prevent users from accessing managed assets that are created in different task groups. For example, if products A and B are created in task groups A and B respectively, a cross-sell association between products A and B can be created in task group C.
Create and using only one task group per workspace is recommended if it can satisfy the business requirements. This is the strictest way to guarantee task group independence.
Keep workspaces independent of each other
Do not allow users to work on the same managed asset in different workspaces. This prevents overwriting data and achieves consistency between the production-ready data and workspaces.
Work on the same managed asset in different workspaces can also cause inconsistency between the production-ready data and the workspace data. For example, a catalog category was updated in workspace 1, but the same category was deleted in workspace 2. If the change from workspace 2 is committed first, committing the changes from workspace 1 will fail due to the inconsistency between the workspace and the production-ready data. The category is used in the workspace but it does not exist in production-ready data.
Keep the workspaces and the production-ready data consistent
You can also introduce inconsistencies between workspaces and the production-ready data by directly updating the production-ready data. When you update a managed asset in a workspace, the managed asset is not locked in the production-ready data.
Updates made directly to the production-ready data can be overwritten once updates in workspaces are committed or the updates can cause the commit from workspaces to be blocked. For example, if you update a catalog category in a workspace, you can block the commit of the changes in the workspace by deleting the category from the production-ready data.
If work directly on the production-ready data, consider using a quick publish task group in a workspace instead. Otherwise, check if manually apply the same change to all of the workspaces as well as the production-ready data.
Avoid direct updates to the production-ready data
Avoid direct updates on the production-ready on the authoring server unless the updates are isolated by the business processes.
Regardless of which locking policy you use, you can always create, update or delete content directly in the production-ready data. Direct updates to the production-ready data might be overwritten when a task group commits or they might prevent a task group from committing successfully.
Typically, updating and creating content in the production-ready data would not cause potential conflicts for the commit except where a unique index is involved. An example is trying to update a product part number to a value introduced in another workspace or base.
Delete resources, such as removing associations or moving products, risks causing conflicts.
You should perform direct updates to the production-ready data only on assets that would not be worked on concurrently in a workspace or on assets that are introduced initially in the base. For example, if you receive pricing from a back-end system, you might choose to load and update directly to the production-ready data since Workspace Content Contributors would never update prices in a workspace. You might introduce new products or items directly into the base and create workspace processes only to update existing products or items.
Related reference
Use workspaces with an extended sites store model in WebSphere Commerce