Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The RTBS agent is a processing agent designed to support the Charging Parlay Service provided by the Comverse Realtime Billing System. The functionality exposed by these services are mapped to the type system. The agent thereby emits a set of UDRs that represent the requests that can be made and their corresponding responses.


Note!

The agent is compatible with the services defined in the Comverse Interface Control Document for Open Services Access release 4.6.


The agent communicates with the billing system using SOAP over HTTP. In order to retrieve responses from the billing system, a separate service needs to be configured for the Execution Context. For further information, see the section below, Preparations. This service is shared by all RTBS agents running on the same EC.

Preparations

When installing the RTBS agent for the first  time, properties must be added to configure the ECs.
 

  1. For each Execution Context that the RTBS workflows will execute on, two Execution Context properties for callback has to be added to the relevant pico configuration files:
     

    • Callbackhost, defines the name or IP address of the interface that should receive responses from the machine hosting the EC.

      mzsh topo set topo://container:<container>/pico:<pico name>/val:config.properties.rtbs.callbackhost <ip address>

    • Callbackport, defines the port that responses should be sent to.

      mzsh topo set topo://container:<container>/pico:<pico name>/val:config.properties.rtbs.callbackport <port>

  2. Startup the ECs:

    $ mzsh startup <ec> <ec>

Transaction Overview

Asynchronous Request

The RTBS agent (Parlay) uses both synchronous and asynchronous requests. It is important to understand the differences between them, since it affects the requirements on the business logic in the workflow.

Usually, when routing a UDR to a subsequent agent, the agent performing the route can trust that the subsequent agents have completed their tasks before it continues with any post activity. For asynchronous requests, this is not the case.

The RTBS agent can not assume that the request has been successful until the corresponding response comes back from the agent. This means that the agent following the RTBS agent must manage any operations that are supposed to take place when the response comes back.

Note!

When a response connected to an asynchronous request returns, the workflow is driven by the response and not by the collection agent as usual. Therefore, the call path for the workflow is different and the workflow logic needs to manage this. This is typically done using the Aggregation agent to store variables and states that are needed to pick up and handle a response from an asynchronous agent.

For a list of requests and the category that each of them belongs to, see the section below, Request/Response Mapping. Basically, UDRs ending with Req represents an asynchronous request and UDRs starting with Get represents a synchronous request.

Request/Response Mapping

The RTBS agent contains a number of different UDRs. The UDRs in turn contain a set of fields corresponding to the fields required by the billing system. The UDRs also contain a few internal fields that can be used by the workflow logic.

There are also additional types that the agent provides, which are used to populate the request and response. These data types are prefixed Tp.

RTBS Related UDR Types

In the UDR Internal Format Browser a detailed view of the available fields is displayed. To open the browser, click the Configuration menu and select the option APL Code, and then right-click in the editing area and select the option  UDR Assistance... .

UDR Internal Format Browser showing a UDR with fields

The following requests and responses are provided by the agent and shown in the rtbs folder:


Asynchronous Request Response or Error
ReserveUnitReqReserveUnitRes or ReserveUnitErr
DebitUnitReqDebitUnitRes or DebitUnitErr
CreditUnitReqCreditUnitRes or CreditUnitErr
DirectDebitUnitReqDirectDebitUnitRes or DirectDebitUnitErr
ReserveAmountReqReserveAmountRes or ReserveAmountErr
DebitAmountReqDebitAmountRes or DebitAmountErr
CreditAmountReqCreditAmountRes or CreditAmountErr
DirectDebitAmountReqDirectDebitAmountRes or DirectDebitAmountErr
DirectCreditAmountReqDirectCreditAmountRes or DirectCreditAmountErr
ExtendLifeTimeReqExtendLifeTimeRes or ExtendLifeTimeErr



Synchronous Request Response
GetAmountLeftReqGetAmountLeftRes
GetUnitLeftReqGetUnitLeftRes
GetLifeTimeLeftReqGetLifeTimeLeftRes



Other Request Other Error
ReleaseSessionN/A
Allows the workflow to tell the agent that an ongoing RTBS session should be released, normally not needed since the billing system will manage this.
Any request RequestException
Error that can be sent from the agent whenever an abnormal error has occurred.
Any request SessionAborted
Possible response from the billing system if an ongoing session must be aborted, e g, when a session has been idle for some time.


Error Management

The agent will, to the extent possible, manage errors without aborting the workflow. Errors related to the communication between the agent and the billing system are sent to the system log and routed into the workflow via the  RequestException  UDR where the two fields errorMessage and errorDetails contain the details of the error. The  RequestException  type is also used for invalid requests detected by the agent. Other errors are only written to the System Log.

  • No labels