Open APIs

 View Only
  • 1.  ProductOfferQualification Response

    TM Forum Member
    Posted Jan 18, 2020 18:12
    Hi, I am studying ProductOfferingQualification V 19.0 and having some questions related to response of qualified Offers.
    Offer in our Catalog look like below

    Offer 1- Zero upfront (TOP Offer, isBundle=true)
    • Iphone 8 (OfferType=Equipment, isBundle=false)
    • Samsung Glaxy (OfferType=Equipment, isBundle=false)
    • Peace of mind Plus (OfferType=Plan, isBundle=false)

    Offer 2 - Low upfront (TOP Offer, isBundle=true)
    • Iphone 8 (OfferType=Equipment, isBundle=false)
    • Iphone X (OfferType=Equipment, isBundle=false)
    • Peace of Mind (OfferType=Plan, isBundle=false)

    Customer is looking for qualified offers to activate with Iphone 8.

    Since ProductOfferRef is define at ProductOfferingQualificationItem and ProductOfferingQualificationItem.Product, I am thinking 2 option for response.

    Option 1
    clients of this API will make 2 calls, first to get the Qualified TOP offers and then for each TOP offer, get the Qualified children of those offers.
    Response of Top Qualified Offer
    ProductOfferingQualification
    • productOfferingQualificationItem 1
      • productOffering.id = Zero upfront
      • Product
        • ProductPrice = Price for Zero upfront offer
    • productOfferingQualificationItem 2
      • productOffering.id = Low upfront
      • Product
        • ProductPrice = Price for Low upfront offer

    Option 2 - Client will get full response in single call and response will look like
    ProductOfferingQualification
    • productOfferingQualificationItem 1
      • Product
        • productOffering.id=Zero Upfront
        • ProductPrice = Price for Zero upfront offer
          • Product
            • productOffering.id=Iphone 8
            • ProductPrice = Price for Iphone 8 offer
    • productOfferingQualificationItem 2
      • Product
        • productOffering.id=Low Upfront
        • ProductPrice=Price for Low upfront offer
          • Product
            • productOffering.id=Iphone 8
            • ProductPrice = Price for Iphone 8 offer
    Any suggestion will be appreciated.





    ------------------------------
    VT
    ------------------------------


  • 2.  RE: ProductOfferQualification Response

    TM Forum Member
    Posted Jan 19, 2020 14:43
    Hi Vishal
    In general, if the information could be returned in a single API call, this would presumably be better for the consumer (lower latency)?
    But perhaps @Ludovic Robert - the lead for this API - has a more specific viewpoint for your use case.
    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: ProductOfferQualification Response

    TM Forum Member
    Posted Jan 20, 2020 17:38
    Thanks Jonathan!

    I have another question, ProductOfferingQualification has ProductOfferRef at both ProductOfferingQualificationItem and ProductOfferingQualificationItem.Product. Can you help to know the use case when one or other is used in response? In Version 17.5, API used to have ProductOfferRef only at ProductOfferingQualificationItem. 
    In our use case, we are using ProductOfferingQualificationItem.ProductOfferRef for request and the qualified offers are presented in ProductOfferingQualificationItem.Product.ProductOfferRef. This give us the flexibility to return bundle offers in single response. Is this the right approach?


    ------------------------------
    Vishal Takyar
    TELUS
    ------------------------------



  • 4.  RE: ProductOfferQualification Response

    TM Forum Member
    Posted Jan 21, 2020 03:04
    Hi Vishal
    Since release 19.5 we took the decision to align all product related API with same pattern using ProductRefOrValue. This pattern allows you to refer an existing product (using by ref) or describing a product 'intend' (by value).

    From my perspective your approach leverages this pattern and is aligned with API 'semantic' in particular when a bundled offer should be described in the response: in the request the POQItem.productOffering.id is a request, in the response via POQItem.product you describe a complete structure of 'possible' future product(s)

    Do you plan to use this API also to qualified request for change offering operation (providing a product structure existing and asking for a qualification for changing is Bundle offer) ? I'm assuming same approach works but probably good to take a depth look.

    Hope it helps

    Ludovic


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



  • 5.  RE: ProductOfferQualification Response

    TM Forum Member
    Posted Jan 22, 2020 20:10
    Hi Ludovic,

    Thanks for your reply. We are planning to use this API to qualify change offering. But we are not able to finalize the approach.
    Approach A - Request as bundle offer
    ProductOfferingQualification
    • productOfferingQualificationItem 1
      • Product
        • productOffering.id=Zero Upfront
          • Product1
            • productOffering.id=iphone
          • Product2
            • productOffering.id=planA
          •  Product3
            • productOffering.id=add-on1
          • Product4
            • productOffering.id=add-on2
    In above if product 4 is not qualified, I don't have any way to pass the UnavailabilityReason as this is only available at POQItem.

    Approach 2 - Request as Inv offer.
    ProductOfferingQualification
    • productOfferingQualificationItem 1
      • productOffering.id=Zero Upfront
      • Product
    • productOfferingQualificationItem 2
      • productOffering.id=planA
      • Product
    • productOfferingQualificationItem 3
      • productOffering.id=Add-on1
      • Product
    • productOfferingQualificationItem 4
      • productOffering.id=Add-on2
      • Product
    In above, we have to build the bundle relationship based upon request ids and then to validate the qualification.

    I was thinking, just like shopping cart, is there possibility to have hierarchy of items like
    ProductOfferingQualification
    • productOfferingQualificationItem 1
      • productOfferingQualificationItem 1.1
      • productOfferingQualificationItem 1.2
    •   productOfferingQualificationItem 2
      • productOfferingQualificationItem 2.1
    Any suggestion will be helpful.
    Thanks


    ------------------------------
    Vishal Takyar
    TELUS
    ------------------------------



  • 6.  RE: ProductOfferQualification Response

    TM Forum Member
    Posted Jan 30, 2020 04:49
    Hello Vishal,

    I agreed with you that alternate 1 is not optimum - you will no get a result per product.
    As of now alternate 2 works (leveraging POQItem relationship).

    I think your suggestion about POQ Item recursive feature deserved to be assess with our API team. This is a feature existing also in Quote & productOrder APIs. I will raide a jira internally to track this.

    Thanks

    Ludovic

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



  • 7.  RE: ProductOfferQualification Response

    TM Forum Member
    Posted Feb 19, 2020 13:09
    Hi Ludovic,

    I have a question about the ProductRefOrValue. You mentioned that this structure could be used to describe an existing product or to describe a product intend.

    As is understand it, i could use this structure in a "add" usecase to describe the product intend for the qualified ProductOfferingQualificationItem in the response.
    In a "modify" usecase i could use it to describe an existing product in the request.

    My question is, how i could describe a product intend in a response for the"modify" usecase when the structure ProductRefOrValue structure is used as a ProductRef in the request.

    Kind Regards

    Jens

    ------------------------------
    Jens Wilken
    EWE TEL GmbH
    ------------------------------