Versions Compared

Version Old Version 1 New Version Current
Changes made by

Former user

Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

It is a best practice to have only one model edition open and editable when creating an MDM model for deployment.

  • Full information on Model Management in Convergence for MDM can be found here:

          http://www.semarchy.com/doc/SEMDG/html/Models-Management.html

 

  • Full information on Deployment in Convergence for MDM can be found here:

          http://www.semarchy.com/doc/SEMDG/html/Deployment.html

 

A few customers have come across problems when they do not follow this best practice and have been making changes to their model but do not see these changes in the deployed Application UI.

The reason this has happened is because they have created multiple versions of their model, without going through the process of closing a model edition, ready for deployment. A model edition is deployed to a Data Location which then makes the Application UI available for that edition. Therefore you must ensure that the model edition you are updating is the one that is deployed to the Data Location.

 

...

Problem

Customers have come across the problem of not seeing the changes done in the models in the generated application UI. This is typically a problem of Deployment.
Developers or production operators should be comfortable with the deployment concepts in Semarchy Convergence for MDM and read the Deployment section of the on-line documentation.

Solution

There are several reasons for not seeing changes reported in the application UI.

At Design-Time

At design-time, when connected to an open model edition deployed in a development data location, changes that only impact the application UI (for example, modifying a form view or a workflow) do not require an update of the deployed model edition.
The application browser window can be refreshed (click your profile in the top right and select 'Refresh application') in order to dynamically regenerate the application UI and see the changes.

An Update of the deployed model edition is necessary when either the model structure (entities, attributes, references, etc) or rules (enrichers, matchers, etc).

Info

If the model structure or rules have been modified, a browser refresh made without a model update may cause the application to behave unexpectedly.

For example:

  • The application's forms or tables try to access new attributes that have not been deployed in the database tables, causing data access exceptions.
  • Data submitted through the application is not certified correctly as the jobs still implement the old enrichers, validators or matchers.

If the changes do not reflect correctly in the application, or if the application behaves unexpectedly, it is recommended to:

  1. Validate the Model and fix possible validation errors
  2. Update the deployed model edition, making sure to update both the jobs definitions and database schema.
  3. Refresh the application browser window.

At Run-Time

At run-time, the typical problems for not seeing the changes in the application UI are:

  • The updated model edition was not deployed to the data location.
    At run-time, you usually use a Production Data Location, that requires deploying a closed model edition. Updating the model is not supported in this context.  

  • An incorrect model edition was modified (See the example below).
    It is a best practice to have only one model edition open and edited at a time. If in the lifecycle of the project several models or branches have been created, make sure to modify and deploy the right model edition.

  • The data edition you connect to is not using the updated deployed model edition.
    In a Product Data Location, after deploying a model edition, you must point the data edition to this model edition either by closing/opening or switching this data edition to the new model edition.

Run-time deployment should follow the process below:

  1. Validate the model and fix possible validation errors.
  2. Close the model edition.
  3. Deploy this newly closed model edition to the data location, making sure to update both the jobs definitions and database schema.
  4. Switch the data edition to this newly deployed model edition, or close and open a new data edition using this newly deployed model edition.
  5. Refresh the application browser window.
Panel
titleExample: The modified model is not the one deployed

 Here is an example where there are 2 open model editions:

 Image Modified

However,

...

in the Data Location, the deployed model is CustomerAndFinancialMDM [0.0]

...

 not CustomerAndFinancialMDM2 [0.0]:

 

...

Image Added


Therefore

...

, any changes made to CustomerAndFinancialMDM2 [0.0] will not be seen in the Application UI

...

(Please also note, if you discover you have a model edition with a number appended to the end and you or another user has not explicitly created this new version (e.g. CustomerAndFinancialMDM2 [0.0]), this will happen if you have exported the open model edition for CustomerAndFinancialMDM [0.0] and then imported it to the same environment where you already have an open CustomerAndFinancialMDM [0.0] model edition. This will only happen in a Design time repository as a Deployment repository will only let you import a closed model edition)

...

.

Best Practice

The best practice is to start with one model edition and , develop and make changes in that one edition (usually v0.0). This edition is deployed in a development data location and updated during the development phase.
Once the model is ready to be deployed to test or production, the model should be closed. This action automatically closes the model edition so it can be deployed but also opens a new edition of the same model which can then be further developed for the next release to production.

More info: