Hi Barry,
Yes TMF656.
If you look on the swagger (https://github.com/tmforum-apis/TMF656_ServiceProblemManagement/blob/master/TMF656-ServiceProblem-v4.0.0.swagger.json) you'll notice a /listener/serviceProblemStateChangeEvent.
So, for me when you have a serviced problem and assessed it as
inProgress then this even could be triggered and sent to your client (if they subscribed to this event type of course).
Nothing prevent your customer to raise TT. Then, when an existing TT is related to serviceProblem, you can link to TT to ServiceProblem (using relatedEntity).
Hope it helps,
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------
Original Message:
Sent: Sep 23, 2021 05:06
From: Barry Clarkson
Subject: Trouble Ticket versus Service Problem
KCOM Commercial in Confidence
Hi,
Thank you for following up on my question. Do you mean Service Problem Management TMF656? I can see that but I can't see anything for Service Problem Event in the Open API list. We would pass on a case/incident with a Trouble Ticket if it was raised by a network event. There are also use cases where we transfer/notify records that are not based on an event. It may have come via a CP customer.
Kind regards,
Barry
Barry Clarkson
Solution Architect
37 Carr Lane
HULL
HU1 3RE
E: barry.clarkson@kcom.com
T: 01482 248 532
M: 07738 170 272
www.kcom.com
Original Message:
Sent: 9/23/2021 4:29:00 AM
From: Ludovic Robert
Subject: RE: Trouble Ticket versus Service Problem
Hello Barry,
Did you take a look on the service problem event ?
For me, once a service problem is created - or state changed - an event is raised. These events could be listened internally but also externally (of course with some filtering). Your communication provider could receive these events and get informed. In order to get this, they have to provide an endpoint to get event.
Hope it helps,
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Sep 22, 2021 07:09
From: Barry Clarkson
Subject: Trouble Ticket versus Service Problem
Hi everyone,
I'm looking for some guidance or experience to this "issue". We have an implementation of the Trouble Ticket API we're using to receive network events to drive our service management platform - "southbound". We have a requirement for a "northbound" interface for our communications providers (CPs) to who we provide service(s). That could be them telling us about an issue or us notifying them of something we've detected. Given the payload of the Trouble Ticket API, we'd need to extend it polymorphically. The Service Problem payload looks more relevant with Service, SLA, embedded Trouble Ticket, etc.
Thoughts on this, please?
Kind regards,
Barry
------------------------------
Barry Clarkson
Solution Architect
KCOM Group Limited
------------------------------