Open APIs

 View Only
  • 1.  TMF638 - serviceSpecification.id field

    TM Forum Member
    Posted Oct 11, 2021 04:48
    Hi,

    I have a question, for which I would like to have your inputs.
    Under the TMF638, to create a service it is mandatory to populate serviceSpecification.id field. If my understand is correct this field points to an entity created under Service Catalog API (TMF633), however we are not planning to implement this API.
    Under our use case we have 2 types of services, which we were planning to identify by using ServiceType field.
    So, my question is: what should we populated under the serviceSpecification.id? A dummy value?
    Should we use serviceSpecification attribute to distinguish  between the 2 types of services, together with the ServiceType field?

    Many thanks,
    Miguel Leal

    ------------------------------
    Miguel Leal
    Nokia
    ------------------------------


  • 2.  RE: TMF638 - serviceSpecification.id field

    TM Forum Member
    Posted Oct 11, 2021 07:47
    Hi Miguel
    The specification/inventory pattern (e.g. service specification and service inventory) is a fairly basic tenet of the TMF model, both in the Information Framework (SID) and the Open API. In this pattern, it is assumed that each inventory entity is instantiated from a corresponding specification. This spec describes how the inventory entity is to be created or modified. Without a specification, how do you "know" what are the characteristics of the entity, what are the limitations on and rules on characteristic values, and much more.
    So in your case, how do you know what characteristics to give a service, if you don't have a corresponding service spec?
    Am I missing something here?
    Can you give examples (without leaking your IP)?

    ------------------------------
    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: TMF638 - serviceSpecification.id field

    TM Forum Member
    Posted Oct 20, 2021 13:29
    Hi Jonathan,

    thanks and apologies for the late reply.
    I understand what you said, however as I'm considering to start using TMF APIs in an existent data model, whatever we will implement needs to be aligned with what we already have.

    So, in my use case, lets consider the service as being for example a SIM card or a group (which may contain several SIM cards). In summary our service could be of type SIM card or of type group. Each of this service will be assigned with products using the product inventory API.
    I was considering to use ServiceType field to distinguish between SIM or Group. But then we realize that servicespecification.id is a mandatory field.
    In my use case, I was not considering to use the Service Catalog API, because for us the type would be enough to understand the characteristics of what is being given - a service for 1 SIM only or to a group of SIMs.
    Knowing  we only have 2 types of fixed services and we are not considering to implement Service Catalog, I'm not sure what could be the approach for the servicespecification without implementing the mentioned API.

    If the scenario is still unclear to you let me know and I will try to find a more concrete use case.

    Many thanks,
    Miguel Leal


    ------------------------------
    Miguel Leal
    Nokia
    ------------------------------



  • 4.  RE: TMF638 - serviceSpecification.id field

    TM Forum Member
    Posted Oct 25, 2021 05:28
    Hi Miguel
    Firstly, I think that the TMF purists in this community will be surprised by your modeling of a SIM (or a SIM group) as a service. Probably a SIM should be treated as a physical resource. The service (e.g. voice) would be enabled by network and other resources, including the SIM.
    Leaving that aside, and dealing with service, you could as a convention have a set of fixed serviceSpecification.id values, each one corresponding to a different type. If you could be sure that no consumer would ever try to resolve the reference to servicespecification (e.g. by doing a GET on a ServiceSpecification endpoint), then this could work.
    You would have something like:
    {
      "id": "servInv123456",
      "href": "https:8080//mycsproot/apiroot/serviceInventory/v4/service/servInv123456",
      "serviceSpecification: {
         "id": "SimpleService",
         "href": "about:blank"
      }
    }​
    Make sense?

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



  • 5.  RE: TMF638 - serviceSpecification.id field

    TM Forum Member
    Posted Oct 26, 2021 03:29
    Hi Jonathan,
    I understand your comment about the SIM, but this is related with the fact that we need to adapt our existent data model to what we have in TMF.  In our model, the service provide voice, messages, etc to the SIM (physical resource). That service will have the reference to the entity that will use that service - in my example was 1:1 relation and I just called it SIM.

    Regarding your suggestion, it makes all the sense to me.

    Many thanks for your feedback!
    Miguel Leal

    ------------------------------
    Miguel Leal
    Nokia
    ------------------------------