Open APIs

 View Only
Expand all | Collapse all

Product Configurator API TMF760 - some fundamental questions

  • 1.  Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted Oct 27, 2023 04:43
    Edited by Radosław Twardy Oct 27, 2023 10:14

    Hi,

    I have few questions about Product Configurator API described in TMF760. This API is statefull - probably we want GET Resource by ID, because we want to use this API asynchronously. I dont't underestand listing this resources - what is use case of it ? I imagine that this resources are not persistent in system (i don't see the justification), but only cached for some necessary time - if it correct approach ? If yes then problematic is listing resources and get by id after some time.

    I imagine that when someone want create an product order, use this api many time (for complex offer). So per on product order we will have several dozen of QueryProductConfiguration - persisting is challenging and (i think) unjustifiable.

    Second part of my questions regarding division into QueryProductConfiguration and CheckProductConfiguration. I imagine that engagement management system for each call QueryProductConfiguration API want to see actual configuration and possible validation errors - so I do not fully understand why have two separated resources - could you explain me it ?

    Third part of my questions is connections between this API and TMF622 or TMF663 - i can't see possiblity to create cart/order based on CheckProductConfiguration - so it is ok that engagement management system should map response one API to request to other API ?



    ------------------------------
    Radosław Twardy
    Comarch S.A.
    ------------------------------



  • 2.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 25 days ago

    Hi @Bostjan Keber

    is the TMF760 API team following up the API community for question on this API? I don't know this API enough to give a complete answer.



    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------



  • 3.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 25 days ago

    Hi Radoslaw,

    The product configuration API (TMF760) is stateless. The basic operation is POST/QueryProductConfiguration. The user provides contextual information (offering or product ref, channel, party, etc.) and the product configuration computes an appropriate product configuration that is used to drive engagement management.

    If you provide instantSync = false, you get a 201 HTTP response and then you need an operation to obtain the QueryProductConfiguration resource. That's why we added GET by ID. State attribute is used to return the configuration state (in case you invoke GET before the configuration has been fully computed).

    I can't think of a use-case where you would need GET / list operation.

    I imagine that when someone want to create a product order, use this api many time (for complex offer). So per on product order we will have several dozen of QueryProductConfiguration - persisting is challenging and (i think) unjustifiable.

    I agree. There will be several QueryPC invocations per product order / quote / cart. See the figure below.

    Second part of my questions regarding division into QueryProductConfiguration and CheckProductConfiguration. I imagine that engagement management system for each call QueryProductConfiguration API want to see actual configuration and possible validation errors - so I do not fully understand why have two separated resources - could you explain me it ?

    QueryPC is used to compute instructions to configure a product offering in a given context or reconfigure an existing product instance. Including obtaining allowed product actions, computing prices based on characteristic values, computing allowed characteristic values based on other characteristic values or selected bundled / add-on offerings etc.

    CheckPC is used to validate a product configuration after all user input is done and prior to creating a quote/order/cart item.

    The sequence diagram below shows interactions among APIs / ODA components, including 663, 648 and 622 (POCV).

    Some TMF member companies consider implementing TMF760 in a stateful way. There are 2 user stories associated with this requirement:

    1. To reduce API payload when re-computing partially configured product configurations. 
    2. The user starts configuring a product through one engagement channel (e.g. mobile app) and continues configuration through another engagement channel (e.g. customer portal). The user doesn't want to lose a partially configured product. See IG1176.


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



  • 4.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 23 days ago

    Hi Bostjan,

    The user starts configuring a product through one engagement channel (e.g. mobile app) and continues configuration through another engagement channel (e.g. customer portal). The user doesn't want to lose a partially configured product. See IG1176.

    why would the user lose their partially configured product offering?
    the current state of configuration should be stored in a managed entity, such as a shopping cart, quote, order.
    typical processes:

    I pick a customisable product offering, start adding some options, then leave as is. system should save the current state in a shopping cart.

    then I go home and continue on my computer, pick up my pending cart and continue.
    that's the basic requirements for omni-channel and 360 degree customer view.

    I checked IG1176 (IG1176 TOSCA Guide for Model-Driven Automation v4.1.0) where does it talk about product configuration?




    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------



  • 5.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 23 days ago

    Hi Matthieu,

    the answer to your question depends on the implementation of the shopping cart. When do you persist a cart item? Is it valid to persist a partially configured cart item? If not, then the product configurator (stateless) wouldn't be able to assist you with a partially configured product configuration when you switch to a different engagement channel.

    Sorry, I mistyped the document code. See IG1167 ODA Functional Architecture Exploratory Report / Chapter 4 - Business use cases.



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



  • 6.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 23 days ago

    Is it valid to persist a partially configured cart item?


    Can you clarify what you mean by "persist"?
    here is an example:

    from the web, I pick a privacy product bundle offer. It includes:
    - an mandatory email product offer with 2 characteristics: email address
    - an optional VPN product offer
    - an optional antivirus product offer

    I decide to leave the email address empty for now and will decide later whether I want the VPN and antivirus
    At this point, I have 2 options:
    1- add my bundle to the shopping cart
    2- do nothing.
    If I do nothing, I don't expect any system to store my partially configured bundle 

    If I add my bundle to the shopping cart, the partially configured should be in the shopping cart and stored in application database.

    Next day I want to check out my cart (from another channel but that's not relevant). In your approach:

    • will I still see my shopping cart?
    • will it still contain my partially privacy bundle?


    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------



  • 7.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 23 days ago

    At this point, I have 2 options:
    1- add my bundle to the shopping cart
    2- do nothing.

    If I do nothing, I don't expect any system to store my partially configured bundle 

    I

    If I add my bundle to the shopping cart, the partially configured should be in the shopping cart and stored in application database.

    I agree.

    But it comes down to how your shopping cart is implemented. Will the shopping cart permit you to create and persist a shopping cart item if you don't fully configure the mandatory e-mail offering? In theory, CheckProductConfiguration operation should return an error that a mandatory offering wasn't fully configured. And if the shopping cart doesn't accept such (incomplete) configurations, you don't have a persistent container as the QueryProductConfiguration is stateless.

    If you successfully create a cart item and later decide to reconfigure it (e.g. change the mailbox size or change the handset color), you can use QueryProductConfiguration operation. This is one of the requirements described in API the user manual.



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



  • 8.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 21 days ago

    My personal view is that backends should allow persisting of shopping carts and product orders with invalid configurations.

    It can take time to achieve a correct and agreed configuration (especially in the B2B world), so it makes sense to allow storage for work-in-progress. Of course the status of the cart or order should reflect this.



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



  • 9.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 20 days ago

    @Michael Kieber My questions was based on TMF760 document which has 224 pages (draft), but I see that this document was removed. Instead of this was released document which has 23 pages. This document mention about f. ex. delete endpoints.... If check and query product configuration is stateless than what is reason of list or delete this resources ?



    ------------------------------
    Radosław Twardy
    Comarch S.A.
    ------------------------------



  • 10.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 20 days ago

    Good question. DELETE operation was required because you can post a query or check request asynchronously (instantSync = false). You can then make a GET request before you get notified that the query or check operation is completed. Assume you are satisfied with a partially completed computation. In that case, you can submit a delete request to cancel the computation.



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



  • 11.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 17 days ago
      |   view attached

    @Bostjan Keber Why document (which I attached) was replaced by currrent document ? Recently published document hasn't have any resources description. It will be changed?



    ------------------------------
    Radosław Twardy
    Comarch S.A.
    ------------------------------

    Attachment(s)



  • 12.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 17 days ago

    Hi Radoslaw,

    all Open API artifacts (user guide, conformance profile, CTK) are autogenerated. API designers contribute input in markup language and yaml files that are later compiled into TMF artifacts.

    You should contact Henrique Henrique Rodrigues - @Henrique Rodrigues @HENRIQUE RODRIGUES.

    Bostjan



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



  • 13.  RE: Product Configurator API TMF760 - some fundamental questions

    TM Forum Member
    Posted 17 days ago

    Radosław,

    My questions was based on TMF760 document which has 224 pages (draft), but I see that this document was removed. Instead of this was released document which has 23 pages

    on the 26th of September TMF uploaded:
    User guide V1 (224 pages), front page shows:
    V1 was a draft.

    on the 29th of September TMF uploaded:

    User guide V2 (220 pages), front page shows:

    The same logic applies to the conformance profile. Last version is V2 (58 pages) 

    Please clarify what document of 23 pages are you refering to because I haven not seen one.



    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------