Open APIs

Expand all | Collapse all

Use of TMF-679 product offering qualification API with subscribed products

  • 1.  Use of TMF-679 product offering qualification API with subscribed products

    TM Forum Member
    Posted 20 days ago

    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
    ------------------------------


  • 2.  RE: Use of TMF-679 product offering qualification API with subscribed products

    TM Forum Member
    Posted 19 days ago
    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.
    ------------------------------



  • 3.  RE: Use of TMF-679 product offering qualification API with subscribed products

    TM Forum Member
    Posted 19 days ago
    Would be great to hear what additional community members think of this design topic. @Ludovic Robert, @Kamal Maghsoudlou, @Alexis de Peufeilhoux, @Stephen Harrop​​​​

    ------------------------------
    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.
    ------------------------------



  • 4.  RE: Use of TMF-679 product offering qualification API with subscribed products

    TM Forum Member
    Posted 19 days ago
    Hello Jonathan

    Adding to your answer: we should also consider to make explicit the difference between what the customer already owns and what are customer target request. When you want to check a change to existing product usually in our implementations we recommend to use the product.id to identify the product but then to provide target configuration (characteristic, relationship,etc.).

    Hope it helps,

    Ludovic

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



  • 5.  RE: Use of TMF-679 product offering qualification API with subscribed products

    TM Forum Member
    Posted 18 days ago
    I haven't studied the TMF 679 spec in detail (I will soon!).  I suspect we need to cater for context and scope of the Qualification query, some mentioned above:

    - contents of the cart/quote/order being assessed (might be empty)
    - existing inventory (might be empty)
    - the seller (channel, role)
    - the buyer (customer segment, customer value, location, other criteria)

    As @Jonathan Goldberg mentioned, there are several non-functional design criteria to consider that will be specific to a provider's implementation.

    I suspect that managing context and non-functional design considerations could be a good topic for an Implementation Guide.


    ​​

    ------------------------------
    Greg Herringer
    IBM Corporation
    ------------------------------