C H A P T E R  20

Notification Configuration

Sun Java System Content Delivery Server provides notifications to content developers about content they submitted and to subscribers about updates and promotions. You can determine the types of notifications sent to content developers and the opt-in default for subscribers.

This chapter includes the following topics:


20.1 Configuring Developer Notifications

Developers submit content to Content Delivery Server through the Developer Portal. You can set up Content Delivery Server to send email notifications to developers whenever action is taken on the content that they submitted.

To set up notifications, follow these steps:

1. Make sure that the default.external.developerportal.uri property in the $CDS_HOME/deployment/deployment-name/conf/CDS.properties file points to the location of the Developer Portal.

Use the format http://hostname:port/developer/, where hostname:port is the host name and port number of the host on which the Developer Portal is running.

2. Set the following properties in the $CDS_HOME/deployment/deployment-name/conf/EventService.properties file.

3. (Optional) Customize the notifications that are sent.

You can customize notifications by editing the default templates provided with Content Delivery Server or by creating your own XSL files.

CODE EXAMPLE 20-1 provides the definition of the notification templates that you can follow. If you create your own files, you must update the properties described in the previous step that identify the location of the files.


CODE EXAMPLE 20-1 Definition of Notification Templates
/*
 * Definition of XML documents that are piped to the
 * XSL transformation sheets.
 *
 * <dn>
 *  <developer>Joe Developer</developer>
 *
 *  <submission> <!-- when content was submitted (even if failed) -->
 *    <succeeded> <!-- may be zero or more -->
 *      <name>Name used to submit</name>
 *      <id>ID used to submit</id>
 *      <url>URL this content is viewable at</url>
 *    </succeeded>
 *    <failed> <!-- may be zero or more -->
 *      <name>Name used to submit</name>
 *      <id>ID used to submit</id>
 *      <errormsg>Error message</errormsg>
 *      <errorlog>Lengthy error info</errorlog>
 *    </failed>
 *  <submission>
 *
 *  <statuschanged>
 *
 *    <!-- The possible status values are:
 *
 *    pending
 *    denied
 *    published
 *    unpublished
 *    deleted
 *    new
 *
 *    -->
 *
 *    <newstatus>status</newstatus>
 *
 *    <name>Name used to submit</name>
 *    <id>content id</id>
 *    <url>URL where this content is accessible</url>
 *    <message>Message left for developer</message>
 *  </statuschanged>>
 *
 *  <propertychanged>
 *    <name>Name used to submit</name>
 *    <id>content id</id>
 *    <url>URL where this content is accessible</url>
 *    <textproperty> <!-- zero or more of those -->
 *      <name>property name</name>
 *      <oldvalue>old property value</oldvalue>
 *      <newvalue>new property value</newvalue>
 *    </textproperty>
 *
 *    <!-- binary property is special, since it doesn't have a
 *         displayable value, so only name is mentioned.
 *    -->
 *    <binaryproperty>property name</binaryproperty> <!-- zero or
 *           more -->
 *    <priceproperty> <!-- zero or one of this, only for suggested
 *           price -->
 *      <!-- note the pricedata tag. It is used to unify the
 *           structure to make XSLT transformation easier.
 *      -->
 *      <oldvalue><pricedata>
 *        <billing1>
 *          <!-- the following is $13.27, but helps localization
 *               if broken in such a way. There is also a "number"
 *               tag which gives the price in cents (coins)
 *           -->
 *          <price>
 *            <number>1327</number>
 *            <bills>13</bills>
 *            <coins>27</coins>
 *          </price>
 *          <usage_count>usage_count</usage_count>
 *         <usage_period_days>usage_period_days</usage_period_days>
 *          <recurring>recurring</recurring>
 *        </billing1>
 *        <billing2>
 *          <price><bills>13</bills><coins>27</coins></price>
 *          <frequency>frequency</frequency>
 *          <recurring>recurring</recurring>
 *        </billing2>
 *        <billing3>
 *          <price><bills>13</bills><coins>27</coins></price>
 *          <usage_count>usage_count</usage_count>
 *        </billing3>
 *      </pricedata></oldvalue>
 *      <newvalue><!-- the same as for oldvalue --> </newvalue>
 *    </priceproperty>
 *
 *  </propertychanged>
 *
 *  <adminemail>Email address developer can inquire at</adminemail>
 * </dn>
 */


20.2 Configuring the Default for Subscriber Notifications

Content Delivery Server sends notifications to subscribers about updates or promotions. Subscribers can choose to receive these notifications by setting the option when they set their preferences for their account. You can set the default to either opt-in or opt-out. The initial default is opt-in.

To change the default option, set the user.profile.optin property in the $CDS_HOME/deployment/deployment-name/conf/security.config file. Set this property to true to set the default to opt-in. Set this property to false to set the default to opt-out.