Open APIs

 View Only
  • 1.  TMF_620 Product Catalog Management API Service/Resource Candidate meaning

    TM Forum Member
    Posted Oct 28, 2019 05:43

    Hi,

    I would like to understand the Service Candidate/Resource candidate  meaning, use and relations.

    - Product Offering may have 0..1 Service Candidate/ 0..1 Resource candidate;

    - Service candidate may have 1 CFSSpec- the service specification implied by this candidate;

    - ProductSpecification resource may have 0..n Service Specifications.

    ServiceCandidate is an entity that makes a ServiceSpecification available to a catalog.

     
    ProductOffering via productSpecification(also under composite PS hierarchy) is usually related to more than 1 service specification. What does this parallel relation via product offering mean and  in which processes is service candidate used?
     

    From thread <https://engage.tmforum.org/communities/community-home/digestviewer/viewthread?GroupId=31&MessageKey=d61702fa-44c0-47bb-9fe3-34a3103ea86c&CommunityKey=d543b8ba-9d3a-4121-85ce-5b68e6c31ce5&tab=digestviewer&ReturnUrl=%2fcommunities%2fcommunity-home%2fdigestviewer%3fcommunitykey%3dd543b8ba-9d3a-4121-85ce-5b68e6c31ce5%26tab%3ddigestviewer>

    "It is also recommended to map one instance of a ProductSpecification to only one instance of CFSS (which can be a composite of multiple CFSSes according to the composite pattern)."

    So  if we have to decide in our technical solution integration do we allow only 1 or also many  CFSSpecs related to ProductsSpecification  what will be the recommendation?



    ------------------------------
    Kind regards
    Reet Meier
    Telia Eesti AS
    ------------------------------


  • 2.  RE: TMF_620 Product Catalog Management API Service/Resource Candidate meaning

    TM Forum Member
    Posted Oct 28, 2019 11:16
    Hi Reet

    You have asked an excellent question.
    Broadly speaking, ServiceCandidate and ResourceCandidate model exposure of Service or Resource Specifications in a particular Service or Resource Catalog. The concept of Candidate is indeed only relevant if you have multiple catalogs.
    But it is not clear to me what the added value is, given that the Candidate=>Specification relationship is 1 (or more accurately 0..1), and there are no attributes with significant business meaning in the Candidate. Some weeks ago I raised change requests on the Open API and on the SID to completely remove the Candidate concepts from Service and Resource. If you have access to the Frameworx and Open API JIRA repositories you can see these CRs FX-872 and AP-1382. Of course I cannot say whether these CRs will be accepted or rejected.

    In any case, with the current model as-is, the idea is that the product catalog is expected to know both at offering and specification level which services and resources implement the product:
    • At product offering level this is done by referring to the service/resource candidate
    • At product spec level this is done by the referring to the actual service/resource specification
    Clearly the catalog implementor must ensure consistency, so when authoring the catalog she must take care to ensure that the referred service candidate corresponds to the referred service spec (for example).

    Hope it helps

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



  • 3.  RE: TMF_620 Product Catalog Management API Service/Resource Candidate meaning

    TM Forum Member
    Posted Oct 31, 2019 09:49

    Thank you Jonathan for clarification.

     The idea of raising change request sounds good. We had TMF Open API training in spring and as I remember Pierre Gauthier also said not to pay attention to this. But now everybody is asking this.

     Just one thing more.

    "In any case, with the current model as-is, the idea is that the product catalog is expected to know both at offering and specification level which services and resources implement the product."

     Why is it important to know it in both level?  I suppose it is related with using it in processes otherwise you need to ask separately from productSpecification resource. For example to determine physical resource or service and to start service qualification TMF645 and later create service orders TMF641.



    ------------------------------
    Reet Meier
    Telia Eesti AS
    ------------------------------



  • 4.  RE: TMF_620 Product Catalog Management API Service/Resource Candidate meaning

    TM Forum Member
    Posted Oct 31, 2019 10:06
    Hi Reet

    I believe that @Pierre Gauthier supports the proposal to remove xxxxCandidate in principle, but it will probably take time to get everyone on board and agreed. So until it happens we will continue to have the xxxxCandidate in the API model.

    Any individual implementation of the Product Catalog API will have to decide if the xxxxCandidate concept is relevant - as far as I understand the API conformance will not fail if this is not supported, and in any case the concept is not relevant if there is only a single instance of Catalog.



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