Open APIs

 View Only
  • 1.  TMF679 Product Offering Qualification v5: Addon Usecase

    Posted Apr 18, 2023 04:05
    Edited by Stefan Zaufl Apr 18, 2023 07:28

    Hi everyone!

    I have a question regarding TMF679 (Product Offering Qualification v5, early adopter). In the new version of the APi there are two methods: check and query qualification. We have discovered a case where we're not sure how to model this with the query method of TMF679 v5.

    Suppose we have the following product structure:

    Bundle Offering 1
     + Product Offering
     + Addon1
     + Addon2
     + Addon3

    Where the customer cannot buy Addon1 and Addon3 at the same time.

    Now suppose we have an existing customer that own the basic tree like this:

    Customer ID = 2345,
    Bundle Offering 1 (Inventory ID = 1234)
     + Product Offering (Inventory ID = 5678)

    The customer now wants to buy Addons and goes to our shop. A qualification call like this will be made:

    {
        "searchCriteria": {
            "product": {
                "id": "1234",
                "productOffering": {
                    "id": "BUNDLE_OFFERING_1"
                },
                "product": [
                    {
                        "id": "5678",
                        "productOffering": { "id": "PRODUCT_OFFERING_1" }
                    }
                ]
            }
        },
        "relatedParty": [
          {
            "id": "2345",
            "role": "CUSTOMER"
          }
        ],
        "category" : {
          "id" : "ADDONS"
        }
    }


    We will then receive an answer like this:

    {
      "searchCriteria": {
        "id": "1",
        "product": {
          "id": "1234",
          "productOffering": {
            "id": "BUNDLE_OFFERING_1"
          },
          "product": [
            {
              "id": "5678",
              "productOffering": { "id": "PRODUCT_OFFERING_1" }
            }
          ]
        }
      },
      "relatedParty": [
        {
          "id": "2345",
          "role": "CUSTOMER"
        }
      ],
      "category" : {
        "id" : "ADDONS"
      },
      "qualifiedProductOfferingItem": [
        {
          "id": "2",
          "productOffering": {
            "id": "ADDON_1"
          },
          "qualificationItemRelationship": [
            {
              "id": "4",
              "relationshipType": "EXCLUDES"
            }
          ]
        },{
          "id": "3",
          "productOffering": {
            "id": "ADDON_2"
          }
        },{
          "id": "4",
          "productOffering": {
            "id": "ADDON_3"
          },
          "qualificationItemRelationship": [
            {
              "id": "2",
              "relationshipType": "EXCLUDES"
            }
          ]
        }
      ]
    }


    First Question: Is our use of the relations here correct? Should we also add a relationship from each addon to the search criteria so it's clear it's only qualified if it's part of that product tree as it's not possible to buy it as stand-alone?

    Second Question: Suppose the customer picks Addon1 and we want to show him what he can now buy. So the query qualification will be called again. How would this request look like? There is no way of passing a hierarchy of QueryProductOfferingQualificationItems as search criteria, so my only option would be to put it in the product tree without id. But this seems not really intended. How would you model this case?

    Here is an example of what I mean:

    {
     "searchCriteria": {
        "id": "1",
        "product": {
          "id": "1234",
          "productOffering": {
            "id": "BUNDLE_OFFERING_1"
          },
          "product": [
            {
              "id": "5678",
              "productOffering": { "id": "PRODUCT_OFFERING_1" }
            },{
              // No ID, as it's not in the inventory yet
              "productOffering": { "id": "ADDON_1" }
            }
          ]
        }
      }
      "relatedParty": [
        {
          "id": "2345",
          "role": "CUSTOMER"
        }
      ],
      "category" : {
        "id" : "ADDONS"
      }
    }


    ------------------------------
    Stefan Zaufl
    IBM Corporation
    ------------------------------



  • 2.  RE: TMF679 Product Offering Qualification v5: Addon Usecase

    Posted Apr 18, 2023 08:35

    Perhaps @Bostjan Keber could help here?



    ------------------------------
    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: TMF679 Product Offering Qualification v5: Addon Usecase

    Posted Apr 18, 2023 09:44
    Edited by Bostjan Keber Apr 18, 2023 09:45

    Hi Stefan,

    we only implemented v4 of TMF679 API. We used POQItems to provide what is currently configured in the context of quote/cart/order (as input). The "action" attribute is set to "modify" on those nodes (POQItems) where we wanted to execute commercial eligibility computation and receive the list of qualified product offerings. Output POQItems are returned under POQItems marked with modify.
    Additionally, we extended the ProductOfferingQualification class with a searchString attribute. POs in the result set must match this searchString (e.g. to avoid receiving Galaxy phones when the customer wants to buy an iPhone).

    Our implementation wouldn't be possible in v5. POQItems are now split between qualifiedProductOfferingItem (0..*) and searchCriteria (0..1). The documentation states that:
    "It allows client side to pass a list of criteria (search criteria to provide the context of the qualification)".
    So I would assume the search criteria to be 0..* (list of criteria).

    There is a jira ticket open regarding "action" attribute in query scenario, but also a forum thread.

    As v5 is still beta, we should bring these issues to the attention of @Ludovic Robert.



    ------------------------------
    Bostjan Keber
    Marand, software ltd
    ------------------------------