Open APIs

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

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

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 agree. There will be several QueryPC invocations per product order / quote / cart. See the figure below.

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.

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

Hi Bostjan,

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?

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 agree. There will be several QueryPC invocations per product order / quote / cart. See the figure below.

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.

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