This page explains how import inspection can help you avoid partial or problematic deployments. Before importing an application, a patch application, or Administration Console settings, you should inspect and evaluate the package contents. No objects are created or updated during inspection.
In this article, the source environment is the environment from which the package was exported and the target environment is the environment where the inspection and import is taking place. Some common deployment path examples include:
|Source Environment, deploys to…||Target Environment|
|Development 1||Development 2|
|Break Fix / Hotfix||Development|
Inspection identifies objects with missing dependencies, data stores that don't match the schema on the target system, and package corruption (invalid XML); it does not catch all possible errors, such as incorrect permissions or insufficiently unique names. Since you can't undo an import, it's a best practice to inspect your packages before deployment to catch any detectable package issues.
To inspect a package:
After you click Inspect, you will be presented with your package inspection results. At the top, there is a summary of how many items in your package have problems or warnings, how many will be created or updated by import, and how many will be skipped. Underneath this summary message is detailed information about the projected import status of each of the objects in your package.
If an object is modified in the source environment AND separately on the target environment, it will appear in the Conflict Detected section of the Inspection Results. When you see this status, you should pause your deployment and investigate the changes.
When you click Import Package, the definition in the package will overwrite whatever is in the target environment. Since the changes in the target environment are not guaranteed to be in the package, there is a risk of losing work! The Last Modified information will be captured and the importing user will be set as the designer of any imported process models with this status.
This check is helpful for detecting conflicts when deploying from a Break Fix environment back to Development or among multiple Development environments.
When you encounter the status Conflict Detected on inspect, you should proceed carefully since there is a chance your import will overwrite someone's work. When you see an unexpected conflict:
To avoid false conflicts, export your application from your development environment after upgrading from a pre-17.3 version and import it to each higher environment. This will set a baseline for your changes.
Objects with no detected import problems appear in the Success section. For these items, inspection performs additional analysis to generate an Inspection Status, which describes how the object in the package compares to what exists in the target environment and, therefore, what type of change the import will make. The available inspection statuses have the following unique characteristics:
|Inspection Status||Object Exists in Target Environment||Object Will Be Imported|
More details about the inspection statuses are available below:
If you need to force an import for objects with a Not Changed status, add the FORCE_UPDATE import-specific setting to your import customization file. See Managing Import Customization Files for a use case with more information on when and how to force an update.
These inspection statuses are helpful for detecting conflicts when deploying from a Break Fix environment back to Development or between multiple Development environments. In a typical Development-Test-Production deployment progression, the statuses will allow a quick gut-check to confirm that the correct objects are being created and updated.
It's a best practice to include data types created from WSDLs in your application or patch package before exporting it.
If those data types are not included in your package AND they don't already exist on the target environment, they'll be listed as problems in the inspection results. Data types that are normally created by the Call Web Service Smart Service or webservicequery() function during import cannot be created by the package inspection process.
On This Page