KCOM Commercial in Confidence
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.
Barry Clarkson Solution Architect 37 Carr Lane HULL HU1 3RE E: firstname.lastname@example.org T: 01482 248 532 M: 07738 170 272 www.kcom.com
Thank you for your response. My requirements are firmly in the assurance/service management space, not around ordering. We receive network events through a Trouble Ticket API that then creates an incident record in our service management platform. I'm still pondering the use of extending Trouble Ticket for our CPs to include related references to service and SLAs versus the use of Service Problem which is directly for service providers such as ourselves to our CPs and their customers and it already is more explicit in its payload with service and SLAs etc. A lot of the APIs are subjective and open to interpretation so I'm trying to collate yours and other member experiences so that we develop and deploy the right solution working with my colleagues where we're looking at Service Test and Service Inventory.
Thank you again for responding. Given the responses I'm coming down on the side of using Service Problem with our CPs. As you say, that has a trouble ticket related entity if we created one from a network event. Time to do some analysis and design work!