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

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 prod