You encounter the following issue with beforeSaving processes: TMDM-8534
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.
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.