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
Software Version Management
Use your existing Version Control software (CVS, PVCS, ClearCase, etc.,) to keep a library of your selected mix of MDM components. MDM releases are frequent (twice a year), and 3 to 4 patches should be expected between releases. Components are almost always not compatible across MDM builds, patches or releases!
Use this library as the baseline for building your MDM environments in Development, QA and Production. Use it to apply MDM upgrades in a controlled fashion across environments.
Need an audit trail for changes to specific MDM tables?
If Change Tracking has been enabled from the console for a table, MDM will start to keep a log of all operations on records in that table (Adds/Changes/Deletes). This log is only visible as a table in the DBMS (Oracle, SQL Server, DB2).
Every MDM repository has two dedicated schemas created in the database:
YourRepositoryName_M000 = The schema used for data and metadata
YourRepositoryName_Z000 = The schema used for change tracking (DBMS table A2i_CM_History)
A simple data audit report can be generated using something like this query:
SELECT rtrim(tablename) "Table Name" ,rtrim(fieldname) "Field Name" ,rtrim( decode(entrytype, 'I', 'Created', 'M', 'Modified', 'D', 'Deleted', entrytype)) "Type of Change" ,rtrim(username) "User Name" ,rtrim(recordname) "Record Identifier" ,rtrim(oldvalue) "Old Value" ,rtrim(newvalue) "New Value" ,to_char(eventtime,'MM/DD/YYYY HH:MI:SS PM') "Date and Time" FROM YourRepositoryName_Z000.A2i_CM_HISTORY WHERE eventtime >= SYSDATE - &vDaysToAudit AND rtrim(tablename) = '&YourTableName' ORDER BY eventtime
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.
MDM's change tracking generates large numbers of records in the A2i_CM_History DBMS table. Set up a periodic purge and/or analyze process to keep this table from affecting MDM (and SQL Query) performance.
A QuickStart Guide to SAP MDM 5.5
Part 1: Select and Install MDM Components
Part 2: MDM Components and Modules
Part 3: MDM architecture: How components fit into the MDM eco-system
Part 4: The OS/DB Product Availability Matrix for MDM 5.5 SP4
Part 5: MDM for the Java Developer
Part 6: Tips and Tools for the MDM Administrator
Part 7: Migrating MDM Configuration