Open APIs

 View Only
  • 1.  TMF620 basics: notification event types

    Posted Feb 01, 2022 15:43

    Hi,

    I'm exploring the TMF620 API v4.1.0 and have a few questions I would like to ask. In the Swagger API definition there is a part that is tagged with "notification listeners (client side)" with paths that start with "/listener/...". I'm assuming the server-side of this part of API has to be implemented by the clients of the TMF620 API and is meant to be a "sink" for events emitted by the TMF 620 service. There are several different events that can be posted for each "entity". For example, for ProductOffering there are the following events:

    ProductOfferingCreateEvent​
    ProductOfferingAttributeValueChangeEvent
    ProductOfferingStateChangeEvent
    ProductOfferingDeleteEvent

    Those events don't differ in structure much (if at all). So I'm asking about the meaning of the different events if each of them may carry the same payload - the  ProductOffering. I can imagine the meaning of ProductOfferingCreateEvent​ and ProductOfferingDeleteEvent, but what is the difference between ProductOfferingAttributeValueChangeEvent and ProductOfferingStateChangeEvent ? Are there any constraints about what one can or can't change vs. the other? Any recommendations?

    Thanks,

    Peter



    ------------------------------
    Peter Levart
    Marand Software
    ------------------------------


  • 2.  RE: TMF620 basics: notification event types

    Posted Feb 02, 2022 03:38
    Hello Peter,
    Yes you're right about the implementation of the server on the listener side.

    About the events themselves it is true that they are generic (the entity is passed). The subscriber can pick only a subset of the attributes when it subscribes via the HUB (specifying the expected attributes).

    We are working on this event topic for the next release. 
    For example we will leverage the json-patch grammar in the informationRequired event.

    To give you an couple of examples on the Quote API (but the pattern will be the same)

    Information required example:
    {
      "correlationId": "qs1-k33",
      "description": "QuoteInformationRequiredEvent illustration",
      "domain": "Commercial",
      "eventId": "966",
      "eventTime": "2021-09-27T07:43:59.059Z",
      "eventType": "QuoteInformationRequiredEvent",
      "priority": "1",
      "timeOcurred": "2021-09-27T07:43:59.059Z",
      "title": "QuoteInformationRequiredEvent",
      "event": {
        "quote": {
          "id": "5252",
          "href": "https://host:port/quoteManagement/v4/quote/5252",
          "@type": "EntityRef",
          "@referredtype": "Quote"
        },
        "informationRequired": {
          "informationRequiredPath": [
            {
              "op": "add",
              "path": "agreement.id"
            },
            {
              "op": "add",
              "path": "contactMedium"
            }
          ]
        }
      },
      "@baseType": "Event",
      "@type": "QuoteInformationRequiredEvent"
    }​


    State change example:

    {
      "correlationId": "333-fd6",
      "description": "QuoteStateChangeEvent illustration",
      "domain": "Commercial",
      "eventId": "569",
      "eventTime": "2021-09-27T07:43:59.059Z",
      "eventType": "QuoteStateChangeEvent",
      "priority": "1",
      "timeOcurred": "2021-09-27T07:43:59.059Z",
      "title": "QuoteStateChangeEvent",
      "event": {
        "quote": {
          "id": "9693",
          "href": "https://host:port/quoteManagement/v4/quote/9693",
          "@type": "Quote",
          "state": "approved",
          "itemStateChange": [
            {
              "itemId": "1",
              "state": "approved"
            },
            {
              "itemId": "2",
              "state": "approved"
            }
          ]
        }
      },
      "@baseType": "Event",
      "@type": "QuoteStateChangeEvent"
    }
    ​

    Hope it helps,
    Ludovic



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



  • 3.  RE: TMF620 basics: notification event types

    Posted Feb 02, 2022 05:49

    Hello Robert,

    Thank you for your reply. So basically you are saying that as events currently stand, they are open to whichever interpretation one desires and that in the future the specifications will change that. I was hoping to get some hints about the differences between say ProductOfferingAttributeValueChangeEvent and ProductOfferingStateChangeEvent in TMF620 API as that is what we are currently trying to implement. The names of the event types are all there is in the spec. Nothing more. And those two names don't say much to differentiate between.

    ProductOfferingAttributeValueChangeEvent hints into changes to the attributes of the ProductOffering. But what are the attributes? Just scalar values at the leafs of the ProductOffering structure? Only on the 1st level or also further down? Are references to other "entities" like ProductOfferingPriceRef also attributes?

    OTOH, ProductOfferingStateChangeEvent hints into changes made to "state" of the ProductOffering. But aren't attributes what state is made of? So where's the catch? What was the meaning behind those two names?

    Regards,

    Peter

    ​​

    ------------------------------
    Peter Levart
    Marand Software
    ------------------------------



  • 4.  RE: TMF620 basics: notification event types

    Posted Feb 02, 2022 07:25
    Peter,

    For me, potentially the ProductOfferingAttributeValueChangeEvent should be triggered for any attribute change (at any level) for a ProductOfferingResource - except probably state attribute where in this case the ProductOrderState event is send (more a feeling than a rule but I'm not comfortable to have 2 event triggered for one modification of state).

    You're free in your implem to restrict the scope but is has to be know from your customer.

    Theoretically, during event subscription you could also restrict the event scope. If I do the following, I subscribe only to TT state change to Completed (not all state change) and I want only 2 attributes in the event TT strcuture (id & external.id):

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

    I'm stuck on one point: I do not know how to specify a subset of attribute to monitor for attributeValueChange.

    Ludovic





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



  • 5.  RE: TMF620 basics: notification event types

    Posted Feb 09, 2023 07:14

    Hello,

    My two cents regarding:

    • ProductOfferingCreateEvent​
    • ProductOfferingAttributeValueChangeEvent

    Q: "Those events don't differ in structure much (if at all)"

    A: Not much. In the second one the structure should support the consumer to know: a) what attributes were changed and b) what information entities were added, deleted or modified. This is not mandantory but it will save you the effort of having multiple consumers comparing huge payloads to check what is changing.

    For the other two:

    • ProductOfferingStateChangeEvent - Because the ProductOfferingAttributeValueChangeEvent can be quite complex and because some listeners may only be interested in the baisc info (PO ID, PO Description, Status) I find it usefull and wise to be defined as a separate event.
    • ProductOfferingDeleteEvent - Also seems usefull as a separate event. Probablly ID's are enough in the event body.


    ------------------------------
    Gonçalo Furtado
    Celfocus
    ------------------------------