Post Installation Methods¶
Objects that has dynamic dependencies to other components cannot be created before all components are in place. The same goes for default data that is inserted during a deployment, if the data is dynamically dependent on other components it must be done late in the deployment process.
There are two ways to solve this, either by write a plsql method called
Post_Installation_Data in a package preferably named <component>_Installation_API, or write a SQL scripts and list the script in deploy.ini as [PostInstallationObject] for adding database objects and [PostInstallationData] or [PostInstallationDataSeq] for data manipulation. How to write these scripts is described here, and how to setup deploy.ini is described here.
There is one exception to this, views with dynamic dependencies should not be declared in
Post_Installation_Object. Instead, all views, no matter if they have dynamic dependencies or not, should be declared in the.views files. How to write views with conditional dependencies is described here. Views with dynamic dependencies are generated in the build process into methods called
Post_Installation_View. Note that these methods cannot be manually written, not even overridden or overtaken
As a part of install.tem, i.e. the deployment of the database parts in a delivery, installation or upgrade, calls are done to all plsql methods named
Post_Installation_Object methods are executed after all components are deployed, and after the scripts defined as [PostInstallationObject]. This means that no internal caches are updated at this point, in difference to
Post_Installation_Data methods, which are executed after the internal caches that concern the dictionary are updated. Caches that are data dependent (security, reports etc.) are updated even later in the process. The [PostInstallationData] or [PostInstallationDataSeq] scripts are deployed before the
Post_Installation_Data methods are executed.
Post_Installation_Data methods are executed in parallel with other components following the component static dependency order. The execution order inside each component is in alphabetical order on the package name, but if there exist a method in the package called <component>_Installation_API, it is always is executed as the first method.
There are some recommendations to follow when writing the
Post_Installation_Data methods . The most important one is to keep them small. Put as little code as possible in them, and as much as possible in the [PostInstallationObject], [PostInstallationData] and [PostInstallationDataSeq] scripts. The reason for this is that these methods are executed in almost every delivery (as long as there is database files included), but it also depends on which components that are included in delivery - see details below. Methods that are heavy to execute will make the performance to suffer. Most probably it is enough to execute the logic once, and only a second time if something is changed. The [PostInstallationObject], [PostInstallationData] and [PostInstallationDataSeq] scripts are executed only when they are changed (and off course also in a fresh install and in an upgrade).
There is a difference between
Post_Installation_Data methods when it comes to executing during deployment. All
Post_Installation_Data methods are actually executed in every delivery but the
Post_Installation_Object methods are only executed if the component itself is included in the delivery or if any dynamic dependent component is included in the delivery. From the framework, it cannot be decided which
Post_Installation_Data methods to run but as owner of the method it is possible to exclude code from being executed if not needed. Below example illustrates how it typically might look like in the component PROJ. The method Post_Installation_Data exists in PROJ component and from this method there is a dynamic dependency to COST component. Then, it is recommended to check if either PROJ or COST are included in the delivery before executing the code since any of those components can be added or modified in any delivery after IFS Cloud installation.
The example uses the method
Module_API.Is_Included_In_Delivery to check if a component is included in the delivery. Optionally, there is the method
Module_API.Is_Affected_By_Delivery, which returns TRUE if the component is included in the delivery or if it has any dynamically dependent components in the delivery. This indicates that the
Post_Installation_Object methods have been executed for this component, which in some cases could be relevant to know when the
Post_Installation_Data methods are executed. These Post Installation methods are only supposed to be executed during deployment, and these functions in
Module_API will never return TRUE outside a deployment run. If there is a possibility that a
Post_Installation_Data method is executed at any other moment in time, you need to include a call to
Installation_SYS.Get_Installation_Mode as well.