Open APIs

Hi Every one,

Can some one help me understand the logic behind this attribute 'serviceRelationship'. The description says "A list of service relationships (ServiceRelationship [*]). Describes links with other service(s) in the inventory.".  Any practical use-case for this attribute is much appreciated.

Thanks,
Dileep

------------------------------
dileep narla
Oracle Corporation
------------------------------

Hi Dileep
For example, TV 4k service might be considered as dependent on Broadband fiber access service
Does this help?

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

Hi Jonathan

Thanks for the quick reply. From your example, can we assume that both TV 4k and Broadband fiber access service are different CFS in inventory. If so, TV 4k activation dependent on Broadband access service. In inventory, do we need to put a check for this lets say at feasibility Check stage ?

What is different between serviceRelationship and supportingService fields. Assuming supportingService holds all RFS services belongs to that CFS service.

Correct me if my understanding is wrong.

------------------------------
dileep narla
Oracle Corporation
------------------------------

Original Message:
Sent: Dec 09, 2021 15:02
From: Jonathan Goldberg
Subject: TMF638 API Spec attribute "serviceRelationship"

Hi Dileep
For example, TV 4k service might be considered as dependent on Broadband fiber access service
Does this help?

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

Hi Dileep
I'm far from being an OSS expert or modeling maven. In general it's up to you how to model your services. But TMF ODA is starting to develop some best practices for end-to-end catalog modeling (product, service, resource). In IG1228 you will find some draft modeling suggestions (currently for fiber and mobile lines-of-business). Suggest you take a look there for clarifications. 
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: Dec 10, 2021 01:17
From: dileep narla
Subject: TMF638 API Spec attribute "serviceRelationship"

Hi Jonathan

Thanks for the quick reply. From your example, can we assume that both TV 4k and Broadband fiber access service are different CFS in inventory. If so, TV 4k activation dependent on Broadband access service. In inventory, do we need to put a check for this lets say at feasibility Check stage ?

What is different between serviceRelationship and supportingService fields. Assuming supportingService holds all RFS services belongs to that CFS service.

Correct me if my understanding is wrong.

------------------------------
dileep narla
Oracle Corporation
------------------------------


Original Message:
Sent: Dec 09, 2021 15:02
From: Jonathan Goldberg
Subject: TMF638 API Spec attribute "serviceRelationship"

Hi Dileep
For example, TV 4k service might be considered as dependent on Broadband fiber access service
Does this help?

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

there are also some modelling guideline for products nd reources in 

IG1233 Product & Service Modelling Best Practices – Conforming to ODA v2.0.0
There is a broadband modelling example and an email example.  However this only looks at RFS resource examples not those based on Resource Functions which is needed for virtualisation cases

------------------------------
Dave Milham
TM Forum, Chief Architect
------------------------------

Original Message:
Sent: Dec 10, 2021 04:08
From: Jonathan Goldberg
Subject: TMF638 API Spec attribute "serviceRelationship"

Hi Dileep
I'm far from being an OSS expert or modeling maven. In general it's up to you how to model your services. But TMF ODA is starting to develop some best practices for end-to-end catalog modeling (product, service, resource). In IG1228 you will find some draft modeling suggestions (currently for fiber and mobile lines-of-business). Suggest you take a look there for clarifications.
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: Dec 10, 2021 01:17
From: dileep narla
Subject: TMF638 API Spec attribute "serviceRelationship"

Hi Jonathan

Thanks for the quick reply. From your example, can we assume that both TV 4k and Broadband fiber access service are different CFS in inventory. If so, TV 4k activation dependent on Broadband access service. In inventory, do we need to put a check for this lets say at feasibility Check stage ?

What is different between serviceRelationship and supportingService fields. Assuming supportingService holds all RFS services belongs to that CFS service.

Correct me if my understanding is wrong.

------------------------------
dileep narla
Oracle Corporation


Original Message:
Sent: Dec 09, 2021 15:02
From: Jonathan Goldberg
Subject: TMF638 API Spec attribute "serviceRelationship"

Hi Dileep
For example, TV 4k service might be considered as dependent on Broadband fiber access service
Does this help?

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