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.

During the deployment 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.

Contents

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]

Defines the name of the component. Even the old section [Module] can be used, but is not recommended.

Name='Component'

[ComponentName]

Defines the description of the component.

Description='Component description'

[ComponentType]

Defines the type of the component.

Example

[ComponentType]
Type=WebB2E

Valid Types

Language files for Component Type Translation have special handling in this version of IFS Configuration Builder, all other types will be handled via options in deploy.ini and structure of component.

[IgnoreDeployFiles]

Defines all files that should not be included in the merge process in IFS Configuration Builder, files that are merged and will be called by the install.tem file.

Files to be ignored during the build step are enumerated as in the example below. Wildcard characters (? and *) may be specified.

File1=fileName.cre
File2=*.sql

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

[ObsoleteFilesRemove]

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.

Files that should be skipped are enumerated as in the example below.

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.

[CapMergeFiles]

Defines the order in which files must be called for deployment in the built component file in case there are dependencies between different files of one and the file type. An example of file dependencies and the order in which they are called, is the file <component>.cre (creating tables, indexes etc.) which must be called before any other cre-file that references database objects.

The call order is defined by enumerating them in correct order as in:

File1=Docman.cre

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= 
File2=

[Connections]

Defines connections and type to other IFS Components. The connections are defined according to:

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 use if they are installed. No error will be raised in deployment if these are not included in installation.

[<component>TableSpace]

Defines the substitution variable names used in the scripts for table spaces of data and index storage. Each entry in this section defines a substitution variable used in cre-, upg- and cdb files.
Default value should be set for each variable delimited by ^-character as in example below. The values can be changed by user when creating the installation template, or by editing the final install.tem file.

[AppsrvTableSpace]
APPSRV_DATA=Tablespace for data storage^IFSAPP_DATA
APPSRV_INDEX=Tablespace for index storage^IFSAPP_INDEX
APPSRV_LOB = Tablespace for large objects (LOB) storage^IFSAPP_LOB
APPSRV_MVIEW_DATA = Tablespace for materialized view data storage^IFSAPP_DATA
APPSRV_MVIEW_INDEX = Tablespace for materialized view index storage^IFSAPP_INDEX

[<component>InstallDialog]

Defines any additional substitution variables that should be set for the component before creating the final install.tem. These variables can be defined in two different type of sections, SelectVariableSet or PromptVariable.

Note: Every section should be prefixed with '<component>'. The section will be validated and matched with the name defined in section [Component]. The section names must be unique and the sub sections do not have fixed or predefined names, except for the prefix.

SectionName=TypeOfSection

Type of section is either of:

• SelectVariableSet
  Means that the stated section contains a list of additional section names from which you must select one in order to define a set of substitution variables.
  Default value can be set, but not required. In example Default=1 means that the second selection is by default selected. Default=0 is the first selection.

         Example

[PrjrepInstallDialog]
PrjrepInvoicIntegration = SelectVariableSet

[PrjrepInvoicIntegration]
PrjrepInvoicYes = Install integration to Invoic, Invoic must exist in database. <See Info>
PrjrepInvoicNo = Do not install integration to Invoic
Default=1

[PrjrepInvoicYes]
IFDEF_INVOIC = 
ENDIF_INVOIC =

[PrjrepInvoicNo]
IFDEF_INVOIC = /*
ENDIF_INVOIC = */

• PromptVariable
  Means that the stated section contains definitions to define a single substitution variable.

      Example

[AppsrvInstallDialog]
AppsrvCalendarStartDate=PromptVariable
AppsrvCalendarEndDate=PromptVariable

[AppsrvCalendarStartDate]
Variable=CALENDAR_START_DATE
Prompt=Start date for default calendar (YYYY-MM-DD) - must be a Monday
LOV=2005-12-26
Default=2005-12-26

[AppsrvCalendarEndDate]
Variable=CALENDAR_END_DATE
Prompt=End date for default calendar (YYYY-MM-DD)
LOV=2016-12-31
Default=2016-12-31

[<component>Versions]

Defines each and every version of the component ever released. A released version is defined according to:

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>Upgrade]

Define the names of the script files that has to be executed in order to upgrade from any released 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 made version for version according to:

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 is:

[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

[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

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.

[<component>Information]

This section gives the developer the possibility to display important installation information in the Information field when selecting Create Installation Template for Database Objects / Edit Settings in IFS Configuration Builder.When selecting the component in Components, the Information field will be shown. This section is only for very important installation information and should not include the whole readme-file. Every new row needs a unique identification like 1,2,3,4.

Example:

[FndbasInformation]
1=This is just an example of how to display
2=important installation information in IFS Configuration
3=Builder for a component.

 [ComponentOptions]

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:

Example 1

[ComponentOptions]
1=LanguageFiles 
2=InstallationOS 
 …

[LanguageFiles]
Option1=EnglishLanguageFiles
Option2=SwedishLanguageFiles
…

[EnglishLanguageFiles]
prompt=Install English language files
path=\LanguageFiles\English
structure=KEEP 
unique=YES

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

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.

Example 2

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

 [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 component have been deployed to the database, after the PostInstallationObjects have been executed and refreshed..

Example

[PostInstallationData]
File1=PostInstallationDataACCRUL.sql

[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 component have been deployed to the database.

Example

[PostInstallationObject]
File1=GrantFndWebconfig.sql

[PreComponent]

Upgrade from other component, when new components are split into more than one or changing names

Example

[PreComponent]
name=fndfnd

[BuildHomeFiles]

For 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

[ShortName]

The name the component will have in module_Tab when registred by install.tem. Used for ComponentType PRODUCT.

Example

[ShortName]
Name=PRDIST