Administer > Manage WebSphere Commerce features > Workspace Administration Tool
Workspaces, task groups, and tasks
Overview
A workspace can be divided into...
The following diagram illustrates how a workspace is broken down into task groups and tasks:
Workspaces
Workspaces provide data isolation. Each workspace has its own database schema to keep data separate from other workspaces and the production-ready data.
When an authoring server instance is created, a finite number of database schemas are allocated for the workspaces. If a Workspace Manager creates more workspaces than the number of workspace database schemas available, task groups in workspaces without an available database schema cannot be activated, until another workspace is completed or cancelled to release a database schema.
To prevent this situation, use as few workspaces as possible while still maintaining the level of data separation you need.
If you manage multiple stores under one organization, you can use one workspace to manage content for the organization across all stores. You might still need multiple workspaces to provide data isolation between other tasks such as seasonal updates and emergency fixes.
Workspaces can be either single-use or persistent:
- single-use workspace
- A single-use workspace changes to the complete state when all task groups within the workspace have been committed or cancelled.
Use a single-use workspace when you only want to use the workspace for one group of activities. Once the workspace moves into the complete state, the resources used by the workspace, such as the database schema, are released.
Seasonal or event driven changes is an example of an ongoing activity that would use a single-use workspace. For example, all store updates for Summer 2006 could be made in a single-use workspace. After the changes for Summer 2006 are complete, the workspace would not be reused.
You can reuse task groups or tasks from a single-use workspace in other workspaces by creating templates from the task groups and tasks within the workspace.
- persistent workspace
- A persistent workspace remains in the active state when all task groups within the workspace have been committed or cancelled. Use a persistent workspace when to keep the workspace resources allocated.
A workspace used for emergency fixes should be a persistent workspaces to prevent the emergency fix workspace from waiting for resources if the maximum number of workspaces is exceeded.
You can reuse task groups or tasks from a persistent workspace in other workspaces by creating templates from the task groups and tasks within the workspace.
The Workspace Manager is responsible for creating and managing a workspace, and its properties, and the task groups and tasks within the workspace.
Workspaces have two identifiers: a workspace name and a workspace code. The Workspace Manager assigns the workspace name to a workspace while the workspace code is a system generated identifier for the workspace. Two different workspaces can have the same workspace name because their workspace codes will be different. However, having the same name for workspaces makes it difficult to distinguish between them in the Workspace Administration Tool.
Before data changes are committed, any changes made within the workspace cannot be seen by users outside the workspace. That is, the changes within a workspace are not saved as part of the production-ready data, but saved only within the workspace. The Workspace Manager commits an entire task group at one time, or a task group commits after it is approved by a Task Group Approver.
Task groups
A workspace contains one or more task groups. The Workspace Manager is responsible for creating and managing a workspace, and its properties, and the task groups and tasks within the workspace.
Task groups provide the following features:
- Separation of commit
- All the changes associated with a task group are committed to the production-ready data at once. When a task group is committed, the changes merge with the production-ready data, allowing users outside the workspace to see the changes. Each task group in a workspace can be committed independently of the other task groups.
When a task group is committed, the data in the task group moves from the workspace to production-ready data. After a successful commit, the data is no longer in the workspace.
- Approvals
- A Workspace Task Group Approver can approve the changes made in a task group before the data in a task group is committed to the production-ready data.
If you enable approvals for a task group, all its tasks are approved together. Individual tasks in the task group can be rejected or the all of the tasks in the task group can be rejected together. If a task group is approved, the task group data is committed to the production-ready data. If a task group is rejected, its tasks return to the working state. If an individual task is rejected, only the rejected task returns to the working state.
- Scheduled commit
- You can choose a date and time for the task group data to be committed to the production-ready data.
- Quick publish
- You can mark a task group for quick publish when you create the task group. When all tasks in a quick publish task group are complete and, if required, the task group is approved, the contents of the task group are committed to the production-ready data on the authoring server and then published to the production server.
The quick publish function is not related to the store publish process.
Quick publish is not supported in WebSphere Commerce Developer.
- Templating
- If a task group will be reused in any workspace, create a template from an existing task group. A task group template contains all of the information of the source task group except for the due date, since the due date should be different each time a user instantiates the template.
Create a template of a task group allows you to create new task groups based on the template quickly. Also, the new task groups will contain all of the tasks in the template task group.
An example of a task group template is a template that is used to update the price of a product. This task group can occur often, and in multiple workspaces.
- Comments
- Workspace Content Contributors can view and make comments through either the WebSphere Commerce Accelerator or the Management Center. Workspace Managers can view and respond to these comments in the Workspace Administration Tool. This helps Workspace Content Contributors and Workspace Managers communicate what is needed or how work is progressing.
Task groups have two identifiers: a task group name and a task group code. The Workspace Manager assigns the task group name to a task group while the task group code is a system generated identifier for the task group. While two task groups might have the same task group name, they will have different task group codes. However, having the same name for task groups makes it difficult to distinguish between the them in the Workspace Administration Tool.
Use task groups to keep sets of related changes together. This avoids possible conflicts, concurrency, or dependency problems. For example, if you are adding a new catalog item and creating an eSpot to market the new item, ensure that both of these tasks are performed within the same task group. If they are performed in different task groups within the same workspace, the eSpot could be committed before the new catalog item, causing the commit of the task group to fail.
The strictest way to avoid conflicts or concurrency problems is to have only one task group per workspace, but you should decide on the number of task groups in a workspace based on the business needs. An example of when you need multiple tasks groups is if different approvers are needed or if content needs to be committed at different time intervals.
Tasks groups can be either single-use or recurring:
- single-use task group
- A single-use task group is complete after the task group is committed.
Single-use task groups must be activated before Workspace Content Contributors can work on their assigned tasks.
- recurring task group
- If a task group will be reused within the same workspace, mark the task group as recurring. When a recurring task group moves into complete state, a copy of the task group is created. This copy has the same tasks as the original task group and is already in working state - this new task group does not need to be activated. The copy of the task group has the same task group name as the original, but it will have a new task group code.
An example of a useful recurring task group is a change to the catalog that occurs daily. After one day's tasks are complete, a new identical task group is ready for the next day.
A task group is committed if the following conditions are met:
- All tasks in the tasks group are complete.
- The task group is approved, if approval was enabled when the task group was created
Tasks
Tasks provide a separation of responsibility. Each task is an individual unit of work that contributes to the completion of an activity that the Workspace Manager assigns to Workspace Content Contributors.
Tasks are what Workspace Content Contributors see in either the WebSphere Commerce Accelerator or the Management Center. Workspace Content Contributors can only see the tasks that they are assigned.
The list of tasks in either the WebSphere Commerce Accelerator or the Management Center displays the following information about assigned tasks:
- Name
- Status
- Due Date
- Task group name
- Workspace name
Tasks have two identifiers:
- task name
- task code
After logging onto the either the WebSphere Commerce Accelerator or the Management Center, a Workspace Content Contributor chooses from a list of assigned tasks. Once a task is complete, the Workspace Content Contributor changes the state of the task to complete.
When planning the work flow for tasks, avoid making tasks too granular. For example, if you have a four-step process you want completed in a workspace, with the first three being done by one Workspace Content Contributor and the last one being done by another Workspace Content Contributor, you only need to create two tasks - one for the first Workspace Content Contributor and one for the second.
A task group cannot be approved or committed until all tasks in the task group are complete.
See