| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.0 Part Number E21362-01 |
|
|
View PDF |
| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.0 Part Number E21362-01 |
|
|
View PDF |
This chapter describes the Parlay X 3.0 Payment/Diameter communication service in detail.
The Parlay X 3.0 Payment/Diameter communication service exposes the Parlay X 3.0 Payment set of application interfaces.
The communication service acts as a credit control client to a credit control server using the Diameter protocol.
For the exact version of the standards that the communication service supports for the application-facing interfaces and the network protocols, see the appendix on standards and specifications in Concepts Guide.
Using a Payment communication service, an application can:
Charge and refund accounts directly.
Operate on reservations, which includes:
Make reservations.
Charge reservations.
Release reservations.
Charge multiple accounts concurrently.
All charging is done on accounts. The unit of charge is specified as a given currency or a charging code.
A reservation expires after a given time. An expiration mechanism provided by the Storage Service is used. If the store entry expires, the reservation is cancelled.
Some Diameter servers, for example Oracle Billing and Revenue Management, mandate that a refund operation be correlated with a previous charge operation. The Payment interface does not provide any correlation between charge operations and refund operations. The session-id tunneled parameter has been added in order to correlate these requests. When an application calls chargeAmount, the tunneled parameter session-id is returned in the SOAP header. An application should use this session-id in subsequent refundAmount requests to correlate the two requests. If the application does not provided the tunneled parameter, it is the responsibility of the Diameter server to either accept or deny the request. If the request is denied, the application receives a ServiceException. See "session-id" for more information.
For information about the SOAP-based interface for the Parlay X 3.0 Payment communication service, see the discussion of Parlay X 3.0 Interfaces in Application Developer's Guide.
For information about the RESTful Call Notification interface, see the discussion of Payment in RESTful Application Developer's Guide.
The RESTful Service Call Notification interfaces provide RESTful access to the same functionality as the SOAP-based interfaces. The internal representations are identical, and for the purposes of creating SLAs and reading CDRs, and so on., they are the same.
The Parlay X 3.0 Payment/Diameter communication service generates Event Data Records (EDRs), Charging Data Records (CDRs), alarms, and statistics to assist system administrators and developers in monitoring the service.
For general information, see Appendix A, "Events, Alarms, and Charging."
Table 14-1 lists Event Data Record (EDR) IDs created by the Payment/Diameter communication service.
Payment/Diameter communication service-specific CDRs are generated when the response to a request is successfully delivered to the application. All of the following operations trigger the generation of CDRs:
chargeAmount
refundAmount
chargeSplitAmount
reserveAmount
reserveAdditionalAmount
chargeReservation
releaseReservation
Table 14-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counter.
Table 14-2 Methods and Transaction Types for Parlay X 3.0 Payment/Diameter
| Method | Transaction type |
|---|---|
|
chargeAmount |
TRANSACTION_TYPE_CHARGING_DIRECT |
|
chargeSplitAmount |
TRANSACTION_TYPE_CHARGING_DIRECT |
|
refundAmount |
TRANSACTION_TYPE_CHARGING_DIRECT |
|
reserveAmount |
TRANSACTION_TYPE_CHARGING_RESERVED_STRING |
|
reserveAdditionalAmount |
TRANSACTION_TYPE_CHARGING_RESERVED_STRING |
|
chargeReservation |
TRANSACTION_TYPE_CHARGING_RESERVED_STRING |
This section lists the parameters that can be tunneled.
Correlates a refundAmount operation with a chargeAmount operation.
Some billing systems, including Oracle Billing and Revenue Management, allow refund operations only on previously charged amounts. Parlay X does not have the ability to correlate charge and refund operations. This parameter provides that functionality.
The key and the value are available in the return message from a chargeAmount operation. It is the responsibility of the application to provide the key and the value in subsequent refundAmount operations to correlate the two.
If no session-id is provided in the request to the Diameter node, the Diameter node can either accept or deny the request. If the node denies the request, a ServiceException is sent back to the application.
String
This is an example in a SOAP header:
<xparams> <param key=" session-id value="12233187769"/> </xparams>
This section describes the properties and workflow for the Parlay X 3.0 Payment/Diameter plug-in instance.
Table 14-3 lists the technical specifications for the communication service.
Table 14-3 Properties for Parlay X 3.0 Payment/Diameter
| Property | Description |
|---|---|
|
Managed object in Administration Console |
domain_name > OCSG > server_name > Communication Services > plugin_instance_id |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng_nt InstanceName=same as the network protocol instance_id assigned when the plug-in instance is created Type=com.bea.wlcp.wlng.plugin.payment.diameter.management.PaymentMBean |
|
Network protocol plug-in service ID |
Plugin_px30_payment_diameter |
|
Network protocol plug-in instance ID |
The ID is assigned when the plug-in instance is created. See "Managing and Configuring the Plug-in Manager" in System Administrator's Guide. |
|
Supported Address Scheme |
tel |
|
Application-facing interfaces |
com.bea.wlcp.wlng.px30.plugin.AmountChargingPlugin com.bea.wlcp.wlng.px30.plugin.ReserveAmountChargingPlugin |
|
Service type |
Payment |
|
Exposes to the service communication layer a Java representation of: |
Parlay X 3.0 Part 6: Payment |
|
Interfaces with the network nodes using: |
Diameter RFC3588 and RFC 4006 |
|
Deployment artifact NT EAR wlng_nt_payment_px30.ear |
Plugin_px30_payment_diameter.jar and px30_payment_service.jar |
|
Deployment artifact AT EAR: Normal wlng_at_payment_px30.ear |
rest_payment.war and px30_payment.war |
|
Deployment artifact AT EAR: SOAP Only wlng_at_payment_px30_soap.ear |
px30_payment.war |
Following is an outline for configuring the plug-in using the Administration Console or an MBean browser.
Create one or more instances of the plug-in service. See "Managing and Configuring the Plug-in Manager" in System Administrator's Guide.Use the plug-in service ID as listed in the "Properties for Parlay X 3.0 Payment/Diameter" section.
Using the Administration Console or an MBean browser, select the MBean for the plug-in instance. The MBean display name is the same as the plug-in instance ID given when the plug-in instance was created.
Configure the behavior of the plug-in instance:
Use "Operation: connect" to connect to the Diameter server.
Set up the routing rules to the plug-in instance. See "Managing and Configuring the Plug-in Manager" in System Administrator's Guide. Use the plug-in instance ID and address schemes listed in the "Properties for Parlay X 3.0 Payment/Diameter" section.
If required, create and load a node SLA. For details see "Defining Global Node and Service Provider Group Node SLAs" and "Managing SLAs" in the Accounts and SLAs Guide.
Provision the service provider accounts and application accounts. For information, see Accounts and SLAs Guide.
The Parlay X 3.0 Payment/Diameter plug-in instance can be explicitly connected to the Diameter server. It does not connect to the server by default. The service has a connection status that will be preserved after service redeployment and server restart.
Use:
Use "Operation: connect" after any changes to the configuration attributes. Changes does not take affect until this operation is invoked.
This section describes the attributes and operations for configuration and maintenance:
Scope: Server
Format: Boolean
Unit: Not applicable
Displays the status of the connection to the Diameter server.
Displays:
true, if connected.
false, if not connected.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the value of the Destination-Host AVP in Diameter requests.
Example:
host.destination.com
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the host name of the Diameter server to connect to.
Example:
host.destination.com
Scope: Cluster
Unit: Not applicable
Format: Integer
Specifies the port on the Diameter server to connect to.
Example:
3588
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the Destination-Realm AVP in Diameter requests.
Example:
destination.com
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the Service-Context ID AVP.
The default is oracle.com.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the Origin-Host AVP in Diameter requests.
Example:
host.oracle.com
Scope: Cluster
Unit: Not applicable
Format: Integer
Specifies the local originator port to be used for the connection to the Diameter server.
Example:
7002
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the Origin-Realm AVP in Diameter requests.
Example:
oracle.com
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the value of the Service-Context-Id AVP in Diameter requests. Used to override the oracle.com suffix in the ServiceContextId value to work with third-party charging applications.
Example:
SCAP_V.2.0@xyz.com
Scope: Cluster
Connects to the Diameter server.
Once connected, the service will try to reconnect to the Diameter server if the server is restarted or the plug-in is redeployed.
Signature:
connect()
Scope: Cluster
Disconnects from the Diameter server.
Once disconnected, the plug-in will not try to reconnect to the Diameter server if the server is restarted or the plug-in is redeployed.
Signature:
disconnect()
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
