Workspaces limitations

When we are using workspaces, be aware of known limitations.

• We can create as many workspaces as you require. The default maximum number of active workspaces is 5. An active workspace contains at least one task group in the active state. If necessary, we can change the default maximum number of workspaces that can be activated during instance creation time.

• The Catalog Filter and Pricing tool is not supported in workspaces. That is, the Catalog Filter and Pricing tool always works with base content (also known as approved content), regardless of whether workspaces are enabled in WebSphere Commerce.

• Management Center folders are not supported in workspaces. For more information about folders, see Folders

Data Load utility

• When you load data from an external source into a workspace, the WebSphere Commerce database referential constraints are not imposed. This limitation in workspaces means we can load bad data into the workspace. Bad data in the workspace prevents the workspace data from being committed to the production-ready data.

  Support for loading XML files is available when you run the Data Load utility. We can use the Data Load utility to load data from an external source into a workspace. If you loaded bad data into a workspace, use the Data Load utility in dataloadmode=Delete with the same XML input file to remove the data. After that, we can correct the data and try to load the data into the workspace again.

Users and potential conflicts

• An administrator can configure the Workspace Management tool to display the list of change history records for task groups that are in one of the following approved or canceled states:

  • Complete

  • Published

  • Publish failed

  • Canceled

  We cannot open or undo the history records for task groups that are in one of these states, or compare the records to approved content. The history records remain in the History tab for the task group until the task group is removed or deleted from the workspace, or the workspace is deleted.

• There is no checking for conflicts between a single-use and recurring workspace task groups. If we create a recurring task group in a single-use workspace, the workspace remains open. The workspace remains open because all task groups in the workspace never move into the complete state.

• Users working in different workspaces must not work on assets that have the same unique identifiers in the same store. For example:

  • Attachments - do not upload files with the same full path for the file in different workspaces for the same store.

  • Products - do not create or update products with the same part number in different workspaces for the same store.

  • Catalogs - do not create or update catalogs with the same identifiers in different workspaces for the same store.

  • Catalog categories - do not create or update catalog categories with the same identifiers in different workspaces for the same store.

  When assets in different workspaces have the same unique identifiers in the same store and the task group that contains one of the assets is committed to the production-ready data, the task group in the other workspace containing the other asset with the same unique identifier in the same store cannot be committed to the production-ready data.

  This limitation does not apply when we are working in different stores.

• If a task group is canceled while a Workspace Content Contributor is working on a task, the Workspace Content Contributor can continue to change. These changes can never be committed to the production-ready data. To prevent this situation from happening, ensure that no one is accessing a task in the task group to cancel.

• A business object is locked only when it is saved. For example, if two Task contributors open the same object, the first Task contributor to save the object locks it. Even though both contributors opened the object, only the "first save" Task contributor can continue working with the object. The other contributor cannot change the business object until the changes or either committed or undone.

Undoing changes

• We cannot undo a history record if there are associated history records that depend on the one we are trying to undo. For example, we cannot undo a create category if you created products within that category. We must first undo all products associated with the category before we can undo the category.

• Undo is not supported for search term associations. If you change search term associations under a task group, the History pane lists history records for each changed term. Trying to undo the changes in a history record results in the following message:

   We cannot perform an undo when the object is of type SearchTermAssociations.

  To reverse changes to search terms, we must manually reverse the changes while we are working on the task containing the changes. We can reverse the changes in the Management Center catalogs tool for the store.

  In addition, if you open a history record for a search term association, the main Search Term Associations page opens, rather than the specific search term association.

• We can delete a sales catalog category even if it contains products. Doing so removes the products associated with the deleted category, but does not delete the products from the master catalog. Undoing the deletion of a sales catalog category restores the category to its previously approved state. Product associations that were already contained in the approved sales category are restored. However, products (either in the workspace or in approved content) that were copied or moved to this sales category from within the same workspace before the delete are not restored. These products will not be included in the sales category after you undo the deleted sales category. To restore the sales catalog category contents, drag products from the master catalog to the sales category.

• When you undo the deletion of a product, the product reverts to its approved version. For example, consider a product that has four SKUs. You then add more SKUs to the product, delete the product, and undo the delete. The product reverts to its approved version with four SKUs. To update the product to have the correct number of SKUs, add the SKUs to the product again.

Database

• Workspaces provide content validation at the database level only. Data is checked only for database constraints when the data is committed to the production-ready data. There might be data inconsistency that is caused by related changes in task groups. If the changes do not violate any data constraints, then the changes are allowed to commit to the production-ready data.

• (DB2) Do not delete any WebSphere Commerce object that involves the MEMBER table from the production-ready data. These objects include users, organizations, customer segments, member groups, customer territory groups, or customer price groups. If you attempt to delete these objects, the objects do not delete.

  We can delete WebSphere Commerce objects that involve the MEMBER table from a workspace, if the objects are available in a workspace. To publish these deletions to the production environment, we must turn off SQL batch update when we are running the stagingprop utility. Turn off SQL batch updates by specifying setting the -batchsize parameter to 0.

  To learn what WebSphere Commerce objects involve the MEMBER table, review the WebSphere Commerce data model documentation.

• (DB2) Do not use the quick publish option to delete catalog categories or to delete any WebSphere Commerce object that involves the MEMBER table. While these updates commit to the production-ready data successfully, they do not publish to the production environment. To publish these operations, we must use the stagingprop utility with SQL batch update turned off.

Previewing the store

• While we are previewing a store shopping flow in a workspace, the following limitations apply:

  • (Oracle) Shopping flow preview is not supported.

  • (DB2) Shopping flow preview is supported for stores with either the non-ATP or the no-Inventory inventory systems, except the following scenarios:

    1. Customer specifies a shipping instruction for the order during the shopping flow.

    2. Customer adds a static kit or dynamic kit into a shopping cart during the shopping flow.

    3. Customer places an order with tax applied during the shopping flow.

    4. Customer places an order under the store whose price refresh flag is 1, 2, or 4. See the PRICEREFFLAGS column of the STORE table for detailed usage.

    5. Customer inputs a promotion code for the order during the shopping flow.

    6. Customer inventory system is non-ATP and inventory is configured as UPDATE mode (INVENTORYFLAGS is not 1 or 3).

  These limitations result because they require that unmanaged assets in the base schema to be updated during the shopping flow. However, these assets also have foreign key constraints on managed assets in the write schema. For example, when a customer specifies a shipping instruction for the order, it attempts to create a record in the SHIPINFO table. However, in a workspace, the SHIPINFO table is an unmanaged asset, and the ORDERS_ID column has a foreign key constraint to the ORDERS_ID column of the ORDERS table. The ORDERS table is a managed operational asset in the write schema, which causes the update on the SHIPINFO table to fail. As a result, the shopping flow cannot be completed.

• Revenue from views and clicks in web activity experiments do not calculate in Store Preview when we are working in a workspace.

• We cannot test Dialog activities in Store Preview when we are working in a workspace.

• Events that occur in store preview when we are working in a workspace are not visible when we are working on approved content.

  For example, view and click events for an e-Marketing Spot that accumulate in workspace Store Preview are not reflected in statistics that are visible when we are previewing approved content. In addition, behavior (catalog browsing behavior, online behavior) that occurs in workspace Store Preview is not considered for target evaluation when we are previewing approved content.

• Searching for extended site store catalog entry description override information is not supported in store preview within workspaces.

  • Workspaces store preview support for searching for extended site store catalog entry description override information is provided by default.

In addition to the limitations listed here, staging environment limitations apply when we are using workspaces.

Related concepts
Workspaces overview
IBM Management Center for WebSphere Commerce
WebSphere Commerce Accelerator

Related tasks
Manage roles in workspaces, task groups, and tasks

Related reference
Workspaces best practices
Workspaces data model
Workspace state flows
Staging environment limitations