5 About Managing and Using Subscriber Data

This chapter describes how Oracle Communications Evolved Communications Application Server (OCECAS) manages subscriber data.

About Subscriber Data Stores

OCECAS uses three possible types of subscriber data stores to store and access subscriber data: a home subscriber server (HSS) accessed through the Diameter Sh interface, the OCECAS default subscriber server (ESS) NoSQL database, which is optional, or a third-party data store from another provider. The subscriber data stores are also known as user data repositories (UDRs).

Note:

The ESS NoSQL database is only for OCECAS to use for storing subscriber data. Do not store anything else in this database.

If you are using the default ESS NoSQL database, every runtime environment in an OCECAS pipeline must have access it. However, more than one runtime environment can share an ESS, which you can place in the following locations:

  • In a runtime domain.

  • In a dedicated UDR domain.

  • In another location that you specify.

However, the data store configuration is flexible. You can use an external database as the ESS instead of the default NoSQL database. See ”Replacing the ESS NoSQL Database” in Oracle Communications Evolved Communications Application Server Operator's Guide for information.

You can populate the ESS with subscriber data using a REST API. For more information, see ”Provisioning the ESS with Subscriber Data” in Oracle Communications Evolved Communications Application Server Operator's Guide.

OCECAS includes data views that specify connection details to these data stores and invoke federation scripts to merge subscriber data into the format that the application expects. An application requests subscriber data from a specific view. Views are defined in a domain_home/config/custom/csp.xml file for each runtime domain.

The Groovy-based federation scripts create views insulate applications from the HSS and ESS data sources and their data formats. The federation scripts do the following:

  • Federate the data as necessary from the data stores for use by the calling applications.

  • If necessary, translate the data into a format that the calling application can use.

Consequently, you need to update the federation scripts if your subscriber data or data stores change.

You can make service decisions such as selecting features, or changing charging levels based on subscriber information. For example, you could obtain subscriber charging information from an HSS, and federate it with details about the services the subscriber is using from a roaming location.

About Views

The csp.xml file defines views that specify the data stores to use, for example, an HSS, the default NoSQL ESS or a data store from a third-party provider. Views contain connection details for the data stores and specify how to merge data from different sources and translate it from the data-store format into the format the application expects.

Figure 5-1 illustrates the construction of a subscriber record from multiple views and data sources.

Figure 5-1 Subscriber Record Constructed from Multiple Views and Data Sources

Description of Figure 5-1 follows
Description of ''Figure 5-1 Subscriber Record Constructed from Multiple Views and Data Sources''

If necessary, you can make changes to the data federation logic at runtime by changing the csp.py Python script using the WebLogic Scripting Tool (WLST). For more information, see "Updating Federation Script Behavior During Runtime" in the Oracle Communications Evolved Communications Application Server Operator's Guide.

You need to ensure that the csp.xml file is protected. See ”About Developing Secure Applications for OCECAS” in Evolved Communications Application Server Security Guide for information.

See ”Working with Subscriber Data” in Evolved Communications Application Server Operator's Guide for details on the default views and how to change them for your implementation.