Open APIs

Expand all | Collapse all

TMF637 ProductPrice (exposing CompositeProdPrice)

  • 1.  TMF637 ProductPrice (exposing CompositeProdPrice)

    TM Forum Member
    Posted Apr 20, 2021 08:14


    I have a question regarding ProductPrice resource exposed in TMF 637 API in a flatten way, compared with SID model where the ProductPrice can be composed of multiple prices. Flattening a complex structure of composite prices with multiple alterations at different layers can be quite a challenge considering their stacking and sequencing. Having this in mind, we would like to understand how these use cases are handled at API level as we are missing the reasons/concerns for not exposing the hierarchy at API level as well.

    Following a similar approach as for Product Offering Prices (considering that a ProductPrice is an instantiation of a ProductOfferingPrice),  and trying to add a new attribute bundledProductPricesRelationship (similar with bundlePopRelationship) for exposing the bundled product prices (as references) it's not feasible as long as we don't have APIs to expose the ProductPrice resource only, therefore we are thinking to add a new attribute – bundledProductPrices ( List of ProductPrice) in order to expose the entire product price hierarchy.

    We would like to keep the resources as per Open API , so we are keen to receive guidance from your side on this topic.

    Thanks in advance,


    Mihaela Bordean
    IBM Corporation

  • 2.  RE: TMF637 ProductPrice (exposing CompositeProdPrice)

    TM Forum Member
    Posted Apr 21, 2021 01:43
    Hi Mihaela
    As a general rule (not just here), we find that when mapping between the SID and the Open API, a lot of flattening takes place, and indeed other simplifications. This is due to the different purposes of the models:
    • The SID is a canonical, normalized information model that describes the service provider business. It is not intended for direct implementation (as far as I am aware) in databases or in APIs
    • The Open API needs a practically usable resource model for REST API payloads.
    Specifically for product pricing, my personal opinion is that you would need to have a very good and convincing use case to have complex prices. I suggest that if relevant you present the use case to the community forum and we can then discuss how the Open API model could represent, both in catalog and in the inventory.
    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.