Open APIs

 View Only
  • 1.  TMF 641 - Notification listener (client side) APIs

    Posted Apr 20, 2022 09:35

    I am pretty new with the APIs.

    While implementing notification listener (client side) APIs I have observed that 201 response payload always have a "callback" attribute.

    I am just curious to know what is the purpose of this "callback" ?

    From the swagger I could see it mentions, callback is to register, what kind of this registration is ?

    EventSubscription {

    description:

    Sets the communication endpoint address the service instance must use to deliver notification information

    id*

    string

    Id of the listener

    callback*

    string

    The callback being registered.

    query

    string

    additional data to be passed

    }



    ------------------------------
    Shabad Mathur
    Zensar Technologies
    ------------------------------


  • 2.  RE: TMF 641 - Notification listener (client side) APIs

    TM Forum Member
    Posted Apr 21, 2022 01:30
    Edited by G B Aswath Apr 21, 2022 01:33
    The callback is a URL of client which is used by server / sender to push notifications to its registered consumers / clients. TMF 641 supports following notifications

    • OrderCreationNotification
    • OrderRemoveNotification
    • OrderStateChangeNotification
    • OrderValueChangeNotification
    • OrderInformationRequiredNotification

    Consumer /Client can registered for any / all of the above notifications which can be supplied in query parameter along with URL to which server should post this notifications should be given in callback during above event registration process.

    ------------------------------
    G B Aswath
    NMSWorks Software Pvt. Ltd.
    ------------------------------



  • 3.  RE: TMF 641 - Notification listener (client side) APIs

    TM Forum Member
    Posted Apr 24, 2022 07:08
    Hi all
    Please note that the hub pattern is entrenched in (almost) all the TMF Open APIs, and is described in the Design Guidelines TMF630.
    The hub pattern allows consumers of API operations to register to receive events that occur as a result of operation invocation, for example entity created, entity deleted, state changed, etc., as in the TMF641 example quoted above by GB Aswath.
    The hub pattern is inherently point-to-point. An alternative is to use true eventing, abstracted by the Event Management API TMF688.

    ------------------------------
    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.
    ------------------------------



  • 4.  RE: TMF 641 - Notification listener (client side) APIs

    Posted Apr 30, 2022 23:28
    Thanks a lot Jonathan & GB Aswath for your reply.
    However, I have one more related query:

    Inside all the skeleton codebase for listener APIs provided in "NotificationListenerClientSideService.js", I observe following two consecutive statements are prominent in all methods :

    1. sendDoc(res, 201, payload);
    2. notificationUtils.publish(req,payload);

    Inside publish (req, payload) method following methods are called :

    1. createEventMessage(resourceType, method, doc, old);
    2. notify(db, clients, message);

    And inside notify(db, clients, message); method, processMessage(db, client, message) is called.

    Could you please help me in understanding the significance of calling notificationUtils.publish() method just after calling sendDoc() method ?



    ------------------------------
    Shabad Mathur
    Zensar Technologies
    ------------------------------



  • 5.  RE: TMF 641 - Notification listener (client side) APIs

    TM Forum Member
    Posted May 01, 2022 08:22
    Hi
    It looks like this is code in the reference implementation (RI) of the API. I'm afraid I have no idea what the business logic in TMF Open APIs RI is. Perhaps @Victor Mari can assist.​

    ------------------------------
    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.
    ------------------------------



  • 6.  RE: TMF 641 - Notification listener (client side) APIs

    TM Forum Member
    Posted May 01, 2022 13:11
    Hi @Shabad Mathur,

    In short, the purpose of the sendDoc​ function is to clean up the payload and return it on the Http response. The payload also gets published to the hub so it can be queried on the other Hub endpoints.

    Calling the methods in that order is purely technical since the sendDoc mutates the object and the publish method will use the same object as it was returned on the request.

    Let me know if you have more questions.

    ------------------------------
    Victor Rodriguez
    TM Forum
    ------------------------------



  • 7.  RE: TMF 641 - Notification listener (client side) APIs

    TM Forum Member
    Posted Aug 24, 2022 08:03
    Hey @Jonathan Goldberg,

    I've just refreshed myself on TMF630 and the hub/listener model and i still have a similar query to Shabad had in the first instance.

    The model that is defined to respond to a POST /api/hub as below make sense as its telling the API client "this is the hub i have created for you and i confirm this is the URL you have supplied for me".

            "EventSubscription": {
                "type": "object",
                "description": "Sets the communication endpoint address the service instance must use to deliver notification information",
                "required": [
                    "id",
                    "callback"
                ],
                "properties": {
                    "id": {
                        "type": "string",
                        "description": "Id of the listener"
                    },
                    "callback": {
                        "type": "string",
                        "description": "The callback being registered."
                    },
                    "query": {
                        "type": "string",
                        "description": "additional data to be passed"
                    }
                }
            }
    ​However when a look at the listener endpoints that are defined in the swagger for 641 (v4.1.0) then i see that they also suggest that in the success scenario (201) that they should return the EventSubscription model.

    This doesnt make any sense to me as these are endpoints implemented by the client and i dont know why the client would be returning back to the server the unique id of its callback address that has been generated by the server. unfortunately the version of TMF630 (4.2.0) that aligns with 641 v4.1.0 stops short of actually showing an example of the response from the client to the server in section 10.3. I feel like this is a bug in the TMF641 schema and the client should probably not be asked to return any body content at all.

    Am i misunderstanding here or do you think this is a schema issue?

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 8.  RE: TMF 641 - Notification listener (client side) APIs

    TM Forum Member
    Posted 14 days ago
    Hey @Jonathan Goldberg or @Ludovic Robert, or anyone else on the team, could you possibly  help with the above query?​​

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 9.  RE: TMF 641 - Notification listener (client side) APIs

    TM Forum Member
    Posted 13 days ago
    Hi,

    Yes. This could be a bug. I guess, they intend to return response code 2xx as a token of notification acknowledgement but they have reused/copied entire response of event subscription in all event listener response.

    ------------------------------
    G B Aswath
    NMSWorks Software Pvt. Ltd.
    ------------------------------