Using Siebel Tools > Using Workspaces in Siebel Tools > Using Workspaces in Siebel Tools >

Detecting Conflicts in Workspaces and Applying Resolutions

In a development environment where multiple users work in parallel making configuration changes concurrently in their own private workspaces, conflicts might arise when the same objects and attributes are modified by different users in their own private workspaces, and then the changes from these users are delivered to the main branch. These situations often lead to non-trivial merges because of the conflicting changes between different users.

For workspaces, the system detects the possibility of conflicts prior to workspace delivery. If conflicts or errors are found, the system displays the issues along with the default resolutions. You must review the conflicts and apply the resolutions to resolve the issues.

In other words, during the rebase workspace process, the system enables you to:

• Identify the conflicts by viewing the conflict flags on the attributes. Notice that some conflicts must be explicitly resolved before you can submit the workspace for delivery again.
• Identify the errors by viewing the status message of the objects or attributes.
• View the status message that describes the error or conflict in details for each object or attribute.

If the system cannot resolve the conflict or the delivery process encounters an error while merging the changes, an error message appears. Although an attempt is made on all objects, the overall delivery process fails even if a single error is encountered.

NOTE:  Overriding the default resolutions is only permitted while the status of rebase is Pending Resolution. After the status changes to Finished, modifications in the Merge Conflicts dialog box will not be applied.

TIP:   For further analysis on errors for Siebel Tools and the Mobile Web Client, see the log file under Siebel/log: WS_REBASE_<wsname>_<rebase attempt number>.log. For Siebel Web Client setup of Web Tools, the log file is available in the standard Siebel log with the minimum loglevel2.

Conflicts and errors can be broadly categorized as:

• Attribute-level conflicts and errors.

  The default resolutions for the attribute conflicts can be overridden by selecting the Override option. You must select the Override option with caution because you might overwrite other users' changes that were already checked into the MAIN workspace. If you select the Override option by mistake, then you can clear it to resolve the issue.

  Errors can happen on attributes when the merge process is unable to set the correct value. Common errors are when there are inconsistencies in the repository and a foreign key is missing.

  You can analyze the error further by viewing the appropriate log files.

• Object-level conflicts and errors, which are name conflicts, object inactive conflicts, and index violation errors.
  • Name Conflicts

    A name conflict occurs when there are two different objects of the same type that have the same combination of name and parent ID. A potential violation of user key is detected as a result of the rebase operation, and the merge process selects a default resolution of renaming the object that belongs to the child workspace by appending the string -[Rebase]. Both object and name attribute are marked with a conflict flag in the Merge Conflicts dialog box.

    If a name conflict is not resolved, then subsequent delivery fails by identifying the system-generated name. This conflict cannot be resolved by selecting the Override option, but you must finish the rebase process and resolve it in either one of the two methods described in this example:

    • Suppose that both User1 and User2 branch from MAIN/5 and create their workspaces WorkSpace_U1 and WorkSpace_U2, respectively.
    • User1 renames and creates a new business component with the name NewBC123. This user then delivers changes to the MAIN workspace by creating a new version MAIN/6.
    • User2 is unaware of User1's changes, so he renames and creates a new business component with the same name, NewBC123, in WorkSpace_U2/1.
    • User2 cannot deliver his branch before starting a rebase process because this is a non-trivial merge.
    • Upon doing a rebase, the merge process detects that there is a name conflict, so it renames the object in WorkSpace_U2 to NewBC123-[Rebase] and issues a conflict flag for this object in the Merge Conflicts dialog box.

      To resolve this conflict, both users can intend to either create two different objects or create the same object being duplicated, as in these cases:

    • Case-1: Two logically different objects. In this case, both users can click the Finish button to finish the rebase process, navigate to the corresponding object in the Object Explorer pane, and then re-name the object to a valid name; for example, NewBC123_ProjA.
    • Case-2: The same object being duplicated. In this case, both users have duplicated the same record because they were not aware of the changes made by the other. Neither user should perform the RevertObject operation from the WorkSpace_U2 branch at this point. Instead, to enable the objects to merge appropriately, User2 should finish the rebase process, open WorkSpace_U2/1 version explicitly, navigate to the NewBC123 workspace and perform a Siebel Archive File (SIF) export, and open the WorkSpace_U2 branch and import the SIF file back into the repository. Subsequently, both users must perform the RevertObject operation or inactivate the NewBC123-[Rebase] business component.
  • Object Inactive Conflicts

    An object inactive conflict occurs when the target workspace being rebased has a change to an object that is inactivated in the source workspace. Even if the source workspace has an inactive parent object, this conflict is still alerted to let users know that the change that is made in the workspace will not be applied at runtime because either this object or its parent is inactivated.

    Users can either ignore this conflict or resolve this conflict by checking the Override option for the Inactive attribute.

    For example:

    • Both User1 and User2 have branched from MAIN/5 and created their workspaces WorkSpace_U1 and WorkSpace_U2, respectively.
    • User1 inactivates the contact business component and delivers this change to the MAIN workspace by creating a new version MAIN/6.
    • User2 modifies the account status Field by making it force active. He then tries to deliver this change to the MAIN workspace, but the system enforces a rebase.
    • On rebase, the merge process detects that the changes on the account status Field are no longer applied as the parent contact Business Component is inactivated. Hence a conflict is logged against the contact Business Component and the corresponding inactive attribute.

      To resolve the conflict, users can select the Override option for the inactive attribute on the contact Business Component.

  • Index violation errors

    An index violation error conflict occurs when there are two different objects of the same type having the same combination of contents. A potential violation of the index is detected as a result of the rebase and the merge process cannot select any resolution. Hence the system displays an error on the object and fails the rebase process.

    Users must fix this error either by manually modifying the fields involved in the index or by performing the RevertObject operation on the object (on a single version or the entire workspace). This fix ensures that there is no longer a violation and then users can run the rebase process again.

    For example:

    • Both User1 and User2 have branched from MAIN/5 and created their workspaces WorkSpace_U1 and WorkSpace_U2, respectively.
    • User1 modifies and creates a Workflow Policy Component Column with these attributes: Name - 'NewCompCol', Workflow Column Name - 'COL1', Workflow Object Name. This user then delivers this change to the MAIN workspace by creating a new version MAIN/6.
    • User2 modifies and creates a Workflow Policy Component Column under the same Workflow Policy Component with these attributes: Name - 'AnotherCompCol', Workflow Column Name - 'COL1'.
    • During the rebase process, the merge process detects the possibility of a unique key violation on the index involving the field Workflow Column Name (Workflow Column Name, Workflow Object Name). The object is marked with the key violation error in the Merge Conflicts dialog box.

      To resolve this conflict, User2 must perform either of the following resolutions to resolve the error and ensure that there is no longer an index violation, and then perform the rebase process again.

    • Case-1: Modify the index-based fields. User2 modifies the Workflow Policy Component Column name from COL1 to COL2 on the AnotherCompCol object.
    • Case-2: Run the RevertObject process. User2 runs the RevertObject process on the AnotherCompCol object either for a single version or for all versions in the workspace.

To view the merge conflicts and resolutions

1. In the workspace dashboard, select the Workspace menu and then select the Merge Reports option.

   The Merged Workspaces pane appears with the following sections:

   • The Merged Workspaces section displays the status of merge, resultant version, base version, From version, and To version of the merge process.
   • The Object Differences section displays the object name, object type, top-level parent name and type, and the status of the selected object after the merge process is completed.
   • The Attribute Differences - Critical Conflicts section displays the attribute information including the workspace resolution, base version value, To and From version values, conflict, override, and so on.
2. (Optional) Select the Override flag to override the default workspace resolution.
3. Click the Finish button to complete the merge process.

   Alternatively, click the Cancel button to cancel the merge process.