Working with Application Configuration Packages¶
The Application Configuration Packages (ACP) functionality provides means to package, export and install certain application-wide configurations They also provide basic lifecycle functionality with the purpose of assisting development and maintenance of such configurations.
ACP makes it very easy to export a large number of custom objects to file at the same time. It is also quick and easy to import those objects into another environment. Export can be to Zip file, or XML files and folder. The Zip file approach is cleaner in most cases (and easier/safer to send as an email attachment).
ACPs are a convenient way to track the development of custom objects over time. If we put the current date into the ACP name we can export it week after week, and thus have a way to look back at what the custom object used to be.
Create Application Configuration Package¶
When developing an Application Configuration Package there are several ways to add Custom Objects to a package. The reason for that is to support a number of different scenarios for under which the package is developed. A package can be developed related to a concept, functionality, business process or practically ad-hoc.
Read about how to Develop a Package.
Export Application Configuration Package¶
A package can be developed for different purposes, but also for different kinds of installations. An exported Application Configuration Package contains configuration items, and the package info, including information about when the package was exported. When exporting the package, also free-text information about the version can be provided.
Read about how to Export a Package.
Install Application Configuration Package¶
There are two ways to install an Application Configuration Package. One way is to install it using IFS Solution Manager. The other way is to use IFS Installer.
Before installing configurations in a target system, it's good to know if this could result in any problems. Before importing configurations, validation is made so that a decision can be made if the installation should continue. Using Solution Manager you can import one package at a time and for each package manually decide to continue or abort the installation based on the validation result. Using IFS Installer, several packages can be imported simultaneously. Those are validated together resolving any dependencies between the packages and items. IFS Installer will only proceed with the installation if there are no validation errors.
Read about how to Install a Package using IFS Solution Manager.
Read about how to Install a Package using IFS Installer.
Handling Single Configuration Items¶
In some scenarios there is just too much administration to create a package in order to export and install configurations. Within the concept, there is also functionality to work with single items.
Read about Single Item Export and Single Item Import.
Validate Application Configuration Package¶
Configurations are dependent on the business logic and can also depend on other configurations. After an upgrade or update of IFS Applications, it is crucial to check the status of existing configurations against the current business logic. The Validate functionality can be used for this to minimize runtime errors.
Read about how to Validate Application Configuration Package.
Important Considerations¶
Any custom object can only be connected to one ACP at a time.
ACPs can be exported and imported by an end user account (with the necessary permissions) as opposed to the application owner account, for which most customers do not have the password. ACPs can be imported using the IFS Cloud Web interface.
There is a deployment sequence in some cases – for example if we have a custom enumeration, a custom persistent field and a custom read-only field that are all related – then they would have to be published in that sequence. If they are in the same ACP, this will probably mean that they need to be published one-by-one.
Consider two environments, a build place environment and CFG. Custom objects W, X and Y are developed in the build place environment, then exported via ACP & imported into CFG. Some time later, in the build place environment, object X is removed and new object Z is added. Then again ACP is exported and imported into CFG. However, the result is that CFG now contains W, X, Y and Z. This is because ACP import does not handle removal of objects that are no longer in the ACP. It only handles new and changed objects currently in the ACP. In this scenario, removal of object X from CFG would have to be done manually.
Another important point is that the custom object pointer is based on the ROWKEY, not the object name. If we independently create the “same” custom object in two environments, they will have differing ROWKEYs. If we try to export one and import it into the other environment, we will receive a conflict; basically the issue is that “another object already exists with that name but a different ROWKEY”.
Known Limitations¶
There is a number of application-wide configuration concepts not handled within Application Configuration Packages. There are also some limitations concerning the supported concepts.
Read about Known Limitations.