Customized output from:
Document Release Date: April 2015 Software Release Date: April 2015 |
|
The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
The information contained herein is subject to change without notice.
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.
© 1994-2015 Hewlett-Packard Development Company, L.P.
Adobe® is a trademark of Adobe Systems Incorporated.
Java is a registered trademark of Oracle and/or its affiliates.
Microsoft® and Windows® are U.S. registered trademarks of Microsoft Corporation.
Oracle® is a registered US trademark of Oracle Corporation, Redwood City, California.
UNIX® is a registered trademark of The Open Group.
For a complete list of open source and third party acknowledgements, visit the HP Software Support Online web site and search for the product manual called HP Service Manager Open Source and Third Party License Agreements.
The following steps are customized according to your selections. Check that your selections are correct.
If any selections are not correct, click Change.
This upgrade guide is interactive and enables you to view the upgrade instructions that are relevant for your Service Manager setup. You can change your selections any time by clicking the Change button at the top of the page. When you complete a step or task, you can click the check box to the right of the heading to mark it as completed. To collapse or expand a section, click the icon to the left of the heading.
The bottom of the pages in the online version of this guide list the following identifying information:
To check for updates, or to verify that you are using the most recent edition of this document, go to the HP Software Support Online web site. This site requires that you register for an HP Passport and sign-in. To register for an HP Passport ID, click the New users - please register link on the HP Passport login page. You will also receive updated or new editions if you subscribe to the appropriate product support service. Contact your HP sales representative for details.
This guide will not print correctly if you attempt to print it using the Internet Explorer print feature. If you decide that you want to print this guide, click Print at the top of the page or at the bottom of the previous page where you made your selections. You can select to print out a hardcopy, or a PDF document (if you have an Adobe PDF printer installed on your machine).
You can find troubleshooting information at the end of this guide.
The HP Service Manager Upgrade Utility upgrades your applications to Service Manager 9.35.
Note: You can upgrade to interim application releases by using the Applications Patch Manager. For more information, see the Applications Patch Manager Guide.
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 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 |
|
This section explains how customization affects the upgrade process.
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, Upgrade Utility marks the object as "Renamed." In both cases, the Upgrade Utility prefixes the object from the upgrade package with "NEW935," and then copies the object in your datebase and prefixes that object as "PRE<version_number>". |
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.” |
|
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 dded 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 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 except.log file after the upgrade.
If any tailoring changes are made to your production system, for example, by applying an application "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.
Before you begin an upgrade, HP recommends that you complete the following steps:
Review this upgrade guide to familiarize yourself with all of the requirements.
Make sure that you are familiar with the tools available and have access to the documentation:
Documentation resources:
Meet the system requirements:
Convert all database tables and fields from lowercase to uppercase: Service Manager does not generate lowercase table names or field names. Therefore, if your database is case sensitive, you must convert all tables and fields from lowercase to uppercase before you can upgrade the server and client or applications.
Develop an upgrade strategy:
HP strongly recommends that you allow the Upgrade Utility to modify your RDBMS tables for you. If you chose not to allow the Upgrade Utility to modify your RDBMS tables and want to modify your tables manually, you can use the SQL Compare utility to determine the tables that you need to update.
Tailored systems: A list of tailored files can help you resolve differences quickly between your existing files and new files. You can also use the SQL Compare utility to determine how files differ. Customization affects the upgrade process the following ways:
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.
If an object in your database that has been tailored does not match the corresponding object that is provided by the upgrade package, the following behaviors apply:
If an object in your database has been tailored, but the out-of-box version matches exactly the corresponding object from the upgrade package, the following behaviors apply:
If an object in your database has not been tailored, but does not match the corresponding object provided from the upgrade package, the following behaviors apply:
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 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 except.log file after the upgrade.
Localized systems: The Upgrade Utility supports upgrading systems that have language packs applied. The upgrade contains the latest language pack records and will upgrade any language pack record to the latest version or flag any changed records for reconciliation.
Backups: HP highly recommends that, at a minimum, you back up the development environment database after you apply the upgrade and after you resolve conflicts.
Note the following new features provided by the release of HP Service Manager 9.35 that require an application upgrade:
Not Null
constraints (provided since Service Manager 9.32)Make sure that you have upgraded your server and the client to the latest version before you attempt to run an application upgrade. This allows the upgrade utility to call the new functions in the latest server and client and to take full advantage of all of the application features following an upgrade.
To upgrade your applications to version 9.35, you must first perform a server and client upgrade. The applications upgrade to Service Manager 9.35 depends on features in the 9.35 platform (server and client) .
To upgrade your applications by using this Upgrade Patch, you must first perform a server and client upgrade to 9.35 platform (server and client).
If you have deployed Knowledge Management, you must also upgrade the Knowledge Management Search Engine to the new version. Follow the instructions in the HP Service Manager 9.35 Knowledge Management Search Engine Guide to install the latest search engine.
HP Service Manager stores application data in a relational database management system (RDBMS). Before you can upgrade the server or applications, you must convert your ServiceCenter data from your original P4 data store to a supported RDBMS. For more information about how to convert your data, see the Database Conversion and RDBMS Support Guide for HP ServiceCenter 6.2 available on your ServiceCenter 6.2 help server.
Increase the user space from the current 4k size for the following tables:
Note:
To enlarge user space for affected tables, follow these steps:
Complete the following procedure from the command line. Increase the user space for each table separately.
Type the following commands from the command line, and then press Enter after each command:
create table INBOXM1_TEMP like INBOXM1 in USER32K
commit
insert into INBOXM1_TEMP (select * from INBOXM1)
commit
drop table INBOXM1
commit
rename table INBOXM1_TEMP to INBOXM1
commit
The current or a previous upgrade process may fail to remove certain mapped indexes and constraints after removing a key from Service Manager applications. These indexes or constraints may prevent the upgrade process from adding records to those specific tables.
To remove these indexes and constraints manually, follow these steps:
Open the dbdict for the svcCatInterface table, and remove the service.request.id unique key.
Log in to the RDBMS, and remove the mapped index for the svcCatInterface table.
Example: For an Oracle RDBMS, run the following SQL statements to determine the key name and remove the index if it exists:
select i.index_name, c.column_name from user_indexes i, user_ind_columns c where i.table_name='SVCCATINTERFACEM1' and i.index_name=c.index_name
drop index SVCCATINTERFACEM1_2
Log in to the RDBMS, and remove the mapped constraint and index for the notification table.
Example: For an Oracle RDBMS, run the following SQL statements to remove the constraint and index (if they exist):
alter table notificationm1 drop constraint NOTIFICATIONM1_P
drop index NOTIFICATIONM1_P
Log in to the RDBMS, and remove the mapped constraint and index for the extaccess table.
Example: For an Oracle RDBMS, run the following SQL statements to remove the constraint and index (if they exist):
alter table extaccessm1 drop constraint EXTACCESSM1_P
drop index EXTACCESSM1_P
Log in to the RDBMS, and remove the mapped constraint and index for the activitytype table.
Example: For an Oracle RDBMS, run the following SQL statements to remove the constraint and index (if they exist):
alter table acttypem1 drop constraint ACTTYPEM1_P
drop index ACTTYPEM1_P
Remove any upgrade files from previous versions of HP Service Manager. You can run the purge tool to remove temporary objects that were generated by the Upgrade Utility. However, the purge tool may not clean up some artifacts that could be left from past upgrades, such as objects prefixed with OLD<version_number>. Before running the purge tool, you can search the Upgrade Results report for records with a result type of "Forced" to find left over artifacts. You can export the list of objects to an Excel spreadsheet so that you can refer to the list when you manually delete the objects from your system.
To view the Upgrade Results report, follow these steps:
To run the purge tool, follow these steps:
Duplicate your current ServiceCenter or HP Service Manager production environment and create a development environment for running the out-of-box upgrade and creating the custom upgrade. Set up the duplicate environment to match your production server exactly. Make sure that the operating system and service pack level on the development environment is identical to the production server.
Identify a server to use for the development environment.
Before you proceed, make sure that you have upgraded your server and client to version 9.35.
To prepare the server for the upgrade, edit the Service Manager configuration (sm.cfg) and initialization (sm.ini) files. Note that you must return the sm.ini and sm.cfg files to their original state after the upgrade, so you may want to keep copies of the original files.
sm system.start
line to disable the #sm system.start background processes.Add sm -sync
to the end of the file if it does not yet exist. This parameter starts the sync process, which identifies and releases locks owned by inactive processes and shared memory that is
not in use.
sm -httpPort
parameter, comment out all instances except for one. Each sm -httpPort
parameter starts
a Service Manager server process.
The upgrade needs only one process. Comment out all other parameters. Commenting out the parameters
disables all of the other Service Manager processes that are not
required during an upgrade.sessiontimeout:1200
parameter to the end
of the file if it does not exist. If
this parameter exists,
update it to an appropriate
value. This parameter defines the number of minutes that the server waits for a client signal before the server assumes that the client session has timed out and closes the connection. A value of 1200 sets the
timeout to 20 hours (1200 minutes), a
period that should be long enough for an
upgrade phase to complete in a
typical scenario.heartbeatinterval:120
parameter to the end of the file if it does not exist. This parameter defines the number of
seconds that the server waits for a
client heartbeat signal before the server assumes that the client session has timed out and closes the connection.If you use HP-UX, add the JVMOption(#):-Xss6M
JVM option to the end of the file if it does not exist: . This parameter increases the Java virtual machine stack size to 6MB.
When you add the parameter, replace the hash symbol (#) with an option number that does not exist in the sm.ini file. For example, if the file already contains a JVMOption(0)
and JVMOption(1)
, add JVMOption(2):-Xss6M
to the file.
shared_
memory:32000000
with
shared_memory:96000000
. This sets the shared memory size to
96MB. However, if you have a large
database, you may need to allocate
more shared memory to
accommodate the upgrade
processing.ir_disable:1
to the end of the file.Since the upgrade process needs read-write access to the Upgrade Utility files, you cannot run the upgrade directly from the DVD. Follow these steps to copy the Upgrade Utility files to the primary directory on the development system.
Create an upgrade folder on the development system. For example, C:\temp\upgrade.
Create an upgrade folder on the development system. For example, /tmp/upgrade.
Note: If you connect to the development server from a client on a remote computer, make sure that you create the folder on the development server and not the client machine.
The Upgrade Utility includes the following files:
AppUpgVersion.txt: Contains Upgrade Utility version and build number information to help you identify which application upgrade version you have available. For example:
A version of "SC62-9.35.00xx v9.35 00xx Upgrade Build 00xx" indicates the following:
Log on to HP Service Manager with a system administrator account.
Note: Select English as the language when logging into the system for an upgrade.
Click Window > Preferences > HP Service Manager and clear the Client side load/unload check box.
Caution: Failure to disable the Client side load/unload option causes the upgrade process to fail.
In the File Name field, navigate to the upgrade directory that you created, and double-click preupg.bin. For example, C:\temp\upgrade\preupg.bin.
In the File Name field, navigate to the upgrade directory that you created, and double-click preupg.bin. For example, /tmp/upgrade/preupg.bin.
Type the fully qualified path to the upgrade folder that you created. For example, C:\temp\upgrade.
Type the fully qualified path to the upgrade folder that you created. For example, /tmp/upgrade.
Before you run the upgrade, you use the data scan option in the Upgrade Utility to scan a portion of your data set for certain types of data that may cause issues following the upgrade. The data scan logs to the datascan.log file basic information about the scan results, such as how many data records it scanned and which records it updated automatically. The scan logs to the sm.log file details about which problematic records it corrected. The data scan option enables you to scan for two types of problematic data:
The data scan does not allow you to specify the tables to scan. The tables that are scanned include the list of tables noted in the latest patches record. To view the patches record, click SERVICE PACK > Update Patch Definitions in the Upgrade Utility. For more information about the rtecall functions that the data scan uses and about how you can implement these functions to scan for additional tables, such as probsummary, see the HP Service Manager Programming Guide.
If you want to modify the automatically fixed data to your own values, follow the instructions below.
The data scan option scanned for null values that violated the restrictions imposed by a No Nulls or Unique key. The utility then removed the record if null values violated a Unique key or replaced one of the null values with a default value if the null values violated a No Nulls key.
To change automatically modified values to your own values, follow these steps:
Search for deleted a record or updated a record to locate a message that resembles either of the following:
scan: scan for nulls, deleted a
record that contains null
values on a "Unique" key field,
table = TABLE_NAME, record =
RECORD_CONTENTS
This message indicates that the utility removed a record. TABLE_NAME shows the name of the table, and RECORD_CONTENTS shows all of the fields and values of the removed record.
scan: scan for nulls, updated a
record that contains null
values on a "No Nulls" key
field, table = TABLE_NAME, key
= RECORD_IDENTIFIER
This message indicates that the utility replaced a null value with a default value. TABLE_NAME shows the name of the table, and RECORD_IDENTIFIER shows the primary key and its value for the updated record.
The data scan option scanned for mismatches between the data type defined on the field and the data type of the field value.
To change automatically modified values to your own values, follow these steps:
Search for scan for inconsistent data types, table to locate a message that resembles either of the following:
scan: scan for inconsistent
data types, table: "TABLE_
NAME", key: "RECORD_
IDENTIFIER", field: "FIELD_
NAME", value "ORIGINAL_VALUE",
type: ORIGINAL_TYPE, value
changed to: "NEW_VALUE", type:
NEW_TYPE.
This message indicates that the utility changed the value of a field in a record:
scan: scan for inconsistent
data types, table: "TABLE_
NAME", key: "RECORD_
IDENTIFIER", field: "FIELD_
NAME", value "ORIGINAL_VALUE",
type: ORIGINAL_TYPE, type
changed to NEW_TYPE.
This message indicates that the utility changed the type of a field in a record:
The SQL Compare utility is an informational tool that you can use to compare your existing table and field information with the tables and fields of Service Manager 9.35. It reports new fields that will merge into the existing tables. You can use the list of the fields produced by SQL Compare to determine whether any fields in your current system differ from those in the new version. Use can also use the report to determine which new fields you must add to RDBMS-mapped files if you choose to make the changes manually during the application upgrade.
Note: If you are going to accept the new dbdicts and the changes made to the dbdicts in the upgrade, you do not need to run this utility.
To run the SQL compare routine, follow these steps:
Type the fully qualified path to the upgrade folder that you created. Include the final back slash (\) in the path. For example, C:\temp\upgrade\.
Type the fully qualified path to the upgrade folder that you created. Include the final forward slash (/) in the path. For example, /tmp/upgrade/.
SQL Compare returns messages for dbdict mappings that contain new fields. You can update the dbdicts to contain the fields specified by SQL Compare before you begin the application upgrade.
To view the SQL compare results, follow these steps:
Add the new fields to the appropriate database dictionary and SQL database. The sqlupgrade record provides the following information for each new field:
The new fields must exist in the database dictionary and the SQL database. If you are updating your RDBMS system manually, you must add them to the database and update the existing Service Manager SQL mapping. When you update a table in sqlsystemtables, add fields only through the database dictionary. Modifying the SQL mapping damages the file structure of the table.
In most cases, you should add the new field to the descriptor structure. However, sometimes the Structure field contains something other than the word descriptor. When this occurs, add the new field to the appropriate location:
The field is part of an array of structures: If the Structure field lists multiple fields exclusive of an array name, add the field to a structured array. To determine the placement in the structured array, follow the list of field names in the Structure/Array from left to right. The first name is the array name and the second is the structure name.
Note: When adding fields to a structured array, add them in the same order as they appear in the sqlupgrade record.
Before you proceed, make sure that you have upgraded your server and client to version 9.35. For more information, see Upgrade the server and client on your production system .
The HP Service Manager Upgrade Utility upgrades the display components, database dictionaries, and the application data. The utility uses digital signatures to determine if an application matches the original application. A matching signature indicates that the object in your system has not changed from the original object and the utility can upgrade it safely. If a signature does not match the object in your system, the Upgrade Utility copies the new object to your system but does not overwrite the existing object. You can then examine both versions during the resolution process.
The Upgrade Utility runs three primary phases:
Caution: If you experience problems such as a power failure or a network connection error while upgrading the system, you can fix the issues and rerun the Upgrade Utility. The utility resumes the upgrade from the failure point. However, if the upgrade does not resume from the failure point, restore your database to the last backup point and fix possible issues; then rerun the Upgrade Utility.
To run the Upgrade Utility, follow these steps:
Review the list of supported non-English languages that the Upgrade Utility will upgrade. By default, the languages that are installed on your system are set to true. Select false for the languages that you do not want to upgrade, and then click Next.
Note: If you choose only part of the languages in this step, there are two points later in the upgrade lifecycle where you can rerun the Upgrade Utility to specify additional languages to be updated:
Before creating a custom upgrade (then the updates to the selected additional languages will be included in the custom upgrade package)
Warning: However, in this case, you must finish conflict reconciliation before you update additional languages, because the Upgrade Results will be cleaned up.
Select Install HP's Version of the Object Alongside Your Own, and then click Next.
Note: The Replace your version of the object with the HP Service Manager's version of the object option is for applying a custom upgrade. Do not choose that option at this point unless you are sure that you want to replace your own versions of objects and do not need to perform conflict resolution.
For the Upgrade Utility to merge conflicting objects automatically, select the Enable check box, select a Base Version from the list, and then click Next.
Note: The Base Version you select here will be considered as a clean version on which all changes are based. The earlier the version is, the less the chance your tailoring will be discarded. However, the earlier the version is, the less likely the utility will successfully merge objects. Typically, it is safe to keep the default value, which is set to the earliest version that your applications were previously upgraded from.
The utility asks if you want to generate To Do records for all existing open records in the major modules. If you want to generate all open application records, leave the Generate To Do records check box selected, and then click Next.
Depending on the number of records in your Change Management, Incident Management, Service Desk, Problem Management, and Request Management applications, this step can take a significant amount of time. If you have a large number of records, you can choose to generate the records after completing the upgrade by typing *aapm.upgrade.todo in the Service Manager command line.
From Service Manager9.35, some Module Fields in the TodoMap table have updated mappings for the To Do List Field. See the following table for these new mappings:
Table Name | Old Module Field Name | New Module Field Name | ToDo List Field Name |
---|---|---|---|
cm3r |
description,1 |
brief.description | description |
cm3t | description,1 | brief.desc | description |
incidents | description,1 | title | description |
ocml |
description,1 | description | description |
ocmo | description,1 | description | description |
ocmq |
description,1 | brief.description | description |
probsummary | next.breach | sla.expire | target.date |
Note:
The Upgrade Utility displays a message: Do you want to force the replacement of the objects?
If you want to replace each Renamed RAD application with its upgrade version, select the Replace RAD option. Each Renamed RAD application is replaced with the upgrade version, and a copy of old RAD application is renamed to PRE<old_version_number><object_name>. Its upgrade result is marked as "Replaced".
If you do not want to replace Renamed RAD application, do not select the Replace RAD option. Each Renamed RAD application is not replaced but still remains in the Renamed list, and the upgrade version of the RAD application is renamed to NEW935<object_name>. Its upgrade result is kept as Renamed.
When you receive an UPGRADE IS COMPLETE message, the Upgrade Utility has finished the data processing and you can follow the instructions in the message to complete the next steps. After you close the message dialog, you are automatically logged out.
After running the Upgrade Utility, the next step is to resolve any exceptions or conflicts that prevented the utility from updating certain objects. Until you reconcile these objects, Service Manager features may not behave as expected or may not function at all. First review the upgrade log files to determine if there are any exceptions. Then review the upgrade reports to find any conflicts.
The Upgrade Utility creates a set of log files during the upgrade process. These files reside in the same directory as the upgrade files. You can open the log .txt files in the upgrade folder that you created when you copied the upgrade files to your development environment.
Log file | Contents |
---|---|
This file contains specific information about the upgrade, including the following:
|
|
This file contains information about any exceptions reported by the upgrade, including the following:
If there are exceptions logged in this file, you will have to resolve them in the "Resolving exceptions and conflicts" phase. |
|
This file contains information about where the upgrade is at any point. This file contains only the main steps of the upgrade, including the following:
|
If the data type of a field in your dbdict does not match the data type of the like-named field defined in the dbdict provided by the upgrade package, the Upgrade Utility cannot merge these dbdicts. For example, if an existing dbdict has a scalar field and the Upgrade Utility attempts to add a structure field with the same name, this discrepancy prevents the dbdict from being updated.
To fix this issue, you can change the data type and the SQL type of the field, and use Complex Update to migrate existing data on that field to the target data type. The following is an example that shows the process of fixing a typical data type mismatch.
Note: The error messages in the except.log file identify each data type by an index number:
Index number | Data type |
---|---|
1 | number |
2 | character |
3 | date/time |
4 | logical |
8 | array |
9 | structure |
11 | expression |
The following table shows a list of data type mismatches that may appear in the except.log file. The data type mismatches are listed for an Oracle database. If you are using an MSSQL or a DB2 database, the actual error message may vary slightly. For example, the following bullet points highlight the different errors in the different databases:
Data type mismatches for HP ServiceCenter 6.2x:
Error message in Oracle: | Solution: |
---|---|
dbdict:ApprovalDef, field:appr.condition, SQL type is CHAR(1) -- expected to be:RAW(255) dbdict:cm3r, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB dbdict:incidents, field:svc.options, SQL type is VARCHAR2(90) -- expected to be:BLOB dbdict:ocmq, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB dbdict:svcCartItem, field:bundle.options, SQL type is VARCHAR2(30) -- expected to be:BLOB dbdict:svcCatalog, field:access.filter.xml, SQL type is VARCHAR2(40) -- expected to be:BLOB |
To fix these issues, change the SQL type to RAW(255) or BLOB by using the Dbdict utility. Additionally, you need to set the “SQL RC” to true to allow the field to store RAD expressions. Note that the stored value of the field in the database is encoded by Service Manager. |
dbdict:cm3eventack, field:number, field type is number -- expected to be:character |
To fix this issue, change the field type to character by using the Dbdict utility. |
dbdict:eventin, field:evnumber, field type is number -- expected to be:character dbdict:eventout, field:evnumber, field type is number -- expected to be:character |
These fields reside in the descriptor structure field of BLOB SQL type. To fix this issue, change the field type to character by using the Dbdict utility. |
dbdict:licenseinfo, field:id, field type is character -- expected to be:number |
The licenseinfo table is used to track the license information by the Service Manager server. This issue should be ignored. |
dbdict:svcCatalog, field:id.attach, field type is character -- expected to be:number |
This id.attach field is an alias of id field in svcCatalog table. To fix the issue, change the field type to by using the Dbdict utility. |
dbdict:cm3profile, field:update, field type is logical -- expected to be:character dbdict:icmenv, field:update, field type is logical -- expected to be:character dbdict:ocmprofile, field:update, field type is logical -- expected to be:character dbdict:pmenv, field:update, field type is logical -- expected to be:character dbdict:rcenv, field:update, field type is logical -- expected to be:character dbdict:rcenv, field:pmt.update, field type is logical -- expected to be:character dbdict:rcenv, field:kne.update, field type is logical -- expected to be:character dbdict:slaprofile, field:sla.update, field type is logical -- expected to be:character dbdict:slaprofile, field:slor.update, field type is logical -- expected to be:character dbdict:slaprofile, field:sloa.update, field type is logical -- expected to be:character dbdict:slaprofile, field:slocat.update, field type is logical -- expected to be:character dbdict:smenv, field:update, field type is logical -- expected to be:character |
These fields reside in the descriptor structure field of BLOB SQL type. To fix the issue, change the field type to character by using the Dbdict utility. |
dbdict:probsummary, field:critical.user, field type is character -- expected to be:logical |
This issue can be fixed by following the steps in the Fixing the probsummary critical.user field section. |
Data type mismatches for HP Service Manager 7.0x
Error message in Oracle: | Solution: |
---|---|
dbdict:ApprovalDef, field:appr.condition, SQL type is CHAR(1) -- expected to be:RAW(255) dbdict:cm3r, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB dbdict:incidents, field:svc.options, SQL type is VARCHAR2(90) -- expected to be:BLOB |
To fix these issues, change the SQL type to RAW(255) or BLOB by using the Dbdict utility. Additionally, you will need to set the “SQL RC” to true to allow the field to store RAD expressions. Note that the stored value of the field in the database is encoded by Service Manager. |
dbdict:cm3eventack, field:number, field type is number -- expected to be:character |
To fix this issue, change the field type to character by using the Dbdict utility. |
dbdict:eventin, field:evnumber, field type is number -- expected to be:character dbdict:eventout, field:evnumber, field type is number -- expected to be:character |
These fields reside in the descriptor structure field of BLOB SQL type. To fix this issue, change the field type to character by using the Dbdict utility. |
dbdict:licenseinfo, field:id, field type is character -- expected to be:number |
The licenseinfo table is used to track license information by the Service Manager server. This issue should be ignored. |
dbdict:svcCatalog, field:id.attach, field type is character -- expected to be:number |
This id.attach field is an alias of id field in svcCatalog table. To fix the issue, change the field type to by using the Dbdict utility. |
dbdict:FolderRights, field:close, field type is logical -- expected to be:character |
The close field is an alias of delete field in FolderRights table. To fix the issue, change the field type to character by using the Dbdict utility. |
dbdict:FolderRights, field:delete, field type is logical -- expected to be:character |
This issue can be fixed by following the steps in the Fixing the FolderRights delete field section. |
Data type mismatches for HP Service Manager 7.1x:
Error message in Oracle: | Solution: |
---|---|
dbdict:cm3r, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB dbdict:incidents, field:svc.options, SQL type is VARCHAR2(90) -- expected to be:BLOB |
To fix these issues, change the SQL type to RAW(255) or BLOB by using the Dbdict utility. Additionally, you will need to set the “SQL RC” to true to allow the field to store RAD expressions. Note that the stored value of the field in the database is encoded by Service Manager. |
dbdict:cm3eventack, field:number, field type is number -- expected to be:character |
To fix this issue, change the field type to character by using the Dbdict utility. |
dbdict:eventin, field:evnumber, field type is number -- expected to be:character dbdict:eventout, field:evnumber, field type is number -- expected to be:character |
These fields reside in the descriptor structure field of BLOB SQL type. To fix this issue, change the field type to character by using the Dbdict utility. |
dbdict:licenseinfo, field:id, field type is character -- expected to be:number |
The licenseinfo table is used to track license information by the Service Manager server. This issue should be ignored. |
dbdict:svcCatalog, field:id.attach, field type is character -- expected to be:number |
This id.attach field is an alias of id field in svcCatalog table. To fix the issue, change the field type to by using the Dbdict utility. |
dbdict:FolderRights, field:close, field type is logical -- expected to be:character |
The close field is an alias of delete field in FolderRights table. To fix the issue, change the field type to character by using the Dbdict utility. |
dbdict:FolderRights, field:delete, field type is logical -- expected to be:character |
This issue can be fixed by following the steps in the Fixing the FolderRights delete field section. |
Data type mismatches for HP Service Manager 9.2x:
Error message in Oracle: | Solution: |
---|---|
dbdict:incidents, field:svc.options, SQL type is VARCHAR2(90) -- expected to be:BLOB |
To fix this issue, change the SQL type to RAW(255) or BLOB by using the Dbdict utility. Additionally, you will need to set the “SQL RC” to true to allow the field to store RAD expressions. Note that the stored value of the field in the database is encoded by Service Manager. |
dbdict:cm3eventack, field:number, field type is number -- expected to be:character |
To fix this issue, change the field type to character by using the Dbdict utility. |
dbdict:eventin, field:evnumber, field type is number -- expected to be:character dbdict:eventout, field:evnumber, field type is number -- expected to be:character |
These fields reside in the descriptor structure field of BLOB SQL type. To fix this issue, change the field type to character by using the Dbdict utility. |
dbdict:licenseinfo, field:id, field type is character -- expected to be:number |
The licenseinfo table is used to track the license information by the Service Manager server. This issue should be ignored. |
dbdict:svcCatLanguage, field:catalogid, field type is character -- expected to be:number |
This field resides in the catalog structure field of BLOB SQL type. To fix this issue, change the field type to number by using the Dbdict utility. |
dbdict:svcCatalog, field:id.attach, field type is character -- expected to be:number |
This id.attach field is an alias of id field in svcCatalog table. To fix the issue, change the field type to by using the Dbdict utility. |
dbdict:FolderRights, field:close, field type is logical -- expected to be:character |
The close field is an alias of delete field in FolderRights table. To fix the issue, change the field type to character by using the Dbdict utility. |
dbdict:FolderRights, field:delete, field type is logical -- expected to be:character |
This issue can be fixed by following the steps in the Fixing the FolderRights delete field section. |
Example: The dbdict for the FolderRights table has a delete field with the "logical" data type. The Upgrade Utility tries to update the delete field with the "character" data type, which has possible values of "always," "never," "workgroup," and "assigned."
In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the delete field to the delete.tmp field.
Example:
if delete in $file=true then delete.tmp in $file="always" else delete.tmp in $file="never"
In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the delete.tmp field to the delete field and empty the delete.tmp field.
Example:
delete in $file=delete.tmp in $file; delete.tmp in $file=NULL
Example: The dbdict for the probsummary table has a critical.user field with the "logical" data type. The Upgrade Utility tries to update the critical.user field with the "logical" data type, which has possible values of true or false.
In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the critical.user field to the critical.user.tmp field.
Example:
if critical.user in $file="true" then critical.user.tmp in $file=true else critical.user.tmp in $file=false
In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the critical.user.tmp field to the critical.user field and empty the critical.user.tmp field.
Example:
critical.user in $file=critical.user.tmp in $file; critical.user.tmp in $file=NULL
If the except.log file lists key change failures such as the ones listed below, follow the appropriate steps to correct the keys:
Error: Failed to add <key_type> key: <field_name> to table <table_name>. Add the key manually:
Error: Failed to update <key_type> key: <old_field_name> to <new_field_name> in table <table_name>. Update the key manually:
Error: Failed to remove <key_type> key: <field_name> from table <table_name>. Remove the key manually:
In addition, you may encounter the following Unique Key errors:
Error: dbdict:Approval, Unique Key is {"unique.key", "file.name", "name"} -- expected to be:{"unique.key", "file.name", "name", "component"}
Error: dbdict:ApprovalLog, Unique Key is {"counter", "file.name", "unique.key"} -- expected to be:{"counter", "file.name", "unique.key", "component"}
Error: dbdict:displayeventrev, Unique Key is {"screen.id", "language", "event", "event.sig", "sc.revision"} -- expected to be:{"id", "sc.revision"}
Error: dbdict:displayoptionrev, Unique Key is {"screen.id", "language", "txt.bank", "txt.option", "text.sig", "sc.revision"} -- expected to be:{"id", "sc.revision"}
Error: dbdict:kmknowledgebaseupdates, Unique Key is {} -- expected to be:{"id"}
Error: dbdict:wfwenvironment, Unique Key is {} -- expected to be:{"name"}
If the except.log file or the Upgrade Results report lists any errors other than key change failures and data type mismatches, contact HP Software Customer Support for assistance.
Follow the instructions in the task below to find conflicts that need to be resolved and to mark objects as reconciled after you resolve the conflicts.
For more specific guidelines and examples for conflict resolution, see the Conflict Resolution for Upgrade to Service Manager (SM) 9.3x white paper.
Follow these steps to view the Upgrade Results report:
In the Result drop-down list, select the type of results you want to search for. For example, select Renamed.
Note: When you select a result type from the drop-down list, the description of that result type appears under the drop-down list. If you want to view the full Upgrade Results report that includes all objects and statuses, clear the Result field and press Enter.
For each renamed or forced object, choose one of the following options:
Option 2: Use the new object instead of your customized object. In this case, delete your customized object and the copied object that is prefixed with PRE<version_number> and rename the new object by removing the NEW935 prefix, or you can select Choose Upgrade to replace the object with the new object that is prefixed with NEW935.
Note: The Mass Choose Upgrade feature can help you replace multiple customized objects with new objects that are prefixed with NEW935. For more information, see the "Using the Mass Choose Upgrade feature" section.
Option 3: Merge the changes shipped with the new object into your customized object. In this case, find out what changes the new object includes, manually apply those changes to your customized object, and then delete the new object that is prefixed with NEW935 and the copied object that is prefixed with PRE<version_number>.
Note: The Merge tool, Auto-Merge and Revert options, and third-party three-way compare and merge tools can assist you in comparing the objects and merging the code during the out-of-box upgrade. See Using the Merge tool and Using the Auto Merge and Revert options for more information.
After you change an object, mark the object as reconciled so that the Upgrade Utility will not identify this object as conflicting when it applies an upgrade to a later version. When you upgrade to a later version in the future, the Upgrade Utility will mark the object as Previously Reconciled instead of Renamed.
Note: The Mark as Reconciled feature can assist you to mark the object as Reconciled." See "Using the Mark as Reconciled feature" for more information.
You can export the upgrade results data to a Microsoft Excel spreadsheet. To do so, from the Upgrade Results report, click the drop-down options menu and select Export to Excel. You can also select File > Print from the Upgrade Results report to print the list of records. For more information, see the Service Manager Help Center.
The search criteria, search results, and a description of the applicable action for each result are described in the table below.
Field | Definition |
---|---|
Object Name | Enter the name of the object you want to search for, or leave this field blank to return objects with any name. The object name is typically the unique identifier in the database table specified for the object type. |
Object Type | Enter the type of object you want to search for, or leave this field blank to return all object types. Some of the object types you could search for are: Application Cluster, Object, Process, ScriptLibrary, displayoption, format, formatctrl, help, joindefs, link, scmessage, screlconfig, triggers, validity, and wizard. |
Result: Added |
Select this option to search for new objects that the Upgrade Utility added to the system. These objects did not exist in your system before this update. No further action is necessary for these objects. |
Result: Already Current |
Select this option to search for objects that were already the latest version. No further action is necessary for these objects. |
Result: Auto Merged |
Select this option to search for objects that the Upgrade Utility automatically merged by using your local version, the out-of-box version and the upgrade version of the objects. Note: The result occurs only after applying the first out-of-box upgrade; it no longer occurs after applying the custom upgrade. Required Action: If the object was not merged the way you expect, use the Revert or Mass Revert option from the options menu to revoke the auto-merge and merge them manually. |
Result: Error |
Select this option to search for objects that encountered an error while being updated by the Upgrade Utility. For more information about the error, review the sm.log and except.log files. Required Action: Fix the cause of the error, or if it is needed, in a copy of your production system, apply the upgrade again. |
Result: Forced |
Select this option to search for objects that were tailored on your Service Manager system or only changed on the upgrade version. After upgrade, your objects were automatically replaced with the objects in your custom upgrade package. The Upgrade Utility copied your object of the original version to its revision. Note: This result occurs only after applying the custom upgrade. No further action is necessary for these objects. |
Result: Kept Customer |
Select this option to search for objects that were tailored on your Service Manager system but not changed on the upgrade version. These objects were not changed. Note: The result occurs only after applying the first out-of-box upgrade; it no longer occurs after applying the custom upgrade. No further action is necessary for these objects. Tip: If the object is Application Cluster and you want to use the upgrade version, you can select Choose Upgrade. The object <object_name> is then renamed to PRE<old_version_number><object_name> and the objectNEW935<object_name> is renamed to <object_name>. |
Result: Kept Customer Non-OOB |
Select this option to search for objects that did not exist in the original version but were added on your Service Manager system, and also added on the upgrade version. Note: The result occurs only after applying the first out-of-box upgrade; it does not occur after applying the custom upgrade. No further action is necessary for these objects. Note: If the object is Application Cluster and you want to use the upgrade version, you can select Choose Upgrade. The object <object name> is then renamed to PRE<old version number><object name> and the object NEW935<object name> is renamed to <object name>. |
Result: Merged |
Select this option to search for objects that were tailored on your Service Manager system, which you have merged with the version in this patch. Required Action: Test these objects, and when satisfied change their result to Reconciled. |
Result: Previously Reconciled |
Select this option to search for objects that were tailored on your Service Manager system, that were marked as Reconciled during a previous upgrade or patch release, or where your object was not changed and the Upgrade Utility added a new object NEW93x<object name>. Note: The result occurs only after applying the out-of-box upgrade; it no longer occurs after applying the custom upgrade. Required Action: Choose one of the following for each object with this result.
|
Result: Reconciled |
Select this option to search for objects that you have already marked as Reconciled. Note: The result occurs only after applying the out-of-box upgrade; it no longer occurs after applying the custom upgrade. No further action is necessary for these objects. |
Result: Renamed |
Select this option to search for objects that were not only tailored on your Service Manager system but also changed on the upgrade version. After upgrade, your tailored object was not changed, the Upgrade Utility added a new object NEW93x<object name> and copied your tailored object as a backed up object PRE<old version number><object name>. Note: The result occurs only after applying the out-of-box upgrade; it no longer occurs after applying the custom upgrade. Required Action: Choose one of the following for each object with this result.
|
Result: Upgraded |
Select this option to search for objects that were automatically replaced with the upgrade version objects. These are objects that were not tailored on your Service Manager system, but changed on the upgrade version. Note: The result occurs only after applying the out-of-box upgrade; it no longer occurs after applying the custom upgrade. No further action is necessary for these objects. |
Result: Replaced |
Select this option to search for RAD Application objects that were not only tailored on your Service Managersystem but also changed on the upgrade version when you select Replace RAD. After upgrade, your tailored object was renamed to PRE<old version number><object name> and the Upgrade Utility added a new object <object name>. Note: The result occurs only after applying the out-of-box upgrade; it does not occur after applying the custom upgrade. No further action is necessary for these objects. Tip: If you do not want to replace the RAD Application, you may select Revert. The object <object name> is then renamed to NEW935<object name> and the object PRE<old version number><object name> is renamed to <object name>. The result is then set back to Renamed, Kept Customer or Kept Customer Non-OOB. |
See the following table for some examples about how the upgrade result types are marked for an existing record.
OOB record (9.30) | OOB record (9.33) | Customer record (9.33) | OOB record (9.35) | Upgrade Utility check sequence |
Upgrade Utility check condition |
Conflict flag | Upgrade result type | Upgrade result value |
---|---|---|---|---|---|---|---|---|
111 | 112 | 112 | 112 | 1 | Customer record (9.33) = OOB record (9.35) | No | Already Current | 112 |
111 | 112 | 112 | 113 | 2 | Customer record (9.33) != OOB record(9.35) and Customer record (9.33) = OOB record (9.33) | No | Upgraded | 113 |
111 | 112 | 113 | 112 | 3 | Customer record (9.33) != OOB record (9.35) and Customer record (9.33) != OOB record (9.33) and OOB record (9.33) = OOB record (9.35) |
No | Kept Customer | 113 |
111 | 112 | 113 | 114 | 4 | Customer record (9.33) != OOB record (9.35) and Customer record (9.33) != OOB record (9.35) and OOB record (9.33) != OOB record (9.35) |
Yes | Renamed | 113 |
For each object marked as "Renamed" in the Upgrade Results list, the Upgrade Utility generates XML objects for the three versions of the object: base, customer, and upgrade.
Version | Location | Description |
---|---|---|
base | Upgrade\3waymerge\work\base | An XML representation of every object that has been signatured in the pre-upgrade out-of-box version. |
customer | Upgrade\3waymerge\work\customer | An XML representation of all objects that were tailored in the customer version and resulted in a conflict during the upgrade. |
upgrade | Upgrade\3waymerge\work\upgrade | An XML representation of the object provided by the upgrade package of all objects that resulted in a conflict. |
Each of the three folders described above contains a sub-folder for each signatured table. You can find the XML representations of the objects in the table within these sub-folders.
The built-in, two-way/three-way Merge tool allows you to examine the upgrade and customer versions of a record in a side-by-side view as well as the base, upgrade, and customer versions of a record in a three-way view. This will help you to determine which changes to include in the final record.
Note: The tool does not work with RAD applications.
This tool assists the conflict resolution process in these two ways:
To use the Merge tool, follow these steps:
In the Result drop-down list, select Renamed.
Note: The Two-way/Three-way Merge tool is available only for “Renamed” records.
The current default merge mode is Three-Way Merge mode. The merge option is not available for format records. Instead, you can click Compare option from the More Actions menu to start the merge tool in read-only mode. You can use this mode to identify the differences in the side-by-side view or three-way view and then merge records manually in Forms Designer.
In Three-Way Merge mode, click the Show Ancestor Pane button to show the base record reference. Click the button again to hide the base record reference.
In Three-Way Merge mode, if the records of base, upgrade, and customer versions are all different, the background color is red. If you put the cursor into the records with the red background and then click the Copy Current Change from Left to Right button, the selected records from the left pane will be appended to selected records in the right pane.
In Three-Way Merge mode, if the records on the left contain red background records, and you then click the Copy All from Left to Right button, the records in the right pane with blue background will be replaced with selected records from the left pane.
Note: The right records with red background will not be changed. To do this, you will need to switch to Two-Way Merge mode to use Copy All from Left to Right feature.
To enter Two-Way Merge mode, click the Two-Way Compare (Ignore Ancestor) button. In this mode, the Show Ancestor Pane button is disabled.
Note: When you do this, the button label changes to Three-Way Compare. Click this again to revert to Three-Way Compare mode.
In Two-Way-Merge mode, click Copy All from Left to Right button to replace all records in the right pane with the records from the left pane.
You may also visually compare the three versions of each object using a three-way compare and merge tool outside Service Manager, and then merge them manually in Service Manager. For example, you can use a tool, such as KDiff3 for Windows, to compare and merge objects.
To download and learn about KDiff3, visit the KDiff3 Web site.
A brief example of using KDiff3 to compare the three versions of an object is provided in the following steps:
Compare the three versions of the object in the 3-way compare view.
Manually apply the changes you have identified to the object in Service Manager.
If, during the upgrade, the Upgrade Utility automatically merges some of your objects with the upgraded versions of the objects, the Upgrade Results reports lists these merged objects as Auto Merged. You can use the Revert feature in the drop-down options menu to restore "Auto Merged" or "Renamed" objects or "Replaced" Application Cluster objects to their original states. From the drop-down options menu, select Revert to restore one object or select Mass Revert to restore multiple objects. After you restore an object, you can also reapply the Auto Merge to that object by selecting the Auto Merge or Mass Auto Merge option from the drop-down options menu.
Note: If you do not choose to use the auto-merge option, you must manually unzip the OOB data to the same folder in which you extracted the Merge Tool. If you do choose the auto-merge option, the OOB data is extracted automatically by the Merge Tool.
During the Upgrade process, you can use the Mass Choose Upgrade feature to overwrite your systems old objects with the newer versions from the upgrade utility. You can use this feature to quickly update the objects of the following statuses, which are generated during the upgrade:
You can use this feature to quickly update Application Cluster objects of the following statuses:
To use the Mass Choose Upgrade feature, follow these steps:
After you click Yes, the objects that you selected will be updated with the contents of the newer versions from the upgrade utility.
During the Upgrade process, you must mark conflicting objects as “Reconciled” after resolving each conflict. To help with this process, you can use the Mass Mark as Reconciled feature to mark multiple objects as “Reconciled.” You can use this feature on objects with the following statuses:
To use the Mass Mark as Reconciled feature, follow these steps:
If more than two objects exist in the resulting search, click the Mass Mark as Reconciled button from the More Actions menu and then click Yes. After you click Yes, all objects that you selected will be marked as “Reconciled” and removed from current conflict list.
Note: If only one object exits in the resulting search, or if you want to resolve conflicts for the selected objects individually, you can use the Mark as Reconciled button from the More Actions menu on each object instead of the Mass Mark as Reconciled button.
You can follow the standard conflict resolution process to resolve conflicts for RAD applications. Since a RAD application is made up of records from several different tables, the Upgrade Results report assigns an object type of Application Cluster for RAD application objects with conflicts.
Note: The codes for RAD applications for which "Current Release Level" is not marked as "SM 9.35" (for example "7.1"), are already current with the ones in Service Manager9.35. Therefore, you should not change the "Current Release Level" field to "SM 9.35". There are two cases in which a RAD application's "Current Release Level" may be marked as "SM 9.35":
Records with the Application Cluster object type appear in the Upgrade Results list only in the following scenarios:
Your organization has applied a hotfix or patch that included a RAD application, which changed the existing RAD application when it was loaded into the system.
Option 3 is not applicable to you. You can keep the new version of the RAD application that came with the upgrade package or keep the RAD application that was loaded with the hotfix or patch. In most cases, you need the newest version of the RAD application, the one that came with the upgrade package. In this scenario, you can use "Revert" or "Choose Upgrade" to resolve RAD application conflicts; alternatively, if you want to resolve the conflicts manually, you can delete a RAD application and rename a RAD application:
The Upgrade Utility upgrades the display components and reports discrepancies if any of your components differ from the new versions. You can follow the standard conflict resolution process to resolve these conflicts. However, you must pay special attention to following types of display components:
The Display RAD application (RAD=display) is a Service Manager RAD application that provides access to RAD features without requiring RAD programming skills or RAD licensing. If a Display RAD application appears in the Upgrade Results report, perform conflict resolution on that application by following the standard conflict resolution process. HP highly recommends that you use the new version of the application.
Display screen records (displayscreen) are individual records identified by a unique screen ID. The displayscreen records define the attributes of a screen and provide access to the individual records for options and events. A display screen is not the same as a form. If displayscreen objects appear in the Upgrade Results report, perform conflict resolution on the objects by following the standard conflict resolution process.
Caution: There are triggers attached to the displayscreen file. Changes to the records in this file affect their associated display options and events.
The Upgrade Utility upgrades the display components in the same manner as all other components. The displayoption table and displayevent table have a unique identifier stored in the ID field. The upgrade process assigns an ID to every display option, following the convention <screen id>_<action>_<number> where the screen ID and action are from the display option or event, and the number is an optional field added when multiple options have the same screen ID and action.
If options that have been added to your system have the same action as others in the same display screen, the upgrade process assigns a <number> in the order of the options' GUI option number. If an added option was not the last option in terms of GUI option number, the upgrade process does not add the additional numbers in the ID field in the same order as it would have for an out-of-box system. The upgrade process renames the added option and any option after it (in GUI option order) and does not upgrade the option or event automatically.
To make sure that this type of renaming does not happen in future upgrades, when performing conflict resolution on these options, use the ID of the renamed option, NEW935<screen id>_<action>_<number>, and change the identifier of the added options. Rename all other options to match the ID of the renamed ones. When renaming an option, use an identifier to specify that this is a customized option added for your installation. For example, apm.edit.problem_do_nothing_ACME1.
The following table gives an example of part of the display screen conflict resolution for apm.edit.problem.
Screen ID | GUI action | Upgrade action | User action |
---|---|---|---|
300 | do nothing | update |
Name: apm.edit.problem_do_nothing_1 Result: This item was updated correctly. User action: No action necessary. |
400 | do nothing | update |
Name: apm.edit.problem_do_nothing_2 Result: This item was updated correctly. User action: No action necessary. |
450 (this is an option that you added) | do nothing | rename |
Name: apm.edit.problem_do_nothing_3 Result: This item was renamed. It is your customized option. User action: Rename this object to give it a unique name. For example, apm.edit.problem_do_nothing_ACME1. Name: NEW935apm.edit.problem_do_nothing_3 Result: This is the new SM9.35 option. User action: Perform conflict resolution. To perform conflict resolution, open apm.edit.problem and look at the options. Compare this option with apm.edit.problem_do_nothing_3 and NEW935apm.edit.problem_do_nothing_3. |
500 | do nothing | The upgrade ignores this option. |
Result: This option does not appear in the reports. User action: Perform conflict resolution. To perform conflict resolution, open apm.edit.problem and look at the options. Compare this option with apm.edit.problem_do_nothing_3 and NEW935apm.edit.problem_do_nothing_3. |
HP Service Manager requires that every operator have a contact record. You can, however, have a contact record without a corresponding operator record. Review your existing operator records and create a contact record for every operator record that does not already have one. Service Manager provides four wizards that you can use to create the missing contact or operator records. These wizards become available when you click the drop-down options menu icon in the contacts.g and operator.g forms.
Disable the Synchronize contacts with operators option in the System Information Definition before running these wizards:
You can customize how the wizards map fields from the contacts and operator tables by editing the createUsers JavaScript in the script library.
In Problem Management, profile records now contain settings to control access to Known Error Tasks. After you update your applications, the settings in the Known Error Tasks section of the profile records are not populated. Therefore, no users can access this feature. You must update your profile records to enable users to view and modify records within Known Error Tasks.
The Service Desk application uses these fields to list contacts for new calls:.
Specify the contact for the callback.contact and contact.name fields for each existing Service Desk ticket in your system. You can use the Complex Update feature to fill these fields automatically if you have a large number of records. Once you select a contact (callback.contact), the other field, if left blank, defaults to the callback.contact.
For Change Management with Web Services, the following fields in the cm3r table must be exposed after an upgrade:
These are now mandatory fields when opening or closing a Change record, so they must be accounted for in any Web services definitions. HP also recommends that you expose the emergency field in the cm3r table to support emergency changes.
To expose the fields, add them to the appropriate extaccess records for the cm3r table published in the Web services API.
For Incident Management with Web Services, expose the affected.item field in the cm3r table following an upgrade of the server. This is now a mandatory field when opening or closing an Incident record, so it must be accounted for in any Web services definitions.
To expose the field, add it to the appropriate extaccess records for the probsummary table published in the Web services API.
In the Incident Management and Service Desk applications, the utility renamed the Configuration Item label to Affected Item. Review customized menus, formats, and messages that refer to Configuration Items and make any necessary changes to match the new naming convention (Affected Item).
Several Service Manager applications now support the use of multiple service level agreements (SLAs) for interactions, incidents, problem records and problem tasks, and change records. Service Manager uses a new agreement.ids array field instead of the scalar agreement.id field to represent SLA IDs. Therefore, you must identify your tailoring that references the agreement.id field and make changes accordingly. To do so, scan for references in tailoring that explicitly have agreement.id in an expression, and update each of those expressions so that it points to the agreement.ids field. Such references may reside in Format Control, Process, Scripts, Wizards, and other areas.
If an expression contains:
if agreement.id in $L.file=13 then $L.x="abc"
, you can change it to the following: if index(agreement.ids in $L.file,13)>0 then $L.x="abc"
.
To identify tailoring that references agreement.id, you can use the out-of-box RAD function findAll, as described in these steps:
If any applications use the agreement.id field for SLA management, you must set the SLA ID Field to agreement.ids in the SLA Integration record for each application (by opening Service Level Management > SLA Administration > Configure Application). For example, change the SLA ID Field to agreement.ids for these applications:
The format of the Service Catalog data now allows for localization. For each Service Catalog item, the Upgrade Utility creates a record in the svcDisplay table for a language available on your system. The utility copies the original English record and adds a language code to each copy. Follow these steps in this section to localize your Service Catalog items:
If the Upgrade Utility found duplicates when imposing a Unique or No Duplicates key on a field, the utility fixed the duplicates by appending suffixes such as -dup1, - dup2, ...-dupx.
To change automatically modified values to your own values, follow these steps:
Search for -dup and locate a message that resembles the following:
RTE I scan: fix duplicates, changed column COLUMN_NAME in TABLE_
NAME to new value: ORIGINAL-dup1
This message indicates that the utility found duplicates in the COLUMN_NAME field in the TABLE_NAME table, and it changed all duplicates other than the first instance from ORIGINAL to ORIGINAL-dup1, ORIGINAL-dup2, and so on.
After the upgrade, the system may not work correctly until you return it to its normal operating environment.
Note: Service Manager does not recompile indexes in your RDBMS. If your RDBMS is not configured to recompile indexes automatically after index changes, recompile your indexes manually.
After you resolve all conflicts, perform functional testing on the upgraded system and verify that it functions properly. In addition, make a checkpoint backup of the data files to enable you to restore from this point if necessary. Refer to the documentation for your RDBMS for backup instructions.
This section describes how to build a custom upgrade to apply to your production system. Before you create and apply a custom upgrade, make sure that all conflicts are resolved. A custom upgrade consists of three types of files:
To create the custom upgrade, follow these steps:
Create a custom upgrade folder on the Service Manager server. For example, C:\temp\customupgrade. Make sure that the custom upgrade folder is empty.
Create a custom upgrade folder on the Service Manager server. For example, /tmp/customupgrade. Make sure that the custom upgrade folder is empty.
Note: If you are connecting to the Service Manager server from a client on a remote computer, make sure that the you create the custom upgrade folder on the Service Manager server and not the client computer.
Click Create an Upgrade. The Service Manager Upgrade Builder guides you through questions about the upgrade process.
The Upgrade Utility automatically checks for duplicate records prefixed with "PRE", "NEW" or "OLD".
If there is duplicate data, click Next.
The Upgrade Utility asks you to confirm the purge operation.
Select Yes to purge the duplicate data.
If you select No, you will need to manually perform the purge operation as described in Perform additional manual tasks.
Review the list of supported non-English languages that the Upgrade Utility will upgrade. By default, the languages that are installed on your system are set to true. Select false for the languages that you do not want to upgrade.
Note: You cannot rerun the upgrade to select additional languages. Make sure that all languages that you want to upgrade are set to true.
Provide the fully qualified path to the custom upgrade directory that you created in step 1.
Provide the fully qualified path to the custom upgrade directory that you created in step 1.
When building the custom upgrade, the Upgrade Utility creates a set of log files, which reside in the same directory as the upgrade files. The following table describes the contents of the log files during this step.
Log file | Contents |
---|---|
detail.log |
This file contains specific information about the upgrade, including the following:
|
transfer.log |
This file contains information about the object being transferred by the upgrade, for example, “2014-03-20 15:12:27 Initiating an export of scmessage on query "((class="error" and message.id isin {"10"})) and syslanguage~="xxx""” |
upgrade.log |
This file contains information about where the upgrade is at any point, including the following:
|
Duplicate your current ServiceCenter or Service Manager production environment and create a test environment for running and testing the custom upgrade before you apply it to the production environment. Set up the duplicate environment to match your current production server exactly. Make sure that the operating system and service pack level on the test environment is identical to the production server.
Identify a server to use for the test environment.
Before you proceed, make sure that you have upgraded your server and client to version 9.35.
To prepare the server for the upgrade, edit the Service Manager configuration (sm.cfg) and initialization (sm.ini) files. Note that you must return the sm.ini and sm.cfg files to their original state after the upgrade, so you may want to keep copies of the original files.
sm system.start
line to disable the #sm system.start background processes.Add sm -sync
to the end of the file if it does not yet exist. This parameter starts the sync process, which identifies and releases locks owned by inactive processes and shared memory that is
not in use.
sm -httpPort
parameter, comment out all instances except for one. Each sm -httpPort
parameter starts
a Service Manager server process.
The upgrade needs only one process. Comment out all other parameters. Commenting out the parameters
disables all of the other Service Manager processes that are not
required during an upgrade.sessiontimeout:1200
parameter to the end
of the file if it does not exist. If
this parameter exists,
update it to an appropriate
value. This parameter defines the number of minutes that the server waits for a client signal before the server assumes that the client session has timed out and closes the connection. A value of 1200 sets the
timeout to 20 hours (1200 minutes), a
period that should be long enough for an
upgrade phase to complete in a
typical scenario.heartbeatinterval:120
parameter to the end of the file if it does not exist. This parameter defines the number of
seconds that the server waits for a
client heartbeat signal before the server assumes that the client session has timed out and closes the connection.If you use HP-UX, add the JVMOption(#):-Xss6M
JVM option to the end of the file if it does not exist: . This parameter increases the Java virtual machine stack size to 6MB.
When you add the parameter, replace the hash symbol (#) with an option number that does not exist in the sm.ini file. For example, if the file already contains a JVMOption(0)
and JVMOption(1)
, add JVMOption(2):-Xss6M
to the file.
shared_
memory:32000000
with
shared_memory:96000000
. This sets the shared memory size to
96MB. However, if you have a large
database, you may need to allocate
more shared memory to
accommodate the upgrade
processing.ir_disable:1
to the end of the file.Place the custom upgrade folder on the test server. For example, C:\temp\customupgrade.
Place the custom upgrade folder on the test server. For example, /tmp/customupgrade.
Click Window > Preferences > HP Service Manager and clear the Client side load/unload check box.
Caution: Failure to disable the Client side load/unload option causes the upgrade process to fail.
In the File Name field, navigate to the custom upgrade directory that you created, and double-click preupg.bin. For example, C:\temp\customupgrade\preupg.bin.
In the File Name field, navigate to the custom upgrade directory that you created, and double-click preupg.bin. For example, /tmp/customupgrade/preupg.bin.
Type the fully qualified path to the custom upgrade folder that you created. For example, C:\temp\customupgrade.
Type the fully qualified path to the custom upgrade folder that you created. For example, /tmp/customupgrade.
Tip: Note how long it takes to apply the custom upgrade so that you can determine how long the production system will be unavailable during the production upgrade.
Caution: If you experience problems such as a power failure or a network connection error while upgrading the system, you can fix the issues and rerun the Upgrade Utility. The utility resumes the upgrade from the failure point. However, if the upgrade does not resume from the failure point, restore your database to the last backup point and fix possible issues; then rerun the Upgrade Utility.
Review the list of supported non-English languages that the Upgrade Utility will upgrade. By default, the languages that are installed on your system are set to true. Select false for the languages that you do not want to upgrade, and then click Next.
Note: You cannot rerun the upgrade to select additional languages. Make sure that all languages that you want to upgrade are set to true.
The utility asks if you want to generate To Do records for all existing open records in the major modules. If you want to generate all open application records, leave the Generate To Do records check box selected, and then click Next.
Depending on the number of records in your Change Management, Incident Management, Service Desk, Problem Management, and Request Management applications, this step can take a significant amount of time. If you have a large number of records, you can choose to generate the records after completing the upgrade by typing *aapm.upgrade.todo in the Service Manager command line.
When you receive an UPGRADE IS COMPLETE message, the Upgrade Utility has finished the data processing and you can follow the instructions in the message to complete the next steps. After you close the message dialog, you are automatically logged out.
The Upgrade Utility does not automatically upgrade all tables and records. You can view the patches record to see a list of the tables and records that the custom upgrade includes. To view the patches record, click SERVICE PACK > Update Patch Definitions in the Upgrade Utility.
Customizations made to tables or records that do not appear in the patches record do not get upgraded. To make sure that the objects that you have reconciled are moved to the production system, verify that the patches record includes these objects. If it does not, you can do one of the following:
When applying the custom upgrade to the test system, the Upgrade Utility creates a set of log files, which reside in the same directory as the custom upgrade files.
The contents of these log files are similar to those in the log files when running an out-of-box upgrade.
This section describes changes that the Upgrade Utility cannot make automatically. Make the following changes manually.
The Upgrade utility does not automatically clean up artifacts that were left over by the upgrade, such as objects that were prefixed with PRE<version_number> or NEW935, which are copied and renamed from pre-upgrade objects. These objects must be delete from the exported list. Otherwise, the system may not work as expected. To make the system work as expected, the purge tool provides a function to clean up artifacts that were left over by the upgrade. To run the purge tool, follow these steps:
Or, you may manually delete those objects against the exported list. To find those objects, search the Upgrade Results list for records with a result type of "Auto Merged" "Previously Reconciled" "Reconciled" or "Renamed" and then export the list to an Excel file.
HP Service Manager requires that every operator have a contact record. You can, however, have a contact record without a corresponding operator record. Review your existing operator records and create a contact record for every operator record that does not already have one. Service Manager provides four wizards that you can use to create the missing contact or operator records. These wizards become available when you click the drop-down options menu icon in the contacts.g and operator.g forms.
Disable the Synchronize contacts with operators option in the System Information Definition before running these wizards:
You can customize how the wizards map fields from the contacts and operator tables by editing the createUsers JavaScript in the script library.
In Problem Management, profile records now contain settings to control access to Known Error Tasks. After you update your applications, the settings in the Known Error Tasks section of the profile records are not populated. Therefore, no users can access this feature. You must update your profile records to enable users to view and modify records within Known Error Tasks.
The Service Desk application uses these fields to list contacts for new calls:.
Specify the contact for the callback.contact and contact.name fields for each existing Service Desk ticket in your system. You can use the Complex Update feature to fill these fields automatically if you have a large number of records. Once you select a contact (callback.contact), the other field, if left blank, defaults to the callback.contact.
For Change Management with Web Services, the following fields in the cm3r table must be exposed after an upgrade:
These are now mandatory fields when opening or closing a Change record, so they must be accounted for in any Web services definitions. HP also recommends that you expose the emergency field in the cm3r table to support emergency changes.
To expose the fields, add them to the appropriate extaccess records for the cm3r table published in the Web services API.
For Incident Management with Web Services, expose the affected.item field in the cm3r table following an upgrade of the server. This is now a mandatory field when opening or closing an Incident record, so it must be accounted for in any Web services definitions.
To expose the field, add it to the appropriate extaccess records for the probsummary table published in the Web services API.
In the Incident Management and Service Desk applications, the utility renamed the Configuration Item label to Affected Item. Review customized menus, formats, and messages that refer to Configuration Items and make any necessary changes to match the new naming convention (Affected Item).
Several Service Manager applications now support the use of multiple service level agreements (SLAs) for interactions, incidents, problem records and problem tasks, and change records. Service Manager uses a new agreement.ids array field instead of the scalar agreement.id field to represent SLA IDs. Therefore, you must identify your tailoring that references the agreement.id field and make changes accordingly. To do so, scan for references in tailoring that explicitly have agreement.id in an expression, and update each of those expressions so that it points to the agreement.ids field. Such references may reside in Format Control, Process, Scripts, Wizards, and other areas.
If an expression contains:
if agreement.id in $L.file=13 then $L.x="abc"
, you can change it to the following: if index(agreement.ids in $L.file,13)>0 then $L.x="abc"
.
To identify tailoring that references agreement.id, you can use the out-of-box RAD function findAll, as described in these steps:
If any applications use the agreement.id field for SLA management, you must set the SLA ID Field to agreement.ids in the SLA Integration record for each application (by opening Service Level Management > SLA Administration > Configure Application). For example, change the SLA ID Field to agreement.ids for these applications:
The format of the Service Catalog data now allows for localization. For each Service Catalog item, the Upgrade Utility creates a record in the svcDisplay table for a language available on your system. The utility copies the original English record and adds a language code to each copy. Follow these steps in this section to localize your Service Catalog items:
If the Upgrade Utility found duplicates when imposing a Unique or No Duplicates key on a field, the utility fixed the duplicates by appending suffixes such as -dup1, - dup2, ...-dupx.
To change automatically modified values to your own values, follow these steps:
Search for -dup and locate a message that resembles the following:
RTE I scan: fix duplicates, changed column COLUMN_NAME in TABLE_
NAME to new value: ORIGINAL-dup1
This message indicates that the utility found duplicates in the COLUMN_NAME field in the TABLE_NAME table, and it changed all duplicates other than the first instance from ORIGINAL to ORIGINAL-dup1, ORIGINAL-dup2, and so on.
After the upgrade, the system may not work correctly until you return it to its normal operating environment.
Note: Service Manager does not recompile indexes in your RDBMS. If your RDBMS is not configured to recompile indexes automatically after index changes, recompile your indexes manually.
Perform user acceptance testing on the test environment to verify that it functions properly. If there are problems that you cannot resolve, contact HP Software Support.
Before you proceed, make sure that you have upgraded your server and client to version 9.35.
To prepare the server for the upgrade, edit the Service Manager configuration (sm.cfg) and initialization (sm.ini) files. Note that you must return the sm.ini and sm.cfg files to their original state after the upgrade, so you may want to keep copies of the original files.
sm system.start
line to disable the #sm system.start background processes.Add sm -sync
to the end of the file if it does not yet exist. This parameter starts the sync process, which identifies and releases locks owned by inactive processes and shared memory that is
not in use.
sm -httpPort
parameter, comment out all instances except for one. Each sm -httpPort
parameter starts
a Service Manager server process.
The upgrade needs only one process. Comment out all other parameters. Commenting out the parameters
disables all of the other Service Manager processes that are not
required during an upgrade.sessiontimeout:1200
parameter to the end
of the file if it does not exist. If
this parameter exists,
update it to an appropriate
value. This parameter defines the number of minutes that the server waits for a client signal before the server assumes that the client session has timed out and closes the connection. A value of 1200 sets the
timeout to 20 hours (1200 minutes), a
period that should be long enough for an
upgrade phase to complete in a
typical scenario.heartbeatinterval:120
parameter to the end of the file if it does not exist. This parameter defines the number of
seconds that the server waits for a
client heartbeat signal before the server assumes that the client session has timed out and closes the connection.If you use HP-UX, add the JVMOption(#):-Xss6M
JVM option to the end of the file if it does not exist: . This parameter increases the Java virtual machine stack size to 6MB.
When you add the parameter, replace the hash symbol (#) with an option number that does not exist in the sm.ini file. For example, if the file already contains a JVMOption(0)
and JVMOption(1)
, add JVMOption(2):-Xss6M
to the file.
shared_
memory:32000000
with
shared_memory:96000000
. This sets the shared memory size to
96MB. However, if you have a large
database, you may need to allocate
more shared memory to
accommodate the upgrade
processing.ir_disable:1
to the end of the file.Place the custom upgrade folder on the production server. For example, C:\temp\customupgrade.
Place the custom upgrade folder on the production server. For example, /tmp/customupgrade.
Click Window > Preferences > HP Service Manager and clear the Client side load/unload check box.
Caution: Failure to disable the Client side load/unload option causes the upgrade process to fail.
In the File Name field, navigate to the custom upgrade directory that you created, and double-click preupg.bin. For example, C:\temp\customupgrade\preupg.bin.
In the File Name field, navigate to the custom upgrade directory that you created, and double-click preupg.bin. For example, /tmp/customupgrade/preupg.bin.
Type the fully qualified path to the custom upgrade folder that you created. For example, C:\temp\customupgrade.
Type the fully qualified path to the custom upgrade folder that you created. For example, /tmp/customupgrade.
Make sure that users cannot access the production system before you start the upgrade.
Caution: If you experience problems such as a power failure or a network connection error while upgrading the system, you can fix the issues and rerun the Upgrade Utility. The utility resumes the upgrade from the failure point. However, if the upgrade does not resume from the failure point, restore your database to the last backup point and fix possible issues; then rerun the Upgrade Utility.
Review the list of supported non-English languages that the Upgrade Utility will upgrade. By default, the languages that are installed on your system are set to true. Select false for the languages that you do not want to upgrade, and then click Next.
Note: You cannot rerun the upgrade to select additional languages. Make sure that all languages that you want to upgrade are set to true.
The utility asks if you want to generate To Do records for all existing open records in the major modules. If you want to generate all open application records, leave the Generate To Do records check box selected, and then click Next.
Depending on the number of records in your Change Management, Incident Management, Service Desk, Problem Management, and Request Management applications, this step can take a significant amount of time. If you have a large number of records, you can choose to generate the records after completing the upgrade by typing *aapm.upgrade.todo in the Service Manager command line.
When you receive an UPGRADE IS COMPLETE message, the Upgrade Utility has finished the data processing and you can follow the instructions in the message to complete the next steps. After you close the message dialog, you are automatically logged out.
The Upgrade Utility does not automatically upgrade all tables and records. You can view the patches record to see a list of the tables and records that the custom upgrade includes. To view the patches record, click SERVICE PACK > Update Patch Definitions in the Upgrade Utility.
Customizations made to tables or records that do not appear in the patches record do not get upgraded. To make sure that the objects that you have reconciled are moved to the production system, verify that the patches record includes these objects. If it does not, you can do one of the following:
This section describes changes that the Upgrade Utility cannot make automatically. Make the following changes manually.
The Upgrade utility does not automatically clean up artifacts that were left over by the upgrade, such as objects that were prefixed with OLD<version_number> which are copied and renamed from pre-upgrade objects. These objects must be delete from the exported list. Otherwise, the system may not work as expected. To make the system work as expected, the purge tool provides a function to clean up artifacts that were left over by the upgrade. To run the purge tool, follow these steps:
Or, you may do it manually. To find those objects, search the Upgrade Results list for records with a result type of "Forced" and then export the list to an Excel file. To make added or upgraded display options work as expected, you must manually re-save all the related display screens. To find those display screens, search the Upgrade Results list for display options records with a result type of "Added" or "Forced" and export the list to an Excel file.
HP Service Manager requires that every operator have a contact record. You can, however, have a contact record without a corresponding operator record. Review your existing operator records and create a contact record for every operator record that does not already have one. Service Manager provides four wizards that you can use to create the missing contact or operator records. These wizards become available when you click the drop-down options menu icon in the contacts.g and operator.g forms.
Disable the Synchronize contacts with operators option in the System Information Definition before running these wizards:
You can customize how the wizards map fields from the contacts and operator tables by editing the createUsers JavaScript in the script library.
In Problem Management, profile records now contain settings to control access to Known Error Tasks. After you update your applications, the settings in the Known Error Tasks section of the profile records are not populated. Therefore, no users can access this feature. You must update your profile records to enable users to view and modify records within Known Error Tasks.
The Service Desk application uses these fields to list contacts for new calls:.
Specify the contact for the callback.contact and contact.name fields for each existing Service Desk ticket in your system. You can use the Complex Update feature to fill these fields automatically if you have a large number of records. Once you select a contact (callback.contact), the other field, if left blank, defaults to the callback.contact.
For Change Management with Web Services, the following fields in the cm3r table must be exposed after an upgrade:
These are now mandatory fields when opening or closing a Change record, so they must be accounted for in any Web services definitions. HP also recommends that you expose the emergency field in the cm3r table to support emergency changes.
To expose the fields, add them to the appropriate extaccess records for the cm3r table published in the Web services API.
For Incident Management with Web Services, expose the affected.item field in the cm3r table following an upgrade of the server. This is now a mandatory field when opening or closing an Incident record, so it must be accounted for in any Web services definitions.
To expose the field, add it to the appropriate extaccess records for the probsummary table published in the Web services API.
In the Incident Management and Service Desk applications, the utility renamed the Configuration Item label to Affected Item. Review customized menus, formats, and messages that refer to Configuration Items and make any necessary changes to match the new naming convention (Affected Item).
Several Service Manager applications now support the use of multiple service level agreements (SLAs) for interactions, incidents, problem records and problem tasks, and change records. Service Manager uses a new agreement.ids array field instead of the scalar agreement.id field to represent SLA IDs. Therefore, you must identify your tailoring that references the agreement.id field and make changes accordingly. To do so, scan for references in tailoring that explicitly have agreement.id in an expression, and update each of those expressions so that it points to the agreement.ids field. Such references may reside in Format Control, Process, Scripts, Wizards, and other areas.
If an expression contains:
if agreement.id in $L.file=13 then $L.x="abc"
, you can change it to the following: if index(agreement.ids in $L.file,13)>0 then $L.x="abc"
.
To identify tailoring that references agreement.id, you can use the out-of-box RAD function findAll, as described in these steps:
If any applications use the agreement.id field for SLA management, you must set the SLA ID Field to agreement.ids in the SLA Integration record for each application (by opening Service Level Management > SLA Administration > Configure Application). For example, change the SLA ID Field to agreement.ids for these applications:
The format of the Service Catalog data now allows for localization. For each Service Catalog item, the Upgrade Utility creates a record in the svcDisplay table for a language available on your system. The utility copies the original English record and adds a language code to each copy. Follow these steps in this section to localize your Service Catalog items:
If the Upgrade Utility found duplicates when imposing a Unique or No Duplicates key on a field, the utility fixed the duplicates by appending suffixes such as -dup1, - dup2, ...-dupx.
To change automatically modified values to your own values, follow these steps:
Search for -dup and locate a message that resembles the following:
RTE I scan: fix duplicates, changed column COLUMN_NAME in TABLE_
NAME to new value: ORIGINAL-dup1
This message indicates that the utility found duplicates in the COLUMN_NAME field in the TABLE_NAME table, and it changed all duplicates other than the first instance from ORIGINAL to ORIGINAL-dup1, ORIGINAL-dup2, and so on.
After the upgrade, the system may not work correctly until you return it to its normal operating environment.
Note: Service Manager does not recompile indexes in your RDBMS. If your RDBMS is not configured to recompile indexes automatically after index changes, recompile your indexes manually.
For all the existing integrations to work correctly, you must remove and re-create certain integrations in the Integration Manager. These integrations include the following:
For more information about your specific integration, see the Integrations section in the HP Service Manager Help Center.
Test the upgraded system and verify that it functions properly. If there are problems that you cannot resolve, contact HP Software Support.
Congratulations! You have completed the upgrade to Service Manager 9.35. You can view the Service Manager 9.35 Help Center for information about database dictionaries, Database Manager, Forms Designer, Request Management, and the Display application.
Before you contact HP Service Manager Customer Support, try the following troubleshooting instructions to identify and resolve your issues. Click a symptom below to view information about the symptom and a possible resolution for the issue.
© 1994-2015 Hewlett-Packard Development Company, L.P.