Activity Notifications are not sent from Service Desk and do not update the Activity History.
Manual Notifications are correctly sent and update the Activity History.
The following error appears in STDLogs when triggering a notifications:
spelsrvr 4148 ERROR pcexec.c 6403 Spell interp failed at doc_rep.spl:720:doc_rep.servlet_path::set_servlet: Non-string arg to get_servlet_path (string)
domsrvr 7328 ERROR attr.c 6369 Error in ATTR_INIT trigger doc_rep.servlet_path::set_servlet for servlet_path: doc_rep.spl:720:doc_rep.servlet_path::set_servlet
spelsrvr 4148 ERROR doc_rep.spl 560 Error on get_attr_vals to retrieve servlet_path and server for doc_rep id (doc_rep:1000). 2
kt_daemon 6968 ERROR DomWrap.c 928 Failed to complete reply method: 'got_rep_services' ,BOP Name:'ntfm:1069' in class:'CDrefHTMLLinks', Error:
kt_daemon 6968 ERROR DomWrap.c 928 Failed to complete reply method: 'dref_html_links_done' ,BOP Name:'ntfm:1069' in class:'CHTMLAttrInit', Error:
domsrvr 7328 ERROR attr.c 6369 Error in ATTR_INIT trigger html_attr_init for notify_msg_body_html_real:
spelsrvr 4148 ERROR pcexec.c 6403 Spell interp failed at alg.spl:332:alg::post_ci_notify: get_attr on notify_msg_body_html_real failed: WOBO
Note: If Manual Notifications are not sending either, then a different issue may be in effect.
Check the stdlogs to confirm that the above errors are seen.
Service Desk Manager 14.1, 17.0, 17.1.
The "Servlet Server" for the repositories is not correct and is pointing to an old server.
Phase 1 - The Standard Solution. USE FIRST.
1. Log into Service Desk Manager > Administration > Attachment Library > Repositories
2. Right-Click on Repository > View > Check the value for "Servlet Server".
3. If the value for "Servlet Server" is not correct, click on Edit and set the right server.
Tip: It is best to take a screenshot before making changes as a precaution.
4. Go through each Repository and check the value for "Servlet Server" is correct for each one
5. Confirm the notifications are sent via Activity Notifications.
Phase 2 - Additional Information if the Standard Solution does not Work
Only continue to Phase 2, if Phase 1 has been tested thoroughly, as a "through the interface" method of correction is preferred if possible.
CAUTION: Damage to the database will occur if incorrect data correction is performed.
This has been written for a specific example of an SDM 12.6 to ITSM 17.1 upgrade where it was found that the usp_servers table had an id of "400001" instead of "1001".
Care should be taken to examine your system, as there may be multiple Repositories or different data in the error messages that require a different correction.
IMPORTANT NOTE: The client's issue stopped occurring on their system without the following change being implemented. This solution has been generated on at test box in a CA Support lab and confirmed as successful there (Hence the different doc_rep id to the error messages). However, at the time of writing this has not been applied to a live client system. Due diligence is advised.
The errors encountered in the client log were:
- - - -
- - - -
You may make changes either with "pdm_load" of corrected text files.
Or directly in the database, with SQL update commands.
The SDM virtual database can updated with by a recycle of the CA SDM Service, or with the "pdm_cache_refresh" command.
1) Take backups of the following two tables from an Administrator command prompt on the SDM server:
These can be used to restore to a current state if needed via the "pdm_load" command.
2) UPDATE the "Default Service Desk Repository" table row 1002 in the Document_Repository table values of "400001" to be "1001". There are TWO values to change.