Alarm Notifications

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.

Calendar Update Notifications

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

caldb.berkeleydb.ensmsg.refreshevent

caldb.berkeleydb.ensmsg.refreshevent.
url

caldb.berkeleydb.ensmsg.refreshevent.
contenttype

no

enp:///ics/caleventrefresh

text/xml

Attendee reply action

caldb.berkeleydb.ensmsg.replyevent

caldb.berkeleydb.ensmsg.replyevent.
url

caldb.berkeleydb.ensmsg.replyevent.
contenttype

no

enp:///ics/caleventreply

text/xml

Calendar creation

caldb.berkeleydb.ensmsg.createcal

caldb.berkeleydb.ensmsg.createcal.
url

yes

enp:///ics/calendarcreate

Calendar deletion

caldb.berkeleydb.ensmsg.deletecal

caldb.berkeleydb.ensmsg.deletecal.
url

yes

enp:///ics/calendardelete

Calendar modification

caldb.berkeleydb.ensmsg.modifycal

caldb.berkeleydb.ensmsg.modifycal.
url

yes

enp:///ics/calendarmodify

Event creation

caldb.berkeleydb.ensmsg.
createevent

caldb.berkeleydb.ensmsg.
createevent.url

yes

enp:///ics/caleventcreate

Event modification

caldb.berkeleydb.ensmsg.
modifyevent

caldb.berkeleydb.ensmsg.
modifyevent.url

yes

enp:///ics/caleventmodify

Event deletion

caldb.berkeleydb.ensmsg.
deleteevent

caldb.berkeleydb.ensmsg.
deleteevent.url

yes

enp:///ics/caleventdelete

Todo (task) creation

caldb.berkeleydb.ensmsg.
createtodo

caldb.berkeleydb.ensmsg.
createtodo.url

yes

enp:///ics/caltodocreate

Todo (task) modification

caldb.berkeleydb.ensmsg.
modifytodo

caldb.berkeleydb.ensmsg.
modifytodo.url

yes

enp:///ics/caltodomodify

Todo (task) deletion

caldb.berkeleydb.ensmsg.
deletetodo

caldb.berkeleydb.ensmsg.
deletetodo.url

yes

enp:///ics/caltododelete

Event URL parameters include:

calid - Calendar ID

uid - Component, either event or todo (task) ID

rid - Recurrence ID

Advanced Topics

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.

WCAP appid parameter and X-Tokens

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

ENS Sample Code for Calendar Server

Calendar Server ships with a complete ENS implementation. If you wish
to customize it, you may use the ENS APIs to do so. The following four code
samples, a simple publisher and subscriber pair, and a reliable publisher
and subscriber pair, illustrate how to use the ENS API. The sample code is
provided with the product in the following directory: