Words and Phrases
Applications major upgrade overview
The following sections describe how to upgrade your Service Manager applications to 9.61 by using the Service Manager 9.61 Upgrade Utility.
Before you begin an upgrade
Before you begin an upgrade, ensure that you:
- Read through the upgrade documentation to familiarize yourself with the upgrade process and all of the upgrade requirements.
- Are an experienced system administrator who is familiar with Service Manager.
If you do not have the administrative experience necessary to manage the upgrade, you may need assistance from your local applications developers and database administrators. You can also contact Service Manager Customer Support for help with troubleshooting upgrade errors. For additional information and support, contact your software sales representative.
Applications upgrade
You can upgrade your existing Service Manager applications to version 9.61 applications using the Upgrade Utility and resolving the differences between the two versions.
What are applications?
Applications are the Service Manager modules and their related configuration files. For example, Incident Management and Change Management are Service Manager applications.
New features that require an applications upgrade
Some new features provided by the release of Service Manager9.61 require an applications upgrade. The following new features provided by the release of Service Manager9.61 require an applications upgrade:
- Enhanced Service Desk, Incident Management, Problem Management, Change Management, Request Fulfillment Management, Service Catalog Management (provided since Service Manager 9.50), and Service Level Management based on Process Designer (provided since Service Manager 9.40)
- Process Designer framework
- Smart Analytics (provided since Service Manager 9.40)
- Smart Analytics Smart Ticket tuning toolkit (provided since Service Manager 9.60)
-
Smart Analytics search accuracy improvement (provided since Service Manager 9.60)
- Mobile Applications
- Service Request Catalog (SRC)
- Case exchange
- Smart email
-
Service Portal (provided since Service Manager 9.50)
-
Simplified interaction (provided since Service Manager 9.41)
-
Logical Name (provided since Service Manager 9.41)
-
Smart Search (provided since Service Manager 9.41)
-
Service Manager Collaboration (provided since Service Manager 9.41)
- Accessibility for the embedded Service Manager Calendar
- Service Manager Reports (provided since Service Manager 9.40)
- Service Manager Survey (provided since Service Manager 9.40)
- Entity Relationship Diagram (ERD and Data integrity check) (provided since Service Manager 9.40)
- The Primary Key and
Not Nullconstraints (provided since Service Manager 9.32)
Applications upgrade lifecycle
You can use three environments to complete the upgrade process: your current production environment, a new development environment, and a new test environment. You will duplicate your production environment to create the development and test environments. Run the out-of-box upgrade and create the custom upgrade on the development environment, and then run and test the custom upgrade on the test environment before you apply it to your production environment. The figure below provides an overview of the steps in the upgrade process.
The following flow chart illustrates the lifecycle of a typical upgrade of Service Manager applications.
Upgrade phases and sub-phases
The following table describes the phases and sub-phases in the entire applications upgrade lifecycle. These sub-phases are logged in the upgrade log files during the upgrade. When an error occurs, the log files can help you find out during which phase and sub-phase the error occurs.
| Phase | Sub-phases |
|---|---|
| Planning and preparation |
|
| Running an out-of-box upgrade |
|
| Creating a custom upgrade |
|
| Applying the custom upgrade |
|
How does customization affect the upgrade process?
The following explains how customization affects the upgrade process.
Conflicts
Object changes: The Upgrade Utility compares the objects in your database with their out-of-box versions and the corresponding objects provided from the upgrade package. The Upgrade Utility compares objects by their signatures. Each data record in Service Manager has a unique signature, which changes once that data record is updated. When processing object changes, the Upgrade Utility behaves as described in the following tables.
| Object in DB has been tailored? | OOB version of object matches upgrade package? | Out-of-box upgrade | Custom upgrade |
|---|---|---|---|
| Yes | No |
The Upgrade Utility tries to merge the object from the upgrade package with your tailored object. If the merge is successful, the Upgrade Utility marks the new merged object as "Auto Merged." If the merge fails, the Upgrade Utility marks the object as "Renamed." In both cases, the Upgrade Utility prefixes the object from the upgrade package with "NEW961," and then copies the object to your database and prefixes that object as "PRE<version_number>". For example, an object from applications version 9.31.0022 PDCP4 would be prefixed with "PRE9.31.0022_PDCP4". |
The Upgrade Utility marks the object from the upgrade package as “Forced,” and then copies the object in its revision. |
| Yes | Yes |
The Upgrade Utility keeps your local version, even if your version has been tailored and marks your local version as “Kept Customer”. |
The Upgrade Utility marks your local version object as “Already Current.” |
| No | No |
The Upgrade Utility overwrites the object in your database with the object from the upgrade package, and marks the object as “Upgraded.” |
The Upgrade Utility marks the object from the upgrade package as “Forced,” and then copies the object in its revision. |
| No | Yes | The Upgrade Utility marks the object as "Already Current" regardless of whether this is the first upgrade or a custom upgrade. | |
| Object is added in ... | Behavior | Note |
|---|---|---|
| DB | The Upgrade Utility always keeps your local version and does nothing else. | The object in your database does not have a corresponding object from the upgrade package. |
| Upgrade package | The Upgrade Utility adds the object to your database and marks the object as "Added" regardless of whether this the first upgrade or a custom upgrade. | The object from the upgrade package does not have a corresponding object from your database. |
Dbdict changes: The Upgrade Utility automatically adds new dbdict and merges new fields to existing dbdicts. The Upgrade Utility does not delete any existing field. For field and key changes, check "Field mapping changes" and "Key changes."
Field mapping changes: Normally the Upgrade Utility applies field mapping changes automatically, but there may be some exceptions. For example, when a length change is required, the Upgrade Utility automatically expands the length mapping. However, if the field mapping is a LOB-type change, the Upgrade Utility will not the change the type mapping. For detailed exceptions, check SQL Field Compare results before the upgrade and the except.log file after the upgrade.
Key changes: Normally the Upgrade Utility applies key changes automatically, but there may be some exceptions. For example, the Upgrade Utility automatically adds a new key and updates the existing key of the pre-upgrade out-of-box version. However, if a Unique key has been tailored, the Upgrade Utility will not apply the key change. For detailed exceptions, check the SQL Unique Key Compare Results before the upgrade and the except.log file after the upgrade.
Customization during upgrade
If any tailoring changes are made to your production system, for example, by applying an applications "hot fix," after you have initiated the upgrade process, it is highly recommended that you apply those same changes to the development system that is being used for conflict resolution before you create the final custom upgrade package. Or, these tailoring changes may be lost after the custom upgrade has been applied to production, and any conflict resolution that needs to be done in a production environment may slow down the production upgrade.
Upgrade Utility contents
The following table lists the files that are included in the Service Manager Upgrade Utility.
| File | Contents |
|---|---|
|
AppUpgVersion.txt |
Contains Upgrade Utility version and build number information to help you identify which applications upgrade version you have available. For example: A version of "SM930-9.61.00xx v9.6100xx Upgrade Build 00xx" indicates the following:
|
|
preupg.bin |
Files that allow you to access the various features of the Upgrade Utility. |
|
Files that allow for the execution of the upgrade. |
|
|
Files that allow you to run SQL compare, a feature of the Upgrade Utility. Note preupg.bin includes the files in sqlupgrade.unl. To run SQL Compare, you do not need to load sqlupgrade.unl again after you load preupg.bin. |
|
|
Signature information for the upgrade objects. |
|
|
Database dictionaries to be upgraded. |
|
|
Version stamp for this upgrade. |
|
| *.dta (in the package\<version>\data folder) |
The data files for each table that needs to be upgraded. For example, upgradeactivityactions.dta and upgradeactivitytype.dta. |
|
Signature definitions for the upgrade objects. |
|
|
Temporary dbdicts needed for the SQL Compare process. |
|
| Files that allow you to run Delta Migration Tool. | |
| .zip (in the 3waymerge\oob folder) |
Each zip file includes the XML representation of the objects that have been signatured in the pre-upgrade out-of-box version for the Three-Way Merge tool. |
