Packaging makes permanent changes to your system, so you must be aware of certain factors and considerations before you begin.
On this page
Database back up and recovery
There is no Undo function for a package installation.
Back up the instance database before installing a package.
An alternate to backing up the instance is to create a package of the affected objects in the target instance before installing the new package. This package provides a snapshot of the instance before the new package is installed, which can be used to help undo the changes made by the package installation. New objects created by the package installation must be manually deleted.
Packaging impact on system performance
System performance may vary based on the size of package files. A large number of cross-reference fields and questionnaires can affect system performance.
Advanced Package Mapping requires a considerable amount of memory, which can result in loss of data input and browser errors when working with large applications.
Package file size
If the modules in a package contain cross-reference fields, the package file includes additional data to ensure that the cross references are properly maintained. As a result, package files can get very large. Because a questionnaire contains cross-references to the Findings application, and the Findings application references other applications, a package file that includes even a single questionnaire can become very large. Large package files can slow the performance of the installation process.
To optimize performance for packaging, increase the RAM on the servers.
Virtual memory size
The page file settings on the server running Archer Services can have a significant impact on performance. If the size of the page file is too small for all current processes, the system generates an out-of-memory error that can result in a loss of functionality or unexpected results.
Installing a large package file is 1 scenario that can cause this condition. The resolution is to modify the virtual memory settings on the operating system to provide more resources to the Archer Services. It is recommended that you configure the operating system to automatically manage the paging file size for all drives.
This setting is found in the System Properties > Performance Options > Virtual Memory dialog box.
When you select Automatically manage paging file size for all drives, the operating system automatically takes steps during resource-intensive activities to protect itself from running out of memory.
If the server in your organization is configured with a fixed size for the paging file, you can still help prevent out-of-memory errors by configuring the system to manage paging file sizes on other drives. Otherwise, if the page file is fixed, the system can incur out-of-memory errors during resource-intensive activities.
Packaging rules
The Packaging process requires a large amount of rules and logic to determine how the individual elements in applications and questionnaires are migrated from one instance of Archer to another. In general, Packaging does not delete objects or permission settings. It only adds new or updates existing objects and permission settings. Exceptions include layout and workflow, in which packaging replaces the existing settings.
See Packaging Rules for additional rules and logic.
Installing a translated language to another instance
You must use the package functionality in Archer to install a translated language to another Archer instance. You can install a translated language for any of the following individual Archer objects:
- Applications
- Questionnaires
- Workspaces
- Dashboards
The Archer versions of the source instance and the target instance affect the kind of package installation you will use because of the existence of Global Unique Identifiers (GUIDs) for objects and any dependencies, for example sub-forms, that are present in the instances. The installation of the translation language can succeed only when the GUIDs match in both instances.
Licensing issues
When installing a package with a core module in to a target instance in which it does not exist currently, that core module must be licensed prior to the package installation in the target instance.
The package installation verifies that core solutions, applications, dashboards, and workspaces are licensed on the target instance. If the target instance does not have the proper licenses, the objects are not installed and errors are logged to the Package Log file. In some cases, the package installation generates errors when installing packages that contain core applications that are properly licensed but have not yet been installed on the target instance.
The resolution is to reapply the license key after the package installation and then install the package again.
How system ID mismatches occur
System ID mismatches occur when a user manually creates an object in the source instance and then manually re-creates the same object in another instance. Because system IDs are assigned randomly to objects when they are created, the system IDs of each of these objects will be different.
Because system ID mismatches occur when the same object is manually created in multiple instances, the simplest way to avoid system ID mismatches is to use Packaging to copy all changes from 1 instance to another.
Using packaging with recommended development environments
The recommended development environment consists of 3 instances of Archer:
- Development
- Test
- Production
When making changes to Archer, the typical workflow involves first building the changes in the development instance, copying them to the test instance for testing and verification, and then copying them to the production instance.
Instead of manually re-creating the objects in each instance, Packaging can efficiently apply the changes to each instance.
Ideally, each of these instances would contain the same database. However, in larger organizations or organizations with strict security policies, the development and test instances have test databases with a smaller set of example data. As a result, some tests cannot be fully validated until the objects are moved from the test to the production instances.
Packaging between environments of different versions
This feature is only available for Archer SaaS and Hosted deployments.
Packages created in non-production environments can be installed into production environments. During the upgrade window, users can continuously deploy new solutions to their production environments.
For example, packages created in a non-production environment running Archer version 6.14.0.1 can be installed into a production environment running Archer version 6.14 or earlier.
Important: Archer recommends that packages created in newer versions of Archer do not include new features, as this may cause package installation in earlier versions to fail.
Authoritative source and control standard references
Authoritative Source and Control Standard references may be added, but existing ones are not removed by the package installation.
