Open APIs

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

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

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.

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.

Interesting discussion about event storage 

Not sure if we have a complete solution to the event storage requirement but a couple of possible starting points:

• In the Modern Data architecture there is a proposal for a Self Service Data Platform SSDP (swisscom) which follows data mesh concepts ( Data Mesh Principles and Logical Architecture (martinfowler.com) of democratization of data with many consumers and producers but this is more about Data discovery and movement for events, streaming etc. see IG1356 Whitepaper on Data Architecture for AI-enabled Telecom Operations v1.0.0 - Modern Data Architecture - TM Forum Confluence
• We have developed a TMF686 topology Graph API  and  Topology Discovery Services in TMF920A that address requirements in TR283 Business Requirements for a Multi-layer Topology Discovery Service v1.0.0
  This work and the SSDP assume that the data is persisted in existing inventories(including those with state). The model is to discover where the information is ( current discussion is around use of rdf based ontologies, also used in IoT) and represent as a  Knowledge graph / digital twin, and then move only the data required to perform graph queries asn get events, streaming from the graph discovered during the discovery phase. TMF686 predates TM688 But the ODA production team has identified a possibility of integrating TMF688 into TMF920A to support events and streaming . But this is just a candidate proposal but if there are more members interested maybe we could start such work.