Open APIs

Hello,

Query Product Configuration provides configurations user can choose. When customer chooses any option in the configuration, the request is sent to product configurator then calculated in it. It is so costly operation. For us, we see that when customer changes options in the configuration, price is calculated again. So, configuration should include rule/policy to calculate the price so that FE can calculate it. In the configuration, policy ref is included. But I am not sure if FE should use it. 

Another option instead of having product offering price ref, we can get product offering price value with product spec char values. In the case, FE can calculated prices based on what option customer chooses. I think it is not good that structure is altered. What alternative options can be used?

------------------------------
Myagaa Nm
Mobicom Corporation
------------------------------

Hi,

very good question! I had the same one a few days ago for our project.

It is my opinion that Front end should not calculate anything. I don't believe this is the spirit of ODA and ODA functional blocks.

If you have 4 frontends, you don't want to maintain 4 codes doing the same thing.

I do however support doing price "calculation" in the frontend (BFF to be more precise) under the condition that it is strictly a UX requirement.

The Pcfg (product configurator) should calculate the configurationPrice based on policy, product catalogue and product inventory. (there is a nice functional diagram in TMF670 documentation that illustrates that).

This being said, I very much agree with your comment:

I'm myself facing the same issue this very moment.

as you pointed out, TMF670 explains this constant back and forth with the example of a customer selecting the blue or red characteristic values and each selection require a POST request.

I don't see why this API has to behave this way. Other Pcfg API I've have see work differently. It's also not customer-friendly to ask users to pick a product option to see the price (aka postpick pricing).

I identified these possible solutions: 

1. extend the API to have a "configurationPrice" for each product option (product option is an abstract term to represent anything that a user can pick in the Pcfg UI, be it a characteristic value or a bundle component)
2. keep the TMF API as-is and have another API (graphQL) that will loop through all possible product option with a POST Query.... request until all possible configuration prices are collected. Finally merge the whole thing and present it. we call this prepick pricing.
3. some caching (it's not ideal as customer still has to select each product option before you can build a cache)

we are going for option 1 and in a single API call, we get this:

PS: we also extending the API to:

recognise what product option is currently active in the product inventory (this is only for customer who which to change their bundle, offer...)

get the price fo active product form billing system (to show what they pay today (as per agreed price in the Product Terms)

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Jul 08, 2024 21:46
From: Myagaa Nm
Subject: Query Product Configuration price calculation in UI

Hello,

Query Product Configuration provides configurations user can choose. When customer chooses any option in the configuration, the request is sent to product configurator then calculated in it. It is so costly operation. For us, we see that when customer changes options in the configuration, price is calculated again. So, configuration should include rule/policy to calculate the price so that FE can calculate it. In the configuration, policy ref is included. But I am not sure if FE should use it. 

Another option instead of having product offering price ref, we can get product offering price value with product spec char values. In the case, FE can calculated prices based on what option customer chooses. I think it is not good that structure is altered. What alternative options can be used?

------------------------------
Myagaa Nm
Mobicom Corporation
------------------------------

Hi @Matthieu Hattab

thanks for your comments.

I have this understanding on the ²base process :

• all eligible productOffering and their prices can be retrieved with TMF679 Product Offering Qualification and TMF620 Product Catalog. For me no need for TMF760 to display the different possible prices of offers. Even the applicable rules can be retrieved from TMF620, that permit to calculate the configurations.
• configuration is needed when an offer is selected and when a choice of characteristics or of bundled (or related) offers should be done by customer
• at this step the TMF760 API is used to get the user choices and respond with a price and an updated configuration proposal

But I think I understand your concern is to display several possible configurations at one time even if user hasn't yet selected anything. And at each user selection, no need to request the Product Configuration API.

You want to avoid this back and forth exchanges + avoid Front-End app to understand the catalog rules applicable to the eligible offers presented. So the idea is to have a full matrix of all possible configurations.

Do I understand well ?

------------------------------
olivier arnaud
Orange

Original Message:
Sent: Jul 09, 2024 10:26
From: Matthieu Hattab
Subject: Query Product Configuration price calculation in UI

Hi,

very good question! I had the same one a few days ago for our project.

It is my opinion that Front end should not calculate anything. I don't believe this is the spirit of ODA and ODA functional blocks.

If you have 4 frontends, you don't want to maintain 4 codes doing the same thing.

I do however support doing price "calculation" in the frontend (BFF to be more precise) under the condition that it is strictly a UX requirement.

The Pcfg (product configurator) should calculate the configurationPrice based on policy, product catalogue and product inventory. (there is a nice functional diagram in TMF670 documentation that illustrates that).

This being said, I very much agree with your comment:

I'm myself facing the same issue this very moment.

as you pointed out, TMF670 explains this constant back and forth with the example of a customer selecting the blue or red characteristic values and each selection require a POST request.

I don't see why this API has to behave this way. Other Pcfg API I've have see work differently. It's also not customer-friendly to ask users to pick a product option to see the price (aka postpick pricing).

I identified these possible solutions: 

1. extend the API to have a "configurationPrice" for each product option (product option is an abstract term to represent anything that a user can pick in the Pcfg UI, be it a characteristic value or a bundle component)
2. keep the TMF API as-is and have another API (graphQL) that will loop through all possible product option with a POST Query.... request until all possible configuration prices are collected. Finally merge the whole thing and present it. we call this prepick pricing.
3. some caching (it's not ideal as customer still has to select each product option before you can build a cache)

we are going for option 1 and in a single API call, we get this:

PS: we also extending the API to:

recognise what product option is currently active in the product inventory (this is only for customer who which to change their bundle, offer...)

get the price fo active product form billing system (to show what they pay today (as per agreed price in the Product Terms)

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Jul 08, 2024 21:46
From: Myagaa Nm
Subject: Query Product Configuration price calculation in UI

Hello,

Query Product Configuration provides configurations user can choose. When customer chooses any option in the configuration, the request is sent to product configurator then calculated in it. It is so costly operation. For us, we see that when customer changes options in the configuration, price is calculated again. So, configuration should include rule/policy to calculate the price so that FE can calculate it. In the configuration, policy ref is included. But I am not sure if FE should use it. 

Another option instead of having product offering price ref, we can get product offering price value with product spec char values. In the case, FE can calculated prices based on what option customer chooses. I think it is not good that structure is altered. What alternative options can be used?

------------------------------
Myagaa Nm
Mobicom Corporation
------------------------------

Hello,

Query Product Configuration provides configurations user can choose. When customer chooses any option in the configuration, the request is sent to product configurator then calculated in it. It is so costly operation. For us, we see that when customer changes options in the configuration, price is calculated again. So, configuration should include rule/policy to calculate the price so that FE can calculate it. In the configuration, policy ref is included. But I am not sure if FE should use it. 

Another option instead of having product offering price ref, we can get product offering price value with product spec char values. In the case, FE can calculated prices based on what option customer chooses. I think it is not good that structure is altered. What alternative options can be used?

Hi Myagaa Nm,

The whole idea of the product configurator component is that you may have several front-ends (e.g. quoting app, ordering app, e-commerce for customers, mobile app etc.) and all these FEs use the same configuration logic (i.e. interpretation of product catalog, policies/rules, existing products,... ) in a given context.

If you implement business logic individually per FE, you will have a lot of work with change requests in the production environment. You also run the risk of inconsistent logic execution due to several implementations.

Now, the community is working on the Policy API (TMF723) specification. The idea is that the product catalog would reference policies. When a product spec or product offering references a policy the product configurator invokes the Policy API to execute these rules in the context of a quote, order, or shopping cart. This flow and dependencies are described in the TMF760 user guide:

If you have a look at the class diagram, you will see that the ProductConfiguration entity references PolicyRef. If the configurator uses policies to compute the configuration, they are returned as PolicyRef.

In our implementation, we invoke TMF760 on every client event that may require recomputation of the product configuration (characteristic value set/limit, price recalc etc.). We were concerned the API would be too chatty but it turned out it works just fine and the end-user is not impacted due to API invocations.

Regarding the specific use-case when a set of characteristics drives a price selection (e.g. bandwidth defines monthly fee or smartphone storage option defines purchase price): this can be supported in the product catalog alone (TMF620) and the TMF760 is not even needed. In this case, FE would have to implement the logic that recalculated the item price in case of a characteristic value set/change. There is an initiative in the community to extend the TMF620 with characteristic-driven prices. As of now, it would require an API extension, though.

BR, Bostjan

Hello,

Query Product Configuration provides configurations user can choose. When customer chooses any option in the configuration, the request is sent to product configurator then calculated in it. It is so costly operation. For us, we see that when customer changes options in the configuration, price is calculated again. So, configuration should include rule/policy to calculate the price so that FE can calculate it. In the configuration, policy ref is included. But I am not sure if FE should use it. 

Another option instead of having product offering price ref, we can get product offering price value with product spec char values. In the case, FE can calculated prices based on what option customer chooses. I think it is not good that structure is altered. What alternative options can be used?

Hello Bostjan,

Modern architectures like ODA, MACH etc decouple engagement layer from business capabilities layer with an API-first approach.

as a principle, we should not recommend to implement business logic in the frontend at least for the reason you mention earlier: it's a nightware to manage multiple basecodes.

(I don't think frontend can use TMF620 because it's a resource API, not a task API, i.e. TMF620 will never return a productPrice (list price - discount + tax etc) like TMF679 does).

You mentioned that your implementation also involves numerous API calls to get the price each time the user changes the configuration and that "it works just fine".

This mirrors your example in the TMF760 documentation where you need to make 2 API requests to fetch the configuration price of the blue and red variant for a mobile handset.

It's not a sustainable approach (API call charge, overall system performance, carbon footprint...) and it's not a good user experience.

(we can of course do data orchestration behind the frontend to make all API calls and collect all possible configurationPrices but again, extra cost and el.)

we need to get all prices for all displayable product options at once in the PcfgGUI (product Configurator UI) before customer picks any option. We call this "prepick pricing".

Do you have another suggestion?

our current design was to avoid making 6 calls (we have 5 bandwidth charvalues). We extended the API to provide all customer all possible configuration prices in a single call.

To mirror your use case (retrieve the price of the red and blue colour variant) in the TMF670 user guide, our implementation includes an price extension to include the price

(I heavily simplified it to remove all the noise such as @type and all unused entities for clarity)

the configurationPrice would always match the price of the selected colour charvalue (postpick price).

Honestly, at this point, the above computedProductConfiguration payload is what customer sees in the UI, augmented with content and page layout from CMS and design system.

That's also supported in 620 v5, using the prodSpecCharValueUse relationship between a POP and a CharValue. We use it in our product catalogue (but only for a single dimension.)

My 2 cents

Hi Myagaa Nm,

The whole idea of the product configurator component is that you may have several front-ends (e.g. quoting app, ordering app, e-commerce for customers, mobile app etc.) and all these FEs use the same configuration logic (i.e. interpretation of product catalog, policies/rules, existing products,... ) in a given context.

If you implement business logic individually per FE, you will have a lot of work with change requests in the production environment. You also run the risk of inconsistent logic execution due to several implementations.

Now, the community is working on the Policy API (TMF723) specification. The idea is that the product catalog would reference policies. When a product spec or product offering references a policy the product configurator invokes the Policy API to execute these rules in the context of a quote, order, or shopping cart. This flow and dependencies are described in the TMF760 user guide:

If you have a look at the class diagram, you will see that the ProductConfiguration entity references PolicyRef. If the configurator uses policies to compute the configuration, they are returned as PolicyRef.

In our implementation, we invoke TMF760 on every client event that may require recomputation of the product configuration (characteristic value set/limit, price recalc etc.). We were concerned the API would be too chatty but it turned out it works just fine and the end-user is not impacted due to API invocations.

Regarding the specific use-case when a set of characteristics drives a price selection (e.g. bandwidth defines monthly fee or smartphone storage option defines purchase price): this can be supported in the product catalog alone (TMF620) and the TMF760 is not even needed. In this case, FE would have to implement the logic that recalculated the item price in case of a characteristic value set/change. There is an initiative in the community to extend the TMF620 with characteristic-driven prices. As of now, it would require an API extension, though.

BR, Bostjan

Hello,

Query Product Configuration provides configurations user can choose. When customer chooses any option in the configuration, the request is sent to product configurator then calculated in it. It is so costly operation. For us, we see that when customer changes options in the configuration, price is calculated again. So, configuration should include rule/policy to calculate the price so that FE can calculate it. In the configuration, policy ref is included. But I am not sure if FE should use it. 

Another option instead of having product offering price ref, we can get product offering price value with product spec char values. In the case, FE can calculated prices based on what option customer chooses. I think it is not good that structure is altered. What alternative options can be used?

Hey Matthieu,

if I understood well, you extended the product configuration API with functionality that enables configurator GUI to obtain all characteristic value/price combinations with a single API invocation. You call this "prepick pricing". The GUI recalculates the configuration price based on the information obtained with the first API invocation on each characteristic value change.

If you want to avoid product configuration API invocations on char value change for the reasons you mentioned, I don't have any alternative idea. Our product doesn't support only simple "price tables" but complicated price calculations where char values are used as formula variables as well. There was no way to pass price computations to BFF/FE because we drive various configuration FEs.

BR,

Bostjan

Hello Bostjan,

Modern architectures like ODA, MACH etc decouple engagement layer from business capabilities layer with an API-first approach.

as a principle, we should not recommend to implement business logic in the frontend at least for the reason you mention earlier: it's a nightware to manage multiple basecodes.

(I don't think frontend can use TMF620 because it's a resource API, not a task API, i.e. TMF620 will never return a productPrice (list price - discount + tax etc) like TMF679 does).

You mentioned that your implementation also involves numerous API calls to get the price each time the user changes the configuration and that "it works just fine".

This mirrors your example in the TMF760 documentation where you need to make 2 API requests to fetch the configuration price of the blue and red variant for a mobile handset.

It's not a sustainable approach (API call charge, overall system performance, carbon footprint...) and it's not a good user experience.

(we can of course do data orchestration behind the frontend to make all API calls and collect all possible configurationPrices but again, extra cost and el.)

we need to get all prices for all displayable product options at once in the PcfgGUI (product Configurator UI) before customer picks any option. We call this "prepick pricing".

Do you have another suggestion?

our current design was to avoid making 6 calls (we have 5 bandwidth charvalues). We extended the API to provide all customer all possible configuration prices in a single call.

To mirror your use case (retrieve the price of the red and blue colour variant) in the TMF670 user guide, our implementation includes an price extension to include the price

(I heavily simplified it to remove all the noise such as @type and all unused entities for clarity)

the configurationPrice would always match the price of the selected colour charvalue (postpick price).

Honestly, at this point, the above computedProductConfiguration payload is what customer sees in the UI, augmented with content and page layout from CMS and design system.

That's also supported in 620 v5, using the prodSpecCharValueUse relationship between a POP and a CharValue. We use it in our product catalogue (but only for a single dimension.)

My 2 cents

Hi Myagaa Nm,

The whole idea of the product configurator component is that you may have several front-ends (e.g. quoting app, ordering app, e-commerce for customers, mobile app etc.) and all these FEs use the same configuration logic (i.e. interpretation of product catalog, policies/rules, existing products,... ) in a given context.

If you implement business logic individually per FE, you will have a lot of work with change requests in the production environment. You also run the risk of inconsistent logic execution due to several implementations.

Now, the community is working on the Policy API (TMF723) specification. The idea is that the product catalog would reference policies. When a product spec or product offering references a policy the product configurator invokes the Policy API to execute these rules in the context of a quote, order, or shopping cart. This flow and dependencies are described in the TMF760 user guide:

If you have a look at the class diagram, you will see that the ProductConfiguration entity references PolicyRef. If the configurator uses policies to compute the configuration, they are returned as PolicyRef.

In our implementation, we invoke TMF760 on every client event that may require recomputation of the product configuration (characteristic value set/limit, price recalc etc.). We were concerned the API would be too chatty but it turned out it works just fine and the end-user is not impacted due to API invocations.

Regarding the specific use-case when a set of characteristics drives a price selection (e.g. bandwidth defines monthly fee or smartphone storage option defines purchase price): this can be supported in the product catalog alone (TMF620) and the TMF760 is not even needed. In this case, FE would have to implement the logic that recalculated the item price in case of a characteristic value set/change. There is an initiative in the community to extend the TMF620 with characteristic-driven prices. As of now, it would require an API extension, though.

BR, Bostjan

Hello,

Query Product Configuration provides configurations user can choose. When customer chooses any option in the configuration, the request is sent to product configurator then calculated in it. It is so costly operation. For us, we see that when customer changes options in the configuration, price is calculated again. So, configuration should include rule/policy to calculate the price so that FE can calculate it. In the configuration, policy ref is included. But I am not sure if FE should use it. 

Another option instead of having product offering price ref, we can get product offering price value with product spec char values. In the case, FE can calculated prices based on what option customer chooses. I think it is not good that structure is altered. What alternative options can be used?

Hi Myagaa Nm,

The whole idea of the product configurator component is that you may have several front-ends (e.g. quoting app, ordering app, e-commerce for customers, mobile app etc.) and all these FEs use the same configuration logic (i.e. interpretation of product catalog, policies/rules, existing products,... ) in a given context.

If you implement business logic individually per FE, you will have a lot of work with change requests in the production environment. You also run the risk of inconsistent logic execution due to several implementations.

Now, the community is working on the Policy API (TMF723) specification. The idea is that the product catalog would reference policies. When a product spec or product offering references a policy the product configurator invokes the Policy API to execute these rules in the context of a quote, order, or shopping cart. This flow and dependencies are described in the TMF760 user guide:

If you have a look at the class diagram, you will see that the ProductConfiguration entity references PolicyRef. If the configurator uses policies to compute the configuration, they are returned as PolicyRef.

In our implementation, we invoke TMF760 on every client event that may require recomputation of the product configuration (characteristic value set/limit, price recalc etc.). We were concerned the API would be too chatty but it turned out it works just fine and the end-user is not impacted due to API invocations.

Regarding the specific use-case when a set of characteristics drives a price selection (e.g. bandwidth defines monthly fee or smartphone storage option defines purchase price): this can be supported in the product catalog alone (TMF620) and the TMF760 is not even needed. In this case, FE would have to implement the logic that recalculated the item price in case of a characteristic value set/change. There is an initiative in the community to extend the TMF620 with characteristic-driven prices. As of now, it would require an API extension, though.

BR, Bostjan

Hello,

Query Product Configuration provides configurations user can choose. When customer chooses any option in the configuration, the request is sent to product configurator then calculated in it. It is so costly operation. For us, we see that when customer changes options in the configuration, price is calculated again. So, configuration should include rule/policy to calculate the price so that FE can calculate it. In the configuration, policy ref is included. But I am not sure if FE should use it. 

Another option instead of having product offering price ref, we can get product offering price value with product spec char values. In the case, FE can calculated prices based on what option customer chooses. I think it is not good that structure is altered. What alternative options can be used?

Hi @Bostjan Keber,

I think, you have requirements customers to choose options that includes all characteristics/attributes and prices. It is prepick pricing as Matthieu said. How did you solve it?

Hi Myagaa Nm,

The whole idea of the product configurator component is that you may have several front-ends (e.g. quoting app, ordering app, e-commerce for customers, mobile app etc.) and all these FEs use the same configuration logic (i.e. interpretation of product catalog, policies/rules, existing products,... ) in a given context.

If you implement business logic individually per FE, you will have a lot of work with change requests in the production environment. You also run the risk of inconsistent logic execution due to several implementations.

Now, the community is working on the Policy API (TMF723) specification. The idea is that the product catalog would reference policies. When a product spec or product offering references a policy the product configurator invokes the Policy API to execute these rules in the context of a quote, order, or shopping cart. This flow and dependencies are described in the TMF760 user guide:

If you have a look at the class diagram, you will see that the ProductConfiguration entity references PolicyRef. If the configurator uses policies to compute the configuration, they are returned as PolicyRef.

In our implementation, we invoke TMF760 on every client event that may require recomputation of the product configuration (characteristic value set/limit, price recalc etc.). We were concerned the API would be too chatty but it turned out it works just fine and the end-user is not impacted due to API invocations.

Regarding the specific use-case when a set of characteristics drives a price selection (e.g. bandwidth defines monthly fee or smartphone storage option defines purchase price): this can be supported in the product catalog alone (TMF620) and the TMF760 is not even needed. In this case, FE would have to implement the logic that recalculated the item price in case of a characteristic value set/change. There is an initiative in the community to extend the TMF620 with characteristic-driven prices. As of now, it would require an API extension, though.

BR, Bostjan

Hello,

Query Product Configuration provides configurations user can choose. When customer chooses any option in the configuration, the request is sent to product configurator then calculated in it. It is so costly operation. For us, we see that when customer changes options in the configuration, price is calculated again. So, configuration should include rule/policy to calculate the price so that FE can calculate it. In the configuration, policy ref is included. But I am not sure if FE should use it. 

Another option instead of having product offering price ref, we can get product offering price value with product spec char values. In the case, FE can calculated prices based on what option customer chooses. I think it is not good that structure is altered. What alternative options can be used?