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 Nov 08, 2023 06:29

    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 Nov 08, 2023 09:39

    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 Nov 10, 2023 06:16

    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 Nov 10, 2023 08:52

    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 Nov 10, 2023 09:55