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.
------------------------------
Original Message:
Sent: Oct 20, 2021 13:29
From: Miguel Leal
Subject: TMF638 - serviceSpecification.id field
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
Original Message:
Sent: Oct 11, 2021 07:47
From: Jonathan Goldberg
Subject: TMF638 - serviceSpecification.id field
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.
Original Message:
Sent: Oct 11, 2021 04:48
From: Miguel Leal
Subject: TMF638 - serviceSpecification.id field
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
------------------------------