Open APIs

Expand all | Collapse all

Product Characteristics: TMF 620 vs GB922 Product

  • 1.  Product Characteristics: TMF 620 vs GB922 Product

    TM Forum Member
    Posted Oct 07, 2019 11:39
    Edited by Igor Veliev Oct 09, 2019 11:00
    Hi team,

    GB 922 Product R19, page 39 shows ProductSpecCharacteristic as an entity separated from a ProductSpecification and even reusable for different ProductSpecCharUse objects in same ProductSpecification or in different ProductSpecifications.
    It make sense for example when we have same Characteristic in many different ProductSpecifications and we want to use single association of OfferingPrice with specific value of such a common Characteristic by it's ID.
    With this approach ProductSpecCharacteristic became more like ProductCharacteristicSpecification reusable from different ProductSpecifications.
    So if we need parameters of this ProductCharacteristicSpecification bit tuned in specific ProductSpecification we may reload it with new values in ProductSpecCharUse.

    TMF 620 R19 shows absolutely different approach. ProductSpecificationCharacteristic is not SID's ProductSpecCharUse or ProductSpecCharacteristic (don't be fooled with the same name of composition).
    It is something different which belongs to only one particular ProductSpecifcation and it doesn't have any references (ID) to be associated with common prototype.
    ProductSpecCharacteristic does not have ID of characteristicSpecification.
    Moreover we can see same ProductSpecificationCharacteristicValue in composition under ProductSpecificationCharacteristicValueUse (which looks like SID's ProdSpecCharUse and exists only in Offerings and Prices).
    ProductOfferingPrice is not associated with particular Value but associated with prodSpecCharUse (it's not SID's prodSpecCharValueUse, because it doesn't even have isDefault flag)

    Please help me answer the following questions:
    1. How can we avoid multiple excessive duplicates of characteristic data in Product Catalog with this approach? For example 'color' with dozens of charValues?
    2. How can we avoid multiple excessive OfferingPrice associations with each particular ProductSpecCharacteristicValue via ProdSpecCharValueUse in the meaning of TMF 620?

    Igor Veliev
    Netcracker Technology

  • 2.  RE: Product Characteristics: TMF 620 vs GB922 Product

    TM Forum Member
    Posted Oct 22, 2019 11:46
    Hi Igor

    The Open API model is a deliberate simplification of the SID, using patterns such as collapsing class hierarchies, consolidating entities, omitting attributes and relationships, and more.
    In addition, the Open API model is just that, a model of the API payload. It does not necessarily represent the underlying persisted data model, for example.

    Specifically for the characteristic model (used in catalogs of Product, Service, Resource, and elsewhere), it was decided not to make Characteristic a separately managed resource. This does not mean that in your persistence model and your API implementation you would repeat Characteristic - you can certainly re-use the same Characteristic in multiple specs, perhaps by ensuring that the is globally unique.

    The ValueUse entity is intended to allow restriction of the characteristic values in context. For example, suppose we have a Characteristic named downstreamBandwidth, used in a Product Spec for ADSL. This Characteristic might have a set of CharacteristicValues such as 10Mbps, 100Mbps, 200Mbps. Now when the ADSL spec is offered for sale in a general Product Offering, all these values might be valid and selectable at ordering time (with corresponding impact on price). But when offered for sale in (say) a Student Broadband offering, we might allow only 10Mbps - the ValueUse entity on Offering would have only one entry in this case, for 10Mbps.

    Hope this helps, feel free to get back to me if you need additional clarification.

    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.