Open APIs

Hi All,

I was looking through the user guide for TMF633 and looking at the content on the Service Catalog resource. Its description illustrates its purpose to link service candidates to a catalog which makes sense but i didn't see in the entity model how the catalog model actually links to the candidate model. For example there is no array of Service Candidates. The JSON example also doesn't show anything to do with any relationship and rather just focuses on the catalog itself and not the related items. Feels like i must be missing something so a quick pointer would be great.

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

Hi All,

I was looking through the user guide for TMF633 and looking at the content on the Service Catalog resource. Its description illustrates its purpose to link service candidates to a catalog which makes sense but i didn't see in the entity model how the catalog model actually links to the candidate model. For example there is no array of Service Candidates. The JSON example also doesn't show anything to do with any relationship and rather just focuses on the catalog itself and not the related items. Feels like i must be missing something so a quick pointer would be great.

To be honest, I had suggested in the past that we should simply the service (and resource) model by removing the Candidate entity. However my suggestion was rejected, so the ServiceCandidate and ResourceCandidate entities remain. I think that @Koen Peeters has posted in the community explaining what use cases might justify the existence of the Candidate entities.

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

Hi All,

I was looking through the user guide for TMF633 and looking at the content on the Service Catalog resource. Its description illustrates its purpose to link service candidates to a catalog which makes sense but i didn't see in the entity model how the catalog model actually links to the candidate model. For example there is no array of Service Candidates. The JSON example also doesn't show anything to do with any relationship and rather just focuses on the catalog itself and not the related items. Feels like i must be missing something so a quick pointer would be great.

@Koen Peeters could you drop a link to the thread please?

@Jonathan Goldberg  thanks for your reply.

I guess i wasnt as such questioning the existence of the service candidate it was more that i didnt see what endpoint you can use in the TMF API to bring back a list of service candidates associated with a service catalog. Is the answer that you must...

1. request the catalog to get a list of categories
2. request the categories based on the list received from 1
3. request for the candidates based on the list received from 2
4. request for the specifications based on the list received from 3

So 4 different endpoint calls to get to what i guess is the 'actual' items within the catalog?

Doesnt this relationship of Specification --> Candidate --> Category --> Catalog have its drawbacks? What if i don't want all of the candidates from a specific category within a catalog? Or is there a different way to achieve?

thanks

Dave

To be honest, I had suggested in the past that we should simply the service (and resource) model by removing the Candidate entity. However my suggestion was rejected, so the ServiceCandidate and ResourceCandidate entities remain. I think that @Koen Peeters has posted in the community explaining what use cases might justify the existence of the Candidate entities.

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

Hi All,

I was looking through the user guide for TMF633 and looking at the content on the Service Catalog resource. Its description illustrates its purpose to link service candidates to a catalog which makes sense but i didn't see in the entity model how the catalog model actually links to the candidate model. For example there is no array of Service Candidates. The JSON example also doesn't show anything to do with any relationship and rather just focuses on the catalog itself and not the related items. Feels like i must be missing something so a quick pointer would be great.

Hi David
It's important to be aware that the relationship models in TMF Open API are generally uni-directional. So in the service catalog area this implies that direct retrieval works in the way you describe. But this doesn't stop reverse retrieval by query, so you could do a direct GET of all the service candidates and use Category, or even Catalog, as a filter criterion.

@Koen Peeters could you drop a link to the thread please?

@Jonathan Goldberg  thanks for your reply.

I guess i wasnt as such questioning the existence of the service candidate it was more that i didnt see what endpoint you can use in the TMF API to bring back a list of service candidates associated with a service catalog. Is the answer that you must...

1. request the catalog to get a list of categories
2. request the categories based on the list received from 1
3. request for the candidates based on the list received from 2
4. request for the specifications based on the list received from 3

So 4 different endpoint calls to get to what i guess is the 'actual' items within the catalog?

Doesnt this relationship of Specification --> Candidate --> Category --> Catalog have its drawbacks? What if i don't want all of the candidates from a specific category within a catalog? Or is there a different way to achieve?

thanks

Dave

To be honest, I had suggested in the past that we should simply the service (and resource) model by removing the Candidate entity. However my suggestion was rejected, so the ServiceCandidate and ResourceCandidate entities remain. I think that @Koen Peeters has posted in the community explaining what use cases might justify the existence of the Candidate entities.

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

Hi All,

I was looking through the user guide for TMF633 and looking at the content on the Service Catalog resource. Its description illustrates its purpose to link service candidates to a catalog which makes sense but i didn't see in the entity model how the catalog model actually links to the candidate model. For example there is no array of Service Candidates. The JSON example also doesn't show anything to do with any relationship and rather just focuses on the catalog itself and not the related items. Feels like i must be missing something so a quick pointer would be great.

@Koen Peeters could you drop a link to the thread please?

@Jonathan Goldberg  thanks for your reply.

I guess i wasnt as such questioning the existence of the service candidate it was more that i didnt see what endpoint you can use in the TMF API to bring back a list of service candidates associated with a service catalog. Is the answer that you must...

1. request the catalog to get a list of categories
2. request the categories based on the list received from 1
3. request for the candidates based on the list received from 2
4. request for the specifications based on the list received from 3

So 4 different endpoint calls to get to what i guess is the 'actual' items within the catalog?

Doesnt this relationship of Specification --> Candidate --> Category --> Catalog have its drawbacks? What if i don't want all of the candidates from a specific category within a catalog? Or is there a different way to achieve?

thanks

Dave

------------------------------
David Whitfield
TalkTalk Group

Original Message:
Sent: May 21, 2023 08:47
From: Jonathan Goldberg
Subject: Service Catalog --> Service Candidate Link

To be honest, I had suggested in the past that we should simply the service (and resource) model by removing the Candidate entity. However my suggestion was rejected, so the ServiceCandidate and ResourceCandidate entities remain. I think that @Koen Peeters has posted in the community explaining what use cases might justify the existence of the Candidate entities.

------------------------------
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: May 18, 2023 03:48
From: Abel Ruiz Huerta
Subject: Service Catalog --> Service Candidate Link

Hi David,

What I interpret in the document is that there should always have a category in the middle. I mean, a specification is made available to a category through a candidate. In turn, the category can be related to several catalogs. So, the relationship between the candidate and the catalog is established through the category.

Hope it helps.

Regards,

------------------------------
Abel Ruiz Huerta
alvatross by SATEC

Original Message:
Sent: May 17, 2023 10:45
From: David Whitfield
Subject: Service Catalog --> Service Candidate Link

Hi All,

I was looking through the user guide for TMF633 and looking at the content on the Service Catalog resource. Its description illustrates its purpose to link service candidates to a catalog which makes sense but i didn't see in the entity model how the catalog model actually links to the candidate model. For example there is no array of Service Candidates. The JSON example also doesn't show anything to do with any relationship and rather just focuses on the catalog itself and not the related items. Feels like i must be missing something so a quick pointer would be great.

------------------------------
David Whitfield
TalkTalk Group
------------------------------