This section outlines common use patterns using the Oracle Communications Services Gatekeeper Partner Relationship Management (PRM).
Note:
This chapter describes the use patterns associated with the older SOAP-based APIs. See "Partner Relationship Management SOAP-based Web Services Interface" for instructions on how to extend and customize the GUIs used in older (Pre-6.0) Services Gatekeeper releases.See "API Management REST-based API" for instructions on how to use the newer API Management API.
The Service Provider applies for a Service Provider Account using Service Provider Login::registerSPAccountReq(...) providing basic information such as desired account name, contact details, and so forth as part of the application.
The Operator lists new requests using &rsquor. The list can be filtered to display only service provider accounts in the REGISTERED state.
The request is inspected by the Operator, and can be changed using Operator::updateSpAccount(...).
If the request is approved by the Operator, the Service Provider Account is first associated with a Service Provider Group and Service Level Agreement (SLA) and then approved using Operator::registerSpAccountRes(...). For information on setting up a Service Provider Group, see "Operator: Creating a Service Provider Group". For information on setting up an SLA, see ”Managing SLAs” in Services Gatekeeper Accounts and SLAs Guide.
Note:
The Service Provider Group that the Service Provider Account belongs to can be changed at any time using Operator::moveSpToGroup(...).Finally, the Service Provider is notified that the request has been approved by using any of the contact channels that were detailed when the request was submitted. The CRM/PRM application implementor must set up a mechanism for this communication, or for the communication of any other account changes that may occur.
The Service Provider applies for an application account by using Service Provider::registerAppAccountReq(...).
The Operator lists new request using Operator::listAppAccounts(...) You can filter this list to display only applications in the REGISTERED state belonging to a specific service provider account.
The request is inspected by the Operator, and can be changed by using Operator::updateAppAccount(...).
If the request is approved by the Operator, the Application Account is first associated with an Application Account Group and SLA and then approved by using Operator::registerSpAccountRes(...). For information on setting up an Application Account Group, see "Operator: Creating an Application Account Group". For information on setting up an SLA, see ”Managing SLAs” in Services Gatekeeper Accounts and SLAs Guide.
Note:
The Application Account Group that the Application Account belongs to can be changed at any time using Operator::moveAppAccountToGroup(...).Finally, the Service Provider is notified that the request has been approved by using any of the contact channels that were supplied with the original request for a Service Provider Account. The CRM/PRM application implementor must set up a mechanism for this communication, or for the communication of any other account changes that may occur.
At this point the Application Account is in the ACTIVE state. To actually begin sending traffic to Services Gatekeeper, however, the application must now apply for an Application Instance ID to be used to authenticate the account. For information on Application Instances, see "Application Instances"; for information on how to register an Application Instances, see "Registering a new Application Instance".
The Service Provider applies for an Application Instance by using Service Provider::registerAppInstGroupReq(...). The request include desired properties to be associated with the instance.
The Operator lists new requests using Operator::listAppInstGroups(...) The list can be filtered to display only requests from specific SP Accounts and App Accounts for instances in the REGISTERED state.
The request is inspected by the Operator, and can be changed using Operator::updateAppInstGroup(...).
If the request is approved by the Operator, it is approved using Operator::registerAppInstGroupRes(...).
Finally, the Service Provider is notified that the request has been approved by using any of the contact channels that was detailed when applying for a Service provider Account. The CRM/PRM application implementor must set up a mechanism for this communication, or for the communication of any other account changes that may occur.
Once the Service Provider has a Service Provider Account, an Application Account, and an Application Instance ID, traffic can be sent to Services Gatekeeper.
The Operator defines the use privileges for a particular Service Provider Group.
These use privileges are formalized in a Service Provider Service Level Agreement XML file. For more information see ”About Service Level Agreements and Accounts” in Services Gatekeeper Accounts and SLAs Guide.
The Operator creates the Service Provider Group using Operator::createSpGroupByType(...) and assigns the newly created Service Provider SLA to it. An ID for the group is also defined.
The Operator defines the use privileges for a particular Application Account Group.
These use privileges are formalized in an Application Service Level Agreement XML file. For more information see ”About Service Level Agreements and Accounts” in Services Gatekeeper Accounts and SLAs Guide.
The Operator creates the Application Account Group using Operator::createAppGroupByType(...) and assigns the newly created Application SLA to it. An ID for the group is also defined.
The Service Provider can request an update to any of its account entities. The request might cover SLA data or user defined properties. The Operator is responsible for approving or disapproving the request.
To request an update for a Service Provider account, the Service Provider uses Service Provider::update<SpAccount|AppAccount|AccountAppInstGroup>Req(...) as appropriate.
Once the Service Provider has requested an update, the state of the account is changed to UPDATE_PENDING until the Operator has inspected the update request and either approved it or disapproved it using Operator::update<SpAccount|AppAccount|AccountAppInstGroup>Res(...).
Note:
When an account is in the UPDATE_PENDING state, no further requests to update the account are allowed until the initial request has been approved or disapproved.The Service Provider can deactivate any of its account entities. The deactivation takes affect immediately. No traffic is allowed through an account that is deactivated. The impact of a deactivation is cascaded through the Service Providers system:
When a Service Provider Account is deactivated, none of the applications run by the service provider are able to send traffic through Services Gatekeeper.
When an Application Account is deactivated, none of the applications that are associated with that Application Account are able to send traffic through Services Gatekeeper.
When an Application Instance is deactivated, only that Application Instance is unable to send traffic through Services Gatekeeper. Other applications are not affected.
An account must always be deactivated before it can be deleted.
To deactivate an account the Service Provider can use either Service Provider::deactivate<SpAccount|AppAccount|AccountAppInstGroup>Req(...), depending on the type of account.
To deactivate an account the Operator can use either Operator::deactivate<SpAccount|AppAccount|AccountAppInstGroup>Req(...), depending on the type of account.
The Service Provider can request to have any of its account entities deleted. The deletion does not take effect until after the request has been approved by the Operator.
An account must always be in state INACTIVE before it can be deleted.
To request to delete an account, either Service Provider::delete<SpAccount|AppAccount|AppInstGroup>Req(...) is used.
When the Service Provider has requested an account deletion, the state of the account is changed to DELETE_PENDING until the Operator has inspected the request and either approved it or disapproved it using Operator::delete<SpAccount|AppAccount|AppInstGroup>Res(...).
Note:
When the request to delete an account is approved the account is deleted from the database. It is the Operator's responsibility to make sure that outstanding charging data records are processed before the deletion takes place.If the request to delete the account is disapproved, the state of the account becomes INACTIVE.
The Service Provider can communicate desired updates to the Operator using the update methods, as described in "Service Provider Requests an Account Update". Each update request can contain a set of properties in the form of name-value pairs, which are defined by the implementors of the CRM/PRM application.
Both the Service Provider and the Operator can retrieve Charging Data Records using <Operator| Service Provider>::listCdrs(...). The operator can retrieve call details records (CDRs) for all Service Providers, while the Service Provider only has access to Charging Data Records generated by its own applications. Results can be filtered.
Both the Service Provider and the Operator can retrieve statistics using <Operator| Service Provider>::getStatistics(...). The operator can retrieve statistics for all Service Providers, while the Service Provider only has access to its own applications. A set of filters can be used, including Application Account IDs and time intervals.