Introduction

Kafka est le fournisseur de messages standard de Railnova pour les flux de données de serveur à serveur et Railnova offre une API générique de flux Kafka à tous les clients d'entreprise dans les conditions suivantes.

Pourquoi Kafka ?

Par rapport à la plupart des systèmes de messagerie tels que AMQP et MQTT, Kafka a un meilleur débit, un partitionnement intégré, une réplication et une tolérance aux pannes, ce qui en fait une bonne solution pour les applications de traitement de messages à grande échelle et à haute disponibilité. Par le passé, nous avons été confrontés à des problèmes de performance avec MQTT et AMQP (dans un contexte de serveur à serveur) et à un manque de redondance avec les architectures MQTT et AMQP à un seul nœud.

Une autre caractéristique essentielle de Kafka est qu'il permet de conserver les messages, ce qui permet au consommateur de les extraire à la demande (pendant la période de conservation) et de les extraire plusieurs fois, en cas de panne du système ou à des fins de rediffusion.

Kafka est un protocole open-source qui ne dépend pas d'un fournisseur de cloud spécifique. Les messages Kafka peuvent être consommés très facilement depuis Azure Event Hubs, AWS Kinesis ou GCP dataflow. Vous pouvez également héberger un service Kafka directement dans votre environnement cloud Confluent ou chez le fournisseur de services Aiven. Vous pouvez consulter la documentation Kafka ici et voir les clients Kafka dans votre langage de programmation préféré ici.

Prix de l'API générique de streaming Kafka

Le prix du service Generic Kafka Streaming API dépend du volume de données et des ressources serveur consommées. Veuillez contacter notre équipe commerciale pour obtenir un devis sur l'API générique de flux Kafka pour les données de votre flotte.

Si vous souhaitez des conditions de service différentes des conditions génériques, nous proposons également des API personnalisées avec des accords de niveau de service et des plans d'intégration personnalisés, sous réserve d'un accord commercial spécifique. Veuillez contacter notre équipe commerciale pour toute question relative aux conditions des API personnalisées.

Informations sur le fournisseur et connexion

Notre fournisseur Kafka est accessible à tous les clients de Railnova Enterprise depuis l'internet public et l'authentification se fait en utilisant le protocole SASL. Nous fournissons un environnement de test parallèlement à l'environnement de production. L'hôte et le mot de passe sont fournis sur demande. Veuillez contacter support@railnova.eu pour plus d'informations.

	Environnement de test	Environnement de production
Host du fournisseur	Sera envoyé séparément	Sera envoyé séparément
Utilisateur (pour SASL)	Nom de votre entreprise	Nom de votre entreprise
Mot de passe (pour SASL)	Sera envoyé séparément	Sera envoyé séparément
Host du registre de schémas	Sera envoyé séparément	Sera envoyé séparément
Protocole d'authentification	SASL SCRAM ou SASL Plain	SASL SCRAM ou SASL Plain
Nom du sujet	output-sharing-username	output-sharing-username
Rétention des données sur le service Kafka générique	24 heures par défaut	24 heures par défaut

Le certificat CA (nécessaire pour l'authentification SASL) sera également envoyé séparément.

Les données seront disponibles dans un seul sujet, divisé par numéro de matériel roulant (locomotive ou rame). Les données doivent être consommées par un seul groupe de consommateurs à la fois.

Format du message et schéma

Les schémas peuvent être récupérés dans notre registre de schémas directement en utilisant le même utilisateur et le même mot de passe que pour le fournisseur ou peuvent également être envoyés sur demande.

Les messages sont encodés avec Avro et compressés avec zstd.

compression.codec	zstd
Avro schema namespace	eu.railnova.supernova.analyst
Avro key schema name	AnalystKey
Avro value schema name	AnalystValue

Enveloppe du message

L'enveloppe du message est définie par le schéma AnalystValue et voici le nom et la description de sa clé de premier niveau.

Nom de clé	Type de valeur	Description
type	string	Type de message (telematic, fault-code, …)
timestamp	string	Date-heure codée selon la norme ISO 8601 dans le fuseau horaire UTC/Zulu
asset	integer	Identifiant du matériel roulant dans Railnova
asset_uic	string	UIC du matériel roulant, comme défini dans l'admin Railnova
device	integer	Identifiant de la balise dans Railnova (peut être nul si les données ne proviennent pas d'un Railster)
is_open	bool	Utilisé pour l'état des codes défaut et des alertes
content	string	La partie principale du message. Dans le format interne de Railnova. Elle est encodée en JSON. Il est décrit ci-dessous.

Le mappage du matériel roulant et de l'asset_uic avec le nom du véhicule et les données supplémentaires peuvent être trouvés par le biais de notre API sur le point de sortie du matériel roulant.

Le champ content

Le contenu clé contient un objet codé en JSON qui constitue le champ du message, spécifique à chaque type de message.

Ce contenu à l'intérieur d'un champ content peut changer à l'avenir car il dépend des données entrantes provenant d'appareils IoT configurables tels que le Railster ou de données de tiers. Aucune garantie de continuité du schéma du champ content n'est donnée dans le cadre de cette API générique de flux Kafka.

Le contenu peut être exploré via la page "Données télématiques" à l'adresse https://one.railnova.eu/telematics/#/.

À titre d'exemple, voici le contenu que vous pouvez typiquement attendre d'un message de type "position":

{
       "gps_time": "2020-06-15 00:00:07",
       "fix": 1,
       "longitude": 5021011,
       "course": 310,
       "location": "Bièvre",
       "period_km": 1.165,
       "latitude": 49946116,
       "speed": 101
   }

Voici un autre exemple de message provenant du moteur de règles intégré au Railster :

{
     "ZSG_Catenary_Voltage": 1.6,
     "ZSG_IW_HB_Druck": 8.6,
     "ZSG_IW_HLDruck": 4.92,
     "ZSG_IW_IFahrSumme_scaled_A": 21.90234375,
     "ZSG_IW_IFahrdr_1_scaled_A": 0,
     "ZSG_IW_IFahrdr_scaled_A": 22.90234375,
     "ZSG_IW_Weg": 31019,
     "ZSG_IW_ZBK_Gesamt": 0,
     "ZSG_IW_ZBK_eigene_Lok": 0,
     "ZSG_IW_Zugnummer": 953,
      … a hundred more symbols
}

Voici un exemple d'alerte provenant du moteur de règles intégré au Railster :

{
     "name": "Tueren auf Seite Rechts wurden Freigegeben bei Befehl Freigabe links",
}

Politique de dépréciation dans le cadre de l'API générique de flux Kafka

Dans le cadre de ces conditions de l'API générique de flux Kafka, nous voulons nous assurer que nos clients sont informés et ont le temps de mettre à jour leurs systèmes avant tout changement important, tout en permettant des flux de travail normaux pour le développement de fonctionnalités et de produits chez Railnova.

Une nouvelle version d'une fonctionnalité peut rendre obsolètes certaines fonctionnalités des versions précédentes ("breaking change"). Lorsque nous publions des changements majeurs, nous vous en informons avant la date de leur mise en place et nous assurons la compatibilité ascendante pendant 6 mois.

Les modifications considérées comme des "ruptures" dans le cadre de l'API Kafka générique sont les suivantes:

la modification ou la suppression de champs existants de la structure de l'enveloppe (schéma AnalystValue),

suppression d'un type de message préexistant

Exemple de code

Nous fournissons un exemple de code en python qui vous permettra de récupérer votre premier message sur notre Kafka après avoir suivi le README.md sur GitHub.

Support

Vous avez encore des questions ? Rendez-vous sur la plateforme Railnova et cliquez sur "Nous contacter" pour obtenir de l'aide !