Release Notes
v5.19.1 on the GitHub
New Features
New Database storage for rules projects and deployments
This feature doesn’t change user functionality and adds a new backend rules repository implementation. The new implementation allows to use DB using a simple JDBC connection. This repository implementation significantly reduces number of library dependencies, makes DB schema easier for understanding and allows simpler integration when running rules embedded (in process) in other applications.
Array Call for multiple arrays
If multiple input parameters for a rule are arrays where the rule expects only a single value, the rule will be separately calculated for each of the elements of these arrays and the result will be an array (or multiple arrays of arrays) of the return type. The order in which these arrays will be iterated is not specified and may change in future. Users are advised to use this feature when there is no interdependency between these rules calculations.
Improvements
Core:
- Updated Spreadsheet tables to do all cell types determination automatically. Spreadsheet tables honor dependencies across tables and find the type information from the used data and other rules
- ‘flatten’, 'add', 'addAll' and similar functions return an array of the specific type instead of Object[]
- 'import' keyword in an environment table allows to import a java library or a single java class
- Added ‘anyFalse’ and ‘allFalse’ functions which check if any or all elements of an array are false values
- Improved the SimpleProjectEngineFactory class. Supported: external classloader, variations and runtime context
- Supported '*' in rules.xml for classpath elements
WebStudio:
- Improved Active Directory support for user management to simplify property files configurations. The wizard for this functionality will be introduced in the next version
- Added hints for Spreadsheet cells to indicate a type of the cell. The hint shows up when the mouse pointer is over the first equals ("=") symbol in the cell
- Added an automatic adjustment of ‘rules-deploy.xml’ for backward compatibility based on the OpenL version in a rules project
- Ambiguous dispatch error message became more user friendly
RuleService:
- Added overriding of placeholder properties. All settings have been extracted to the single application.properties file, which can be located at $user.dir and $user.home directories
- Removed dependencies on JCR-related libraries. The new Database storage is preconfigured by default.
Demo Package:
- Added application.properties file with settings for RuleService
- Moved 'openl-demo' folder to the root of the Demo package
- Moved ‘start’ scripts to the root of the Demo package
- Configured the new Database storage for a deployment repository
OpenL Maven Plugin:
- Added 'package' goal for creating a zipped artifact
- Updated 'generate' goal for supporting variations and RuntimeContext in a generated Java interface
- Added support of Maven build lifecycle
Updates:
- Auto Type Discovery for Spreadsheet tables is switched on by default
- Completely removed support of an Eclipse based rules projects
- slf4j-log4j and jcl-over-slf4j are in runtime scope now
- Updated CXF to 3.0.11 version
- Upgraded Ehcache to 2.7.8 version
- Removed dependencies on 'ant' library
- Removed dependencies on 'jersey-common' library
Fixed Bugs
- Fixed the trinary if operator (‘? :’) to use second expression in the case the first one is null
- Fixed an issue with storing SOAP requests in Cassandra
- Fixed incorrect URL generation for web services when run in Linux (slash symbol was mandatory)
- Fixed dropdown lists for alias datatypes while editing tables in Editor
- Fixed FailOnMiss issue when 'Empty' was showed instead of an error message
- Fixed an incorrect display of merged cells in an environment table for ‘dependency’ keyword
Migration Notes
Rule Services
Default OpenL properties are initialized in PropertySourcesLoader now. Add the following lines into web.xml:
<context-param> All OpenL-related properties should be in a single file. Merge rules-production.properties , ruleservice-ext.properties , openl-ruleservice.properties into application.properties. It is also recommended to remove default properties from the merged file.
<description>Load default and application properties to the Spring application
environment.</description>
<param-name>contextInitializerClasses</param-name>
<param-value>org.openl.spring.env.PropertySourcesLoader</param-value>
</context-param>
OpenL Maven Plugin
JavaWrapperAntTask was replaced with openl-maven-plugin. Use 'generate' goal to generate Java beans from OpenL datatypes
The following properties were changed
| Before | After |
|---|---|
| ruleservice.openl.home | openl.home |
| ruleservice.datasource.repositoryPropertiesFile = rules-production.properties | Removed. |
| production-repository.factory = org.openl.rules.repository.factories.JdbcDBRepositoryFactory | production-repository.factory = org.openl.rules.repository.db.JdbcDBRepositoryFactory |
Core
- OpenL does not use JCL loging framework anymore, all dependencies on JCL were removed. Use JSF4J instead.
- RulesEngineFactory(File) was deprecated. Use RulesEngineFactory(URL) or RulesEngineFactory(String) instead
String xlsxPath = "filepath/or/classpath/to/file.xlsx";
// The argument is a filepath. It is useful for JUnit tests
new RulesEngineFactory(xlsxPath);
//Alternative way, using a classpath
URL xlsxUrl = getClass().getResource(xlsxPath);
new RulesEngineFactory(xlsxUrl);
OpenL Rules
- Add ‘rules.xml’ file to any rules projects which were based on a deprecated Eclipse rules project template
- If the rules relied on ‘autoType’ property being off by default it is advised to check if rules are working correctly and add this property if necessary
- It is also recommended to remove the following imports in 'Environment' table from the rules:
- import java.utils.Arrays
- import org.apache.commons.lang
- import org.dozer.mapping
OpenL has own 'smart' functions like isEmpty() and addAll()
