Skip to content

Component Deployment Profile File

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.

The sections defining installation dependencies between components are merged into the resulting installation profile file install.ini.

Contents

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.
[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.
[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 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 IFS Cloud platfrom components.
[Layering] Defines the capability of extending the component in Cust layer. Optional.

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.

[Component]

Mandatory. Defines the name of the component.

[Component]  
Name='Component'

[ComponentName]

Defines the description of the component.

[ComponentName]  
Description='Component description'

[ComponentType]

Defines the type of the component.

Example

[ComponentType]  
Type=Base

Valid Types

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.

[IgnoreDeployFiles]

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.

[CapMergeFiles]

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.

[CapMergeFilesLast]

Defining files that should be deployed last in sequence. File2 will be the last deployed.

[CapMergeFilesLast]  
File1=XlrMvUtil.apy   
File2=XlrDimSourceHintItem.apy

[Connections]

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: For direct (hard-coded) API calls to the component.
  • DYNAMIC: For dynamic PL/SQL API calls to the component.

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.

[<component>Defines]

Variables added as DEFINE and UNDEFINE to tem files(s) with predefined values for the component.

[AppsrvDefines]  
CALENDAR_START_DATE=2010-01-01

[<component>Versions]

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.

[<component>PreUpgrade]

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.

Note! The file name and any versions must be separated with a space character. No other white spaces, like Tab, are valid.

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.

[<component>Upgrade]

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:

  • Versions must be defined in chronological order. The last version definition always states current version.
  • Upgrade from one version to the next must always be present even if no changes have to be made to the database. Thus, the number of entries in the upgrade section is always one less than the number of version entries.

[Comments]

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.

Example

[Comments]  
051208 Added dependency to xxxx

[PostInstallationData]

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 installed
  • AnyUpgrade - the file is deployed when the component is lifted from one core version to another
  • Always - 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 deploying

If 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.

Note! The file name and any versions must be separated with a space character. No other white spaces, like Tab, are valid. The line must start with the word File as in example.

Example

[PostInstallationData]  
File1=PostInstallationDataFile1.sql {Always}  
File2=PostInstallationDataFile2.sql {x.x.x;y.y.y}  
File3=PostInstallationDataFile3.sql {AnyUpgrade}

[PostInstallationDataSeq]

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 PostInstallationDatafiles are executed.

Note! The file name and any versions must be separated with a space character. No other white spaces, like Tab, are valid. The line must start with the word File as in example.

Example

[PostInstallationDataSeq]  
File1=PostInstallationDataSeqACCRUL.sql {x.y.x}

[PostInstallationObject]

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.

Note! The file name and any versions must be separated with a space character. No other white spaces, like Tab, are valid. The line must start with the word File as in example.

Example

[PostInstallationObject]  
File1=PostInstallationObjectFile1.sql {FreshInstall;AnyUpgrade}  
File2=PostInstallationObjectFile2.sql {x.y.z}  
File3=PostInstallationObjectFile3.sql {y.x.z}

[PreComponent]

Upgrade from another component, e.g. when one component is split into several 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.

Example

[PreComponent]  
name=fndser

[BuildHomeFiles]

Define files that should be copied to the root of <build_home>.

Example

[BuildHomeFiles]  
File1=Setup.exe

[Bootstrap]

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.

Example

[Bootstrap]  
File1=Installation.api  
File2=Installation.apy  
File3=Bootstrap.cre

[Layering]

This tag restricts Layered Application Architecture by component level. To restrict any customizations to the component, it should be marked as Final as in:

[Layering]  
Implementation=Final

If a component is final, it does not allow customization of any models inside that component or to add any new customization models to the component. Further, code generation is restricted if any of the models are customized within a final component.