Open APIs

 View Only
  • 1.  TM633 Service Catalog - ServiceFeatureSpecification - href attribute

    TM Forum Member
    Posted 26 days ago
    Hi Everyone,

    The ServiceFeatureSpecification contains a href attribute. Does this imply that the TMF633 implementation should support a GET endpoint for this href URI?
    If yes, would it look something like:
    serviceCatalogManagement/v4/serviceSpecification/aa5d00c3-9758-40ca-a1cf-bce4ddcd3f4f/featureSpecification/f3b54fcc-66bc-4a7d-8831-2479fbcd09ce

    Currently the TMF633 Swagger does not have GET endpoint for featureSpecification.



    Thanks,



    ------------------------------
    Anu Aulakh
    Telstra Corporation
    ------------------------------


  • 2.  RE: TM633 Service Catalog - ServiceFeatureSpecification - href attribute

    TM Forum Member
    Posted 25 days ago
    Edited by Kinshuk Kulshreshtha 25 days ago

    Hi Anu,

    I believe href is an optional attribute and it is not mandatory to have it in the model. In my view, TMF has left these optional attributes up-to vendor implementations based on their specific needs. I see a lot of entities across various TMF API specifications that has hrefs but the corresponding Open API does not specify explicit GET endpoint for them. I think for such cases, we are free to provide a GET endpoint if it is needed for our requirements, but TMF does not mandate them.

    On the topic of format of GET endpoint, I guess. we can define Features Specifications that can be used across multiple Service Specifications. So, the endpoint should ideally not have the id of the service specification in the url. It can just be as follows in my view. But there could be reasons why you would want to do it in the way you have specified as well

    serviceCatalogManagement/v4/featureSpecification/f3b54fcc-66bc-4a7d-8831-2479fbcd09ce


    Regards,
    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 3.  RE: TM633 Service Catalog - ServiceFeatureSpecification - href attribute

    TM Forum Member
    Posted 23 days ago
    Hi
    To me it looks more like an error, since (at least currently) FeatureSpec is not an independently manageable entity. The schema for FeatureSpec includes Entity when instead it should include Extensible. (both in Service and in Resource domains).
    I'm opening a defect report, but of course if someone can come up with a good use case for FeatureSpec to be independently manageable we could think again ...
    Adding @Kamal Maghsoudlou and @Vance Shipley for their thoughts.​​​

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



  • 4.  RE: TM633 Service Catalog - ServiceFeatureSpecification - href attribute

    TM Forum Member
    Posted 23 days ago
    Hi @Jonathan Goldberg,

    Yes that's the clarification we were seeking, is FeatureSpec meant to be an ​independently manageable entity? Could you please share the defect JIRA number?

    Thanks,
    Anu


    ------------------------------
    Anu Aulakh
    Telstra Corporation
    ------------------------------



  • 5.  RE: TM633 Service Catalog - ServiceFeatureSpecification - href attribute

    TM Forum Member
    Posted 23 days ago
    https://projects.tmforum.org/jira/browse/AP-4164

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



  • 6.  RE: TM633 Service Catalog - ServiceFeatureSpecification - href attribute

    TM Forum Member
    Posted 22 days ago
    I think there may be some cases where querying features independently can make sense. A feature with a set of characteristics can be present in multiple services. This may get more common on RFS side where there can be multiple technology implementations providing same feature. In cases when you synchronize your Technical Catalog, with an external downstream systems, you may want to expose 2 layers of information. A first level query where it only provide the existence of a feature. And a second level query where you get all the details of the features that exists. 

    This will help particularly the cases where there are a lot of possible features, as specified by standards like 3GPP, but a vendor has chosen to implement only a few of those in their system. So, the Catalog will have all the features with their details, while downstream systems will get only the details of the features that it supports.


    Regards,
    Kinshuk