Searching the Help
To search for information in the Help, type a word or phrase in the Search box. When you enter a group of words, OR is inferred. You can use Boolean operators to refine your search.
Results returned are case insensitive. However, results ranking takes case into account and assigns higher scores to case matches. Therefore, a search for "cats" followed by a search for "Cats" would return the same number of Help topics, but the order in which the topics are listed would be different.
Search for | Example | Results |
---|---|---|
A single word | cat
|
Topics that contain the word "cat". You will also find its grammatical variations, such as "cats". |
A phrase. You can specify that the search results contain a specific phrase. |
"cat food" (quotation marks) |
Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase. |
Search for | Operator | Example |
---|---|---|
Two or more words in the same topic |
|
|
Either word in a topic |
|
|
Topics that do not contain a specific word or phrase |
|
|
Topics that contain one string and do not contain another | ^ (caret) |
cat ^ mouse
|
A combination of search types | ( ) parentheses |
|
Out-of-box data migration settings
The Data Migration Tool provides the following out-of-box data migration settings.
Problem data migration
Considering that Problem does not need to copy data from two different tables, and that it typically has a large volume of data, we recommend that you run the migration by using the batch update mode (especially for migrating a large volume of closed tickets).
Note After you migrate the Problem data, remove the “Problem_Library_disabled_by_PDHD” knowledge base as this legacy library is no longer used.
The out-of-box example data migration is based on the following three key fields:
- status
- category
- current.phase
Note You can add additional fields if needed, but do not remove these three fields.
Problem
Default settings:
Source Table |
rootcause |
Target Table |
rootcause |
Filter Condition |
category="BPPM" |
Field Mapping:
Target Field |
Source Field |
---|---|
category |
category |
current.phase |
current.phase |
rcStatus |
rcStatus |
Value Mapping:
Target Value Mapping Field |
Mapping Type |
Condition |
Target Value |
---|---|---|---|
category |
fixedValue |
category="BPPM" |
problem |
current.phase |
fixedValue |
(current.phase="Problem Detection, Logging and Categorization" or |
Categorization |
current.phase |
fixedValue |
current.phase="Problem Investigation and Diagnosis" and rcStatus~="Closed" |
Investigation |
current.phase |
fixedValue |
current.phase="Problem Resolution" and rcStatus~="Closed" |
Resolution |
current.phase |
fixedValue |
current.phase="Problem Closure and Review" and rcStatus~="Closed" |
Review |
current.phase |
fixedValue |
rcStatus="Closed" |
Closure |
rcStatus |
fixedValue |
(current.phase="Problem Detection, Logging and Categorization" or current.phase="Problem Prioritization and Planning") and rcStatus~="Closed" and rcStatus~="Deferred" |
Categorize |
rcStatus |
fixedValue |
current.phase="Problem Resolution" and (rcStatus="Pending Vendor" or rcStatus="Pending User") |
Pending |
rcStatus |
fixedValue |
(current.phase="Problem Investigation and Diagnosis" or current.phase="Problem Resolution") and rcStatus~="Closed" and rcStatus~="Deferred" |
Work In Progress |
rcStatus |
fixedValue |
current.phase~="Problem Closure and Review" and rcStatus="Deferred" |
Deferred |
rcStatus |
fixedValue |
current.phase="Problem Closure and Review" and rcStatus~="Closed" |
Resolved |
rcStatus |
fixedValue |
rcStatus="Closed" |
Closed |
Problem Task
Default Settings:
Source Table |
rootcausetask |
Target Table |
rootcausetask |
Filter Condition |
task.category="Default" |
Field Mapping:
Target Field |
Source Field |
---|---|
task.category |
task.category |
current.phase |
current.phase |
rcStatus |
rcStatus |
Value Mapping:
Target Value Mapping Field |
Mapping Type |
Condition |
Target Value |
---|---|---|---|
task.category |
fixedValue |
Investigation |
|
current.phase |
fixedValue |
rcStatus~="Closed" |
Active |
current.phase |
fixedValue |
rcStatus="Closed" |
Closure |
rcStatus |
fixedValue |
rcStatus="Work In Progress" |
Work In Progress |
rcStatus |
fixedValue |
rcStatus="Pending Vendor" or rcStatus="Pending User" |
Pending |
rcStatus |
fixedValue |
rcStatus="Closed" |
Closed |
rcStatus |
fixedValue |
rcStatus~="Work In Progress" and rcStatus~="Pending Vendor" and rcStatus~="Pending User" and rcStatus~="Closed" |
Assigned |
Task Planner data migration
In versions of Service Manager earlier than 9.40, Task Planner data is stored in the changeModel and changePlan tables. However, in Service Manager 9.40, Task Planner data is stored in the changePlan table only. Therefore, two data migration settings are provided to migrate Task Planner data from Service Manager 9.40 and earlier versions.
Migrate legacy change model Task Planner data to new Task Planner
Default settings:
Source table |
changeModel |
Target Table |
changePlan |
Query |
not null(tasks) |
Batch Update |
false |
Field mapping:
Target field |
Source field |
---|---|
fileName |
|
number |
id |
Value mapping:
Target value mapping field |
Mapping type |
Condition |
Target value |
---|---|---|---|
fileName |
fixedValue |
changeModel |
Post script:
for(var i=0;i<$sourceTable.tasks.length();i++){ $targetTable.tasks[i].taskId=$sourceTable.tasks[i].taskId; $targetTable.tasks[i].taskCoords=$sourceTable.tasks[i].taskCoords; $targetTable.tasks[i].dependentIds=$sourceTable.tasks[i].dependentIds; $targetTable.tasks[i].dependentCoords=$sourceTable.tasks[i].dependentCoords; $targetTable.tasks[i].taskCategory=$sourceTable.tasks[i].taskCategory; $targetTable.tasks[i].taskTemplate=$sourceTable.tasks[i].taskTemplate; $targetTable.tasks[i].taskDescription=$sourceTable.tasks[i].taskDescription; $targetTable.tasks[i].openInPhase=$sourceTable.tasks[i].openInPhase; $targetTable.tasks[i].closeByPhase=$sourceTable.tasks[i].closeByPhase; $targetTable.tasks[i].activeCond=$sourceTable.tasks[i].activeCond; $targetTable.tasks[i].activeCondXML=$sourceTable.tasks[i].activeCondXML; $targetTable.tasks[i].activeCondDesc=$sourceTable.tasks[i].activeCondDesc; $targetTable.tasks[i].mandatory=$sourceTable.tasks[i].mandatory; } $targetTable.doUpdate();
Migrate legacy change instance Task Planner data to new Task Planner
Default settings:
Source table |
changePlan |
Target Table |
changePlan |
Query |
null(fileName) |
Batch Update |
true |
Field mapping:
Target field |
Source field |
---|---|
fileName |
fileName |
Value mapping:
Target value mapping field |
Mapping type |
Condition |
Target value |
---|---|---|---|
fileName |
fixedValue |
cm3r |
Migrate legacy change/task data to new Task Planner
In Service Manager Hybrid, task information is stored in the change’s task plan. Change task information must be migrated to the new Task Planner. To do this, use the “Legacy change/task data to new taskplanner” data migration setting in the data migration tool.
Default settings:
Source table |
cm3r |
Target Table |
changePlan |
Query |
open=true |
Batch Update |
Field mapping:
Target field |
Source field |
---|---|
fileName |
|
Number | header,number |
Value mapping:
Target value mapping field |
Mapping type |
Condition |
Target value |
---|---|---|---|
fileName |
|
|
Known Error data migration
Known Error data migration differs from Interaction, Incident, and Problem because Known Error data must be copied from the knownerror file to the rootcause file, and the field mapping is also more extensive than in other modules.
Because it is a data copy, you cannot use the batch update mode. However, knownerror data volume is usually much less than that of Incident or Interaction. Therefore, the normal copy mode should be sufficient for most environments.
Note After you migrate the knownerror data, remove the “KnownError_Library_disabled_by_PDHD” knowledge base as this legacy library is no longer used.
The Data Migration Tool provides four migration settings, which you should run in their corresponding scenario as described in the following table.
Scenario | Migration setting(s) |
---|---|
Migrating from legacy Known Error |
Legacy known error to new known error Legacy known error related record migration Legacy known error attachment to new known error attachment |
Migrating from legacy Process Designer Known Error |
Legacy Process Designer known error to new Process Designer known error For more information about how to use this migration setting, see Migrating from legacy Process Designer known error records. |
Additionally, because knownerror data is copied and the records are re-created in the rootcause file, you must also update the screlation file to correct the relations of known errors. To do this, the out-of-box Process Designer provides another migration script called “Legacy known error related record migration”.
Note Attachments for legacy knownerror records are migrated as attachments for the new known error records.
Default Settings:
Source Table | knownerror |
Target Table | rootcause |
Filter Condition | true |
Field Mappings:
Target Field(Problem) | Source Field(Known Error) |
---|---|
id | id |
category | category |
assignment | assignment |
status | status |
logical.name | logical.name |
brief.description | brief.description |
description | description |
root.cause | root.cause |
update | update |
open | open |
open.time | open.time |
opened.by | opened.by |
update.time | update.time |
updated.by | updated.by |
close.time | close.time |
closed.by | closed.by |
reopen.time | reopen.time |
reopened.by | reopened.by |
priority.code | priority.code |
ticket.owner | ticket.owner |
severity | severity |
sysmodtime | sysmodtime |
sysmodcount | sysmodcount |
sysmoduser | sysmoduser |
assignee.name | assignee.name |
subcategory | subcategory |
product.type | product.type |
problem.type | problem.type |
company | company |
dump | dump |
resolution | resolution |
workaround | workaround |
incident.category | incident.category |
current.phase | current.phase |
incident.count | incident.count |
initial.impact | initial.impact |
future.impact | future.impact |
impact | impact |
users.affected | users.affected |
problem.start.time | problem.start.time |
expected.resolution.time | expected.resolution.time |
location.type | location.type |
frequency | frequency |
proposed.solution | proposed.solution |
review.notes | review.notes |
cause.code | cause.code |
affected.ci | matching.ci |
ci.device.name | matching.device.name |
ci.device.type | matching.device.type |
ci.assign.group | matching.assign.group |
ci.location | matching.location |
affected.companies | affected.companies |
affected.ci.count | matching.ci.count |
last.task.no | last.task.no |
kpf.id | kpf.id |
kpf.file | kpf.file |
folder | folder |
closure.code | closure.code |
estimatedCost | estimatedCost |
estimatedMandays | estimatedMandays |
rootcauseDate | knownerrorDate |
solutionDate | solutionDate |
affected.item | affected.item |
rcStatus | rcStatus |
interaction.count | interaction.count |
publishWorkaround | publishWorkaround |
Value Mappings:
Target Value Mapping Field | Mapping Type | Condition | Target Value |
---|---|---|---|
category |
fixedValue |
true |
known error |
current.phase |
fixedValue |
rcStatus~="Closed" |
Logging |
current.phase |
fixedValue |
rcStatus="Closed" |
Closure |
isKnownError |
fixedValue |
true |
true |
rcStatus |
fixedValue |
rcStatus~="Closed" |
Open |
rcStatus |
fixedValue |
rcStatus="Closed" |
Closed |
Migrating from legacy Process Designer known error records
If you upgraded your system from an older Process Designer version, you need to migrate your old Process Designer knownerror records to new Process Designer knownerror records by using the Legacy PD known error to new PD known error migration setting. The migration process includes the following procedures:
- Change the old Known Error record to Problem record, and then create a new Known Error record with a category of "known error."
- Link the new Known Error record to the Problem record.
-
Copy or do not copy the original relations to the new Known Error record, based on the option you select in the Post Script tab of this migration setting, as described in the following table.
Option for relation processing
Description
Skip Copying Relations to New Known Error Records
This option does not copy original relations to new known error records.
Copy Relations to New Known Error Records
This option copies original relations to new known error records.
Service Level Management data migration
As of Service Manager 9.40, the Service Level Management (SLM) module is reimplemented on Process Designer (PD). If you upgraded from an earlier version of Service Manager, you need to migrate your legacy SLM data so that your SLM module can work correctly on Process Designer-based workflows.
The purpose of SLM data migration is to set a category and set a phase for agreement records based on the following rules:
- The Category of an agreement record is populated with the category of one of the targets if all the targets of the agreement have the same category (that is, the Service Level Category field in the target record).
- The Category of an agreement record is populated with a value of Service Level Agreement if the targets of the agreement have different categories or have an empty category.
- The Phase of an agreement record is populated with “agreed” if the expiration date is later than the current date.
- The Phase of an agreement record is populated with “expired” if the expiration date is earlier than the current date.
For SLM data migration, the Legacy SLA to new Agreement migration setting is provided. See the following tables for its details.
Default settings
Source Table | |
---|---|
Source Table | sla |
Target Table | sla |
Filter Condition | true |
Field Mappings
Source Field | Target Field |
---|---|
agreement.id | agreement.id |
agreements | agreements |
category | |
contacts | contacts |
current.phase | |
customer | customer |
description | description |
display.category | display.category |
expiration | expiration |
external.support.groups | external.support.groups |
Value Mappings
Target Value Mapping Field | Mapping Type | Condition | Target Value |
---|---|---|---|
category | jsCallback | $value=lib.MigrateSLA.migrateSLA(sourceTable['agreement.id']) | |
current.phase | fixedValue | expiration>tod() | agreed |
current.phase | fixedValue | expiration<tod() | expired |
display.category | jsCallback | $value=lib.MigrateSLA.migrateSLA(sourceTable['agreement.id']) |
Related Records data migration
Process Designer-based related records retrieves information that is displayed in the related records columns directly from the screlation table. The table contains a large number of screlation records and the field values are generated based on legacy sccrelconfig settings. Therefore, you must perform data migration in order for the related records section to be displayed correctly.
An out-of-box script ("DataMigrationForRelatedRecords") is available to perform this data migration. To run the script, follow these steps:
- Open the Script Library and search for the "DataMigrationForRelatedRecords" file.
-
Open the file and uncomment the following line:
//migrateScrelations
- Execute the script. The data migration is performed automatically.
Note By default, only active screlation records are migrated (for time-saving purposes). Therefore, if you view inactive (closed ) records in the related records section, the wrong field value may be displayed.
To migrate all the screlation records, uncomment the following line, and then execute the script:
//var REFRESH_All_SCRELATION_RECORDS = "true";
If you have a large number (millions) of screlation records, the script may take hours to update all the records. Therefore, you must ensure that the Windows client session timeout setting is large enough for the script to complete.
Service Catalog data migration
Considering that Service Catalog does not need to copy data from two different tables, and that it typically has a large volume of data, we recommend that you run the migration by using the batch update mode (especially for migrating a large volume of closed records).
The out-of-box example data migration is based on the following two key fields:
- status
- current.phase
Note You can add additional fields if needed, but do not remove these two fields.
Default settings:
Source Table |
svcCatalog |
Target Table |
svcCatalog |
Filter Condition |
null(current.phase) |
Field Mapping:
Target Field |
Source Field |
---|---|
current.phase |
|
status |
|
Value Mapping:
Target Value Mapping Field |
Mapping Type |
Condition |
Target Value |
---|---|---|---|
current.phase |
fixedValue |
active="t" |
Published |
current.phase |
fixedValue |
null(active) or active="t" |
Retired |
status |
fixedValue |
null(active) or active="t" |
Retired |
status |
fixedValue |
active="t" |
Operational |
Configuration Item data migration
Considering that Configuration Item does not need to copy data from two different tables, and that it typically has a large volume of data, we recommend that you run the migration by using the batch update mode.
The out-of-box example data migration is based on the following key field:
- current.phase
Note You can add additional fields if needed, but do not remove these two fields.
Default settings:
Source Table |
device |
Target Table |
device |
Filter Condition |
null(current.phase) |
Field Mapping:
Target Field |
Source Field |
---|---|
current.phase |
|
Value Mapping:
Target Value Mapping Field |
Mapping Type |
Condition |
Target Value |
---|---|---|---|
current.phase |
fixedValue |
istatus=null or (istatus~="Missing" and istatus~="Retired/Consumed" and istatus~="Return for Maintenance" and istatus~="Return to Supplier") |
Active |
current.phase |
fixedValue |
istatus="Missing" or istatus="Retired/Consumed" or istatus="Return for Maintenance" or istatus="Return to Supplier" |
Inactive |
Re-index the knowledge bases
After you remove the Problem_Library_disabled_by_PDHD
and KnownError_Library_disabled_by_PDHD
knowledgebases, you must run a full re-index of the knowledgebases if you use Knowledge Management in a production environment.