Open APIs

Hello Community,
I am looking at the TMF645 v4.0.1 API. In the past, we have already implemented v3 once in our environment.

I have to be honest, I haven't really understood the difference between a CheckServiceQualification and QueryServiceQualification. Does anyone dare to give me concrete examples of when to use what and where the difference lies? Reading the related API guide hasn't worked for me yet :-/

Thanks and regards,

Jan

• Check allows me to pass in a specific service configuration and see if this can be provisioned at the service address (and if not, what are feasible alternatives). It's quite possible that this will take time, i.e. there won't be an immediate synchronous response. Additionally, the check might need more information (an event will be raised if so).
• Query allows me to get a list of possible services for a service address, without supplying a configuration up-front. It's more likely to give an immediate response (although it can be asynchronous as well).

Hello Community,
I am looking at the TMF645 v4.0.1 API. In the past, we have already implemented v3 once in our environment.

I have to be honest, I haven't really understood the difference between a CheckServiceQualification and QueryServiceQualification. Does anyone dare to give me concrete examples of when to use what and where the difference lies? Reading the related API guide hasn't worked for me yet :-/

Thanks and regards,

Jan

• if the configuration is not qualified, reason could be provided
• Alternate eligible service configuration could be pass also in the response

• Check allows me to pass in a specific service configuration and see if this can be provisioned at the service address (and if not, what are feasible alternatives). It's quite possible that this will take time, i.e. there won't be an immediate synchronous response. Additionally, the check might need more information (an event will be raised if so).
• Query allows me to get a list of possible services for a service address, without supplying a configuration up-front. It's more likely to give an immediate response (although it can be asynchronous as well).

Hello Community,
I am looking at the TMF645 v4.0.1 API. In the past, we have already implemented v3 once in our environment.

I have to be honest, I haven't really understood the difference between a CheckServiceQualification and QueryServiceQualification. Does anyone dare to give me concrete examples of when to use what and where the difference lies? Reading the related API guide hasn't worked for me yet :-/

Thanks and regards,

Jan

Hi @Ludovic Robert and @Jonathan Goldberg

Thanks for your insights.

In my use case, the requestor has a Place, a specific ServiceSpecification (in our case an InternetLeasedLine) and a bandwidth demand.
Did I understand correctly that in this case the CheckServiceQualification would be a good fit?​​

/Jan

• if the configuration is not qualified, reason could be provided
• Alternate eligible service configuration could be pass also in the response

• Check allows me to pass in a specific service configuration and see if this can be provisioned at the service address (and if not, what are feasible alternatives). It's quite possible that this will take time, i.e. there won't be an immediate synchronous response. Additionally, the check might need more information (an event will be raised if so).
• Query allows me to get a list of possible services for a service address, without supplying a configuration up-front. It's more likely to give an immediate response (although it can be asynchronous as well).

Hello Community,
I am looking at the TMF645 v4.0.1 API. In the past, we have already implemented v3 once in our environment.

I have to be honest, I haven't really understood the difference between a CheckServiceQualification and QueryServiceQualification. Does anyone dare to give me concrete examples of when to use what and where the difference lies? Reading the related API guide hasn't worked for me yet :-/

Thanks and regards,

Jan

Hi @Ludovic Robert and @Jonathan Goldberg

Thanks for your insights.

In my use case, the requestor has a Place, a specific ServiceSpecification (in our case an InternetLeasedLine) and a bandwidth demand.
Did I understand correctly that in this case the CheckServiceQualification would be a good fit?​​

/Jan

• if the configuration is not qualified, reason could be provided
• Alternate eligible service configuration could be pass also in the response

• Check allows me to pass in a specific service configuration and see if this can be provisioned at the service address (and if not, what are feasible alternatives). It's quite possible that this will take time, i.e. there won't be an immediate synchronous response. Additionally, the check might need more information (an event will be raised if so).
• Query allows me to get a list of possible services for a service address, without supplying a configuration up-front. It's more likely to give an immediate response (although it can be asynchronous as well).

Hello Community,
I am looking at the TMF645 v4.0.1 API. In the past, we have already implemented v3 once in our environment.

I have to be honest, I haven't really understood the difference between a CheckServiceQualification and QueryServiceQualification. Does anyone dare to give me concrete examples of when to use what and where the difference lies? Reading the related API guide hasn't worked for me yet :-/

Thanks and regards,

Jan

• Check allows me to pass in a specific service configuration and see if this can be provisioned at the service address (and if not, what are feasible alternatives). It's quite possible that this will take time, i.e. there won't be an immediate synchronous response. Additionally, the check might need more information (an event will be raised if so).
• Query allows me to get a list of possible services for a service address, without supplying a configuration up-front. It's more likely to give an immediate response (although it can be asynchronous as well).

Hello Community,
I am looking at the TMF645 v4.0.1 API. In the past, we have already implemented v3 once in our environment.

I have to be honest, I haven't really understood the difference between a CheckServiceQualification and QueryServiceQualification. Does anyone dare to give me concrete examples of when to use what and where the difference lies? Reading the related API guide hasn't worked for me yet :-/

Thanks and regards,

Jan

Hi @Jonathan Goldberg

Its was really helpful to clear our understanding.  

We are referring TMF swagger for this API and getting various operations<POST, GET,PATCH,GET-ID,DELETE> under each resource <queryServiceQaulification and checkServiceQualification>.

We are getting below information<use operations to retrieve information> in all the operations.  Can you please guide, when should we use POST and GET operation for both resources? Will POST operation use to create any entry in database because description is saying to use for retrieving services?

• Check allows me to pass in a specific service configuration and see if this can be provisioned at the service address (and if not, what are feasible alternatives). It's quite possible that this will take time, i.e. there won't be an immediate synchronous response. Additionally, the check might need more information (an event will be raised if so).
• Query allows me to get a list of possible services for a service address, without supplying a configuration up-front. It's more likely to give an immediate response (although it can be asynchronous as well).

Hello Community,
I am looking at the TMF645 v4.0.1 API. In the past, we have already implemented v3 once in our environment.

I have to be honest, I haven't really understood the difference between a CheckServiceQualification and QueryServiceQualification. Does anyone dare to give me concrete examples of when to use what and where the difference lies? Reading the related API guide hasn't worked for me yet :-/

Thanks and regards,

Jan

Hi Chetan

Both of these entities are Task entities, see the TMF630 Design Guidelines for full details of what a Task entity is.

In short, to carry out the Task, you POST a task entity, e.g. CheckServiceQualification entity with all the relevant information populated in the request.

Depending on the implementation (and definitely if the task is performed asynchronously), the task will be persisted as part of the POST (201 returned), and in this case you can use GET to retrieve the task. Typically you would listen to a status change event on the task entity, and do the GET only when the task reports completed.

Hope it helps

Hi @Jonathan Goldberg

Its was really helpful to clear our understanding.  

We are referring TMF swagger for this API and getting various operations<POST, GET,PATCH,GET-ID,DELETE> under each resource <queryServiceQaulification and checkServiceQualification>.

We are getting below information<use operations to retrieve information> in all the operations.  Can you please guide, when should we use POST and GET operation for both resources? Will POST operation use to create any entry in database because description is saying to use for retrieving services?

• Check allows me to pass in a specific service configuration and see if this can be provisioned at the service address (and if not, what are feasible alternatives). It's quite possible that this will take time, i.e. there won't be an immediate synchronous response. Additionally, the check might need more information (an event will be raised if so).
• Query allows me to get a list of possible services for a service address, without supplying a configuration up-front. It's more likely to give an immediate response (although it can be asynchronous as well).

Hello Community,
I am looking at the TMF645 v4.0.1 API. In the past, we have already implemented v3 once in our environment.

I have to be honest, I haven't really understood the difference between a CheckServiceQualification and QueryServiceQualification. Does anyone dare to give me concrete examples of when to use what and where the difference lies? Reading the related API guide hasn't worked for me yet :-/

Thanks and regards,

Jan