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 two types of subscriber data stores to obtain subscriber data for a calling application: a Diameter Sh home subscriber server (HSS), and the OCECAS subscriber server (ESS) NoSQL database.
Note:
The ESS NoSQL database is only for OCECAS to use for UDR data. Do not store anything else in this database.Every runtime environment in an OCECAS pipeline must have access to an ESS that you install during installation. However more than one runtime environment can share an ESS. You can locate the ESS:
-
Inside a runtime domain.
-
Inside a runtime environment, in a dedicated domain called the UDR domain.
-
In another location that you specify.
However, the data store configuration is flexible. You must always have an ESS NoSQL database for OCECAS internal data, but you could also use an external database as the ESS. Or if your applications only read data, have them read it only from the HSS.
If your implementation does not use an HSS (or for testing purposes) you can populate the ESS with subscriber data directly using a REST interface.
OCECAS includes data views that specify connection details to these data stores and specify federation scripts to manipulate subscriber data. Calling applications request subscriber data from a specific view. Views are defined in a domain_home/config/custom/csp.xml file for each runtime domain.
The views insulate calling applications from the HSS and ESS data sources and data formats by using the Groovy-based federation scripts. These scripts:
-
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.
-
Manipulate subscriber data in any way that the calling application or your OCECAS implementation requires.
Consequently, you need to update the federation scripts if anything related to your subscriber data or data stores changes.
You can change 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 on the services they are accessing from a roaming location.
About Views
The csp.xml file defines views that specify the HSSs and an ESS to use. Views contain connection details for the HSSs and ESS.
Figure 5-1 illustrates the construction of a subscriber record from multiple views and data sources.
If necessary, you can also make changes to the data federation logic at runtime using the csp.py Python script using the WebLogic Scripting Tool (WLST).
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.