There are two parts to the format of an Calendar Server notification:
The event reference– A URL identifying the event.
The payload– The data describing the event. Three different payload formats are supported: binary, text/calendar, and text/XML.
There are two types of calendar notifications:
Alarm Notifications– relay reminders
Calendar Update Notifications– distribute changes to the calendar database
Alarm notifications relay reminders. They are published by the csadmind daemon whenever it wants to send a reminder. The default subscriber for these alarms in Communications Suite is the csnotifyd daemon. Notifications consumed by csnotifyd have a binary payload and are acknowledged (reliable).
Additionally, the server can be configured to generate one additional notification for each reminder, which can be consumed by a third party notification infrastructure.
Table 5–1 shows the configuration variables that enable these notifications.
Table 5–1 Alarm Notifications
ics.conf |
Default Value |
Descripton |
||
---|---|---|---|---|
|
|
Used by csadmind and csnotifyd to send SMTP reminders. |
||
|
yes |
Enable or disable the default alarm (binary) transport provided by the Calendar Server product. |
||
|
NULL |
ENS topic URL for custom implementation. If this is NULL, then no formatted messages will be published. The ics.conf value will be set to enp:///ics/alarm. |
||
|
text/xml |
Content MIME type of formatted message. |
||
|
300 |
Retry interval in seconds for failed deliveries. Specify zero (0) to disable retry. |
Event URL parameters are the same for either one:
calid - Calendar ID
uid - Component, either event or todo (task) ID
rid - Recurrence ID
aid - Alarm ID
comptype - An event or a todo (task)
URI
Calendar update notifications distribute changes to the calendar database. They are published by the cshttpd or csdwpd daemons whenever a change is made to the database (if the notification is enabled for this type of change).
There are eleven types of notifications. Table 5–2 lists each type of calendar update notification, it’s ics.conf parameters, and their default values.
Table 5–2 Calendar Update Notifications
Types |
ics.conf Parameters |
Default Value |
||||||
---|---|---|---|---|---|---|---|---|
Attendee refresh actions |
|
|
||||||
Attendee reply action |
|
|
||||||
Calendar creation |
|
|
||||||
Calendar deletion |
|
|
||||||
Calendar modification |
|
|
||||||
Event creation |
|
|
||||||
Event modification |
|
|
||||||
Event deletion |
|
|
||||||
Todo (task) creation |
|
|
||||||
Todo (task) modification |
|
|
||||||
Todo (task) deletion |
|
|
Event URL parameters include:
calid - Calendar ID
uid - Component, either event or todo (task) ID
rid - Recurrence ID
Normally, ENS notifications for attendee replies and organizer refreshes are published to the caldb.berkeleydb.ensmsg.modifyevent topic along with other modifications. By setting the ics.conf parameter caldb.berkeleydb.ensmsg.advancedtopics to “yes” (the default is “no”), the ENS notifications can be published to separate modify, reply and refresh topics. This allows the consumer of the notification to understand more precisely what type of transaction triggered the notification.
Table 5–3 shows the topics ENS publishes notifications to depending on the setting of the ics.conf parmeter caldb.berkeleydb.ensmsg.advancedtopics.
Table 5–3 Advanced Topics Parameter
Value of Advanced Topics Parameter |
Topics to Which ENS Publishes Attendee Notifications |
|
---|---|---|
yes |
|
|
no |
|
When ENS sends out notifications of modifications made to existing events, it returns two X-Tokens with the notification, X-NSCP-COMPONENT-SOURCE and X-NSCP-TRIGGERED-BY.
The contents of the X-NSCP-COMPONENT-SOURCE X-Token varies depending on who originated the event and the absence or presence of the appid parameter in the original WCAP command that requested the event.
If the appid parameter is present in the original WCAP command, ENS returns its value in the X-NSCP-COMPONENT-SOURCE X-Token.(Only certain commands take the appid parameter. See the Calendar Server Programmer’s Manual for further information on the appid parameter.) Using this mechanism, applications can “tag” ENS notifications in order to detect which ones it originated. The value of the appid command is a character string of the application’s choosing. If the appid parameter is missing, standard values are assigned to the X-Token depending on the origin, see Table 5–4 that follows for the standard values).
The X-Token, X-NSCP-TRIGGERED-BY holds the name (uid) of the organizer or attendee that triggered the notification regardless of the absence or presence of the appid parameter.
Table 5–4 shows the effect of the presence of the appid parameter in WCAP commands on the value of the X-Token X-NSCP-COMPONENT-SOURCE.
Table 5–4 Presence of appid and Value of X-Token X-NSCP-COMPONENT-SOURCE
appid Present? |
Value of X-Token X-NSCP-COMPONENT-SOURCE (with Request Origin) |
---|---|
no |
WCAP (default) CALENDAR EXPRESS (from UI) ADMIN (from Admin tools) |
yes |
Value of appid |