Hi Anish
This is a general question, not just for the qualification API. When designing an API, do we want:
- to make its implementation self-sufficient and independent, i.e. to get all the information it needs as input
- OR to pass minimum information, and if the implementation needs more, it will have to fetch it
It's a fine balance, and probably needs to be analyzed separately for each use case. Factors to be considered include:
- Latency and performance
- Payload size
- Complexity of the business flow
- Complexity of the implementation
- Reusability of the API
Specifically for product offering qualification, you can see that the current design of the API does not explicitly pass the additional data that is needed, such as:
- full catalog information (only pointers are passed in - the implementation presumably needs to GET details via TMF620 operations)
- full customer information (products from the inventory, customer risk information, credit rating, etc.)
Of course you can extend the API to add the customer installed base, if this is your business need.
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: Apr 25, 2021 06:24
From: Anish Parekh
Subject: Use of TMF-679 product offering qualification API with subscribed products
Hi All,
We are trying to implement TMF-679 Product Offering Qualification API to provide product offering eligibility while placing product order for existing subscriber. This product order can be of change existing subscribed offer or subscribe new add-on offer.
Here, the subscribed product details are also required to check the eligibility of product offering. There are 2 approaches to fetch these subscribed product details.
Approach-1:
The product offering qualification management system access the product inventory API to get the installed base/existing products of the subscriber.
Approach-2:
The TMF-679 POQ API will get the already subscribed products details in input request itself from front-end channels so that the POQ management system does not require to integrate with product inventory system to fetch it during POQ API request. In this case, POQ API doesnot have subscribed product context in API.
Which approach would be proper for implementation out of the above 2?
In any of the above approaches, how to map the fields in TMF-679 POQ API?
------------------------------
Anish Parekh
Sterlite Technologies Limited
------------------------------