2 Understanding the API Management Model

This chapter introduces the Oracle Communications Services Gatekeeper management model, lists the types of accounts and account states that it uses, and explains how these accounts relate to the PRM portals.

Understanding the Services Gatekeeper Management Model

The Services Gatekeeper management model defines roles for operators and application service providers, and defines the interactions between them. An operator runs the network in which Services Gatekeeper is installed. Operators have partners who provide one or more applications to interact with the operator's network. These partners are the application service providers and they can be in-house or external to the operator.

Operators manage application service provider accounts. An application service provider registers with Services Gatekeeper and is given a service provider account. To support tiering, service provider accounts are collected into Service Provider Account Groups. These groups that are associated with service level agreements (SLAs).

Service provider accounts include individual application accounts, registered on their respective service provider accounts. Like service provider accounts, application accounts are grouped into application account groups. Again, SLAs are associated with applications by using the application group.

Finally, the model also includes the idea of the application instance, which is tied to a specific instance of the application and is used in the traffic authentication process.

For more information on SLAs and accounts, see ”About Service Level Agreements and Accounts” in Services Gatekeeper Accounts and SLAs Guide.

The Partnership Management module allows for management of:

  • Service provider accounts

  • Application accounts

  • Application groups

  • Service provider SLAs:

    • Provisioned and enforced in one cluster

    • Provisioned and enforced across clusters (used for establishing geo-redundancy)

  • Service provider node SLAs

  • Application SLAs

    • Provisioned and enforced in one cluster

    • Provisioned and enforced across clusters (used for establishing geo-redundancy)

Account States

Service provider accounts and application accounts have one of these states:


    The service provider has requested that an account be registered, but the operator has not yet approved or disapproved it.


    The operator has approved the account the service provider registered.


    The account has been deactivated, either temporarily or as a step toward being deleted.


    The service provider has requested an update of the account, and this update has not yet been approved by the operator.


    The service provider or the operator has requested that the account be deleted. This is an intermediate state. The operator can, for example, use this state to process all charging data records for the account before deleting it.


    Charging data records may still be in the Services Gatekeeper, even when the account information is deleted. Make sure all data has been processed before deleting an account.

    Once an account is deleted, all data about the account is removed from the Services Gatekeeper.

The possible state transitions are outlined in Figure 2-1.

Figure 2-1 States and state transitions

Description of Figure 2-1 follows
Description of ''Figure 2-1 States and state transitions''

There are two sets of interfaces in the partner relationship module (PRM) module. The service provider interfaces give application service providers access to information relative to their own accounts and applications. The operator interfaces allow operators to manage their service providers. These include access to a much broader range of management functions.

In Figure 2-1, the method names in bold can be executed by both the operator and the application service provider. The non-bold methods names can only be executed by the operator. XXX indicates that the methods are valid for both service provider accounts and application accounts.

Administering PRM Administrative Users

You create and manage PRM administrative users in the same way as other Services Gatekeeper administrative users, using the Administration Console or the ManagementUserMBean. At least one PRM-OP user must be set up before the PRM interfaces can be used, and you are prompted to create this user during installation. For information on the ManagementUserMBean, see the ”All Classes” section of the Services Gatekeeper OAM Java API Reference. For more information on managing administrative users, see ”Managing Users and User Groups” in Services Gatekeeper System Administrator's Guide.

Table 2-1 describes the characteristics of an administrative user.

Table 2-1 Contents of wlng_mgmt_users Database Table

Field Type Description



Authentication name of the administrative user.



Possible values are:

  • 0: Activated

  • 1: Deactivated

Transitional states (Registered, Update pending, Delete pending) are stored temporarily as properties of the account.



Kind of user. Options are:

  • 0: OAM (Console-based user)

  • 1: PRM-OP (Operator using PRM)

  • 2: PRM-SP (Service Provider using PRM)



Administrative user password. 3DES Encrypted.



Privilege level of user. See Table 2-2 below for values.



Allows administrative us.ers to be grouped for ease of management




Table 2-2 Privilege Levels

Level Services Gatekeeper Role Type


Equivalent to Administrative Access on WebLogic Server (WLS). Can:

  • Manage servers and server configuration

  • Deploy applications

  • Control all Services Gatekeeper management functions


Equivalent to Deployer Access on WLS. Can:

  • View server configuration and make some changes

  • Have read/write access on Services Gatekeeper management functions


Equivalent to Monitor Access on WLS. Can

  • View server configuration

  • Have read-only access to Services Gatekeeper management functions


Equivalent to Anonymous Access on WLS. Can:

  • Use servers. PRM-SP users have this privilege level


Service providers may also have direct access to account management functions by using JMX if the service provider has appropriate user permissions. Operator make this decision.