Le composant SignalR utilise WebSocket comme transport pour se connecter à un serveur SignalR ; si ce transport n'est pas pris en charge, une erreur sera levée.
Le composant client SignalR possède une propriété appelée SignalR où vous pouvez définir les données suivantes :
Le client prend en charge l'envoi de données texte ou binaires.
L'API Hubs permet d'appeler des méthodes du serveur depuis le client et des méthodes du client depuis le serveur. Le protocole utilisé pour la connexion persistante n'est pas suffisamment riche pour permettre d'exprimer la sémantique RPC (appel de procédure distante). Cela ne signifie pas pour autant que le protocole utilisé pour les connexions hub est complètement différent du protocole utilisé pour les connexions persistantes. Au contraire, le protocole utilisé pour les connexions hub est principalement une extension du protocole pour les connexions persistantes.
Lorsqu'un client invoque une méthode serveur, il n'envoie plus une chaîne de flux libre comme c'était le cas pour les connexions persistantes. À la place, il envoie une chaîne JSON contenant toutes les informations nécessaires pour invoquer la méthode. Voici un exemple de message qu'un client enverrait pour invoquer une méthode serveur :
WriteData('{"H":"chathub","M":"Send","A":["Delphi Client","Test message"],"I":0}');
La charge utile possède les propriétés suivantes :
I – identifiant d'invocation – vous permet de faire correspondre les réponses aux requêtes
H – le nom du hub
M – le nom de la méthode
A – arguments (un tableau, peut être vide si la méthode n'a aucun paramètre)
Si l'argument chaîne contient des guillemets doubles, remplacez " par \"
Exemple : si l'argument est {"test":1}, envoyez l'argument sous la forme {\"test\":1}
WriteData('{"H":"chathub","M":"Send","A":["{\"test\":1}"],"I":0}');
L'authentification peut être activée pour associer un utilisateur à chaque connexion et filtrer les utilisateurs pouvant accéder aux ressources. L'authentification est implémentée à l'aide de Bearer Tokens : le client fournit un jeton d'accès et le serveur valide ce jeton et l'utilise pour identifier l'utilisateur.
Actuellement, seuls les tokens Bearer sont pris en charge :
Ici, vous passez le jeton directement au serveur Signal (car le jeton a été obtenu depuis un autre serveur).
Authentication.Enabled : si actif, une autorisation sera utilisée avant l'établissement d'une connexion WebSocket.
Authentication.Authentication : 2 types d'authentification sont pris en charge : jeton bearer ou cookies. Les deux nécessitent une méthode externe pour obtenir les valeurs requises.
BearerToken : valeur du jeton obtenu.
Cookie : définir la valeur du cookie requis.
oSignalR := TsgcWSAPI_Signal.Create(nil);
oSignalR.SignalR.Enabled := True;
oSignalR.SignalR.Authentication := srcBearerToken;
oSignalR.SignalR.BearerToken.Token := 'token here';
Le composant possède les événements suivants :
Cet événement est déclenché lorsque le client se connecte avec succès au serveur.
Cet événement est déclenché lorsque le client est déconnecté du serveur.
Cet événement est appelé en cas d'erreur dans la connexion WebSocket.
Le protocole utilisé pour la connexion persistante est assez simple. Les messages envoyés au serveur sont simplement des chaînes brutes. Il n'y a pas de format spécifique imposé. Les messages envoyés au client sont plus structurés. Les propriétés que vous pouvez trouver dans le message sont les suivantes :
C – identifiant de message, présent pour tous les messages non-KeepAlive
M – un tableau contenant les données réelles.
{"C":"d-9B7A6976-B,2|C,2","M":["Welcome!"]}
Cet événement est appelé lorsque des données binaires sont reçues depuis le serveur.
Lorsqu'une méthode serveur est invoquée, le serveur retourne une confirmation que l'invocation est terminée en envoyant l'identifiant d'invocation au client et — si la méthode a retourné une valeur — la valeur de retour, ou — si l'invocation de la méthode a échoué — l'erreur.
Voici des exemples de résultats d'un appel de méthode serveur :
{"I":"0"}
Une méthode void serveur dont l'identifiant d'invocation était « 0 » s'est terminée avec succès.
{"I":"0", "R":42}
Une méthode serveur retournant un nombre dont l'identifiant d'invocation était "0" s'est terminée avec succès et a retourné la valeur 42.
{"I":"0", "E":"Error occurred"}
Cet événement est déclenché lorsqu'un message KeepAlive est reçu du serveur.