Workspaces limitations

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

  • You 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, you 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 you 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. You 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, you 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
    You 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 you 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 that contains 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 you 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 that you want 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

  • You cannot undo a history record if there are associated history records that depend on the one you are trying to undo. For example, you cannot undo a create category if you created products within that category. You must first undo all products that are associated with the category before you 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:
    You cannot perform an undo when the object is of type SearchTermAssociations.

    To reverse changes to search terms, you must manually reverse the changes while you are working on the task that contains the changes. You 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.

  • Undo does not work for managed files that are uploaded with the Assets tool. For example, if you upload, replace, or delete an image file under a task group with the Assets tool, you cannot undo this change with the Workspace Management tool. Instead, you must use the Assets tool to manually undo the change in the task group. For example:
    • If you uploaded a new file, you can delete the uploaded file from the Assets tool if it is no longer needed.
    • If you replaced or deleted the file, you can upload the previous version of the file.
    This limitation does not apply to attachments; if you create, update, or delete an attachment, you can undo those changes in the Workspace Management tool.
  • You can delete a sales catalog category even if it contains products. Doing so removes the products that are 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.

    You can delete WebSphere Commerce objects that involve the MEMBER table from a workspace, if the objects are available in a workspace. If you want to publish these deletions to the production server, you must turn off SQL batch update when you 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.

  • DB2Do 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 server. To publish these operations, you must use the stagingprop utility with SQL batch update turned off.

Previewing the store

  • While you are previewing a store shopping flow in a workspace, the following limitations apply:
    • OracleShopping flow preview is not supported.
    • DB2Shopping 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 you are working in a workspace.
  • You cannot test Dialog activities in Store Preview when you are working in a workspace.
  • Events that occur in store preview when you are working in a workspace are not visible when you 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 you 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 you 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 server limitations apply when you are using workspaces.