Work in teams

For teams to work effectively, the environment should be set up appropriately and team members should understand the characteristics of the software configuration management (SCM) and versioning systems they are applying.

The easiest way to coordinate team development is to use the Process Center as your team repository. By associating your modules or libraries with a process application, you can easily share and manage artifacts that you publish to the Process Center repository. Versioning is handled for you through snapshots.

If you are working with Integration Designer as a stand-alone product without IBM Process Center, use a separate SCM system for versioning and source control. The topics in this section provide some guidance for working with SCM systems.

For information about versioning modules and libraries in your Integration Designer development environment, see Versioning modules and libraries.


Team development in Integration Designer

IBM Integration Designer provides tools to help teams share resources and collaborate effectively. For teams to work effectively, the environment should be set up appropriately and team members should understand the characteristics of the software configuration management and versioning systems they are applying.


Reusing artifacts

Integration Designer enables developers to reuse existing items, both within and across projects. For example, if you know several artifacts already exist that you and other developers need, you can access and reuse those items by including them in a library. You or others can then reuse those artifacts in other modules. To use artifacts from a library, set up a dependency from that module to the library using the Integration Designer dependency editor. You can set up dependencies on a library from any number of modules. To learn more about modules and libraries, see "Libraries" in the related links.


Work with the Process Center

The Process Center includes a repository for processes, services, and assets created in IBM authoring environments. You can use the Process Center repository to share artifacts with other users who are developing process applications and toolkits.

The Process Center console provides a location in which to create and maintain high-level library items such as process applications and toolkits. Administrators who do not actively work in the designer view can use the Process Center console to provide a framework in which BPM analysts and developers can build their processes and underlying implementations. Another primary task for administrators is managing access to the Process Center repository by setting up the appropriate authorization for users and groups.


Software configuration management systems

You can use Integration Designer with software configuration management (SCM) systems. You can view or change the preferences for available version control systems under Window > Preferences > Team. For more information about working with SCM systems, see "Using remote software configuration management systems" in the related links.


Use software configuration management systems

Libraries


Perspectives and views for team development in Integration Designer

Several perspectives and views in IBM Integration Designer are useful for collaborative development.

The following perspectives are critical for team development:


Business Integration perspective

The Business Integration perspective is the central work area for Integration Designer, where you can do artifact design, development, and component integration. You can also do most team development activities, such as check out, commit, and update, in this perspective.

As part of the Business Integration perspective, the Physical Resources view lists the relevant artifacts and resources for modules and libraries. The Physical Resources view is similar to the Project Explorer view under the Resource perspective, except that only Service Component Architecture (SCA) modules are shown; staging modules are not shown.

The Business Integration view includes a Show Files option that displays all authored files for an artifact. For example, a Business Process Execution Language (BPEL) process saves its process flow logic in a .bpel file, but there are other backing files-.bpelex, .mon, and Artifacts.wsdl-needed for the BPEL process to build properly. Right-click any artifact and select Show Files to open the view. The Show Files option highlights all the backing files in the Physical Resources view.


Physical Resources view

The Physical Resources view shows all of the file-level resources from the modules and libraries in their natural form. Related projects that are generated when you create business integration applications are still hidden in this view.

The logical contents of the physical file are also displayed in this view. For example, if you have several business objects in an XSD file, you will be able to expand the XSD file in this view and see all the business objects in the file.

If you have an artifact open in an editor, you can click the opened artifact in the editor pane (to focus on it) and then click the Link with Editor button to quickly locate the file in the Business Integration view.

You can apply filters to exclude all but the objects that you want from the Physical Resources view. By default, filters are enabled for XSD files to make it easier to find data types. You can also apply filters to WSDL files by enabling that function in Preferences and you can apply a filter to hide secondary artifacts.

The .settings folder also appears in this view. The .settings folder contains properties that are used by Integration Designer and should be shared with each project. For that reason, the .settings folder should be added to team repositories. See the related links for more information about the .settings folder.


Resource perspective

In the Project Explorer view, which is listed under the Resource perspective, you can see every module and artifact in the workspace, including all staging modules.


Team Synchronizing perspective

In the Synchronize view within the Team Synchronizing perspective, you can synchronize the workspace with the remote repository. It displays any relevant outgoing or incoming changes and can identify merge conflicts.


CVS Repository Exploring perspective

The CVS Repository Exploring perspective lists all modules or projects that are currently managed in CVS. If your project uses a different SCM provider, then a similar perspective may exist.



Related concepts:

Physical Resources view: The .settings folder


Related tasks:

Use CVS with Integration Designer and Process Center

Sharing your integration project through CVS

Associating a module or library with a process application or toolkit

Disassociating a module or library from a process application or toolkit


Modules and staging modules in Integration Designer

Every IBM Integration Designer application consists of an SCA module and an optional set of service library dependencies. The SCA module contains the core artifacts needed to deploy and run the application. Core artifacts might include business objects, interfaces, maps, and BPEL processes, and other objects. When the application is deployed and installed, Java™ code is generated based on core artifact logic.

Artifacts that are created in Integration Designer are said to be authored. If you create a new WSDL interface or business object, you are also creating, behind the scenes, a corresponding .wsdl or .xsd file in the workspace. In some cases, a single artifact type consists of multiple files. For example, when you create a new BPEL process, a few authored files including the .bpel, .bpelex, and Artifacts.wsdl file are created in the workspace. Each of these files is authored, since they are all necessary in order for the module to build successfully.

After a module is built, Integration Designer generates Java code for the authored artifacts during the deployment process. Generated artifacts are usually Java classes based on the logic defined in the authored BPM artifacts. Some of the generated deployment code is in the module or library; some is in a separate staging project. When working with the Process Center, no generated artifacts, neither files nor entire projects, are placed in the repository.


Staging modules

Every SCA module also contains a set of generated staging modules. Since the staging modules define the Java EE dependencies and optional web content, they generally do not need to be modified by the user. Since the staging modules do not contain authored BPM logic, they are not visible in the Business Integration perspective, but they can be viewed in the Java EE or Resource perspective.

Staging module names are based on the SCA module base name. For example, assume that an SCA module, HelloWorld, exists in the Integration Designer workspace. After the SCA module is built, the following staging modules are created:

In general, only the SCA module and dependent libraries need to be managed in source control. Staging modules appear in the workspace after the SCA module is built. Because of this timing, staging modules do not need to be managed within the source management control system as long as they contain no custom content or changes to the Java EE deployment descriptor.

In general, it is not advisable to add authored content to a staging module. If you add authored content to a staging module or make custom Java EE deployment changes, then the affected staging modules will also need to be managed in source control so these changes can be preserved. If you add custom content to the web staging module, such as HTML or JSP pages, the ModuleName web module will need to be managed in the remote source control repository. To avoid confusion, consider creating a separate web module for any custom web content, rather than rely on the ModuleName web staging module.

Non-derived files that are inside a folder marked as derived assume the properties of the parent folder; therefore, those files become derived.

An artifact's derivation properties should never be changed. If you change an authored artifact to "derived", the Integration Designer builders treat the files as generated and delete them from the workspace.

Assume that you create a Java component. When you create the component, an authored .java file is created for you. It represents the Java source code logic. After you build the application, an associative .class file is generated, containing derived properties. For a list of authored and derived files, see Integration Designer artifacts managed in source control.



Related tasks:

Manage SCA modules, libraries, and staging modules in Integration Designer

Manage integration solutions in source control


Related reference:

Integration Designer artifacts managed in source control


Team development with mediations

When you create a mediation flow, you have the option to optimize the mediation flow for team development.

By default, a new mediation flow is saved as a single .medflow file for all operations. Thus, if you have a flow with five operations, all logic will exist in a single .medflow file.

You can also choose to save the mediation flow as multiple files. In that case, you would have a .medflow file for each operation mapping. Multiple files are useful for collaborative development, because each developer can work on an operation flow without worrying about conflicts. Of course, if your mediation flow only uses a single operation, there is no benefit in enabling the team development option.

There are two practices to follow when saving mediations as multiple flows:



Use software configuration management systems

Although IBM Process Center provides the easiest repository for managing processes and services, you can also use IBM Integration Designer with a number of software configuration management (SCM) systems.

The officially supported SCM systems are Concurrent Versions System (CVS), Rational ClearCase , and Rational Team Concert™ (RTC). You can view or change the preferences for available version control systems under Window > Preferences > Team.

You can add projects to a remote software configuration management system through the Business Integration view. See the related links to topics that provide additional details about using this view.

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. When use the Team menu options you will notice the physical files do not directly map to the resources that you see in the Business Integration view. Always work from the Business Integration view when sharing a project or committing changes, so that you share or commit all the necessary resources.

Make sure your preferences always use the .project file for the project name, rather than using the folder name. Although this setting can be changed, Integration Designer modules rely on the name defined in the .project file, which is also used by sca.module, sca.modulex, and other artifacts in the module. By reading the module name from the .project metadata file, rather than from a user-defined folder, you can avoid module name discrepancies.

When setting up source control processes, you must decide whether to have everyone work off one stream or branch, or have developers working off different streams or branches. Having developers working off the same stream or branch helps to avoid concurrent development and difficult merge scenarios if the team uses reserved checkouts. This cautionary practice is particularly important if you are using Rational ClearCase with pessimistic locks (checkout reserved). However, silent checkouts of common resources can unknowingly lock files, and that can cause build failures in other workspaces.

When working in a team environment, one way of working is to allow all users to edit resources concurrently, then merge the various files later. This approach is not a good approach when working with IBM Integration Designer unless all the users are very familiar with managing the physical files for artifacts and working with their code. To help avoid overlapping changes to files, set up the repository systems to avoid concurrent modification. For example, set up ClearCase in exclusive checkout mode or use the Watch/Edit feature when using the CVS repository system.

After moving to a new workspace, be cautious of adding new files to source control. The flag indicating a file is derived can be lost after importing the files into a new workspace. See "Integration Designer artifacts managed in source control" for a guide about which files should be under source control.


Team development in Integration Designer


Manage SCA modules, libraries, and staging modules in Integration Designer

Team development with IBM Integration Designer is most effective if everyone on the team follows some basic practices.

Read about authored and derived files in "Modules and staging modules" and "Integration Designer artifacts managed in source control" (see the related links).

Artifacts created in IBM Integration Designer should be managed in the Business Integration perspective; however, they have backing files that can only be seen in Physical Resources view or the Resource perspective.



Related concepts:

Modules and staging modules in Integration Designer


Related reference:

Integration Designer artifacts managed in source control


Synchronizing with the software configuration management system

As you work with modules managed in source control, differences arise between the local and remote copies of the modules. To keep the artifacts in the local working copy and remote source control system in accordance with one another, the local workspace should be synchronized with the remote software configuration management system (SCM).

This topic applies to software configuration management systems other than IBM Process Center, which has more integrated processes than the ones described here. Actions and terminology may vary from one SCM system to another. Use the Team Synchronizing perspective to synchronize the local and remote copies and to identify artifacts that need to be committed or updated. Synchronize often to check for updates from other users. Synchronizing is especially important for core artifacts that may be used in multiple modules, such as libraries with WSDL and XSD files.

If you try to commit items that have been modified by other users, you will see a merge conflict. Although there are merge tools within the Team Synchronizing perspective, these tools are designed for traditional code such as Java™ and do not work well for XML-based business process artifacts. Merge conflicts should be handled manually.

You can only use the commit operation for modules that are already managed in source control. If you are creating a new module, use the Share Project window.

To synchronize the workspace module with the remote repository:

  1. In the Business Integration view, right-click the module name and select Team > Synchronize with Repository.

  2. Click Yes to open the Team Synchronizing perspective. A list of modified artifacts will appear in the Synchronize view.

  3. Optional: Use filters to reduce the list of modified artifacts that appears in the Synchronize view. By default, all changes and conflicts appear in the synchronization list. You can change the filter to show only outgoing changes, incoming changes, or conflicts.
  4. Commit, update, or merge conflicts through the Synchronize view. You can commit all the changes or individual changes. Right-click the module or artifact to make these changes. In CVS, a dirty flag (>) in your workspace indicates that your local copy differs from the copy in the software configuration management system. If no differences are listed, no commits or updates are needed. Although you can update or commit before synchronization, that is not a recommended practice. The synchronization wizard shows you a full list of changes that have been made in the local and remote module versions. If you commit or update these changes without synchronization, then you might overwrite critical work from other users. Avoid these problems by always synchronizing first. Furthermore, when you are working with modules that may see frequent revisions, synchronize often to verify that your local working copy is current.

    1. To commit your work to the software configuration management system, right-click either the module or artifact name and click Commit. You need to save any changes that you made in the local working copy to the remote repository before the changes take effect. When you add a project to the software configuration management system, an initial commit action saves all artifacts from the local working copy to the repository.
    2. To update your local working copy, right-click either the module or artifact name and click Update. If other users have made changes to a module that you have checked out, your local working copy is out of sync and needs to be updated. An update is effectively the polar opposite of commit-instead of pushing changes from the local workspace to the source control system, an update loads any changes from the source control system that have occurred from the time the module was checked out.
    3. Merge conflicts. There are a few options you have when merging conflicts. For traditional source code, such as Java, the best and easiest option is to use the merge utility to assist with integration from both versions of the code. However, this is not quite practical for artifacts that you developed in the Integration Designer, because they are XML-based and are usually very difficult to integrate in raw-text format. Most often these artifacts are developed using GUI tools, so performing text-based integration is risky and error-prone. If a core artifact is improperly merged, the process needed to rectify problems can be very time consuming and may adversely affect other artifacts or modules. If you absolutely need to merge Integration Developer artifacts due to conflict, make sure you keep local copies of both artifacts in case you need to revert to one or the other. If at all possible, try to avoid merge conflicts altogether. If you know that multiple users will be working with a common module or library, discuss this matter with your team and make certain that only one person will make changes to an artifact at any given time. You can also use the Lock and Unlock options in the Team menu to lock read or write access to specific modules or artifacts.
    4. To prevent multiple users from having write-access to a module or resource, set a lock on it. From the Business Integration view, right-click the module and select Team > Lock. Select Lock recursively and click OK. The module is now locked for your exclusive use. You will see pink lock icons in your workspace. When a module or artifact is locked, other users can still check out the module, but they will not be able to commit any changes until after the lock is released. When you no longer need exclusive access, make sure you unlock the module.
    5. To mark the file as merged, right-click a module or artifact from the Synchronize view and select Mark as Merged. The Mark as Merged option allows you to override the conflict markers by marking the artifact as if it is already merged. Use this option when you have manually merged the artifact in question and do not want to use the text-based compare-and-merge utility to merge conflicts. The merge-conflict indicator will be removed and the artifact can now be committed or updated, accordingly. Locking only affects write-access to an artifact. If a module is locked by one user, other users can still check out a locked module, but they will not be allowed to commit any changes until the lock is released.



Integration Designer artifacts managed in source control

In general, only the module and dependent libraries need to be managed in source control. Most generated backing files should not be kept in source control. A detailed list of the files in each category appears below.

After a module is built, Integration Designer generates Java™ code for the authored artifacts during the deployment process. Generated artifacts are usually Java classes based on the logic defined in the authored BPM artifacts.

Since the staging modules define the Java EE dependencies and optional web content, they generally do not need to be modified or kept in source control.

Artifacts and files to manage in source control

Artifacts File names
Assembly artifacts .component, .module, .modulex, .import, .export, .mon, ibm-deploy.scaj2ee, sca.module.attributes, sca.library.attributes, sca.library
Eclipse metadata .settings folder, MANIFEST.MF, .classpath, .project
Business object maps :map, .xsl, .xsl.smap
Business processes .bpel, .bpelex, ProcNameArtifacts.wsdl, ProcName_bpel.mon
Business rules .brg, .brgt, BRGName_brg.mon, .ruleset
Business state machines: (Note the underlying .bpel file for the state machine is generated during application installation, and therefore not managed in source control.) .sacl, .saclex, BSMName_sacl.mon
Data types (business objects) .xsd
Human tasks .tel, .itel (inline task only), HTName_tel.mon
Interface maps .ifm, IFMapName_ifm.mon
Interfaces .wsdl
Mediations .medflow, .mfc, .mfcex
Relationships .rel, .rol
Selectors .sel, .selt, SelName_sel.mon
Solution projects .project, projectSet.psf, solution.graphml
Visual snippets You can choose to manage the deployment of the generated .java files, in which case they should be stored in your source control system.


Files that should not be placed in source control

Staging modules appear in the workspace after the SCA module is built. Because of this timing, staging modules do not need to be managed within the source management control system as long as they contain no custom content. The staging modules are named according to the following formula:

In general, it is not advisable to add authored content to a staging module. Do not add custom content, such as HTML or JSP pages, to the web staging module. To avoid confusion, create a separate web module for any custom web content, rather than rely on the ModuleBaseNameweb staging module.

Do not keep the Eclipse metadata .runtime file in source control. It can cause the migration wizard to fail.



Related concepts:

Modules and staging modules in Integration Designer

Work with ClearCase


Related tasks:

Manage SCA modules, libraries, and staging modules in Integration Designer

Manage integration solutions in source control


Physical Resources view: The .settings folder

You could find unexpected changes in a module or library due to changes in the .settings folder.

When you check out files from a repository, a clean build might show these files have changed when, in fact, the content has stayed the same. For example, this change indicator occurs when a module contains a BPEL business process or a business object map. It occurs because the time stamp changes on the org.eclipse.core.resources.prefs file in the .settings directory during a clean build. There is code in IBM Integration Designer that ignores the changes to the .settings folder in the data used by the Build Activities view, but the server marks these changes. This difference in behavior results in a distinction where a module might show as "Synchronized" in the Build Activities view but "Republish" in the Servers view. The Build Activities view is correct; you do not need to republish.

You can access the .settings folder from the Physical Resources view. The .settings folder contains properties that are used by IBM Integration Designer and should be shared with each project. For that reason, the .settings folder should be added to team repositories. Some settings made to this folder will be updated during a clean build. Therefore, running a clean build on certain projects will cause outgoing changes in this folder. Changes made to this folder can be safely committed when outgoing changes are detected.



Related concepts:

Perspectives and views for team development in Integration Designer

Work with ClearCase


Related tasks:

Use CVS with Integration Designer and Process Center

Sharing your integration project through CVS

Associating a module or library with a process application or toolkit

Disassociating a module or library from a process application or toolkit


Manage integration solutions in source control

Although integration solutions have no deployable logic, you can still manage them in source control like any other project.

Solutions should not be used if you are working with the IBM Process Center. Process applications and toolkits serve a similar purpose as solutions do. Integration Designer provides integration solutions, which are non-deployable projects that allow you to logically reference related modules in a workspace. You can add SCA modules, mediation modules, libraries, and Java™ projects to a solution. The integration solution diagram shows the invocations and relationships that exist among the modules. Additionally, there are a few options in integration solutions that allow you to streamline some team development tasks.

  1. To add projects to the integration solution:

    1. Right-click Project References and select Add or Remove Project References.

    2. In the Add or Remove Project References window, select the modules that you want managed in the software configuration management system. Click OK to save the changes.

  2. To check out an integration solution from source control, right-click Project References and select Check Out Referenced Shared Projects.



Related concepts:

Modules and staging modules in Integration Designer


Related reference:

Integration Designer artifacts managed in source control


Sharing your integration project through CVS

IBM Integration Designer provides the capability to develop applications in a team environment using Concurrent Versions System (CVS).

Through Eclipse, Integration Designer provides a client for the Concurrent Versions System (CVS). This topic explains how to share a project with a CVS repository.

The Business Integration view includes team development support for the following operations:

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. When use the Team menu options you will notice the physical files presented in the Synchronize and CVS Repositories views do not directly map to the resources that you see in the Business Integration view. Always work from the Business Integration view when sharing a project or committing changes, so that you share or commit all the necessary resources.

You can also refer to a technical paper on the IBM developerWorks site, Team development with WebSphere Integration Developer and WebSphere Process Server: Developing applications using CVS.

The topics that follow illustrate the basic steps to share a project when working in a CVS environment.

  1. Before you can share a project with a CVS repository, you need to add the repository to the CVS repositories view.

    1. Switch to the CVS Repository Exploring perspective, right-click and select New > Repository Location.

    2. In the Add CVS Repository wizard, enter the location, authentication, and connection information.

    3. Click Finish.

  2. In the Business Integration view, select the module or library to share, right-click, and select Team > Share project.

  3. In the Share Project wizard, Select CVS as the repository type, and click Next.
  4. Choose to use the existing repository connection that you created previously and click Next.
  5. Choose to use the project name as the module name and click Next. Never rename the module when placing it in CVS. The SCA.module file depends on the module name.
  6. The next page shows you the project that is to be shared. Expand the project to view the physical files within it. The decorator showing an arrow with a plus sign indicates the file is new, and does not exist on the server. Select the project and click Finish. A version of the module including all its resources will be created in the shared repository.

After the project has been added to CVS control, new team actions are available in the pop-up menu. Among other tasks, you can use those actions to synchronize with the repository, commit changes to the repository, and update your local workspace. The examples that follow provide additional information about these actions.


Example

The following examples illustrate how to commit changes, check out a project from the shared repository, receive changes into your workspace, compare files, and resolve conflicts.

Committing changes

Suppose you have made some changes to a shared module, DataMergeModule. In the assembly diagram, you added a BPEL process named TransferFromBrokerageToBankProcess and connected it to two new Java™ components. The Java components are implemented as Component1Impl and Component2Impl. After the assembly diagram is saved, the Business Integration view shows a > decorator beside the three changed resources: DataMergeModule, Component1Impl, and Component2Impl.

Before committing your resources, you should always synchronize the project with the repository to see the resources that have changed in the local workspace and in the repository. Select the project, right-click and select Team> Synchronize with Repository. The Synchronize view shows the physical files in the module. Change decorators indicate the changed files.

Switch to the Physical Resources view. This view also shows the changed physical files, indicated by a > decorator.

Always add or check out complete modules to or from CVS, rather than individual folders or artifacts. To commit your changes, work from the Business Integration view. Select the module, right-click, and select Team > Commit. Commit updates CVS with a new version of the file. If there are conflicts, you have the opportunity to see and resolve them.

When you delete an authored file from your local workspace and synchronize with CVS, you will see a minus sign (-) beside the artifact, indicating that you are deleting the artifact from the server.

The commit process uploads an empty file structure to CVS, even though all the files in the folders are derived. Empty folders are pruned by default when you extract a module. You might see an error message for a missing gen/scr directory. You can ignore the message. CVS flags the omission if the directory is missing, but the gen/scr directory is optional.

Checking out a project from the shared repository

When you check out a module from CVS, you are extracting the entire service module, so you do not need to create a shell module beforehand. The entire project structure that is in CVS is mirrored in your Business Integration view, except that each entry from the SCM has the label CVS in brackets after it.

Before you check out a project, synchronize it to view changes that another team member may have made to the server version of the project. Select the project from the Business Integration view, right-click, and select Team > Synchronize. The left facing arrow beside a file shows that it has changed in the shared repository. Always synchronize with the repository before you commit changes.

To check out a project, switch to the CVS Repositories view, select the project, right-click and select Check Out. Check out dependent libraries to use artifacts from them.

Receiving changes into your workspace

Use the Update command to check CVS for changes that others have provided and update your local files if changes are found. The Update command places new remote versions of files in your local workspace. Always synchronize before you update your files. Be very cautious about using Update with override, which replaces local files without warning about conflicts.

You might see an error message for a missing gen/scr directory. You can ignore this message or get rid of it by disabling the directory pruning option. From the menu, select Window > Preferences > Team > CVS. Clear the Prune empty directories option. Click OK.

Comparing files

To view the difference between the local and remote files, you can open the files in the Compare editor. In the Synchronize view, select a file, right-click and choose Open in Compare Editor. The remote and local files will open in a text editor, with the changes highlighted.

Conflict resolution

If two members of the team check out the same module, make changes to the same BPEL process or service, and check in their changes, a conflict occurs. Try to avoid conflicts by synchronizing often and by trying to ensure that only one person works on a component at a time or assigning ownership of each component to a developer.

Conflicts can be difficult to resolve if a user is unfamiliar with the artifacts because conflict resolution takes place at the level of the XML structure of the underlying files. It is usually better to update with a new version of the artifacts and integrate your changes in the new copy than it is to try to merge conflicts in the XML.

Some files can be flagged as out of sync when they appear to be identical. This condition can occur if the files have different timestamps. Use the Clean Timestamps option in to automatically get rid of these problems.



Related concepts:

Work with ClearCase

Perspectives and views for team development in Integration Designer

Physical Resources view: The .settings folder


Related tasks:

Use CVS with Integration Designer and Process Center


Use CVS with Integration Designer and Process Center

This topic shows you how to perform common tasks using IBM Integration Designer with IBM Process Center and a traditional software configuration management (SCM) system. If you are using Integration Designer with Process Center, you are either storing your projects in Process Center or storing them in both Process Center and an SCM system. The latter case is likely to apply if you were working with earlier versions of WebSphere Integration Developer for several reasons:

Work with two repositories introduces additional complexity to the governance system, but those can be addressed by careful planning. These instructions will help you manage that configuration successfully.

Although this topic addresses working with Concurrent Versions System (CVS), the principles also apply to other SCM systems. For more information about working with CVS or other SCM systems, see the related links at the end of this topic. You can access actions for source control management system clients that you have currently installed from the Integration Designer Business Integration view by right clicking a project and opening the Team menu.

Eclipse only allows one SCM to be associated with a project. If you use Process Center with another SCM system, treat Process Center as a secondary repository. The SCM system is the primary storage area used by the developers as they work with their artifacts. Load projects to the Process Center intermittently, perhaps at project milestones. Do not check projects out from Process Center to make changes.

Because you work from CVS, artifacts such as business process definitions, which are solely associated with Process Center will not exist in the CVS repository.



Related concepts:

Work with ClearCase

Perspectives and views for team development in Integration Designer

Physical Resources view: The .settings folder


Related tasks:

Sharing your integration project through CVS

Associating a module or library with a process application or toolkit

Disassociating a module or library from a process application or toolkit


Work with ClearCase

You can use Rational ClearCase as a software configuration management (SCM) system for projects created in IBM Integration Designer.

The ClearCase Remote Client (CCRC) is not packaged with Integration Designer. To install it, switch to the Java™ EE perspective and follow the instructions in this technote: Install or updating CCRC for Eclipse and RSA.

During the installation, a security warning window-box might open because the client .jar files are not signed. If this happens, click OK to complete the installation.

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 Use software configuration management systems. For ClearCase documentation, see the ClearCase information center. For more detailed instructions and best practices for using Integration Designer with ClearCase, see a presentation from Joef Huang, Use of ClearCase in WebSphere Integration Developer. The product name has changed, but the instructions and advice are still relevant.

To use Integration Designer with ClearCase, you need to have the following prerequisites in place:

There are two ways to use ClearCase with Integration Designer. Inside Integration Designer, use the ClearCase remote client for Eclipse plugin and the ClearCase SCM adapter plugin. Outside Integration Designer, use ClearCase Explorer and ClearCase Remote Client Standalone. The latter method is preferable in most circumstances. If you have a ClearCase or ClearCase LT server installed on the same machine as Integration Designer, the ClearCase server can also act as a client.

Integration Designer provides capabilities that can be activated for developers working in teams. The core team capabilities and CVS capability are enabled by default. The most common Integration Designer support for ClearCase usage is provided through the ClearCase SCM adapter plug-in that is included with Integration Designer. If you install the Rational ClearCase Adapter, an additional capability appears in the list. To use the adapter, you need to enable this capability by selecting Window > Preferences > General > Capabilities > Advanced > Team > ClearCase SCM Adapter.

You can use Rational ClearCase to manage a team's software development process using either of two models. 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. When use the Team menu options you will notice the physical files presented in the Synchronize and Repositories views do not directly map to the resources that you see in the Business Integration view. Always work from the Business Integration view when sharing a project or committing changes, so that you share or commit all the necessary resources.

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.


Handling files with the same base names

The ClearCase client has a particular way of dealing with files that have the same path and base name, but slightly different extensions. When this situation is encountered, only the file with the longer file name can be added to version control. This behavior may result in BPEL or BSM source files not being added to ClearCase when you are attempting to add a module to source control.

To counteract this behavior, open the ClearCase plug-in menu and search for resources to add to source control. ClearCase will, at that point, have a list of items that can be added.


Configure ClearCase to allow it to check in identical files

When you check files into ClearCase, configure ClearCase to allow it to check in identical files.

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.

On Windows, you can globally enable the Checkin even if identical preference from any IBM Integration Designer perspective. Select Window > Preferences > Team > ClearCase SCM Adapter > Advanced Options > Operations to enable that preference.

On Linux, the option is provided on the check-in window itself each time files are checked in.


More configuration hints

If you are using the ClearCase SCM Adapter plugin, do not set the checkout preferences to "Do Nothing." You can check this preference under Window > Preferences > Team > ClearCase SCM Adapter.

If you are using the ClearCase SCM Adapter plugin, enable the hijack preference to work disconnected from ClearCase. Select Window > Preferences > Team > ClearCase SCM Adapter > Hijack in snapshot views when disconnected. You can convert hijacks to checkouts after reconnecting.

If you are using ClearCase Remote Client (CCRC), select Window > Preferences > Team > ClearCase Remote Client > Dialogs > Undo the checkout if the version is identical to its predecessor.

If you are using ClearCase Remote Client (CCRC), you can keep the default checkout set to "reserved" for a more pessimistic strategy. To do that, select Window > Preferences > Team > ClearCase Remote Client > Dialogs > Checkout > Always reserved.

Some CCRC versions have a ClearCase > Work Disconnected menu item. For other versions, select Window > Preferences > Team > ClearCase Remote Client > Workspace > Hijack only if disconnected to work disconnected from ClearCase.


Update 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. To properly update all assembly artifacts from the ClearCase repository, right-click the name of the module in the Business Integration view and select Team > Update. This action will ensure that all assembly artifacts are updated, including new or deleted ones. (Do not update from the Assembly diagram node in the Business Integration view.)


Troubleshooting

What information would you need if you are seeking help from a customer service representative? This list will help you answer that question.


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 starting 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.



Related concepts:

Physical Resources view: The .settings folder


Related tasks:

Use CVS with Integration Designer and Process Center

Sharing your integration project through CVS


Related reference:

Integration Designer artifacts managed in source control

Associating a module or library with a process application or toolkit

Disassociating a module or library from a process application or toolkit


Install Rational Team Concert into the workbench

You can use the p2 installation method to install Rational Team Concert Client v2.x into the same workbench as IBM Integration Designer. You can use IBM Installation Manager to install Rational Team Concert Client v3.x. You can use the installation method described in the procedure to install Rational Team Concert Client v2.x into the same workspace as IBM Integration Designer.

If you are installing Rational Team Concert Client v3.x, follow the instructions inthe Rational Team Concert information center. However, be aware that use the same version of Installation Manager to install Rational Team Concert as you used to install Integration Designer.

  1. Open the Installation Manager that references your IBM Integration Designer installation.
  2. Follow the Rational Team Concert Client 3.0 installation instructions to add the path to the repository location.
  3. Install Rational Team Concert Client 3.0 to the same package as Integration Designer.

  1. From https://jazz.net, download a "p2 Install" edition of a version of Rational Team Concert Client for Eclipse that is compatible with IBM Integration Designer. For Rational Team Concert Client v2.x, use this method; using IBM Installation Manager to install into the same workbench as the IDE is only supported for version 3.0 and later.
  2. Extract the contents of the compressed file that you downloaded. For example, extract the contents to C:\RTC. Ensure that you preserve the directory structure of the extracted contents.

  3. Start Integration Designer.

  4. Click Help > Install new software.

  5. In the Available Software wizard, click Add.

  6. In the Add Repository window, beside the Name field, click Local and then look for the rtc-p2-repository subdirectory of the directory where you previously extracted the compressed file, for example, C:\RTC\rtc-p2-repository. Click OK.

  7. On the Available Software page:

    1. In the Name section, select Rational Team Concert and, optionally, one or both NLS categories to install language packs.

    2. In the Details section, ensure Group items by category and Contact all update sites are selected.

  8. Click Next, and click Next again on the Details page and on the Install Details page.

  9. On the Review Licenses page, read the text of the license agreements. If you agree to the terms of all of the license agreements, select I accept the terms of the license agreements and then click Finish.
  10. During the installation, a security warning window-box might open because the Rational Team Concert Client bundles and features are not signed. If this happens, click OK to complete the installation.
  11. When you are prompted to restart at the end of the installation, click Yes. When the workbench restarts, the Rational Team Concert Welcome page opens.


If you used this procedure to install Rational Team Concert Client into the same workbench as IBM Integration Designer, then you must manually enable the workbench capabilities for Rational Team Concert Client:

  1. Click Window > Preferences.

  2. On the Preferences page, expand General and click Capabilities.

  3. On the Capabilities page, click Advanced.

  4. In the Advance Capabilities Settings window, expand Team, select Jazz Source Control, and then click OK.

  5. On the Capabilities page, click OK.


Rational Team Concert 2.0 information center

Rational Team Concert 3.0 information center


+

Search Tips   |   Advanced Search