Open APIs

Hello,

I have a question regarding the OpenAPI TMF645 Service Qualification API, which is part of the Pre-Ordering Management APIs. As I understand it, the Service Qualification API's goal is to assess service availability at the customer location.

In typical implementations, the TMFC009 Service Qualification Management component often utilizes other APIs such as the Service Catalog, Geographic Address Management, or Inventory to evaluate technical feasibility.

However, in the case I am working on, the service is more complex. It involves sending a technician to the customer's home, scheduling an appointment, and reserving specific equipment to perform measurements.

My question is: Is the Service Qualification Management component the right one to orchestrate this process? The workflow seems to be closer to a Service Order creation rather than a simple service qualification.

I would appreciate any insights or suggestions from the community on how to approach this scenario effectively.

Thank you in advance!

Hi,

TMF has a Work Order Management (TMFC061) component is responsible for setup and maintenance requests from initiation to completion at party's location.

TMFC009 will not orchestrate any activities that would "upgrade" the customer location to make it compatible with the requested CFS (CFSspec).

If you POST a request towards the TMF645 CHECK endpoint, you will get a response that has:

• Eligibility unavailability reason
• Alternate service proposal

 in the AlternateServiceProposal sub-resource, 645 provide the alternate service. It can be another service or it can be the CFS  that you requested but with a future date (alternateServiceAvailabilityDate).

What is not clear is how TMFC009 can calculate that alternateServiceAvailabilityDate, which will be the date your field technician is expected to upgrade the location's CPE in order to provide one technical solution (RFSspec) available to deliver the requested service (CFSspec).

what TMFC009 cannot do, I think, is to tell you what RFSspec is needed

Another approach is to POST a request towards the TMF645 QUERY endpoint. with Query, you only get what exist at the location. No qualification rules  are computed. It's the requester that has to contain all the logic to evaluate SQ and determine alternatives. Our BSS does this because it has its own SQ component and it works with the product catalogue and product configurator to identify what products are missing and can also automatically add the required product offers in the carts:

• tangible products like Gigabit fiber, PON, fiber CPE etc
• non tangible x hours of a field technician, engineer etc
• generic installation charges (software config is OSS, swapping cables, planning activities, construction company work etc)

then customer must accept our proposal (still a cart) which becomes an product order and then you can use TMFC003 to orchestrate all the dependent orders in the right sequence (first the work orders).

In general, I see more and more questions about how ODA component can work together. once to try to make them work together, we often see gaps. Service Qualification is an area that has many gaps as we have seen in a recent post on CFS determination)

Hello,

I have a question regarding the OpenAPI TMF645 Service Qualification API, which is part of the Pre-Ordering Management APIs. As I understand it, the Service Qualification API's goal is to assess service availability at the customer location.

In typical implementations, the TMFC009 Service Qualification Management component often utilizes other APIs such as the Service Catalog, Geographic Address Management, or Inventory to evaluate technical feasibility.

However, in the case I am working on, the service is more complex. It involves sending a technician to the customer's home, scheduling an appointment, and reserving specific equipment to perform measurements.

My question is: Is the Service Qualification Management component the right one to orchestrate this process? The workflow seems to be closer to a Service Order creation rather than a simple service qualification.

I would appreciate any insights or suggestions from the community on how to approach this scenario effectively.

Thank you in advance!

Hello,

I have a question regarding the OpenAPI TMF645 Service Qualification API, which is part of the Pre-Ordering Management APIs. As I understand it, the Service Qualification API's goal is to assess service availability at the customer location.

In typical implementations, the TMFC009 Service Qualification Management component often utilizes other APIs such as the Service Catalog, Geographic Address Management, or Inventory to evaluate technical feasibility.

However, in the case I am working on, the service is more complex. It involves sending a technician to the customer's home, scheduling an appointment, and reserving specific equipment to perform measurements.

My question is: Is the Service Qualification Management component the right one to orchestrate this process? The workflow seems to be closer to a Service Order creation rather than a simple service qualification.

I would appreciate any insights or suggestions from the community on how to approach this scenario effectively.

Thank you in advance!