Open APIs

  • 1.  Trouble Ticket versus Service Problem

    TM Forum Member
    Posted Sep 22, 2021 09:45
    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
    ------------------------------


  • 2.  RE: Trouble Ticket versus Service Problem

    TM Forum Member
    Posted Sep 23, 2021 04:29
    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
    ------------------------------



  • 3.  RE: Trouble Ticket versus Service Problem

    TM Forum Member
    Posted Sep 23, 2021 05:07

    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

    A picture containing drawing  Description automatically generated

     






  • 4.  RE: Trouble Ticket versus Service Problem

    TM Forum Member
    Posted Sep 24, 2021 02:53
    Hi Barry,

    I think there are some synergies between what is being asked here and the discussion on ServiceOrderExceptionEvent. Ludovic has already created AP-2873 to add the new Event to TMF641 Service Order API. I think whenever there is an Exception arising in the Service Order Processing, serviceOrderExceptionEvent will be raised. Exception processing module will listen to this event and in some cases, it can decide that a Trouble Ticket needs to be created to handle this Exception during the Order Processing.

    I understand that there are other scenarios also where a Trouble Ticket needs to be created where the trigger will come from Assurance System and TMF656 Service Problem Management describes those use cases.

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 5.  RE: Trouble Ticket versus Service Problem

    TM Forum Member
    Posted Sep 24, 2021 06:21

    KCOM Commercial in Confidence


     

    Hi Kinshuck,

     

    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.

     

    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

    A picture containing drawing  Description automatically generated

     






  • 6.  RE: Trouble Ticket versus Service Problem

    TM Forum Member
    Posted Sep 24, 2021 08:11
    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
    ------------------------------



  • 7.  RE: Trouble Ticket versus Service Problem

    TM Forum Member
    Posted Sep 24, 2021 08:26

    KCOM Commercial in Confidence


     

    Hi Ludovic,

     

    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!

     

    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

    A picture containing drawing  Description automatically generated