This document describes the Installer from a technical overview perspective. For more details on please read IFS Installer Interface.
The Installer Tool is intended to have a minimum amount of logic. The components file structure, xml-files and plugins owns the logic. The purpose is to be able to add components and functions without modifying or patching the Installer itself.
A component can easily add and modify its own installation scripts or plug ins.
Installer is a java application included in the fndbas component. Besides java it requires ant software to perform its actions. All scripts used for actions are ant scripts.
The Installer can be started both from <build_home>, to install to a target <ifs_home>, and from an existing <ifs_home> for reconfiguration or patching. One <ifs_home> on the target servers disk corresponds to one specific version of IFS Applications.
There are two main sections in the Installer interface
The Installer itself owns the following forms:
| Form | Description |
|---|---|
| Startup Main | Select what main step to execute. |
| Verify Locations | For confirming OS information,<build_home> and <ifs_home> |
| Select Components to Install | What to Install to <ifs_home> |
| Manage Application Server Instance | Name and description for Instance |
| Select Components to Deploy | What to Deploy to a Instance |
| Execute Installation and Deployment Actions | For confirming process start and showing progress log |
The start scripts for Installer, installer.cmd or installer.sh are OS specific and will start by installing java and ant software to a temporary location. Some OS version uses its own java version. The start scripts will in this case, prompt for the location of the local java home.
The Installer will scan all folders in it's <build_home> for config.xml files. They will be parsed and validated. Valid components with a install tag will be automatically included in the installation and components with declaration showme as type in install tag will appear on screen as optional components to install.
The script for Installer will exist in the <ifs_home>, and depending on OS it will be either installer.cmd or installer.sh.
If the Installer started from <build_home> and execution of database code is selected, following steps will be called.
Prepare database / File Executor:
- fileExec step. The step is performed for ALL components
having these tags specified. Only server
component should have this defined in the config_fndbas.xml file.
Deploy Database Objects:
- deployDB step. The step is performed for ALL components
having these tags specified. Only server
component should have this defined in the config_fndbas.xml file.
If the Installer is started from <ifs_home> and a delivery is installed including database code, the deployDB step will be called.
This includes the analyze and install steps. Each step is
performed for ALL components having these tags specified. This means that
the analyze runs first, for ALL components
before running install for ALL components.
The purpose of the analyze step is to investigate the files that will
be installed, and if implemented, can inform the user if specific actions has to
be taken.
This logic is useful when installing deliveries, where different deliveries may
requires different actions to be performed.
An example of this logic is where analyze of the delivery to install will set
the SystemRestart property and give the user a possibility to decide if the
installation process
should stop before Middleware Application Server will be shutdown.
Installers own config.xml is always the first to be processed. After analyze step is executed for ALL components, the install step for the installer will create the base folder structure in <ifs_home> and install itself.
A folder for the current instance is created, <ifs_home>\instance\<instance>, and a ant build.properties file with all properties having ifs. as prefix is created in that folder.
The install step is performed for ALL components before the configuration starts.
The Installer executes what is defined in the components config.xml install tag. To find out what actually is performed, you must analyze the contents of the config.xml.
A normal procedure for install is copying files from <build_home> to <ifs_home>\repository.
This includes the delete, configure, build, post and finalize steps. Each step is performed for ALL components having these tags specified. This means that the delete runs first for ALL components before running configure for ALL components.
The Installer executes what is defined in the components config.xml tags. To find out what actually is performed you must analyze the contents of the config.xml.
Examples:
| Step | Action (example) |
|---|---|
| delete | remove the components files deployed to an Instance |
| configure | edit xml files for the current Instance |
| build | create the Applications j2ee files |
| post | cleanup |
| finalize | finalize |
Installer displays a screen log that should be examined and further logs are located on <ifs_ home>.
| Log file | Description |
|---|---|
| installer.log | The current log for installing to the <ifs_ home> |
| /logs | History logs and other logs |
| /instance/<Instance> | The current log for creating the Instance |
| /instance/<Instance>/logs | History logs |
After a successful installation the System URL is shown in the progress bar field.
If an answer is received on this URL, a call to a welcome page is performed. Depending on OS version a browser will start with the welcome page. You can also double click on the URL to initiate this action.
Installer has created two important xml files holding the configuration for the <ifs_home> and for the Instance.
In <ifs_home> the file is installer.xml
In <ifs_home>/instance/<Instance> the file is <Instance>_configuration.xml.
These files can be used to perform unattended installations. A backup copy of the xml files are saved in the same locations as the log files.