All the catalog APIs, including Service Catalog Management, allow definition of self-relationships between the principal catalog entities. Thus you have ServiceSpecificationRelationship (currently ServiceSpecRelationship but likely to be renamed) with which you would define parent-child relationships between ServiceSpecs, or indeed any other type of relationship (e.g. dependency).
The examples in the published spec document include a dependency relationship from a firewall to a DPI, thus:
{
"id": "7655",
"href": "https://mycsp.com:8080/tmf-api/serviceCatalogManagement/v4/serviceSpecification/7655",
"name": "Firewall Service",
"description": "This service specification describes a firewall service that can be deployed in customer premise.",
"serviceSpecRelationship": [
{
"relationshipType": "dependency",
"role": "dependent",
"id": "5563",
"href": "https://mycsp.com:8080/tmf-api/serviceCatalogManagement/v4/serviceSpecification/5563",
"name": "Points to the Deep Packet Inspection service on which this Firewall service depends",
"validFor": {
"startDateTime": "2017-08-25T00:00",
"endDateTime": "2018-03-25T00:00"
}
}
}
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.
------------------------------
Original Message:
Sent: Nov 11, 2019 06:25
From: Rakesh Girija Ramesan Nair
Subject: TMF 633 service category hierarchy and service candidate
Even I have a query in similar lines, on how we need to maintain the Service Hierarchy in service catalog . How do we maintain that in catalog , is there any specific relationship that we have or do we need to implement one of our own ?
Regards,
Rakesh G R
------------------------------
Rakesh Girija Ramesan Nair
Infosys
Original Message:
Sent: Jul 24, 2019 01:58
From: Shino Jacob
Subject: TMF 633 service category hierarchy and service candidate
Thanks Jonathan for clarifying.
I was working on another product which had capabilities like ,services has an inheritance model and not just for category.
I thought with TMF 633, I can have a very flat hierarchy for service candidates.
and relate service spec to each other any way I wish.
I was wondering if my this understanding about the TMF633 is wrong or not.
------------------------------
Shino Jacob
Infosys
Original Message:
Sent: Jul 21, 2019 05:13
From: Jonathan Goldberg
Subject: TMF 633 service category hierarchy and service candidate
Hi Shino
A category tree in the catalog allows organization of the catalog items by category. This is completely optional and is an implementation decision based on your business use cases. Typically to allow easier navigation of the catalog.
Let's take the Product Catalog (TMF 620) as an example – you might create a Content catalog, and within this catalog you could have root categories Films, Music, eBooks. Then each category would have subcategories, say for Films you could have Documentaries, Romance, Thriller, SciFi, etc.
Catalog materials, in particular Product Offerings, would be attached to relevant categories.
A discovery UI might choose to render the category tree, or search for catalog items by categories.
Personally I am less sure that there is a good use case for categories in Service and Resource, but maybe that's because I am not so familiar with those functional areas.
Anyway I don't think there is a direct impact on ServiceCandidate, you can have candidates without categories.
Hope it helps.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Original Message:
Sent: Jul 19, 2019 04:59
From: Shino Jacob
Subject: TMF 633 service category hierarchy and service candidate
Hi,
What is the use of category hierarchy. How does it affect a service candidate of a child category?
------------------------------
Shino Jacob
Infosys
------------------------------