Open APIs

Hi
I see that there are a number of discussions on the 'resourceCandidate' for various TMF OpenaAPIs. I wanted to run this by you, to ensure my understanding is correct.
Scenario:
We are offering Product Offering for wholesale Fibre Broadband services. Each Product Offering can support various Optical Terminal Terminals (ONT/ONU), but only "one-of" these ONTs is implemented with the service (which is decided when fibre is first installed or when the service is activated where the ONT is pre-isntalled).

Open API TMF620 
In the TMF620 Open API for the Product Catalog, in the response for the GET ProductOffering, it specifies the following:

• Product Offering is an Array - this is okay to support each of the Product Offers
• Under the Properties, it shows the 'resourceCandidate' 

Problem:
The 'resourceCandidate' is an Object (and this is reinforced in TMF620B 'ProductOffering Resource Mandatory Attributes' section on page '9 of 10' where it states "A single Resource Candidate ref (not an array)".

Possible Options:
The following are the possible options I have:

1. change the 'resourceCandidate' to an Array - however, this can be misleading as, it can assume we require All-of these array objects, whereas I only require Any-one of these - which I cannot identify at the Product Offer level until the product is ordered as a specified premise (address).
2. remove the 'resourceCandidate' from the Product Offering.
3. Have 'resourceCandidate' supported by enum, with a default setting (therefore breaking out the swagger for this scenario) - thinking about it I don't think this option will work very well.

Can you please identify if this logic is correct and which of the possible options are valid, or if there is an alternative approach to this?

Many thanks
Pete

------------------------------
Pete Bains
Ultrafast Fibre Limited
------------------------------

Hi Pete,

I like the use case you are presenting.
There exist two distinct use cases when selling GoodsProducts.

In the first use case the actual ResourceCandidate behind a ProductOffering is important for the customer. The customer in this case wants a "Pink Samsumg Galaxy S22 with 256GB memory", not just any smartphone. To model this use case a ProductOffering is linked to a specific resourceCandidate.


In the the second use case the customer doesn't care about the actual model as in the case of the ONT in your use case. In that case the ProductOffering is not linked to a specific ResourceCandidate. It is only linked to a ResourceSpecification "ONT" via the ProductSpecification. This actually means that the decision about which ResourceCandidate is deferred. At some later point in the fulfilment process, not later than the start of installation, the actual ResourceCandidate will be chosen. The decision can be based on criteria that come from the service (Hyperfibre requires model C or D) and stock availability. (the technician has a refurbished ONT model D in his truck)
For this use case I suggest indeed to remove the ResourceCandidate from the ProductOffering.
If you technician has an installation app, he will probably see on hit workorder that he needs to pick a model C or a model D. When he scans a a Model A the app will tell him that this device is not compatible with the service. When he scans the refurbished model D, the app will trigger the registration of the serial number of the ONT on the OLT.

I hope this is helpful  to you.

Regards


------------------------------
Koen Peeters
OryxGateway
------------------------------

Hi
Just a heads-up - the whole area of modeling the connection between product specification and tangible goods is planned to be enhanced, using the concept of a stock item.
It was a candidate for v5 in TMF620, and indeed the SID has already been updated I believe. But there is a dependency on the stock availability API so we are somewhat stalled at the moment.
This enhancement will not solve the more general issue of the cardinality between product offering and service or resource candidate.

------------------------------
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 18, 2022 03:08
From: Koen Peeters
Subject: TMF620 - GET ProductOffering - Response for "resourceCandidate"

Hi Pete,

I like the use case you are presenting.
There exist two distinct use cases when selling GoodsProducts.

In the first use case the actual ResourceCandidate behind a ProductOffering is important for the customer. The customer in this case wants a "Pink Samsumg Galaxy S22 with 256GB memory", not just any smartphone. To model this use case a ProductOffering is linked to a specific resourceCandidate.


In the the second use case the customer doesn't care about the actual model as in the case of the ONT in your use case. In that case the ProductOffering is not linked to a specific ResourceCandidate. It is only linked to a ResourceSpecification "ONT" via the ProductSpecification. This actually means that the decision about which ResourceCandidate is deferred. At some later point in the fulfilment process, not later than the start of installation, the actual ResourceCandidate will be chosen. The decision can be based on criteria that come from the service (Hyperfibre requires model C or D) and stock availability. (the technician has a refurbished ONT model D in his truck)
For this use case I suggest indeed to remove the ResourceCandidate from the ProductOffering.
If you technician has an installation app, he will probably see on hit workorder that he needs to pick a model C or a model D. When he scans a a Model A the app will tell him that this device is not compatible with the service. When he scans the refurbished model D, the app will trigger the registration of the serial number of the ONT on the OLT.

I hope this is helpful  to you.

Regards


------------------------------
Koen Peeters
OryxGateway
------------------------------