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 |
|
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.
We welcome your comments!
To open the configured email client on this computer, open an email window.
Otherwise, copy the information below to a web mail client, and send this email to ovdoc-ITSM@hpe.com.
Help Topic ID:
Product:
Topic Title:
Feedback: