Deployment Configuration

C H A P T E R 1

After deploying Sun Java System Content Delivery Server, some configuration is needed to set up the deployment to work within your existing infrastructure. The configuration needed is dependent on the features that you want to use.

This chapter includes the following topics:

Configuring the Monitoring Service

Configuring the Event Service

Configuring Synchronization

Configuring Marketing Campaigns

Setting Up Custom Reports

Configuring Externally Hosted Content

Setting Up Automatic Publishing

Setting Up Custom Fields

Defining Popularity

Enabling Cleanup of Expired Items

Configuring Device Client Web Services

Configuring the Fulfillment Service

1.1 Configuring the Monitoring Service

To integrate the Application Monitoring Agent with your network monitoring system, you need to configure the Monitoring Service. Configure the Monitoring Service to issue only the alarms in which you are interested and disable all other alarms. The statuses and alarms issued by the Monitoring Agent are described in Section 1.1, “Application Monitoring Agent,” in the Sun Java System Content Delivery Server System Management Guide.

To configure the Monitoring Service, edit the CDSSnmp.properties file in the $CDS_HOME/deployment/deployment-name/conf directory. The following table describes the properties.

TABLE 1-1 Monitoring Service Properties
Property	Description
`snmp.trap.disabled`	Indicates if all traps are disabled. Set to `true` to disable all traps and ignore the `snmp.trap.`alarm`.enabled` properties for the individual traps. Set to `false` to honor the settings for individual traps.
`snmp.trap.v1`	Indicates if Simple Network Management Protocol (SNMP) v1 or SNMP v2 traps are generated. Set this property to `true` to generate SNMP v1 traps. Set to `false` to generate SNMP v2 traps.
`snmp.agent.port`	The port number for the host on which the Monitoring Service is running.
`snmp.manager.address`	The IP address of the host on which the network management system is running.
`snmp.manager.port`	The port number for the host on which the network management system is running.
`snmp.oid.base`	The absolute object identifier (OID) value from the root node. Other Content Delivery Server OIDs are specified as a relative value from this base value. Note - Do not change this value.
Scalar Object Definitions status is the name of the component for which status is provided, for example, `eventServiceStatus`. See Section 1.1, “Application Monitoring Agent,” in the Sun Java System Content Delivery Server System Management Guide for the valid statuses.
`snmp.object.`status`.oid`	The MIB identifier for this object. Note - Do not change this value.
`snmp.object.`status`.handler`	The handler for this object. Note - Do not change this value.
`snmp.object.`status`.attr.pidfile`	The name and location of the file that contains the process ID for this object. Note - Do not change this value.
`snmp.object.`status`.attr.uri`	The path to the main servlet that this object monitors. Note - Do not change this value.
Trap Definitions alarm is the name of the alarm that is issued, for example, `downloadFailure`. See Section 1.1, “Application Monitoring Agent,” in the Sun Java System Content Delivery Server System Management Guide for the valid alarms.
`snmp.trap.`alarm`.oid`	The MIB identifier for this object. Note - Do not change this value.
`snmp.trap.`alarm`.enabled`	Indicates if the alarm is issued. Set to `true` to permit the alarm to be issued. Set to `false` to prevent the alarm from being issued. The default is `true`. If `snmp.trap.disabled` is `true`, this setting is ignored.

1.2 Configuring the Event Service

The Event Service generates events based on the properties set in the $CDS_HOME/deployment/deployment-name/conf/EventService.properties file. If the consumer of the event is not running, the Java Message Service (JMS) maintains the events until the consumer of the event is started. Over time, messages might accumulate and result in an out-of-memory error.

The campaign event handler produces events that are consumed by the Notify Service. The billable event handler publishes messages to a topic for the Postpaid Service, which creates a durable topic listener client the first time it runs. The developer update event handler, developer submit event handler, and the OMA DRM 1.0 rights delivery event handler publish messages to a queue that is consumed by the Messaging Service.

If you do not plan to run the Notify Service, Postpaid Service, or the Messaging Service as part of your Content Delivery Server system, you can avoid the accumulation of messages by configuring the Event Service so the messages are not generated. To stop the generation of messages by a handler, edit the EventService.properties file and comment out the handler by adding a pound sign (#) to the beginning of the line for the property that defines the handler:

When the Notify Service is not running, stop the generation of campaign notifications by commenting out the following statement as shown:

#eventservice.handler=Campaign

When the Postpaid Service is not running, stop the generation of billable events by commenting out the following statement as shown:

#eventservice.handler=Billing

When the Messaging Service is not running, stop the generation of messages by commenting out the following statements as shown:

#eventservice.handler=DeveloperUpdate 
#eventservice.handler=DeveloperSubmit 
#eventservice.handler=OMARightsDelivery

1.3 Configuring Synchronization

The Catalog Manager and each Vending Manager has its own database. Information such as the status of content or the types of devices supported must be maintained across databases. Synchronization of the databases is managed by Content Delivery Server. When the Vending Manager receives a notification of change from the Catalog Manager, the Vending Manager attempts to synchronize with the Catalog Manager. If synchronization fails, the Vending Manager retries the operation.

To manage the number of times and how often the operation is attempted, set the following properties in the $CDS_HOME/deployment/deployment-name/conf/RemoteVending.properties file for the Vending Manager deployment:

vending.messaging.retries.no - Number of times that the Vending Manager attempts to synchronize with the Catalog Manager if synchronization fails. After retrying for the number of times specified, the Vending Manager waits for the time interval specified for the vending.messaging.processor.restart.interval property before attempting another synchronization.

vending.messaging.processor.restart.interval - Number of milliseconds the Vending Manager waits before trying again to synchronize with the Catalog Manager.

Note - A high number of retries or a short interval between each series of retries can slow response to subscriber requests and rapidly increase the size of log files.

Additional information about the synchronization between the Catalog Manager and Vending Managers is available in the “Catalog and Vending Managers” chapter of the Sun Java System Content Delivery Server Reference Manual.

1.4 Configuring Marketing Campaigns

Content Delivery Server provides a feature that enables you to send advertisements to selected subscribers. Messages can be sent using Short Message Service (SMS), Wireless Application protocol (WAP), Multimedia Messaging Service (MMS), or Simple Mail Transfer Protocol (SMTP).

Campaigns sent as email use the SMTP mail service defined for the Messaging Service. To change the mail service, see Section 10.1, Configure the Mail Service.

You can include a link to promotional items in the message. The address to which the link points is based on the value specified for the sp.external.uri property in your deployment configuration file.

If the value in the configuration file is not correct, edit the CDS.properties file found in the $CDS_HOME/deployment/deployment-name/conf directory and set the value for the default.external.subscriberportal.uri property to the correct address. If Content Delivery Server is running behind a firewall, specify an address that subscribers can access from outside the firewall.

1.5 Setting Up Custom Reports

The Vending Manager provides daily statistical reports that enable you to view and track application download information and usage statistics. To generate custom reports, you can configure Content Delivery Server to store transaction data in the REPORT_DOWNLOAD table in the Vending Manager database.

Note - To store transactions in the reports database, you must deploy and run the Postpaid Service.

1.5.1 Enabling Custom Reports

To configure support for customized reports, follow these steps:

1. Edit the PostpaidService.properties file found in the $CDS_HOME/deployment/deployment-name/conf directory.

To enable the reporting handler, remove the pound sign (#) from the postpaid.handler=ReportingHandler statement.

Also, set the following properties:

postpaid.handler.ReportingHandler.events. Specify one or more billing events for the reporting handler to process. The following events are valid:

content_purchased

content_refunded

download_error

download_initiated

subscription_cancelled

subscription_purchased

usage_purchased

To specify more than one event, separate the events with a vertical bar (|).

postpaid.handler.ReportingHandler.billingevent.process_free_downloads. Set to true to process events for free content. Set to false if you do not want to process events for free content.

postpaid.handler.ReportingHandler.billingevent.process_prepay_events. Set to true to process events for prepaid content. Set to false if you do not want to process events for prepaid content.

postpaid.handler.ReportingHandler.billingevent.identify_recurring_download_purchases. Set to true to identify billing events for the per download billing model as Recurring. Set to false to identify the events as Purchased.

postpaid.handler.ReportingHandler.recovery.starting.transaction. Set to the time stamp that identifies the first transaction that you want to recover. The format of the time stamp is MM-dd-yyyy HH:mm:ss, which is defined in the SimpleDateFormat class. Past records are recovered when the REPORT_DOWNLOAD table is empty. The table is filled with data from the transaction that you specify to the most recent transaction.

2. Edit the ReportService.properties file found in the $CDS_HOME/deployment/deployment-name/conf directory.

Set the following properties:

reportdb.username. The user name used to access the reports database. This is prefix_vs_app, where prefix is the value specified for the Prefix element under the Vending element in the database configuration file used to create the database. See the Sun Java System Content Delivery Server Installation Guide for information on this file.

reportdb.password. The password used to access the reports database. This is the value specified for the Password element under the Vending element in the database configuration file.

reportdb.server.url. The connection URL for the database. This value is specified as jdbc:oracle:thin:@dbhost.domain.com:1521:sid. Set dbhost.domain.com and sid as needed for your database server.

1.5.2 Data Stored for Reports

If you have enabled custom reports, the Postpaid Service stores a record of each purchase and refund transaction in the REPORT_DOWNLOAD table in the Vending Manager database. The information stored for each transaction is current at the time the transaction occurs. Information for stored transactions is changed only if a transaction recovery operation is performed and historical information is not available. For example, if a subscriber changes the device used, new transactions for that subscriber show the new device. Transactions that occurred with the old device continue to show the old device in the MODEL field, unless a recovery operation is performed. Recovered transactions show the new device.

The following table describes the data that is currently stored for each transaction. This table could change in future releases.

TABLE 1-2 Report Data
Name	Format	Description
`REPORT_DOWNLOAD_ID`	Number	Unique identifier for the transaction
`TRANSACTION_DATE`	Date	Time stamp of when the transaction occurred
`RESOURCE_INSTANCE_ID`	Number	Identifier for the edition of the content item involved in the transaction
`RESOURCE_CLASS_ID`	Number	Identifier for the content item involved in the transaction
`CONTENT_NAME`	String	Name of the content involved in the transaction
`CONTENT_DESCRIPTION`	String	Description of the content
`CONTENT_TYPE`	String	Type of content, for example, MIDlet
`CONTENT_PROVIDER_KEY`	String	Identifier that the content provider gave the content
`CONTENT_PROVIDER_ID`	Number	Identifier for the content provider
`CONTENT_PROVIDER`	String	Name of the content provider
`CONTENT_COST`	Float	Price assigned by the content provider
`PRICE`	Float	Price accepted by the subscriber
`FULFILLMENT_REQUEST_ID`	Number	Identifier for the fulfillment request
`FULFILLMENT_STATUS`	String	Status of the transaction, which is one of the following values: `Cancelled` `Error` `Initiated` `Purchased` `Recurring` `Refunded` `Requested` `Trial`
`BILLING_MODEL`	String	Billing model for the content
`SUBSCRIBER_ID`	Number	Identifier for the subscriber
`MSISDN`	String	MSISDN associated with the subscriber
`FIRST_NAME`	String	First name of the subscriber
`LAST_NAME`	String	Last name of the subscriber
`MODEL`	String	Name of the subscriber’s device

1.6 Configuring Externally Hosted Content

If you support content that is hosted externally, the Event Service must have access to the Developer Portal. The value specified for the dp.internal.uri property in your deployment configuration file is used for this access. If this property is not set correctly, updates to externally hosted content are not fetched.

If the value in the configuration file is not correct, follow these steps to set the Developer Portal URL:

1. Edit the CDS.properties file found in the $CDS_HOME/deployment/deployment-name/conf directory.

2. Set the value of the default.internal.developerportal.uri property to the internal address for the Developer Portal.

1.7 Setting Up Automatic Publishing

Typically, the Catalog Manager administrator reviews all content that is submitted and determines which items to publish. If desired, you can configure Content Delivery Server to automatically publish content and bypass the review by the administrator. The following options are available:

Automatically publish all content.

For this option, set the submission.content.auto_publish property to true in the $CDS_HOME/deployment/deployment-name/conf/DeveloperPortal.properties file.

Automatically publish content hosted externally when Content Delivery Server detects an update.

For this option, set the external.content.auto_publish property to true in the $CDS_HOME/deployment/deployment-name/conf/DeveloperPortal.properties file.

Automatically publish content as indicated by the rules set in the $CDS_HOME/deployment/deployment-name/conf/AutoPublishRules.properties file.

For this option, define the rules for automatic publishing and create a submission verifier workflow that uses the Autopublish Content Validation Adapter. See the instructions in the AutoPublishRules.properties file for information on setting up the rules. See Chapter 14 for information on content validation adapters.

The following algorithm is used to determine whether submitted content is automatically published:

1. If the submission verifier workflow indicates that the content is to be published automatically, then submission.content.auto_publish and external.content.auto_publish properties are ignored and the content is automatically published.

2. If submission.content.auto_publish is true, then external.content.auto_publish is ignored and the content is automatically published.

3. If external.content.auto_publish is true, then the content is automatically published if the content is external content and the external content update was automatically detected by Content Delivery Server.

4. If external.content.auto_publish is true and the content is not external content, then the content is not automatically published.

5. Otherwise, the content is not automatically published.

1.8 Setting Up Custom Fields

Content Delivery Server provides a standard set of fields that provide information about each item of content, such as Name, Version, and Short Description. In addition to the standard fields, you can configure Content Delivery Server to manage custom fields.

Custom fields provide additional information about content that you require for your enterprise. Custom fields can also be used to support additional functionality. For example, Content Delivery Server uses custom fields to support the concept of featured content. See Chapter 17 for information on this feature.

You can define custom fields to apply to all content types or specify different fields for different content types. For example, you might want to create a field called Rating for the content type midlet to specify the rating of a game.

Note - Do not make any changes to the system reserved fields that are predefined by Content Delivery Server.

1.8.1 Defining Your Fields

To define a custom field, edit the $CDS_HOME/deployment/deployment-name/conf/CustomField.properties file and create the set of properties that are described in TABLE 1-3. For each property, content-type is the content type to which the field is associated, and custom-key is the string used to identify the custom field to which the property applies.

The content type specified must be a content type that is defined to Content Delivery Server. To associate the field with all content types, use all.

The custom key is an alphanumeric string that can also contain dash (-) or underscore (_) characters. A custom key can be used for more than one field only if the content type is different. If a key is used with the content type all, it must not be used with another content type.

TABLE 1-3 Properties for Custom Fields
Property	Description	Values
`emf.`content-type`.`custom-key`.scope`	Identifies whether the field applies to the content item or to the editions of the item. This property is required.	`item`, `edition`
`emf.`content-type`.`custom-key`.required`	Indicates if the field must have a non-null value. This property is required.	`true`, `false`
`emf.`content-type`.`custom-key`.datatype`	Specifies the data type that the field accepts. For `timestamp`, the valid format is `yyyy-MM-dd’T’HH:mm:ss.SSSZ`. This property is required.	`number`, `text`, `timestamp`, `boolean`
`emf.`content-type`.`custom-key`.editable`	Identifies the portals in which the field can be edited. Separate multiple values with a comma. If this property is omitted or no value is provided, the field is not editable in any portal. Note - If the `required` property is set to `true`, the value for the `editable` property must contain `dp`.	`dp`, `vm`, `cm`, empty string (““)^[1]
`emf.`content-type`.`custom-key`.viewable`	Identifies the portals in which the field can be viewed. If this property is omitted or no value is provided, the field is not viewable in any portal. Note - If a field is editable in a portal, it must also be set as viewable in that portal.	`dp`, `vm`, `cm`, `sp`, empty string (““)`*`
`emf.`content-type`.`custom-key`.datasource`	Identifies the database in which this field is stored. For the Catalog Manager database, specify `cs`. For the Vending Manager database, specify `vs`. To specify both databases, separate the values with a comma. This property is required. Note - If the required property is set to true, the value must be `cs,vs` to store the value in both databases.	`cs`, `vs`
`emf.`content-type`.`custom-key`.weightage`	Indicates the order in which custom fields are shown. Fields are shown in ascending order based on the value assigned to this property. Values do not need to be consecutive. If two fields are given the same value, they are shown in random order within their position in the list. Fields that are not assigned a weightage are shown in random order before the fields that are assigned a weightage.	any integer

Note - If the definition of any custom field is invalid, an error message is shown when a user attempts to access content. The definition must be corrected to make content accessible.

To include custom fields in searches for content, the fields must be included in the search index. See Section 11.2.2, Adding Custom Fields to the Search Index for instructions.

If you have remote Vending Managers, define custom fields for the Catalog Manager, then copy the CustomField.properties file to the Vending Managers. You can modify the properties of the custom fields for the Vending Managers, if desired, or define additional fields. Do not delete a field. If you do not want to show a field to the Vending Manager administrator or subscribers, remove the portal from the viewable and editable properties in the field definition. To hide a field from all portals, set the property to the empty string (““).

You do not need to restart the server after you make changes to CustomField.properties. If you change the properties after content has been submitted, existing content uses the new definitions, however, the changes could have the following consequences:

Existing data in a custom field might become unavailable if the datatype property changes for a particular custom key.

Custom fields that are added are empty. If a new field is declared required, errors might occur when processing existing content that does not have data for that field.

Data in custom fields that are deleted becomes unavailable.

Content Delivery Server has no migration capability for custom fields. If data migration is required after you make changes to the custom field definitions, you must provide the process.

1.8.2 Assigning Labels and Hints

Labels and hints for custom fields are defined in a separate file for localization purposes. Labels identify the field and are shown in the user interface. Hints provide information about the field and are shown when a user hovers over the field with the mouse pointer. These strings must be set for each portal in the following property files, which are located in the $CDS_HOME/deployment/deployment-name/localization directory:

AdminConsoleMessages.properties

DevPortalMessages.properties

VendingManagerMessages.properties

SubscriberPortalLocaleResources.properties

The file names for localized versions of these files include the language code and possibly the country code. In the files for each portal and each supported language in which the field appears, set the following properties for each field that you defined in the CustomField.properties file:

emf.content-type.custom-key.label. Set this property to the string that is shown as the label for the field.

emf.content-type.custom-key.hint. Set this property to the string that provides information on the data to enter in the field. If this property does not exist for a field, a default hint based on the data type is used.

content-type is the content type to which the field is associated and custom-key is the string used to identify the field to which the attribute applies. The content type and custom key combination must match a field definition in the CustomField.properties file.

Tip - A default hint is provided for each data type. If you do not provide a hint for a field, the default hint for the data type associated with the field is used.

1.9 Defining Popularity

Knowing how popular an item of content is can be useful information. Content Delivery Server provides a function for calculating popularity based on the number of times content is accessed over time. If the default definition of popularity is not suitable for your needs, you can customize it. The change can be as simple as limiting the events that are included in the count of times accessed or as advanced as writing your own algorithm for calculating popularity.

The field that contains the popularity rating is available only for stocked content and is automatically updated by Content Delivery Server according to the schedule you set. This field can be shown in the Vending Manager administration console or in the Subscriber Portal by including it in the default search results or in a search query. See Section 11.1, Configuring Default Result Fields for information on setting up the default search results.

Popularity ratings are specific to a Vending Manager. If multiple Vending Managers that do not share a database stock the same item of content, the popularity rating for that item is calculated independently by each Vending Manager.

1.9.1 Default Definition

By default, Content Delivery Server rates the popularity of content by dividing the number of system-generated events that are counted towards popularity by the time that has passed since the first event occurred. The result of this calculation is a floating point value. The following events are counted to determine popularity:

content_purchased

subscription_purchased

usage_purchased

gift_download_initiated

gift_purchased

gift_subscription_purchased

gift_usage_purchased

Each time one of the events in the list is processed, the event count is increased by one. By default, events for free content are also counted.

Content Delivery Server uses custom fields that are defined in the $CDS_HOME/deployment/deployment-name/conf/CustomField.properties file for storing information related to popularity. Do not change field definitions for the fields with the following prefixes:

emf.all.first_access_time - Stores the timestamp of the first time the content is accessed.

emf.all.popularity_hits - Stores the number of events counted towards popularity for the content.

emf.all.popularity - Stores the popularity rating for the content. This field is used to display the rating and is used to search or sort content by popularity.

1.9.2 Customizing the Popularity Definition

If the default definition of popularity does not meet your needs, you can create your own definition. You can continue to use the default algorithm and change only the events that are counted, or you can write your own algorithm.

The following properties in the $CDS_HOME/deployment/deployment-name/conf/EventService.properties file control which events are counted and whether free content is counted by the default algorithm:

eventservice.handler.Popularity.events. Remove system-generated events that you do not want included in the popularity count and that cannot be excluded using one of the other properties. Do not add events to this property.

eventservice.handler.Popularity.count_download. Set to true to include the download_initiated event in the popularity count. Set to false if you do not want the event included in the count.

eventservice.handler.Popularity.count_purchase. Set to true to include the content_purchased, subscription_purchased, and usage_purchased events in the popularity count. Set to false if you do not want these events included in the count.

eventservice.handler.Popularity.count_gift. Set to true to include the gift_download_initiated, gift_purchased, gift_subscription_purchased, and gift_usage_purchased events in the popularity count. Set to false if you do not want these events included in the count. If set to true, gift_download_initiated events are counted only if eventservice.handler.Popularity.count_download is also set to true.

eventservice.handler.Popularity.count_free_content. Set to true to include the events for free content in the popularity count. Set to false if you do not want free content included in the count. If set to true, at least one other property must also be set to true for free content to be counted.

The default algorithm used by Content Delivery Server to set the popularity rating is defined in the com.sun.content.server.vending.PopularityImpl class. To define your own algorithm, implement the com.sun.content.server.content.Popularity interface that is part of the cdsapi.jar file. See the output of the Javadoc trademark tool in the $CDS_HOME/javadoc/cdsapi directory for information on this interface.

When your implementation is ready, set the vsadmin.popularity.impl property in the $CDS_HOME/deployment/deployment-name/conf/VSAdminConsole.properties file to the fully qualified class name. Put the file that contains your algorithm in the $CDS_HOME/deployment/deployment-name/lib/external directory for Content Delivery Server to access.

If you want to change the way events are counted, for example, to add different weights to the events, you can write your own popularity handler to handle the events and set the count that is stored in the custom field popularity_hits. If you do write your own handler, set the eventservice.handler.Popularity.classname property in the $CDS_HOME/deployment/deployment-name/conf/EventService.properties file to the fully qualified class name.

1.9.3 Scheduling the Recalculation of Popularity

Recalculating the popularity of all content in a Vending Manager can decrease performance while the process runs. Instead of recalculating every time a relevant event is processed, configure Content Delivery Server to recalculate on a set schedule.

To set up the schedule, set the following properties in the $CDS_HOME/deployment/deployment-name/conf/VSAdminConsole.properties file:

vsadmin.popularity.reindex.interval. Set this property to the number of minutes between recalculations.

vsadmin.popularity.reindex.start. Set this property to the number of minutes past midnight for the base time from which the interval is calculated. For example, if this property is set to 30 and vsadmin.popularity.reindex.interval is set to 90, popularity ratings are recalculated every 90 minutes beginning at 12:30 a.m.

vsadmin.popularity.reindex.enable. Set this property to true to recalculate popularity ratings on the schedule specified by the vsadmin.popularity.reindex.interval and vsadmin.popularity.reindex.start properties. Set to false if you do not want the recalculation process to run.

Note - If you have multiple Vending Managers sharing the same database, configure only one Vending Manager to recalculate the popularity ratings. Disable the function on all other Vending Managers.

1.10 Enabling Cleanup of Expired Items

Streamed content can have an end time assigned to it. Using custom fields, other content can also have an end time. You can configure Content Delivery Server to automatically deactivate items that have reached their expiration time so those items are no longer available to subscribers. To automatically set the status of expired content to Inactive, set the following properties in the $CDS_HOME/deployment/deployment-name/conf/VSAdminConsole.properties file:

vsadmin.expired_content.cleanup.enabled. Indicates whether content is automatically deactivated. Set to true to automatically deactivate content. Set to false to prevent content from being automatically deactivated. The default is true.

vsadmin.expired_content.cleanup.interval. Time, in seconds, between checks for expired content. The default is 3600.

1.11 Configuring Device Client Web Services

Device Client web services are APIs that you can use over the web to access data in the Content Delivery Server database. You can use Device Client web services to authenticate a subscriber, discover, preview, purchase, and download content, access a subscriber’s purchase history, and cancel a subscription to a content item.

If you plan to use the Device Client web services to create your own subscriber interface, set the following properties in the $CDS_HOME/deployment/deployment-name/conf/SubscriberPortal.properties file:

subscriberApi.authkey.timeout.minutes. Number of minutes of inactivity after which an authentication key expires. The initial value is 10.

webservices.v1.authenticate.headers.enable. Flag that indicates if request headers can be used to authenticate a user. The request headers that are used depends on the WAPGatewayAdapter implementations that Content Delivery Server is configured to use. Set to true to enable the use of request headers. Set to false to require either anonymous use or user name and password authentication. The initial value is false.

webservice.v1.auto_provision.unknown.userpeer. Flag that indicates if subscribers known to the external subscriber database, but not known to Content Delivery Server, are provisioned in Content Delivery Server. Set to true to provision unknown users. Set to false to prevent unknown users from being provisioned. The initial value is true. If set to false, a subscriber can be authenticated, but can use only Device Client web services that do not require a subscriber who is known to Content Delivery Server.

For information on Device Client web services, see Chapter 13 in the Sun Java System Content Delivery Server Customization Guide.

1.12 Configuring the Fulfillment Service

Requests for content using a URL from the device are handled through the Fulfillment Service. The MSISDN of the subscriber making the request is used to verify that the subscriber’s subscriber plan includes the content being requested so the subscriber has access to the content. The MSISDN is retrieved from the request header. If the MSISDN is not part of the request header, verification fails and the content is not delivered.

If the request headers that are generated by requests from the devices that you support do not include the MSISDN, you must enable downloads to unprovisioned users to ensure that content is delivered. Allowing unprovisioned users to download content bypasses the verification of the subscriber plan so the MSISDN is not needed.

To enable downloads to unprovisioned users, set the fs.allow_unprovisioned_downloads property in the $CDS_HOME/deployment/deployment-name/conf/FulfillmentService.properties file to true for each Vending Manager deployment.

^{1 (TableFootnote) dp = Developer Portal, vm = Vending Manager administration console, cm = Catalog Manager administration console, sp = Subscriber Portal, empty string (““) = no portal.}