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
------------------------------
Original Message:
Sent: Jul 07, 2018 15:12
From: Adrian Ofterdinger
Subject: TMF641: Service Ordering API: Notification: Content and Registering
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
------------------------------