The deployment and installation properties of a component are defined in the profile file deploy.ini. The file is structured like an ordinary ini-file with sections and entry names.
During the build process, the file is read to ensure that the correct subset of files is being collected to the <build_home> directory. At the same time, the sections defining installation dependencies between components are merged into the resulting installation profile file install.ini.
Part of the definitions are relevant for IFS Configuration Builder and part in the database file generation process when the files are merged and the tem file(s) are created.
Profile Section | Description |
---|---|
[Component] | Defines name of component. Mandatory. |
[ComponentName] | Defines the description of the component. |
[ComponentType] | Defines type of component. |
[IgnoreDeployFiles] | Defines all files, of types managed by the database file generation process, that are not to be merged at all. |
[ObsoleteFilesRemove] | Defines files that should be skipped in fetch process. For fetch during update scenarios, even obsolete files will be fetched anyway if they are modified. |
[CapMergeFiles] | Defines the order in which files must be merged into the build component file in case there are dependencies between different files of one and the same file type. |
[CapMergeFilesLast] | Defining files that should be deployed last in sequence. |
[Connections] | Defines connections and type to other IFS Components. Mandatory. |
[<component>Defines] | Define variables added to tem files(s) with predefined values. |
[<component>Versions] | Defines each and every version of the component ever released. Mandatory. |
[<component>PreUpgrade] | Define the name of the file that has to be executed for a specific version before any component has been upgraded. |
[<component>Upgrade] | Define the names of the files that have to be executed in order to upgrade from any supported version to current. |
[ComponentOptions] | ComponentOptions gives the possibility to include own file options. |
[Comments] | Comments in the deploy.ini. |
[PostInstallationData] | Defines files that will be executed in the PostInstallationData section in Install.tem. This will occur after all components have been deployed to the database, after the PostInstallationObjects have been executed and the dictionary and reference caches are refreshed. Depending on which version you start on, it is possible to define if the files should be executed or not. |
[PostInstallationDataSeq] | Same as PostInstallationData but the files listed in this section will be deployed in sequence and not in parallel with files from other components in order to avoid lock situations. This section will occur directly after all the PostInstallationData files are executed. |
[PostInstallationObject] | Defines files that will be executed in the PostInstallationObject section in Install.tem. This will occur after all components have been deployed to the database. Depending on which version you start on, it is possible to define if the files should be executed or not. |
[PreComponent] | Names a component preceding the current one. Use this when renaming, merging or splitting components. |
[BuildHomeFiles] | Define files that should be copied to the root of <build_home>. |
[Bootstrap] | Defines files that should be deployed before any component. Note: This section should only be used by Foundation1 components. |
[ShortName] | The name the component will have in module_tab when registered by install.tem. |
Note: The component in sections prefixed with
'<component>' is validated and matched with the name defined in section [Component]
.
The section names must be unique.
Mandatory. Defines the name of the component. Even the old section [Module] can be used, but is not recommended.
[Component] Name='Component'
Defines the description of the component.
[ComponentName] Description='Component description'
Defines the type of the component.
[ComponentType] Type=Base
Type | Description |
---|---|
Base | Base components |
ExtendedApplication | Components running in Extended Server, for example BizAPI's and similar functionality |
External | All components not deployed via framework tools |
Framework | Extended Server components |
Product | Prod components |
Trans | Component containing language files |
Language files in a component with Type=Trans have special handling in IFS Configuration Builder, where the check of component name in language files will be ignored.
Defines all files that should not be included in the merge process, i.e. files that are merged and will be called by the install.tem file. Typically to be used when files are being emptied in support
Files to be ignored are enumerated as in the example below. Wildcard characters (? and *) may be specified.
[IgnoreDeployFiles] File1=fileName.cre File2=*.sql
The only requirement on the entry names is that each entry is unique.
Defines files that should be skipped in fetch process. This feature can be used to enable the possibility to specify files that should be obsolete in the build process, but is not possible to remove from the archive. If defined, these definitions will be written to the fetch log file, if named file(s) found in the the fetch process. Note that modified files are still fetched in an update process even if they are listed as obsolete.
Files that should be skipped are enumerated as in the example below.
[ObsoleteFilesRemove] File1=ObsoleteFile.txt File2=*.txt File3=[sub path]\*.* File4=[sub path]\[parent folder]\*
If *.* is defined, all files in the folder will be skipped but not file(s) in sub folder(s).
If only * character is defined, all files and sub folder(s) will be skipped and also the parent folder.
Defines the order in which files must be called for deployment in the merged component file in case there are dependencies between different files of one and the same file type.
The call order is defined by enumerating them in correct order as in:
[CapMergeFiles] File1=ObjectProperty.apy
The only requirement on the entry names is that each entry is unique. Note that it is not necessary to name all files, list only the ones that are required before any other. Files not defined here, or if this section is not present at all, are always merged in alphabetical order.
Defining files that should be deployed last in sequence. File2 will be the last deployed.
[CapMergeFilesLast] File1=XlrMvUtil.apy File2=XlrDimSourceHintItem.apy
Mandatory. Defines connections and type to other IFS Components. The connections are defined according to:
[Connections] ConnectedComponent=ConnectionType
The connection type is either of:
STATIC dependency definition will sort the components installation order. A STATIC dependent component has to be installed before actual one.
DYNAMIC dependency is a list of components the actual component will access using conditional compilation or other dynamic coding technique if they are installed. No error will be raised in deployment if these are not included in installation.
Variables added as DEFINE and UNDEFINE to tem files(s) with predefined values for the component.
[AppsrvDefines] CALENDAR_START_DATE=2010-01-01
Mandatory. Defines each and every version of the component that is still supported. A released version is defined according to:
[AppsrvVersions] x.y.z=VersionDescription
The version definitions are used to mark each installed component with its version and to detect how upgrades must be performed. Adapted component versions must be entered here as well to provide the marking and upgrade functionality.
Define the name of the file that has to be executed for a specific version before any component has been upgraded.
Only the defined files will be executed for the selected upgrade version for your
component. It is possible to enter several versions, then separate the version
numbers with a semicolon. Available wildcards are FreshInstall
, AnyUpgrade
and
Always
. If no specific version is given, the file will be executed in
every installation the file is available, i.e. it is equal to the wildcard
Always
.
The preUpgrade definitions are created version by version according to:
[AppsrvPreUpgrade] File1=appsrvpre.sql {x.x.x;y.y.y}
This logic could be used when it is necessary to be able to execute some pre
upgrade statements, using the existing packages in the database.
Note! This defined file will be executed before any component has been upgraded,
in a pre upgrade section in the install.tem template file.
Define the names of the script files that has to be executed in order to upgrade from any supported version to current. During the deployment process, these script file definitions are used to create the <component>.upg. This single upgrade file is a merge of all upgrade scripts with a version marker between each upgrade sequence.
The upgrade definitions are created version by version according to:
[AppsrvUpgrade] x.y.z=x1y1z1.upg
defining that in order to upgrade from version x.y.z to version x1.y1.z1 the script x1y1z1.upg is to be executed. An example of the [<component>Versions] and [<component>Upgrade] sections illustrating how they must be constructed:
[AppsrvVersions] 3.2.0=Application Services version 3.2.0 3.2.0-MCE=Application Services version 3.2.0-MCE 3.2.0.A=Application Services version 3.2.0.A 3.3.0=Application Services version 3.3.0 3.4.0=Application Services version 3.4.0 3.5.0=Application Services version 3.5.0 3.6.0=Application Services version 3.6.0 4.0.0=Application Services version 4.0.0 4.1.0=Application Services version 4.1.0[AppsrvUpgrade] 3.2.0= 3.2.0-MCE= 3.2.0.A=330.upg 3.3.0=340.upg 3.4.0=350.upg 3.5.0=360.upg 3.6.0=400.upg 4.0.0=410.upg
Note the following:
The ComponentOptions
gives IFS Configuration Builder the possibility to access data based on
options, stored in some kind of structure. IFS Configuration Builder will read
deploy.ini and if any ComponentOptions
exist, the path supplied in it
will redirect IFS Configuration Builder to the proper
directory to fetch the files. This option could e.g. include hardware dependent installationfiles.
The files and folders affected by ComponentOptions
should exist in
the folder conditionalbuild in the
component. When specifying the path in the section, folder name itself,
conditionalbuild,
should be left out. The use of ComponentOptions
result in subsections in deploy.ini.
All entries in ComponentOptions
must have a subsection if
it should be used and all options in ComponentOptions
must have a
subsection. The last section must
include entries prompt, path
and unique
.
When unique
is set to YES
the user have to select one option
only. When unique
is set to NO
, then no rules exist for the selection.
When structure
parameter has value KEEP
then the whole subdirectory including the directory will be copied to the
build destination, <build_home>.
[ComponentOptions] 1=LanguageFiles 2=InstallationOS … [LanguageFiles] Option1=EnglishLanguageFiles Option2=SwedishLanguageFiles … [EnglishLanguageFiles] prompt=Install English language files path=\LanguageFiles\English structure=KEEP unique=YES
When structure
parameter has value
MULTIPLE
then
all files and folders in the defined path will be copied to the
build destination, <build_home>.
Using this feature, you can for example define files in
folders that should copied on the build destination, e.g. source and model
folders.
[ComponentOptions] 1=Solution … [Solution] Option1=SolutionFiles1 Option2=SolutionFiles2 … [SolutionFiles1] prompt=Add Solution Files 1 path=SolutionFiles1 structure=MULTIPLE unique=NO
When structure
is not defined, then an additional
subfolder should be created in the structure, and the files/folders should be
placed into that subfolder. When running the build step, the content of the
additional subfolder will be copied one level up
in the folder stucture in the build destination. Using
this feature, you can for example define separate files that should be deployed into
database depending on what user has selected.
[ComponentOptions] 1=OPTIONPI 2=OPTIONSV ... [OPTIONPI] 1=ConnectionToPi [ConnectionToPi] prompt=Install Connection to PI-Salary path=\database\payint\PI unique=NO [OPTIONSV] 2=ConnectionToSv [ConnectionToSv] prompt=Install Connection to Swedish Salary path=\database\payint\SV unique=NO
There is also a possibility to use ComponentOptions
without question in deploy
process.
Typically this is used for copying structures from the components into the
build target folder. To accomplish this simply set the prompt=NOPROMPT.
Section comments can include comments about the deploy.ini file. Example to useful comments are history over all changes made to the deploy.ini file.
[Comments] 051208 Added dependency to xxxx
Use the PostInstallationData
tag in your component deploy.ini when
there is a need to create/update/move data on other sources, where the oracle
object you want to use, may not have been created yet.
Defines files that will be executed in the PostInstallationData
section in
install.tem. This will occur after all components have been deployed to the
database, after the PostInstallationObjects
have been executed and
the runtime caches have been refreshed. For better performance, files are
executed in parallel with files from other components, without breaking the
component dependency order.
Files will only be executed for the selected upgrade version for your component. It is possible to enter several versions, then separate the version numbers with a semicolon. Instead of setting specific version numbers, these wildcards are available
FreshInstall
- the file is deployed the when the component
is initially installedAnyUpgrade
- the file is deployed when the component is
lifted from one core version to anotherAlways
- the file is always deployed. This means in fresh
installs, upgrades and in deliveries, but only in deliveries where the file
is touched and by that included in the Update or the single patch you are
deployingIf no specific version or no wildcard is given, the file will be executed in
every installation the file is available, i.e. it is equal to the wildcard
Always
.
[PostInstallationData] File1=PostInstallationDataFile1.sql {Always} File2=PostInstallationDataFile2.sql {x.x.x;y.y.y} File3=PostInstallationDataFile3.sql {AnyUpgrade}
Use the PostInstallationDataSeq
tag with the same purpose as PostInstallationData
tag, i.e. when
there is a need to create/update/move data on other sources, where the oracle
object you want to use, may not have been created yet. In difference to files in
the PostInstallationData
section, where files are deployed in
parallel with files from other components, files in this section are deployed in
sequence, and follow the component dependency order.
Files will be deployed according to the same rules that are described in [PostInstalllationData] section.
Note: Files should only be listed here if there is a risk that lock situations may occur due to files from other components are updating the same data at the same time.
Defines files that will be executed in the PostInstallationDataSeq
section in
install.tem. This will occur directly after all the PostInstallationData
files are executed.
[PostInstallationDataSeq] File1=PostInstallationDataSeqACCRUL.sql {x.y.x}
Use the PostInstallationObject
tag in your component deploy.ini
when you need to create oracle objects based on other sources, where the oracle
object you want to use, may not have been created yet.
Defines files that will be executed in the PostInstallationObject
section in
install.tem. This will occur after all components have been deployed to the
database. For better performance, files are executed in parallel with files from
other components, without breaking the component dependency order.
Files will be deployed according to the same rules that are described in [PostInstalllationData] section.
[PostInstallationObject] File1=PostInstallationObjectFile1.sql {FreshInstall;AnyUpgrade} File2=PostInstallationObjectFile2.sql {x.y.z} File3=PostInstallationObjectFile3.sql {y.x.z}
Upgrade from another component, e.g. when one component is split into several, when several components are merged into one, or when the name of a component is changed.
When setting the starting version number on a new component with a preceding component, it is recommended to continue on the sequence from the preceding component rather than restart on 1.0.0 for the new one. E.g. if the last version of the preceding component fndser was 3.0.0, then the first version of the new component fndbas should be 4.0.0.
[PreComponent] name=fndser
Define files that should be copied to the root of <build_home>.
[BuildHomeFiles] File1=Setup.exe
Use the Bootstrap
tag in your component deploy.ini to
list files that should be deployed before any component.
Note: This section should only be used by Foundation1 components.
Defines files that should be executed in the BootStrapSection
section in
install.tem. This will occur before any component have been deployed to the
database.
[Bootstrap] File1=Installation.api File2=Installation.apy File3=Bootstrap.cre
The name the component will have in module_tab when registered by install.tem. Used for ComponentType PRODUCT.
[ShortName] Name=PRDIST