CA Service Management

Currently in my stdlog file I am seeing the following message repeatedly:

09/20 15:19:54.07 sdbs1          spelsrvr             2456 SIGNIFICANT  cr.spl                 438 Transition from 'Resolved / Fulfilled' to 'Closed' failed condition macro macro:500163 - WARNING

Here are the current settings for the above mentioned macro (500163):

name = Sheetz User AT is SD or user=customer

ob_type = cr

type = cond_site

If all conditions succeed, return TRUE

description = Return true if the access type of the user performing action is Service Desk or the user is same as customer. Created to allow only SD or the user to close ticket.

In my research I found the above macro code is being used/referenced for Incident Transition ... from status Resolved/Fulfilled to Closed status.

My question or concern is how do I find out why this is continually failing and/or who is trying to close the Incident ticket? Would like to know so if this is a training issue (letting certain people know they are not to close tickets but only resolve them) I can address it. Not sure if this is a big deal as the log message is showing it as a Warning?

thanks

Katherine

Is it possible that you have some required fields for the CLOSED status that are not populated, hence the transition rule fails?

Its possible since these are Incident tickets but I won't know for sure until I am able to find some of the tickets and actually look at them.

This is why I want to know if there is a way for me to find out what the ticket numbers are for the ones causing this error and having it logged in the stdlog file. 

Didn't know if maybe I can write a query against the db using the date when the message is logged or if I can turn something on to also be written in the stdlog file along with the message?

Katherine........

We can turn tracing on, but it is advisable to enable the tracing when you know the issue will occur

Enable tracing:
pdm_logstat -f cr.spl TRACE
pdm_trace spelsrvr ON

Disable tracing:
pdm_logstat -f cr.spl
pdm_trace spelsrvr ON OFF

The traces will be written to NX_ROOT/log folder in the STDLOGs

I will go ahead and try the tracing to see if I can capture the information ... will let you know how I make out.

thank you

Katherine

The tracing commands worked great ... I was able to get specific ticket information from the log files for research.

What I found:

• This entry in the logs is just a warning message that all the macro conditions were not met
  • the access type of the user performing the status change is not one of the ones specified in the macro
• The call ticket status DOES change from resolved/fulfilled to closed
• The account performing the status change
  • an internal account (System_AHD_generated)
  • has access type = employee
  • this account has not been modified for years

I don't remember noticing this error message in the logs before upgrading to v14.1 CUM3 so I don't know if maybe something is now being enforced and logged better than before?

Since the status is actually changing, this warning message is not a major problem but I am wondering if maybe the macro conditions should be updated/changed to include the internal account from above so the warning message does not have to be written to the log file?

thanks

Katherine

Hi Katherine, 

I dont think that updating the macro condition would necessarily prevent the message from being put into the logs if the conditions ARE being met.  From what you show in your posts here it seems like the macro conditions are being met, but I think its the status transition that it thinks it fails at first, but then sees the conditions are met and goes through.  I think its actually more of a timing thing - but i cannot say for sure. . I would say that since its working at this point, you can ignore the message, BUT, if you want to investigate it further, then I would say the best bet would be to open a support ticket so we can troubleshoot it further and try to figure out specifically why that message is thrown.

Let us know where you want to go on this one.    If you are ok leaving it alone, then if you dont mind, just mark this as answered.  If you want to pursue this further, then def. open a support case and then post the case number here on this community post so that we can follow it through and post the resolution here as well

Thanks!!

Jon I.

Jon,

Thanks so much for the help. As long as the process (status change) is happening then I am good with ignoring the message in the logs.

Katherine

No problem - I think you are good to go there. Its not showing as an "error" - i think its more of a rogue or generic response to something in your code, but not anything functionally wrong.  If you ever want to look deeper into it, just open a support case and we will dig into it