1 Introduction

The present guide is addressed to administrators who want to install IOM 2.1.x in their Linux based infrastructure. It enables them to understand what artifacts are contained in the IOM 2.1 delivery and how they can be installed, configured and deployed.

The document describes how to install IOM 2.1.x. It makes no difference whether the host is a front-end server, back-end server or a single server installation.

 For a technical overview of typical installation scenarios please see references.

1.1 Glossary

1.2 References

• System Requirements - Intershop Order Management 2.1
• Guide - Intershop Order Management - Technical Overview
• Guide - IOM Database Migration

2 Prerequisites

2.1 Java Development Kit

The WildFly application server hosting and running IOM requires an installed Java development kit (JDK) of at least version 8.

The JAVA_HOME global environment variable has to point to the installation directory of the JDK.

2.2 Mail Server

The IOM requires an existing mail server that processes internal and external emails sent from IOM via the SMTP protocol.

Also server host and port need to be known for later configuration.

2.3 FTP server

The IOM requires Pure-FTPd, as it supports virtual users. The user credentials used for accessing the FTP-server differ from the credentials used for accessing the file system.

2.4 PostgreSQL Server

The IOM requires a PostgreSQL database hosted by a PostgreSQL database server and can reside on its own host.

To make the database server fit for IOM, certain configuration steps in a standard installation are necessary. Setup and initialization your will find in section Database Setup and Initialization.

2.4.1 Support

Intershop does not offer PostgreSQL support further than general recommendations for its use as relational database for IOM.

A list of companies offering professional Postgres support can be found here www.postgresql.org/support/professional_support/.

Also the PostgreSQL community has some excellent mailing lists, pgsql-general being the most active http://www.postgresql.org/list/.

2.4.2 Operating System

The IOM only supports PostgreSQL servers hosted on a Linux based OS.

2.4.3 Version

PostgresSQL 9.5.x or later is required.

A list of possible incompatibilities with 9.5.x is rather short and should not affect the IOM http://www.postgresql.org/docs/9.5/static/release-9-5.html.

3 Definition of Properties

The IOM uses three major property files which are explained below.

3.1 Installation Properties

The local environment of IOM is defined in $OMS_ETC/installation.properties.

The file installation.properties defines shell variables, which are read by $OMS_HOME/bin/set_env.sh to provide the environment for all scripts and programs belonging to the IOM system.

$OMS_HOME/bin/set_env.sh provides the content of installation.properties as simple shell variables, additionally it adds some exported variables, e.g., PATH and some variables required by 3^rd party programs (e.g., the content of JBOSS_JAVA_OPTS will be exported as JAVA_OPTS to be available for standalone.sh).

3.2 Cluster Properties

Cluster properties are WildFly system properties, which are defining the machine independent configuration of an IOM cluster.

These properties are located in $OMS_ETC/cluster.properties.

PostgreSQL related properties are read by set_env.sh and exported as environment variables.

Adjust cluster.properties to the real values, used by your OMS cluster. For example, you have to enter the access-information for the database, in order to enable the IOM application server, to access the database.

3.3 Deployment Properties

Deployment properties define which artifacts of the IOM should be deployed to the WildFly application server.

The properties are located in $OMS_ETC/deployment.properties.

Adjust the file to only include the artifacts that need to be deployed on the application server. Please make sure to keep the order.

The table below shows the entries for all supported types of server:

4 Database Setup and Initialization

4.1 User

Define a dedicated OS user for the Postgresql service. (referred as the "postgres OS user" in following descriptions)

4.2 Cluster Initialization

4.2.1 Data Directory

The PostgreSQL data directory contains all of the data files for the database. The variable PGDATA is used to reference this directory. It must be prepared prior to the initialization and belongs exclusively to the Postgres user.

You should not use this directory for private data, nor add symbolic links into it. But you will probably want an extra file system built on RAID and battery backed for it. Just make sure, not to use its root folder for the data directory and have the major version within the path.

This will facilitate maintenance and Postgres major upgrades, e.g., /iomdata/pg_9.5/data.

This directory must belong to the postgres OS user.

# as root
mkdir /iomdata/pg_9.5/data
chown <postgres OS user>:<group> /iomdata/pg_9.5/data

# as the postgres OS user
# add PGDATA=/iomdata/pg_9.5/data to the user environment

4.2.2 Initialization (initdb)

The initdb of the standard installation process needs special consideration in order to work on one of the IOM's databases. Initdb will create a new PostgreSQL database cluster and its superuser (see https://www.postgresql.org/docs/9.5/static/app-initdb.html).

It must be called as the postgres OS user.

There are a few options to choose during a Postgres initialization for IOM:

1. Consider using data-checksums (https://www.postgresql.org/docs/9.5/static/app-initdb.html#APP-INITDB-DATA-CHECKSUMS).

2. Make sure to use an UTF8 encoding. Depending on your operating system, you may need to replace the string "UTF8" with "UTF-8" (all places).

   Note

   No change of encoding
   This parameter cannot be changed after the cluster initialization.

   The command to perform initdb may change according to the OS, the Postgres version and to the way you did install it. For YUM installations refer to YUM_Installation.
   Examples:

   Example

   # as the postgres OS user
   
   # Postgres 9.5, YUM installation on Red Hat 7
   # for more info type /usr/pgsql-9.5/bin/postgresql95-setup --help 
   /usr/pgsql-9.5/bin/postgresql95-setup initdb postgresql-9.5 --encoding UTF8 --locale=en_US.UTF8 --data-checksums -D /iomdata/pg_9.5/data -U postgres -W
   
   # without YUM:
   ...../pgsql-9.5/bin/initdb --encoding UTF8 --locale=en_US.UTF8 --data-checksums -D /iomdata/pg_9.5/data -U postgres -W
   
   
   

   


4.3 Further Recommendations

4.3.1 Client Authentification

The access permissions must be defined in $PGDATA/pg_hba.conf.

Use md5 as auth-method to prevent passwords to be sent in clear-text across the connection.

Also you cannot use ident for TCP/IP connections, otherwise the JDBC driver connection from IOM to the database will not work. See https://www.postgresql.org/docs/9.5/static/auth-pg-hba-conf.html for details.

4.3.2 Database Server Configuration

To achieve best performances, almost all of the data (tables and indexes) required for the ongoing work load should be able to reside within the file system cache. Monitoring the I/O activity will help to identify insufficient memory resources.

The IOM is built on hibernate as API between the application logic and the database. This results mainly in a strong OLTP activity, with a large number of tiny SQL statements. Larger statements occur during import/export jobs and for some OMT search requests.

Following main parameters in $PGDATA/postgresql.conf should be adapted. See https://www.postgresql.org/docs/9.5/static/runtime-config-resource.html.

You can consider http://www.pgconfig.org/ as guideline (using the OLTP Model).

Some aspect of data reliability are discussed here https://www.postgresql.org/docs/9.5/static/wal.html. Understanding vacuum is also essential when configuring/monitoring Postgres https://www.postgresql.org/docs/9.5/static/routine-vacuuming.html.

4.4 Create User and Database

The following steps describes the setup of a new database.

In order to perform the next steps, you need to be able to use the psql command and be able to access the database server via its superuser (usually postgres).

su - <postgres OS user>
# set variables
IS_OMS_DB_HOST=<value of your is.oms.db.host>
IS_OMS_DB_PORT=<value of your is.oms.db.port>
 
# connect to the database server as the super user
psql -U postgres -h $IS_OMS_DB_HOST -p $IS_OMS_DB_PORT -d postgres

4.4.1 Create User

IOM connects with its own dedicated database user.

1. Create user

   Create user

   -- create user 
   CREATE USER "<value of your is.oms.db.user>" PASSWORD '<value of your is.oms.db.pass>';

4.4.2 Dedicated Tablespace (optional)

The database initialization dump does not expect a given tablespace, all objects will be placed in the default users tablespace. When your data directory is located on an adequate file system, you can keep the Postgres default tablespace which is located in $PGDATA/base. If you want to define a dedicated tablespace (i.e. on a dedicated file system) , you should:

1. Set it as default for the user and for the database prior to use the provided initialization dump (provided it has been created):

   Default tablespace

   -- set default table space
   ALTER USER "<value of your is.oms.db.user>" SET default_tablespace = 'tblspc_iom';

Also see Postgres table spaces:http://www.postgresql.org/docs/9.5/static/sql-createtablespace.html

4.4.3 Create Database

IOM uses its own dedicated database.

1. Create the database.

   Create database

   -- create database
   CREATE DATABASE "<value of your is.oms.db.name>"
     WITH OWNER = "<value of your is.oms.db.user>"
      ENCODING = 'UTF8'         -- or 'UTF-8'
      TABLESPACE = pg_default   -- or your dedicated tablespace 
      LC_COLLATE = 'en_US.UTF8' -- or 'en_US.UTF-8'
      LC_CTYPE = 'en_US.UTF8'   -- or 'en_US.UTF-8'
      CONNECTION LIMIT = -1; 

2. Set database search_path.

   Set search path

   -- set search_path
   ALTER DATABASE "<value of your is.oms.db.name>" SET search_path = "$user", customer, oms, omt, product, public;

3. Exit the psql console.

   Exit console

   -- exit console
   postgres=# \q

5 FTP Server Setup

The following steps illustrate the setup of the Pure-FTPd server on a RedHat based Linux system.

# as root install pure-ftpd
yum install pure-ftpd

In the file /etc/pure-ftpd/pure-ftpd.conf, uncomment the following line, in case it is commented out by default:

PureDB /etc/pure-ftpd/pureftpd.pdb

# as root install pure-ftpd as a service
cp /usr/lib/systemd/system/pure-ftpd.service /etc/systemd/system/
systemctl enable pure-ftpd
systemctl start pure-ftpd

The FTP accounts can be set up on the same host as IOM is installed on or on separate hosts. If you use separate hosts, you have to create operating system user and directory structure first.

The following code snippets are showing the preparation of directories, if the FTP server is running on the same machine as the IOM application server.

5.1.1 FTP Account PdfHost

# as root set variables
IS_OMS_PDF_USER=<value of your is.oms.pdf.user>
OMS_USER=<value of your OMS_USER>
OMS_VAR=<value of your OMS_VAR>
 
# as $OMS_USER create home folder for virtual user
mkdir $OMS_VAR/pdfhost
 
# as root create virtual user for the pdfhost
pure-pw useradd $IS_OMS_PDF_USER -u $OMS_USER -d $OMS_VAR/pdfhost
pure-pw mkdb

5.1.2 FTP Account MediaHost

# as root set variables
IS_OMS_MEDIA_USER=<value of your is.oms.media.user>
OMS_USER=<value of your OMS_USER>
OMS_VAR=<value of your OMS_VAR>
 
# as $OMS_USER create home folder for virtual user
mkdir $OMS_VAR/mediahost
 
# as root create virtual user for the mediahost
pure-pw useradd $IS_OMS_MEDIA_USER -u $OMS_USER -d $OMS_VAR/mediahost
pure-pw mkdb

6 Installation of IOM

6.1 Preparation of Operating System and File System

6.1.1 Create OS User and Group on the Host

Intershop strongly recommends to create a dedicated group and user for the IOM installation on the host system. The following script, uses the same value for user name and group name.

1. Create user credentials.

   Set user credentials

   # as root set variables
   # default: oms
   # use "oms" if you don't want to customize the installation layout
   OMS_USER=<name of user to own and run IOM>
    
   # default: /opt/$OMS_USER
   # use "/opt/$OMS_USER" if you don't want to customize the installation layout
   OMS_HOME=<directory where to install IOM>
    
   # add group
   groupadd $OMS_USER
   
   # add user
   useradd -g $OMS_USER -d $OMS_HOME -m $OMS_USER
   
   # set password
   passwd $OMS_USER

6.1.2 Extracting the Release Package

1. Log in as $OMS_USER.

2. Place and extract the IOM release package in $OMS_HOME.

   Extract package

   # as $OMS_USER at directory $OMS_HOME
   # extract the IOM release package
   tar -xvzf IOM-2.1.x.x.tgz

   This creates the main directories: etc, var, bin, lib, application etc.

6.1.3 Edit Installation Properties

For the following tasks the local environment of IOM has to be defined in ~/etc/installation.properties. See installation.properties for more information.

You should add the following line to ~/.profile of $OMS_USER in order to have a readily prepared environment just after logging in:  

. ~/bin/set_env.sh

6.1.4 Distributing the Release Package Contents

According to the Linux File System Hierarchy Standard, OMS installation will be distributed on different file systems. The variable $OMS_VAR and the command line switch --etc of integrate.sh are defining the directories, where to place the according parts of OMS. There is no need to change the default values, except you want to adapt the installation layout to your own needs.

1. Edit etc/installation.properties as $OMS_USER if you want to adapt the installation layout to your own needs. You do not need to make any changes at the moment, if you want to use the default layout.
   1. Change OMS_USER to the name of the user, who should own and run IOM.
   2. Change OMS_HOME to the name of the directory, where the IOM software has been placed.
   3. Change OMS_VAR to the name of the directory, where to place var-data of IOM.
      
      

2. Prepare the directories $OMS_VAR and $ETC_TARGET before distributing OMS to these locations. Set the placeholders to the values defined in installation.properties.

   Setup user and directories

   # as root set variables
   # default: oms
   # use "oms" if you don't want to customize the installation layout
   OMS_USER=<name of user to own and run IOM> 
    
   # default: /etc/opt/$OMS_USER
   # use "/etc/opt/$OMS_USER" if you don't want to customize the installation layout
   ETC_TARGET=<directory, where to place etc-data>
   
   # default: /var/opt/$OMS_USER
   # use "/var/opt/$OMS_USER" if you don't want to customize the installation layout 
   OMS_VAR=<directory, where to place var-data>  
    
   # prepare the directories 
   mkdir -p $ETC_TARGET 
   chown $OMS_USER:$OMS_USER $ETC_TARGET 
   mkdir -p $OMS_VAR 
   chown $OMS_USER:$OMS_USER $OMS_VAR

3. Distribute the release package parts by running the integrate.sh script as $OMS_USER.

   Execute integrate.sh

   # as $OMS_USER at $OMS_HOME
   # read $OMS_USER defined at installation.properties
   . etc/installation.properties
    
   # set variable
   # default: /etc/opt/$OMS_USER
   # use "/etc/opt/$OMS_USER" if you don't want to customize the installation layout
   ETC_TARGET=<directory, where to place etc-data>
    
   # copy etc- and var-data to configured locations
   bin/integrate.sh --etc="$ETC_TARGET"

   This will copy the relevant parts to the target directory, defined by the --etc=... command line parameter and $OMS_VAR as defined at installation.properties. It also creates symlinks from $OMS_HOME/etc -> $ETC as well as from $OMS_HOME/var -> $OMS_VAR:

4. Afterwards, check the newly created symlinks in $OMS_HOME directory and delete the temporary directory ETC.VAR.SRC.*, which contains backups of etc- and var-directories.

6.2 Initialize Database with Dump

Import the initial dump for IOM that will contain the basic necessary database configuration. This dump can be found in the IOM delivery package at $OMS_HOME/postgres/dumps.

1. Edit etc/cluster.properties as $OMS_USER if you don't want to use the default PostgreSQL configuration. You don't need to make any changes at the moment, if you want to use a PostgreSQL database at localhost, which was created with default configuration.

   1. Change /system-property=is.oms.db.host to the hostname or IP of the machine hosting your PostgreSQL database
   2. Change /system-property=is.oms.db.port to the the port, where your PostgreSQL server is listening.
   3. Change /system-property=is.oms.db.name to the name of your database dedicated for IOM.
   4. Change /system-property=is.oms.db.user to the name of the user, which should be used to connect to the PostgreSQL database.
   5. Change /system-property=is.oms.db.pass to the password of the user, who is connecting to the PostgreSQL database.
      
      

2. Import is done using the following SQL command.

   Install database dump

   # as $OMS_USER at $OMS_HOME
   # setup environment
   . bin/set_env.sh
    
   # unzip and install initial data dump
   gunzip -c postgres/dumps/OmsDB.initial.2.1.x.x.sql.gz | psql -U $PGUSER -h $PGHOST -p $PGPORT -d $PGDATABASE

6.2.1 Database Migration

Use the the Guide - IOM Database Migration 2.1 if you need to migrate to version 2.1.x.

6.3 Install WildFly

6.3.1 Download and Place the WildFly Installation Package

1. Get the latest version of WildFly 9 from http://wildfly.org/downloads/ (currently 9.0.2) as a tgz archive into $OMS_HOME.

2. As $OMS_USER unpack the downloaded archive into $OMS_HOME and create a symlink to the directory wildfly:

   Install Wildfly

   # as $OMS_USER at $OMS_HOME
   # set variable
   WILDFLY_VERSION=9.0.2.Final
   
   # extract archive and create symbolic link
   tar -xf wildfly-$WILDFLY_VERSION.tar.gz &&
   ln -s wildfly-$WILDFLY_VERSION wildfly &&
   rm wildfly-$WILDFLY_VERSION.tar.gz

   JBOSS_HOME

   If you are installing WildFly exactly this way, no further changes in installation.properties are required. Otherwise you have to adapt JBOSS_HOME.

6.3.2 Install WildFly Application Server as a System Service

IOM release provides a systemd-unit template to install WildFly as a service. The expand_template.sh script uses the environment, hence the information stored in installation.properties, to fill the template. Before expanding the template, make sure you have updated installation.properties. At least the variable JAVA_HOME needs to be adapted.

1. Edit installation.properties.
   1. JAVA_HOME has to be adapted to point to the directory holding the Java 1.8 installation.
   2. JBOSS_JAVA_OPTS might be adapted, if you want change the default memory-configuration, garbage-collection configuration, etc.

2. Expand the systems unit template with current configuration.

   Expand system-unit template

   # as $OMS_USER setup environment
   . bin/set_env.sh
   
   # expand systemd-unit template
   expand_template.sh < $OMS_ETC/jboss-as.service.template > /tmp/jboss-as.service

3. Install WildFly as a service.

   Install Wildfly as a service

   # as root copy expanded template
   cp /tmp/jboss-as.service /etc/systemd/system
   
   # enable service
   systemctl enable jboss-as
   
   # start service
   systemctl start jboss-as

6.4 Prepare WildFly to act as Single IOM Application Server

6.4.1 Configure WildFly

For the following steps, the WildFly application server needs to be running. WildFly will be configured for usage with IOM. 

1. Edit installation.properties.
   1. It is recommended to change the default password defined by JBOSS_ADMIN_PASSWD.

2. Create the admin user, the ejbuser and configure WildFly.

   Configure Wildfly fo version 2.1.0.0

   # as $OMS_USER setup environment
   . bin/set_env.sh
    
   # create admin user for WildFly management
   add-user.sh -u $JBOSS_ADMIN_USER -p $JBOSS_ADMIN_PASSWD
    
   # create ejbuser
   add-user.sh -a -u ejbuser -p Evalolaku416
    
   # load initial configuration of IOM
   jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD --controller=$JBOSS_BIND_ADDRESS -c < $OMS_ETC/initSystem.std.cli
    
   # enhanced standard properties are set in the WildFly 
   update_properties.sh < $OMS_ETC/system.std.properties | jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS
    
   # load $OMS_ETC/cluster.properties
   update_properties.sh < $OMS_ETC/cluster.properties | jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS

   Configure Wildfly from version 2.1.1.0

   # as $OMS_USER setup environment
   . bin/set_env.sh
    
   # create admin user for WildFly management
   add-user.sh -u $JBOSS_ADMIN_USER -p $JBOSS_ADMIN_PASSWD
    
   # create ejbuser
   add-user.sh -a -u ejbuser -p Evalolaku416
    
   # load initial configuration of IOM
   jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD --controller=$JBOSS_BIND_ADDRESS -c < $OMS_ETC/initSystem.std.cli
    
   # enhanced standard properties are set in the WildFly 
   update_properties.sh < $OMS_ETC/system.std.standalone.properties | jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS
    
   # load $OMS_ETC/cluster.properties
   update_properties.sh < $OMS_ETC/cluster.properties | jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS

3. Restart WildFly application server.

   Restart Wildfly

   # as root restart application server
   systemctl restart jboss-as

6.4.2 Deployment Properties

The deployment.properties file is now required to be defined.

6.4.3 Deploy IOM Artifacts

For the following steps, the WildFly application server and the PostgreSQL database need to be running. All deployment artifacts, which are listed in $OMS_ETC/deployment.properties will be deployed into WildFly application server.

1. Deploy all artifacts defined by deployment.properties.

   Deploy IOM artifacts

   # as $OMS_USER setup environment
   . bin/set_env.sh
    
   # deploy all artifacts defined by deployment.properties
   deploy.sh --jboss-cli="jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS"

2. Check wether all artifacts have deployed successfully:

   Get deployment status

   # as $OMS_USER setup environment
   . bin/set_env.sh
    
   # get deployment status
   jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS "deployment-info" 

   Example output for version 2.1.0.0:

   Console output

   NAME                                          RUNTIME-NAME                                  PERSISTENT ENABLED STATUS 
   ArticleQueues-jms.xml                         ArticleQueues-jms.xml                         true       true    OK     
   CacheTopic-jms.xml                            CacheTopic-jms.xml                            true       true    OK     
   CustomerQueues-jms.xml                        CustomerQueues-jms.xml                        true       true    OK     
   OrderQueues-jms.xml                           OrderQueues-jms.xml                           true       true    OK     
   bakery.base-app-2.1.0.0.ear                   bakery.base-app-2.1.0.0.ear                   true       true    OK     
   bakery.communication-app-2.1.0.0.ear          bakery.communication-app-2.1.0.0.ear          true       true    OK     
   bakery.control-app-2.1.0.0.ear                bakery.control-app-2.1.0.0.ear                true       true    OK     
   bakery.impex-app-2.1.0.0.ear                  bakery.impex-app-2.1.0.0.ear                  true       true    OK     
   bakery.omt-app-2.1.0.0.war                    bakery.omt-app-2.1.0.0.war                    true       true    OK     
   bakery.process-app-2.1.0.0.ear                bakery.process-app-2.1.0.0.ear                true       true    OK     
   postgresql-jdbc4                              postgresql-jdbc4                              true       true    OK

6.4.4 Configure Rotation of Access Logs

Sub system undertow is configured to write access logs to $OMS_VAR/log. It is only able to provide a daily rotation of logs. If you want to provide access logs to ICI (Intershop Commerce Insight) in order to get a performance analysis, you need to use hourly rotation of logs. To overcome the limitation of undertow rotation feature, OMS provides a simple shell script to rotate the logs: bin/logrotate.sh.

This script has to be executed at the beginning of every hour, by adding the following line to the crontab of $OMS_USER:

0 * * * *  . $HOME/bin/set_env.sh && logrotate.sh $OMS_VAR/log/access_log.log

0 * * * *  . $HOME/bin/set_env.sh && logrotate.sh $OMS_LOG/access_log.log

7 Distributed installation of IOM

7.1 Prepare an IOM Application Server to act as Backend Server

7.1.1 Prerequisites

IOM application server has to be installed and configured according the instructions in section Prepare WildFly to act as single IOM Application Server. Before starting the following configuration steps, OMS has to be undeployed.

# as $OMS_USER undeploy all artifacts
undeploy.sh --jboss-cli="jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS"

7.1.2 Adapt deployment.properties

1. Edit the content of deployment.properties to contain the following entries only.
   Please take care to use the order of entries exactly as listed here:

   deployment.properties

   CacheTopic-jms.xml
   ArticleQueues-jms.xml
   CustomerQueues-jms.xml
   OrderQueues-jms.xml
   bakery.base-app-2.1.x.x.ear
   bakery.control-app-2.1.x.x.ear
   bakery.process-app-2.1.x.x.ear
   bakery.impex-app-2.1.x.x.ear
   

7.1.3 Adapt installation.properties

1. Set JBOSS_BIND_ADDRESS in installation.properties to an IP address, which is reachable by the frontend application servers.
   It is also possible to use the default value of „0.0.0.0“ here. This value represents „any address“ and covers all available network interfaces.

7.1.4 Adapt cluster.properties

1. Set is.oms.jms.host in cluster.properties to the IP address of the backend application server, which is used by frontend application servers to connect to the backend application server.
   Unless you have set JBOSS_BIND_ADDRESS (in installation.properties) to „any address“ (0.0.0.0), is.oms.jms.host and JBOSS_BIND_ADDRESS have to be identical.

7.1.5 Apply Changes

If you have changed the setting of JBOSS_BIND_ADDRESS in installation.properties, you have to:

1. Recreate the environment, to reconfigure the application server and and to restart it.

   Rebuild environment, recreate configuration of wildfly system service

   # as $OMS_USER recreate environment:
   . $OMS_HOME/bin/set_env.sh
    
   # recreate configuration of WildFly system service
   expand_template.sh < $OMS_ETC/jboss-as.service.template > /tmp/jboss-as.service

   update and restart wildfly system service

   # as root update systems-unit file
   cp /tmp/jboss-as.service /etc/systemd/system
    
   # restart WildFly systemctl restart jboss-as

2. After restarting WildFly, changes of cluster.properties and deployment.properties have to be applied.

   apply configuration changes and redeploy for version 2.1.0.0

   # apply changes of cluster.properties
   update_properties.sh < $OMS_ETC/cluster.properties | jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS
    
   # redeploy OMS according to the changes made to deployment.properties
   deploy.sh --jboss-cli="jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS"

   apply configuration changes and redeploy from version 2.1.1.0

   # apply system properties for backend server
   update_properties.sh < $OMS_ETC/system.std.backend.properties | jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS
    
   # apply changes of cluster.properties
   update_properties.sh < $OMS_ETC/cluster.properties | jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS
    
   # redeploy OMS according to the changes made to deployment.properties
   deploy.sh --jboss-cli="jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS"

7.2 Prepare an IOM Application Server to act as Frontend Server

7.2.1 Prerequisites

IOM application server has to be installed and configured according the instructions in section Prepare WildFly to act as single IOM Application Server. Before starting the following configuration steps:

1. Undeploy the IOM.

   undeploy IOM

   # as $OMS_USER undeploy all artifacts
   undeploy.sh --jboss-cli="jboss-cli.sh -u=$JBOSS_ADMIN_USER -p=$JBOSS_ADMIN_PASSWD -c --controller=$JBOSS_BIND_ADDRESS"

7.2.2 Adapt deployment.properties

1. Change the content of deployment properties to contain the following entries only.
   Please take care to use the order of entries exactly as listed here:

   deployment.properties

   bakery.base-app-2.1.x.x.ear
   bakery.communication-app-2.1.x.x.ear
   bakery.omt-app-2.1.x.x.war

7.2.3 Adapt cluster.properties

1. Set is.oms.jms.host in cluster.properties to the IP address of the backend application server, which is used by frontend application servers to connect to the backend application server.

7.2.4 Apply Changes