This document describes the steps needed to upgrade the edoras one application to 1.5.0-S127.
Please stop the edoras one server, perform all upgrade steps described below and then restart the server again at the end.
Configurable full index name
The index name used by the full index configuration can now be changed using the
full.index.name
system property, allowing a single ES cluster to support
multiple edoras one full indexes at the same time (simply set a different index
name for each edoras one environment).
Note that if an ES cluster is supporting an edoras one cluster, all nodes within a specific edoras one cluster must use the same index name.
If you have custom index configurations and you want to support this functionality
as well, then you will need to provide an index template resource that can be used with
multiple index names. This can be achieved by using the #{index.name}
placeholder
in your template resource file. This will be replaced by the configured index name when
the template resource is loaded:
{
"template": "#{index.name}*",
"settings": {
...
Release version changes
Our version format has changed from MAJOR.MINOR.PATCH.S$sprintId
to MAJOR.MINOR.PATCH-S$sprintId
.
Please change your project dependencies to reflect the new format.
Account color information
Account color and logo information has already been removed in the 1.5.0.S124 version. On-premise customers could and still can create
appropriate css classes for their accounts following edoras one Modeler Guide | Getting familiar with account
For tenant initialization with JSON read: Tenant configuration | Account information
Cloud customers can now use the same mechanism to select one of several pre-defined color schemes.
Backward compatibility in Initialize variables step
In release 1.5.0.S125
we introduced an initialize variables step optimization. The variables initialization
takes place at the end of the initialize variables step and not immediately after the expression evaluation. The optimization
significantly decreased database load. A side effect was that if you use a variable initialized on a previous row in the same Initialize Variables,
that variable would not be initialized. We believe this is a conceptual improvement, preferring a declarative style over a procedural one in the models.
However, to support backward compatibility edoras one provides the backwardcompatibility.allowVariableReferencesInInitVariableTask
property.
This defaults to false
meaning to support the declarative, performant style. In the case when backward compatibility with version 1.5.0.S125
and earlier is needed set
attribute to true
. To fix your models, ensure that same-task variable references are separated out into different Initialize Variables Tasks.
Example:
Let’s say that process definition has following two rows in the initVariables
service task
name | value |
---|---|
a |
aValue |
b |
#{a} |
The behavior prior 1.5.0.S125
release is that variable b
is initialized to aValue
. Since 1.5.0.S125
variable b
is initialized to null
. If you want to use optimized initVariables
step you can split initialization into 2 phases.
Form initialization default values
On form initialization, all components that handle string or number type values will be set by default to null (rather than "" or undefined) if no default value or runtime value is present.
If your backend expects these components to send empty string ("") values instead of null, this can be a breaking change.
Booleans and array or object values are not affected by this change.
Changes to be made in custom palettes
The palette XSDs have been refactored in this release.
Due to this refactoring, following changes are to be made in the custom palettes of all types (process, form and case):
-
Change the XML Namespace value to http://www.edorasware.com/schema/vis/palette
-
Change the schema location to http://www.edorasware.com/schema/vis/palette followed by the location of the corresponding latest XSD version.
For example, a custom form palette would have the XML Namespace and schema location set in it’s root <palette> element as shown in the sample below:
<palette id="custom-form-palette-1" apply-patch-to-palette="edoras-one-form-palette"
resource-bundle="translation"
xmlns="http://www.edorasware.com/schema/vis/palette"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.edorasware.com/schema/vis/palette http://www.edorasware.com/schema/vis/edoras-vis-form-palette-2.0.60.xsd">
The latest versions of the process, form and case palette XSDs are 2.0.57, 2.0.60 and 2.0.19 respectively.
Bootstrap project
Here you will find a list of files which have changed in the bootstrap project since the last release. This helps you check the difference between your bootstrap project version and the current one:
-
src/main/java/com/edorasware/acme/elastic/AcmeEntitySerializer.java
-
Sample elasticsearch indexing code
-
src/main/java/com/edorasware/acme/elastic/AcmeIndexConfiguration.java
-
Sample elasticsearch indexing code
-
src/main/java/com/edorasware/acme/elastic/AcmeIndexEntry.java
-
Sample elasticsearch indexing code
-
src/main/java/com/edorasware/acme/elastic/AcmeIndexSearch.java
-
Sample elasticsearch indexing code
-
src/main/resources/com/edorasware/acme/config/acme-index-config.xml
-
Replaced the full index configuration with the sample index configuration
-
src/main/resources/com/edorasware/acme/elastic/acme-template.json
-
Elasticsearch template for the sample index
-
src/main/resources/com/edorasware/bootstrap/config/one.properties
-
Added elasticsearch configuration properties, email validation pattern change to support _,- in names
-
src/main/resources/com/edorasware/acme/palette/acme.process.palette.xml
-
changing xmlns name from
process-palette
topalette
-
src/test/java/com/edorasware/acme/elastic/AcmeIndexTest.java
-
Sample elasticsearch index unit test
-
build.gradle
-
Added edoras-gear-search test dependency
-
pom.xml
-
Added edoras-gear-search test dependency