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

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.

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

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?

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.

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

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.

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?

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.

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

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

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

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

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.

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

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

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

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.

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

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

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

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.

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

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

Radosław,

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.

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

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.

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

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