TMF621 Not functional when trying to implement in the real world

[Dewald]

The Open API Specification:

TMF621 Trouble Ticket Management API REST Specification

ServiceNow Documentation:

Trouble Ticket Open API

Spoiler

Use this API to manage ticket information between external ticketing systems and the Now Platform.

Trying this out as part of an actual implementation in the Telecoms Industry I find it lacks a lot of functionality:

• Channel is hardcoded in script and not dynamically linked to the option list that was added to in front end.
• relatedEntity.id - Sys_id of the impacted item or service - how would any calling system know this?
• relatedParty.id - Sys_id is from the Contact [customer_contact] - how would any calling system know this?
• attachment - not catered for, must call it as a separate call

That is just getting an actual ticket created in ServiceNow.

Communicating back to the calling system the TMF Specification mentions the following.

Notification of events on trouble ticket:
o Trouble ticket state change
o Trouble ticket value change
o Trouble ticket resolved
o Trouble ticket created
o Trouble ticket deleted, typically restricted to admin role
o Trouble ticket Information required

It seems like this should all be implemented from scratch...

[Rahul Priyadars]

I was trying with Different Channel Values in PAYLOAD its making use of It..I Spinned case using TMF 621

• relatedParty.id - Sys_id is from the Contact [customer_contact] - how would any calling system know this?--> Which Calling System you are using and how are you trigerring this. Customer Contact comes into Picture for B2B Customers. Calling System either store Accounts vs Contact Mapping or fetch it from some other system.
• relatedEntity.id - Sys_id of the impacted item or service - how would any calling system know this?

So when raising case or Incident using TMF 621 - Which Install base Item or CI is having Problem? In your source system do u have these data ?

Regards

RP

[Dewald]

Hi Rahul,

Add a new channel on the List Lookup - In our use case we want to track "Incidents created by system".

• Thus we added our system OSSI as an option for the choice list.

Use case for calling system would be customer ITSM Tool wanting to "eBond" to us.

• It would make sense if you can pass customer referential data:
  • AccountNo - which is understandable between us and customer (A002448-01)
  • Location
  • Product or Service affected

[snowdev8]

Channel needs to be set in two places - on the Case itself and then there is another table too where it needs to be maintained. I am not at my workstation, but it needs to be hunted down.

Related Entity and Party - you should be able to override the OOB Script Includes either to look up by some other common ID between the two systems or to use a default value

[Tom Schnarr]

I understand the concern of the client knowing relatedEntity.id and relatedParty.id - but these are the patterns defined by TMForum in the use of their APIs.  We have been extending the TMF APIs in many scenarios to take advantage of 'external_id' (customer.external_id, location.external_id, contact.external_id - soon product_inventory.external_id (Vancouver)).  I well take your suggestion and get on the product backlog a request to extend this API to support the use of an 'externalId' on EntityId and RelatedPartyId.