Hi Thomas,
We went for a similar approach:
- To offer this kind of serviceability information, which basically aggregates (either by locally stored projections or by invoking legacy trough adapters) based on a geographical address (there is TMF API that works well for that) an set of "flags" indicating what is available on an address. E.g. DSL/Cable/Fibre/LTE and so on, typically flags on available technologies and bandwidths. These are then used for display in agent facing UIs or further simplified in customer facing UIs/sales flows. This indeed is a simply GET call accepting the geographical address (or ID(s)).
- This (those simple flags/keys) we consider context and we've extended the qualification APIs to accept context like this to them (other context usually are shoppingcart or customer account), we expose this context to relevant rule engines and evaluate (in our case using a declarative DSL, e.g. concepts like serviceability, compatibility, eligibility, life-cycle, promotions and so on) which products are available given the serviceability flags (and or any other context). This then you can use in conjunction with e.g. the shopping-cart API.
We faced the same concern you do that the current model (in our opinion) doesn't fit our sales-related uses cases as well as we hoped. What we needed in qualification (a very important topic for us, being oriented at sales (support) processes) was simply information on what is available, and a way for our consumers to translate that easily to which commercial products/services customers can buy in a given context, or how he/she can change products on his/her contract. Without concerning the consumer of the services with too much complexity other then capturing address data.
However most of this we currently do using either schemas not existing in TMF and by extending TMF schemas (as we need to achieve compatibility).
Please let me know how you plan to tackle the challenge in your case. Always interesting to see how different parties use the APIs and how they are extended to make them work IRL.
Br,
------------------------------
Pieter Pabst
Dynacommerce
------------------------------
Original Message:
Sent: Jan 08, 2019 09:02
From: Thomas Dupré
Subject: TMF 645: Synchronous and transient Service Qualification?
Hi,
a typical use case in TelCo industry would be a check whether a given service - or, alternatively, which services at all - are available at a given location (e.g. address). Typically this service is a purely reading request and synchronous, so the service consumer awaits a response within the current session and within a few seconds.
I had a look in TMF 645 (Service Qualification) and found that this is a very powerful and complex modelling:
- a service qualification resource will be created (and persisted) - with an own lifecycle
- it contains mechanism for asynchronous communication
- etc.
which implies the need for a "health care" process in order to remove such service qualification objects after some period of time etc.
This would be fine for complex, asynchronous processes for service qualification checks.
But isn't there also a somewhat "light version" of service qualification available, e.g. some GET method which just returns the possible services at a given place/location? Without any persistence, house-keeping process, state notification changes and all this?
BR Thomas
------------------------------
Thomas Dupré
Deutsche Telekom AG
------------------------------