Integration
Start Menu Path: Module Menu / Configuration Mgt / Integration
Function: Integration provides a merge method to pull changes from one stream into another stream. This provides a strong structure merge facility that is recommended for most merge events. It is implemented as a three way merge using the common parent from the branches to assess the differences. See also Merge Concepts.
If the "Integration" is started from a module that already has an active Integration, then the integration is resumed. Otherwise a new integration is started.
Starting an Integration
An Integration is initiated from the target module, i.e. the module that shall receive the changes. By selecting integration, the user is presented the option to configure the merge event with the following GUI:

The options are as follows:
- Integration from
Here the source branch can be selected. The source branch defines the location from which the changes are taken. The parallel module in the source branch will be determined automatically. The tool will also calculate the common base between the current module and the parallel module in the source branch.

- Common Base
This value is automatically calculated and shows the last baseline in history that the source module and the target module share. See also Merge Concepts.
- Source Module
This field shows the parallel module that was determined in the selected source branch.
- Source Version (see Merge Concepts)
Here the user can select the source module for the integration, i.e. the module up to which changes should be considered. The source base is either the common base or the integration baseline selected depending on the selection in the radio button. These two settings (source module and source base) determine the changes that should be taken into account when performing the integration. Note that when a 'current' version is chosen as the source module, then the source module must be baselined when finishing the integration. This is not necessary when choosing a baseline for the source module. Also it should be considered if integrating from a current version is really wanted, since especially when the integration is performed over a longer period of time, changes in the source module can yield to confusing effects and conflicts in the integration.
- Source Base (see Merge Concepts)
The Source Base can be either the Common Base in which case all changes since branching the modules will be considered for integration, or any recent integration baseline that was created due to an earlier integration between both modules. Note that the normal use is here to use the common base for the first integration and the most recent integration baseline for all further ones. However it can be desirable to go back to an earlier integration or the common base to merge changes that have not been merged on earlier integrations.
- Start Integration - this button starts the integration. On starting the Integration, the integration parameters must be specified.
Integration Parameters
When starting an integration, the user will also have the option to select the changes that should be considered for the integration. It might, for example, not be desired to integrate hierarchy changes to the objects or links or certain attributes in all cases.
Executing the Integration
The merge is directed via the Integration GUI:

Additionally, in the target module (i.e. the module from which the integration was started) an Integration view is created that shows the information about the changes in different columns. Using this view, changes can be viewed in the context of the surrounding requirements. It is therefore advised to have the target module and the Integration GUI side by side during the integration. A second monitor is very helpful in organizing the overview during integration.
The GUI consists of the following elements:
- Navigation buttons - The four buttons "Open Source", "Open Source Base", "Open Target" and "Open Target Base" allow the user to bring the corresponding module to the foreground. If the module is closed, it will be reopened. Note that the modules can be closed or minimized to keep a better overview. On the right side of the button, the full name and version of the modules is shown.
- List of Changes tree view - This tree view shows all differences that were detected on the comparison of the Source Base and Source module. It is important to understand that only the changes in the source module are shown. The changes that have been applied to the target module only matter for conflict detection in the integration. The list shows the object identifiers and a short annotation for each object that shows the type of changes that have been applied to the object. If multiple types of changes have been applied to the object, then each change will be listed in the List of Changes below the object.
Hint: By double-clicking on a change, all opened modules will navigate to the corresponding object. This way a change can be quickly localized in the module.
Non Conflicting Changes vs. Conflicting Changes:
The problem when merging hierarchies is that changes can depend on each other to be merged (see Understanding Object Merges). The Integration GUI tries to remedy this problem by evaluating those hierarchy conflicts in advance and showing the objects that cannot yet be merged under the "Conflicted Changes" tree part. On every merge, the tool reevaluates the conflicts and moves changes that are not conflicted anymore (because dependent changes have been merged) to the "Non Conflicted Changes" part. By doing this, trial and error for the correct order of merges is not necessary.
- Changes in the source module - this text field shows the difference for the changes to the object / change that has been selected in the List Of Changes.
- Conflict Information - this text field lists the differences in the target module to the same object, which account for change conflicts and other conflict information.
- Merge Selected Changes - this button will merge the change that was selected in the List of Changes to the target module. Note that if an object is selected, then all changes of that object will be merged to the target module. After merging a change, the conflict potential of the change is evaluated and some changes might move from being conflicted to not being conflicted anymore, since the merged change was a prerequisite to merging the other changes. When the last change on an object is merged, the object is removed from the List Of Changes and the 'BranchManager Last Integrated On' attribute is set to the current date/time (see 'Continue Later Button'). When trying to integrate a conflicted change, the tool will require a confirmation before overwriting the target module values.
- Merge All Non Conflicted - this button can be used to Merge at once all 'Non Conflicted Changes' in the List Of Changes to the target module. All changes will be automatically integrated, so a confirmation dialog box will appear before beginning the 'Merge All'process.
- Mark Object as Integrated - this button can be used to indicate that the remaining changes on the object shall NOT be merged. Note that this affects all unmerged changes of the object. So this button shall be used after all relevant changes on the object have been merged. After pressing the button, the object is removed from the List Of Changes. The 'BranchManager Last Integrated On' attribute is set to the current date/time (see 'Continue Later Button').This can also be necessary after manually resolving a conflict.
- Abort Integration - This button can be used to abort the integration. Abort, present's user with choice of how to close the target module (Save any merge changes and close, Close without saving, Leave open in unsaved state)
- Finalize Integration Button - This button will trigger the creation of an integration baseline and finish the integration.
- Save and Continue Later - This button allows the user to close the integration GUI, save and close the target module and continue at a later time. All changes that have already been processed will not show up in the list of changes. This is achieved using the value of the 'BranchManager Last Integrated On' attribute. If the last time the object was integrated is later than the last modification time of the source object, the object will not be shown in the list of changes. This way, when integrating from a current version of the source module, an object that has already been "Marked as Integrated" will show up again if it is changed afterwards. The last modification date of the object will be larger than the last integrated on date.
Note: This will only work with changes that actually trigger the modification date of the source object. In settings where this is a problem, it is advisable to integrate from a baseline of the source module instead of the current version.
- Settings - This allows the user to change the integration parameters for the current integration. Note that changes only take effect after restarting the GUI or pressing the 'Refresh All' button.
- Refresh All - This button will recalculate the comparison for the integration. Note that performance might degrade when pressing this button often, so it is advised to use this button seldom, or instead, close and reopen the GUI.