Why Telcos Implement TM Forum Open APIs with MongoDB

How MongoDB speeds up development of new TM Forum services

In the evolving and increasingly complex telecommunications industry, providers are turning to open digital architectures to enable interoperability and manage new digital offerings.

TM Forum (TMF), an alliance of more than 850 companies, accelerates digital innovation through its TMF Open APIs, which provide a standard interface for the exchange of different telco data models. The use of TMF Open APIs ranges from providers of off-the-shelf software to proprietary developments of the largest telecommunications providers.

In working with many of the world’s largest communication service providers (CSPs) and the related software provider ecosystem, MongoDB has seen a significant number of organizations leveraging these emerging standards. Through exposing common interfaces CSPs are able to adopt a modular architecture made up of best-of-breed components (either internally or externally developed) while minimizing the time, effort, and cost required to integrate them.

“MongoDB’s document model technology has given CSPs the ability to be more agile and more innovative at the same time, which aligns perfectly with the mission of TM Forum Open APIs,” said George Glass, TM Forum Chief Technology Officer. “We’re delighted to see MongoDB partnering with developers to deliver TM Forum-compliant microservices in days instead of weeks or months.”

TMF Open APIs empower CSPs to build new microservices in days, not weeks or months

The MongoDB document model allows developers to work with data in a natural way and store data as it is retrieved by the application. In the context of TMF Open APIs, this means that TMF resources of the API can be persisted 1:1 in the database without the need for additional mappings. This is highlighted in the example below, which demonstrates how a portion of the TMF666 (Account Management) resource model can be simply and intuitively implemented as MongoDB documents as opposed to traditional relational structures.

Relational Model

MongoDB Representation

{
   "_id": "3df04c97-51c7-4cb4-817e-1bd86eb2e2b3",
   "name": "John Doe",
   "state": "verified",
   "accountType": "B2B",
   "description": "Special Customer",
   "accountBalance": [
       {
           "amount": {
               "unit": "euro",
               "value": NumberDecimal(89.98)
           },
           "balanceType": "main",
           "validFor": {
               "endDateTime": ISODate("2021-09-01"),
               "startDateTime": ISODate("2021-07-01")
           }
       }
   ],
   "accountRelationship": [...],
   "contact": [...],
   "creditLimit": {
       "unit": "euro",
       "value": 500
   },
   "lastModified": ISODate("2021-08-31T16:28:41.111Z")
}

When new versions of the specifications are released, or requirements demand that the data model be extended with custom defined data, the new attributes can be implemented in the application without having to spend time and effort changing database tables and constraints. This flexibility allows CSPs to achieve the agility promise of TMF Open APIs in practice. Development teams can rapidly develop TMF-compliant microservices because there is no need to model TMF entity models in your relational database.

Together with full-stack digital BSS Finnish provider Tecnotree, MongoDB is helping build broader access for telecommunications development teams in charge of launching new microservices.

Tecnotree recently earned Platinum Badge for Open APIs from TM Forum and were among the first in the telecom industry to adopt, mature and stabilize open-source principles for Digital Business Support System (BSS).

“As we continue to support telecoms operators’ customer-first approach to drive growth in the enterprise market, partnership with MongoDB is helping us push aside some of the biggest technological obstacles faced by operators globally,’’ said Sajan Joy Thomas, VP-Product Office, Tecnotree Oyj.

Query data flexibly using TMF specifications

With this flexibility comes the ability to query data flexibly in order to support a variety of defined access patterns. This is demonstrated by the FinancialAccount resource in the TM666 specification (account management API).

The GET operation contains a parameter to specify which fields should be returned (a projection) and iterate through the result set by 'offset' and 'limit’ parameters. As the specification evolves, the MongoDB query language and rich indexing capabilities will allow for complex filter parameters to be easily supported.

The original GET operation referred to above can be implemented using MongoDB’s aggregation framework with the following query:

db.collection.aggregate([
    { $skip: 50 }, 
    { $limit: 10 }, 
    { $project: {
          "accountType": "B2C",
           "state": "active"
      }
    }
])

Adding additional filtering is as simple as including an additional $match stage as the first stage in the pipeline (with appropriate index support).

These aggregation queries can easily be represented in an idiomatic way using any of the supported drivers. The following Java example implementation shows how the above query can be written using the Java driver. No error-prone query string is needed nor an additional object-relational mapping layer to translate the result from MongoDB objects into Java objects.

public List<FinancialAccount> getFinancialAccounts(String fields, Integer skip, Integer limit) {
        [...]
        var projectStage = createProjectStageFromFieldList(fields);

        var pipeline = new ArrayList<Bson>();

        pipeline.add(skip(skip));
        pipeline.add(limit(limit));

        if (projectStage != null) {
            pipeline.add(projectStage);
        }

        collection.aggregate(pipeline).iterator().forEachRemaining(accounts::add);

        return accounts;
}

GitHub: https://github.com/mongodb-industry-solutions/tmforum-openapi-example

Aside from some additional boilerplate code, this is the only code needed to get a basic working API. TMF provides the API as a Swagger specification, and this can be used to generate the resource and API classes automatically. These resource classes can be passed directly to the MongoDB driver, which will handle the translation into MongoDB data types.

The easiest way to access the Swagger file and get started is to download the specification from the TMF Open API resources page. In the linked GitHub project, a Maven plugin is used to generate the code from the Swagger file, but this can also be manually done by using the Swagger Codegen CLI, depending on what fits better into the development workflow:

java -jar swagger-codegen-cli-3.0.30.jar generate \
-i ./TTMF666-Account-v4.0.0.swagger.json \
-l java \
-o ./client/java

In most applications, more is needed than a functioning external API. Business processes, such as customer creation, may require that multiple operations on resources be treated as an atomic transaction. MongoDB has support for distributed transactions at global scale to fulfil this requirement at the database level. Despite this, with the power of the document model, transactions are often not needed in many cases where a relational database would need them.

Take a look at the FinancialAccount again. Updating all related information in one atomic operation would require a transaction in relational databases, whereas it’s just one update operation of a document in MongoDB. This leads to an overall reduction in I/O and better application performance.

These advantages, combined with industry leading scale and resilience capabilities, drive CSPs to implement TMF APIs with MongoDB as the primary data source and indeed, many of the example implementations provided by TM Forum use MongoDB for data persistence.