You wish to deploy two or more MDM models to a single MDM server, but the entity names in the two models overlap. For example, Model 1 contains an entity called customer and Model 2 also contains a customer entity, but with a different structure.
You encounter the following issue with beforeSaving processes: TMDM-8534
You encounter the following issue with MDM views: TMDM-4803
You are not using Oracle as the underlying physical storage, and the MDM server using Oracle only supports the deployment of a single model / container pair.
The view issues can be overcome by understanding how to correctly utilize security roles and have multiple versions of views deployed to MDM
The beforeSaving issue requires your processes (Jobs) to be designed appropriately to take the multiple model scenarios into account.
As a general rule, beforeSaving processes should only be designed to execute when an update to an entity is requested using the MDM Web UI or workflow. Executing a beforeSaving process on each insert / update from a batch Job or real-time service is poor design, and will lead to performance issues.
Model 1 contains an entity called bsTest, and Model 2 also contains an entity called bsTest with a different structure.
There is nothing stopping you from having two or more views for bsTest in Studio. The view is linked to the entity by the naming convention Browse_items_<entityName> but you can use the # notation to have:
Now all you need to do is set up your security roles properly – have a role for each model, and provide access to the appropriate views in each.
Model / role 1
Model / role 2
Once these objects are deployed to MDM, you need to set up your users and role assignments. For example:
Now your model 1 user will only see the views for model 1 (in other words, the views with the correct xpaths) and your model 2 user will only see model 2 views. If a user can see both models (not a common requirement), then you can use descriptions in the views to distinguish for that user which views go with which models:
You do not have the facility to use the # notation with beforeSaving processes. Instead, accept that the same beforeSaving process will be called, regardless of whether you are using model 1 or 2. Therefore, design a router parent Job to send the MDM exchange message to the correct beforeSaving Job:
An example router Job is attached to this article.
To reiterate: beforeSaving processes should only be instantiated for inserts / updates that originate from the MDM UI or workflow. Why should they not be used for batch inserts or real-time service inserts? Say you were loading 1000 records to MDM – the beforeSaving Job would be fired 1000 times, which is a significant overhead. It is much more sensible to do the logic in the Job / service that’s loading the data to MDM and thus only instantiate one Job.
... View more
Say you have a list of tables, each with different structures. All you know is which field is the primary key for each table.
Use the attached Job to:
Iterate through your table list
Read each table using dynamic schema
Pivot to key-value pairs (plus original primary key and some row metadata)
This particular solution does the pivot whilst streaming data from the source, avoiding having to hold a large amount of data in memory or use an iteration per row.
Job is for version 6.4.1
... View more
Hi, Two things: 1) You need two jobs in your beforeSaving process, one to return output_report , one to return output_item. 2) output_item - the xml message you return from your job has the same schema as an MDM exchange message - i.e. if you use tMDMTriggerInput and look at the structure of the message provided by MDM, this will give you an idea of what to return to MDM. You only need to return /exchange/item which is the section that contains the actual data of your entity, /exchange/report is not mandatory. Hope that helps!
... View more