Open APIs

 View Only
Expand all | Collapse all

TMF620 and Billing Catalogue

  • 1.  TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 28, 2024 06:01

    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).

    Scenario: 

    1. Business user creates a product offering from Unified product catalogue (UPC)
    2. 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))
    3. 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
    ------------------------------


  • 2.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 28, 2024 10:48

    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.
    ------------------------------



  • 3.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 02:43

    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
    ------------------------------



  • 4.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 06:03

    The whole area of catalog federation, which is effectively what you are discussing, is actually rather complex. TM Forum has a rather aged white paper on that, which I think largely predates the Open API effort (I don't have the reference to hand, perhaps @David Milham can assist).

    Conceptually at least, you could run an ExportJob in the master catalog, and then an ImportJob in your slave catalogs - both of these task resources are specified in TMF620 swagger and user guide.

    Hope it helps.



    ------------------------------
    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.
    ------------------------------



  • 5.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 09:12

    Clear Sir....

    export/import job is clear



    ------------------------------
    Janakiram Renganathan
    OMANTEL
    ------------------------------



  • 6.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 12:56

    AS per Jonathan's comment:
    Catalog  federation was addressed in this early document: 

    GB978 Catalog to Catalog Interface R17.5.1

    The reason this happened at least in the past is multiple Catalogs embedded in CRM, Ordering and billing applications that needed to be synchronised. It is possible that this is avoided with use of ODA Components but may still be needed with Open APIs added to best of breed applications.

    We touched on this also in the early ODA Architecture work. see IG1222 Part 4: ODA Technical Architecture ODA Patterns v1.0.0 - Published Deliverables - TM Forum Confluence  Sections 2 3 and especially section 4.



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



  • 7.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Mar 01, 2024 06:33

    Thank you @David Milham



    ------------------------------
    Janakiram Renganathan
    OMANTEL
    ------------------------------



  • 8.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 08:32
    Edited by Jag Baddukonda Feb 29, 2024 08:47

    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
    ------------------------------



  • 9.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 09:16

    @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
    ------------------------------



  • 10.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 11:41

    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 :-) 



    ------------------------------
    Sri-Jagadish (Jag) Baddukonda
    Bell Canada
    ------------------------------



  • 11.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 07:56

    Hi

    @Janakiram Renganathan Not clear for me why billing/charging system would need to expose TMF620 Product Catalog API. I don't yet see any other ODA component than TMFC001 Product Catalog that exposes this API. I'm interested in understanding the need.



    ------------------------------
    olivier arnaud
    Orange
    ------------------------------



  • 12.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 09:10

    @olivier arnaud

    I will try to explain it in a different way

    We have implemented a unified product catalogue - API's are exposed from this component following TMF620.

    Now a business or IT user is using the UPC GUI to define a new productOffering for Mobile postpaid with Recurring Charge as $20.  Now this product definition has to be cascaded to billing with ID, Name and recurring charge details so that the same can be used during order process. We have 2 options to do this

    Option 1: As per 620, UPC will notify about this new product (publish event to listener), the listener (Billing system) will parse the JSON file and load/create new product definition in billing catalogue.

    Option 2: Instead of using a batch process, we have asked billing vendor to expose API's so that UPC can invoke these API's to create a product in billing system

    based on the above, the suggestion/recommendation/ required is as follows:

    1. for option 1, Billing system should be able to parse, read the the JSON file exported by UPC and import into Billing catalogue; Which essentially means, billing system catalogue is aligned/in conformance to TMF 620
    2. for option 2, instead of JSON FILE, UPC is going to invoke an billing API to pass this product info. I expect this API to be in alignment with TMF620 so that there is a common language, model and structure between billing and UPC

    hope this is more clear now.....So if a billing vendor claims that their platform is exposing open API's in conformance with TMF, I expect that platform to following TMF620 for product related aspects



    ------------------------------
    Janakiram Renganathan
    OMANTEL
    ------------------------------



  • 13.  RE: TMF620 and Billing Catalogue

    TM Forum Member
    Posted Feb 29, 2024 10:55

    ok, thanks, I understand more the requirements.



    ------------------------------
    olivier arnaud
    Orange
    ------------------------------