This document describes the steps needed to upgrade the edoras one application to 1.5.0.S122.
Please stop the edoras one server, perform all upgrade steps described below and then restart the server again at the end.
Query API behavior change
The following predicate API changes have been made:
-
and
andor
combined predicates that are not explicitly separated usingMultipleNamedValuePredicate
will be merged to a single query. -
the following static methods and values have been moved to the new
Predicates
class:-
Predicate.and()
-
Predicate.or()
-
Predicate.not()
-
Predicate.EMPTY
-
-
new predicates have been provided for some use cases that could not easily be expressed before:
-
isNotNull()
for checking that a value is not NULL -
VARIABLE.undefined(name)
for checking that no work object variable is defined with the given name -
PROPERTY.undefined(name)
for checking that no work object definition property is defined with the given name
-
Projects will have to correct references to the old Predicate static methods, and queries using combined predicates should be reviewed to make sure that the query is still describing the required semantics.
Combined predicates with and / or
The previous behaviour for executing queries based on predicate combinations was not intuitive, and may have returned unexpected results. The reason for this is that the separate parts of a combined predicate were evaluated separately instead of being combined to check a specific variable. As an example, the following predicate:
Task.VARIABLE.name().eq("var").and(Task.VARIABLE.stringValue().eq("foo"))
used to be evaluated as the following pseudo-SQL:
select workObject where ((select where variableName = 'var') and (select where variableValue = 'foo'))
From the original predicate, this would seem to return all work objects that have a single variable with name 'var' and value 'foo'. That is not the case, however. In fact it returns all work objects that have a variable with name 'var' (which may have any value) and a variable with the value 'foo' (which may or may not have the name 'var').
The change to the query API means that such predicates are now combined into a single variable query:
select workObject where (select where variableName = 'var' and variableValue = 'foo')
This query will return only work objects that have a single variable with the required name and value.
Any predicates affected by this change will probably return different results because they were previously
returning unexpected matches, but it is also possible that some applications rely on the current 'incorrect'
behaviour. If you have a query where the original behaviour should be retained, the existing
MultipleNamedValuePredicate
class can be used to combine predicates that should be applied to separate variables:
MultipleNamedValuePredicate.matchAll( Task.VARIABLE.name().eq("var"), Task.VARIABLE.stringValue().eq("foo"))
New predicates
The isNotNull()
predicate can be used to check that a given value is not null:
Case.OWNER_ID.isNotNull()
The undefined()
predicate is supported by work object variable and work object definition property
queries, and checks that no variable or property is defined with the given name:
Case.VARIABLE.undefined("var1")
This can be used in place of the following predicate that performed the same query in a less readable way:
Predicate.not(Case.VARIABLE.name().eq("var1")))
Improved elasticsearch index support
Updated full index template
The stability of the elasticsearch integration code has been improved, but unfortunately this required a change to the full index template, so a full resynchronization of the elasticsearch index will be required after upgrading to this release.
Full index support
The FullIndexConfiguration
class has been moved out of the internal
sub-package to reflect the fact that this
is intended for use in project configurations and is not an internal implementation detail. The new package name is:
com.edorasware.elastic.index.FullIndexConfiguration
A new FullIndexSearch
implementation has been provided with some useful utility methods to execute an elasticsearch
query against the index and return work object or definitions directly, avoiding the need to code this explicitly in
customer projects. To use this functionality, simply declare a bean with the following class name and autowire it into
your search implementation:
com.edorasware.elastic.index.FullIndexSearch
In addition, a new FullIndexValidator
implementation is provided to support periodic validation of the elasticsearch
index. At the moment this just checks that the number of items in the index and in the database match.
Validation of the FullIndexConfiguration
is supported. In the case when you want to make validation of the full index active,
add fullIndexValidator
bean to the spring context:
<bean id="fullIndexValidator" class="com.edorasware.elastic.index.FullIndexValidator"/>
and add a task periodically validate index to the scheduler (e.g. in com/edorasware/cloud/core/config/scheduler-config.xml
).
<task:scheduled-tasks scheduler="scheduler"> ... <task:scheduled ref="fullIndexValidator" method="validate" fixed-delay="3600000"/> ... </task:scheduled-tasks>
fullIndexValidator
counts and compares amount of workobjects and workObjectDefinitions in the database and in the full elasticsearch index. In the case when amounts are not
the same warning is logged to the logs.
CMMN interfaces refactoring
A number of low-level CMMN engine interfaces has been cleaned-up and harmonized as part of this release. You may have to adjust your Bootstrap project based code in the following areas:
-
The
oneEngineListeners
bean expects an additional constructor argument. It is calledcmmnExtensions
and is expected to be an instance of interfacecom.edorasware.cmmn.one.transitionhandlers.CmmnExtensions
. There is a default implementation calledDefaultCmmnExtensions
that you can use if you don’t have your own extensions to pass along to the constructor of theoneEngineListeners
bean. -
A new interface has been introduced for action decorators called
ActionDecorators
, along with a default implementationOneActionDecorators
. The methods exposed by the interface were previously part of theEngineListeners
interface. The threedecorate
methods now pass along an additional parameter of type `TransitionData'. -
A new interface has been introduced for state decorators called
StateDecorators
, along with a default implementationOneStateDecorators
. The method exposed by the interface was previously part of theEngineListeners
interface. The onedecorate
method now passes along an additional parameter of type `TransitionData'.
Angularjs has been upgraded to 1.5
edoras one is now using Angularjs 1.5, please refer to the Angularjs 1.5.8 changelog for the breaking changes.
Root and parent context variables are not copies anymore
The root and parent context variables are now references instead of copies in the browser. When one or both are equal to self, all the changes done in one of the objects is also reflected in the others.
Also starting from now, both root and parent context variables are available in init forms.
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/resources/com/edorasware/bootstrap/config/one.properties
-
added new property maxChunkUploadSize
-
src/main/resources/com/edorasware/acme/config/acme-index-config.xml
-
added example
FullIndexSearch
bean -
src/main/resources/config/cmmn-engine-context.xml
-
passing an additional parameter to
oneEngineListeners
bean