Highlighted
Absent Member.. Absent Member..
Absent Member..
417 views

Open - Callback Status not getting set

Jump to solution

Looking for help with "Open - Callback" not getting set.

SM Version: Apps: 7.02; Runtime: 7.11

Something "broke" in setting the status of the interaction to "Open - Callback" after a related incident is closed.

Following the workflow described for 9.3, I found the following:

 

schedule: Link Header record for incicent IM2001
Status: application failed due to error - check msglog for possible messages
Expiration: 01/24/12 14:34:48

 

From msglog:
Operator: linker, Time: 1/24/12 14:35:47
Unrecoverable error in application:  scmessage on panel decide.msg.cond
Unrecoverable error in application:  apm.compute.linked.close on panel save.incident.1
Unrecoverable error in application:  apm.start.linked.close on panel process

 

From sm.log:
  2780(  3772) 01/24/2012 14:34:48  RTE I Triggers have been turned off
  2780(  3772) 01/24/2012 14:34:48  RTE I Triggers have been turned on

 

Any ideas where to look?  Is there a particular line in the link record or entry in screlation that we should check out?

Tags (3)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Absent Member.
Absent Member.

Based on your post, I assume you've seen the work-flow outlined here:

http://h30499.www3.hp.com/t5/Service-Manager-Support-Forum/Open-Callback-issue-in-SM-9-30/m-p/5356145/highlight/true#M3534

 

The reported errors in the msglog, assuming us.notify instead of scmessage, state there was a failure evaluating a condition in a notification record. There is insufficient information available to confirm whether this was the primary failure point. In order to get that level of detail, you will need to capture the issue with tracing enabled for the linker background process.

 

The trace will identify the primary areas of concern and also record the notification record that was being processed.

View solution in original post

0 Likes
6 Replies
Highlighted
Absent Member.
Absent Member.

Unrecoverable error in application:  scmessage on panel decide.msg.cond

 

There is no RAD Application named "scmessage" in SM 7.x. However, there is a decide.msg.cond panel in the us.notify RAD Application. If the failure occurred in this app, then the issue is a condition in one of your notification records.

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..
I noticed that... but will fixing a condition in the notification record, assuming we can find it, will that fix the issue of the interaction status not getting changed?
Thanks
0 Likes
Highlighted
Absent Member.
Absent Member.

Based on your post, I assume you've seen the work-flow outlined here:

http://h30499.www3.hp.com/t5/Service-Manager-Support-Forum/Open-Callback-issue-in-SM-9-30/m-p/5356145/highlight/true#M3534

 

The reported errors in the msglog, assuming us.notify instead of scmessage, state there was a failure evaluating a condition in a notification record. There is insufficient information available to confirm whether this was the primary failure point. In order to get that level of detail, you will need to capture the issue with tracing enabled for the linker background process.

 

The trace will identify the primary areas of concern and also record the notification record that was being processed.

View solution in original post

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..
It looks like fixing the condition in SM Update fixed the callback status. Thanks
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

BTW, I found your workflow on the post you mentioned which led me to the various error messages.  Where are these workflows documented?  Are you using Mike Sanders book or something else?

Thanks!

0 Likes
Highlighted
Absent Member.
Absent Member.

I'm not aware of a document, official or otherwise, which specifically outlines this work-flow. I happen to be very familiar with this particular area, but the work-flow can be discovered by reviewing traces.

 

In general...

 - if the relevant event is directly related to user activity without an add/update/delete, then consider using the RAD Debugger

 - if the relevant event occurs immediately after user activity but includes an add/update/delete, then trace that user's session with sm.ini parameters (or via command line)

 - if the relevant event occurs some time after user activity, locate the relevant schedule record and then trace the corresponding background process

 

It does require an investment of time to perform the steps and gain the experience, but the ROI is an improved ability to troubleshoot and customize Service Manager. Perhaps the next round of topics in this thread could include: using the RAD Debugger, reading a RAD Application, etc...

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.