Workspace Limitations

Workspace limitations include the following:

• Developer Workspace. The maximum number of Developer Workspace versions that can be created under an Integration Workspace is 10,000. To avoid significant performance degradation, however, the recommendation is not to exceed 500 versions on a single Workspace.

• Integration Workspace. There is no limit on the number of Integration Workspaces that can be created for parallel development in a database. As the number of Workspaces increases, performance may start to degrade. If this occurs, you can delete Integration Workspaces when they are no longer needed. For more information, see Deleting Developer Workspaces.

• Workspace Hierarchy. There is no specific limit on the depth of your Workspace hierarchy.

  Each Workspace layer, however, requires additional logic to determine the definition of an object. For example, consider a situation where you have changed Field_X in the Account Business Component in a Developer Workspace that is under a feature Integration Workspace (IWS), under a release IWS, under the MAIN Workspace. In this scenario, for the Account Business Component to be used at runtime to test the field change, the Object Manager must query for the following:

  • Field_X definition in the Developer Workspace, plus

  • any other changes made to the Account Business Component in the parent feature IWS, plus

  • any changes made in the release IWS, plus

  • the original definition in MAIN.

  Object Managers understand how to do this properly, but collecting all this data requires multiple queries, which reduces the runtime performance. There is no specific recommendations for the depth of the Workspace hierarchy, but a tree with too much depth may result in slow performance when performing configuration in a Developer Workspace.

  Note: This performance degradation will only apply to DR environments because there is no Workspace hierarchy in RR environments.