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:
Sent: Mar 15, 2019 07:00
From: Ludovic Robert
Subject: Usage of TMF 645
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:
Sent: Mar 14, 2019 10:51
From: Jonathan Goldberg
Subject: Usage of TMF 645
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:
Sent: Mar 14, 2019 04:09
From: Dino Pellegrini
Subject: Usage of TMF 645
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:
Sent: Mar 13, 2019 14:49
From: Jonathan Goldberg
Subject: Usage of TMF 645
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:
Sent: Mar 13, 2019 06:23
From: Vijendra Hulmani
Subject: Usage of TMF 645
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
------------------------------