Open API Enterprise Service Bus
OpenAPI_ESB, an enterprise service bus (ESB), is a key integration product in the new billing solution architecture developed by Peter-Service.

OpenAPI_ESB is designed to be deployed in large-sized network infrastructures (e.g. at the national level) to provide integration between front-end subscriber service systems and the billing core of a communications network, payment processing servers and address servers; in addition, it enables interoperability between OCS (a real-time charging system) and PCRF (policy and charging management) using OpenLDAP. The solution is intended for major communications service providers; it is continuously updated to keep pace with the latest technology it uses (Talend, Apache).

Prerequisites and Characteristics

An enterprise-level business-critical system for a communications service provider is expected to meet the following non-functionality requirements:

  • Compliance with the applicable 3GPP and TM Forum standards
  • Horizontal scalability
  • Only standard SQL/PSM; RDBMS-agnostic
  • Interoperability with external systems via a documented API
  • Control over the volume of data stored; timely archiving
  • Control over the input load and time-to-respond
  • Monitoring and diagnostics tools
  • Disaster recovery

To ensure that each of the above requirements is fully met and to provide a greater level of flexibility in complex solution deployments, Peter-Service has developed a range of integration components to use them in its latest BSS solution architecture, with most interactions between solution components being mediated by OpenAPI_ESB, an enterprise service bus.

Peter-Service synchronizes the source code of OpenAPI_ESB with latest updates to the code of the source systems, such as Talend ESB Standard Edition and RabbitMQ, on a regular basis. A synchronization can be made on demand, when a customer asks for it, or at the initiative of Peter-Service when some new important functionality is added to the source systems.



Flexible configuration options; the ability to select only those functional components that are relevant for a given deployment project


Horizontal scalability; no limits on the number of subscribers being served


The negative impact of a failed node is limited to certain services and subscribers, not extending to the entire subscriber base and every service available


Subscribers can see the cost of any transaction immediately after it is finished


A graphical interface for system configuration tasks


The solution includes only up-to-date open source components that are being actively developed


  • An open API with SSO authentication is the main way of interaction
  • Products that implement some business functionality, like OCS (Online Charging System) and CIS (Customer Inspiration System) get “clean” requests from authenticated and authorized users
  • High-speed data exchanges without direct interactions (everything is mediated by ESB)
  • Unlimited horizontal scalability, allowing for smooth functioning in distributed networks or networks with weak or unstable communications channels
  • Integration of multiple instances of a system, with one of them running as the master system
  • A set of monitoring and management tools, including Logstash/Kibana (log administration and control) and Hawtio (graphic representation and online monitoring of Camel routes)