In the siebel IP19 a Workspace feature provides users a new way to manage configurations of repository artifacts in Siebel Tools. This feature allows multiple developers to work on the same repository objects in the Siebel database.
A workspace provides a user with a sandbox for editing and publishing (delivering) configuration changes until these changes are ready to be delivered into the main workspace (parent, root, or master workspace).
A workspace provides a user with a sandbox for editing and publishing (delivering) configuration changes until these changes are ready to be delivered into the main workspace (parent, root, or master workspace).
This feature ensures isolation from other users making changes to either the same objects or other objects in the application. It is also an alternative to using local databases to make changes to the repository data.
Users can preview and test repository updates made in a developer's environment (workspace) in Web Tools without affecting other developers. They can do this when they are added to the database and also have the Composer Administrator responsibility to access the Workspace Dashboard to perform developer or configuration operations. Until all updates are delivered, these updates will not impact other developers. Once the changes in developer workspace are delivered then Siebel runtime repository tables will be updated with the new values.
Users can preview and test repository updates made in a developer's environment (workspace) in Web Tools without affecting other developers. They can do this when they are added to the database and also have the Composer Administrator responsibility to access the Workspace Dashboard to perform developer or configuration operations. Until all updates are delivered, these updates will not impact other developers. Once the changes in developer workspace are delivered then Siebel runtime repository tables will be updated with the new values.
In other words, the Workspace feature in Siebel Tools provides the following capabilities:
- A user can make configuration changes to the repository application without any impact on other users.
- Configuration changes are persistent but in isolation from the metadata of the deployed application.
- Only modifications to the configuration (delta) are tracked and stored, while other configurations are referenced from the base repository in order to render a consistent view of the modified application.
- Persistence of configuration changes enables configuration to be a long-running operation or transaction.
- Concurrency is achieved so that multiple users can each modify the same application in isolation from one another.
No comments:
Post a Comment