TM Forum Community

Hi,

I need to create an application layer on top of BSS application. The role of this layer is to receive requests from client systems, transform and invoke corresponding BSS/OSS APIs as per the requirement. Here, I need to expose a capability to client for Product technical feasibility check (e.g. Fiber Connectivity Product) . In the Open API definitions, I could only find Service Technical feasibility, but not Product Technical feasibility. Usually client systems will mainly have info on Product instead of underlying service.
I checked TMF links related to it i.e.
Use Case UC002: Browse B2C catalogue and check Fiber technical eligibility v1 - Published Deliverables - TM Forum Confluence
https://projects.tmforum.org/wiki/display/PUB/TMF070B+Advanced+Platform+Deployment+Blueprints+R17.5.1?_ga=2.107166212.723378726.1524824266-753906893.1507067474#TMF070BAdvancedPlatformDeploymentBlueprintsR17.5.1-ProductPre-Ordering

But not getting clarity why dont we have an API as Product technical feasibility. Also, in case we have to use service technical feasibility only, then can the service specification id be returned to client in getProductOffering call? Mainly how client systems should fetch Service specification? 

Thanks!
Paras
#General

------------------------------
Paras Agrawal
Infosys
------------------------------

Hi Paras

Firstly, I'd like to understand what you mean by "product technical feasibility". In general, the technical feasibility is determined at the service level. Of course this has a knock-on effect on products that are implemented using these services. But product feasibility includes also commercial considerations (such as credit-worthiness, risks, and more), and these are represented in the product offering qualification API. But perhaps you had in mind additional technical feasibility aspects that are not related to service?

Regarding the relationship between these two APIs, the connection is at the level of product specification and corresponding service specification. The assumption in TM Forum model and architecture (e.g. ODA) is that the Product layer (BSS, Core Commerce) is aware of the Service layer (OSS, Production). When an API consumer gets a result from service qualification, it should be able to use the information in product catalog to map the returned service/service spec into the product implications.

Hope this helps somewhat.


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

Thank You @Jonathan Goldberg for the clarification.
Please check the attached file with my understanding. 
We have a layer on top of BSS/OSS systems. This layer is responsible for receiving and sending messages to other client systems. 
So, should the flow for this access layer be like?
1) Receive Product Offering qualification request from client system
2) Using Product specification, identify Service specification (specific call to BSS??).
3) Make Service qualification call to OSS.
4) Make Product Offering Qualification call to BSS.
5) Send final result to client system.
​

------------------------------
Paras Agrawal
Infosys
------------------------------

Original Message:
Sent: Feb 27, 2022 04:18
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras

Firstly, I'd like to understand what you mean by "product technical feasibility". In general, the technical feasibility is determined at the service level. Of course this has a knock-on effect on products that are implemented using these services. But product feasibility includes also commercial considerations (such as credit-worthiness, risks, and more), and these are represented in the product offering qualification API. But perhaps you had in mind additional technical feasibility aspects that are not related to service?

Regarding the relationship between these two APIs, the connection is at the level of product specification and corresponding service specification. The assumption in TM Forum model and architecture (e.g. ODA) is that the Product layer (BSS, Core Commerce) is aware of the Service layer (OSS, Production). When an API consumer gets a result from service qualification, it should be able to use the information in product catalog to map the returned service/service spec into the product implications.

Hope this helps somewhat.


------------------------------
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 Paras
You might find the ODA end-to-end use case UC002 useful here. It covers exactly the use of the qualification APIs.
Hope it helps.
https://projects.tmforum.org/wiki/display/PUB/IG1228+Use+Case+UC002%3A+Browse+B2C+catalogue+and+check+Fiber+technical+eligibility+v8.0.0

------------------------------
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: Feb 28, 2022 04:00
From: Paras Agrawal
Subject: Confusion on using Product offering qualification and service qualification apis

Thank You @Jonathan Goldberg for the clarification.
Please check the attached file with my understanding.
We have a layer on top of BSS/OSS systems. This layer is responsible for receiving and sending messages to other client systems.
So, should the flow for this access layer be like?
1) Receive Product Offering qualification request from client system
2) Using Product specification, identify Service specification (specific call to BSS??).
3) Make Service qualification call to OSS.
4) Make Product Offering Qualification call to BSS.
5) Send final result to client system.
​

------------------------------
Paras Agrawal
Infosys
------------------------------


Original Message:
Sent: Feb 27, 2022 04:18
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras

Firstly, I'd like to understand what you mean by "product technical feasibility". In general, the technical feasibility is determined at the service level. Of course this has a knock-on effect on products that are implemented using these services. But product feasibility includes also commercial considerations (such as credit-worthiness, risks, and more), and these are represented in the product offering qualification API. But perhaps you had in mind additional technical feasibility aspects that are not related to service?

Regarding the relationship between these two APIs, the connection is at the level of product specification and corresponding service specification. The assumption in TM Forum model and architecture (e.g. ODA) is that the Product layer (BSS, Core Commerce) is aware of the Service layer (OSS, Production). When an API consumer gets a result from service qualification, it should be able to use the information in product catalog to map the returned service/service spec into the product implications.

Hope this helps somewhat.


------------------------------
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 Goldberg. Yes, I had gone through this UC already.
But my query is - can i expose productofferingqualification to client system in the Supplier Partner layer and then , the layer can internally call BSS ​for product offering qualification as well as OSS for service qualification ?

------------------------------
Paras Agrawal
Infosys
------------------------------

Original Message:
Sent: Mar 01, 2022 04:52
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras
You might find the ODA end-to-end use case UC002 useful here. It covers exactly the use of the qualification APIs.
Hope it helps.
https://projects.tmforum.org/wiki/display/PUB/IG1228+Use+Case+UC002%3A+Browse+B2C+catalogue+and+check+Fiber+technical+eligibility+v8.0.0

------------------------------
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: Feb 28, 2022 04:00
From: Paras Agrawal
Subject: Confusion on using Product offering qualification and service qualification apis

Thank You @Jonathan Goldberg for the clarification.
Please check the attached file with my understanding.
We have a layer on top of BSS/OSS systems. This layer is responsible for receiving and sending messages to other client systems.
So, should the flow for this access layer be like?
1) Receive Product Offering qualification request from client system
2) Using Product specification, identify Service specification (specific call to BSS??).
3) Make Service qualification call to OSS.
4) Make Product Offering Qualification call to BSS.
5) Send final result to client system.
​

------------------------------
Paras Agrawal
Infosys


Original Message:
Sent: Feb 27, 2022 04:18
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras

Firstly, I'd like to understand what you mean by "product technical feasibility". In general, the technical feasibility is determined at the service level. Of course this has a knock-on effect on products that are implemented using these services. But product feasibility includes also commercial considerations (such as credit-worthiness, risks, and more), and these are represented in the product offering qualification API. But perhaps you had in mind additional technical feasibility aspects that are not related to service?

Regarding the relationship between these two APIs, the connection is at the level of product specification and corresponding service specification. The assumption in TM Forum model and architecture (e.g. ODA) is that the Product layer (BSS, Core Commerce) is aware of the Service layer (OSS, Production). When an API consumer gets a result from service qualification, it should be able to use the information in product catalog to map the returned service/service spec into the product implications.

Hope this helps somewhat.


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

From Open API perspective, you can do what you like. The Open APIs do not in general constrain or prescribe functional architecture.

ODA tries to go deeper and give a best practice for functional components, and these are surfaced/illustrated by the use cases. But ODA is still a work-in-progress, so it may take time for finalized component specifications to be published.

But maybe @Ludovic Robert and @Sylvie Demarest want to add their advice here.​​

------------------------------
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: Mar 02, 2022 07:27
From: Paras Agrawal
Subject: Confusion on using Product offering qualification and service qualification apis

HI @Jonathan Goldberg. Yes, I had gone through this UC already.
But my query is - can i expose productofferingqualification to client system in the Supplier Partner layer and then , the layer can internally call BSS ​for product offering qualification as well as OSS for service qualification ?

------------------------------
Paras Agrawal
Infosys
------------------------------


Original Message:
Sent: Mar 01, 2022 04:52
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras
You might find the ODA end-to-end use case UC002 useful here. It covers exactly the use of the qualification APIs.
Hope it helps.
https://projects.tmforum.org/wiki/display/PUB/IG1228+Use+Case+UC002%3A+Browse+B2C+catalogue+and+check+Fiber+technical+eligibility+v8.0.0

------------------------------
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: Feb 28, 2022 04:00
From: Paras Agrawal
Subject: Confusion on using Product offering qualification and service qualification apis

Thank You @Jonathan Goldberg for the clarification.
Please check the attached file with my understanding.
We have a layer on top of BSS/OSS systems. This layer is responsible for receiving and sending messages to other client systems.
So, should the flow for this access layer be like?
1) Receive Product Offering qualification request from client system
2) Using Product specification, identify Service specification (specific call to BSS??).
3) Make Service qualification call to OSS.
4) Make Product Offering Qualification call to BSS.
5) Send final result to client system.
​

------------------------------
Paras Agrawal
Infosys


Original Message:
Sent: Feb 27, 2022 04:18
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras

Firstly, I'd like to understand what you mean by "product technical feasibility". In general, the technical feasibility is determined at the service level. Of course this has a knock-on effect on products that are implemented using these services. But product feasibility includes also commercial considerations (such as credit-worthiness, risks, and more), and these are represented in the product offering qualification API. But perhaps you had in mind additional technical feasibility aspects that are not related to service?

Regarding the relationship between these two APIs, the connection is at the level of product specification and corresponding service specification. The assumption in TM Forum model and architecture (e.g. ODA) is that the Product layer (BSS, Core Commerce) is aware of the Service layer (OSS, Production). When an API consumer gets a result from service qualification, it should be able to use the information in product catalog to map the returned service/service spec into the product implications.

Hope this helps somewhat.


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

Hello

Just to add some historical context here....

Initially ProductOfferingQualification was able to manage both the technical & commercial eligibility but we get a lot of feedback from the community about the confusion between both. So, we moved to 2 distinct API with clear scope. Additionally the catalog API - resource Product Specification - allow you to link the Product catalog layer <-> Service Catalog layer.
Nevertheless, your point, Paras is very valid, the ProductOfferingQualification API scope when exposed to an external partner is a very good question. For example, in TMF API use, in MEF context the ProductOfferingQualification is supposed to handle both technical & commercial checks. Indeed 1/we do not want to expose service specification to external and 2/we want to limit API call.

Hope it helps,
Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------

Original Message:
Sent: Mar 02, 2022 08:37
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

From Open API perspective, you can do what you like. The Open APIs do not in general constrain or prescribe functional architecture.

ODA tries to go deeper and give a best practice for functional components, and these are surfaced/illustrated by the use cases. But ODA is still a work-in-progress, so it may take time for finalized component specifications to be published.

But maybe @Ludovic Robert and @Sylvie Demarest want to add their advice here.​​

------------------------------
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: Mar 02, 2022 07:27
From: Paras Agrawal
Subject: Confusion on using Product offering qualification and service qualification apis

HI @Jonathan Goldberg. Yes, I had gone through this UC already.
But my query is - can i expose productofferingqualification to client system in the Supplier Partner layer and then , the layer can internally call BSS ​for product offering qualification as well as OSS for service qualification ?

------------------------------
Paras Agrawal
Infosys


Original Message:
Sent: Mar 01, 2022 04:52
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras
You might find the ODA end-to-end use case UC002 useful here. It covers exactly the use of the qualification APIs.
Hope it helps.
https://projects.tmforum.org/wiki/display/PUB/IG1228+Use+Case+UC002%3A+Browse+B2C+catalogue+and+check+Fiber+technical+eligibility+v8.0.0

------------------------------
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: Feb 28, 2022 04:00
From: Paras Agrawal
Subject: Confusion on using Product offering qualification and service qualification apis

Thank You @Jonathan Goldberg for the clarification.
Please check the attached file with my understanding.
We have a layer on top of BSS/OSS systems. This layer is responsible for receiving and sending messages to other client systems.
So, should the flow for this access layer be like?
1) Receive Product Offering qualification request from client system
2) Using Product specification, identify Service specification (specific call to BSS??).
3) Make Service qualification call to OSS.
4) Make Product Offering Qualification call to BSS.
5) Send final result to client system.
​

------------------------------
Paras Agrawal
Infosys


Original Message:
Sent: Feb 27, 2022 04:18
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras

Firstly, I'd like to understand what you mean by "product technical feasibility". In general, the technical feasibility is determined at the service level. Of course this has a knock-on effect on products that are implemented using these services. But product feasibility includes also commercial considerations (such as credit-worthiness, risks, and more), and these are represented in the product offering qualification API. But perhaps you had in mind additional technical feasibility aspects that are not related to service?

Regarding the relationship between these two APIs, the connection is at the level of product specification and corresponding service specification. The assumption in TM Forum model and architecture (e.g. ODA) is that the Product layer (BSS, Core Commerce) is aware of the Service layer (OSS, Production). When an API consumer gets a result from service qualification, it should be able to use the information in product catalog to map the returned service/service spec into the product implications.

Hope this helps somewhat.


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

Thanks @Ludovic Robert! Got the clarity now.

------------------------------
Paras Agrawal
Infosys
------------------------------

Original Message:
Sent: Mar 02, 2022 09:06
From: Ludovic Robert
Subject: Confusion on using Product offering qualification and service qualification apis

Hello

Just to add some historical context here....

Initially ProductOfferingQualification was able to manage both the technical & commercial eligibility but we get a lot of feedback from the community about the confusion between both. So, we moved to 2 distinct API with clear scope. Additionally the catalog API - resource Product Specification - allow you to link the Product catalog layer <-> Service Catalog layer.
Nevertheless, your point, Paras is very valid, the ProductOfferingQualification API scope when exposed to an external partner is a very good question. For example, in TMF API use, in MEF context the ProductOfferingQualification is supposed to handle both technical & commercial checks. Indeed 1/we do not want to expose service specification to external and 2/we want to limit API call.

Hope it helps,
Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------


Original Message:
Sent: Mar 02, 2022 08:37
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

From Open API perspective, you can do what you like. The Open APIs do not in general constrain or prescribe functional architecture.

ODA tries to go deeper and give a best practice for functional components, and these are surfaced/illustrated by the use cases. But ODA is still a work-in-progress, so it may take time for finalized component specifications to be published.

But maybe @Ludovic Robert and @Sylvie Demarest want to add their advice here.​​

------------------------------
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: Mar 02, 2022 07:27
From: Paras Agrawal
Subject: Confusion on using Product offering qualification and service qualification apis

HI @Jonathan Goldberg. Yes, I had gone through this UC already.
But my query is - can i expose productofferingqualification to client system in the Supplier Partner layer and then , the layer can internally call BSS ​for product offering qualification as well as OSS for service qualification ?

------------------------------
Paras Agrawal
Infosys


Original Message:
Sent: Mar 01, 2022 04:52
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras
You might find the ODA end-to-end use case UC002 useful here. It covers exactly the use of the qualification APIs.
Hope it helps.
https://projects.tmforum.org/wiki/display/PUB/IG1228+Use+Case+UC002%3A+Browse+B2C+catalogue+and+check+Fiber+technical+eligibility+v8.0.0

------------------------------
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: Feb 28, 2022 04:00
From: Paras Agrawal
Subject: Confusion on using Product offering qualification and service qualification apis

Thank You @Jonathan Goldberg for the clarification.
Please check the attached file with my understanding.
We have a layer on top of BSS/OSS systems. This layer is responsible for receiving and sending messages to other client systems.
So, should the flow for this access layer be like?
1) Receive Product Offering qualification request from client system
2) Using Product specification, identify Service specification (specific call to BSS??).
3) Make Service qualification call to OSS.
4) Make Product Offering Qualification call to BSS.
5) Send final result to client system.
​

------------------------------
Paras Agrawal
Infosys


Original Message:
Sent: Feb 27, 2022 04:18
From: Jonathan Goldberg
Subject: Confusion on using Product offering qualification and service qualification apis

Hi Paras

Firstly, I'd like to understand what you mean by "product technical feasibility". In general, the technical feasibility is determined at the service level. Of course this has a knock-on effect on products that are implemented using these services. But product feasibility includes also commercial considerations (such as credit-worthiness, risks, and more), and these are represented in the product offering qualification API. But perhaps you had in mind additional technical feasibility aspects that are not related to service?

Regarding the relationship between these two APIs, the connection is at the level of product specification and corresponding service specification. The assumption in TM Forum model and architecture (e.g. ODA) is that the Product layer (BSS, Core Commerce) is aware of the Service layer (OSS, Production). When an API consumer gets a result from service qualification, it should be able to use the information in product catalog to map the returned service/service spec into the product implications.

Hope this helps somewhat.


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