All previously existing server-types (property
OMS_SERVER_TYPE in $OMS_ETC/installation.properties) became invalid and cannot be used any longer. The following server-types became invalid:
The new server-type cluster was introduced, replacing all previously existing types. As now only one server-type remains, there is no need to have a property for configuration. Therefore the property
OMS_SERVER_TYPE was removed completely. Nevertheless the variable is still available in the environment and can be accessed where needed. The fixed value
cluster is now set by the script set_env.sh.
Along with the change of server-types, the overall high availability (HA) architecture of IOM has changed. HA nodes of distributed IOM installations now require a single IOM application server only. Previously, it were two, a frontend- and a backend-server. All the details can be found in Guide - Intershop Order Management - Technical Overview.
To migrate existing installations, you have to reinstall IOM using the new server-type. Please make sure that data within the DB and on shared file-system are kept safe.
As IOM 2.12 has removed support for server-types standalone, frontend and backend, the according server-groups in Ansible4IOM 1.2 were removed too. Ansible4IOM 1.2 does not support server-groups
oms_single_node for IOM 2.12 and newer. Instead, two new server-groups were added:
oms_cluster_node and oms_azure_cluster_node.
For migration of existing installations, please remove the old installations (please make sure that DB data and data on shared file-system are kept safe), change the server-groups in the inventory file according the following rules:
If you use group-files in your config-repository, you have to rename them too. Now you can reinstall IOM with Ansible4IOM 1.2.
The extensions of the deployment artifacts bakery.control-app-<version>.ear and bakery.impex-app-<version>.ear has changed to war.
In the deployment.cluster.properties:
The default value of
OMS_LOG in $OMS_ETC/installation.properties has changed from "
$OMS_VAR/log" to "
You have to make sure to provide sufficient disk space at the new position of
OMS_LOG. Advantage of this change is the separation of
OMS_LOG will not be removed any longer when uninstalling IOM.
Script $OMS_HOME/bin/load_test_data.sh: command line switch
--var-dir is deprecated (but still working). Please use
--share-dir instead. The change was necessary as the directory importarticle was moved from $OMS_VAR to newly introduced $OMS_SHARE.
As of IOM 2.12 the previously existing mounts of shared file-systems within OMS_VAR were consolidated within OMS_SHARE. The new central shared file-system became now part of the health-check mechanism of IOM. This health-check is controlled by the newly introduced property
The previously existing mounts of shared file-systems were not tested by health-checks. Only the two internal FTP-servers were checked. As these FTP-servers were replaced by the new central shared file-system too, the according properties were removed:
The default value of
enabled. If you do not have a distributed installation, you do not need a shared file-system. In this case you have to to disable the check of the shared file-system by setting the property to
The health-check of the shared file-system requires a special directory .healthcheck in the root of $OMS_SHARE. You have to make sure, that this directory exists on the shared file-system.
Standalone installations of IOM (< 184.108.40.206) were running without Watchdog. This setup made this installation type the ideal base for developers.
As of IOM 2.12 the server-type standalone was removed, hence a suitable setup of IOM suitable for developers was lost. To enable developers again to setup a system according their needs, a new Ansible4IOM configuation variable in roles/oms_config/defaults/main.yml was added:
WATCHDOG_ACTIVATED (set to
true by default).
In order to setup an IOM installation without Watchdog, the variable has to be set to
false within the config-repository. When changing from an older IOM version to 220.127.116.11, this change has to be applied to all config-repositories, which are used to setup developer installations of IOM.
The deactivation of Watchdog is only supported for installations consisting of a single
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.