I recently read through TMF688 Event Management API and TMFC019 Event Management documents. TMF688 seems to be a much older document as compared to TMFC019 which I believe came out of relatively recent catalyst projects.
Looking at TMF688, the Topic resource has the contentQuery and headerQuery fields. To me, the implication of these was that there could be a single central (or "root") Event resource, and that an instance of a Topic is a filtered view of those, however there's no "POST /event" API operation defined in the TMF688 swagger swagger. In any case, it's not relevant anymore because the fields have now been declared in TMFC019 as being "removed because purpose is not clear".
In terms of a long term storage of events, there's a lot written about event streaming and the implications thereof in the Confluent documentation and/or covered in Tim Berglund's presentations. Short answer is that event streaming solutions typically don't store the events long term, but they can form the basis of aggregates, such as in CQRS patterns. Difficulties arise when the event schema changes over time.
------------------------------
Graham Agnew
CSG Systems, Inc.
------------------------------
Original Message:
Sent: Sep 24, 2024 06:26
From: Johan Andersson
Subject: TMF688 and event history
Hi Yurii,
thanks for the links to the explanation and clarification of the purpose of TMF 688.
My conclusion is then that there exists no TMF API for fetching events (related to for example a customer) from a long term event repository like a Data Warehouse.
------------------------------
Johan Andersson
Ericsson Inc.
Original Message:
Sent: Sep 24, 2024 05:22
From: Yurii Yushchak
Subject: TMF688 and event history
Hi Johan,
The community has already had discussions on this topic. I will quote @Thomas Braun here:
The Event API is generic API for Publish/subscribe Event platforms. (e.g. KAFKA,..) with event log capabilities. If you are using that API for a messaging (queing) platform, then the API operation are restricted and the GET operation might be not available, because the messaging platform pushes the message direct to the consumer. @the event is only a short time stored into the queue and can not be consumed by other clients. (no publish/subscribe)
But you can use the Event API model also for messaging systems with some restriction and the missing pub/sub (streaming) benefit.
The topic/event resource storage is implemented by the message queue(s). An additional database for events is not provided.
The full discussions you can find here:
TMF 688 Event API and Event resource in other APIs
TMF 688 logic
------------------------------
Yurii Yushchak
System Manager
Ericsson Inc.
Original Message:
Sent: Sep 23, 2024 09:22
From: Johan Andersson
Subject: TMF688 and event history
Hi,
I was looking into if there is a TMF API that supports retrieval of "Event history".
I mean the history of the events/notifications of a certain type generated by a business support system within a given time frame.
A typical use-case could be to retrieve events, related to a customer, that happened in the current month and present them in a self-service portal.
I found TMF688, but it seems that API is mainly targeting an interface towards a messaging/streaming system.
But that API contains the listEvents() and retrieveEvent() operations that would be a quite good fit for retrieving historical events from a long term event storage such as a Data Warehouse (DW).
In my opinion, applying these operations on a DW would make more sense than applying them on a messaging/streaming system. It would however require having a fixed topic like "root" or "history", because the topics used by a messaging system is most likely not of interest for a DW.
So my question to the community is what is your opinion about using selected parts of TMF688 as in interface to a long term event storage system?
Would that violate the purpose of TMF688?
Also, are there any plans/discussions in TMF for providing another API that can be used to retrieve the events/notifications generated by other TMF APIs?
Best Regards,
Johan Andersson
------------------------------
Johan Andersson
Ericsson Inc.
------------------------------