Open APIs

  • 1.  TMF 620 Post

    Posted Oct 06, 2021 15:04
    How should we interpret the resources that are not marked as Ref or RefOrValue? For example
    1) ProductOfferingTerm
    2)ProductOfferingRelationship - this one has a id, href , but also has a name - Is there an expectation that a child offering will be created on the fly if name is present ? Why is name here?
    3)BundledProductOffering - similar to ProductOfferingRelationship, in that it is not clear if this is a ref or value , is there an expectation that an array of bundledpo is created if they do not exist (as Ref is missing from the resource name)

    In general what is the underlying principle for these entities that do not have a Ref or RefOrValue appended at the end?

    Nash Verghese


  • 2.  RE: TMF 620 Post

    TM Forum Member
    Posted Oct 10, 2021 08:39
    Hi Nash
    Ref and RefOrValue apply only to managed entities (i.e. top-level entities), which are the direct objects of REST operations such as GET and POST. These are addressable entities (via id and href), and so it makes sense to have Ref (or RefOrValue).
    Sub-entities within an entity are not directly addressable and so Ref is meaningless.
    This applies across all the TMF Open APIs.

    Specifically for your examples (from TMF620 Product Catalog Management):
    • ProductOfferingTerm is not an independent entity, it is embedded within ProductOffering (and will be instantiated as a ProductTerm embedded within a Product at ordering/provisioning time). You could argue that it would make sense to have reusable terms, but currently we don't have them.
    • ProductOfferingRelationship is a specialized form of Ref - the id and href are not of the relationship itself but rather of the referred ProductOffering. Hence name, which appears in Refs, appears here as well. The POR entity has additional attributes that are not in a general Ref, i.e. type, role, and validity period.
    • BundledProductOffering is also a specialized form of Ref - the id and href are of the ProductOffering being bundled in the containing PO. The BPO has additional attributes that define the cardinality options for the offerings being bundled (in the BundledProductOfferingOption sub-entity).
    • ProductSpecificationCharacteristicValueUse is a way to limit the allowed values of a product spec characteristic when the spec is used in the context of a particular offering.
    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.