The main purpose of a change package is to transfer configurations between systems or to a version control system. Once a change package has been sealed and exported from a source system, it is expected that it will then be imported to a target system. Upon import, the change package can be analyzed against the target system data set, and subsequently installed if desired.
Automated System to System Integration
To automate the integration, sealing a change package on the source system triggers an event, which can be linked to automated import on a target system using REST services for delivery and receiver methods. This eliminates the need for a user to export, download, name, and import a file, and to migrate it to the next system in a chain of IEPs across various STEP systems that are part of a Development, Testing, Acceptance, and Production (DTAP) environment. Additionally, or instead of direct system to system integration, change packages can automatically be exported to a version control system, like GitHub, GitLab or Bitbucket. For details on configuration for integration endpoints, refer to the Configure an OIEP for VCSI with Change Packages topic and the VCSI: Change Package Git Delivery Method in OIEP topic.
Importing a Change Package
Change packages are exported as encoded STEPXML files and are imported using the Import Manager or an IIEP with the REST Receiver, both are defined in the Data Exchange documentation.
Note: You must create the setup group for change packages manually on the target system before you can import a change package. For more on creating the setup group, refer to the Initial Setup for Change Packages topic. After initial setup, if child setup groups are desired below the Change Packages top node, move these setup groups to target systems using a change package or recreate them manually with the same ID before transferring a new change package to the target systems.
Upon import, the new change package is found in the same location on the System Setup tab as it existed on the source system. Imported change packages have a status of 'Dormant' and a gray icon: 
At this point, the contents of the change package have not yet been applied. Only the change package itself has been imported. No system configurations will be updated, and the status remains dormant until the change package is installed.
Analyzing a Change Package
Once a change package has been imported, you can run an impact analysis. The analysis provides the user with information they can use to assess if the change package should be installed and to determine what the system impacts are likely to be upon installation.
To run an impact analysis, right-click on the Change Package and select Start Impact Analysis.
The impact analysis runs as a background process, which is then accessible on the BG Processes tab under Analyze Change-Package. A link to the background process is also provided on the change package object.
Note: If you do not open the BG Processes tab, click the Force Reload button (
) to refresh the indicators on the editor. Verify that the Impact Report Process link displays the current date and time for the BGP.
The contents of the impact analysis can be viewed directly in the change package editor via the Install Preview column and also in the Change Package Analysis Actions section.
The impact analysis report can also be downloaded via the Download Impact Analysis Report button for viewing offline (e.g., in Excel).
Analyze the Install Preview column in the editor or review the impact analysis report to determine if the change package should be installed and if any changes should be made on the target system prior to installation. If system changes occur, it may be useful to re-run the impact analysis.
Note: Not all objects are supported in the impact analysis. Refer to the Change Package Object Support topic for details. False positives are possible for some object types, resulting in a difference indicator being displayed instead of the synchronized indicator.
Items included in the 'Items Required for Transfer' section and the 'Possibly Impacted Items' section are ignored by the impact analysis and are only installed if the Handling parameter is set to 'Analyze and Install'. When the impact analysis identifies a missing object that is relevant to the feature being migrated (for example, when a setup item is missing its parent setup group and cannot be installed), it is recommended to re-open the change package on the source system and either promote the object to the 'Primary Items' section or add a necessary item that has not been identified, like a referenced business rule or workflow on an IEP or in a Web UI. If system changes occur, it may be useful to run the impact analysis again after it is re-imported.
If the change package should not be installed, right-click on the change package and select Delete to completely remove it from the system, without the option for restoration.
Note: A change package deleted on a target system can only be accessed by importing the package again.
Installing a Change Package Manually
Installation of the change package means that all objects within the change package in the Primary and Secondary sections are added to the system.
-
Items in the 'Items Required for Transfer' section are not analyzed and are only installed if the Handling parameter is set to 'Analyze and Install'.
-
Items in the 'Possibly Impacted Items' are not analyzed or installed.
To include these items in future Impact Analysis or installation, promote these items to the Primary section which removes the item from the 'Items Required for Transfer' section or the 'Possibly Impacted Items' section. If objects in the change package previously existed on the system, they are updated to reflect the contents of the package.
Refer to the Change Package Object Support topic for considerations when installing a change package.
When the impact analysis has been reviewed and the change package is determined acceptable, import it on the target system. Select the imported change package, right-click, and select Install Package Contents. Review the execution report for potential warnings or errors.
