This document describes possible configuration while executing database files, e.g. Prepare Database or Deploy Database Objects, from IFS Applications Installer
Fresh install, upgrading and patching.
There are several commands that control the behavior of the IFS Installer when deploying database files. The majority of them do not need any further parameters then just the command itself but some them also need to be named (normally with a component name). The simple commands are described in the table below and the more complex ones are described in separate sections.
-- [IFS COMPLETE BLOCK PACKAGE Account_API]
| Start tag | End tag | Description |
|---|---|---|
| -- [IGNORE IN INSTALLER] | -- [END IGNORE IN INSTALLER] | All commands between these tags are ignored when running the script from IFS Installer. They are only executed when using SQL*Plus. |
| -- [IGNORE IN MULTI INSTALL] | -- [END IGNORE IN MULTI INSTALL] | All commands between these tags are ignored when running the script in multi-delivery mode. This is to exclude unnecessary multiple executions of the same code, e.g. compile of invalid objects. |
| -- [IFS COMPLETE BLOCK <Type> <Name>] | -- [END IFS COMPLETE BLOCK] | Tells that the block between these tags is a complete command and can be executed as is. The tags are added for performance reasons since the installer does not need to parse this code block. The types supported are package, package body, view, procedure, function, declareend, and beginend. All but the last two must come with the name of the object. |
| -- [DB GENERAL] | -- [END DB GENERAL] | Commands between these tags are executed as first commands in all database sessions that are opened during the installation process. Only one DB GENERAL section is allowed in the installation. |
| -- [DB FINAL] | -- [END DB FINAL] | Commands between these tags are executed at the very end of the installation, also in an aborted installation. Only one DB FINAL section is allowed in the installation. |
| -- [NO EXTENDED LOGGING] | -- [END NO EXTENDED LOGGING] | Tells that no extended logging is done between these tags. Could be useful if you are spooling to a command file. Note! Start deploying another file in this section is not allowed |
| -- [NO DEPLOY LOGGING] | -- [END NO DEPLOY LOGGING] | Temporary disables the logging into the _deploy.log and the online windows log. This is used when a lot of details are logged, or when a temporary file for deployment is generated. |
| -- [Thread packed components] | -- [End thread] | Components in this area are installed in parallel threads. Files are packed into <component>.<type> files, e.g. fndbas.api, which are called from the install.tem file (or other tem file). The <component>.ins is executed in an own thread. |
| -- [Thread outlined components] | -- [End thread] | Components in this area are installed in parallel threads. Files are outlined in the install.tem file (or other tem file). All files from one component are executed in one thread only. |
| -- [Component <component>] | -- [End Component] | Defines the start and end of a component (inside a threading of components area). |
| -- [Thread SQL_COMMANDS] | -- [End thread] | The SQL commands inside this sections are executed in parallel threads. |
| -- [SQL_COMMAND <command>] | -- [End SQL_COMMAND] | Defines the start and end of a SQL command (inside a threading of SQL commands area). Each SQL Command must have an unique name. |
IFS Installer Loop enables the installer to halt the installation process until a certain condition is fulfilled. The condition is checked against a return value from a database function call.
When the installer find a IFS Installer Loop in a database script file, like
install.tem, a database function is called and the result is compared
against a conditional value. If the condition is fulfilled, the installation
process continues, otherwise the installer halts for a while before it call the
method again to get a fresh value for a new comparison. You can also define that
a new database call should be initialized by the technician instead of a few
seconds wait. The
technician can also decide to break the loop and let the installation
process continue by pressing the Break button in the popup dialog (the actual
text at the Break button is dynamic depending on available options).
The format for IFS Installer Loop is -- [IFS INSTALLER LOOP ; <parameter>... ; ]. The
parameters are separated by a semicolon and there has to be a final semicolon
after the last parameter. Do not separate the parameters and the equal signs
with space characters!
The available option parameters are described in the table below.
| Parameter | Description |
|---|---|
| DBMETHOD | Name of the database function to call. This parameter is mandatory. |
| CONDITION | When the function return this value the installation process continues. Several values are possible, list them separated by a comma sign (e.g. 1,2,3). This parameter is mandatory. |
| LOOPMETHOD | AUTO(MATIC) or MANUAL. Tells whether the installer automatically should call the database to check for the current value or if the technician should initialize a new call. If automatic mode is selected, a new call is executed every 3rd second. This parameter is mandatory. |
| RETRYMETHOD | Method to be executed in the database in purpose to adjust what is blocking the process, e.g. compile invalid objects in the database. |
| DISCLAIMER | The text to show in the popup dialog when try to fix is chosen. |
| PROMPT | Information text to be displayed in the popup dialog. This text is always appended with Expected value(s) and Current value. Additional output may also occur in the logging window. This parameter is mandatory. |
| ABORT | TRUE or FALSE (default). An abort button is enabled in the popup dialog that makes it possible to abort the entire installation process. |
| IGNORE | TRUE or FALSE (default). An ignore button is enabled in the popup dialog that makes it possible to ignore the issue that halts the installation process and continue regardless. |
| WHEN | B or I. When, depending on where you are running the installer from, the condition should be verified or not. Either it is the B(uild_home) or the I(FS_home). Both values, i.e. BI, is a valid option but also no value which means that the condition will be always verified. |
| SILENT | TRUE (default) or FALSE. Tells whether this condition should be executed or not when then installation process is running in silent mode. When running in silent mode, the LOOPMETHOD is set to AUTOMATIC. To avoid a hangup situation when no one is guarding the installation process, the defined maximum waiting time in silent mode is set to 10 minutes. |
| ACCEPTERROR | NONE (default), ALL or NOTEXIST. If the database call returns any errors, should they be accepted or written in the error log? NONE accept no errors and write them in error log while ALL accept all errors without raising any error flag. The NOTEXIST do not accept any errors except when the specified dbmethod cannot be found in the database. If the database call returns an error, the installation process continues directly. |
Before an installation starts it could be wise to verify that no database scheduled tasks are running since they might interfere the installation process. How you set up a loop that automatically waits until all running tasks are completed is shown below, but also how the popup dialog will locks like.
-- [IFS INSTALLER LOOP ; DBMETHOD=Install_Tem_SYS.Show_Scheduler_Processes ; CONDITION=0, ; LOOPMETHOD=AUTOMATIC ; PROMPT=Waiting for running job(s) to stop ; ABORT=TRUE ; ]
In another example, we check for invalid objects before we start the
installation. In this case, it should be able to abort the process if invalids
are found. Also, this condition is not relevant to check in silent mode why the
silent parameter is set to FALSE. The operator may also try run the method
Database_SYS.Compile_All_Invalid_Objects to re-compile the invalid
objects.
-- [IFS INSTALLER LOOP ; DBMETHOD=Install_Tem_SYS.Show_Db_Obj_Invalid_Count ; RETRYMETHOD=Database_SYS.Compile_All_Invalid_Objects ; CONDITION=0, ; LOOPMETHOD=MANUAL ; PROMPT=Number of invalid objects ; ABORT=TRUE ; ACCEPTERROR=NOTEXIST ; SILENT=FALSE ; ]
IFS Installer Accept is an extension to the ACCEPT command in
SQL*Plus. The purpose with both commands is to request for a value on a
variable which is used in the installation process. When running the IFS Installer both
variants result in an popup query dialog where the technician should enter the
requested value but the IFS Installer Accept enables more configuration possibilities. And of course, the
IFS Installer Accept is
only working in IFS Installer, and not in SQL*Plus. ACCEPT
is working both in IFS Installer and SQL*Plus.
The format for IFS Installer Accept is -- [IFS INSTALLER ACCEPT ; <parameter>... ; ]. The
parameters are separated by a semicolon and there has to be a final semicolon
after the last parameter. Do not separate the parameters and the equal signs
with space characters!
The available option parameters are described in the table below.
| Parameter | Description |
|---|---|
| ALIAS | Name of the variable to set. The variable will be displayed in the header of the query dialog. This parameter is mandatory |
| PROMPT | A describing text displayed in the query dialog. If not included, a standard text will be used. |
| MANDATORY | Tells that this value is mandatory, you cannot proceed without giving a value |
| DEFAULT | A default value to use if reply is not given. |
| DEFHIDDEN | A default value to use if the question isn't raised, i.e. when running in hidden mode. If not set, the DEFAULT value is used. |
| DEFHIDDEN_B | Same as above, but this default value is only used when running the installer from a B(uild_home). |
| DEFHIDDEN_I | Same as above, but this default value is only used when running the installer from n I(FS_home). |
| WHEN | B or I. When, depending on where you are running the installer from, the question should be raised or not. Either it is the B(uild_home) or the I(FS_home). Both values, i.e. BI, is a valid option but also no value which means that the question will be always raised. |
| CONFIRM | TRUE or FALSE (default). The reply must be entered twice to confirm that they are equal. Occurs often together with the HIDE option. |
| HIDE | TRUE or FALSE (default). Suppresses the display as you type the reply |
| DBMETHOD | Name of a database function to call in order to verify whether this variable should be requested or not. |
| CONDITION | When the database function return this value, the variable is requested. Several values are possible, list them separated by a comma sign (e.g. 1,2,3). |
Requesting for passwords is a typical example where you could use the
hide option to suppress the display. But as the text is hidden, you
should let the technician confirm the password to make sure
that the correct one is entered. How this is set up and the outcome is shown
below.
-- [IFS INSTALLER ACCEPT ; ALIAS=IFSSYS_PASSWORD ; PROMPT=Set password when creating a new system user (IFSSYS) ; DBMETHOD=&APPLICATION_OWNER..Install_Tem_SYS.User_Exist('IFSSYS') ; CONDITION=0, ; CONFIRM=TRUE ; HIDE=TRUE ; DEFAULT= ; ]
Define.tem is a file for defining variables during deployment. It should be included in every script you execute when you deploy IFS Applications. This is automatically done when database files are generated for the deployment and nothing you need to add extra unless it is a manually processed file. A template of define.tem file is located together with the other database script templates, i.e. in folder fndbas/template/fndbas or just template/fndbas if you look in your build_home. When your database files are generated, the define.tem is copied into the build_home/database folder. The file contains some variables with default values but they are able to change to suite your installation. Any changes are done either directly in the file or from the IFS Applications Installer.
Note: If you override the default values, make sure that all (alphabetic) values are given in uppercase format.
| Variable | Comment | Default value | Where used |
|---|---|---|---|
| APPLICATION_OWNER | The name of the application owner | IFSAPP | Prepare DB and Deploy DB objects |
| TABLESPACE_PREFIX | Prefix for the tablespace names, _DATA, _INDEX etc. will be added | IFSAPP | Prepare DB and Deploy DB objects |
| <TABLESPACE NAME> |
The actual name of the tablespaces, a concatanation of the TABLESPACE_PREFIX
and some standard suffixes. These values should normally not be changed |
Prepare DB | |
| <TABLESPACE PATH> | Individual path to each tablespace. If DEFAULT value is used, they will be placed where the SYSTEM tablespace is found | Prepare DB | |
| TEMP_TABLESPACE | The temporary tablespace given to the application owner | TEMP | Prepare DB and Deploy DB objects |
| IAL_OWNER | The name of the information access layer (IAL) owner | IFSINFO | Prepare DB and Deploy DB objects |
| DO_PUBLIC_REVOKE | Should UTL privileges be revoked from the public role, Y or N | Y | Prepare DB |
| INTERNAL_USER_PROFILE | Default Oracle profile for internal IFS users | IFS_INTERNAL | Prepare DB and Deploy DB objects |
| DAYS_TO_KEEP_INSTALL_LOG | Number of days for keeping install_tem_sys logs | 30 | Prepare DB |
| REMOVE_DEBUG_INFO | Should debugging information be removed from database objects, Y or N | Y | Deploy DB objects |
| COMPILE_OTHER_SCHEMA | Should other schemas than application owner be compiled after an installation, Y or N | Y | Deploy DB objects |
| SHOW_NEW_INVALIDS | Should new invalid objects be listed in the error log after an installation, Y or N | Y | Deploy DB objects |
| ENABLE_ROWKEY_HOURS | For how many hours should rowkeys be enabled, UNLIMITED, 0, 1, 2, 3, 4, 6, 8, 12 | UNLIMITED | Deploy DB objects |
| DEF_ENABLE_SEARCH_DOMAIN | Should Search Domains be enabled by default, Yes or No | Yes | Deploy DB objects |
| DEF_CONVERT_LOBS | Should LOB columns be converted to secure files by default, Yes or No | Yes | Deploy DB objects |
| JOB_QUEUE_PROCESSES | Numbers of job queue processes during deployment (5 or higher) | 16 | Deploy DB objects |
