Open APIs

Hi!
Usually BSS Product Management Platform is creating CFS service orders and BSS knows the references with CFS and physical goods(resources)

I am a little bit confused with following

TMF641 ServiceRestriction sub-resource has

supportingResource

A list of resource references (ResourceRef [*]). A list of supporting resources (SupportingResource [*]).Note: only Service of type RFS can be associated with Resources.

supportingService

A list of service references (ServiceRef [*]). A list of supporting services (SupportingService [*]). A collection of services that support this service (bundling, link CFS to RFS).

 

Is it BSS responsibility to decompose both level CFS and RFS services(link CFS to RFS) and use Service Catalog and Service Inventory data for that?

Or it is still service order management systems responsibility to add this information (PATCH serviceOrder)

 

Inspecting TMF641(ServiceOrdering) and TMF645(ServiceQualification) their resource models look similar.

So our OSS architects figured out that BSS Order Management have to take  service qualification resource information and add it as an input while creating service order. So service order management do not need Service Catalog for decomposition and OSS starts the work as BSS predefined.

Could anyone explain how to understand  this API spec?

------------------------------
Kind regards,
Reet Meier
Solutions Architect
Telia Eesti
------------------------------

Hi Reet
My understanding is that according to the Open API model, the BSS layer (order capture and handling) is responsible for decomposition of Product to Service. This is expressed by the fact that the Product Catalog (TMF620) has pointers to the ServiceSpecs that would be instantiated to implement a ProductSpec. This would be done in various business processes, including:

• Checking serviceability - the BSS layer would decompose the product view to service view in order to invoke the Service Qualification API
• Submitting order - the BSS layer would decompose the product view in a submitted product order to the service view for network provisioning by the Service Order API

There is no expectation that the BSS layer would do internal service decomposition (from CFS to RFS), that would be in the OSS layer (e.g. in a Service Order management component)

You could reach out to @Ludovic Robert for additional clarifications.

Hope it helps​​

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------

Hello Reet, Jonathan

I globally agreed with Jonathan. First, the product catalog has the productSpec to CFSSpec relationship.

BSS layer 'calculates' during (product) order fulfillment the CFS to be instanciated (or modified) and then leverage TMF641 ServiceOrder to describe CFS-action to the SOM.
The SOM will determine which RFS to be use for each CFS of the service order. Then, at this point it depends on you SOM/OSS architecture (and exposed capabilities) - In some case you'll trigger resource level action (leveraging resource order API or resource Activation & Configuration API) - in some other case you'll have to send RFS level action (and in this case you could use TMF641 again but at 'RFS' level).

I'm sure The ODA team could provide more relevant comments on this topic.

About serviceQualification, I envision it more in pre ordering phase use....meaning that during order capture (or before) you'll use this API to identify eligible servicesSpec in order to filter relevant  proposed productSspec/productOffering (using again the catalog information).

Hope it helps.



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

Original Message:
Sent: Oct 10, 2019 04:05
From: Jonathan Goldberg
Subject: TMF641 Service Ordering Management API

Hi Reet
My understanding is that according to the Open API model, the BSS layer (order capture and handling) is responsible for decomposition of Product to Service. This is expressed by the fact that the Product Catalog (TMF620) has pointers to the ServiceSpecs that would be instantiated to implement a ProductSpec. This would be done in various business processes, including:

• Checking serviceability - the BSS layer would decompose the product view to service view in order to invoke the Service Qualification API
• Submitting order - the BSS layer would decompose the product view in a submitted product order to the service view for network provisioning by the Service Order API

There is no expectation that the BSS layer would do internal service decomposition (from CFS to RFS), that would be in the OSS layer (e.g. in a Service Order management component)

You could reach out to @Ludovic Robert for additional clarifications.

Hope it helps​​

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------

Hello
Thank you Jonathan and Ludovic. It helps.

I got the answer that I have expected.  We will use only CFS specs references we get from product catalog and create service orders on them.

We have discussed that service qualification done in pre-ordering phase usually does not change during ordering . So if it is not expired by some network event or other reason we can use it as backbone to design and book technical resources in SOM processes. Of course only those on which customer has selected offerings and characteristics.

------------------------------
Reet Meier
Telia Eesti AS
------------------------------

Original Message:
Sent: Oct 10, 2019 05:22
From: Ludovic Robert
Subject: TMF641 Service Ordering Management API

Hello Reet, Jonathan

I globally agreed with Jonathan. First, the product catalog has the productSpec to CFSSpec relationship.

BSS layer 'calculates' during (product) order fulfillment the CFS to be instanciated (or modified) and then leverage TMF641 ServiceOrder to describe CFS-action to the SOM.
The SOM will determine which RFS to be use for each CFS of the service order. Then, at this point it depends on you SOM/OSS architecture (and exposed capabilities) - In some case you'll trigger resource level action (leveraging resource order API or resource Activation & Configuration API) - in some other case you'll have to send RFS level action (and in this case you could use TMF641 again but at 'RFS' level).

I'm sure The ODA team could provide more relevant comments on this topic.

About serviceQualification, I envision it more in pre ordering phase use....meaning that during order capture (or before) you'll use this API to identify eligible servicesSpec in order to filter relevant  proposed productSspec/productOffering (using again the catalog information).

Hope it helps.



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


Original Message:
Sent: Oct 10, 2019 04:05
From: Jonathan Goldberg
Subject: TMF641 Service Ordering Management API

Hi Reet
My understanding is that according to the Open API model, the BSS layer (order capture and handling) is responsible for decomposition of Product to Service. This is expressed by the fact that the Product Catalog (TMF620) has pointers to the ServiceSpecs that would be instantiated to implement a ProductSpec. This would be done in various business processes, including:

• Checking serviceability - the BSS layer would decompose the product view to service view in order to invoke the Service Qualification API
• Submitting order - the BSS layer would decompose the product view in a submitted product order to the service view for network provisioning by the Service Order API

There is no expectation that the BSS layer would do internal service decomposition (from CFS to RFS), that would be in the OSS layer (e.g. in a Service Order management component)

You could reach out to @Ludovic Robert for additional clarifications.

Hope it helps​​

------------------------------
Jonathan Goldberg
Amdocs Management Limited

Hi Robert

The approach toward 641 usage is well defined, but there is one question on which you may be able to help.

For the decomposition from Product to CFS  to take place the catalogue, or  published CFS  must be available in the BSS or commerce layer, what if we want to keep commerce and production ( as per the ODA ) completely separate and use the SOM for decomposition based on 622 ? This would keep  the BSS independent of any service characteristics whatsoever.

In short what is mean by ' "calculates"  the CFS ? ' as this information is available in the service catalogue ? In order to maintain independence between BSS and SOM we can either have the product pointer in the SOM or the service pointer in the BSS , either would work right?    It depends where the decomposition would take place. 

As for the rules, again we have a separation of concerns between commerce and production , so the dependencies would be handled in each respective area.

Your thoughts?

Regards

Peter Skoularikos
Telekinetics 



 


------------------------------
Peter Skoularikos
Telekinetics
------------------------------

Original Message:
Sent: Oct 10, 2019 05:22
From: Ludovic Robert
Subject: TMF641 Service Ordering Management API

Hello Reet, Jonathan

I globally agreed with Jonathan. First, the product catalog has the productSpec to CFSSpec relationship.

BSS layer 'calculates' during (product) order fulfillment the CFS to be instanciated (or modified) and then leverage TMF641 ServiceOrder to describe CFS-action to the SOM.
The SOM will determine which RFS to be use for each CFS of the service order. Then, at this point it depends on you SOM/OSS architecture (and exposed capabilities) - In some case you'll trigger resource level action (leveraging resource order API or resource Activation & Configuration API) - in some other case you'll have to send RFS level action (and in this case you could use TMF641 again but at 'RFS' level).

I'm sure The ODA team could provide more relevant comments on this topic.

About serviceQualification, I envision it more in pre ordering phase use....meaning that during order capture (or before) you'll use this API to identify eligible servicesSpec in order to filter relevant  proposed productSspec/productOffering (using again the catalog information).

Hope it helps.



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


Original Message:
Sent: Oct 10, 2019 04:05
From: Jonathan Goldberg
Subject: TMF641 Service Ordering Management API

Hi Reet
My understanding is that according to the Open API model, the BSS layer (order capture and handling) is responsible for decomposition of Product to Service. This is expressed by the fact that the Product Catalog (TMF620) has pointers to the ServiceSpecs that would be instantiated to implement a ProductSpec. This would be done in various business processes, including:

• Checking serviceability - the BSS layer would decompose the product view to service view in order to invoke the Service Qualification API
• Submitting order - the BSS layer would decompose the product view in a submitted product order to the service view for network provisioning by the Service Order API

There is no expectation that the BSS layer would do internal service decomposition (from CFS to RFS), that would be in the OSS layer (e.g. in a Service Order management component)

You could reach out to @Ludovic Robert for additional clarifications.

Hope it helps​​

------------------------------
Jonathan Goldberg
Amdocs Management Limited

Hi Peter,

Probably ODA team could provide better outputs. From my perspective, and given the fact that a productSpec is build from one CFSSpec (it restricts it) I tend to think that the decomposition will be done in the BSS in the order fulfillment component (retrieving CFS in catalog bijectivly from ProductSpec for add or reading the inventory link product to service for other order action). Doing this decomposition in BSS will also provide you some flexibility has managing severals SOM and then sending separate service order for one product order (it is trick if you do the decomposition in SOM).
I you look of today open apis you'll find alignement with this pattern: serviceSpec is retrievable from productSpec - service from product but not the reverse way.

Hope it helps
Ludovic

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

Original Message:
Sent: Oct 13, 2019 11:26
From: Peter Skoularikos
Subject: TMF641 Service Ordering Management API

Hi Robert

The approach toward 641 usage is well defined, but there is one question on which you may be able to help.

For the decomposition from Product to CFS  to take place the catalogue, or  published CFS  must be available in the BSS or commerce layer, what if we want to keep commerce and production ( as per the ODA ) completely separate and use the SOM for decomposition based on 622 ? This would keep  the BSS independent of any service characteristics whatsoever.

In short what is mean by ' "calculates"  the CFS ? ' as this information is available in the service catalogue ? In order to maintain independence between BSS and SOM we can either have the product pointer in the SOM or the service pointer in the BSS , either would work right?    It depends where the decomposition would take place.

As for the rules, again we have a separation of concerns between commerce and production , so the dependencies would be handled in each respective area.

Your thoughts?

Regards

Peter Skoularikos
Telekinetics






------------------------------
Peter Skoularikos
Telekinetics
------------------------------


Original Message:
Sent: Oct 10, 2019 05:22
From: Ludovic Robert
Subject: TMF641 Service Ordering Management API

Hello Reet, Jonathan

I globally agreed with Jonathan. First, the product catalog has the productSpec to CFSSpec relationship.

BSS layer 'calculates' during (product) order fulfillment the CFS to be instanciated (or modified) and then leverage TMF641 ServiceOrder to describe CFS-action to the SOM.
The SOM will determine which RFS to be use for each CFS of the service order. Then, at this point it depends on you SOM/OSS architecture (and exposed capabilities) - In some case you'll trigger resource level action (leveraging resource order API or resource Activation & Configuration API) - in some other case you'll have to send RFS level action (and in this case you could use TMF641 again but at 'RFS' level).

I'm sure The ODA team could provide more relevant comments on this topic.

About serviceQualification, I envision it more in pre ordering phase use....meaning that during order capture (or before) you'll use this API to identify eligible servicesSpec in order to filter relevant  proposed productSspec/productOffering (using again the catalog information).

Hope it helps.



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


Original Message:
Sent: Oct 10, 2019 04:05
From: Jonathan Goldberg
Subject: TMF641 Service Ordering Management API

Hi Reet
My understanding is that according to the Open API model, the BSS layer (order capture and handling) is responsible for decomposition of Product to Service. This is expressed by the fact that the Product Catalog (TMF620) has pointers to the ServiceSpecs that would be instantiated to implement a ProductSpec. This would be done in various business processes, including:

• Checking serviceability - the BSS layer would decompose the product view to service view in order to invoke the Service Qualification API
• Submitting order - the BSS layer would decompose the product view in a submitted product order to the service view for network provisioning by the Service Order API

There is no expectation that the BSS layer would do internal service decomposition (from CFS to RFS), that would be in the OSS layer (e.g. in a Service Order management component)

You could reach out to @Ludovic Robert for additional clarifications.

Hope it helps​​

------------------------------
Jonathan Goldberg
Amdocs Management Limited

All, we discussed this topic between the SID and the ODA team and Ludovics perspective is pretty much consistent with what we concluded.

The SID does not use directed association, so from a modelling perspective both directions of navigation are possible (from ProductSpecification to CFSS and the other way round) and the association between ProductSpecification and CFSS is n:m - i.e. it would be possible to associate one instance of ProductSpecification with multiple CFSS instances.

However, looking into concrete examples and the way the APIs are designed, the product domain (part of core commerce management aka BSS layer) is exposing the product order interface (TMF622) and the service domain (part of production aka OSS) is exposing the service order interface (TMF641 and TMF 640). So the mapping between ProductSpecification and CFSS in located in the BSS . It is also recommended to map one instance of a ProductSpecification to only one instance of CFSS (which can be a composite of multiple CFSSes according to the composite pattern).

The way the SID is documented is pretty much domain oriented. As members of the TM Forum are asking for cross domain guidelines for product/service/resource modelling we started to put a "vertical modelling guideline" together (based on real-world examples and best-practices) - interested parties are very welcome to join this effort .

A useful source of information might also be the "SID clarification documents" which can be found here: https://www.tmforum.org/resources/how-to-guide/ig1163-information-framework-sid-clarification-documents-r17-5-0/

Hopefully  this post helps to clarify this issue - please contact me if there are any question left.

Best regards,
Dirk


------------------------------
Dirk Rejahl
TM Forum
------------------------------

Original Message:
Sent: Oct 17, 2019 14:55
From: Ludovic Robert
Subject: TMF641 Service Ordering Management API

Hi Peter,

Probably ODA team could provide better outputs. From my perspective, and given the fact that a productSpec is build from one CFSSpec (it restricts it) I tend to think that the decomposition will be done in the BSS in the order fulfillment component (retrieving CFS in catalog bijectivly from ProductSpec for add or reading the inventory link product to service for other order action). Doing this decomposition in BSS will also provide you some flexibility has managing severals SOM and then sending separate service order for one product order (it is trick if you do the decomposition in SOM).
I you look of today open apis you'll find alignement with this pattern: serviceSpec is retrievable from productSpec - service from product but not the reverse way.

Hope it helps
Ludovic

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


Original Message:
Sent: Oct 13, 2019 11:26
From: Peter Skoularikos
Subject: TMF641 Service Ordering Management API

Hi Robert

The approach toward 641 usage is well defined, but there is one question on which you may be able to help.

For the decomposition from Product to CFS  to take place the catalogue, or  published CFS  must be available in the BSS or commerce layer, what if we want to keep commerce and production ( as per the ODA ) completely separate and use the SOM for decomposition based on 622 ? This would keep  the BSS independent of any service characteristics whatsoever.

In short what is mean by ' "calculates"  the CFS ? ' as this information is available in the service catalogue ? In order to maintain independence between BSS and SOM we can either have the product pointer in the SOM or the service pointer in the BSS , either would work right?    It depends where the decomposition would take place.

As for the rules, again we have a separation of concerns between commerce and production , so the dependencies would be handled in each respective area.

Your thoughts?

Regards

Peter Skoularikos
Telekinetics






------------------------------
Peter Skoularikos
Telekinetics


Original Message:
Sent: Oct 10, 2019 05:22
From: Ludovic Robert
Subject: TMF641 Service Ordering Management API

Hello Reet, Jonathan

I globally agreed with Jonathan. First, the product catalog has the productSpec to CFSSpec relationship.

BSS layer 'calculates' during (product) order fulfillment the CFS to be instanciated (or modified) and then leverage TMF641 ServiceOrder to describe CFS-action to the SOM.
The SOM will determine which RFS to be use for each CFS of the service order. Then, at this point it depends on you SOM/OSS architecture (and exposed capabilities) - In some case you'll trigger resource level action (leveraging resource order API or resource Activation & Configuration API) - in some other case you'll have to send RFS level action (and in this case you could use TMF641 again but at 'RFS' level).

I'm sure The ODA team could provide more relevant comments on this topic.

About serviceQualification, I envision it more in pre ordering phase use....meaning that during order capture (or before) you'll use this API to identify eligible servicesSpec in order to filter relevant  proposed productSspec/productOffering (using again the catalog information).

Hope it helps.



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


Original Message:
Sent: Oct 10, 2019 04:05
From: Jonathan Goldberg
Subject: TMF641 Service Ordering Management API

Hi Reet
My understanding is that according to the Open API model, the BSS layer (order capture and handling) is responsible for decomposition of Product to Service. This is expressed by the fact that the Product Catalog (TMF620) has pointers to the ServiceSpecs that would be instantiated to implement a ProductSpec. This would be done in various business processes, including:

• Checking serviceability - the BSS layer would decompose the product view to service view in order to invoke the Service Qualification API
• Submitting order - the BSS layer would decompose the product view in a submitted product order to the service view for network provisioning by the Service Order API

There is no expectation that the BSS layer would do internal service decomposition (from CFS to RFS), that would be in the OSS layer (e.g. in a Service Order management component)

You could reach out to @Ludovic Robert for additional clarifications.

Hope it helps​​

------------------------------
Jonathan Goldberg
Amdocs Management Limited

I picked this discussion a day or so back and  have now discussed with Dirk today as it  lies as the intersection of API, ODA and SID thinking
There is no one way mandated but there are some best practices emerging in ODA driven by the need to publish service  in a catalog and  and expose services that are self contained and support a move to intent base management ultimately implemanted by Autonomous Closed Control Loop solutions. Dirk has summarised the current understanding of best practice for that pathway very succinctly

This topic has come up a few times in the past  and IG1163 C in IG1163 Information Framework (SID) Clarification Documents R17.5.1 has the SID view of the options and best approach and is the most current.
Earlier in the MTOSI standards  for multiple Network technologies a Service Activation and Configuration capability was defined within the Service Domains  There are some useful document covering general concepts of relationship between Product/Customer Domains and Service Domain including process proposals linked into the eTOM
TMF518_SA_1 TMF518_SA_3 in particular.  General principles Are in  in TMF518_SA_1.   
MTOSI 4.0 
Service Management and Operations related – OM-DDPS – ServiceActivation (SA)
mtosi-4-0\service-management-and-operations-related-om-ddps-serviceactivation-sa\Service_Activation.zip\BA\Part1

It is likely that we need to publish in ODA some refresh more prescriptive version of this material described in ODA terms and intent based management .
I am wondering if there is a group of people that would be willing to contribute to putting together a draft or at least a draft contents list for such a document  leveraging this previous materials over the next 6-7 weeks ? This would form on  part of the verticals document that DIrk mentioned ( which need to cover Serivce Resource mapping as well) 

BTW several of these posts need feedback from ODA nd SID team so feel free to add links to staff leads  @Dave Milham to trigger ODA response and @Dirk Rejahl for SID response. This will then catch our attention more quickly. 
​​​​

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

Original Message:
Sent: Oct 18, 2019 12:45
From: Dirk Rejahl
Subject: TMF641 Service Ordering Management API

All, we discussed this topic between the SID and the ODA team and Ludovics perspective is pretty much consistent with what we concluded.

The SID does not use directed association, so from a modelling perspective both directions of navigation are possible (from ProductSpecification to CFSS and the other way round) and the association between ProductSpecification and CFSS is n:m - i.e. it would be possible to associate one instance of ProductSpecification with multiple CFSS instances.

However, looking into concrete examples and the way the APIs are designed, the product domain (part of core commerce management aka BSS layer) is exposing the product order interface (TMF622) and the service domain (part of production aka OSS) is exposing the service order interface (TMF641 and TMF 640). So the mapping between ProductSpecification and CFSS in located in the BSS . It is also recommended to map one instance of a ProductSpecification to only one instance of CFSS (which can be a composite of multiple CFSSes according to the composite pattern).

The way the SID is documented is pretty much domain oriented. As members of the TM Forum are asking for cross domain guidelines for product/service/resource modelling we started to put a "vertical modelling guideline" together (based on real-world examples and best-practices) - interested parties are very welcome to join this effort .

A useful source of information might also be the "SID clarification documents" which can be found here: https://www.tmforum.org/resources/how-to-guide/ig1163-information-framework-sid-clarification-documents-r17-5-0/

Hopefully  this post helps to clarify this issue - please contact me if there are any question left.

Best regards,
Dirk


------------------------------
Dirk Rejahl
TM Forum
------------------------------


Original Message:
Sent: Oct 17, 2019 14:55
From: Ludovic Robert
Subject: TMF641 Service Ordering Management API

Hi Peter,

Probably ODA team could provide better outputs. From my perspective, and given the fact that a productSpec is build from one CFSSpec (it restricts it) I tend to think that the decomposition will be done in the BSS in the order fulfillment component (retrieving CFS in catalog bijectivly from ProductSpec for add or reading the inventory link product to service for other order action). Doing this decomposition in BSS will also provide you some flexibility has managing severals SOM and then sending separate service order for one product order (it is trick if you do the decomposition in SOM).
I you look of today open apis you'll find alignement with this pattern: serviceSpec is retrievable from productSpec - service from product but not the reverse way.

Hope it helps
Ludovic

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


Original Message:
Sent: Oct 13, 2019 11:26
From: Peter Skoularikos
Subject: TMF641 Service Ordering Management API

Hi Robert

The approach toward 641 usage is well defined, but there is one question on which you may be able to help.

For the decomposition from Product to CFS  to take place the catalogue, or  published CFS  must be available in the BSS or commerce layer, what if we want to keep commerce and production ( as per the ODA ) completely separate and use the SOM for decomposition based on 622 ? This would keep  the BSS independent of any service characteristics whatsoever.

In short what is mean by ' "calculates"  the CFS ? ' as this information is available in the service catalogue ? In order to maintain independence between BSS and SOM we can either have the product pointer in the SOM or the service pointer in the BSS , either would work right?    It depends where the decomposition would take place.

As for the rules, again we have a separation of concerns between commerce and production , so the dependencies would be handled in each respective area.

Your thoughts?

Regards

Peter Skoularikos
Telekinetics






------------------------------
Peter Skoularikos
Telekinetics


Original Message:
Sent: Oct 10, 2019 05:22
From: Ludovic Robert
Subject: TMF641 Service Ordering Management API

Hello Reet, Jonathan

I globally agreed with Jonathan. First, the product catalog has the productSpec to CFSSpec relationship.

BSS layer 'calculates' during (product) order fulfillment the CFS to be instanciated (or modified) and then leverage TMF641 ServiceOrder to describe CFS-action to the SOM.
The SOM will determine which RFS to be use for each CFS of the service order. Then, at this point it depends on you SOM/OSS architecture (and exposed capabilities) - In some case you'll trigger resource level action (leveraging resource order API or resource Activation & Configuration API) - in some other case you'll have to send RFS level action (and in this case you could use TMF641 again but at 'RFS' level).

I'm sure The ODA team could provide more relevant comments on this topic.

About serviceQualification, I envision it more in pre ordering phase use....meaning that during order capture (or before) you'll use this API to identify eligible servicesSpec in order to filter relevant  proposed productSspec/productOffering (using again the catalog information).

Hope it helps.



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


Original Message:
Sent: Oct 10, 2019 04:05
From: Jonathan Goldberg
Subject: TMF641 Service Ordering Management API

Hi Reet
My understanding is that according to the Open API model, the BSS layer (order capture and handling) is responsible for decomposition of Product to Service. This is expressed by the fact that the Product Catalog (TMF620) has pointers to the ServiceSpecs that would be instantiated to implement a ProductSpec. This would be done in various business processes, including:

• Checking serviceability - the BSS layer would decompose the product view to service view in order to invoke the Service Qualification API
• Submitting order - the BSS layer would decompose the product view in a submitted product order to the service view for network provisioning by the Service Order API

There is no expectation that the BSS layer would do internal service decomposition (from CFS to RFS), that would be in the OSS layer (e.g. in a Service Order management component)

You could reach out to @Ludovic Robert for additional clarifications.

Hope it helps​​

------------------------------
Jonathan Goldberg
Amdocs Management Limited