Workspace Concept in Websphere Commerce Server

This specific post is a small step to understand the workspace concept in WCS.

Will give a clear picture how the content management works in WCS.

Will also give a understanding of data flow from authoring to production server.

What are workspaces?

A workspace allows content to be created in a workspace separated from production ready until the business approves such content changes

Only production-ready data on authoring server is published to production

Workspaces provide data isolation. Each workspace has its own database schema to keep data separate from other workspaces and the production-ready data.

Each workspace consists of three database schemas

– Base schema

• Contains the current content.

• The base schema contains data that is identical to the production environments.

  All workspaces draw from this common repository of data but none of their working

  changes are reflected here.

[Regular tables with regular information]

– Write schema

• Stores the content changes.

• It is in the individual write schemas that any uncommitted changes are stored,

thereby if there are two workspaces, workspace 1 changes are isolated from changes in workspace 2.

[Three extra field for each table to carry task group, task information]

– Read schema

• Presents how the current and changed content looks like.

• However, when users preview their changes, the write and base schemas are hidden behind the

read schema. The read schema first checks the write schema for the requested data and,

if it is not found there, then goes to the base schema.

[Actually there will be no table available in this schema all are views each view fetch data from both

 Baseschema and Write schema]

Within a workspace context, updates to a resource are directed to the write schema, whereas retrieving data for a resource is directed to the read schema.

                                           

Write Schema:

There will be additional three fields for each table to carry task related information.

Read Schema Example:

CREATE OR REPLACE FORCE VIEWread_schema.offerprice

                (offer_id, currency, price, compareprice, optcounter) AS

SELECT offer_id, currency, price, compareprice, optcounter

                FROM base_schema.offerprice

                   WHERE NOT EXISTS (SELECT 'match' FROM write_schema.offerprice

                                                                WHERE base_schema.offerprice.currency = write_schema.offerprice.currency

                                                                      ANDbase_schema.offerprice.offer_id = write_schema.offerprice.offer_id)

UNION ALL

  SELECT offer_id, currency, price, compareprice, optcounter

                FROM write_schema.offerprice

                     WHERE content_status<> 'D';

Content Management Data Model:

WebSphere Commerce database table: CMWSSCHEMA

The association of the underlying database schemas thatmakes up the workspace along with the assigning the workspace to a workspace identifier

.

Workspace Users:

A workspace is divided into task groups and tasks. Task groups serve as containers for tasks, where each task group can be committed independently of the other task groups. Tasks provide a separation of responsibility, where each task is an individual unit of work that contributes to the completion of an activity. A workspace content contributor chooses from a list of assigned tasks to work on. 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.

Different users:

select * from role;

User role and responsibility:

  

Data Management:

The data that is enabled for workspace approvals will have the model described before with base, read and write schemas. Unmanaged resources have only one table that is the same for base, read, and write schemas.

•               Create a task group

•               Optional: Enable quick publish

•               Optional: Enable retry for quick publish

•               Create tasks

•               Activate your task group

•               Optional: Schedule the commit of your task group

•               Mark all of the tasks in the task group complete

•               Approve your task group

•               Publish production-ready data

Various tasks will be created under each task group and assigned to different contributors. The next step is for the content contributors to work on their tasks and mark them complete. A task group cannot be approved or committed until all tasks in the task group are complete. After the tasks are marked complete, approve your task group to commit data in the task group to production-ready data, either immediately or at a scheduled time set earlier. If the task group is marked as quick publish, changes are also published to the production server. If not, publish production-ready data from the authoring server to the production server to view changes on your site.

Note:There is one separate utility to transfer all updated data to production server.

Stagingprop utility:

The stagingprop utility propagates staged data and managed files from the production-ready data to the production server. It consolidates the changed data from the production-ready database, and then it propagates the necessary changed data into the production database if the connection is available.

Graphical Representation of Workspace Concept:

 

This information can be provided by individual contributor or can also come from various external systems. A business user can also play are role of contributor. Business user can provide or manipulate some information by using the dedicated tools.

 In this case we have introduced a security to allow only valid error free data.
Still something is lacking here, Business user cannot get the clear picture what is going to be delivered to the end user.
Cannot afford to perform undo, redo kind of activity on environment like production.

After doing the store preview if everything looks good the task group approver can approve the tasks and mark them completed. All the changes available in write schema will be committed to base schema and same changes will reflect on store front pages, so the end user can experience the changes.

If task approver is not satisfied with the store preview he can reject this task and nothing will be committed to base schema, so end user will continue to experience what he was experiencing.

A particular activity can be divided into various tasks.

For Example. Need to load a product data.

We can divide the same load activity into various tasks.

Say task group name is “Load Product Info”

There are few tasks under this task group like

                1.     Load Product Descriptions Task

                2.     Load Product Images Task

                3.     Load Product Price Task

                4.     Load Product Attribute Task

                5.     Product Publish Task

All these above tasks have been assigned to individual contributors.

Once all these above tasks are completed, the task group approver can validate it on store preview.

Depending on the outcome approver can approve or reject a specific task.