Necessary Actions When Updating/Upgrading to 4.5

Owned by Team Kolibri (Unlicensed)
Last updated: Nov 09, 2022 by Technische Redaktion
2 min read

Necessary Actions When Updating/Upgrading

This page describes the actions that you must manually execute when updating from version x.y.z to a newer version. It also lists things that you must pay special attention to. An update to a new version that skips some previous versions is possible and doesn’t require updating to each version in between. However, in this case you must carry out all the actions from your previous version to the target version in the order listed here.

  • 2018-04-25 --> 4.0

    • You can only upgrade from version 2018-04-25. 
    • Before upgrading to version 4.0, you must complete the following steps. 
      • You must update to version 2018-04-25. Important information about installing updates in 3.x can be found here.
      • You must complete the migration of the schema and data.
    • After upgrading to version 4.0, additional manual actions are necessary. These are described here.


  • 4.0 --> 4.1

    • In the file <service-manager>\config\servicewatcher-sw.yml add the following line after the line starting with "eureka.instance.preferIpAddress": eureka.instance.prefer-ip-address: true
    • Replace the contents of <service-manager>\apps\structureservice with the contents of the structureservice-4.0.x.zip file from the setups folder


  • 4.1 --> 4.2

    • Replace the contents of <service-manager>\apps\structureservice with the contents of the structureservice-4.0.x.zip file from the setups folder


  • 4.2 --> 4.3

    • Replace the contents of <service-manager>\apps\structureservice with the contents of the structureservice-4.1.x.zip file from the setups folder


  • 4.3 --> 4.5

    • Replace the contents of <service-manager>\apps\structureservice with the contents of the structureservice-4.1.x.zip file from the setups folder

    • If you have changed the default location of the renditiion-plus log files, you will have to set these settings after the update of rendition-plus to version 4.0.0 again.

    • If there are problems with process model defaults
      From this version a clean installation of enaio ensures that the default model id actually exists in the model group (this property is ensured at the database level). Previously, this was not checked and you could store a default model id of a model that no longer exists. This led to errors in the visualization of management studio.
      Since an automated update action is a bit risky, it is not necessary to create this "Foreign Key Constraint" automatically for existing systems. However, a warning is displayed in the management studio that there are differences in the definition and the Database. In order to provide the foreign key constraint in an existing database, an administrator can add the constraint (from the install.sql). If that works for the database everything is ok, if not it has to be looked up in detail, which data are inconsistent. In this case you would first have to remove the faulty DefaultModelIds and then install the constraint.