Open APIs

Expand all | Collapse all

Usage of TMF 645

  • 1.  Usage of TMF 645

    Posted 13 days ago
    Hi Guys,

    Need your valuable inputs here,

    Our requirement is such that we have to check the feasibility of products for the address provided by the customer.
    So now,
    1. BSS requests OSS for a feasibility check(Ex: Is Internet available at Customer Location(Inputs his address) and  what all technology is available at his location(Technology as in Copper or Fibre).
    2. OSS takes this as an input and queries southbound system(s) to  get required information like bandwidth, technology, CPE etc
    3. After which OSS system maps to  structure of TMF 645 and sends back the output.

    Questions:
    1.Can i use TMF 645 for the requirement which i mentioned above ? Or is there any API which i Can use ?
    2.I learnt that TMF 645 supports both Synchronous and Asynchronous. How to determine when to use Synchronous and when Asynchronous  ?

    ------------------------------
    Vijendra Hulmani
    India
    ------------------------------


  • 2.  RE: Usage of TMF 645

    TM Forum Member
    Posted 13 days ago
    Hi
    To my best understanding, Service Qualification (TMF645) is exactly the API and functionality that you are looking for.
    Regarding synch/asynch:
    • If you are implementing this API as a provider, then it is up to you (based on your OSS and network capability) to decide if you can provide a synchronous yes/no answer (always, or sometimes, depending on the request, or not at all). You would presumably document this as part of your implementation documentation so that your consumers know how to behave.
    • If you are consuming this API, and you don't know if the response will be synch or asynch, then you would code your consumer defensively to allow for an immediate success/failure, as well as for an in-progress response (to be tracked afterwards by polling or better listening for the event).
    Hope it helps

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



  • 3.  RE: Usage of TMF 645

    TM Forum Member
    Posted 12 days ago
    Hi,
    I agree with Jonathan, just want to add that, from order management perspective, I would recommend to implement the provider side with an asynchronous response since in general the feasibility process, even if done with a high level of automation, could include rainy day scenarios requiring manual tasks/activities, as for example a site visit, that could not be supported with a simple synchrounous approach.

    Regards,

    ------------------------------
    Dino Pellegrini
    Solution Architect OSS Services&Network Management
    Ericsson Inc.
    ------------------------------



  • 4.  RE: Usage of TMF 645

    TM Forum Member
    Posted 12 days ago
    It depends - consider that in an order capture situation, especially in the residential sector, you have an end user waiting at the UI, who probably expects a quick response. There can be different levels of feasibility and serviceability checks, it might be as simple as checking the address postcode or zipcode against a database, or making some other database query. These examples could be done synchronously.
    The more complex cases, including site surveys, would probably occur in business and enterprise sectors.

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



  • 5.  RE: Usage of TMF 645

    TM Forum Member
    Posted 9 days ago
    Hello
    Agreed with you Jonathan. Just to add more UC... in the MEF API effort that leverage the TMF API open APIs we have the requirement to add in the request an attribute allowing requester to specifically indicate that he/she wants a qualification response completed in the POST response. The UC is between 2 service providers, SP1 requesting for a customer (interacting on SP1portal) an access in SP2 footprint. This is very ambitious from my perspective (on the fly access serviceability could be tricky )...but the requirement is there.

    ------------------------------
    Ludovic Robert
    Orange
    ------------------------------



  • 6.  RE: Usage of TMF 645

    Posted 8 days ago
    Edited by Vijendra Hulmani 8 days ago
    Thanks Jonathan, Dino and Ludovic for sharing your inputs,

    I agree with Ludovic that API needs a way to specify if response is expected sync or async, because both scenarios exists in real world from business perspective, also for the project I am implementing here now.
    Overall we can say that Service Qualification can be of 2 types -
    1. Service Availability ( it is expected that availability is typically answered asap within couple of seconds)
    2. Service Feasibility (a non-availability could lead to a feasibillity check and that could take a longer time, hence would typically execute in async mode).

    Can the authors look at extending the API spec to accomodate this to add an addition parameter?
    For example : serviceQualificationType { checkAvailability, checkFeasibility, checkConnectionPoints,....} and the project could decide to implement and add their qualificationType options based on what backend performance and user experience they want at various points in their journey, by keeping API input and output specs standard and consistent.

    For example in our case :
    CheckAvailabiity - is performed when customer is browsing product offer on portal, and it needs to be as quick as possible ( by checking technology availability information through as less systems as possible).
    checkConnectionPoints - Once user choose a technology based product offering, we need to show him list of available connectionpoints (specially in a complex business building).
    checkFeasibility - When we could not satisfy customer requirement with any alternativeServiceProposal, on portal we can offer a feasiblity check option (for ex. to dig fiber and provide an estimate), and a long running asynchronous feasiblity request is needed here.

    Whats your view on this ?

    ------------------------------
    Vijendra Hulmani
    T-Mobile
    ------------------------------



  • 7.  RE: Usage of TMF 645

    TM Forum Member
    Posted 7 days ago
    Hello Vijendra
    I am not an author but here's what I think about your topic and proposal.
    checkAvailability is already the essence of TMF645.
    checkConnectionPoints would require navigating inventories and routing of a service, ​which is essentially a design task. This could take time, and if this is your intent then consider using TMF640. Once TMF645 returned "Feasible", use TMF640 to create a service instance in "Feasibility Checked" state, then proceed to require the instance be in "Designed" state (via TMF640). When succeeded, you will have the points. Note they will not be Reserved yet, so you can either Cancel or proceed to "Reserved" or "Active" depending on how you Bill the customer.
    The last item you asked is "checkFeasibility" - this is same as checkAvailability but you got negative response which means that a bespoke construction process might be required - here an API will not help because CSP may not be willing, or legal limitations may exist, or network construction is still in progress etc.
    API will not help, this will require manual quoting and appraisal - probably a different engagement channel altogether.

    ------------------------------
    Sergey [Last]
    Australia
    Senior Domain Architect
    ------------------------------



  • 8.  RE: Usage of TMF 645

    TM Forum Member
    Posted 8 days ago
    The API does NOT require that the response is asynchronous ie that the task can't be executed immediately.
    API always returns a 201 with an ID -if the TASK was created successfully.
    The state of the tasks indicate if the request has been completed.
    It is up to the implementation to always return with a state of completed.
    If there is no requirement for supporting GET then either return operation not supported or 404 not found.


    ------------------------------
    pierre gauthier
    TM Forum
    ------------------------------



  • 9.  RE: Usage of TMF 645

    TM Forum Member
    Posted 7 days ago

    Hi,


    I agree with Pierre, it is just an implementation/design aspect and on my point of view there is no need to extent the API profile as the existing one allows both implementations.

    To be noted that the async choise is not "slower" than the synch one, it's just a bit more complex in terms of design/implementation. So, either the synchronous way is preferred for simplicity, or the async way is preferred for flexibility. No point for me to implement both of them with a selection parameter, it's just an extra complexity not providing any benefit.

     

    Best regards,

    Dino



    ------------------------------
    Dino Pellegrini
    Solution Architect OSS Services&Network Management
    Ericsson Inc.
    ------------------------------