CA Service Management

Hi everyone... We have one contact record that is giving this error when trying to send a manual notify email from a ticket.  The contact record does have a valid email address in the 'email address' field. 

I have changed that email address to my own and tested, and am getting the same error.  I am getting this error only on this one contact record, but am getting the error in both our test and production systems.  I have re-created a new contact record from scratch, tested, and am still getting the same error.  If I select his contact record in the 'contacts' field of the manual notify screen, I also get the same error.  But if I put his email address in the 'Email address' field of the manual notify screen, it sends the email successfully.  If I change the customer to another person's contact record and try sending a manual notify to that customer, it works just fine.

Does anyone have any ideas what might be causing this, or how to fix it?

Thanks.

Tammy

Tammy..........

Please verify via the ca_contact and usp_contact table that the user does not have a duplicate contact record with the same first, middle and last name.

Hi Paul... How've you been?

So yes... There are 2 contact records with the same first, middle, and last name -- but they are 2 different people with different userids.  (Our contact load process looks looks for a match on userid rather than name. because there's often times where there will be more than one person with the same exact name.)

The other contact record did not have an email address (he doesn't have an email account), so I put my own email address in it, tested again, and didn't get the error this time --- and I was expecting the manual notify email to be sent to me instead, because I thought you were trying to tell me that the manual notify functionality grabs the first contact record it finds with a matching name and sends it to that email address.  But, I didn't get the email... So does that mean it went to the right address now?  I'm not really sure I understand why though...

Thanks,

Tammy

Hi Tammy,

You could run a trace on the bpnotify_nxd process. This could show what's happening behind the scenes as to which contact it is using. Alternatively, enable the 'write_to_file' setting on the Notification Method in question and interrogate the file to see which contact is it trying to notify.

===

Kind Regards,

Brian

Tammy,  I think you may need to open a Support case for this problem. Or, if you what to play some fun, take a look at

nf.htmpl file and may see why(I am not saying should). Thanks _Chi

Thanks, Brian and Chi... I don't think confirming where the email went is really the issue.  I didn't get it on that last test, so that tells me it probably went to the right place that time.  But the bigger question and concern to me is how to deal with the fact that the manual notify functionality seems to only look at the contact name to find the correct email address to send to.  Our contacts are loaded/synchronized from AD, and AD is loaded/synchronized from our HR PeopleSoft system, which must use their legal name so I can't just change someone's name in the originating source to be something unique. 

I glanced through the nf.htmpl file, Chi, and I'm sure there's something in there that explains what it's doing, but I'm not a programmer so I don't know what most of that code is really doing... 

Tammy

Tammy..........

As Brian indicated, we would most likely need to enable tracing on the notification process and then have our Engineering team analyze.

We can also ask at the same time from Engineering how the manual notification process is supposed to work in the specific scenario you are facing.

When you have time, please open a CA Support ticket so that we can further assist with you.

When opening the ticket, please ensure to provide the exact use case details along with your SDM .HIS file.

Also, please post the CA Support ticket # to this post so we can track progress.

Out of curiosity I looked over the nf.htmpl form.. It's performing a search on the combo name of the user added to the TO or CC fields(isEmailIDExist function), and if any of the users returned don't have an email it'll return an error.  Seems like it should be using userid instead of combo_name..

Great find Grant. ;-)

Sounds like we definitely need a case to get all the right answers and way to see if we can change the logic to use userid instead of combo_name.

===

Kind Regards,

Brian

I agreed that a Support case would need to get to the bottom of this.

when one/some of the recipients does not have an email address, the error will occur, which is the right designed behavior as SDM needs an email address to send the notification to that recipient. in an env that has multiple same

combo name, the user would need to choose the right recipient as the list_cnt.htmpl that pops up DOES have userid

there. It does not include the email address field so maybe you can customize the detail_cnt.htmpl page to add email address so the user knows who has email address and who does not. again, having that message is not a problem itself

(in fact, it is helpful as the user knows he has selected some recipient who does not have email address).

I'm submitting a support case right now..... In our use case, they are selecting the 'Affected End User' of the ticket from the list of Available Recipients at the top left of the manual notify screen, so it's already been confirmed that this contact record does have an email address (we display the affected end user's telephone number and email address right on the ticket screen).  And when using the link above the 'Contacts' field on the manual notify screen to search for a contact, we are also able to see if the contact we are selecting has an email address -- but there's no visibility when you're selecting from the auto-suggest list.  The auto-suggest list wasn't being used in this case, but I can see how that would cause problems. 

So are you all suggesting that the 'Available Recipients' functionality be changed to look at that contact record's userid to know what contact to send to -- and the 'Contact' field functionality ould be changed to have you look up the contact by userid rather than by the combo_name?

Thanks.

Tammy

Support Case #00868832.

Thanks,

Tammy

Hey Tammy,

Does this look like a match to your use case?  This was fixed in the newer cumulatives from what I see...

PRODUCT: Unicenter Service Desk RELEASE: 14.1
PROB #: 3378 
STARTRAK PRODUCT NAME: USRD (Star Problem Product)
PROBLEM SYMPTOM: WIN-INCORRECT ERROR FOR MISSING EMAIL
----------------------------------------------------
In a case where multiple users share the same
full name (first, last and middle name), if at
least one of these users does not have an email
address set, a message similar to the one below
may be logged to the web interface:

"Email id does not exist for the user(s):[***]"

Steps to reproduce:

1. Create at least two users with the same Last
Name and First Name.
2. Set the email address for only one of them and
leave the email address as empty for the other
one.
3. Open an existing ticket and select one of the
two new users.
4. Click on the 'Notify' button.

Result:

A message similar to the one below will be
logged in the web interface:

"Email id does not exist for the user(s):[***]"

The expected result is that if the user with the
email address field filled in was selected, then
the notification should be sent.

Hi Raghu,

Yes, that matches the problem # on the patch I just got... 

Thanks.

Tammy

Good morning Tammy - did that patch fix the issue for you?

Hi Jon,

I don't know yet --- I just got the patch last night as I was trying to walk out the door.  Will try to apply it to the test environment sometime this week (hopefully today), and will keep everyone updated.

Thanks,

Tammy

Sure let us know - i am interested in hearing the outcome on this one

I applied the patch in our test environment and tested, but unfortunately it didn't resolve the issue.  I've udpated the support case with the results.

Thanks.

Tammy

Hi Tammy - I was going to suggest to open a support case for this one.  I didnt you know that you already did.  Would you mind posting the case number here for us so we can track it?

Thanks,

Jon I

Got a patch for it already!   #T5ET639 ---- Yay!

Will try to apply this to our test environment tomorrow and will let you know the results...

Thanks,

Tammy

Thanks Tammy,

I was going to say the next thing is that I would suggest to open a support case, but you already did!   Would you mind posting the support case number here so we can track it?

Thanks!

Jon I.

Hi Jon,

I posted that yesterday --- here it is:  Support Case #00868832.

Thanks!

Thanks Tammy,

I am going to mark the post about the support case as correct - and then when Scott has resolved the case for you, he will post the resolution here as well so that we close the loop on it

Thanks and sorry for any confusion here!

Jon

That's fine, Jon --- thanks!

Tammy Zadell

Technical Team Manager, Parker Service Desk

Parker Hannifin Corporation

Corporate Information Technology Infrastructure Department

216-896-2118 (Office)  216-408-6094 (Cell)

Service Desk:  216-896-4357

tzadell@parker.com

www.parker.com

Ok, so now I feel quite stupid... When Chi suggested I look at the nf.htmpl file the other day, I did -- and noted that it wasn't a modified form.  But I was looking in the production environment at that time, and it seems there was a modified nf.htmpl form in our test environment from something I had tried to change back in 2016 -- I had backed out of the change on production due to intermittent errors it gave, but as much as I painstakingly try to keep test and prod the same, I obviously forgot to back out of the change on the test system.  Removed that file, and now the results are that this patch did fix the issue.  Yay!

Thanks.

Tammy

That is great news Tammy!

This was addressed by applying T5ET639.

Thanks @johsc03 !

Yep, that is the patch number I noted above that I was given.  It did resolve the issue.

Thanks.

Tammy