Open APIs

Hi Folks

I am currently working on implementing a solution for handling asynchronous notifications for ServiceOrder resources, and was going through the TMG guidelines laid out in TMF630 Part 1. I've got a question that I would like to clarify or learn from anyone who has implemented similar solution in their organization.
Does the listener need to subscribe on a per resource basis or specifically for every instance of a resource that its interested in? For ex. If I have a ServiceOrderA and ServiceOrderB resources, both inheriting their properties from the parent resource class ServiceOrder, then can I just subscribe for ServiceOrder resource, and I will be notified of all the events happening on ServiceOrderA & ServiceOrderB sub-resources, or do I need to subscribe for them individually?

Appreciate your thoughts.

Kind Regards

------------------------------
Vishal Thakur
BT Group plc
------------------------------

Hi Vishal

See CH10 in  TMF630 REST API Design Guidelines Part 1. It describes that a listener can subscribe using content based filtering too.
Hope this helps!

------------------------------
Srikanth Minnam
Qvantel Oy
------------------------------

Thanks Srikanth
Open API team members might want to give their perspective here, especially as we are on the cusp of publishing the updated guidelines document set TMF630. @Ludovic Robert and @Alexis De Peufeilhoux what do you think?
​​

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------

Original Message:
Sent: May 22, 2020 10:27
From: Srikanth Minnam
Subject: Async Message handling

Hi Vishal

See CH10 in  TMF630 REST API Design Guidelines Part 1. It describes that a listener can subscribe using content based filtering too.
Hope this helps!

------------------------------
Srikanth Minnam
Qvantel Oy
------------------------------

Hello Vishal

In fact...both UC can be managed. See examples based on Trouble Ticket but logic is the same.

If you POST a Hub with following:

POST {api_url}/HUB
Accept: application/json

{"callback": http://in.listener.com,
"query":"eventType = TicketStateChangeNotification"
}
​

You'll received notification for all trouble ticket when TT state change.

If you do:

Accept: application/json

{"callback": http://in.listener.com,
"query":"eventType = TroubleTicketStateChangeNotification"&troubleTicket.id=452-45k
}
​

You're subscribing only to TT state change for TT #452-45k.

In my experience the first case is more often use... subscribing for one instance is for very specific UC (never saw implemented on my experience).

But restricting the query is nevertheless vey useful:

Accept: application/json

{"callback": http://in.listener.com,
"query":"eventType = TroubleTicketStateChangeNotification"&troubleTicket.Status=COMPLETED
}

Here I just want to receive notification when TT are completed.

hope it helps,

Ludovic
​

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------

@Jonathan Goldberg @Ludovic Robert @Srikanth Minnam,, thank you Folks. This was very helpful.​​​

While awaiting answers on this one, I was doing some self reading and came across a few things which raised a few doubts. I've tried to jot down my queries below:

1. TMF 630, part 1 mentions "Subsequent POST calls may be rejected by the service if it does not support multiple listeners". Does this mean that some services would support multiple listeners, while some won't?  If yes, is there a list of which services do support multiple listeners, and which ones don't?

2. As @Jonathan Goldberg mentioned about the updates specs coming out soon, it got me wondering if there would be a major change in the framework for notifications? i.e, would we be moving to a more industry standard framework for async messaging like Kafka or AMQP? Or is it just some fine grained enhancements to the same framework.

Again, Thanks for your contributions to the community, and I am every so grateful for your support.

Kind Regards
Vishal
​​​

------------------------------
Vishal Thakur
BT Group plc
------------------------------

Original Message:
Sent: May 25, 2020 03:41
From: Ludovic Robert
Subject: Async Message handling

Hello Vishal

In fact...both UC can be managed. See examples based on Trouble Ticket but logic is the same.

If you POST a Hub with following:

POST {api_url}/HUBAccept: application/json{"callback": http://in.listener.com,"query":"eventType = TicketStateChangeNotification"}​

You'll received notification for all trouble ticket when TT state change.

If you do:

Accept: application/json{"callback": http://in.listener.com,"query":"eventType = TroubleTicketStateChangeNotification"&troubleTicket.id=452-45k}​

You're subscribing only to TT state change for TT #452-45k.

In my experience the first case is more often use... subscribing for one instance is for very specific UC (never saw implemented on my experience).

But restricting the query is nevertheless vey useful:

Accept: application/json{"callback": http://in.listener.com,"query":"eventType = TroubleTicketStateChangeNotification"&troubleTicket.Status=COMPLETED}

Here I just want to receive notification when TT are completed.

hope it helps,

Ludovic
​

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------