Interaction With External Systems

C H A P T E R 3

Content Delivery Server interacts with your existing billing system and subscriber database. Content Delivery Server also interacts with its own Oracle database. This section describes the work flow between components.

For information on integrating Content Delivery Server with external systems, see the Sun Java System Content Delivery Server Integration and Configuration Guide.

This chapter includes the following topics:

Billing System Workflow

Subscriber Database Workflow

Content Delivery Server Database Workflow

Billing System Workflow

Content Delivery Server supports both prepaid and postpaid billing models. For prepaid billing models, the billing system is contacted for authorization before a subscriber is permitted to purchase and download content. For postpaid billing models, the billing system receives purchase information after the transaction occurs.

For prepaid billing implementations, Content Delivery Server contacts the billing system before each of the following transactions:

A subscriber views details. For prepaid billing, the billing system has the option of returning a customized price for the content selected.

A subscriber purchases content.

A subscriber downloads content.

A subscriber purchases a subscription.

A subscriber cancels a subscription.

A refund is issued to a subscriber.

The device confirms a successful download.

The device reports an error.

The billing system can decide whether to allow or reject the transaction. For postpaid billing implementations, after each of the following transactions, Content Delivery Server generates an event that contains the information for the billing system to process according to its own schedule.

Subscriber Database Workflow

If Content Delivery Server is configured to work with an external subscriber database, the information kept in the Vending Manager for each subscriber who accesses the Subscriber Portal is limited to the subscriber’s login ID, mobile phone number, device information, and Subscriber Plan. The Vending Manager also keeps information on the subscriber’s download history. For profile information such as the subscriber’s name and address, Content Delivery Server contacts the external subscriber database.

If the external database allows Content Delivery Server to change the subscriber records, the Vending Manager administrator can edit the profile information through the Accounts Management feature of the Vending Manager administration console. If the external database does not allow Content Delivery Server to make changes, the Vending Manager administrator can only view the profile information for subscribers.

Subscriber profiles are reflected in Content Delivery Server only after a subscriber accesses the Subscriber Portal. At that time, a Subscriber Account is created in the Vending Manager. The Vending Manager Administrator can view a list of all Subscriber Accounts without interaction with the subscriber database. When the administrator opens a Subscriber Account, Content Delivery Server contacts the subscriber database and retrieves the profile information.

Content Delivery Server also contacts the external subscriber database to perform the following tasks:

Verify authorization when the subscriber logs in to the Subscriber Portal.

Update the account when the subscriber changes the password.

Send a reminder to a subscriber who forgets the password.

Access a subscriber’s MSISDN or email address for campaigns.

Content Delivery Server Database Workflow

Content Delivery Server uses JDBC trademark API Type 4 drivers to communicate with the database. With the exception of error logs and system configuration properties, all Content Delivery Server data is maintained in the database.

The database is accessed each time information needs to be presented to a user through the Subscriber Portal or the Developer Portal, or to an administrator through the Catalog Manager or Vending Manager administration consoles. To minimize access to the database, you can specify that the database information be cached by setting the cache.enabled property in the $CDS_HOME/deployment/deployment-name/conf/cache.config file.

Content Delivery Server has built-in fault tolerance so it continues to run even if the database fails and can manage stale connections to the database. An error message is issued and logged for each failed transaction and Content Delivery Server continues processing. Database access must be restored to process the transactions that occur.