Another use of multiple Applications is to separate out those parts of your Feature Set which are either slow to build or slow to install. Some suggested considerations are:

• Place all the Settings options and all the Additional LANSA Features in one Application. The first Application requires the LANSA Execution Environment and then add in all the other Settings and Additional LANSA Features your Feature Set requires. This separation limits configuration and standard imports to only the time that you need to package a LANSA patch, LANSA EPC or new LANSA version.
  
  

• Place all the LANSA tables in a separate Application. Tables tend to change less frequently and the data in the tables is the most important part of the Application. The fewer times that changes to the tables are even considered, the better it is as this can also be a slow part of the installation if the tables contain a large amount of data which needs to be unloaded and reloaded to apply a table change. Note that when a Patch is created that the Table Data Processing option for every table is set to Exclude data, Reload existing to ensure that the only time the table is processed is if there is a table change to apply.
  
  

• Place all the other application artefacts in one or more Applications. This is the most volatile part of an application and therefore is the most likely to need patching. Limiting what else is in the same Application greatly speeds up building, distributing and installing the Patch. A single artefact change becomes almost instantaneous to install. And the separation also means that no other part of the application is touched by the patch process, greatly reducing the risk of unintended consequences.
  
  

• Put the Web Images in a separate application so the build of the other Applications is faster.
  
  

• The PowerShell installation script needs to launch an appropriate application at the end of the installation. This is particular to each Feature Set so ensure that this is coded for your needs.