Open APIs

I want to get a ProductOfferingPrice via a ProductOffering request. According to TMF620 realese 17.5.0 a ProductOfferingPrice in a ProductOffering is a full object with name, description, priceType, price etc attributes, this sample on the page 30. But in the same document on the page 85, we can see that the ProductOffering response has a short variant of a ProductOfferingPrice: only "id", "href", "name" and "@type" attributes. What is the right variant of a ProductOffering response?

------------------------------
Artyom Valeev
Mobile TeleSystems OJSC
------------------------------

Hi Artyom
In previous releases of this API, ProductOfferingPrice was a contained entity within ProductOffering, so that there was no way to directly address a POP. In the 17.5 release, @Kamal Maghsoudlou has made a significant enhancement, making POP an independently managed entity. This allows re-use of the same POP in multiple offerings, making it easier for catalog implementers and reducing duplication.
Per Open API guidelines, if a managed entity refers to another manged entity, the Ref pattern is used, so ProductOffering would contain POPRef, that has a minimum set of fields (id, href, perhaps name). When doing a GET on a managed entity, you should be able to specify the level of expansion required for Refs, consult the published guidelines for more details. https://projects.tmforum.org/wiki/display/API/API+Design+Guidelines
Hope this is clear enough.​

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

Hi Jonathan,

What would be your suggestion if I need to expand prices, but do not need to expand other references like productSpecification, category, etc.?
In the example provided in TMF630, v 4.0.1, Part 2, section 3. Depth and Expand Directive:
GET /catalogManagement/productOffering/23/?depth=3&expand =productOffering.productSpecification

the response contains not only productSpecification expanded, but also prices.

Thanks!

------------------------------
Nick Nilga
.NET Solutions Architect
Telenor Denmark
------------------------------

Original Message:
Sent: May 25, 2018 01:11
From: Jonathan Goldberg
Subject: ProductOfferingPrices in ProductOffering

Hi Artyom
In previous releases of this API, ProductOfferingPrice was a contained entity within ProductOffering, so that there was no way to directly address a POP. In the 17.5 release, @Kamal Maghsoudlou has made a significant enhancement, making POP an independently managed entity. This allows re-use of the same POP in multiple offerings, making it easier for catalog implementers and reducing duplication.
Per Open API guidelines, if a managed entity refers to another manged entity, the Ref pattern is used, so ProductOffering would contain POPRef, that has a minimum set of fields (id, href, perhaps name). When doing a GET on a managed entity, you should be able to specify the level of expansion required for Refs, consult the published guidelines for more details. https://projects.tmforum.org/wiki/display/API/API+Design+Guidelines
Hope this is clear enough.​

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

Hi Nick

My understanding of the example you have quoted from the DG document is that the productSpecification attribute will be expanded (up to depth 3), while other attributes won't be expanded. The expand takes a list, so you could say expand=productOffering.productSpecification,productOffering.productOfferingPrice, and then only those two attributes would be expanded. To be honest, I am not quite sure why the prefix productOffering. is needed, possibly it is a mistake in the guidelines.

For much finer control, refer to Part 6 of the design guidelines, where JSON Path is described. Of course this requires the implementation of the API to support JSON Path, which is not currently mandatory for Open API conformance.

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: Nov 19, 2020 09:19
From: Mykola Nilga
Subject: ProductOfferingPrices in ProductOffering

Hi Jonathan,

What would be your suggestion if I need to expand prices, but do not need to expand other references like productSpecification, category, etc.?
In the example provided in TMF630, v 4.0.1, Part 2, section 3. Depth and Expand Directive:
GET /catalogManagement/productOffering/23/?depth=3&expand =productOffering.productSpecification

the response contains not only productSpecification expanded, but also prices.

Thanks!

------------------------------
Nick Nilga
.NET Solutions Architect
Telenor Denmark
------------------------------


Original Message:
Sent: May 25, 2018 01:11
From: Jonathan Goldberg
Subject: ProductOfferingPrices in ProductOffering

Hi Artyom
In previous releases of this API, ProductOfferingPrice was a contained entity within ProductOffering, so that there was no way to directly address a POP. In the 17.5 release, @Kamal Maghsoudlou has made a significant enhancement, making POP an independently managed entity. This allows re-use of the same POP in multiple offerings, making it easier for catalog implementers and reducing duplication.
Per Open API guidelines, if a managed entity refers to another manged entity, the Ref pattern is used, so ProductOffering would contain POPRef, that has a minimum set of fields (id, href, perhaps name). When doing a GET on a managed entity, you should be able to specify the level of expansion required for Refs, consult the published guidelines for more details. https://projects.tmforum.org/wiki/display/API/API+Design+Guidelines
Hope this is clear enough.​

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

Hi Jonathan,

Thanks for the detailed explanation!

------------------------------
Nick Nilga
.NET Solutions Architect
Telenor Denmark
------------------------------

Original Message:
Sent: Nov 19, 2020 11:35
From: Jonathan Goldberg
Subject: ProductOfferingPrices in ProductOffering

Hi Nick

My understanding of the example you have quoted from the DG document is that the productSpecification attribute will be expanded (up to depth 3), while other attributes won't be expanded. The expand takes a list, so you could say expand=productOffering.productSpecification,productOffering.productOfferingPrice, and then only those two attributes would be expanded. To be honest, I am not quite sure why the prefix productOffering. is needed, possibly it is a mistake in the guidelines.

For much finer control, refer to Part 6 of the design guidelines, where JSON Path is described. Of course this requires the implementation of the API to support JSON Path, which is not currently mandatory for Open API conformance.

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: Nov 19, 2020 09:19
From: Mykola Nilga
Subject: ProductOfferingPrices in ProductOffering

Hi Jonathan,

What would be your suggestion if I need to expand prices, but do not need to expand other references like productSpecification, category, etc.?
In the example provided in TMF630, v 4.0.1, Part 2, section 3. Depth and Expand Directive:
GET /catalogManagement/productOffering/23/?depth=3&expand =productOffering.productSpecification

the response contains not only productSpecification expanded, but also prices.

Thanks!

------------------------------
Nick Nilga
.NET Solutions Architect
Telenor Denmark


Original Message:
Sent: May 25, 2018 01:11
From: Jonathan Goldberg
Subject: ProductOfferingPrices in ProductOffering

Hi Artyom
In previous releases of this API, ProductOfferingPrice was a contained entity within ProductOffering, so that there was no way to directly address a POP. In the 17.5 release, @Kamal Maghsoudlou has made a significant enhancement, making POP an independently managed entity. This allows re-use of the same POP in multiple offerings, making it easier for catalog implementers and reducing duplication.
Per Open API guidelines, if a managed entity refers to another manged entity, the Ref pattern is used, so ProductOffering would contain POPRef, that has a minimum set of fields (id, href, perhaps name). When doing a GET on a managed entity, you should be able to specify the level of expansion required for Refs, consult the published guidelines for more details. https://projects.tmforum.org/wiki/display/API/API+Design+Guidelines
Hope this is clear enough.​

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