Using the Merge Tool
How to Send a Merge List to Someone Else- Start the merge tool
- Drag and drop the objects from your Framework that you want to send into the merge list. For example, you might drag and drop the 3 new business object filters that you have added to your Framework.
- Use the Save to File button.
- From the Merge Files Tab select the file that was saved and drag and drop it into the place that will be used by the recipient to receive it. For example, to a shared network drive, or into an e-mail message, etc.
How to Receive a Merge List from Someone Else
- Start the merge tool
- Switch to the Merge Files Tab.
- Drag and drop the merge list file you received into the Merge folder (for example from an e-mail message, from a shared network drive, etc).
- After a few seconds the Merge Tool will prompt you to open the file you have just dropped. Click Yes. The contents of the merge file will then be displayed in the Merge List – Selected Items and Merge List – Associated Reference Items areas.
- Select the objects to be merged into the current Framework from the Merge List areas by clicking on them. Then click on the Merge Selected button. Use the Merge Options tab to control how they are merged into your Framework.
- Remember that you can and should be selective about what you merge. You do not have to merge in everything that someone has sent you.
- All Framework items (or objects) are uniquely identified by a GUID (Global Unique Identifier). Theoretically a GUID is a 32 character identifier that is unique in space and time. No two GUIDs are ever the same. This means if that developer A creates a business object captioned "Customer" and developer B creates a business object captioned "Customer" they are not the same Framework object. They are two completely separate business objects that just happen to have the same caption. In the Merge List display area is a column titled "Currently Exists". This indicates whether an object of this type with this GUID currently exists in your Framework.
- The benefit of the GUID approach is that objects from any two Frameworks in the world can be merged without risking object or property duplication.
- The downside is that two developers at the same site cannot create a single object if they both create an object of the same type with the same caption because the GUIDs of these two objects will be different.
- The preceding points mean that the optimal project work flow model is probably one where the main designer always creates new high level "container" objects such as applications, business objects, 5250 RAMP sessions, etc. These are then sent out to the individual project developers, who then extend and enhance them as required, sending back their alterations periodically. This way all the high level container objects being used all have the same GUID (ie: they are actually the same object) which makes merging them simpler and easier to manage.