Usage of attribute prefixes in mail notification variables
Article ID: 425494
Updated On:
Products
Issue/Introduction
The message templates that are used in Initial activity notification show that the variables all start with "call_req_id". However, in other locations, such as message templates that are used in Event notifications, the "call_req_id" prefix is not presented. This article discusses the differences between these notifications and when attribute prefixes are needed.
Environment
All releases of Service Desk
Cause
The reason for this is due to the way the objects are being referenced in the notification
Resolution
When you send out an Initial Activity notification, you need to specify the ref_num field with syntax @{call_req_id.ref_num}.
When you send out an Event based notification, you need to specify the ref_num field with syntax @{ref_num}.
When you send out an Initial Activity notification, the notification is sent from a reference point of the activity log, or alg object. The alg object will not have direct access to the call request's ref_num attribute, but it does have the call_req_id attribute available to it. In order for the activity log to present the call request's ref_num value, you need to include the call_req_id attribute, hence the syntax @{call_req_id.ref_num}.
Event based notifications do not function the same as Activity Notifications. Events are attached directly to a given call request. As a result, these notifications are being sent from a reference point of the call request, or cr object. The cr object already has the "ref_num" attribute directly defined. Specifying the "call_req_id" attribute is not necessary as the cr object has no attribute named "call_req_id". In order for the request's attached event to list the ref_num value, the syntax @{ref_num} is all that is needed.
Running the bop_sinfo command for the given objects alg and cr:
>bop_sinfo -d alg
Factory alg
Attributes:
id INTEGER
producer_id LOCAL STRING(20)
persistent_id STRING(30)
call_req_id SREL -> cr.persistent_id REQUIRED
last_mod_dt DATE
time_spent DURATION
[rest of output omitted]
We see in the above that the call_req_id exists. There is no ref_num attribute directly available from the alg object. You need to access it through the alg attribute call_req_id.
As for the cr object, running bop_sinfo reveals:
>bop_sinfo -d cr
Factory cr
Attributes:
id INTEGER
producer_id LOCAL STRING(20)
persistent_id STRING(30)
new_delay_log LOCAL STRING(0)
ref_num STRING(30) REQUIRED
summary STRING(255)
description STRING(16000)
[rest of output omitted]
The ref_num field is directly present. No other prefix is needed in this scenario. Conversely, there is no "call_req_id" attribute defined for the cr object.
Additional Information
Currently, there is no way to have a unified message template where the variables will function regardless of the type of notification. This is due to the way objects are being referenced for the notification in the backend.
A best practice to test variables out for a given message template is to include multiple variations on a given variable syntax in the same message template and send out the notification to see which values are presented. This is the simplest and fastest way to lock down variable syntax for mail message templates. Any instances with incorrect or invalid variable syntax will not work and will simply present with no value.
The following screencap shows such content introduced in the "Default initial message template for request/incident/problem Message Template"
The two variations that are being used are to test which version of the ref_num variable syntax will work:
Ref Num Test 1 (call_req_id.ref_num): @{call_req_id.ref_num}
Ref Num Test 2 (ref_num): @{ref_num}
The rest of the message body content is default content that is common across an otherwise unmodified installation.
When the notification is sent out for a new ticket creation, Incident 32 in this case, the resultant mail will appear as follows:
This demonstrates the result of sending such a notification out, showing that @{call_req_id.ref_num} is the correct syntax for Initial Activity Notification. A similar test can be done using the same notification text when sending out an Event based notification.
Feedback
