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...

[Dewald]

Hi Tom,

I want to use it for eBonding to Customer with their own ITSM system

Here is an example extract from TM Forum API

    {
      "id": "9176",
      "href": "https://host:port/partyManagement/v1/customer/9176",
      "name": "Jack Smith",
      "role": "customer",
      "@referredType": "Customer"
    }

It would make sense for the Customer calling the service to pass a "name" value eg "Jack Smith".

Thus your API needs a bit of extending still in terms of the schema to align with a more usable format.

[Tom Schnarr]

You are proposing what amounts to be a slippery slope that we are careful on implementing.  This api (TMF622) is a request to create an order - you are proposing that behind that order request we should create the customer record, and therefore we also likely need a contact and a location, and why not a offering, a product spec, a sla/commitment, and the list goes on.  From a product perspective - we have tried to manage the 'intention' of the TMF apis - this one creates an order and has refereces to the related entities.  We do hear that behind the order apis it may back sense to create some entities (as you are suggesting) and we  have a roadmap item to create some objects/entities behind the order - customer, location, contact are candidates.  I can't commit to when this will be delivered.  The pattern of integration for this fucntionality will be to create a customer, create a location, create a contact, then create order (referencing offerings/specs/chars that you need).  Which is consistent with our interpretation of TMF APIs.

[Dewald]

Hi Tom,

I am referring to TMF621 which is TroubleTicket Management, which means creating, tracking and managing trouble tickets as a result of an issue or problem identified by a customer on an existing service.