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.
[Module]	Defines name of component. Deprecated - use [Component] instead.
[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 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 apply_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 apply_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.
[ShortName]	Define the techncial component name if the name is longer than 6 characters. Deprecated - do not use.

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.
Note: The Build Process validates the deploy.ini files and will raise errors if the files contain invalid information. This includes validating that only the above mentioned profile sections are present in the files as well as validating that each file is consistent within itself by verifying that the versions referenced in the [<component>PreUpgrade], [<component>Upgrade], [PostInstallationData], [PostInstallationDataSeq] and [PostInstallationObject] profile sections are present in the [<component>Versions] profile section.

[Component]¶

Mandatory. Defines the name of the component.

[Component]  
Name=ComponentNameHere

[ComponentName]¶

Defines the description of the component.

[ComponentName]  
Description=ComponentDescriptionHere

[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 apply_install.tem and cleanup_install.tem files. Typically to be used when files are being emptied in support

Files to be ignored are enumerated as in the example below.

[IgnoreDeployFiles]
File1=FileName.cre
File2=FileName.sql

The only requirement on the entry names is that each entry is unique.

[ObsoleteFilesRemove]¶

Defines all files that should be excluded from the Static Code Analysis by IFS Developer Studio. All files listed here should be either emptied or made obsolete in their appropraite way.

When moving to the next Release Update all the previously obsoleted files should be removed from the repository and this section in the deploy.ini should be emptied or removed.

[ObsoleteFilesRemove]
File1=FileName.entity
File2=FileName.plsql

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 connection type to other IFS Components. The connections are defined according to:

[Connections]  
ConnectedComponent=ConnectionType

The connection type is one of the following:

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. At least one STATIC dependency has to be defined, except for component FNDBAS.

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. The versions referenced here have to be present in the [<component>Versions] section. 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 apply_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.
As each version can only have one upgrade script, to be able to interject modification related upgrade scripts between Core upgrade scripts, a "400-Cust.upg" will automatically get executed after "400.upg". "400-Cust.upg" does not have to be listed in the [Upgrade] section for this.
The versions referenced here have to be present in the [<component>Versions] section.

[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 apply_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. i.e. the versions in {} are from which version your component upgrades from. It is possible to enter several versions, then separate the version numbers with a semicolon. When a version is specified, the post script will only run if the component version in the DB matches any of the versions in {}. The versions referenced here have to be present in the [<component>Versions] section.

Instead of setting specific version numbers, these wildcards are available.

FreshInstall - The file is deployed 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 apply_install.tem. This will occur directly after all the PostInstallationData files 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 apply_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 apply_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.