Using Siebel Tools > Parallel Development Using Workspaces > Administering Parallel Development using Workspaces >

Understanding Integration Workspaces in Siebel Tools

Users with the administrative permissions can create parallel-development integration workspaces in the production environment. Developers use these integration workspaces to set up a parallel release development environment. The names of all integration workspaces start with the prefix int_ and these workspaces have the corresponding run-time repository version.

Only administrators can perform these workspace operations on the integration workspaces: Submit for Delivery, Rebase, Delivery, and Undo Submit for delivery. By default, the Deliver and Rebase processes trigger the Publish process on an integration branch that is the parent branch of the workspace you are trying to deliver. Also, only administrators can deliver the changes in the integration workspaces to the immediate parent integration workspace, and the rebase process must be performed from the immediate parent integration workspace.

For more information on how to deliver workspace changes and rebase workspaces, see Using the Command Line".

NOTE:  Users with the developer permissions can create development workspaces but they cannot create integration workspaces in the production environment nor deliver their workspace changes to the multiple-release integration workspaces simultaneously. In fact, they can open the integration workspaces and view the version changes in read-only mode, but they cannot perform any other workspace-related actions. After the administrators successfully deliver their workspace changes into the integration workspace, developers can open the integration workspaces in the Siebel application and view the latest delivered changes.

For more information on how to create development workspaces, see Understanding Development Workspaces in Siebel Tools, Creating Development Workspaces Using Siebel Tools, and Creating Development Workspaces in the Workspaces Dashboard.

After the Merge process from the source workspace to the destination workspace has completed, the Publish process runs automatically if the destination workspace is an integration workspace. The publish process is not initiated if the destination workspace is a development workspace. When the Publish process starts, processing updates all run-time repository tables with the latest metadata values. After the Publish process has successfully completed, users can see the latest compiled and published changes when they open the integration workspace in the Siebel application.

To avoid conflicts, it is recommended that you always create workspaces branching from the latest versions of the integration workspaces. For more information on how to resolve the conflicts in the emerging resolution window in Siebel Tools, see Detecting Conflicts in Workspaces and Applying Resolutions.

The parallel-development workspaces are incremented either when:

• The child-level integration or development workspaces merge their object repository changes with them, or
• Users perform the rebase operation on an integration workspace to uptake the changes that are made in the parent integration workspace (which means the Check Point option is not available for all users, including the administrators, to manually checkpoint the version of the integration workspaces).

NOTE:  You cannot perform the Revert functionality on the integration workspace.