Open APIs

Hi Team,

I have below queries regarding service qualification V5, does it missing information or new behavior?

1) Service qualification have below data model structure while swagger have "provideAlternative" and "provideResultReason" fields thats not available in below data structure so where should we define swagger inputs?

2) Why "value" is missing under characteristics object?

Hi Chetan

1) The ServiceQualification API has two primary resources, representing the two capabilities exposed by the API: Query (what services are available in principle) and Check (can a given configuration actually be provisioned). provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource.

2) In v5 APIs, Characteristic is an abstract base class, where the concrete subclasses have the value of the characteristic as a property, typed according to JSON schema types. So StringCharacteristic has a value of type string, NumberCharacteristic has a value of type number, etc.

Hope it helps

Hi Team,

I have below queries regarding service qualification V5, does it missing information or new behavior?

1) Service qualification have below data model structure while swagger have "provideAlternative" and "provideResultReason" fields thats not available in below data structure so where should we define swagger inputs?

2) Why "value" is missing under characteristics object?

@Jonathan Goldberg

Thanks a lot for clarification. Its really helpful to build my knowledge.

1) Agree,  provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource but we are not getting these fields in data model in user guide so our query is, where should we define these fields?

2) Just want to confirm our understanding, There will no explicitly value<any > input <same as V4> under Characteristic   but we need to consider concrete subclasses for Characteristic  which may be any string, number, Boolean etc.

Regards

Chetan Hirpara

Hi Chetan

1) The ServiceQualification API has two primary resources, representing the two capabilities exposed by the API: Query (what services are available in principle) and Check (can a given configuration actually be provisioned). provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource.

2) In v5 APIs, Characteristic is an abstract base class, where the concrete subclasses have the value of the characteristic as a property, typed according to JSON schema types. So StringCharacteristic has a value of type string, NumberCharacteristic has a value of type number, etc.

Hope it helps

Hi Team,

I have below queries regarding service qualification V5, does it missing information or new behavior?

1) Service qualification have below data model structure while swagger have "provideAlternative" and "provideResultReason" fields thats not available in below data structure so where should we define swagger inputs?

2) Why "value" is missing under characteristics object?

As I explained, the provideAlternative and provideResultReason are in CheckServiceQualification. I've pasted this diagram directly from the v5 user guide at the Open API published materials https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/Beta/TMF645_Service_Qualification/5.0.0/user_guides/TMF645_Service_Qualification-v5.0.0.pdf

And yes, the Any data type for characteristic from v4 has been replaced by the concrete subclass pattern in v5. It does appear, however, that the subclasses have been erroneously omitted from the swagger/OAS file and the user guide, so I'll open a defect report.

@Jonathan Goldberg

Thanks a lot for clarification. Its really helpful to build my knowledge.

1) Agree,  provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource but we are not getting these fields in data model in user guide so our query is, where should we define these fields?

2) Just want to confirm our understanding, There will no explicitly value<any > input <same as V4> under Characteristic   but we need to consider concrete subclasses for Characteristic  which may be any string, number, Boolean etc.

Regards

Chetan Hirpara

Hi Chetan

1) The ServiceQualification API has two primary resources, representing the two capabilities exposed by the API: Query (what services are available in principle) and Check (can a given configuration actually be provisioned). provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource.

2) In v5 APIs, Characteristic is an abstract base class, where the concrete subclasses have the value of the characteristic as a property, typed according to JSON schema types. So StringCharacteristic has a value of type string, NumberCharacteristic has a value of type number, etc.

Hope it helps

Hi Team,

I have below queries regarding service qualification V5, does it missing information or new behavior?

1) Service qualification have below data model structure while swagger have "provideAlternative" and "provideResultReason" fields thats not available in below data structure so where should we define swagger inputs?

2) Why "value" is missing under characteristics object?

@Jonathan Goldberg

Ok now It's clear. 

We want to implement common data structure for multiple TMF API implementation.

We have one more query, Here we are using service class under service qualificationItem. Can you please guide us which TMF API will be used to create this service? We have referred serviceSpecification resource of TMF633 Service Catalog API but attribute of this resource and service object are different. 

Regards

Chetan Hirpara

As I explained, the provideAlternative and provideResultReason are in CheckServiceQualification. I've pasted this diagram directly from the v5 user guide at the Open API published materials https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/Beta/TMF645_Service_Qualification/5.0.0/user_guides/TMF645_Service_Qualification-v5.0.0.pdf

And yes, the Any data type for characteristic from v4 has been replaced by the concrete subclass pattern in v5. It does appear, however, that the subclasses have been erroneously omitted from the swagger/OAS file and the user guide, so I'll open a defect report.

@Jonathan Goldberg

Thanks a lot for clarification. Its really helpful to build my knowledge.

1) Agree,  provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource but we are not getting these fields in data model in user guide so our query is, where should we define these fields?

2) Just want to confirm our understanding, There will no explicitly value<any > input <same as V4> under Characteristic   but we need to consider concrete subclasses for Characteristic  which may be any string, number, Boolean etc.

Regards

Chetan Hirpara

Hi Chetan

1) The ServiceQualification API has two primary resources, representing the two capabilities exposed by the API: Query (what services are available in principle) and Check (can a given configuration actually be provisioned). provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource.

2) In v5 APIs, Characteristic is an abstract base class, where the concrete subclasses have the value of the characteristic as a property, typed according to JSON schema types. So StringCharacteristic has a value of type string, NumberCharacteristic has a value of type number, etc.

Hope it helps

Hi Team,

I have below queries regarding service qualification V5, does it missing information or new behavior?

1) Service qualification have below data model structure while swagger have "provideAlternative" and "provideResultReason" fields thats not available in below data structure so where should we define swagger inputs?

2) Why "value" is missing under characteristics object?

Hi Chetan

Not sure what you mean by "to create this service".

If you consider an ordering process, it typically starts with a customer-facing product sales and ordering interaction. As part of this interaction, depending on the business, there may be need to check serviceability, i.e. qualification - the BSS (core commerce) layer will need to translate the product being ordered into a service representation, so that the Check endpoint can be invoked. There is no actual service creation (in inventory or in network) at this time.

Later on, the BSS layer will need to submit a service order - again this requires a translation from the product order to a service order. The service order execution will include steps that activate the service in the network (possibly after additional decomposition) - TMF640, and that create the service in the service inventory - TMF638.

You can find examples in the published ODA use cases TMFS002, TMFS003, TMFS004.

@Jonathan Goldberg

Ok now It's clear. 

We want to implement common data structure for multiple TMF API implementation.

We have one more query, Here we are using service class under service qualificationItem. Can you please guide us which TMF API will be used to create this service? We have referred serviceSpecification resource of TMF633 Service Catalog API but attribute of this resource and service object are different. 

Regards

Chetan Hirpara

As I explained, the provideAlternative and provideResultReason are in CheckServiceQualification. I've pasted this diagram directly from the v5 user guide at the Open API published materials https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/Beta/TMF645_Service_Qualification/5.0.0/user_guides/TMF645_Service_Qualification-v5.0.0.pdf

And yes, the Any data type for characteristic from v4 has been replaced by the concrete subclass pattern in v5. It does appear, however, that the subclasses have been erroneously omitted from the swagger/OAS file and the user guide, so I'll open a defect report.

@Jonathan Goldberg

Thanks a lot for clarification. Its really helpful to build my knowledge.

1) Agree,  provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource but we are not getting these fields in data model in user guide so our query is, where should we define these fields?

2) Just want to confirm our understanding, There will no explicitly value<any > input <same as V4> under Characteristic   but we need to consider concrete subclasses for Characteristic  which may be any string, number, Boolean etc.

Regards

Chetan Hirpara

Hi Chetan

1) The ServiceQualification API has two primary resources, representing the two capabilities exposed by the API: Query (what services are available in principle) and Check (can a given configuration actually be provisioned). provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource.

2) In v5 APIs, Characteristic is an abstract base class, where the concrete subclasses have the value of the characteristic as a property, typed according to JSON schema types. So StringCharacteristic has a value of type string, NumberCharacteristic has a value of type number, etc.

Hope it helps

Hi Team,

I have below queries regarding service qualification V5, does it missing information or new behavior?

1) Service qualification have below data model structure while swagger have "provideAlternative" and "provideResultReason" fields thats not available in below data structure so where should we define swagger inputs?

2) Why "value" is missing under characteristics object?

Hi @Jonathan Goldberg

I have referred your shared ODA use cases, its explaining the user purchase journey  but it didn't clear my query.

Let me explain whole scenario.

User will purchase product<Internet Fiber Product Plan > from various platform and product will be combination of service<Fiber Internet> and resource<Modem> or either one.

Here user will select specific product while service provide will check qualification for that service before order submission. 

So in this context, product or service<Fiber Internet> should be already configured in system.  Now we want to understand which TMF API  we can use to configure/create this service in service provider's system?

TMF620 Product Catalog is just using service specification reference that created using TMF633 Service Catalog API. So whatever service reference we are referring under serviceQualificationItem>>service is totally different than we are creating service specification using TMF633 Service Catalog. So want to understand, do we have any specific API that can be helpful to create service resource/object that we referring under serviceQualificationItem>>service.

Regards

Chetan Hirpara

Hi Chetan

Not sure what you mean by "to create this service".

If you consider an ordering process, it typically starts with a customer-facing product sales and ordering interaction. As part of this interaction, depending on the business, there may be need to check serviceability, i.e. qualification - the BSS (core commerce) layer will need to translate the product being ordered into a service representation, so that the Check endpoint can be invoked. There is no actual service creation (in inventory or in network) at this time.

Later on, the BSS layer will need to submit a service order - again this requires a translation from the product order to a service order. The service order execution will include steps that activate the service in the network (possibly after additional decomposition) - TMF640, and that create the service in the service inventory - TMF638.

You can find examples in the published ODA use cases TMFS002, TMFS003, TMFS004.

@Jonathan Goldberg

Ok now It's clear. 

We want to implement common data structure for multiple TMF API implementation.

We have one more query, Here we are using service class under service qualificationItem. Can you please guide us which TMF API will be used to create this service? We have referred serviceSpecification resource of TMF633 Service Catalog API but attribute of this resource and service object are different. 

Regards

Chetan Hirpara

As I explained, the provideAlternative and provideResultReason are in CheckServiceQualification. I've pasted this diagram directly from the v5 user guide at the Open API published materials https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/Beta/TMF645_Service_Qualification/5.0.0/user_guides/TMF645_Service_Qualification-v5.0.0.pdf

And yes, the Any data type for characteristic from v4 has been replaced by the concrete subclass pattern in v5. It does appear, however, that the subclasses have been erroneously omitted from the swagger/OAS file and the user guide, so I'll open a defect report.

@Jonathan Goldberg

Thanks a lot for clarification. Its really helpful to build my knowledge.

1) Agree,  provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource but we are not getting these fields in data model in user guide so our query is, where should we define these fields?

2) Just want to confirm our understanding, There will no explicitly value<any > input <same as V4> under Characteristic   but we need to consider concrete subclasses for Characteristic  which may be any string, number, Boolean etc.

Regards

Chetan Hirpara

Hi Chetan

1) The ServiceQualification API has two primary resources, representing the two capabilities exposed by the API: Query (what services are available in principle) and Check (can a given configuration actually be provisioned). provideAlternative and provideResultReason are properties of the CheckServiceQualification task resource.

2) In v5 APIs, Characteristic is an abstract base class, where the concrete subclasses have the value of the characteristic as a property, typed according to JSON schema types. So StringCharacteristic has a value of type string, NumberCharacteristic has a value of type number, etc.

Hope it helps

Hi Team,

I have below queries regarding service qualification V5, does it missing information or new behavior?

1) Service qualification have below data model structure while swagger have "provideAlternative" and "provideResultReason" fields thats not available in below data structure so where should we define swagger inputs?

2) Why "value" is missing under characteristics object?