The Cisco SCMS SCE Subscriber API is used for integrations that require direct access to the SCE platform for subscriber provisioning purposes.
Cisco Service Center Release |
Part Number |
Publication Date |
---|---|---|
Release 3.0.5 |
OL-8236-03 |
November, 2006 |
Description of Changes
Added new section on Quota State Restore Event.
Updated SCAS_BB_Quota class.
Updated the QuotaListenerEx interface due to deprecation of the QuotaListener interface.
Cisco Service Center Release |
Part Number |
Publication Date |
---|---|---|
Release 3.0.3 |
OL-8236-02 |
May, 2006 |
Description of Changes
Updated API code examples. See API Code Examples.
Release 3.0 |
OL-8236-01 |
December, 2005 |
This guide is intended for the networking or computer technician responsible for integrations involving policy servers that perform subscriber provisioning with the SCE platform.
This guide covers the following topics:
Chapter |
Title |
Description |
---|---|---|
Chapter 1 |
This chapter discusses the platforms on which the SCE Subscriber API can be used, and how to install, compile, and start running the API. | |
Chapter 2 |
This chapter describes various terms and concepts that are utilized when working with the SCMS SCE Subscriber API. | |
Chapter 3 |
This chapter describes various events accessed by the SCMS SCE Subscriber API. | |
Chapter 4 |
This chapter describes the various API data types. | |
Chapter 5 |
This chapter provides a detailed description of the API programming structure, classes, methods, and interfaces. | |
Chapter 6 |
This chapter describes the usage of the API logging abilities for troubleshooting the integration with the API. API logging enables the user to monitor the operations being called including the received parameters both at the API client and at the SCE side. | |
Appendix A |
This appendix lists the error codes that are returned by the API. |
This API Guide should be used in conjunction with the following Cisco documentation:
Cisco SCMS Subscriber Manager User Guide
Cisco Service Control Application for Broadband User Guide
Cisco SCE 1000 or SCE 2000 User Guides
This document uses the following conventions:
Convention |
Description |
---|---|
boldface font |
Commands and keywords are in boldface. |
italic font |
Arguments for which you supply values are in italics. |
[ ] |
Elements in square brackets are optional. |
{x | y | z} |
Alternative keywords are grouped in braces and separated by vertical bars. |
[x | y | z] |
Optional alternative keywords are grouped in brackets and separated by vertical bars. |
string |
A nonquoted set of characters. Do not use quotation marks around the string, or the string will include the quotation marks. |
|
Terminal sessions and information that the system displays are in |
|
Information you must enter is in |
|
Arguments for which you supply values are in |
→ |
This pointer highlights an important line of text in an example. |
< > |
Nonprinting characters, such as passwords, are in angle brackets. |
[ ] |
Default responses to system prompts are in square brackets. |
!, # |
An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line. |
Means reader take note. Notes contain helpful suggestions or references to materials not covered in this manual.
Means reader be careful. In this situation, you might do something that could result in loss of data.
The following sections provide sources for obtaining documentation from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at the following sites:
Cisco documentation and additional literature are available in a CD-ROM package that ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Cisco documentation is available in the following ways:
Registered Cisco Direct Customers can order Cisco Product documentation from the networking Products MarketPlace:
Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:
Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North America, by calling 800 553-NETS(6387).
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Attn Document Resource Connection Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-9883
We appreciate your comments.
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at any time, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to http://www.cisco.com.
The Cisco Technical Assistance Center (TAC) website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website http://www.cisco.com/tac.
P3 and P4 level problems are defined as follows:
P3—Your network is degraded. Network functionality is noticeably impaired, but most business operations continue.
P4—You need information or assistance on Cisco product capabilities, product installation, or basic product configuration.
In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.
To register for Cisco.com, go to http://tools.cisco.com/RPF/register/register.do.
If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at http://www.cisco.com/tac/caseopen.
If you have a priority level 1 (P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml.
P1 and P2 level problems are defined as follows:
P1—Your production network is down, causing a critical impact to business operations if service is not restored quickly. No workaround is available.
P2—Your production network is severely degraded, affecting significant aspects of your business operations. No workaround is available.
This chapter discusses the platforms on which the SCE Subscriber API can be used, and how to install, compile, and start running it.
The SCMS SCE Subscriber API provides the ability to external applications (policy servers) to connect directly to the SCE for the purpose of subscriber provisioning.
Subscriber provisioning is a process of updating the Network IDs, Policy Profile and Quota characteristics of the subscriber using the Subscriber ID as the correlation. For more information about the characteristics of the subscriber in the Service Control Application for Broadband (SCA BB), see the Subscriber Characteristics section.
The API can be installed and used concurrently on several policy servers and each of them can perform different parts of the subscriber provisioning process as shown in the following diagram:
The API uses the PRPC (Proprietary Remote Procedure Call) protocol as a transport for the connection to the SCE. The PRPC is a proprietary RPC protocol designed by Cisco.
The API provides a connection to one SCE platform for each API instance
The SCMS SCE Subscriber API distribution is part of the SCMS SM-LEG distribution file and is located in the sce_api directory.
The SCMS SCE Subscriber API is packaged in a UNIX tar file. You can extract the SCMS SCE Subscriber API using the UNIX tar utility or most Windows compression utilities.
To install the distribution on a UNIX platform:
Extract the SCMS SM-LEG distribution file and locate the SCE Subscriber API distribution tar sce-java-api-dist.tar.gz
Unzip the distribution file:
#
> gunzip sce-java-api-dist.tar.gz
Extract the SCE Subscriber API package tar:
#
> tar -xvf sce-java-api-dist.tar
For brevity, the installation directory sce-java-api-
<version>_<build-number>
is referred to as <installdir>.
The <installdir>/javadoc
folder contains the SCE Subscriber API JAVADOC documentation.
The <installdir>/lib
folder contains the sceapi.jar
file, which is the API Executable. It also contains additional jar files necessary for the API operation.
Table 1.1. Layout of Installation Directory
Path |
Name |
Description |
---|---|---|
<installdir> |
|
|
|
README |
API readme file |
<installdir>/Javadoc |
|
|
|
index.html |
Index of all API specifications |
|
(API specification files, etc.) |
API specification documents |
<installdir>/Lib |
|
|
|
sceapi.jar |
SCE Subscriber API executable |
|
asn1rt.jar |
Utility jar used by the API |
|
log4j.jar |
Utility jar used by the API |
|
log4j.properties |
Property file needed for the logging functionalities |
|
jdmkrt.jar |
Utility jar used by the API |
To compile and run a program that uses the SCMS SCE Subscriber API, the following files must be in CLASSPATH:
sceapi.jar
asn1rt.jar
log4j.jar
log4j.properties
—For more information about the file format, see the API Client Logging section.
jdmkrt.jar
The SCE Subscriber API provides internal logging interface using the log4j logging functionalities. In order to function correctly log4j.jar
and log4j.properties
must be in a CLASSPATH when running a program.
For example, if the program source is in SCEApiProgram.java
, use the following command-line to compile:
#
> javac -classpath sceapi.jar SCEApiProgram.java
Afterward, use the following command-line to run the program:
#
> java -cp .;<installdir>/lib/asn1rt.jar; <installdir>/lib/log4j.jar;<installdir/log4j.properties>;<installdir>/lib/sceapi.jar SCEApiProgram
Version 3.0.5 of the API is backward compatible with previous versions, but is not binary-compatible. You must recompile applications that use a previous version of the API in order to use the new version. Since the API is backward compatible, you do not need to make any changes to the application source code.
If you upgrade the SCE to version 3.0.5, you must upgrade the API to version 3.0.5 and recompile the application that uses it.
The following sections describe the configuration that is performed on the SCE platform to allow correct API functioning.
The API connects to the PRPC server on the SCE platform. The PRPC server is a server running a proprietary RPC protocol designed by Cisco. For more information, see the SCE User Guide.
Before using the API, ensure that:
The SCE must be up and running, and reachable from the machine that hosts the API.
The PRPC server on the SCE must be started.
To enable the SCE platform to issue a request for subscriber information when running in a Pull Model (see Pull Model), configure the following using the SCE platform Command-Line Interface (CLI):
To configure the SCE in Pull Model:
Configure the subscriber templates (optional):
(config if)#
>subscriber template import
<CSV file>
For more information about the templates and the format of the CSV file, see the Cisco Service Control Application for Broadband User Guide.
Configure the unmapped-subscriber groups ranges.
Use the following CLI to import anonymous groups from a file:
(config if)#
>subscriber anonymous group import <
CSV file
>
Alternatively, use the following CLI to manually define the anonymous group:
(config if)#
>subscriber anonymous group name <
NAME
> IP-range <
IP RANGE
>
For more information about configuring the SCE platform, see the SCE 1000 or SCE 2000 User Guides.
To enable the RDR formatter to issue quota-related indications, configure the RDR formatter on the SCE platform as follows:
#
>RDR-formatter destination 127.0.0.1 port 33001 category number 4 priority 100
By default, Quota RDRs tags are mapped to category 4. If another category is required, use the following CLI command:
#
>RDR-formatter rdr-mapping add tag-ID <
tag number
> category-number <
number
>
For Quota RDR tag IDs, see the Cisco Service Control Application for Broadband User Guide.
To enable the application to issue quota-related indications, it should be enabled in the Cisco Service Control Application for Broadband GUI. See the Cisco Service Control Application for Broadband User Guide for configuration description.
To enable the API to receive Quota indications, the RDR server should be enabled and listening on the same port that is configured in the RDR formatter. To verify the RDR server configuration, use the following CLI:
#
>show RDR-server
RDR server is ONLINE
RDR server port is 33001
Use the following CLI to enable the RDR server:
#
>configure
(config)#
>RDR-server
Default RDR server port is 33001
Use the following CLI to change the RDR server port:
#
>configure
(config)#
>RDR-server port <
port
>
The SCE platform allows setting the timeout for the API to reconnect to the SCE platform after it was disconnected. During this timeout, the SCE will not free the resources and no data will be lost. After the timeout has elapsed and the API did not reconnect, the SCE considers the API disconnected and frees all the resources. The default timeout value is 5 minutes.
Use the following CLI command to configure the timeout:
(config)# management-agent sce-api timeout
<
timeout-in-sec
>
Use the following CLI command to reset the timeout to the default value:
(config)# default management-agent sce-api timeout
Use the following CLI command to view the timeout value:
# show management-agent sce-api
This chapter describes various terms and concepts that are utilized when working with the SCMS SCE Subscriber API.
One of the fundamental entities in the Service Control Application for Broadband (SCA BB) solution is a subscriber. A subscriber is the entity that the SCA BB solution individually monitors, accounts, and enforces a service configuration. The following sections briefly describe the characteristics of the subscriber in the SCA BB. For more information about the format and usage of the subscriber's characteristics, see the Getting Familiar with the API Data Types section.
Subscriber ID is a subscriber unique identifier, for example, a user name, IMSI (International Mobile Subscriber Identity), or other codes that uniquely identify a subscriber.
When working in the Pull Model integration, the SCE assigns each unknown subscriber IP address with a temporary Subscriber ID, Anonymous Subscriber ID, until it receives the real Subscriber ID from the Policy Server.
For more information on the Pull Model integration, see the Subscriber Integration Models section.
The SCE correlates a certain traffic flow to a subscriber by mapping a network identifier, for example, IP address, IP range, or VLAN, to the subscriber entity.
A Policy Profile includes a set of parameters used by the SCA BB solution to define what policy is enforced on the subscriber.
The following terms describe two models of a dynamic subscriber integration that the SCE platform supports.
In push model integration, an external server introduces (pushes) the subscribers to the SCE platform. This is performed whenever a new subscriber logs in to the network or the external server presumes to know all subscribers and introduces them to the SCE box when they connect.
The SCE Subscriber API is implemented using a non-blocking model. Non-blocking methods return immediately, even before the completion of a subscriber provisioning operation. The Non-blocking Model method is advantageous when the operation is lengthy and involves I/O. Performing the operation in a separate thread allows the caller to continue doing other tasks and it improves overall system performance.
The operation results are either returned to an Observer object (Listener) or may not be returned at all.
The API supports retrieval of operation results using an operation result handler described in the Result Handling section.
The following diagram illustrates the Non-blocking Model method during a subscriber provisioning operation:
Operation results can be used for operation result error logging or for inspection of the parameters used by the operation.
The API provides the user with the ability to receive an indication when certain events occur on the SCE platform. The API dispatches the indications received from the SCE to the interested entities, called listeners, by activating the relevant Listener's callback methods. The indications are separated into several logical groups when only one listener can be defined for each group of indications.
To receive certain indications, you need to register a listener to the API that implements the required callback functions. After the listener is registered, the API can dispatch the required indications to the listener. The SCMS SCE Subscriber API provides three types of indications when separate listeners are registered to the following types of the indications:
Login-pull indications
Logout indications
Quota indications
For more information about listener indications, see the API Events chapter.
The following topologies are recommended to use with the SCMS SCE Subscriber API:
One policy server (or two-node cluster) that is responsible for all aspects of the subscriber provisioning process:
Three policy servers (or three two-node clusters)—Every server is responsible for a different aspect of the subscriber provisioning process:
Two policy servers (or two two-node clusters) when one of the servers is responsible for two aspects of the subscriber provisioning and the other server is responsible for one aspect only (any combination is allowed). For example:
DHCP Lease Query LEG, which is responsible for mapping a Network ID to a Subscriber ID, with one or more policy servers as described in the three policy server diagram above. The following diagram shows the DHCP Lease Query LEG:
SCMS SM, which is responsible for mapping Network ID to Subscriber ID, with one or more policy servers. The number of policy servers depends on whether the SM is used for policy profile provisioning in addition to the network ID:
The API itself does not limit the use of any topology; however, the SCE platform does not correlate between all the entries (Policy Servers) that perform subscriber provisioning. Therefore you should be extremely careful when using more than one Policy Server for the same provisioning purpose (for example Network ID/Subscriber ID correlation). If you are not careful when using more than one Policy Server, the SCE platform may receive different information for the same subscriber from the two policy servers responsible for the same aspect of the subscriber provisioning. This may cause a loss of synchronization with at least one policy server. For example, using two policy servers that are responsible for providing Subscriber ID/Network ID correlation for the same subscriber will produce the situation where the SCE is always synchronized with the policy server that performed the last update for this subscriber.
The API supports an unlimited number (limited by the available memory) of threads calling its methods simultaneously.
In a multi-threaded scenario, the order of invocation is guaranteed: the API performs operations in the same chronological order that they were called.
The API supports auto-reconnection to the SCE in case of connection failure. When this option is activated, the API can determine when the connection to the SCE is lost. When the connection is lost, the API activates a reconnection task that tries to reconnect to the SCE again in a configurable interval time until reconnection is successful.
The SCMS SCE Subscriber API is implemented as a reliable API. The API ensures that no requests to the SCE are lost and no indication from the SCE is lost. The API maintains an internal storage for all API requests that were sent to the SCE. Only after receiving an acknowledgement from the SCE that the request was handled, it considers the request as committed and the API can remove the request from its internal storage. If a connection failure occurs between the API and the SCE, the API accumulates all requests in its internal storage until the connection to the SCE is reestablished. On reconnection, the API resends all non-committed requests to the SCE, ensuring that no requests are lost.
The order of resending requests is guaranteed: the API resends the requests in the same chronological order that they were called.
The API provides high availability support. It assumes that the high availability scheme of the policy server is a two-node cluster type where only one server is active at any given time. The other server, in standby, is not connected to the SCE. For more information, see the Implementing High Availability section.
The SCE and Policy Server must be kept synchronized concerning the subscribers for which the SCE is handling their internal parameters. Otherwise, the SCE might confuse one of the subscriber's traffic to another subscriber, or the subscriber's SLA (Service Level Agreement) will not be enforced because of a change in the policy that did not reach the SCE. For more information read SCE-API Synchronization section.
When implementing the code that integrates the API with your application you should consider the following practical tips:
Connect once to the SCE and maintain an open API connection to the SCE at all times, using the API many times. Establishing a connection is a timely procedure, which allocates resources on the SCE side and the API client side.
Share the API connection between your threads - it is better to have one connection per Policy Server. Multiple connections require more resources on the SCE and client side.
Do not implement synchronization of the calls to the API. The client automatically synchronizes calls to the API.
If the Policy Server application has bursts of logon operations, enlarge the internal buffer size accordingly to hold these bursts (Non-Blocking flavor).
During the integration, use the logging capabilities that are described in the SCE Logging and the API Client Logging sections in the Troubleshooting chapter to view the API operations in the SCE's client logs and to troubleshoot problems during the integration, if any.
Use the debug mode for the Policy Server application that logs/prints the return values of the operations.
Use the automatic reconnect feature to improve the resiliency of the connection to the SCE.
This chapter describes various events accessed by the SCMS SCE Subscriber API.
The API accesses a set of events that are a pre-defined set of messages passed back and forth between the Policy Server and the SCE platform:
Every message can be assigned a type according to the purpose of the message:
Request—Requests information or an action to be performed. A request is not necessarily followed by a response.
Response—Answers a previous request
Indication—Indicates the other side that an event has occurred
Most of the events may be used for both push and pull models. See the Subscriber Integration Models section.
The events may be divided into the following Subscriber Provisioning process groups:
Network ID management events—Includes events relating to the modification of the subscriber Network ID mapping
Policy Profile management events—Includes events relating to modification of the subscriber Policy Profile parameters
Quota management events—Includes events relating to the management of subscriber quota
SCE Synchronization management events—Includes events relating to the management of the SCE synchronization process
You can perform bulk operations, which bundle many triggers for the same event on many subscribers to one global event.
The following sections provide a general description of each type of event.
Login events occur when the subscriber connects to the network and vary for pull and push models.
The push integration model assumes that the Policy Server triggers the subscriber introduction to the SCE. For example, the server receives a subscriber login indication from an external entity such as AAA (Authorization, Authentication, and Accounting), extracts the required subscriber attributes, and "pushes" the information to the SCE platform:
The subscriber login operation may either cause the creation of a new subscriber record in the SCE or update an existing subscriber. For example, for cable modem networks the subscriber is a cable modem and the CPEs connected to this cable modem are configured as a list of IP addresses (potentially ranges). In this case, the login of the new CPE connected to the same modem causes the CPE IP address to be added to the subscriber's Network ID list.
The pull integration model assumes that the SCE discovers a new subscriber from the incoming data traffic. The new subscriber is entered in the system as an anonymous subscriber and is assigned one of the default policies. The SCE initiates a request to the external system (a login-pull request) that may either provide the subscriber login information (a login-pull reply) or is omitted if no information exists for this IP. The login information provided to the SCE replaces the anonymous subscriber with the actual subscriber and enforces the correct policy.
If the external system rejects the login and the traffic keeps coming from the anonymous subscriber, the pull request will be retried.
Despite being classified as “Network-ID Management Event”, LOGIN-REQUEST event and LOGIN-PULL-RESPONSE event are optimized to allow sending all subscriber information to the SCE. It is recommended to use these events for Policy Profile and Quota updates when a single Policy Server performs all parts of the subscriber provisioning. For multiple Policy Servers topologies, use separate events for updating Policy Profile and Quota information described in the following sections. For more information about topologies, see the Supported Topologies section.
The logout event indicates that the subscriber no longer uses a certain network ID. A logout event is not necessarily followed by the removal of the subscriber record from the SCE. For example, in cable modem networks, when there are more than one CPE connected to the same modem, the logout of one CPE may not lead to the removal of a subscriber if another CPE remains connected. The actual removal of the subscriber occurs when all of the CPEs (Subscriber's network-IDs) are disconnected.
The logout event in the pull model may occur, for example, when the SCE identifies that the subscriber is not active for a specific time interval. The SCE “logs out” the subscriber and sends a LOGOUT-INDICATION event.
The LOGOUT-INDICATION event may also follow the Logout operation. This occurs once a subscriber is actually removed; for example, when no more valid network mappings (IP) are associated with this subscriber.
This event is a REQUEST from the Policy Server to the SCE to update the policy profile of the subscriber that already exists in the SCE platform. This event does not require any RESPONSE.
As described above, the LOGIN-REQUEST event and LOGIN-PULL-RESPONSE event can also update the policy profile.
The Quota Update Event is a REQUEST from the Policy Server to the SCE to update the quota of the subscriber that already exists in the SCE platform. This event does not require any RESPONSE event.
As described above, the LOGIN-REQUEST event and LOGIN-PULL-RESPONSE event can also update the quota.
The Get Quota Status Event is a REQUEST from the Policy Server to the SCE to report the quota information of the subscriber that already exists in the SCE platform. A QUOTA-STATUS-INDICATION event follows this event.
A QUOTA-STATUS-INDICATION event may be issued periodically by the SCE without a specific request from the Policy Server. See the next section.
The SCE uses the Quota Status INDICATION event to notify the Policy Server about the remaining quota. This event is invoked periodically in a preconfigured time interval.
The SCE uses the Quota Below Threshold INDICATION event to notify the Policy Server that the remaining quota for certain services of the specific subscriber is below the preconfigured threshold. An UPDATE-QUOTA-REQUEST event from the Policy Server to the SCE may follow this event, but it is not mandatory.
The SCE uses the Quota Depleted INDICATION event to notify the Policy Server that the quota for certain services of the specific subscriber is depleted. An UPDATE-QUOTA-REQUEST event from the Policy Server to the SCE may follow this event.
The Quota State Restore Event is an INDICATION from the SCE to the Policy Server to restore the quota of the subscriber that exists in the SCE platform. This event is invoked immediately after a subscriber is logged in to the SCE. A Quota Update event from the Policy Server may follow this event.
The Start Synchronization REQUEST event is used to notify the SCE that the synchronization process is about to start. The SCE uses this REQUEST to perform internal operations that are required for synchronization process preparation. This event has a push and a pull component.
The End Synchronization REQUEST event is used to notify the SCE that the synchronization process has ended. This event has a push and a pull component.
During the SCE's Pull Model synchronization process, the Policy Server is required to retrieve ALL subscribers that the SCE is currently handling. The GET-SUBSCRIBERS-BULK-REQUEST event is a request from the Policy Server to the SCE to retrieve the next bulk of subscribers that the SCE is currently handling. Upon receiving this request, the SCE responds with the GET-SUBSCRIBERS-BULKRESPONSE event that supplies the subscriber names and Network-IDs.
For more information, see the Pull Model section and the Pull Model Synchronization Procedure section.
This chapter describes the various API data types used in the SCMS SCE Subscriber API.
Most methods of the SCE Subscriber APIs require the subscriber ID to be used as an input parameter. The Subscriber ID is a string representing a subscriber name or a CM MAC address. This section lists the formatting rules of a subscriber ID.
The subscriber name is case-sensitive. It may contain up to 40 characters. The following characters may be used:
Alphanumerics |
$ (dollar sign) |
. (period or dot) |
_ (underscore) |
- (minus sign or hyphen) |
% (percent sign) |
/ (slash) |
~ (tilde) |
! (exclamation mark) |
& (ampersand) |
: (colon) |
' (apostrophe) |
# (number sign) |
() (parentheses) |
@ (at sign) |
|
For example:
String subID1=”john”;
String subID2=”john@yahoo.com”;
A network ID is a network identifier that the SCE device relates to a specific subscriber record. A typical example of a network ID mapping is an IP address. Currently, the Cisco Service Control Engine (SCE) supports IP address, IP range, and VLAN types of mappings.
The NetworkID class represents various types of subscriber network identification.
The API supports the following subscriber mapping types:
IP addresses or IP ranges
VLAN tags
Mixing IP addresses/IP ranges with VLAN tags for the same subscriber is not supported.
When using subscriber operations that involve network ID, the caller is requested to provide a NetworkID parameter.
NetworkID class constructors are defined as follows:
public NetworkID(String mapping,short mappingType) throws Exception
public NetworkID(String[] mappings,short[] mappingTypes) throws Exception
Parameters of the NetworkID constructors are:
a java.lang.String
mapping identifier or array of mapping identifiers
a short mapping type or array of mapping types
When passing arrays, the mappingTypes array must contain either the same number of elements as the mappings array, or a single element.
Use NetworkID.TYPE_IP or NetworkID.TYPE_VLAN constants if the array contains more than one element
Use NetworkID. ALL_IP_MAPPINGS or NetworkID.ALL_VLAN_MAPPINGS constants when a single array element is used
The string format of an IP address is the commonly used decimal notation:
IP-Address=[0-255].[0-255].[0-255].[0-255]
Example:
216.109.118.66
The mapping type of an IP address is provided in the class NetworkID:
com.scms.common.NetworkID.TYPE_IP
:
com.scms.common.NetworkID.ALL_IP_MAPPINGS
specifies that all the entries in the mapping identifiers array are IP mappings.
The string format of an IP range is an IP address in decimal notation and a decimal specifying the number of 1s in a bit mask: IP-Range=[0-255].[0-255].[0-255].[0-255]/[0-32]
.
Examples:
10.1.1.10/32
is an IP range with a full mask, that is, a regular IP address.
10.1.1.0/24
is an IP range with a 24-bit mask, that is, all of the addresses ranging between 10.1.1.0
and 10.1.1.255
.
The mapping type of an IP Range is identical to the mapping type of the IP address.
The string format for VLAN tag mapping is a decimal number in the following range: [2-2046]
The com.scms.common.NetworkID
class provides the VLAN mapping type:
The mapping type of an IP address is provided in the class NetworkID:
com.scms.common.NetworkID.TYPE_VLAN
:
com.scms.common.NetworkID.ALL_VLAN_MAPPINGS
specifies that all the entries in the mapping identifiers array are VLAN mappings.
Construct NetworkID with a single IP address:
NetworkID nid = new NetworkID(“1.1.1.1”,NetworkID.TYPE_IP)
Construct NetworkID with a range of IP addresses:
NetworkID nid = new NetworkID(“1.1.1.1/24”,NetworkID.TYPE_IP)
Construct NetworkID with multiple IP addresses:
NetworkID nid = new NetworkID(new String[]{“1.1.1.1”,”2.2.2.2”,”3.3.3.3”}, NetworkID.ALL_IP_MAPPINGS)Construct NetworkID with a single VLAN address:
NetworkID nid = new NetworkID(“23”,NetworkID.TYPE_VLAN)
The Policy Profile describes the subscriber policy information. A policy profile is generally comprised of two main parts including a statically defined policy that is identified by the policy package and a set of subscriber policy properties that might have a dynamic nature. The package ID identifies the policy package. Most of the rules enforced on the subscriber traffic are derived from the package ID.
Subscriber policy property in the SCA BB is a key-value pair that affects the way the SCE analyzes and reacts to network traffic generated by the subscriber.
More information about properties can be found in the Cisco Service Control Application Suite for Broadband User Guide.
SCA BB version 3.0 contains the following properties:
packageId—Defines the package ID of the subscriber
monitor—Indicates whether to issue an Raw Data Record (RDR) for each transaction of this subscriber
The API provides a PolicyProfile class to format subscriber policy profiles required for the API operations.
The following method constructs the PolicyProfile class based on the array of policy properties:
public PolicyProfile(String[] policy)
The encoding of each string within the array must be as follows: “property_name=property_value”.
The following method allows adding a policy property to the profile according to the format described above:
public void addPolicyProperty(String policyProperty)
This method is not optimized for performance. For best performance results, use the PolicyProfile constructor.
PolicyProfile pp = new PolicyProfile(new String[]{"packageId=22", "monitor=1"})
The quota provisioning in SCA BB is prepared using subscriber quota buckets. Each subscriber has 16 buckets, and you can define each bucket for volume or sessions. When a subscriber uses a particular service, the amount of consumed volume or number of sessions is subtracted from one of the buckets. The service configuration, which is defined in the general policy definition by using the SCA BB GUI, determines which bucket to use for each service. Consumption for the volume buckets is counted in units of L3 kilobytes and consumption for the session buckets is the number of sessions. For example, it is possible to define that the Browsing and E-mail services consume quota from Bucket #1, P2P service consumes quota from Bucket #2, and that all other services are not bound to any particular bucket.
Quota bucket comprises from the following components:
Bucket ID—Unique identifier of the bucket (String
) as defined in the predefined policy. Valid values are numbers in range [1-16]
Bucket value—Quota bucket value (long
)
Quota Operation dynamically modifies a subscriber's quota buckets. There are two types of quota operations:
ADD_QUOTA_OPERATION—Adds the new quota value to the current value of the bucket residing on the SCE platform
SET_QUOTA_OPERATION—Replaces the value of the quota bucket residing on the SCE platform with the new value
Current values of subscriber A's quota at the SCE is as follows:
We want to apply the following actions to the existing quota:
After performing the quota actions, the result is:
For additional information about Subscriber Quota, see the Service Control Application for Broadband User Guide.
The following sections describe the classes the API provides for operations that include the subscriber quota management operations.
The SCAS_BB_Quota class implements the Quota interface, which the QuotaListenerEx interface uses in all callback functions.
The following method constructs the SCAS_BB_Quota based on the array of IDs and values:
public SCAS_BB_Quota (String[] bucketIDs,
long[] bucketValues)
The following method constructs the SCAS_BB_Quota based on the array of IDs and values, the profile ID, the reason, and the timestamp:
public SCAS_BB_Quota (String[] bucketIDs,
long[] bucketValues,
int quotaProfileId,
int reason,
long timestamp)
The following method allows retrieving of the quota buckets' IDs:
public String[] getBucketIDs()The following method allows retrieving of the quota buckets' values:
public long[] getBucketValues()
The quotaProfileId
parameter is the identifier for the quota profile, which is the package ID. The following method allows retrieving of the quota profile ID:
public int getQuotaProfileId()
The reason
parameter is relevant only for quota status events and has three possible values:
0—The configured time was reached, for example, every two minutes
1—The quota status event was triggered by a subscriber logout
2—The quota status event was triggered by a package change
The following method allows retrieving of the reason:
public int getReason()
The timestamp
parameter contains the time (in the SCE) at which the event was generated. It is calculated as the number of seconds from January 1, 1970 00:00 GMT.
The following method allows retrieving of the timestamp:
public long getTimestamp()
The SCAS_BB_QuotaOperation class implements the QuotaOperation interface, which is used for Subscriber Provisioning operations that include the subscriber's quota such as login operation (see the login operation section) and update quota operation (see the quotaUpdate operation).
The following method constructs the SCAS_BB_QuotaOperation based on the array of IDs, values and actions:
public SCAS_BB_QuotaOperation (String[] IDs,
long[] values,
short[] actions)
The following method allows retrieving of the quota buckets' IDs:
public String[] getBucketIDs()The following method allows retrieving of the quota buckets' values:
public long[] getBucketValues()
The following method allows retrieving of the quota buckets' actions:
public short[] getBucketActions()
Use bulk classes and operations when performing the same method for many subscribers each with its own parameters. The API provides the bulk classes for result handling of bulk operations and for bulk indications from the SCE. The bulk classes are passed to the bulk methods such as loginBulk
and logoutBulk
.
The following is a list of considerations when using the bulk operations:
All bulk classes are inherited from the common BulkBase class.
Due to the memory constraints of the SCE, the bulk size is limited to a maximum of 100 entries.
The BulkBase class provides an iterator to view the data contained in the bulk.
The following is the syntax for the Bulk Iterator:
Iterator getIterator()
This iterator can be used for iteration over the bulks received from the SCE in various indications (for example, logoutBulkIndication, loginPullBulkResponseIndication, and so forth) or for inspecting the data you provided to various operations in case an operation has failed.
The iterator provides the following methods for data retrieval:
public Object next() public boolean hasNext()The next() method returns a SubscriberData object.
The SubscriberData class is used for retrieving the information of a single subscriber contained within the bulk.
The SubscriberData class represents all of the operations that can be performed on a specific subscriber. The SubscriberData class contains the following utility methods for information retrieval:
public String getSubscriberID() public String getAnonymousID() public String[] getMappings() public short[] getTypes() public boolean getAdditiveFlag() public String[] getPolicyStrings() public String[] getQuotaStrings() public String[] getQuotaOperationStrings()
The following sections describe various bulk data types that are available for different API operations.
This class represents bulk of subscribers and it includes all data required for the loginBulk
operation.
To construct the Login_BULK filled with the data use the following constructor:
public Login_BULK(String[] subscriberIDs,
NetworkID[] networkIDs,
boolean[]networkIDsAdditive,
PolicyProfile[] policy,
QuotaOperation[] quota)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
networkID
—The network identifier of the subscriber. See the Network ID Mappings section for more information.
networkIDAdditive
—If this flag is set to TRUE, the supplied NetworkID is added to the existing networkIDs of the subscriber. Otherwise, the supplied networkID replaces the existing networkIDs.
policy
—Policy profile of the subscriber. See the SCA BB Subscriber Policy Profile section for more information.
quota
—Quota of the subscriber. See the Subscriber Quota section for more information.
To construct an empty Login_BULK, use the following method:
public Login_BULK()
Use the following method to add entries to the bulk:
public void addBulkEntry(String subscriberID, NetworkID networkID, boolean networkIdsAdditive, PolicyProfile policy, QuotaOperation quota)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
networkID
—The network identifier of the subscriber. See the Network ID Mappings section for more information.
networkIDAdditive
—If this flag is set to TRUE, the supplied NetworkID is added to the existing networkIDs of the subscriber. Otherwise, the supplied networkID replaces the existing networkIDs.
policy
—Policy profile of the subscriber. See the SCA BB Subscriber Policy Profile section for more information.
quota
—Quota of the subscriber. See the Subscriber Quota section for more information.
The following example demonstrates the usage of the Login_BULK object:
// Prepare all data for the bulk constructionString[] names = new String[5];
NetworkID[] mappings = new NetworkID[5];
boolean[] additive = new boolean[5];
PolicyProfile[] policy = new PolicyProfile[5];
for (int i=0; i< 5; i++)
{
names[i]="sub_"+i;
mappings[i] = new NetworkID(”1.1.1.”+i,NetworkID.TYPE_IP);
additive[i] = true;
policy[i] = new PolicyProfile(new String[]{"packageId="+(i+1)});
}
// construct the bulk object
Login_BULK bulk = new Login_BULK(names,mappings,additive,policy,null);// Now it can be used in loginBulk operation
sceApi.loginBulk(bulk,null);
An alternative way of manipulating Login_BULK:
// Construct the empty bulk
Login_BULK bulk = new Login_BULK ();
// Fill the bulk using addBulkEntry method:
for (int i=0; i<20; i++)
{
String name ="sub_"+i;
NetworkID mappings = new NetworkID(i+1);
boolean additive = true;
PolicyProfile policy = new PolicyProfile(
new String[]{"packageId="+(i+1)});
QuotaOperation quota = new SCAS_BB_QuotaOperation(
new String[]{“1”,”2”,”3”},
new long[]{80,80,0}
new short[]{SCAS_BB_QuotaOperation.ADD_QUOTA_OPERATION,
SCAS_BB_QuotaOperation.ADD_QUOTA_OPERATION,
SCAS_BB_QuotaOperation.SET_QUOTA_OPERATION}); bulk.addBulkEntry(name,mappings,additive,policy,quota);
}// Now it can be used in loginBulk operation
sceApi.loginBulk(bulk,null);
The logoutBulkIndication
callback function that requires only subscriber IDs to be entered uses the SubscriberID_BULK class. See logoutBulkIndication callback method.
To construct the SubscriberID_BULK
with Subscriber IDs data, use the following constructor:
public SubscriberID_BULK(String[] subscriberIDs)
To construct an empty SubscriberID_BULK, use the following method:
public SubscriberID_BULK()
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
Use the following method to add entries to the SubscriberID bulk:
addBulkEntry(String subscriberID)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
Use the NetworkAndSubscriberID_BULK class in bulk operations that require Subscriber IDs and NetworkIDs in the following operations:
getSubscribersBulkResponse
callback (see the LoginPullListener section)
logoutBulk
operation (see the logoutBulk operation section)
networkIDUpdateBulk
operation (see the networkIdUpdateBulk operation section)
To construct the NetworkAndSubscriberID_BULK
with the SubscriberID and NetworkID data, use the following constructor:
public NetworkAndSubscriberID_BULK(String[] subscriberIDs, NetworkID[] networkIDs, boolean[] netIdAdditive)To construct an empty
NetworkAndSubscriberID_BULK,
use the following method:public NetworkAndSubscriberID_BULK()
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
networkID
—The network identifier of the subscriber. See the Network ID Mappings section for more information.
networkIDAdditive
—If this flag is set to TRUE, the supplied NetworkID is added to the existing networkIDs of the subscriber. Otherwise, the supplied networkID replaces the existing networkIDs.
Use the following method to add entries to the bulk:
addBulkEntry(String subscriberID, NetworkID networkID, boolean netIdAdditive)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
networkID
—The network identifier of the subscriber. See the Network ID Mappings section for more information.
networkIDAdditive
—If this flag is set to TRUE, the supplied NetworkID is added to the existing networkIDs of the subscriber. Otherwise, the supplied networkID replaces the existing networkIDs.
This class represents a bulk of subscribers and includes all data required for the loginPullResponseBulk
method.
To construct the LoginPullResponse_BULK
containing the relevant data, use the following constructor:
public LoginPullResponse_BULK(String[] anonymousSubscriberIDs,
String[] subscriberIDs,
NetworkID[] networkIDs,
boolean[] networkIdsAdditive,
PolicyProfile[] policy,
QuotaOperation[] quota)
To construct an empty LoginPullResponse_BULK,
use the following method:
public LoginPullResponse_BULK()anonymousSubscriberID
—The identifier of the anonymous subscriber. This is sent by the SCE within the loginPullRequest/loginPullBulkRequest indication. See the Subscriber Integration Models section for more information.
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
networkID
—The network identifier of the subscriber. See the Network ID Mappings section for more information.
networkIDAdditive
—If this flag is set to TRUE, the supplied NetworkID is added to the existing networkIDs of the subscriber. Otherwise, the supplied networkID replaces the existing networkIDs.
policy
—The policy profile of the subscriber. See the SCA BB Subscriber Policy Profile section for more information.
quota
—The quota of the subscriber. See the Subscriber Quota section for more information.
Use the following method to add entries to the bulk:
public addBulkEntry(String anonymousSubscriberID, String subscriberID, NetworkID networkID, boolean networkIdAdditive, PolicyProfile policy, QuotaOperation quota)
anonymousSubscriberID
—The identifier of the anonymous subscriber. This is sent by the SCE within the loginPullRequest/loginPullBulkRequest indication. See the Subscriber Integration Models section for more information.
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
networkID
—The network identifier of the subscriber. See the Network ID Mappings section for more information.
networkIDAdditive
—If this flag is set to TRUE, the supplied NetworkID is added to the existing networkIDs of the subscriber. Otherwise, the supplied networkID replaces the existing networkIDs.
policy
—The policy profile of the subscriber. See the SCA BB Subscriber Policy Profile section for more information.
quota
—The quota of the subscriber. See the Subscriber Quota section for more information.
The updatePolicyProfileBulk
operation uses this class that represents a bulk of subscriber IDs and subscriber policy profiles.
To construct the PolicyProfile_BULK
containing the relevant data, use the following constructor:
public PolicyProfile_BULK(String[] subscriberIDs, PolicyProfile[] policy)To construct an empty PolicyProfile_BULK
, use the following method:
public PolicyProfile_BULK()
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
policy
—The policy profile of the subscriber. See the SCA BB Subscriber Policy Profile section for more information.
Use the following method to add entries to the bulk:
public addBulkEntry(String subscriberID, PolicyProfile policy)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
policy
—The policy profile of the subscriber. See the SCA BB Subscriber Policy Profile section for more information.
The following operations use this class that represents a bulk of subscribers IDs and subscriber quota buckets:
getQuotaStatusBulk operation (only the bucket IDs are to be provided)
quotaStatusBulkIndication callback method
quotaDepletedBulkIndication callback method
quotaBelowThresholdIndication callback method
To construct the Quota_BULK
containing the relevant data, use the following constructor:
public Quota_BULK(String[] subscriberIDs, Quota[] subscribersQuota)
To construct an empty Quota_BULK, use the following method:
public Quota_BULK()
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
quota
—The quota of the subscriber. See the Subscriber Quota section for more information.
Use the following method to add entries to the bulk:
public addBulkEntry(String subscriberID,Quota quota)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
quota
—The quota of the subscriber. See the Subscriber Quota section for more information.
The QuotaUpdateBulk
operation and the login operation use this class that represents a bulk of subscribers IDs and subscriber Quota operations.
To construct the QuotaOperation_BULK
containing the relevant data, use the following constructor:
public QuotaOperation_BULK(String[] subscriberIDs, QuotaOperation[]quotaOperations)To construct an empty
QuotaOperation_BULK,
use the following method:public QuotaOperation_BULK()
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
quotaOperation
—The quota operation to perform on the quota of the subscriber. See the Subscriber Quota section for more information.
Use the following method to add entries to the bulk:
addBulkEntry(String subscriberID, QuotaOperation quotaOperation)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
quotaOperation
—The quota operation to perform on the quota of the subscriber. See the Subscriber Quota section for more information.
This chapter provides a detailed description of the API programming structure, classes, methods, and interfaces.
The following list maps the classes provided by the API.
PRPC_SCESubscriberApi—Main API class.
LoginPullListener Interface Class (interface)
LogoutListener Interface Class (interface)
QuotaListenerEx Interface Class (interface)
ConnectionListener (interface)
OperationException (class)
SCESubscriberApi (interface)—Contains error codes constants that can be received inside OperationException
OperationArguments (class)
OperationResultHandler (interface)
com.scms.common
package contains all data types used by the API.
Login_BULK (class)
LoginPullResponse_BULK (class)
NetworkAndSubscriberID_BULK (class)
PolicyProfile_BULK (class)
SubscriberID_BULK (class)
SubscriberData (class)
SCAS_BB_Quota (class)
SCAS_BB_QuotaOperation (class)
NetworkID (class)
PolicyProfile (class)
As described in previous sections, many of the API operations are based on callback methods. The user provides a “listener”, which is called when certain events occur. The following warning defines the main guideline for programming with callback methods.
Do not perform long operations within the thread of the callback method. Long operations should be performed from a separate thread. Moreover, not following this recommendation might result in resource leakage on the client's side.
This caution applies to the following operations:
LoginPullListener callback methods
LogoutListener callback methods
QuotaListenerEx callback methods
ConnectionListener callback methods
The PRPC_SCESubscriberAPI class (resides in a com.scms.sce.api.prpc package) is the main API class that provides the following functionality:
Constructing the API
Connecting the API to exactly one SCE (configuring the connection attributes)
Registering/unregistering indications listeners
Setting the connection listener
Performing Subscriber Provisioning operations
Disconnecting from the SCE
The PRPC_SCESubscriberAPI provides the following constructors:
Syntax:
public PRPC_SCESubscriberApi(String apiName, String sceHost) throws UnknownHostException public PRPC_SCESubscriberApi(String apiName, String sceHost, long autoReconnectInterval) throws UnknownHostException public PRPC_SCESubscriberApi(String apiName, String sceHost, int scePort, long autoReconnectInterval) throws UnknownHostExceptionParameters:
The following is a description of the constructor arguments for the API constructors:
apiName
—Specifies an API name.
Note
The API name should be unique per SCE. If you construct more than one API with the same name and connect it to a single SCE, the SCE platform will handle the APIs as one API client. Use this feature only when high-availability is supported. For more information about high availability, see the Implementing High Availability section.
sceHost
—Can be either an IP address or a reachable hostname.
scePort
—PRPC protocol TCP port to connect to the SCE (default value is 14374)
autoReconnectInterval
—Defines the interval (in milliseconds) for attempting reconnection by the reconnection task, as follows:
If the value is 0 or less, the reconnection task is not activated (no auto-reconnect is attempted).
If the value is greater than 0 and a connection failure exists, the reconnection task will be activated every
<autoReconnectInterval>
milliseconds.Default value: -1 (no auto-reconnect is attempted)
Note
To enable the auto-reconnect support, the
connect
method of the API must be called at least once.Examples:
The following code constructs an API with an auto-reconnection interval of 10 seconds:
PRPC_SCESuscriberAPI sceApi = new PRPC_SCESuscriberAPI(“MyApi”, ”10.1.1.1”, 10000); sceApi.connect();
The following code constructs an API without auto-reconnection support:
PRPC_SCESuscriberAPI sceApi = new PRPC_SCESuscriberAPI(“MyApi”, ”10.1.1.1”); sceApi.connect();
After initializing the API, it should be set-up with the utilized listeners based on the type of application using the API, and the topology used. For more information about topologies, see the Supported Topologies sections.
The listeners setup operations may include:
Setting a connection listener, described in more detail in the ConnectionListener Interface section:
public void setConnectionListener(ConnectionListener listener)
Setting a login-pull listener, described in more detail in the LoginPullListener Interface section:
public void registerLoginPullListener(LoginPullListener listener)Setting a logout listener, described in more detail in the LogoutListener Interface section.
public void registerLogoutListener(LogoutListener listener)Setting a quota listener, described in more detail in the QuotaListenerEx Interface section.
public void registerQuotaListener(QuotaListener listener)Note
The listener registration to the API causes resource allocations in the SCE to support reliable delivery of messages to the listener. Even if the application that uses the API crashes and restarts after a short time the messages are kept and sent to the SCE when the API reconnects.
The API enables initializing certain internal properties for API customization. The initialization is done using the API
init
method.Note
For settings to take effect, the
init
method must be called before theconnect
method.The following properties can be set:
Output queue size—The internal buffer size defining the maximum number of requests that can be accumulated by the API until they are sent to the SCE (Default: 1024)
Operation timeout—A suggested time interval about the desired timeout (in milliseconds) on a non-responding PRPC protocol connection (Default: 45 seconds)
properties (java.util.Properties)
Enables setting the properties described above:
To set the output queue size, use
prpc.client.output.machinemode.recordnum
as a property keyTo set the operation timeout, use
com.scms.api.sce.prpc.regularInvocationTimeout
orcom.scms.api.sce.prpc.listenerInvocationTimeout
as a property keyNote
com.scms.api.sce.prpc.listenerInvocationTimeout
is used for operations that may be invoked from listener callback. This timeout should be shorter thancom.scms.api.sce.prpc.regularInvocationTimeout
to avoid deadlocks.The following code shows how to customize properties during initialization:
// API construction PRPC_SCESuscriberAPI sceApi = new PRPC_SCESuscriberAPI(“MyApi”, “10.1.1.1”,10000); // API initialization java.util.Properties p = new java.util.Properties(); p.setProperty("prpc.client.output.machinemode.recordnum", 2048+""); api.init(p); // connect to the API sceApi.connect();Note
The
init
method is called before theconnect
method.After setting up the API, you should attempt to connect to the SCE. If the auto-reconnect feature is activated, the API will handle any disconnection from this point on.
To connect to the SCE, use the following methods:
public void connect() throws Exception
At any time during the API operation, you can check if the API is connected to the SCE by using the method
isConnected()
:public boolean isConnected()Note
Every API instance supports a connection to exactly one SCE platform.
To free the resources of both server and client, call the
disconnect
method:public void disconnect()The call to the disconnect method frees the resources in the SCE that manages the reliability of the connection from the SCE to the API. If the application is restarting and you do not want to lose any messages, do not use the disconnect method.
It is recommended that you use a
finally
statement in your main class. For example:public static void main(String [] args) throws Exception { PRPC_SCESubscriberApi sceapi = new PRPC_SCE_SubscriberApi (“myApi”, “sceHost”); try { … // Your code goes here } finally { sceapi.disconnect(); } }
The SCE platform issues several types of indications when certain events occur. There are three types of indications:
Login-pull indications
Logout indications
Quota indications
The indications are sent only if there are listeners that are registered to listen to those indications. For every type of indications, a separate listener may be registered. For descriptions about the events that trigger these indications, see the API Events chapter.
The LoginPullListener
interface defines a set of callback functions that are used only in the pull model.
Policy Servers that are responsible for the Network ID management part of the Subscriber Provisioning process and intend to work in the pull model should register a LoginPullListener to enable to respond to the login-pull requests from the SCE and to synchronize the SCE platform.
To enable listening to those indications, the API allows a listener to be set for these types of indications:
public void registerLoginPullListener(LoginPullListener listener)
public void unregisterLoginPullListener(LoginPullListener listener)
The API supports one LoginPullListener at a time. Furthermore, it is strongly recommended not to have more than one API that has registered a LoginPullListener. This can lead to non-synchronized SCE platforms if both SCEs respond to the same login-pull request.
LoginPullListener
is an interface that is implemented to enable to register a login-pull indications listener. It is defined as follows:
public interface LoginPullListener
{
public void loginPullRequest (String anonymousSubscriberID,
NetworkID networkID)
public void loginPullRequestBulk(NetworkAndSubscriberID_BULK subs)
public void getSubscribersBulkResponse(
NetworkAndSubscriberID_BULK subs,
SubscriberBulkResponseIterator iterator)
}
When the SCE encounters an unknown IP address's subscriber-side traffic, it issues a request for the subscriber login information based on the IP address (see Pull model in API Events chapter). The SCE expects the policy server to respond with the configuration data of the subscriber data to which this IP was allocated.
This request is dispatched to the registered listener and triggers the loginPullRequest
callback function. Upon this callback, the listener should retrieve the subscriber information of the subscriber matching this IP address and activate loginPullResponse
to deliver the information to the SCE (see loginPullResponse operation section in Subscriber Provisioning Operations). If no information exists for this IP address, no response is issued.
The following diagram illustrates the loginPullRequest
callback method:
anonymousSubscriberID
—This anonymous subscriber ID must be supplied to the loginPullResponse
operation (see the loginPullResponse operation section). Also see the Anonymous Subscriber ID section.
networkID—The network identifier of the unknown subscriber. See the NetworkID section for more information.
This callback function is the bulk version of the loginPullRequest
callback function that is described above.
subs
—Contains pairs of NetworkIDs and anonymous IDs of several subscribers. See the parameters description of the loginPullRequest callback method for more information.
The Policy Server can respond to this request by the loginPullBulkResponse method activation or by activating the loginPullResponse method for each NetworkID in the bulk. To iterate over the data contained in the subs parameter use the next() iteration method provided by the bulk class.
This callback method is used during the SCE synchronization process in the pull model. For a detailed description, see the SCE-API Synchronization section.
Policy Servers that are responsible for the Network ID management part of the Subscriber Provisioning process might want to register a LogoutListener to be notified when certain subscribers are actually removed from the SCE platform.
The API allows setting a LogoutListener
to be able to receive logout indications.
public void registerLogoutListener(LogoutListener listener)
public void unregisterLogoutListener(LogoutListener listener)
The API supports one LogoutListener at a time.
The following sections describe callback functions of the LogoutListener
interface.
When the SCE platform identifies the logout of the last Network-ID of the subscriber identified by the subscriberID, it issues the logout indication. This triggers a call to the logoutIndication
callback function of all registered logout indications listeners.
public void logoutIndication(String subscriberID)subscriber ID
—A unique identifier of the subscriber. See Subscriber ID for more information. The SCE no longer handles this subscriber ID.
When the SCE platform identifies the logout of the last NetworkID of the group of subscribers, it issues the logout bulk indication. This triggers a call to the logoutBulkIndication
callback function of all registered logout indications listeners.
public void logoutBulkIndication(SubscriberID_BULK subs)
subs
—Contains subscriber IDs of the subscribers that were logged out. See the SubscriberID_BULK section for more information.
From version 3.0.5, the QuotaListener interface is deprecated and should be replaced with QuotaListenerEx. For backwards compatibility, the QuotaListener interface still exists, but you should use the QuotaListenerEx interface when integrating with version 3.0.5 of the API.
Policy Servers that are responsible for the Quota management operations in the Subscriber Provisioning Process should be able to receive quota-related indications issued by the SCE platform.
The API allows setting the QuotaListener
to be able to receive quota indications.
public void registerQuotaListener(QuotaListener listener) public void unregisterQuotaListener(QuotaListener listener)Note
The API supports one QuotaListener at a time.
Note
The QuotaListener interface is used for backward compatibility, but it is recommended to pass an object that implements QuotaListenerEx.
The following sections describe the callback functions of the
QuotaListenerEx
interface.Note
The Bulk versions of the quota callback methods are not used in this release of the API.
Quota status indication delivers the remaining value of the specified set of the quota buckets for a specific subscriber. This indication is issued by the SCE periodically or upon a call to the getQuotaStatus operation (see the getQuotaStatus section) and is distributed to the registered listener by activating a
quotaStatusIndication
callback function.public void quotaStatusIndication(String subscriberID, Quota quota)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
quota
—Quota of the subscriber. See Subscriber Quota section for more information.Quota status bulk indication delivers the remaining value of the specified set of the quota buckets for a group of subscribers. This indication is issued by SCE periodically or upon a call to the
getQuotaStatusBulk
operation (see the Get Quota Status Event section) and is distributed to the registered listener by activating a
quotaStatusBulkIndication
callback function.public void quotaStatusBulkIndication(Quota_BULK subs)
You can configure the period for periodically issued indications. For more information, see the Cisco Service Control Application for Broadband User Guide.
subs
—Contains quota data of the bulk of the subscribers. See the Quota_BULK section for more information.When the quota of a subscriber drops below a pre-configured threshold, the SCE platform issues an indication that is distributed to the registered listener by activating a
quotaBelowThresholdIndication
callback function.public void quotaBelowThresholdIndication(String subscriberID, Quota quota)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
quota
—Quota of the subscriber. See the Subscriber Quota section for more information.When the quota of a group of subscribers drops below a pre-configured threshold, the SCE platform issues an indication that is distributed to the registered listener by activating a
quotaBelowThresholdBulkIndication
callback function.public void quotaBelowThresholdBulkIndication(Quota_BULK subs)
subs
—Contains quota data of the bulk of the subscribers. See the Quota_BULK section for more information.When the quota of a subscriber is depleted, the SCE platform issues an indication that is distributed to the registered listener by activating a
quotaDepletedIndication
callback function.public void quotaDepletedIndication(String subscriberID, Quota quota)
subscriberID
—The unique ID of the subscriber. See Subscriber ID section for more information.
quota
—Quota of the subscriber. See the Subscriber Quota section for more information.When the quota of a group of subscribers is depleted, the SCE platform issues an indication that is distributed to the registered listener by activating a
quotaDepletedBulkIndication
callback function.public void quotaDepletedBulkIndication (SubscriberID_BULK subs)
subs
—Contains names of the subscribers whose quota was depleted. See the SubscriberID_BULK section for more information.When a subscriber logs in to the policy server, the policy server performs a login operation to the SCE. The SCE issues a request to the policy server to restore the subscriber quota in the SCE by activating a
quotaStateRestore
callback function. The policy server should respond to this function with a Quota Update Event.public void quotaStateRestore(String subscriberID, Quota quota)
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for more information.
quota
—Quota of the subscriber. See the Subscriber Quota section for more information. The bucket IDs array is of size 0 because when this indication is created all the quota buckets are empty.When a group of subscribers log in to the policy server, the policy server performs a login operation to the SCE. The SCE issues a request to the policy server to restore the subscriber quota in the SCE by activating a
quotaStateBulkRestore
callback function. The policy server should respond to this function with a Quota Update Event.public void quotaStateBulkRestore(SubscriberID_BULK subs)
subs
—Contains names of the subscribers whose quota was depleted. See the SubscriberID_BULK section for more information.
The SCMS SCE Subscriber API monitors the connection to the SCE platform. A Policy Server requesting to perform certain operations on connection establishment or disconnection from the SCE can implement a ConnectionListener interface.
The API allows setting a connection listener.
setConnectionListener(ConnectionListener listener)
The connection listener is an interface that is defined as follows:
public interface ConnectionListener { /** * called when the connection with the SCE is down. */ public void connectionIsDown(); /** * called when the connection with the SCE is established. */ public void connectionEstablished(); }The connection establishment callback is used to start the SCE synchronization. See the SCE-API Synchronization section for more information.
The following example is a simple implementation of a disconnect listener that prints a message to stdout
and returns.
import com.scms.api.sce.ConnectionListener;
public class MyConnectionListener implements ConnectionListener {
public void connectionIsDown(){
System.out.println(“Message: connection is down.”);
return;
}
public void connectionEstablished(){
System.out.println(“Message: connection is established.”);
// activate thread that starts SCE synchronization
}
}
The API enables setting a result handler for every operation allowing handling operations results in a different manner.
The OperationResultHandler interface's handleOperationResult callback is called when a result of an operation, which ran on the SCE, returns to the API.
If no result handling is required for a specific operation, insert null in the handler argument.
The same operation result handler can be passed to all operations.
This interface is implemented to receive results of operations performed through the API.
The operation result handler is called with the following single method:
public interface OperationResultHandler {
/**
* handle a result
*/
public void handleOperationResult(Object[] result,
OperationArguments handback);
}
You should implement this interface if you want to be informed about the results of operations performed through the API.
The OperationResultHandler interface is the only way to retrieve results. The results cannot be returned immediately after the API method has returned to the caller. To enable to receive operation results, set the result handler of each operation at the time of the operation call (as displayed in the examples).
The following is the data returned from the OperationResultHandler interface:
result—The actual result of the operation - each entry within the array can be one of the following:
NULL—indicates success
of the operation.
OperationException—indicates operation failure (see below).
For non-bulk operations, the result array will have only one entry. For bulk operations, each entry of the result array corresponds to the relevant entry in the bulk operation.
handback—The API automatically provides this object to every operation call. It contains the information about the operation that was called, including all arguments that were passed at the time of the call. The input arguments of the operation are retrieved by the argument name in the API documentation. For example, this data can be used to inspect/output the parameters after the operation failed or to repeat the operation call.
In operations involving bulk objects, even if the operation fails for any specific element in the bulk, the processing of the bulk will continue until the end of the bulk.
Use the following methods to retrieve the operation name:
public String getOperationName()Use the following methods to retrieve the arguments names:
public String[] getArgumentNames()
Use the following method to retrieve the specific operation argument. Use the operation's arguments' names from the operation signature as an argument:
public Object getArgument(String name)
Sample implementation of the OperationResultHandler interface:
public class MyOperationHandler implements OperationResultHandler
{
long sucessCounter = 0;
long errorCounter = 0;
public void handleOperationResult(Object[] result,
OperationArguments handback)
{
for (int index=0; index < result.length; index++)
{
if (result[index]==null)
{
// success
successCounter++;
}
else
{
// failure
errorCounter++;
// Extract error details
OperationException ex = (OperationException)result[index];
// Extract operation name
String operationName = handback.getOperationName();
// Print operation name and error message
System.out.println(“Error for operation ”+
operationName +”:” +
ex.getErrorMessage());
// Print operation arguments
String[] argNames = handback.getArgumentNames();
if (argNames!=null)
{
for (int j=0; j<argNames.length; j++)
{
System.out.println(argNames[j]+ ”=“+
handback.getArgument(argNames[j]));
}
}
}
}
}
}Note
The above sample implementation can be used for both regular and bulk operations.
The following example demonstrates login operation sample result handler:
public class LoginOperationHandler implements OperationResultHandler
{
public void handleOperationResult(Object[] result,
OperationArguments handback)
{
for (int index=0; index < result.length; index++)
{
if (result[index]!=null)
{
// failure
// Extract error details
OperationException ex =
(OperationException)result[index];
// Print operation name and error message
System.out.println(“Error for login operation ”+
”:” + ex.getErrorMessage());
// Print subscriber ID parameter value
System.out.println(“subscriberID”+
handback.getArgument(“subscriberID”));
}
}
}
}
The com.scms.api.sce.OperationException
Java class provides all of the functional errors of the SCMS SCE Subscriber API, which is contrary to the normal Java usage. This “contrary” approach was chosen because of the required “cross-language and cross-protocol” nature of the SCMS SCE Subscriber API, which should allow all future SCE API implementations to appear the same (Java, C, C++).
Each OperationException exception provides the following information:
A unique error code (long
)
An informative message (java.lang.String
)
A server-side stack trace (java.lang.String
)
See the List of Error Codes for more details about error codes and their meaning.
This section lists the methods of the API that can be used for Subscriber Provisioning purposes. The signature of each method is followed by a description of its input parameters and its return values.
All the methods return a java.lang.IllegalStateException
when called before a connection with the SCE is established.
void login(String subscriberID,
NetworkID networkID,
boolean networkIdAdditive,
PolicyProfile policy,
QuotaOperation quotaOperation,
OperationResultHandler handler) throws Exception
This operation adds or updates the subscriber to the SCE. The operation is performed according to the following algorithm:
If the subscriber ID does not exists in the SCE, a new subscriber is added with all the data supplied
If the subscriber ID exists:
If the networkIdAdditive flag is set to TRUE, the supplied NetworkID is added to the existing networkIDs of the subscriber. Otherwise, the supplied networkID replaces the existing networkIDs.
policy—Policy is updated with the new policy values. Subscriber Policy entries that are not provided within the PolicyProfile remain unchanged or created with default values.
quota—The quota is updated according to the bucket values and the operations provided (see the Subscriber Quota section )
If there is a networkID congestion with another subscriber, the networkID of the other subscriber is logged out implicitly and the new subscriber is logged in.
For relevant events description, see the Push Model section in the API Events chapter.
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
networkID
—The network identifier or identifiers of the subscriber. See the Network ID Mappings section for more information.
networkIDAdditive
—If this flag is set to TRUE, the supplied NetworkID is added to the existing networkIDs of the subscriber. Otherwise, the supplied networkID replaces the existing networkIDs.
policy
—Policy profile of the subscriber. See the SCA BB Subscriber Policy Profile section for more information.
quota
—Quota of the subscriber. See the Subscriber Quota section for more information.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_RESOURCE_SHORTAGE
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
To add the IP address 192.168.12.5 to an existing subscriber named john without affecting any existing mappings:
login(
“john”, // subscriber name
new NetworkID(new String[]{“192.168.12.5”},
SCESubscriberApi.ALL_IP_MAPPINGS),
true, // isMappingAdditive is true
null, // no policy
null); // no quota
To add the IP address 192.168.12.5 overriding previous mappings:
login(
“john”, // subscriber name
new NetworkID(new String[]{“192.168.12.5”},
SCESubscriberApi.ALL_IP_MAPPINGS),
false, // isMappingAdditive is false
null, // no policy
null); // no quota
For more examples, see the Login and Logout section.
This operation applies the logic described in the login operation for each subscriber in the bulk.
subsBulk
—See the Login_BULK Class section.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_RESOURCE_SHORTAGE
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
void loginPullResponse(String anonymousSubscriberID,
String subscriberID,
NetworkID networkID,
PolicyProfile policy,
QuotaOperation quota,
OperationResultHandler handler) throws Exception
This operation sends subscriber login information to the SCE as a response to a loginPullRequest
call from the SCE or a loginPullBulkRequest
.
For relevant events description, see the Pull model section in the API Events chapter.
anonymousSubscriberID
—The identifier of the anonymous subscriber. This is sent by the SCE within the loginPullRequest/loginPullBulkRequest indication. See the Anonymous Subscriber ID section for more information.
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
networkID
—The network identifier of the subscriber. See the Network ID Mappings section for more information. This must include the network ID received by the loginPullRequest. If this subscriber in the SCE already has other network IDs, this network ID is added to the existing ones.
policy
—Policy profile of the subscriber. See the SCA BB Subscriber Policy Profile section for more information.
quota
—Quota of the subscriber. See the Subscriber Quota section for more information.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_RESOURCE_SHORTAGE
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
void loginPullResponseBulk(LoginPullResponse_BULK subsBulk,
OperationResultHandler handler) throws Exception
This operation applies the logic described in loginPullResponse operation for each subscriber in the bulk.
For relevant events description, see the Pull model section in the API Events chapter.
subsBulk
—See the LoginPullResponse_BULK section.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_RESOURCE_SHORTAGE
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
void logout(String subscriberID,
NetworkID networkID,
OperationResultHandler handler) throws Exception
This operation removes the specified networkID of the subscriber from the SCE. If this is the last networkID of the specified subscriber, the subscriber is removed from the SCE. If no subscriber ID is specified, the supplied network ID is removed from the SCE regardless to which subscriber this network ID belongs. If no network ID is supplied, all Network IDs of this subscriber are removed.
If the subscriber record is not in the SCE, the logout operation will succeed.
For relevant events description, see the Logout Events section in the API Events chapter.
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
networkID
—The network identifier of the subscriber. See the Network ID Mappings section for more information.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_OPERATION_ABORTED
For a description of error codes, see List of Error Codes.
void logoutBulk(NetworkAndSubscriberID_BULK subsBulk,
OperationResultHandler handler) throws Exception
This operation applies the logic described in logout operation for each subscriber in the bulk.
For relevant events description, see the Logout Events section in the API Events chapter.
subsBulk
—See the NetworkAndubscriberID_BULK section.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_OPERATION_ABORTED
For a description of error codes, see List of Error Codes.
void networkIDUpdate(String subscriberID,
NetworkID networkID,
boolean networkIdAdditive,
OperationResultHandler handler) throws Exception
This operation adds or replaces an existing subscriber's network ID.
This operation is effective only if the subscriber record exists in the SCE. Otherwise, the operation will fail.
For relevant events description see the Network ID Update Event section in the API Events chapter.
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
networkID
—The network identifier of the subscriber. See the Network ID Mappings section for more information.
networkIDAdditive
—If this flag is set to TRUE, the supplied NetworkID is added to the existing networkIDs of the subscriber. Otherwise, the supplied networkID replaces the existing networkIDs.
The following is the list of error codes that this method might return:
ERROR_CODE_SUBSCRIBER_NOT_EXIST
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_RESOURCE_SHORTAGE
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
void networkIDUpdateBulk(NetworkAndSubscriberID_BULK subsBulk,
OperationResultHandler handler) throws Exception
This operation applies the logic described in networkIDUpdate operation for each subscriber in the bulk.
For relevant events description, see the Network ID Update Event section in the API Events chapter.
subsBulk
—See NetworkAndSubscriberID_BULK section.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_SUBSCRIBER_NOT_EXIST
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_RESOURCE_SHORTAGE
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
void profileUpdate(String subscriberID,
PolicyProfile policy,
OperationResultHandler handler) throws Exception
This operation modifies an existing subscriber's policy profile. If the subscriber record does not exist in the SCE, this operation will fail.
For relevant events description, see the Profile Update Event in the API Events chapter.
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
policy
—Policy profile of the subscriber. See the SCA BB Subscriber Policy Profile section for more information.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_SUBSCRIBER_NOT_EXIST
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
void profileUpdateBulk(PolicyProfile_BULK subsBulk,
OperationResultHandler handler) throws Exception
This operation applies the logic described in profileUpdate operation for each subscriber in the bulk.
For relevant events description, see the Profile Update Event in the API Events chapter.
subsBulk
—See the PolicyProfile_BULK section.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_SUBSCRIBER_NOT_EXIST
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
void quotaUpdate(String subscriberID,
QuotaOperation quotaOperation,
OperationResultHandler handler) throws Exception
This operation performs an operation of updating the subscriber's quota.
For relevant event description, see Quota Update Event in the API Events section.
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
quotaOperations
—Quota operation to perform on the quota of the subscriber. See the Subscriber Quota section for more information.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_SUBSCRIBER_NOT_EXIST
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
void quotaUpdateBulk(QuotaOperation_BULK subsBulk,
OperationResultHandler handler) throws Exception
This operation applied the logic of the quotaUpdate operation on each subscriber in the bulk.
For relevant events description, see the Quota Update Event in the API Events section.
subsBulk
—See the QuotaOperation_BULK section.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_SUBSCRIBER_NOT_EXIST
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
void getQuotaStatus(String subscriberID,
Quota quota,
OperationResultHandler handler) throws Exception
This operation places the request to query the current remaining quota amount of the specified set of quota buckets. The getQuotaStatusIndication including the queried data follows this request (asynchronously).
For relevant events description, see the Get Quota Status Event section in the API Events section.
subscriberID
—The unique ID of the subscriber. See the Subscriber ID section for the subscriber ID format description.
quota
—Should include the list of the names (without values) of the quota buckets to retrieve. See the Subscriber Quota section for more information about how to construct quota with buckets' names only.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_SUBSCRIBER_NOT_EXIST
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
This method is a bulk version of the getQuotaStatus method described above.
For relevant events description, see the Get Quota Status Event section in the API Events section.
subsBulk
—See the Quota_BULK section.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
The following is the list of error codes that this method might return:
ERROR_CODE_SUBSCRIBER_NOT_EXIST
ERROR_CODE_FATAL_EXCEPTION
ERROR_CODE_OPERATION_ABORTED
ERROR_CODE_INVALID_PARAMETER
ERROR_CODE_NO_APPLICATION_INSTALLED
For a description of error codes, see List of Error Codes.
In cases when the SCE and the Policy Server have a conflict in the data about a subscriber because of disconnection, loss of logon messages, or reboot, several problems can arise. These problems can cause a misclassification of one the subscriber's traffic as if it was another subscriber, enforcement of the wrong service on the subscriber's traffic, or loss of resources.
It is possible to prevent such conflicts by keeping the communication channels as reliable as possible by performing synchronization of the subscribers' data between the SCE and the Policy Server using the API. The Policy Server, by using the API, is always the initiator of the synchronization.
Performing the synchronization process from several Policy Servers at the same time will cause the subscriber information in the SCE to be inconsistent with all servers.
The following list describes the synchronization guidelines the Policy Server must adhere while implementing synchronization:
Step 1: The Policy Server indicates to the SCE that it is starting to synchronize the SCE.
Step 2: The Policy Server logs-in all of the subscribers the SCE should handle. Preferably, the login operations are performed in bulks.
Step 3: The Policy Server notifies the SCE that the synchronization has ended.
Step 4: The SCE removes all of the subscriber data that was not part of the synchronization process.
During the synchronization process, the regular logon operations can be performed.
The following sections describe the methods provided for use for the synchronization procedure in the push model.
Use this operation in the push model only to signal the SCE that synchronization with the server is about to begin. The SCE marks all of the subscriber data with a “dirty-bit”, which is reset if this data is re-applied as part of the synchronization process. Every call to this method restarts the synchronization process.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
Use this operation in the push model only to signal the SCE that synchronization with the server has ended. The SCE scans the entire subscriber database for data with the “dirty-bit” assigned at SynchronizePushStart and removes it.
success
—A flag indicating that the synchronization was successful to the SCE.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
Step 1: The Policy Server indicates to the SCE that it is starting to synchronize the SCE
Step 2: The Policy Server retrieves from the SCE all of the subscribers IDs and network-IDs it is currently handling
Step 3: The Policy Server fixes any miss-synchronization.
Algorithm:
Use the following algorithm template when planning the synchronization procedure:
For each retrieved subscriber (<SubscriberID, IP address>):
If < SubscriberID, IP address > exists in Policy Server database,
send a policy profile and networkID update to the SCE
Otherwise,
send a logout with the Subscriber IP to the SCE
Steps 2 and 3 are performed as a bulk at one time.
During the synchronization process, the regular logon operations can be performed.
The following sections describe the methods provided for use for the synchronization procedure in the pull model.
Use this operation in the pull model only to signal the SCE that synchronization with the server should be started.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
Use this operation in the pull model only to signal the SCE that synchronization with the server has ended.
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
success
—A flag to the SCE indicating that the synchronization was successful.
void getSubscribersBulk(int bulkSize, SubscribersBulkResponseIterator iterator, OperationResultHandler handler)
Use this operation in the pull model synchronization process to retrieve a bulk of subscribers the SCE is currently handling (see Pull Model Synchronization Procedure section).
Upon receiving this request (getSubscribersBulk
), the SCE issues asynchronously the getSubscribersBulkResponse
indication containing subscriberIDs and corresponding NetworkIDs (see the LoginPullListener Interface Class section). This method supplies an iterator that is passed to the next call of getSubscribersBulk
. To signal the end of iterations, the iterator of the last bulk is null.
bulkSize
—The size of the bulk to retrieve. Maximum bulk size is limited to 100 entries.
iterator
—Iterator of the subscribers at the SCE side. This iterator is received in getSubscribersBulkResponseIndication and it should be passed to the next call to getSubscribersBulk method. When calling the getSubscribersBulk method for the first time, use null
as an iterator (using null
indicates that you want to start from the beginning).
handler
—Result handler for this operation. See the Result Handling section for a description of the OperationResultHandler interface.
High availability support provided by the API assumes that the high-availability scheme of the policy server is a type of two-node cluster where only one server is active at every given time. The other server (standby) is not connected to the SCE.
When the active server fails, it is the responsibility of the user's two-node cluster scheme to perform a fail-over to the standby server.
High-availability can be implemented separately for every policy server provisioning the SCE platform at the same time.
To implement high-availability with the SCMS SCE Subscriber API:
Set up a two-node cluster for two policy servers
Construct two API instances with the same API name each one on the different server (node) within the cluster (For constructors description, see the API Construction section). During cluster runtime, only one API instance should be connected to the SCE platform. When a fail-over occurs, the failed server should disconnect from the SCE and the standby server should become active and re-connect to the SCE within the pre-defined timeout (see the SCE Platform Setup section). Because of identical API names, the SCE will behave as if the same API was re-connected and no information will be lost.
Do not call the unregisterXXXListener
methods implicitly in the API used on the failed policy server as this will cause the loss of data. Calling the disconnect()
method does not unregister the listeners.
This section gives several code examples for the API usage:
The following example logs in a predefined number of subscribers to the SCE, and then logs them out. This example uses auto-reconnect support; therefore, it does not define a connection listener.
The following code outline contains a sample implementation of a result handler that counts success and failure results:
// Class responsible for operations result handling
import com.scms.api.sce.OperationArguments;
import com.scms.api.sce.OperationException;
import com.scms.api.sce.OperationResultHandler;
public class MyOperationResultHandler implements OperationResultHandler
{
long count = 0;
public void handleOperationResult(Object[] result,
OperationArguments handback)
{
for (int index=0; index < result.length; index++)
{
count++;
if (result[index]==null)
{
//print success every 100 operations
//if (++count%100 == 0)
{
System.out.println("\tsuccess "+count);
}
}
else // error - print every error
{
// failure
count++;
// Extract error details
OperationException ex =
(OperationException)result[index];
// Extract operation name
String operationName = handback.getOperationName();
// Print operation name and error message
System.out.println("Error for operation "+
operationName+": "+
ex.getMessage());
}
}
}
public synchronized void waitForLastResult(int lastResult)
{
while (count<lastResult)
{
try
{
wait(100);
}
catch (InterruptedException ie)
{
ie.printStackTrace();
}
}
}
}
Class that contains simple LogoutListener implementation that counts the number of received logout indications:
import com.scms.api.sce.LogoutListener;
import com.scms.common.NetworkAndSubscriberID_BULK;
import com.scms.common.SubscriberID_BULK;
class MyLogoutListener implements LogoutListener
{
long count = 0;
public void logoutIndication(String subscriberID)
{
increaseCounter(1);
}
synchronized void increaseCounter(long value)
{
count = count + value;
}
synchronized long getCounter()
{
return count;
}
//waits for result number 'last result' to arrive
public synchronized void waitForLastResult(int lastResult)
{
while (count<lastResult)
{
try
{
wait(100);
}
catch (InterruptedException ie)
{
ie.printStackTrace();
}
}
}
public void logoutBulkIndication(SubscriberID_BULK subs)
{
increaseCounter(subs.getSize());
}
}
Class that contains the main
method:
import com.scms.api.sce.prpc.PRPC_SCESubscriberApi;
import com.scms.common.*;
public class LogonPolicyServer {
public static void main (String args[]) throws Exception
{
int numSubscribersToLogin = 500;
//instantiate an API with reconnect interval of 5 seconds
PRPC_SCESubscriberApi api = new PRPC_SCESubscriberApi(
"myAPI",
args[0], // IP of the SCE
5000);
try {
// instantiate operation result handler
// we will use one handler for all operations
MyOperationResultHandler resultHandler =
new MyOperationResultHandler();
// instantiate logout listener
MyLogoutListener listener = new MyLogoutListener();
// register to logout indications
api.registerLogoutListener(listener);
// connect to the SCE
api.connect();
//login
System.out.println("login of "+numSubscribersToLogin+
" subscribers");
PolicyProfile pp = new PolicyProfile(
new String[]{"packageId=1",
"monitor=1"});
for (int i=0; i<numSubscribersToLogin; i++)
{
api.login("sub"+i,
new NetworkID(getMappings(i), // generate ip
NetworkID.ALL_IP_MAPPINGS),
true, // additive flag
pp, // policy
null, // no quota
resultHandler);
}
// wait for subscribers to log in
resultHandler.waitForLastResult(numSubscribersToLogin);
//logout all subscribers
System.out.println("logout of "+numSubscribersToLogin+
" subscribers");
for (int i=0; i<numSubscribersToLogin; i++)
{
NetworkID nid = new NetworkID(getMappings(i),
NetworkID.ALL_IP_MAPPINGS);
api.logout("sub"+i,nid,resultHandler);
}
// wait for all subscribers to be logged out -
//but this time use
//logout listener to count the results
listener.waitForLastResult(numSubscribersToLogin);
}
finally
{
api.unregisterLogoutListener
api.disconnect();
}
}
//'automatic' mapping generator for the sample program
private static String[] getMappings(int i) {
return new String[]{ "10." +((int)i/65536)%256 + "." +
((int)(i/256))%256 + "." + (i%256)};
}
}
The following code fragment demonstrates a login-pull request and login-pull response manipulations:
This class is a sample implementation of the listener for the logout and login pull indications:
import java.util.Iterator;
// result handler from the previous example
import MyOperationResultHandler;
import com.scms.api.sce.*;
import com.scms.common.*;
class MyListener implements LoginPullListener, LogoutListener
{
// indications counters
long logoutCount = 0;
long pullCount=0;
// api instance – used to send login-pull responses to the SCE
PRPC_SCESubscriberApi api = null;
// construct operation handler -
// from previous (Login and Logout) example
MyOperationResultHandler h = new MyOperationResultHandler();
public MyListener(PRPC_SCESubscriberApi api)
{
this.api = api;
}
// Increase logout counter
public void logoutIndication(String subscriberID)
{
increaseLogoutCounter(1);
System.out.println("Got logout notification " +
getLogoutCounter());
}
// Increase logout counter
public void logoutBulkIndication(SubscriberID BULK subs)
{
System.out.println("Got logout notification");
increaseLogoutCounter(subs.getSize());
}
public void loginPullRequest (String anonymousSubscriberID,
NetworkID networkID)
{
try
{
increasePullCounter(1);
System.out.println("Got pull request" + getPullCounter());
// prepare policy
PolicyProfile pp = new PolicyProfile(
new String[]{"packageId=1",
"monitor=1"});
// Answer with pull response
// retrieve subscriber name – for example from your
// policy server database
// In this example we use fixed names based on the
// subscribers counter
api.loginPullResponse(anonymousSubscriberID,
"sub"+getPullCounter(),
networkID,
pp, // policy
null, // no quota
h); // handler from previous example
}
catch (Exception ex)
{
System.out.println(ex.getMessage());
}
}
public void loginPullRequestBulk(NetworkAndSubscriberID BULKsubs)
{
try
{
increasePullCounter(subs.getSize());
System.out.println("Got pull request" + getPullCounter());
// Answer with pull response in bulk form
PolicyProfile pp = new PolicyProfile(
new String[]{"packageId=1",
"monitor=1"});
LoginPullResponse_BULK responseBulk =
new LoginPullResponse_BULK();
Iterator subsIterator = subs.getIterator();
// iterate of the received bulk (IPs and anonymous IDs)
// and build a response bulk
int count=0;
while(subsIterator.hasNext())
{
// retrieve subscriber name – for example from your
// policy server database
// In this example we use fixed names based on the
// subscribers counter
String subName = "sub_"+count;
SubscriberData sub = (SubscriberData)subsIterator.next();
// Extract subscriber mappings from the bulk and
// constract a new NetworkID based on those mappings
NetworkID subNetId = new NetworkID(sub.getMappings(),
NetworkID.ALL_IP_MAPPINGS);
responseBulk.addEntry(sub.getAnonymousSubscriberID(),
subName,
subNetId,
true,
pp,
null);
count++;
}
//use the bulk constructed above in the bulk response
//use handler from the previous example
api.loginPullBulkResponse(responseBulk,h);
}
catch (Exception ex)
{
System.out.println(ex.getMessage());
}
}
public void getSubscribersBulkResponse(
NetworkAndSubscriberID BULK subs,
SubscruberBulkResponseIterator iterator)
{
//not implemented in this example
}
synchronized void increaseLogoutCounter(long value)
{
logoutCount = logoutCount + value;
}
synchronized void increasePullCounter(long value)
{
pullCount = pullCount + value;
}
synchronized long getPullCounter()
{
return pullCount;
}
synchronized long getLogoutCounter()
{
return logoutCount;
}
//waits for result number 'last result' to arrive
public synchronized void waitForPullResult(int lastResult) {
while (pullCount<lastResult) {
try {
wait(100);
} catch (InterruptedException ie) {
ie.printStackTrace();
}
}
}
public synchronized void waitForLogoutResult(int lastResult) {
while (logoutCount<lastResult) {
try {
wait(100);
} catch (catch (InterruptedException ie) {
ie.printStackTrace();
}
}
}
}
Class that contains the main
method:
import java.util.Iterator;
import com.scms.api.sce.*;
import com.scms.common.*;
public class LogonPolicyServer {
static PRPC_SCESubscriberApi api = null;
// This sample program waits for pull requests from the SCE
// and answers to them with pull response
// The program exists after all 500 were logged in
public static void main (String args[]) throws Exception
{
int numSubscribersToLogin = 500;
//instantiate an API with reconnect interval of 5 seconds
api = new PRPC_SCESubscriberApi("myAPI","1.1.1.1",5000);
// construct an operation result handler (from the
// previous example
MyOperationResultHandler handler =
new MyOperationResultHandler();
// instantiate logout and login-pull listener
MyListener listener = new MyListener(api);
try
{
// register to logout indications
api.registerLogoutListener(listener);
api.registerLoginPullListener(listener);
// connect to the SCE
api.connect();
// wait for login-pull requests from the SCE
// they will be issued if you have traffic for unknown
// subscribers at the SCE
System.out.println("Waiting for pull requests for "+
numSubscribersToLogin+
" subscribers");
// wait for all subscribers to be logged in
listener.waitForPullResult(numSubscribersToLogin);
//logout all subscribers
System.out.println("logout of "+numSubscribersToLogin+
" subscribers");
for (int i=0; i<numSubscribersToLogin; i++)
{
api.logout("sub"+i,null,handler);
}
// wait for all subscribers to be logged out
listener.waitForLogoutResult(numSubscribersToLogin);
}
finally
{
api.unregisterLoginPullListener();
api.unregisterLogoutListener();
api.disconnect();
}
}
}
This chapter describes the usage of the API logging abilities for troubleshooting the integration with the API. API logging enables the user to monitor the operations being called including the received parameters both at the API client and at the SCE side.
The SCE platform provides the ability to log all of the operations called by the Policy Server into the SCE user-log file.
The SCE issues the following messages by default without any further configuration:
For connect operation:
<client-name> - connect operation was called, registered listeners: <type of the listeners that were registered>
For disconnect operation:
<client-name> - disconnected
For registerLoginPullListener operation:
<client-name> - registered a Login Pull Listener
For unregisterPullListener operation:
<client-name> - unregistered a Pull Listener
For registerLogoutListener operation:
<client-name> - registered a Logout Listener
For unregisterLogoutListener operation:
<client-name> - unregistered a Logout Listener
For registerQuotaListener operation:
<client-name> - registered Quota Listener
For unregisterQuotaListener operation:
<client-name> - unregister Quota Listener
For synchronizePushStart operation:
<client-name> - synchronize Push Start
For synchronizePushEnd operation:
<client-name> - synchronize Push End
For synchronizePullStart operation:
<client-name> - synchronize Pull Start
For synchronizePullEnd operation:
<client-name> - synchronize Pull End
A special flag activates subscriber operation log messages. To receive these messages, enable the flag.
To enable logging, use the following CLI at the SCE platform:
(config)# management-agent sce-api logging
To view the USERLOG file, use the following CLI at the SCE platform:
#
>logger get user-log <FILE NAME>
Enabling logging causes performance degradation. Therefore, it is advisable to use logging only for troubleshooting purposes.
To disable logging, use the following CLI at the SCE platform:
(config)#
> no management-agent sce-api logging
To view whether the logging is enabled, use the following CLI at the SCE platform:
#
> show management-agent sce-api
When the logging flag is enabled, the message below is issued for the following operations:
login operation
networkIDUpdate operation
logout operation
quotaUpdate operation
loginPullResponse operation
profileUpdate operation
getQuotaStatus operation
<operation name> operation was called
with parameters:
subscriberID -
<subscriber ID> anonymousSubscriberID - < anonymousSubscriberID >
mappings -
<mappings list>
mappings types -
<mapping types list>
policy -
<policy properties list>
quota -
<quota operation/quota buckets list>
For the following bulk operations:
loginBulk operation
networkIDUpdateBulk operation
logoutBulk operation
quotaUpdateBulk operation
loginPullBulkResponse operation
profileUpdateBulk operation
getQuotaStatuBulkRequest operation
getSubscribersBulk
The following message is issued:
<operation name> operation was called with parameters:
bulk size -
<bulk size>
The following messages are issued for the LoginPullListener:
For loginPullRequest:
loginPullRequest operation was called with parameters:
anonymousSubscriberID -
<anonymous subscriber ID>
mappings -
<mappings list>
mapping types -
<mapping types>
For loginPullRequestBulk:
loginPullRequestBulk operation was called with parameters:
bulk size -
<bulk size>
getSubscribersBulkResponse
getSubscribersBulkResponse operation was called with parameters:
bulk size -
<bulk size>
The following messages are issued for the LogoutListener:
For logoutIndication:
logoutIndication operation was called with parameters:
subscriberID -
<anonymous subscriber ID>
For logoutBulkIndication:
logoutBulkIndication operation was called with parameters:
bulk size -
<bulk size>
The following messages are issued for the QuotaListenerEx:
For quotaStatusIndication:
quotaStatusIndication operation was called with parameters:
subscriberID -
<Subscriber ID>
quota -
<subscriber quota>
For quotaBelowThresholdIndication:
quotaBelowThresholdIndication operation was called with parameters:
subscriberID -
<Subscriber ID>
quota -
<subscriber quota>
For quotaDepletedIndication:
quotaDepletedIndication operation was called with parameters:
subscriberID -
<Subscriber ID>
quota -
<subscriber quota>
For quotaStateRestore:
quotaStateRestore operation was called with parameters:
subscriberID -
<Subscriber ID>
quota -
<subscriber quota>
For quotaStatusBulkIndication:
quotaStatusBulkIndication operation was called with parameters:
subs -
<bulk size>
For quotaBelowThresholdBulkIndication:
quotaBelowThresholdBulkIndication operation was called with parameters:
subs -
<bulk size>
For quotaDepletedBulkIndication:
quotaDepletedBulkIndication operation was called with parameters:
subs -
<bulk size>
For quotaStateBulkRestore:
quotaStateBulkRestore operation was called with parameters:
subs -
<bulk size>
The API provides the ability to log every activated operation into the apilog file located under ${user.home} directory. The logging parameters are configured using the Log4J properties files. To enable the logging make sure this file is in the application's CLASSPATH. This file is read at startup of the application so after changing it you must restart the application.
The following is the content of the log4.properies
file:
# default Log4j configuration for SCE Subscriber API
log4j.rootCategory=INFO, apiStdout
# In order to enable the logging to the file Replace the above
# line with the following:
# log4j.rootCategory=INFO, files
# stdout is set to be a ConsoleAppender.
log4j.appender.apiStdout=org.apache.log4j.ConsoleAppender
log4j.appender.apiStdout.layout=org.apache.log4j.PatternLayout
log4j.appender.apiStdout.layout.ConversionPattern=+ %d{dd-MMM HH:mm:ss.SSS} [%t] %-5p %c%n%m%n
# files is set to be a RollingFileAppender.
#log4j.appender.files=org.apache.log4j.RollingFileAppender
#log4j.appender.files.layout=org.apache.log4j.PatternLayout
#log4j.appender.files.layout.ConversionPattern=+ %d{dd-MMM yyyy HH:mm:ss.SSS} [%t] %-5p %c %x\n%m\n
#log4j.appender.files.File=${user.home}/apilog
#log4j.appender.files.Threshold=INFO
#log4j.appender.files.ImmediateFlush=true
#log4j.appender.files.MaxFileSize=1MB
#log4j.appender.files.MaxBackupIndex=4
# In order to enable debug logging uncomment the following line
#log4j.category.com.scms.api.sce.prpc=DEBUG
To enable the debug logging, uncomment the last line in the file. By default, the logging is performed to the standard output. To direct the logging to the file, uncomment the # log4j.rootCategory=INFO, files line as explained in the file.
The API client issues the following messages after properly configuring the log4j.properties
file:
For API constructor:
"PRPC_SCESubscriberApi constructor was called with the following parameters:
apiName -
<apiName>
host -
<sceHost>
port -
<scePort>
auto-reconnect -
<autoReconnectInterval>
For init operation:
init operation was called with parameters
<properties>
For setConnectionListener:
setConnectionListener operation was called
For isConnected:
is
Connected operation was called
For getAPIVersion:
getAPIVersion operation was called
For the following operations:
login operation
networkIDUpdate operation
logout operation
quotaUpdate operation
loginPullResponse operation
profileUpdate operation
getQuotaStatus operation
The following message is issued:
<operation name> operation was called with parameters:
subscriberID -
<subscriber ID>
anonymousSubscriberID -
< anonymousSubscriberID >
mappings -
<mappings list>
mappings types -
<mapping types list>
policy -
<policy properties list>
quota -
<quota operation/quota buckets list>
For the following bulk operations:
loginBulk operation
networkIDUpdateBulk operation
logoutBulk operation
quotaUpdateBulk operation
loginPullBulkResponse operation
profileUpdateBulk operation
getQuotaStatuBulkRequest operation
getSubscribersBulk operation
The following message is issued:
<operation name> operation was called with parameters:
bulk size -
<bulk size>
For connect operation:
connect operation was called, registered listeners:
<type of the listeners that were registered>
For disconnect operation:
disconnect operation was called
For registerLoginPullListener operation:
registerLoginPullListener operation was called
For unregisterPullListener operation:
unregisterPullListener operation was called
For registerLogoutListener operation:
registerLogoutListener operation was called
For unregisterLogoutListener operation:
unregisterLogoutListener operation was called
For registerQuotaListener operation:
registerQuotaListener operation was called
For unregisterQuotaListener operation:
unregisterQuotaListener operation was called
For synchronizePushStart operation:
synchronizePushStart operation was called
For synchronizePushEnd operation:
synchronizePushEnd operation was called
For synchronizePullStart operation:
synchronizePullStart operation was called
For synchronizePullEnd operation:
synchronizePullEnd operation was called
The following messages are issued for the LoginPullListener listener callback methods:
For loginPullRequest:
loginPullRequest operation was called with parameters:
anonymousSubscriberID -
<anonymous subscriber ID>
mappings -
<mappings list>
mapping types -
<mapping types>
For loginPullRequestBulk:
loginPullRequestBulk operation was called with parameters:
bulk size -
<bulk size>
getSubscribersBulkResponse
getSubscribersBulkResponse operation was called with parameters:
bulk size -
<bulk size>
The following messages are issued for the LogoutListener listener callback methods:
For logoutIndication:
logoutIndication operation was called with parameters:
subscriberID -
<anonymous subscriber ID>
For logoutBulkIndication:
logoutBulkIndication operation was called with parameters:
bulk size -
<bulk size>
The following messages are issued for the QuotaListenerEx listener callback methods:
For quotaStatusIndication:
q
uotaStatusIndication operation was called with parameters:
subscriberID -
<Subscriber ID>
quota -
<subscriber quota>
For quotaBelowThresholdIndication:
quotaBelowThresholdIndication operation was called with parameters:
subscriberID -
<Subscriber ID>
quota -
<subscriber quota>
For quotaDepletedIndication:
quotaDepletedIndication operation was called with parameters:
subscriberID -
<Subscriber ID>
quota -
<subscriber quota>
For quotaStateRestore:
quotaStateRestore operation was called with parameters:
subscriberID -
<Subscriber ID>
quota -
<subscriber quota>
For quotaStatusBulkIndication:
quotaStatusBulkIndication operation was called with parameters:
subs -
<bulk size>
For quotaBelowThresholdBulkIndication:
quotaBelowThresholdBulkIndication operation was called with parameters:
subs -
<bulk size>
For quotaDepletedBulkIndication:
quotaDepletedBulkIndication operation was called with parameters:
subs -
<bulk size>
For quotaStateBulkRestore:
quotaStateBulkRestore operation was called with parameters:
subs -
<bulk size>
Error codes are used for interpreting the actual error for which an OperationException
was returned. The error code is extracted using the getErrorCode
method.
A list of the error codes and their description are given in the following table.
Table A.1. List of Error Codes
Error Code |
Description |
---|---|
|
Application required for the operation execution is not installed |
|
One of the arguments provided to the method is illegal. |
|
The subscriber on which the operation was performed already exists in the SCE. |
|
The subscriber on which the operation is performed does not exist in the SCE . |
|
Too many errors occurred at the SCE when trying to perform the operation |
|
Internal error |
|
Internal error |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |
|
Internal error. |