...
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.
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.
| Code Block |
|---|
- 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:
| Code Block |
|---|
- 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. ... - 2018-04-25
4.12 -->
45.0
You can only upgrade from version 2018-04-25. - 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
Before upgrading to version
45.0, you must
complete the following steps. After upgrading to version 4.0, additional manual actions are necessary. These are described here.- Replace the contents of
have upgraded to version 4.12 and you must have completely removed any folder-in-folder structures in your schema and object instances (see Migrating folder structures from version 3.3 to 4.0).
With enaio redline 5.0 the Elasticsearch service has to be updated to version 6.3. Reindexing the enaio data is neccessary. How to update the service and how to migrate the data is documented here: Migration of Elasticsearch from version 5.5 to version 6.3
The StructureService MicroService is now part of the service-manager Setup. Before updating the service-manager service, please uninstall the previously manually installed StructureService:
- delete the following folder and all its contents: <service-manager>\apps\structureservice
4.1 --> 4.2
4.0 --> 4.1
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):
| Code Block | ||||
|---|---|---|---|---|
| ||||
archives:
iternity:
profiles:
default:
userName: userName
userPassword: password
endpoint: https://127.0.0.1/iTernity/iTernity.asmx
cscMode: SNSN |
...
- edit the file <service-watcher>\config\servicewatcher-sw.yml and delete the entire structureservice section.
- The import organisation (AD-Sync) operation is now only available via the management-studio and the parameters "import method" "import mode" and "rootpath" have been removed from the GUI form.
- import method: This is automatically determined by the ID in the specified configuration file
- import mode: This will be taken from the value specified in the configuration file. Please make sure you have the correct mode ("NORMAL" or "SIMULATION") in the configuration file
- rootpath: This will be taken from the value specified in the configuration file. Please make sure you have the correct rootpath in the configuration file
- Edit the file <service-manager>\config\application-es.yml and add the line spring.elasticsearch.rest.uris: '<es-server-ip>:9200' - where <es-server-ip> needs to be replaced with the ip of the elasticsearch server.
Multiple elasticsearch server (cluster environment) can be defined by '<es1-server-ip>:9200,<es2-server-ip>:9200,<es3-server-ip>:9200' archiveservice: the service-specific configuration is done via the archive-prod.yml file.
The structure in the archive-prod.yml has changed.
At the top level, the "archives" property is replaced by the "storage" property.
The next property level defines the „profiles“ for the different storage types (e.g., iternity)
From that level on, the property structure remains unchanged.
Compared to the previous format example the level of depth of the „profiles“ and „iternity“ properties is switched.now:
Code Block storage: profiles: iternity:previous:
Code Block archives: iternity: profiles: