Open APIs

 View Only
Back to discussions
Expand all | Collapse all

Usage of TMF 645

  • 1.  Usage of TMF 645

    Posted Mar 13, 2019 09:32
    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 Mar 13, 2019 15:15
    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
    ------------------------------

    Original Message


  • 3.  RE: Usage of TMF 645

    Posted Mar 14, 2019 05:01
    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.
    ------------------------------

    Original Message


  • 4.  RE: Usage of TMF 645

    TM Forum Member
    Posted Mar 14, 2019 11:31
    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
    ------------------------------

    Original Message


  • 5.  RE: Usage of TMF 645

    TM Forum Member
    Posted Mar 17, 2019 20:53
    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
    ------------------------------

    Original Message


  • 6.  RE: Usage of TMF 645

    Posted Mar 18, 2019 05:30
    Edited by Vijendra Hulmani Mar 18, 2019 06:52
    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
    ------------------------------

    Original Message


  • 7.  RE: Usage of TMF 645

    TM Forum Member
    Posted Mar 19, 2019 05:54
    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
    ------------------------------

    Original Message


  • 8.  RE: Usage of TMF 645
    Best Answer

    TM Forum Member
    Posted Mar 18, 2019 08:58
    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
    ------------------------------

    Original Message


  • 9.  RE: Usage of TMF 645

    Posted Mar 19, 2019 05:55

    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.
    ------------------------------

    Original Message


  • 10.  RE: Usage of TMF 645

    TM Forum Member
    Posted Mar 29, 2019 04:52
    I think it would be a good idea to update TMF630 to explain better how both server and client could handle asynch an synch operations.

    Currently there is no explanation on how a client can request its prefered response type.
    Client behaviour
    I suggest TMF630 could be extended with a section that adopts RFC7240 for OpenAPI.

    RFC7240 defines a Prefer HTTP header that can be used for this.
    It allows the client to add a header like this:

    Prefer: async-respond

    This indicates that the client always prefers to get an asynchronous response. Alternatively the header could be:

    Prefer: async-respond, wait=10

    This indicates that the client prefers to get a synchronous response, unless the response is expected to take more then 10 seconds to caculate.

    Server behaviour
    Servers should use HTTP response codes to indicate synchronous or asynchronous operation. This is already appearing in TMF630 but could be made more explicit:

    201 Created -> the workflow completed synchronously
    202 Accepted -> an asynchronous workflow started succesfully, but will complete later.




    ------------------------------
    Koenraad Peeters
    Ciminko Luxembourg
    ------------------------------

    Original Message


  • 11.  RE: Usage of TMF 645

    Posted Mar 28, 2019 10:21
    Hi Pierre,

    Thanks for the confirmation that it is not mandatory to implement TMF 645 as Asynchronous and having an HTTP 201 could be the only step in the API. The reason this question was raised was to ensure that we implement a fully compliant version of API and not have an interpretation of ourselves (in order to make sure other consumers interpret it the same way).
    Do you think it is a good idea to explicitly mention your above comments in the document as well for people to benefit in future referring the document ?

    BR

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

    Original Message