Additional Object for Results in Service Qualification API(TSQ)

[ashwajit_b]

Hello, is it possible to include additional object in the OOTB TSQ API as we need to send some additional details in the service qualification request. Currently I can see that the qualificationResult sent is qualified/unqualified etc., but we need to add an additional object, as per the sample below, which can accommodate few additional status:

"result": {
"qualificationResult": "qualified",
"currentStaus": ",connected till point A",
"availableTechnology": "gpon",

"availabilityDate": "dd/mm/yyyy"
}

[ShashankInamdar · Accepted solution]

Hi @ashwajit_b , all the TMF Open APIs from ServiceNow are extendable. As such, you can make implementation specific changes as described in your requirement.

[ShashankInamdar · Accepted solution]

Hi @ashwajit_b , all the TMF Open APIs from ServiceNow are extendable. As such, you can make implementation specific changes as described in your requirement.

[Aneesh-D · Accepted solution]

Hi @ashwajit_b ,

As mentioned by @ShashankInamdar, you can obviously extend the TMF API implementation, that too in multiple ways. But its important to review if the use case can be achieved in the existing construct itself. Here are my thoughts on these. 

As per TMF645 - there is an overall result and then each individual qualification item has its own result.

Looking at the additional fields that you wanted to add: Wanted to clarify few things.
1) "currentStaus": ",connected till point A",
What is the reason for this field. Is this relevant only when the result is unqualified? If so, there is already a placeholder for this: you can use:

 "eligibilityUnavailabilityReason": [
 {
 "code": "26-001",
 "label": "not enough bandwith at this place",
 "@baseType": "string",
 "@schemaLocation": "string",
 "@type": "string"
 }

2) "availableTechnology": "gpon",

As per product-service-resource catalog model: if the given service has multiple ways of implementation depending on the technology used, then it will have multiple rfs specification:  say rfs1 for GPON and rfs2 for EPON.
Now as part of TMF645, you are qualifying the service (cfs) for a given location or criteria. Now the result could be:

-> GPON - qualified
-> EPON - unqualified.

So you can use individual "serviceQualificationItem" object for each rfs's and mark its qualificationResult. for those unqualified you can use "eligibilityUnavailabilityReason" to capture the reason why its not qualified.

If you want to send mode details regarding the rfs then "serviceCharacteristic" array can be used. 

 "serviceCharacteristic": [
 {
 "id": "1",
 "name": "A End Location",
 "valueType": "string",
 "value": "start_location"
 },
 {
 "id": "1",
 "name": "Z End Location",
 "valueType": "string",
 "value": "end_location"
 }
]

In case where multiple rfs are available and if you want to know details about each then your initial approach just adding a "availableTechnology" field in the result object will not scale.

3) availabilityDate

I assume this field indicates the date from which this the service will be available for the given qualification request.
When a qualification is requested, requester can mention by which date the service is expected and activated. place holder for these: expectedQualificationDate, expectedActivationDate.

Now, if within these date, if the service can be provided then the response will be qualified. and incase if its not feasible then the response will be unqualified. So it make sense in the case of unqualified result, to provide a future  date by when the service can be provided. That can be done by providing an alternate proposal and you can use alternateServiceAvailabilityDate to give that future date.

Let me know if you need any further assistance.

Thanks,

Aneesh D