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

Deployment

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 and Post_Installation_Data. The 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.

The Post_Installation_Object and 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.

Coding recommendations

There are some recommendations to follow when writing thePost_Installation_Object and 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. Post_Installation_Object and Post_Installation_Data are executed if the component itself is included in the delivery or if any dynamic dependent component is included in the delivery. 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 of course also in a fresh install and in an upgrade).

Post Installation after Import Data

After the install.tem has been executed, importing of data like translations, lobbies, reports is executed. Some of the imported data maybe need some post methods to be called in the database, e.g. grant permissions to imported lobbies. By adding a plsql method called Post_Installation_Import_Data in a package named <component>_Installation_API that will have the e.g. grant logic, will achieve this. When there exist anything to import, as last execution, the Post_Installation_Import_Data will be called.