Migrating from 8.0 to 10.0

License

You need to request a new license for Axon Ivy Engine 10.0.

Updates

Java 17

We updated Java to version 17:

Convert your Axon Ivy projects to the latest version to use the new Java 17 features.
You may have to update third-party libraries that do not yet support Java 17 to newer versions.
Use Java 17 to run your Maven project builds.
Use an Adoptium / Eclipse Temurin JDK or JRE to run Axon Ivy on Linux or macOS.

Details

TLS 1.0 and TLS 1.1 disabled

We disabled TLS 1.0 and 1.1 by default because they are outdated and should no longer be used. This can break communication links with legacy databases or other external services that still use the old TLS protocols. Have a look at our community blog post if you experience such problems to find out how to enable those protocols again.

Primefaces 11

We upgraded the Primefaces library from version 7 to version 11. Unfortunately, Primefaces made some breaking changes in its latest versions. Therefore, your user interfaces are most likely broken. To mitigate the migration pain, we have built a project converter that fixes most breaking changes. See Primefaces 11 Migration for more information.

Details

Primefaces 11 Migration

Old Themes removed

Instead of modena, primefaces-ivy, or all-themes, use freya-ivy or serenity-ivy. You may need to adjust your hand-crafted CSS rules to the new theme.

Elasticsearch 7.17

Elasticsearch has been upgraded from 7.3 to 7.17. If you use an external Elasticsearch server you need to upgrade to version 7.17.

Upgrade Log4j 1 to Log4j 2

Logs are written now with Log4j 2, which has a new configuration format. If you made any custom logging configuration entries, you need to adapt these changes to the new logging configuration.

Details

The legacy logging configuration file [engineDir]/configuration/log4jconfig.xml is no longer in charge. You need to make all your custom logging configuration in [engineDir]/configuration/log4j2.xml. Read more about customizing in the Logging chapter.

Portal 10.0

Portal version 8 and earlier are no longer compatible with Axon Ivy 10.0. If you have used the Portal in your projects, you have to migrate your projects also to Portal 10.0. Please have a look at the Portal Migration Notes.

Hibernate 5.4

All persistence.xml` will have a property hibernate.id.new_generator_mappings with the value set to false. This is made so that all persistence unit still work the same way according to primary key columns. They will still use the auto increment feature of the database management system. Read more here: https://community.axonivy.com/d/470-hibernate-update-54-in-axon-ivy-10-and-inserting-new-entites

Engine changes

Engine default base path changed

We changed the default value of the WebServer.IvyContextName from "ivy" to "". This means the default engine URL has changed (from http://localhost:8080/ivy/) to http://localhost:8080/.

If you have a Reverse Proxy configured, you have to manually define the WebServer.IvyContextName with the old value ivy. Otherwise the AJP uri workers will not find a valid path.

URL changes

The paths in the URL have changed. The name of the application is now at the top.

Details

Setting up a classic frontend server is now much easier, because you can now define routes on app level. If you have a Reverse Proxy configured and you block some URLs for security reasons, you need to adjust them.

Here are some examples:

Old URL	New URL
/<servlet>/<appName>/<pmv>/…	/<appName>/<servlet>/<pmv>/…
/pro/myApp/myPmv/…	/myApp/pro/myPmv/…
/api/myApp/myPmv/…	/myApp/api/myPmv/…
/wf/myApp/myPmv/…	/myApp/wf/myPmv/…

app.yaml new file location

Shifting towards highly configurable Axon Ivy projects, we needed to move the app.yaml to a new location in the Axon Ivy Engine.

Details

If the new engine is aware of the existing applications, the app.yaml files will be migrated automatically. The new locations are the following:

Old Location	New Location
/[engineDir]/applications/myApplication/app.yaml	/[engineDir]/applications/myApplication/config/app.yaml
/[engineDir]/configuration/app-myApplication.yaml	/[engineDir]/configuration/applications/myApplication/app.yaml

If you deploy an app.yaml in an application zip file, it has to be placed now in the sub-folder config. For compatibility reasons, the old legacy location in the root of the application deployment zip is still supported for the time being.

Global Variables moved and renamed

The GlobalVariables in the app.yaml are renamed to Variables. System database migration does this automatically.

Details

System Database:

We have dropped the system database table IWA_GlobalVariables and migrated its data to the app.yaml. We recommend that you migrate your projects and redeploy them to your engine. If you used your app.yaml to override Global Variables, please take note of this change as well: Supporting Environments.

Configuration:

Old app.yaml:

GlobalVariables:
  myVariable: value

New app.yaml:

Variables:
  myVariable: value

Multi Application Security System

Users and roles are no longer attached to a single application, but can be shared across multiple applications in a security system. Now, different applications can be developed and installed with their own release cycles, and the end user receives one single task list for all applications. This enables independent feature-driven development.

Details

Most engine installations will only have the predefined security context default. By default, new applications end up in this context. There are two use cases for multiple security contexts on one engine:

you want to isolate applications against each other - each application has its own security context.
you implement multi-tenancy by having one security system per tenant.

For both use cases, we suggest using multiple engines in order to make accidental security breaches impossible.

During migration, however, the status quo is maintained. The migrated applications are placed in an isolated security system with the name of the application. It is no longer possible to change the security system at runtime, this must always be done when the application is created.

Refer to Application Lifecycle for further details.

Users are no longer attached to the application, but to the Security System. This means that the user is unique over several applications.
Roles are still defined in projects. The roles are deployed into a security system. Now, the roles must not only be unique in the application, but in the security system.
Business Data has not been scoped. Now, it is scoped to the security system.
Standard process default pages are now automatically determined at runtime. You don’t have to define them anymore. If there are multiple implementations of a default process, one is simply selected. But you can fix this using settings.
EmailNotification Settings are no longer part of the application configuration. They are part of the security system and can be found there.

Changed Configuration

We renamed configuration keys to be more clear.

ImportOnDemand -> UserSynch.OnSchedule.ImportUsers
UpdateEnabled -> UserSynch.OnSchedule.Enabled
UpdateTime -> UserSynch.OnSchedule.Time

ImportOnDemand also changes the semantic - the value needs to be changed from false to true or otherwise.

Role Mapping moved to ivy.yaml 

The external name of a role that can be set in the Engine Cockpit is no longer stored in the System Database. It has been moved from IWA_Role.ExternalSecurityName to ivy.yaml. This change allows you to easily automate the role mapping configuration, which is now located in ivy.yaml.

Language

There is a new global language concept. The content language as well as the formatting language can be defined per security system in ivy.yaml, which are considered as default languages. Users can overwrite these two language settings in their user profiles.

The existing EMailNotification.Language is automatically migrated to Language.Content in ivy.yaml.

Read more here: Language and Content resolution.

Ivy Project changes

Variables configuration file

Variables (former Global Variables) are stored in new locations. During development, the project’s Variables are now stored in the variables.yaml file. Furthermore, the project migration do the conversion from the old to the new format for you automatically.

Details

Global Variables are no longer defined using the configuration editor but in the variables.yaml file within your project.

By running the latest Project-Migration in your Designer, your existing Global Variables are automatically migrated into the variable.yaml files.

Databases, Rest Clients and Web Service configuration files

Configurations of Databases, Rest Clients and Web Services are stored in new locations. On the Axon Ivy Engine, the configurations of of these have been moved from the System Database to the application’s app.yaml file. Furthermore, the System Database and project migration converts from the old to the new format automatically.

Details

We recommend that you migrate your projects and redeploy them to your engine.

Databases

During development, the project’s Databases are now stored in the databases.yaml file.

We have dropped the System Database tables IWA_ExternalDatabase and IWA_ExternalDatabaseProperty and migrated its data to the app.yaml.

All APIs to load databases configuration from IApplication and IEnvironment has been removed. They were introduced to show the configuration in the legacy AdminUI. They were never intended to be used in your Axon Ivy Projects.

Rest Clients

During development, the project’s Rest Clients are now stored in the rest-clients.yaml file.

We have dropped the System Database tables IWA_RestClient, IWA_RestClientFeature and IWA_RestClientProperty and migrated its data to the app.yaml.

Web Services

During development, the project’s Web Service Clients are now stored in the webservice-clients.yaml file.

We have dropped the System Database tables IWA_WebService, IWA_WebServiceEndpoints, IWA_WebServiceEnvironments, IWA_WebServiceFeature, IWA_WebServicePortType and IWA_WebServiceProperty and migrated its data to the app.yaml. We recommend that you migrate your projects and redeploy them to your engine.

Supporting Environments

As we now support Environments for our app.yaml, the app.yaml will no longer override all environment values. If you want to override a value for a specific Environment, define this value in the _<environment>/app.yaml file, besides in the normal app.yaml file.

Formats

Formats are migrated from the so-called config CMS to the config/formats.yaml in your project. There is no more UI Editor to edit those formats. If you migrate a running Axon Ivy Engine you need to convert your projects and redeploy them again to make formats work.

Moved JSP pages from CMS to webContent

We now only support plain JSP pages in the webContent folder. The project conversion copies the JSP pages from the CMS automatically to the webContent folder.

Enterprise changes

Cluster Name

The name of a cluster (Axon Ivy Engine Enterprise Edition) can now be configured in the ivy.yaml file. Before, it was pre-configured in the license file as server.cluster.name property.

JGroups Configuration

JGroups is the library we use to communicate between cluster nodes (Axon Ivy Engine Enterprise Edition). By default, you do not need to provide the jgroups.xml file in the configuration folder anymore. Please remove your existing jgroups.xml file from the configuration folder, if you have not made any changes to it; otherwise replace it with a standard JGroups 5.0 jgroups.xml file and re-apply your changes to this file. jgroups.xml files used in earlier versions of the Axon Ivy Engine are not compatible with JGroups 5.0.

More changes

Business Case Lifecycle

The lifecycle of the Business Case has been simplified. The first case is the business case and will always be the business case. Additional cases will be sub-cases of the business case.

Details

Previously, the first case (formerly, the initial case) has been copied as soon as new cases have been attached. The copy has then become the business case.

This change also means that the business case can now have tasks as direct children and not only sub-cases.

Maven dependencies automatically packed into Axon Ivy archives

With 9.2, it is no longer necessary to copy maven dependencies to a specific folder manually or with the Maven dependency plugin. However, the old way still works.

Details

There is a new project-build-plugin version 9.2.1 with new execution goals, which are active by default:

maven-dependency: Copy maven dependencies to lib/mvn-deps

maven-dependency-cleanup: Remove lib/mvn-deps folder.

If you use the functions to pack or export projects in Axon Ivy Designer, the same happens as with the Maven plugin:

Your Maven dependencies are copied to the lib/mvn-deps folder.

If you used the Maven dependency plugin to copy your dependencies and you have made manual entries to the .classpath file, you can remove those now and use the normal Maven dependencies descriptor. To remove those entries you can edit the .classpath file directly or use the Axon Ivy Designer.

Before:

After:

Warning

Make sure that your project is converted to a Maven project!

Only dependencies with the scope compile, system and runtime are copied. To reduce the size of your Axon Ivy archive, make sure that your dependencies are configured correctly:

Mark test dependencies with the scope test

Exclude transient dependencies that are already delivered by the Axon Ivy core

Web integration tests simplified

Selenium based integration test do no longer require huge manually crafted maven build pom.xml definitions. Existing pom.xml files for test projects must be manually simplified.

Details

We introduced an new lifecycle called iar-integration-test that basically binds all the plugin executions which are required to have a running in memory engine with your workflow app deployed.

Here’s how you make use of these simplified stack in the pom.xml of a test project:

change the packaging from type iar to iar-integration-test
remove manually bound executions of the goals start-test-engine and stop-test-engine
consider removing bound deployment executions (goal deploy-to-engine or deploy-iar). The new plugin lifecycle automatically takes all your IAR dependencies and deploys them.
remove unittest jvm argLine configurations that propagate the start engine URL (test.engine.url) and test application hint (test.engine.app).
verify that your web tests stick to a naming pattern which complies with the maven-failsafe-plugin includes. If not, rename the unit tests to end with IT (e.g. WebTestCustomerOnboardingIT.java)
run the maven build to verify your changes.

A sample conversion can be reviewed on Github. Another way to get a valid example is to use the new Axon Ivy Test Project wizard of the Axon Ivy Designer, select IvyWebTest as testing flavour and examine the created pom.xml in the newly created test project.

IvyScript Validation is Enabled by Default

The ivy.script.validation.skip compilation parameter of our Project Build Plugin is now set to false. This validates IvyScript code within Ivy processes by default during compilation. Therefore, errors and warnings related to the IvyScript code will be reported.

Read more about the compilation parameters and their default values here: https://axonivy.github.io/project-build-plugin/release/9.4/compileProject-mojo.html#skipScriptValidation

Programmable Process Elements

We changed the UI technology to build custom inscription editors for programmable process elements. Therefore, existing programmable elements, built with AWT, will show deprecation warnings.

Affected elements are: Program Start Event, Program Interface (PI) Activity and Wait Intermediate Event

Details

To make your custom editors compliant, change your internal Editor implementation to extend from UiEditorExtension, and create widgets using the new ExtensionUiBuilder.

Here are some valid examples:

ui.label("seconds to wait").create()
scriptEditor = ui.scriptField().requiredType(Integer.class).create();
textArea = ui.textField().multiline().create();

Enabled JavaTime module for REST Clients by default

The standard JSON serialization feature for REST Clients is now aware of JavaTime objects, such as ZonedDateTime, and will therefore optimize their JSON representation.

Details

E.g. java.time.ZonedDateTime will be serialized as a simple timestamp number, rather than a complex object structure.

This change should not have any side-effects on existing clients since java.time objects, which did not have any special serializer features enabled, could not be serialized in a way that provides any value outside of the Java world.

However, if you face any issues with the changed java.time object serialization, you may disable the JavaTime module by setting the REST Client property JSON.Module.JavaTime=false

Using HttpAsyncClient for CXF web service calls

We switched the default connection implementation of CXF web service calls from HttpURLConnection to org.apache.http.nio.client.HttpAsyncClient.

Details

The HttpAsyncClient has improved performance and provides better support for NTML authentication.

There are no known issues with HttpAsyncClient, but if you still want to use HttpURLConnection you can set the property use.async.http.conduit to false on the web service client configuration.

Default REST Client entity processing changed to buffered

Since we are using the ApacheConnectorProvider as the default provider for Rest Clients, the default entity processing has changed from BUFFERED to CHUNKED. This means that the HTTP header Content-length is not set which makes trouble with a lot of services. You can fix this by switching to chunked processing again. Change your REST Client config and set the property jersey.config.client.request.entity.processing to CHUNKED.

New Security System config Membership.UserMemberOfLookupAllowed

We introduced a new security system configuration property Membership.UserMemberOfLookupAllowed, with true as its default value. If your active directory or eDirectory does not allow to read the memberOf property of a user (groups of a user), you need to set this configuration property to false. With the introduction of this new property we removed the property Membership.UseUserMemberOfForUserRoleMembership.

SSL Client Configuration

We made the life of Axon Ivy Engine administrators easier with some simplifications in the SSL configuration.

Details

We removed SSL.Client.UseSystemTruststore and SSL.Client.UseCustomTruststore in the ivy.yaml. It’s not possible to configure them anymore. The system truststore of the JVM and the custom truststore of Axon Ivy are always active now. If you don’t trust a certificate, simply remove it from the truststore.

HTTPS port disabled by default

HTTPS port is now disabled by default on the Axon Ivy Engine, because you should always terminate SSL on the reverse proxy (frontend webserver). If you need HTTPS directly on the Axon Ivy Engine then you need to set the property WebServer.HTTPS.Enabled to true in ivy.webserver.yaml (a part of ivy.yaml).

Frontend config combined into BaseUrl

The configuration of the frontend URL in ivy.yaml has been simplified. You need to define now the BaseUrl in your ivy.yaml. This property is a combination of the old frontend properties Frontend.Host, Frontend.Protocol and Frontend.Port.

Daily Jobs are only executed at configured time

Daily jobs are now executed only at the configured time, even if the Axon Ivy Engine was not running at the last execution time.

Details

Daily jobs like sending task summary emails or synchronizing users are executed once a day. Prior to 9.1, if the Axon Ivy Engine was not running at the configured time, the daily jobs were executed on the next start of the Axon Ivy Engine. This lead sometimes to a heavy workload on start-up, making the Axon Ivy Engine unusable for other tasks.

We changed this behavior in order to make the Axon Ivy Engine responsive straight after start-up.

context.xml and web.xml moved to configuration folder

The context.xml and web.xml files are now in the global /configuration/ folder. If you modified them you need to apply these changes to the files in the new location.

Details

Prior to 9.1 they were located under webapps/ivy/META-INF/context.xml and webapps/ivy/WEB-INF/web.xml.

Changes to the Axon Ivy System Database

We have introduced a new table IWA_SecurityMember that contains entries for all users and roles. Migration to the new database schema is done automatically.

Details

We also removed most of the foreign key references to the tables IWA_User and IWA_Role and replaced them with references to IWA_SecurityMember. Entries in table IWA_SecurityMember will not be deleted even if a corresponding user or role is deleted.

During migration all users and roles that could not be mapped to existing entries (e.g. because they were deleted from the database) but still have an entry in a Name column, will be added to the IWA_SecurityMembers table, to ensure referential integrity. All security members added this way will be in state disabled.

Note that the following database definitions have changed:

In view IWA_TaskQuery the naming of the activator columns has slightly changed, to match the Java API methods naming:
- ActivatorName and ActivatorDisplayName change to OriginalActivatorName and OriginalActivatorDisplayName
- CurrentActivatorName and CurrentDisplayName change to ActivatorName and ActivatorDisplayName
Column IWA_WorkflowEvent.UserId now references IWA_SecurityMember.SecurityMemberId and changes to a VARCHAR(210) value.

System Database Cache Configuration and MBean (JMX)

We have changed the System Database cache configuration. Instead of configuring a UsageLimit you can now configure a TimeToIdle (TTI) value. As an alternative, you can also configure a TimeToLive (TTL) value.

Details

The TimeToIdle value specifies how long the cache keeps an object after the last usage. Whereas the TimeToLive value specifies how long the cache keeps an object after the first usage. Have a look at configuration\ivy.cache.properties and replace all configured UsageLimit values with appropriate TimeToIdle and/or TimeToLive values. By default, the TimeToIdle value is 600 (10 minutes) and the TimeToLive is 0 (disabled).

The usageLimit attribute on MBeans with name pattern ivy Engine:type=CacheClassPersistencyService,name=*,strategy=CacheAllRemoveUnused has been removed. Instead, we introduced the timeToIdle and timeToLive attributes.

Deprecations and Removals

Environments

The environment editor and all environment aware editors like the Web Service Client Editor, the REST Client Editor, and the Database Editor are not environment aware anymore. Learn how you can define environment aware configurations.

Read more here about the future of environments: https://community.axonivy.com/d/142-environments-will-disappear-in-the-long-term

Overriding

We deprecated the Case Scope (deprecated) project overrides in favor of Strict Overriding.

Details

If your application uses Overrides. You should migrate to Strict Overriding. Define the customization project in your app.yaml.

OverrideProject: com.acme.solution:MyCustomerAdaption

Custom Application Properties API deprecated

The Public-API’s ICustomProperties, ICustomProperty and ICustomPropertyProvider are deprecated and will be removed in the near future. Please use the Ivy.var() API to create application variables.

AJP support is deprecated

AJP is used to integrate the Axon Ivy Engine with Microsoft IIS or Apache HTTP as reverse proxy. We still support AJP, but you should migrate to a more modern URL rewrite approach based on HTTP/HTTPS.

Details

AJP’s days are numbered. It is not getting developed any further and prevents the use of new web features such as websockets. We highly recommend migrating to a modern URL rewrite approach based on HTTP/HTTPS. In future versions of the Axon Ivy Engine, you won’t be able to use AJP.

If you are using Microsoft IIS as your reverse proxy, proceed as follows:

Open the IIS administration interface.
Delete the virtual directory named ivy. It is located under Default Website.
Follow the instructions here on how to integrate Microsoft IIS with a modern URL rewrite.

If you are using Apache HTTP Server as your reverse proxy you need to reconfigure Apache HTTP.

System Database

Dropped support for outdated System Database versions.

Details

Oracle Database

The support for Oracle Database 12c, 18c is removed as Oracle support has ended for these versions. If using Oracle Database we recommend using version 19c as this is the long term support version.

Postgres Database

The support for Postgres Database 9 and 10 is removed as Postgres support has ended for this version. We recommend using Postgres 14 as this is the latest and longest supported version.

MySQL Database

The support for MySQL 5.6 is removed as MySQL support has ended for this version. We recommend upgrading to MySQL 8.0 as this is the latest and longest supported version.

MariaDB Database

The support for MariaDB 10.0 - 10.2 is removed as they are not supported anymore. We recommend upgrading to MariaDB 10.6 as this is the long term support version.

Windows Server

The support for Windows Server 2008 R2 is removed as Microsoft support has ended for this version. If using Windows Server we recommend using version 2022 as this is the long term support version.

Global deploy.options.yaml removed

The deploy.options.yaml in the deployment directory can no longer be used to influence deployments.

Details

We think that it made deployments unnecessary hard to track and that administrators are better off with the deployment options packed as part of the application ZIP or specific YAML per artifact.

Configuration deployment options removed

Now that most of the app configuration is defined in YAML files, the configuration deployment options are disregarded and can be removed from your deploy.options.yaml file.

Details

The following options are deprecated and can be removed:

configuration:
  overwrite: false               # [false], true
  cleanup: DISABLED              # [DISABLED], REMOVE_UNUSED, REMOVE_ALL

Legacy jTDS driver for MS SQL Server dropped

The legacy jTDS driver have been dropped. You need to switch to the official Microsoft JDBC Driver for the System Database and external databases if you still have used the jTDS driver.

Details

System Database

Go to Engine Cockpit / System Database
Choose Driver Microsoft SQL Server
Click Check Connection
Click Save
Restart Axon Ivy Engine

External Databases

Go to Engine Cockpit / External Databases
Edit all External Databases with Driver net.sourceforge.jtds.jdbc.Driver
Choose com.microsoft.sqlserver.jdbc.SQLServerDriver as Driver
Save configuration

VisualVM Plugin no longer delivered with the Axon Ivy Engine

The Axon Ivy Visual VM plugin to monitor your Axon Ivy Engine is now available in the Axon Ivy Market. It is not bundled with the Axon Ivy Engine in the directory [engineDir]/misc/visualvm/ anymore.

Drop AXIS Technology for Web Service Client

With Axon Ivy 7.1 we have introduced the CXF Web Service Client as a super-fast, secure, and future-proof technology to call SOAP Web Services. AXIS has been making more and more trouble. To keep the quality of Axon Ivy on a high level we need to remove AXIS. You have to convert all Web Service Clients based on AXIS (1+2) to CXF in the Axon Ivy Designer.

Details

The Designer comes with a project converter to convert your Axis2 clients automatically to CXF. Additionally, a quick fix is available on the Axis error marker.

The detailed steps to migrate from AXIS clients to CXF are outlined here: https://community.axonivy.com/d/199-migrate-from-axis2-webservice-to-cxf

Non-public API Email

If you have used some non-public email classes like EmailSetupConfiguration, EmailSetupProviderUtil or SimpleMailSender then you need to touch your project because they no longer exist. We are currently building a public API for mail. It is already available but not officially public yet:

import ch.ivyteam.ivy.mail.MailClient:
import ch.ivyteam.ivy.mail.MailMessage;

try (var client = MailClient.newMailClient()) {
  var message = MailMessage.create()
    .to("my.good.old.friend@neighborhood.com")
    .subject("Beer!")
    .textContent("Do you feel like having a beer on Friday?")
    .toMailMessage();
  client.send(message);
}

Workflow Event Log API removed

The Workflow Event Log API has been deprecated in Axon Ivy 8.0 and has been removed now. As it was never Public API, most projects will not be affected.

Details

The API consists of the following methods, interfaces and enums:

ch.ivyteam.ivy.workflow.IWorkflowContext.findEventLog(...)

ch.ivyteam.ivy.workflow.IWorkflowContext.createEventLog(...)

ch.ivyteam.ivy.workflow.IWorkflowContext.createEventLogPropertyFilter(...)

ch.ivyteam.ivy.workflow.eventlog.EventLogDescription

ch.ivyteam.ivy.workflow.eventlog.EventLogProperty

ch.ivyteam.ivy.workflow.eventlog.EventLogSeverity

ch.ivyteam.ivy.workflow.eventlog.EventLogStatus

ch.ivyteam.ivy.workflow.eventlog.IEventLog

ch.ivyteam.ivy.workflow.eventlog.IEventLogCase

ch.ivyteam.ivy.workflow.eventlog.IEventLogTask

Removed StartSignalEventElementQuery

There used to be an API to create a query for StartSignalEventElements (StartSignalEventElementQuery). As the StartElements are no longer part of the System Database, we removed this API. If you had this API in usage, please change to the simpler methods all(), matches(pattern) or contains(part).

Details

Replace usages of:

Ivy.wf().signals().receivers().createStartSignalQuery()

With one of:

Ivy.wf().signals().receivers().all()

Ivy.wf().signals().receivers().matches(pattern)

Ivy.wf().signals().receivers().contains(part)

Removed support for CMS Page

We no longer support CMS pages. Both in Axon Ivy Designer and on Axon Ivy Engine. You will need to manually re-implement them to an alternative. For example as HTML Dialog (JSF) or as static JSF page. We still support plain JSP pages which would be a non-future alternative.

Removed support for Macro expansion in RTF documents

RTF is not a common format anymore. We have supported macro expansion in RTF documents from CMS. This is no longer working. To generate documents with placeholders, use other well-maintained components like the DocFactory.

Call & Wait intermediate event

The Call&Wait intermediate process element is no longer supported.

It will be automatically removed from existing processes where it has been present.

In most cases the ‘call’ aspect implementation can be replaced with a normal PI (Programming Interface) Activity which subsequently is connected to a Wait Program Intermediate Event element that implements the ‘wait’ aspect.

Subversion Client unplugged from Axon Ivy Designer

We removed the Subversion client Subclipse from the Axon Ivy Designer. It can still be easily installed through the Eclipse Marketplace in the Designer. Go to Help ‣ Eclipse Marketplace, search for Subclipse and install it.

Special handling for Informix as external third-party database

Informix is a database management system and can be integrated with Axon Ivy like any other database system. We have removed any special handling for Informix as this is no longer necessary. If you are using Informix and have any problems, please contact us.

Tag Legend:

This migration is handled either by the Migration Wizard or by the System Database conversion. The wizard will interact with you if you are affected by this change.

This migration will change something in the engine operation. If you are responsible for the operation of an engine, check if this change affects you.

This migration highlights behaviors or features that are deprecated. That functionality will be removed soon. If you are responsible for the operation of an engine, you should check if this change affects you.

This migration will remove a behavior or feature that has been available for the engine operation. If you are responsible for the operation of an engine, check if this change affects you.

This migration is handled by the Project Conversion automatically.

This migration will change a certain behavior in the projects. If you are a project developer, check if this change affects you.

This migration will mark features or APIs as deprecated in projects. That functionality will be removed soon. If you are a project developer, check if this change affects you.

This migration will remove a behavior or feature of a project. If you are a project developer, check if this change affects you.

Migrating from 8.0 to 10.0

License

Updates

Java 17

Primefaces 11

Elasticsearch 7.17

Upgrade Log4j 1 to Log4j 2

Portal 10.0

Hibernate 5.4

Engine changes

Engine default base path changed

URL changes

app.yaml new file location

Global Variables moved and renamed

Multi Application Security System

Role Mapping moved to ivy.yaml

Language

Ivy Project changes

Variables configuration file

Databases, Rest Clients and Web Service configuration files

Supporting Environments

Formats

Moved JSP pages from CMS to webContent

Enterprise changes

Cluster Name

JGroups Configuration

More changes

Business Case Lifecycle

Maven dependencies automatically packed into Axon Ivy archives

Web integration tests simplified

IvyScript Validation is Enabled by Default

Programmable Process Elements

Enabled JavaTime module for REST Clients by default

Using HttpAsyncClient for CXF web service calls

Default REST Client entity processing changed to buffered

New Security System config Membership.UserMemberOfLookupAllowed

SSL Client Configuration

HTTPS port disabled by default

Frontend config combined into BaseUrl

Daily Jobs are only executed at configured time

context.xml and web.xml moved to configuration folder

Changes to the Axon Ivy System Database

System Database Cache Configuration and MBean (JMX)

Deprecations and Removals

Environments

Overriding

Custom Application Properties API deprecated

AJP support is deprecated

System Database

Windows Server

Global deploy.options.yaml removed

Configuration deployment options removed

Legacy jTDS driver for MS SQL Server dropped

VisualVM Plugin no longer delivered with the Axon Ivy Engine

Drop AXIS Technology for Web Service Client

Non-public API Email

Workflow Event Log API removed

Removed StartSignalEventElementQuery

Removed support for CMS Page

Removed support for Macro expansion in RTF documents

Call & Wait intermediate event

Subversion Client unplugged from Axon Ivy Designer

Special handling for Informix as external third-party database

Role Mapping moved to ivy.yaml 