Sarah - I second Greg's view that the Product Catalog API is probably the best way to go. Exposing offerings is one of the business aims of this API.
As the new lead for the Product Catalog API (after amazing work done by
@Kamal Maghsoudlou in all the catalogs), I would be happy to hear suggestions for enhancements of this API. I have a backlog of improvements that I am starting to work on, such as:
Since the API was recently published for 17.5, we are aiming at 18.5 (end of this calendar year) as the next release.
So feel free to reach out to me directly by email to open a discussion.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------
Original Message:
Sent: Apr 10, 2018 13:25
From: Greg Herringer
Subject: Entity Catalog API vs Product Catalog API
I would tend towards a Product Catalog API approach and work with TMF to extend the API as necessary or implement extensions in such a way that they can be transformed to the standard API approach. That implies that there is a roadmap for extending the Product Catalog API to meet the needs you have (Characteristics,Rules, etc.)
------------------------------
Greg Herringer
IBM Canada
Original Message:
Sent: Apr 09, 2018 13:52
From: Sarah Ness
Subject: Entity Catalog API vs Product Catalog API
We're trying to expose an offering catalog through a TMF-compliant API but are debating whether we should use the entity catalog API (TMF662) or product catalog API (TMF620). Our use case is that we want to build and cache an extract of our entire offering catalog which will be made available via an interface. Our catalog has certain entities not described in the product catalog API such as rules, relations, and certain offering characteristics that we need so we are leaning towards the entity API which allows us to more generically describe them all. However, the entity API doesn't have the export operations that the product catalog API has for retrieving the entire catalog at once. Looking for advise on which one to use and extend if needed.
------------------------------
Sarah Ness
TELUS
------------------------------