MDM projects that implement a custom data model, or extensions to the standard models, will need to include a site-specific strategy to document and migrate changes.

1. The data model for a repository can be exported from the console as a complete schema and selected changes then imported into a target repository. This feature, delivered with SP4, is the only way to reliably transport incremental changes to your MDM data model.

2. Validation Expressions and MDM security configuration are two areas of custom configuration that cannot be migrated from the console. These will need to be manually re-applied to the target repository.

3. Maps saved via the Import Manager and via the Syndicator can be saved to the file system and migrated with relative ease into the target repository. This requires the source and target tables be absolutely identical.

4. MDM does not currently provide a physical report that documents the meta model — the metadata for the model, validation expressions, security, port configuration, etc. The Java API however completely exposes the meta model, with the exception of expressions. The following specification can get you started on building your own MDM meta model report.

By: MD in searchsap.techtarget.com

Easy Point-in-time backups of MDM Repostiories are possible in several ways. Each of these operations is available as a CLIX command, to be scripted for your favorite OS command line:

* Master Slaving: Create a Slave Repository mounted on a separate MDS instance. Synchronize (refresh) it at your desired interval. This provides a live read-only mirror of your original repository. Normalize the slave to get a writeable copy.
* Archiving: Create periodic archives of your repository. This generates “.a2a” files in the “/Archives” folder of your MDS installation. Note that the filenames are datestamped, but not timestamped. Rename or relocate the files if you need to generate archives more than once a day.
* Duplication: Create a duplicate of the repository to make a writeable clone available e.g., for training use.

By: searchsap.techtarget.com

If your MDM scenario has a significant number of data-entry capable end users, then take some time to integrate MDM with your corporate LDAP. This will greatly simplify the process of maintaining MDM users and defining their roles and capabilities. At a minimum, your users will thank you for not having to remember yet another application-specific password!

You will need to modify mds.ini for each MDS instance to include this section. Example:

[MDM LDAP]
LDAP in Use=false
Server=Your.LDAP.Server (e.g. ad.yourcompany.com)
Server Port=xxx
Base DN=OU=Portal,DC=ad,DC=yourcompany,DC=com
Admin Name=PickAName
Admin Password=PickAPassword
Admin Identifier=cn
User Identifier=sAMAccountName
MDM Roles Algorithm=GroupMapping
MDM Roles Attribute=MemberOf
Fallback in Use=True (Falls back to MDM Password for non-LDAP Users)
Fallback Roles=
Fallback User=
Fallback Password=
Allow Referrals=False
Trace Level=1
MDM Email Attribute=Mail

By: searchsap.techtarget.com