Showing results for 
Search instead for 
Did you mean: 

Proof of Concept

Former Member
0 Kudos

Hi ,

It will be very helpful if someone can please share the proof of concept docs .

Thanks in Advance ,

Dev .

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi ,

hope this is useful .

- An

Message was edited by:


Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Dev,

Here is what we have done:

1. First prerequisite: Come up with the "<b>sample</b>" business data model that you want to prototype. I used the word sample because the model does not have to be your organization's complete business model. But it should contain all representative objects so that you can build look up tables, main table with fields of all "<u>field types</u>", taxonomy, qualified look up tables etc.

2. Second prerequisite: Come up the sample data that you want to load for all the objects that you have in mind.

3. Third execute in a logical flow:

a) Build the repository- manual if your model is a custom model.

If not you can use the out of the box, and customize as needed.

Assign display fields, unique fields, writable once, search tab, calculated expressions, etc.

b) Try out <b>centra data management scenarios</b>- data entry through data manager, write validation expressions to validate the data; assignment expressions; add workflow, and approvals; search and sort of the data; test unique fields, writable once, calculation expressions, required fields, etc;

c) Then, ETL: use different types of source files; import using import manager into all table types; then try out import server; workflow job activation on import. If your repository is out of the box, you will probably start with out of the box maps.

d) Syndicator: extract data into all types of output files; use syndications that use merge feature, delta syndications, syndications with filter on qualified links; syndication of expressions, and finally syndication server.

e) You can go back to data manager, and try out match, and merge strategies & rules; savable searches; free form search and simple search combinations, etc.

f) If you are interested in iviews, build some, one on each table type. If you have 2 repositories that have related information (such as one for master data, and one for exceptions), try cross repository iviews;

g) Now is the time to learn the console admin ops such as archive (manual and scheduled), unarchive, check, repair, master-slave, duplicate, schema transport, delete, update, etc.

h) Define security using the Admin section of your repository in the console, and use data manager to test the security. Establish change tracking, and see how it works.

At this point you have a got a very good idea of how MDM nuts and bolts work.

Hope this helps. This is what I have done in April 2005, and by end of a good 4-6 weeks, I felt extremely comfortable speaking about the technology. You can do it in half the duration if you are focussed on just the prototype.


Former Member
0 Kudos


I find it quite difficult that someone could share those, since with MDM proof of concepts involve master catalogs which is data very sensitive to the customer.

What are you looking for exactly? perhaps we can give ideas



Former Member
0 Kudos

I understand ,

Basically I just needed to run 1 complete cycle step by step to learn it completely .

Hope someone can help ,