Open APIs

 View Only
  • 1.  TMF641: Service Ordering API: Notification: Content and Registering

    TM Forum Member
    Posted Jul 07, 2018 15:12
    Dear TMF641 Committers and Experts,

    Two questions regarding the Notifications of Type "ServiceOrderChangeStateNotification", where I need your experience in implementing the API.

    1.) Is it possible (by TMF standard) to define exactly on which state change notifications to be informed? In the current use case, a client is only interested in the change state to "Completed".
    2.) In case of a ServiceOrderChangeState, a client is interested about some attributes inside a specific service charactersistic of the service order. There are now two possibilities: First possibility: The client of the service needs to do a http GET request after receiving the notification, the second is, to pass the entire service order with its subresources inside the notificaiton. I personally would very much prefer the first possibility, because it would bloat my notificaitons with content. How are your opinions on this? Or are there any "specifications", which a client could give during the registering to a notificaiton to specifiy exactly, which part of the service order resource it needs to have in the notificaiton?

    Thanks in advance

    Adrian

    ------------------------------
    Adrian Ofterdinger
    Capgemini
    ------------------------------


  • 2.  RE: TMF641: Service Ordering API: Notification: Content and Registering

    TM Forum Member
    Posted Jul 09, 2018 02:16
    Hi Adrian,

    1. Look at TMF630 chapter "Content type filtering" - "query":"eventType = TroubleTicketStateChangeNotification & event.troubletTicket.severity=Urgent" you can also specify event.troubletTicket.state='complete'

    2. I'm also prefer to have event as simple as possible. Subscriber should collect necessary data by himself using your API. Also during subscription, client can specify which fields he need (but it can be difficult to handle in case several subscribers)

    ------------------------------
    Sergey N Lukin

    ------------------------------



  • 3.  RE: TMF641: Service Ordering API: Notification: Content and Registering
    Best Answer

    TM Forum Member
    Posted Jul 09, 2018 02:36
    Hi Adrian

    As per current design guidelines, it is possible to register an event listener for only a subset of the message content. The guideline gives an example of setting up a selective listener for trouble ticket state changes, for only urgent tickets, as follows:

    POST /api/hub/

    Accept: application/json

     {

    "callback": http://in.listener.com,

     "query":"eventType = TroubleTicketStateChangeNotification & event.troubletTicket.severity=Urgent",

    "fields":"event.troubleTicket.id, event.TroubleTicket.name, event.troubleTicket.severity"

    }

    Regarding the message content, look in the specification document for each API to see which parts of the resource are published. From memory, I would say that the current trend is that the entire resource is published into the message. There is no mechanism for a message consumer to request a specific format from the message producer.
    Your point makes sense for a point-to-point communication, but perhaps in that case you should consider creating a new message format specifically for this use case.



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 4.  RE: TMF641: Service Ordering API: Notification: Content and Registering

    Posted Jul 10, 2018 00:23

    Hi Adrian

    Firstly it's good to remember that TMForum is a framework and you can pick and choose the solution that best fits your service requirements (within the confines of your service specification).

    From some of the implementations that I have seen in previous lives - the State Change Notifications can be configured based on recipients (end customer) needs, provided your orchestration engine can support this flexibility (on a per company/user - to switch on/off specific notification types). 

    Some recipients like more notifications and others less and its a personal choice in many cases (normally to avoid being spammed by unnecessary information overload).

    With regards to only providing selective characteristic/values with the service state notification - In effect if you comply with TMForum you should include  the service specification and all its characteristic/values.

    A GET may be a good option, but the same issue exist as mentioned above, however you may want to see if using customized filters can be applied in your GET request, but this is not  specified in the TMForum specs. the issue with this will be where in your GET structure would you would specify the filter (Service Order or Service Order Item?).

    Not sure if this helps with your query.

    Good luck.

     

    Pete



    ------------------------------
    Pete Bains
    ------------------------------