The purpose of this article is to explain the steps necessary for merging two or more Knowledge Bases using Module Objects.
Merging Knowledge Bases is now easier, since with the Modules feature, the value of an object’s Name property must be unique among all objects in the Module, though it may be repeated in a different Module.
Note: remember to back up your Knowledge Bases before making any changes to them.
Step 1 - Creating the Knowledge Base#
Step 2 - Creating the Module organization#
For each of the remaining Knowledge Bases:
- Open the old Knowledge Base and export all the GeneXus objects necessary. An .XPZ file will be created containing these objects.
This is a good opportunity to get rid of unused objects. We recommend cleaning up the Knowledge Base before exporting its objects, or exporting only used objects.
- Open the new Knowledge Base—where the merge is being performed—and create a new Module Object for containing the exported objects.
- Import the .XPZ file generated before in the Knowledge Base where the merge is being performed.
- Move all imported objects to the new Module Object—read HowTo: Adding an object to a Module.
When this process is over, the Knowledge Base will have a new Module organization, where each Module Object will contain all the GeneXus objects of every Knowledge Base that needed to be merged.
Step 3 - Defining Module Interfaces#
After defining the Module organization, the process that will define each interface begins, since most of the Knowledge Bases being merged did not use the Modules feature. This process will determine how Modules should interact with one another.
In defining the interface, you should bear in mind that its main purpose is to protect other Modules from the effects of the significant modification of objects, and the internal design decisions made in the Module, as well as to provide the services required.
See article Modules - Defining an interface for recommendations on how to define a Module interface. Also, read the article Module - Parallel Transactions and Object Visibility to better understand how parallel transactions will behave when we use Modules.
Step 4 - Defining interaction between Modules#
To have things clearer, it is best to maintain the interaction between modules to the minimum. Use the Module Diagram for a clearer view of relationships between Modules, and then proceed to fine-tune the interaction.
Step 5 - Defining a Module organization for each new Module#
Since most of the Knowledge Bases merged did not use the Modules feature, it is highly recommended that you arrange the inner structure to also use the Modules feature. In the future, this will help keep maintenance and development as simple and fast as possible. Below are the steps required to achieve that:
- If the Knowledge Base was organized using Folder objects, then an initial approach would be to convert those Folders into Modules — read HowTo: Convert a Folder into a Module.
- Arrange objects by the type of service they provide, where the same 'type' should belong to the same Module.
Step 6 - Continuing development work#
Done! Now your Knowledge Bases should be merged, so that you may continue developing new services. By using the Modules feature, you may increase your development speed while keeping maintenance simple.