Open APIs

 View Only

  • 1.  TMF620 - Product Specification APIs

    Posted Nov 17, 2020 04:22
    Hello,

    We are working on implementing serviceability checks for offerings to be purchased by customers, meaning that only services with specific characteristics might be available in the customer's location (e.g. at address x, internet is available with upload speed of 500mb and download speed of 200mb)

    To determine which are the offerings supporting those service characteristics we need to have in the APIs the following relationships:
    • Product Spec Characteristics (PSC) and Customer Facing Service Spec Characteristics (SSC)
    • Product Spec Characteristic Value (PSCV) and Service Spec Characteristic Value (SSCV)

    Although present in the Information Framework, these relationships are not present in the Product Specification APIs (the candidate API which we considered to offer these associations between Offerings and Services).
    Our intend is to enhance this API by adding the missing information.

    Can you please share your thoughts if this is the right way to handle this use case or you have considered a different approach, case in which those relationships were not added intentionally in TMF620.

    Many thanks,
    Cristina

    ------------------------------
    Cristina Keserii
    IBM Corporation
    ------------------------------


  • 2.  RE: TMF620 - Product Specification APIs

    Posted Nov 18, 2020 03:25
    Hello Cristina,
    To provide you some feedbak and working on a Product catalog component we faced same question.
    We create the ProductSpec from a CustomerFacingServiceSpec and in fact we used a process to manage this creation.

    For the productSpec characterisitcSpec (and valueSpec) we present to the administrator the characteristicSpec (and valueSpec) of the root CFS Spec and the admin could take all of them or restrict some of them (the service spec upload speed is 100mb to 10 gb - for this product spec we want to offer only from 100mb to 1gb).

    We always check before to enter the productSepc in the database.

    But - and you are probably on the same point - we had to extend the model of the Product characteristicSpecification (and value) to add the id of the CFS characteristicSpecification (and value). We have to keep this information because it is easier in the product order management to define the service to be instantiated (by the service order) from the product ordered. We have a explicit link.

    we have to add @Jonathan Goldberg in the discussion as Jonathan is our leader for this catalog API and he has probably some good idea/feedback on this topic.

    Hope it helps

    Ludovic
    ​

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 3.  RE: TMF620 - Product Specification APIs

    Posted Dec 01, 2020 02:48
    Hi Cristina
    Firstly my apologies for the delay in answering, I hope that this has not inconvenienced you.
    You are correct in that the Open API model is missing these SID implementation details. And we could consider this as an enhancement to v5 Product Catalog (the list is getting longer :) ).
    I should add, to be fair, that even the SID model is not sufficient, since it assumes a simple mapping between characteristics (and values) between the two levels Product and Service. In many cases this may be good enough, but in some cases the mapping rules might be more complex, for instance:
    • product characteristic value might cause a choice between two different services, e.g. at product level I might have defined copper or fiber for broadband (with corresponding pricing), these would be translated (perhaps) to completely separate CFS.
    • combination of product characteristic values might result in service characteristic value (can't think of a convincing use case)
    Possibly this complexity could be solved using Policy in the SID - we don't currently have Policy at all in the Open API.

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


Related Content