Extending physical MDM capabilities with the InfoSphere MDM Workbench

The InfoSphere® MDM Workbench simplifies the construction and maintenance of customized physical InfoSphere MDM programming artifacts. You can use the InfoSphere MDM Workbench tools to customize your solution by developing additions, extensions, metadata specs, hierarchies, and more.

In the following diagrams, the example workflows show the high-level tasks that are iterative and are repeated until you achieve the results that you require. The diagrams are provided only as an example. Your team might use a different workflow. In addition, the diagrams imply that each task follows sequentially, whereas in reality tasks might be performed simultaneously.

Hover and click the icons, or replay the animation.

In the first diagram, the example workflow shows the high-level tasks for customizing the physical MDM capabilities:
The graphic shows the tasks that can be performed for physical MDM. In MDM Workbench, a project is a container that holds the operational server configuration and its associated files. You create or import physical MDM model content, by creating data additions in the model editor. By default, Add, Update, and Get Record transactions are created for each entity, and standard error reasons are defined for each of these transactions. The validation process checks that the model is complete and correct. Validation is always performed before generating code to ensure that no errors will be generated in the code. If errors are found, the code is not generated. You generate the code artifacts by using the mdmgen.xml ANT build script that is created by the new MDM Development Project wizard and placed in the root of the project. You can manually edit generated Java code and protect any changes that you have made from being overwritten. Any generated files that are not Java are overwritten when code is generated from the model. If you make manual changes to these files, you must back them up to avoid losing your changes. As you iteratively work through your project, you can regenerate implementation code. During the development cycle, model changes must be reflected in the generated code. Where elements are renamed or deleted, the files must be changed accordingly. This maintenance process is performed each time code generation takes place and is the first step in the process. SQL scripts are in the module project resources folder that create and update the MDM database tables. The scripts cover setup, foreign-key constraints, triggers, rollbacks, and so on. After you complete development of an extension or addition, you must deploy it to the operational server. For customized functions, you also must correct any validation errors. Export CBA and SQL files. Deploy the CBA to the production server.

Hover and click the icons, or replay the animation.

In the second diagram, the example workflow shows the high-level tasks for setting up product hierarchies:
The graphic shows the tasks that can be performed for physical MDM. In MDM Workbench, a configuration project is a container that holds the files to manage specs and product type hierarchies. Metadata specs are used by other components in an MDM implementation to support the creation of structured data. The default product-type hierarchy is a root product with these children products: goods, services, financial, and insurance. The validation process checks that the specs are complete and correct. If errors are found, you must correct the errors before you can deploy the spec. Where elements are renamed or deleted, the files must be changed accordingly. This maintenance process is performed each time code generation takes place and is the first step in the process. Update or deploy CBA in MDM operational server. For the models, you also must correct any validation errors. Deploy spec and hierarchy to production server.
Related information:
Introduction: How to create new metadata customizations using metadata tooling
Introduction: How to create physical customizations using extension tooling

Last updated: 6 May 2015