This article describes the actions which must be performed before all changes done on a model are visible in the generated application UI.
Developers or production operators should be comfortable with the deployment concepts in Semarchy xDM and read the Deployment section of the on-line documentation.

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) are modified.

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.

Example: The modified model is not the one deployed

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

However, in the Data Location, the deployed model is CustomerAndFinancialMDM [0.0] not CustomerAndFinancialMDM2 [0.0]:

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

Best Practice

The best practice is to start with one model edition, 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.

For more details: documentation about deployment is available at the following URL: