Introduction to Datafeed and the Datafeed versions
Datafeed is a service that transmits encrypted messages that come from the endusers to the bot (e.g. service account). The datafeed provides messages and events from all conversations that the user is in. The types of events surfaced in the datafeed can be found in the Real Time Events list.
Currently you should be using Datafeed 1.0 (as it is the default version). So all real-time messages, alerts, etc are delivered to the users via an SSE (Server Sent Event) protocol. This requires Symphony’s backend to constantly send heartbeats to each client application to maintain connectivity, where the stability of every user’s Datafeed connection depends on the resilience of the pod itself.
With Datafeed 2.0, we are migrating the real-time event delivery infrastructure to a long polling protocol for users to retrieve events. This switch alleviates the responsibility of Symphony’s backend to maintain connectivity, while also improving the stability of the service overall by moving to a highly-resilient and modular infrastructure.
This improvement will not only ensure that maintaining connectivity is easier from both a client and server perspective, but also that the service is more reliable and performant for users as well.
Activation of Datafeed 2.0 is not linked to SBE version
Contact your Symphony administrator to know if Datafeed 2.0 is activated on your pod and for more details.
Implementation in the Agent and impacts on your bots
In order to benefit from this improvement for your bots, we have implemented the endpoints to use new Datafeed 2.0 in the Agent service and are supporting it in our Java and Python SDKs (NodeJS and .NET to come soon).
The mapping is the following:
-
Datafeed 1.0 is accessible via the path /agent/v4/datafeed
- Via a POST on the endpoint /agent/v4/datafeed/create, the datafeed is created and then the ID is persisted in a file, which is by default datafeed.id on the bot side
- The bot subscribes to this ID to retrieve datafeed events; if it cannot be retrieved by using this ID, a new datafeed is created
- Via a GET on the endpoint /agent/v4/datafeed/{id}/read, the list of events within the specific datafeed identified with {id} is returned
- Deleting a datafeed is not supported
-
Datafeed 2.0 is accessible via the path /agent/v5/datafeeds
- Via a GET on the endpoint /agent/v5/datafeeds, is returned the list of already created IDs for a service account
- Via a POST on the endpoint /agent/v5/datafeeds, the datafeed is created and the ID is not persisted on the bot side → Even if the bot is stale, a GET on the same endpoint will retrieve the ID to which the service account is subscribed
- Via a POST on the endpoint /agent/v5/datafeeds/{id}/read with a parameter ackId (empty string at the first query), the endpoint returns: the list of events, a new ackId string → This ackId permits acknowledgement of the last query and retrieve all events since the last one. All events received between the last payload and the new request are queued and therefore retrieved.
- Via a DELETE on /agent/v5/datafeeds/{id}, the datafeed specified with the {id} is deleted → Deletion is enabled via datafeed 2.0 and not via datafeed 1.0
Datafeed version 2.0 is a new step toward the high availability and resiliency of your bots running on the Symphony platform.
See also
More details on how to do the queries can be found on the description of these endpoints here after:
Datafeed 1.0
Datafeed 2.0
Compatibility between both
It is not possible to create a datafeed id via the v4 path on the agent and read it via the v5 path. The reverse is not possible either.