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.

• 4.5 --> 4.6

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

  • With this version the "icas-provideradapter" was replaced by the "archiveservice". If you were using the icas-provideradapter service the following steps need to be done to adapt the configuration to the new archiveservice:

    • In the file <service-manager>\config\servicewatcher-sw.yml change the name of the icas-provideradapter section to archiveservice.
      Also change the path Parameter from "${appBase}/icas-provideradapter/icas-provideradapter-app.jar" to "${appBase}/archiveservice/archiveservice-app.jar"

    • In the folder <service-manager>\config rename the file icas-provideradapter-prod.yml to archive-prod.yml.
      Then edit the file and add a new top-level element "archives:" to the yml-structure. It should look like the following example afterwards (pay attention to the indentation - it should be 2 spaces for each level):

      archive-prod.yml

      archives:
        iternity:
          profiles:
            default:
              userName: userName
              userPassword: password
              endpoint: https://127.0.0.1/iTernity/iTernity.asmx
              cscMode: SNSN  

    • Start the service-manager and navigate to the media-configuration in the management-studio as shown in the below pictures. Make sure that the archive-set that is used for the icas archive does not use the old servicename within the service-url. If it does, change it to use the new servicename or the ip-address.
      
      

• 4.6 --> 4.8

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

• 4.8 --> 4.10

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

  • In the gateway route configuration in <service-manager>\config\gateway-prod.yml, the status service route has to be added.

    - name: 'status'
      url: 'http://status/api/v1'

  • A new microservice "Status-Service" was introduced in this release. The setup will create the service-files in the <service-manager>\apps\ folder. To enable it add the following lines to the <service-manager>\config\service-watcher.yml file:

    - name: statusservice
      type: microservice
      profiles: prod,cloud,mq
      instances: 1
      memory: 128M
      port: 7470
      path: ${appBase}/statusservice/statusservice-app.jar

• 4.10 --> 4.12

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

• 4.12 --> 5.0

ToDos

• • The Elasticsearch service has to be updated to version 6.3. This cases a reindexing of the enaio data as well. How to change the service and how to migrate the indexdata is documented here:
    Elasticsearch 6.3 Migration
  • The Service Admin is updated to Spring Boot version 2.1. ...