Open APIs

Dear community.

I understand that there can be two different options (or more) how to model mobile offer in the product catalog and TMF760 seems to support both of them:

1. As a bundled offering - customer can "select" add-ons and subsidized device using hierarchical structure of QueryProductConfiguration.queryProductConfigurationItem.
2. As a flat list of simple offerings with relationships (compatible, requires, etc) - TMF provides list of QueryProductConfiguration.requestProductConfigurationItem on the input.

Typically there is configuration "wizard" in eShop/shop assistant UI. Customer can define his requested configuration in the mutiple steps:

• He chooses tariff
• He selects subsidized device from the HUGE list of devices (based on many features)
• He selects add-ons

It seems to me that TMF760 is naturally optimized for option #2. TMF760 API can be used to query list of devices based on the selected tariff and other criterias.

Unfortunatelly, I do not have experience with option #1. What is the best practice to avoid huge responses?

• A) Should we return partial product configuration without device nodes based on the context (e.g. wizard step, specified criteria)?
• B) Should we model indirection to support something as "lazy loading"? E.g. extend BundledProducfOffering to specify that customer can buy devices from the specified category and using the defined pricelist.
• C) Any other?

Thanks a lot.

Dear community.

I understand that there can be two different options (or more) how to model mobile offer in the product catalog and TMF760 seems to support both of them:

1. As a bundled offering - customer can "select" add-ons and subsidized device using hierarchical structure of QueryProductConfiguration.queryProductConfigurationItem.
2. As a flat list of simple offerings with relationships (compatible, requires, etc) - TMF provides list of QueryProductConfiguration.requestProductConfigurationItem on the input.

Typically there is configuration "wizard" in eShop/shop assistant UI. Customer can define his requested configuration in the mutiple steps:

• He chooses tariff
• He selects subsidized device from the HUGE list of devices (based on many features)
• He selects add-ons

It seems to me that TMF760 is naturally optimized for option #2. TMF760 API can be used to query list of devices based on the selected tariff and other criterias.

Unfortunatelly, I do not have experience with option #1. What is the best practice to avoid huge responses?

• A) Should we return partial product configuration without device nodes based on the context (e.g. wizard step, specified criteria)?
• B) Should we model indirection to support something as "lazy loading"? E.g. extend BundledProducfOffering to specify that customer can buy devices from the specified category and using the defined pricelist.
• C) Any other?

Thanks a lot.

We do optimize payloads in the way that the initial configuration includes only bundled and related product offerings that are mandatory to be configured as a part of the base offering. For example, when picking a mobile tariff plan (offering), the TMF760 post/create invocation returns a minimum response needed to configure the plan. If a selection of a handset is part of the minimum configuration, there would be a list of devices, but typically, this is not the case as the list is usually pretty comprehensive (wide range of devices).

We usually model devices as add-ons (related to base product offerings with a relationship of type "add-on"). Once the base product offering is configured, the user gets an option to configure add-ons. TMF679 is used to determine commercial eligibility (i.e. determine the handset at the right price / subsidy depending on the base plan). To limit payloads, input arguments are offering category or part of product offering name. The response is paginated.

An exception where devices would be bundled offerings, are, for example, STB offerings. IPTV cannot be configured without an STB (or smart TV app), so a selection of an STB product offering would be obligatory on the configuration screen. Meaning - these offerings would be modeled as bundled offerings under the IPTV offering (usually bundled under an n-play package offering). But then - there are usually very few STB offerings to choose from (unlike handsets).

Dear community.

I understand that there can be two different options (or more) how to model mobile offer in the product catalog and TMF760 seems to support both of them:

1. As a bundled offering - customer can "select" add-ons and subsidized device using hierarchical structure of QueryProductConfiguration.queryProductConfigurationItem.
2. As a flat list of simple offerings with relationships (compatible, requires, etc) - TMF provides list of QueryProductConfiguration.requestProductConfigurationItem on the input.

Typically there is configuration "wizard" in eShop/shop assistant UI. Customer can define his requested configuration in the mutiple steps:

• He chooses tariff
• He selects subsidized device from the HUGE list of devices (based on many features)
• He selects add-ons

It seems to me that TMF760 is naturally optimized for option #2. TMF760 API can be used to query list of devices based on the selected tariff and other criterias.

Unfortunatelly, I do not have experience with option #1. What is the best practice to avoid huge responses?

• A) Should we return partial product configuration without device nodes based on the context (e.g. wizard step, specified criteria)?
• B) Should we model indirection to support something as "lazy loading"? E.g. extend BundledProducfOffering to specify that customer can buy devices from the specified category and using the defined pricelist.
• C) Any other?

Thanks a lot.

hi @Bostjan Keber,

Great insightful tips on product modelling (bundled vs product relationships for long list of handsets offers).

what is "mandatory to be configured"?

Do you mean to define a minimum qty in bundledGroupProductOffering ("box") to make a product group mandatory but still let customer select and configure a product ("box 1", "box 2") that exist in that Group?

A minimum qty on the bundledProductOfferingOption alone would also make a product "mandatory" but not "configurable" in the sense that customers has options to choose from.

• Do you have an example of a QueryProductConfiguration response for a bundle that contains an optional and a mandatory bundle in  bundledProductOfferingOption?
  (curious to see how is the payload is optimised in the case of "bundled bundles")
• Do you have an example of a QueryProductConfiguration response for a product offering that has related product offerings (e.g. your example of mobile handset add-on).
  • • the guide says:
      • ProductConfigurationItemRelationship is a list of product configuration item(s) related to the ProductConfigurationItem from the same CheckProductConfiguration. Relationship may represent a bundle, an add-on etc.
    • I assume there is a little bug in the definition as it should say  "from the same CheckProductConfiguration or  QueryProductConfiguration"
    • the "Fiber contract" bundle example (UC003 from IG1228) is not using ProductConfigurationItemRelationship for any bundle, add-on etc relationships except between the "request" id and the "compute" id with a role called "requestItem":
      
      • 

@Peter Rajsky if you look in the TMF760 OAS file, we have an example for UC003 from IG1228.

You will see that the bundle offers 2 STBs. One is selected (box 1) and the other isn't (box 2)

you will notice some payload optimisation for box 2. (configurationCharacteristic node is absent on box 2)

We do optimize payloads in the way that the initial configuration includes only bundled and related product offerings that are mandatory to be configured as a part of the base offering. For example, when picking a mobile tariff plan (offering), the TMF760 post/create invocation returns a minimum response needed to configure the plan. If a selection of a handset is part of the minimum configuration, there would be a list of devices, but typically, this is not the case as the list is usually pretty comprehensive (wide range of devices).

We usually model devices as add-ons (related to base product offerings with a relationship of type "add-on"). Once the base product offering is configured, the user gets an option to configure add-ons. TMF679 is used to determine commercial eligibility (i.e. determine the handset at the right price / subsidy depending on the base plan). To limit payloads, input arguments are offering category or part of product offering name. The response is paginated.

An exception where devices would be bundled offerings, are, for example, STB offerings. IPTV cannot be configured without an STB (or smart TV app), so a selection of an STB product offering would be obligatory on the configuration screen. Meaning - these offerings would be modeled as bundled offerings under the IPTV offering (usually bundled under an n-play package offering). But then - there are usually very few STB offerings to choose from (unlike handsets).

Dear community.

I understand that there can be two different options (or more) how to model mobile offer in the product catalog and TMF760 seems to support both of them:

1. As a bundled offering - customer can "select" add-ons and subsidized device using hierarchical structure of QueryProductConfiguration.queryProductConfigurationItem.
2. As a flat list of simple offerings with relationships (compatible, requires, etc) - TMF provides list of QueryProductConfiguration.requestProductConfigurationItem on the input.

Typically there is configuration "wizard" in eShop/shop assistant UI. Customer can define his requested configuration in the mutiple steps:

• He chooses tariff
• He selects subsidized device from the HUGE list of devices (based on many features)
• He selects add-ons

It seems to me that TMF760 is naturally optimized for option #2. TMF760 API can be used to query list of devices based on the selected tariff and other criterias.

Unfortunatelly, I do not have experience with option #1. What is the best practice to avoid huge responses?

• A) Should we return partial product configuration without device nodes based on the context (e.g. wizard step, specified criteria)?
• B) Should we model indirection to support something as "lazy loading"? E.g. extend BundledProducfOffering to specify that customer can buy devices from the specified category and using the defined pricelist.
• C) Any other?

Thanks a lot.