IBM InfoSphere® Master Data Management Server provides a complete data model for Party, Account and Product master data, and a large number of services (known as transactions) for querying and modifying master data records. A variety of extension mechanisms are supported to allow the data model and transaction behavior to be customized or to add completely new transactions if required.
MDM Server includes MDM Server Workbench, tooling that supports development of extensions to MDM Server. The workbench allows you to define the desired data model and transactions and generate the code required to implement the MDM Server extensions.
MDM Server Workbench is installed as an add-on to Rational® Application Developer (RAD). To develop extensions to MDM Server, you need to import into the RAD workspace the MDM Enterprise Application Archive (EAR).
The default development environment setup results in a large number of projects being created in the workspace. Fifty-five projects are created when importing the MDM EAR, and you may be creating a number of additional projects for extensions.
The large number of projects in the workspace can be confusing and adds to the overhead of building the code, managing it in source control, and deploying the code.
In this article, I will describe how you can reduce the number of projects in the workspace by changing some of them into binary modules. The instructions given here apply to the MDM Workbench with MDM Server 9.0.1 (WebSphere® version) on RSA 188.8.131.52. If you have different versions, the approach should still work, but there may be some differences in the user interface.
Development environment setup
Use the MDM Workbench Development and Test Environment Setup wizard to set up your development environment. After setup, you will have 55 projects in the workspace. Some are used for the initial setup of the MDM Server, but are not part of the MDM EAR. You do not need to have them in the workspace once the development environment is set up.
Once you are satisfied that your development environment is set up correctly and the Install Verification Test is passing, you can close the following projects:
- InstallVerification — This project contains the Install Verification tool used by the Development Environment Setup wizard to run the Validate Installation task.
- ManagementAgent — This project contains the ManagementAgent tool used by the Development Environment Setup wizard to run the Deploy Configuration task.
- ManagementConsole — This project contains the ManagementConsole tool used by the Development Environment Setup wizard to run the Deploy Configuration task.
- MDMDatabase — This project contains the database creation scripts used by the Development Environment Setup wizard to run the Create Application Database task.
Closed projects remain in the file system, but are by default not visible in the workspace. You might need to reopen these if you need to repeat part or all of the setup process later.
Filtering content in the workspace
To control whether closed projects are visible, use the Customize View menu item in the Enterprise Explorer view (to access the menu, click on the small down arrow in the View toolbar).
Figure 1. Customize View menu item
Items checked in the Customize View dialog are not visible in the Enterprise Explorer view.
Figure 2. Customize View dialog
If you are using the Project Explorer, Navigator, or Package Explorer views instead of the Enterprise Explorer view, the menu item may be called something different, but similar functionality is available.
Enabling use of binary modules
Next, in the folder MDM/.settings, create a file named com.ibm.etools.j2ee.teamshare. This is a marker file; the contents do not matter, only the name. If the .settings folder is not visible in your workspace, you need to make .* resources visible by following the instructions in the preceding section.
Figure 3. Create marker file in MDM
Using binary modules
The MDM application project contains a number of JAR files (binary modules), which are the modules of the enterprise application. Some of these are expanded into the workspace as projects, which allows you to modify the files they contain.
When the MDM EAR file is exported or published to the server, the source projects from the workspace are built into JAR files, which override any JAR files with the same names in the MDM project.
Normally, if you delete a project from the workspace that is an EJB module, web module or utility module, the module is removed from the EAR. But once the teamshare marker file is in place, deleting a project will not remove it from the EAR. As long as the module JAR file is still present in the EAR, the EAR will function the same as before.
All this means that now that you have added the teamshare marker file to the MDM project, you can delete from the workspace some of the out-of-the-box projects that you don't actually need for extension development.
If you have modified files in an out-of-the-box project for any reason, don't delete it from the workspace. Your changes won't be in the binary module. And although you can repackage the binary module to update it, you may lose your changes if you apply server fixpacks later.
Having deleted a project from the workspace, you can easily recreate it from the binary module if needed by right-clicking on the MDM project and selecting Java EE > Extract Binary Modules to Projects.
Deleting projects from the workspace
Deleting a project is different from closing it. A closed project still exists and Eclipse knows it is there, so you won't be allowed to create a new project with the same name. A deleted project no longer exists, and you could create a new project with the same name as the one that was deleted.
When you delete a project from the workspace, Eclipse asks if you want to also delete the files from the file system — generally, it is a good idea to delete the files.
If you don't delete the files and later decide to recreate the deleted project, then the new project in your workspace will be automatically populated with the files from your file system that were in the project before. This can be rather confusing if you have forgotten that the files were still there. I recommend always deleting files from the file system when you delete a project (keep a separate backup if wanted).
Deciding which projects are required
The following projects in the workspace are modules that do not normally need to be expanded as projects:
Unless you know you need to modify the content of one of these projects for some reason, they can all now be deleted from the workspace (delete the files from the file system too).
Because you added the teamshare marker file to the MDM project, deleting these projects from the workspace will not modify the services available from the MDM application; the binary modules are still present and working.
If you are developing extensions to MDM Server, the following projects must be in the workspace:
To enable definition of extensions to the MDM data model and services, I recommend you also keep the following projects in workspace:
If you delete from the workspace a utility JAR project, such as BusinessServices, the corresponding EJB project disappears with it. When you add it back, the EJB project comes along, too.
If you do not intend to use MDM web services at all, you can delete from your workspace all projects with names ending in WS, WS_HTTPRouter, and WSEJB. If you do this, then when you create new module projects you must disable web service generation.
To do so, edit the mdmgen.xml file in the module project and locate the line:
<target name="all" depends="sql, implementation, createReferenceModel, webservices, merge" description="--> description">
and change to:
<target name="all" depends="sql, implementation, createReferenceModel, merge" description="--> description">
Save the change and generate code as usual.
If you are using web services and the test server has security disabled, you need to modify the WSEJB projects to swap in the _SecurityDisabled versions of the WebSphere deployment descriptor files, which means they must be in the workspace as projects.
You should keep the WS, WSEJB, and WS_HTTPRouter projects for the same module together, all in the workspace, or all as binary modules.
In theory, it is possible to remove some of the out-of-the-box web services projects from the workspace depending on which ones you are planning to use and what extensions and additions you are developing. However, in practice, it is quite difficult to know which web services projects you will need because the dependencies are not straightforward. So I recommend that if you are planning to use web services, keep all the following out-of-the-box web services projects in the workspace:
If you know that you don't plan to use the CrossDomainServices web service, then all the CrossDomainServices projects can be deleted. Keep them in the workspace if you are planning to use the web service.
Note that for MDM Server 10, a new set of web services has been introduced that don't require any of these WS projects. In the instructions here, web services refers to the web services in MDM 9 and earlier. If you are on Version 10 and are only using the new single endpoint web services, you can remove from the workspace all the *WS projects (make sure legacy web service generation is disabled for your own module projects).
Create new module projects as usual. If you do not want to generate web services for the new module, then disable web service generation by editing the mdmgen.xml file before generating code for the first time.
When you generate code, if any errors occur or projects with the same name as out-of-the-box projects have been created in the workspace unexpectedly, you have deleted from the workspace a project that was needed by code generation. Review which projects are required and correct any problems.
To recover an out-of-the-box project that you may have deleted in error, right-click on the MDM project, select Java EE > Extract Binary Modules to Projects.
New projects you create in the workspace will not automatically appear as binary modules in the MDM application project. You can package them as binary modules if wanted, but I recommend keeping all your extension code as source projects in the workspace.
In this article, I have explained how to start using the binary modules approach to reduce the number of projects in your MDM Server workspace. Making a few simple changes can dramatically speed up common extension development tasks.
For more in-depth information on binary modules, see the article by Gary Karasiuk and Jason Sholl which is, referenced in Resources.
- "Using binary modules to optimize Rational Application Developer in a team environment" is a step-by-step guide to using binary modules when developing J2EE applications.
- Join the MDM Developers Group.
- Learn more about Information Management at the developerWorks Information Management zone. Find technical documentation, how-to articles, education, downloads, product information, and more.
- Stay current with developerWorks technical events and webcasts.
- Follow developerWorks on Twitter.
Get products and technologies
- Build your next development project with IBM trial software, available for download directly from developerWorks.
- Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edition and provides a solid base to build and deploy applications.
- Participate in the discussion forum.
- Check out the developerWorks blogs and get involved in the developerWorks community.
Dig deeper into Information management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.