Working with ClearCase (Deprecated)
You can use Rational® ClearCase® as a software configuration management (SCM) system for projects created in IBM® Integration Designer.
This topic addresses some specific issues that arise when you use ClearCase. For general information about using software configuration management systems with Integration Designer, see Using software configuration management systems. For ClearCase documentation, see the ClearCase information center.
- There must be an existing ClearCase server set up.
- There must be an existing client-to-server connection.
- If the ClearCase server is remote, it must be on the same NT domain as the clients. If the server is local, this issue does not apply.
You must use ClearCase outside of Integration Designer, by using ClearCase Explorer and ClearCase Remote Client Standalone. If you have a ClearCase or ClearCase LT server that is installed on the same machine as Integration Designer, the ClearCase server can also act as a client.
You can use Rational ClearCase to manage a team's software development process. The unified change management (UCM) model supports patterns defined in the Rational Unified Process (RUP). Custom behavior can be specified through the use of policies. Base ClearCase uses triggers, scripts, and utilities to manage the software development process. See "Good development practices" below for tips about using the UCM model effectively.
A VOB (versioned object base) in ClearCase is the permanent data repository in which you store files, directories, and metadata. On a typical Integration Designer project, a single VOB is used to store multiple ClearCase components. Each component stores a logical group of modules and libraries. For large projects, multiple VOBs could be used.
Hint: Using snapshot views usually provides better performance than using dynamic views.
The Business Integration view provides a logical view of the resources in each module, mediation module, and library. Within each project, the resources are categorized by type. Logical resources shown in the navigation tree in the Business Integration view do not necessarily have a one-to-one mapping to physical files.
For information about the files that should be managed or excluded from source control, see "Integration Designer artifacts managed in source control" in the related links.
Configuring ClearCase to allow it to check in identical files
When you check in your files, choose the option to check in identical files. If you do not see this option, set the Checkin identical options preference in ClearCase.
The identical file check-in helps you to track the relationship between logical artifacts (such as BPEL processes) and the logical artifact's associated physical files. This configuration prevents the occurrence of error windows if you attempt to check in identical files.
Checking in identical files, especially text files, does not increase storage size in ClearCase.
Updating assembly artifacts from ClearCase
When you are sharing work on a project in a ClearCase repository, you need to be careful to keep your own local assembly artifacts (components, imports, exports, or stand-alone references) current. When one user adds a new artifact and checks it in, this change is not automatically communicated to other users. The same is true when a user deletes an artifact from the assembly diagram.
Update your snapshot or ClearCase (web) view frequently when working on assembly artifacts.
Troubleshooting
- Version number of Integration Designer that you are using
- Operating system and version
- Workspace log file
- Configuration details ()
- Team repository information
- Snapshot, dynamic, or ClearCase (web) view?
- Base ClearCase or UCM?
Good development practices
Work in a single stream when you can to avoid merge issues. If you need to work in multiple streams, merge often. Module-level merging is not supported, so avoid concurrent development on the same module. When you need to update files across modules, such as refactoring or compare/merge actions, avoid concurrent development on all the affected modules.
If you are using the Base ClearCase model, the triggers and scripts that you use dictate which actions you can take and what prerequisites must be in place at different points in the development cycle.
If you use Base ClearCase, you do not have to be concerned with silent checkouts being included in the current UCM activities. The disadvantage is that developers are working at the file level instead of the activity level. UCM lets developers work at the activity level instead of the file level.
Based on the model you are using, there are minor differences in the mechanics of user interaction. For example, in the UCM model, you must specify an activity when you version elements. When you use Integration Designer to check in elements, you are prompted to specify a corresponding activity for the new version. Make sure you have at least one activity before you start a build. And before you deliver to the integration stream, rebase the development stream with the most recent baseline.
If you are working in ClearCase UCM mode, work with one activity at a time, and check in all changes for one activity before moving on to the next activity. Always set ClearCase UCM view's default activity to the current activity that you are using. The automated source control operations that occur during refactoring and checkout use that current activity. If you are using serial development with multiple activities, you can create dependencies among activities. In that case, an activity cannot be delivered without its dependent activity.