TM Forum Community

Hi TMF community,

We, as a product catalog team, have built TMF complaint APIs given below :

TMF 620 resources = product offering, product offering price , product specification 

TMF 671 resources =  promotions

Consumers need to make retrieve operations to each of the resources individually. However there is a common use case where consumers, particularly those facing digital channels, need to be able to get back offers, their associated product specs , prices as well as promotions in a single API call, rather than having to make multiple calls to get these.

We currently have built a custom API called getAggregrateOffer API to aggregrate these resources. (Attached image)

We wanted help from TMF community to find out if any other users had this or similar requirement?

We did look at TMF630 but not sure if thats thr right fit for this.

Thanks!

 

#General

------------------------------
Mohit Shetty
Telstra Corporation
------------------------------

Hello!

How about TMF630 REST API Design Guidelines Part 2, Chapter 3. Depth and Expand Directive?

------------------------------
Vitalii Zhakov
Veschatel LLC
------------------------------

While this is one approach, please also consider how you model promotions. Is it necessary to create another object or are you reusing the Product Offering entity with additional identifiers to distinguish a promotion? Even the definition within the API states that the 671 is to be used only when the additional criterion are being applied (Discount, voucher etc. meaning there is a deviation from the POP) even though it is not clear on the data entity. 

The integration approach should be based on your answer to the above. 

------------------------------
Jag Baddukonda
Deutsche Telekom AG
------------------------------

Thanks for the feedback Jag.
Our promotion model does need additional criterions like Discount, Voucher, coupon codes, etc. which is why we had inclined towards TMF671.

This aggregration approach does meet our need, we just wanted to have a look if at all there are any other approaches out there being used.

------------------------------
Mohit Shetty
Telstra
------------------------------

Original Message:
Sent: Aug 26, 2024 03:06
From: Jag Baddukonda
Subject: How to aggregrate different TMF APIs?

While this is one approach, please also consider how you model promotions. Is it necessary to create another object or are you reusing the Product Offering entity with additional identifiers to distinguish a promotion? Even the definition within the API states that the 671 is to be used only when the additional criterion are being applied (Discount, voucher etc. meaning there is a deviation from the POP) even though it is not clear on the data entity. 

The integration approach should be based on your answer to the above. 

------------------------------
Jag Baddukonda
Deutsche Telekom AG
------------------------------

As Jag has mentioned, we model the promotions using Product Offering and have extended the TMF620 Product Catalog Mgmt API to add an isPromotion field (from SID) plus a promotionId.

The depth/expand pattern may then be used to return all relevant sub-resources of the (promotion) Product Offering, i.e. spec, POP, etc.

------------------------------
ROCHANA MACHAROEN
ADVANCED INFO SERVICE PLC. (AIS)
------------------------------

Thanks Rochana, as mentioned above we had the need for a separate promotion object as per TMF671.

 But yes we will look at the depth/expand pattern if it can extend across objects.

------------------------------
Mohit Shetty
Telstra
------------------------------

Original Message:
Sent: Aug 27, 2024 04:58
From: ROCHANA MACHAROEN
Subject: How to aggregrate different TMF APIs?

As Jag has mentioned, we model the promotions using Product Offering and have extended the TMF620 Product Catalog Mgmt API to add an isPromotion field (from SID) plus a promotionId.

The depth/expand pattern may then be used to return all relevant sub-resources of the (promotion) Product Offering, i.e. spec, POP, etc.

------------------------------
ROCHANA MACHAROEN
ADVANCED INFO SERVICE PLC. (AIS)
------------------------------

Hi Mohit,

The UI layer of your Web channels can use GraphQL to aggregate the responses from multiple APIs dynamically during runtime. That's an efficient mechanism and an apt approach for your requirement. If you are not looking for native TMF approach for APIs aggregation, GraphQL would be the best choice to implement at UI layer. 

------------------------------
Raghu Meda
Infosys
------------------------------

We did define a TMF686 Topology Graph Api for selecting and combining data from multiple inventories . It supports a JSON Path plus w3C Function approach for describing graph type operations as supported by GraphQL, Opencypher and others . We have identified some additional feature for this API but need additional requirements input from members.

------------------------------
Dave Milham
TM Forum, Chief Architect
------------------------------

Original Message:
Sent: Sep 26, 2024 06:33
From: Raghu Meda
Subject: How to aggregrate different TMF APIs?

Hi Mohit,

The UI layer of your Web channels can use GraphQL to aggregate the responses from multiple APIs dynamically during runtime. That's an efficient mechanism and an apt approach for your requirement. If you are not looking for native TMF approach for APIs aggregation, GraphQL would be the best choice to implement at UI layer. 

------------------------------
Raghu Meda
Infosys
------------------------------