Workspaces, task groups, and tasks

A workspace can further be divided into task groups and tasks. This section provides details about the following items:

The following diagram illustrates how a workspace is broken down into task groups and tasks:


D

 

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, 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 you want 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 WebSphere Commerce Accelerator. 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 your 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:

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 WebSphere Commerce Accelerator. Workspace Content Contributors can only see the tasks that they are assigned. The list of tasks in Accelerator displays the following information about assigned tasks:

Tasks have two identifiers: a task name and a task code. The Workspace Manager assigns the task name to a task while the task code is a system generated unique identifier for the task. While two tasks might have the same task name, they will have different task codes. However, having the same name for tasks makes it difficult to distinguish between them in the Workspace Administration Tool and might make it difficult for Workspace Content Contributors to distinguish between them in WebSphere Commerce Accelerator.

After logging onto the WebSphere Commerce Accelerator, 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.


Related Concepts


Workspaces
Workspaces roles
Workspaces locking policies

Related tasks

Enabling Workspaces
Create a workspace
Create a task group
Create a task group template
Create a task group from a template
Create a task
Accessing assigned workspace tasks
Marking a workspace task as complete (Workspace Content Contributor)
Scheduling the commit of a task group


Related Reference


Workspaces best practices
Workspaces data model
Workspace example scenario: Seasonal changes
Workspace example scenario: Regular maintenance
Workspace example scenario: Emergency fixes