Hi Kalpana
The event structure defines the contents of the event from the point of view of the event provider (typically this will be the same software module implementing the API that specified the event).
It seems to me very unlikely that the event will be read as-is to a human customer. Humans can read JSON, but I suspect that your average Jane Doe will say Huh? to a JSON document even if all the "technical" fields were suppressed. Surely you will have some sort of software (middleware) that will translate the raw event contents into some friendly human-readable form, and this would also remove the non-needed elements.
Hope it helps
------------------------------
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: Oct 27, 2020 11:14
From: Kalpana HV
Subject: Event Notification Structure
Hi All,
We are implementing a TMF Open API (TMF655). In the first release, only notification operation to be implemented. As per API specification, the notification should have below payload and hence will contain entire resource payload.
{"eventId": "00005",
"eventTime": "2016-03-02T16:42:25",
"eventType": " ChangeRequestAttributeValueChangeNotificationNotification",
"event": {
"ChangeRequest": {-- SEE ChangeRequest RESOURCE SAMPLE --}
}
}
In our case, as the notifications are being sent to customers we want to suppress some of the mandatory elements is API data model like specification, targetEntity etc. Is this acceptable?
Thanks,
------------------------------
Kalpana HV
Colt Technology Services
------------------------------