Your expectation is correct.
If the SID model is followed, the API exposure should be via 620. Even if the model is not followed, the vendor can have internal transformation and expose via 620.But that is a discussion with the vendor :-)
Original Message:
Sent: Feb 29, 2024 09:15
From: Janakiram Renganathan
Subject: TMF620 and Billing Catalogue
@Jag Baddukonda
Thanks for responding,
This is for consumer/residential related product offering/catalogue.
If a billing vendor claims that his platform is in conformance to ODA/Open API's and the platform also has API's to accept the product federation/cascading from UPC, then is it appropriate for me to expect this API to follow/adhere to TMF620 resource model/entity structure?
------------------------------
Janakiram Renganathan
OMANTEL
Original Message:
Sent: Feb 29, 2024 08:32
From: Sri-Jagadish (Jag) Baddukonda
Subject: TMF620 and Billing Catalogue
Hi Janakiram,
Conceptually you are right. And more important than the API structure is the topic of federation and the decisions to be made around the first point of PO creation. There are various approaches.
One approach can be the way you described. And there are slightly different ones where in mass market retail scenarios with frequent price changes and launch of time based promotions a slightly different approach for federation is followed.
Once this is decided, the mapping of the entities between the UPC and Billing and the attributes needs to be done.
Regards,
------------------------------
Sri-Jagadish (Jag) Baddukonda
Bell Canada
Original Message:
Sent: Feb 29, 2024 02:42
From: Janakiram Renganathan
Subject: TMF620 and Billing Catalogue
Thank you Sir for your feedback,
Irrespective of whether we follow API based/publish model, the downstream systems (like billing, charging) are expected to import/expose API's (in conformance with TMF620) to capture relevant catalogue resources into the local catalogue. Is this understanding correct?
------------------------------
Janakiram Renganathan
OMANTEL
Original Message:
Sent: Feb 28, 2024 10:47
From: Jonathan Goldberg
Subject: TMF620 and Billing Catalogue
Seems reasonable in general, but I'm not sure that it is OK to expect a UPC to deliver a tailored subset to each possible downstream system. To me, it makes more sense that UPC publishes a full model, and each downstream system takes what information it needs.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Feb 28, 2024 01:05
From: Janakiram Renganathan
Subject: TMF620 and Billing Catalogue
We have implemented a unified product catalogue in conformance with ODA guidelines, including TMF620.
Our understanding about TMF620 is that all the applications/components in the eco-system (including billing, charging, CRM) will also adhere to the same guidelines, in order to have a common data model (We could not see any product catalogue guidelines specific to billing catalogue or charging catalogue).
- Business user creates a product offering from Unified product catalogue (UPC)
- As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
- Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream
We request you to provide your feedback on the above understanding.
------------------------------
Janakiram Renganathan
OMANTEL
------------------------------