Open APIs

 View Only
Expand all | Collapse all

TMF 645: Synchronous and transient Service Qualification?

  • 1.  TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Jan 08, 2019 09:11
    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
    ------------------------------


  • 2.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Jan 09, 2019 03:44
    Hi Thomas

    To my understanding, the ServiceQualification is one example of the TASK resource paradigm that we have in the Open APIs.
    By POSTing a task resource, a business operation is invoked (e.g. address validation, prepay balance topup, and more).
    The TASK resource pattern supports synchronous and asynchronous behavior.

    • For asynch, the POST results in creation (persistence) of the task resource as well as actual execution of the task, and this resource is responsible for subsequent tracking of the task (which may take seconds, minutes, or days). The task resource would be expected to have a status attribute that would be populated with a value such as Pending, In Process, etc. Later notifications or polling would give indication as to when the task is finished (with success or failure).
    • For synch, the POST may or may not create a persistent representation of the resource, and would return a value of success or failure in the status attribute, together with any information that results from the completion of the task (e.g. the validated address, the updated amount of the prepay balance, etc.). The reason for persisting synch task requests might be for auditing, for monetization of tasks, etc.

    It's up to the implementer of the API to decide whether synch or asynch (or both) is supported.

    Hope it helps

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 3.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Jan 10, 2019 06:19
    Hi Thomas, Jonathan,

    The TMF630 design guidelines have a good explanation of how task resources should be implemented.

    • If it returns 200 OK : the task has completed synchronously
    • If it returns 202 Accepted : The task will complete asynchronously

    The implementor has absolute freedom to implement this synchronously or asynchronously.
    So a synchronous implementation of TMF645 can be perfectly compliant to the specifications.

    Regards







  • 4.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Jan 14, 2019 07:25
    Hi Koen,

    I agree that TMF645 can be implemented in a synch or asynch way.

    My primary point, however, is the need to persist Service Qualification resources if I use TMF 645 (at least how I understand it).

    • In most cases the result of a service availability check can be provided to the service consumer within a few seconds and in a purely transient manner by retrieving some sort of service data base. This is a read-only mode, no need to persist anything on the service provider side from a business point of view.
    • However, if I use TMF 645 POST for this availability check, the service provider needs to instanstiate a Service Qualification resource, generate an id for it (and for all involved Service Qualification items) and persist it in order to allow for subsequent GET operations.
      In addition, if we take into account that the number of service qualification requests can be extremely high (anyone in the Internet could submit such a service availability request) we have to take care of a clean-up job that periodically deletes old service qualification objects, and so on.
      For long-running processes (which might involve manual operations for availability check) this seems to be worth the effort - but for the >95% cases of purely reading, short running retrievals of availability information I have some doubts. 
    Therefore I wonder if there might be some more light-weight approach for service availability checks.

    Best regards
    Thomas

    ------------------------------
    Thomas Dupré
    Deutsche Telekom AG
    ------------------------------



  • 5.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Jan 14, 2019 08:30
    Hi Thomas,

    The conformance Profile indeed describes that for a fully compliant solution the GET operation is mandatory.
    However when your implementation is synchronous and not costly I do not see a reason for having it mandatory.
    You could request the OpenAPI team to make the GET operation optional.


    Regards





  • 6.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Jan 10, 2019 06:19
    Hi Jonathan,

    thanks for your reply.

    If I understand you correctly, following your idea, for the synchronous and purely transient case a POST would then just return the available services, but without necessarily creating and persisting a service qualification object. In particular it might not return an id of this service qualification (if it is not persisted). This might look a bit strange - together with the fact that a POST (not a GET) operation would be used to retrieve some information.

    In my humble view (I am just starting to get occupied with this matter in more detail) the question is about the fundamental resource:
    • If it is about a service qualification object then it is a logical consequence that a POST should create it and return its id. This could be used for short-running and long-running service qualification processes by the same interface. (TMF645)
    • What the consumer needs from the business point of view, however, is not the qualification object (this would only be a means to an end) but information about the available services. So maybe a GET method based on the service (not the service qualification) would be more appropriate for this use case, e.g.
      GET /service?fields=...&{filtering}
      where filtering criteria could include the address. This is, however, not (yet) contained e.g. in TMF640.
    So I'm still struggling about the matter...

    BR THomas

    ------------------------------
    Thomas Dupré
    Deutsche Telekom AG
    ------------------------------



  • 7.  RE: TMF 645: Synchronous and transient Service Qualification?

    Posted Jan 09, 2019 04:50
    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
    ------------------------------



  • 8.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Jan 16, 2019 04:54
    ​Hi Thomas
    I have looked at TMF645 and it creates and queries SQ tasks - not services themselves.
    Yes you may get/pass some attributes of the services that are available/wanted at a given location, but these is up to your implementation and interaction design.
    Services are only instantiated (UUID created are returned in responses) when using TMF640.
    If TMF645 returned a service type your customer would like as available, then next call could be creating service instance in "Feasibility Checked" state by TMF640, then progressing it (the instance) into "Reserved" or "Designed" state depending on whether there was a shortfall or intention to reserve necessary resources.
    The "health care" (housekeeping) logic might want to clean-up service/resource reservations after a period of no progress. This is down to overall interaction and business flow design.

    HTH

    ------------------------------
    Sergey Zak
    Australia
    Senior Domain Architect
    ------------------------------



  • 9.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Jan 20, 2019 14:07
    Hi all


    From my (admittedly very limited) experience in the area of service qualification, we can conceive of many use cases, such as:
    • A synchronous check that leaves no traces - this indeed has the characteristics of a query e.g. is idempotent (at least for as long as there are no changes in the network that would cause the query to be different), and in this case a GET on Service might be appropriate. But an additional consideration is that the query may be quite complex, difficult to express in a GET query string.
    • A synchronous check that does work in the network (e.g. reserves candidate resources), here even though the check is synchronous it is not idempotent and a GET on Service would be inappropriate
    • An asynchronous check (whether or not it leaves traces in the network) - here a POST is needed since the check entity (ServiceQualification) must be persisted so that it can be tracked
    Given the above, it is reasonable that a task resource with POST was chosen. We can raise the issue of whether GET on the task resource should be mandatory from conformance perspective.

    Anyway, nice to see a good healthy discussion going on here about service qualification. The team leaders for this API ( @Ludovic Robert and ​@Takayuki Nakamura ​​might want to add their views here.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 10.  RE: TMF 645: Synchronous and transient Service Qualification?

    Posted Aug 12, 2021 00:31
    Edited by Dheeraj dheeraj.joshi@nokia.com Aug 12, 2021 00:54

    I am replying to a fairly old thread. Apologies for doing it.

    However when TMF 645 POST is called? I believe it is called after the service specification is defined. I am interpreting complete service creation and service ordering flow like below

    TMF 633 POST would create a service specification object.
    TMF 645 POST would create a qualification object for a service specification.

    When TMF 641 POST is used to place an order. Internally as part of order processing, TMF 640 POST would create a service instance with an initial state, and TMF 645 GET is called for service specification and if service is qualified to be ordered then service would move to a "feasibilitychecked" state.



    ------------------------------
    ~Dheeraj Joshi

    Nokia
    dheeraj.joshi@nokia.com
    ------------------------------



  • 11.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Aug 12, 2021 01:49
    Hi Dheeraj
    I think there may be a misunderstanding here.

    TMF633 - Service Catalog - the CUD operations (POST/PATCH/DELETE) on ServiceSpecification will be invoked as part of catalog authoring. For Service domain, we can imagine that this will be done when the CSP is introducing a new line-of-business, or updating network technology, or similar. 

    TMF645 - Service Qualification - will typically be invoked as part of an ordering flow, e.g. a customer or partner product order. The Qualification object will be created at this time (if needed, e.g. due to an asynchronous check).

    Possibly what we are missing is a way to author service qualification rules as part of the service specification maintenance.

    Hope it helps

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 12.  RE: TMF 645: Synchronous and transient Service Qualification?

    Posted Aug 12, 2021 02:43

    Ok. Thanks
    The reason why I had interpreted that TMF 645 is created before placing an order is because of the following statement in TMF 645 specification document

    Service Qualification API is one of Pre-Ordering Management API Family. Service Qualification API goal is to provide service technical eligibility in the context of the interaction 


    ------------------------------
    ~Dheeraj Joshi

    Nokia
    dheeraj.joshi@nokia.com
    ------------------------------



  • 13.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Aug 12, 2021 02:51
    Hi Dheeraj
    The statement is perfectly correct, you would typically (depending on line of business) do a service qualification check before placing an order. But it's still part of the overall order capture flow, which happens at runtime (if you like). As distinguished from catalog maintenance that happens at design time.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 14.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Aug 12, 2021 08:12
    Hi Deeraj, I would also add to Jonathan's comment that you will typically query the service inventory for this service qualification step prior to instantiating the service.  You want to know ahead if a particular service technology is supported at a location/address or you want to ask what are all the service types supported again at a location/address.  I suggest you review IG1228 Oda Flow use cases 3 and 4 which will give you a high level flow. 

    Regards... Johanne

    ------------------------------
    Johanne Mayer
    MayerConsult Inc
    ------------------------------



  • 15.  RE: TMF 645: Synchronous and transient Service Qualification?

    TM Forum Member
    Posted Aug 12, 2021 08:20
    Thanks Johanne
    And here's the link to all the published IG1228 use cases:
    https://projects.tmforum.org/wiki/display/PUB/IG1228+How+to+use+ODA%3A+Realizing+Use+Cases+with+Open+APIs+v5.0.0?src=contextnavpagetreemode

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 16.  RE: TMF 645: Synchronous and transient Service Qualification?

    Posted Aug 12, 2021 23:43
    Thanks, @Johanne Mayer & @Jonathan Goldberg​​

    ------------------------------
    ~Dheeraj Joshi

    Nokia
    dheeraj.joshi@nokia.com
    ------------------------------