Comment créer un serveur de messagerie en Low-Code


Dans cet exemple, nous allons implémenter le côté serveur d’une application de messagerie de style client-serveur. Pour ce faire, vous pouvez utiliser votre langage de programmation préféré, mais pour plus de rapidité, nous utiliserons Linx, un outil de développement low-code pour les API backend, les intégrations et l’automatisation.

Pour un aperçu rapide de Linx et de son fonctionnement, consultez cette vidéo.

Portée

Nous allons implémenter quelques méthodes web, qui seront utiles pour créer un client de messagerie. Toutefois, les éléments suivants n’entrent pas dans le cadre de cet exemple:

  • Le client de messagerie. Nous utiliserons Postman pour simuler un client, pour tester nos méthodes Web.
  • La sécurité, qui est un aspect essentiel de tout système réel.
  • Administration des données.
  • Chiffrement.
  • Tests de régression automatisés. Nous le ferons dans un exemple ultérieur.

Conditions préalables

  • Linx 5.18 ou version ultérieure. Télécharger gratuitement ici.
  • Serveur MongoDB 4.0 ou version ultérieure.
  • Postman 7.34 ou version ultérieure.
  • Robo 3T 1.2 ou version ultérieure est recommandé pour travailler avec la base de données.

L’API Web

Pour que notre API Web soit utile, elle doit nous permettre de faire ce qui suit:

  • Ajoutez un utilisateur.
  • Obtenez une liste d’utilisateurs.
  • Envoyez un message à un utilisateur.
  • Obtenez une liste de messages pour un utilisateur.
  • Lisez un message.

Nous ajouterons une méthode pour chacun d’entre eux à notre API Web.

Règles commerciales

Quelques règles aideront la mise en œuvre de notre application de messagerie à avoir plus de sens:

  • Chaque utilisateur sera défini de manière unique par son / elle email adresse. Aucun utilisateur ne peut avoir la même adresse e-mail. Nous appelons cela le clé naturelle pour l’utilisateur. Chaque utilisateur aura également un Clé de substitution dans la base de données. Dans MongoDB, le champ de clé de substitution est un champ spécial nommé _id. Les raisons pour lesquelles il s’agit d’une bonne pratique sortent du cadre de cet échantillon. Si vous ne le savez pas, il peut être utile de le rechercher sur Google à un moment donné.
  • Chaque message est destiné à un et un seul utilisateur. Le message doit donc contenir un champ pour l’identifiant de l’utilisateur associé. Un message a une clé de substitution comme pour un utilisateur, mais il n’y a pas de clé naturelle logique pour un message.

Conventions

  • Nous utiliserons des traits de soulignement dans noms dans Linx, partout où nous voudrions autrement utiliser des espaces parce que Linx ne joue pas bien avec les espaces dans les noms.
  • Les valeurs de propriété de certaines fonctions de Linx peuvent contenir expressions. Dans la zone de saisie de valeur d’une telle propriété, une expression est indiquée par un «=» (signe égal) ajouté au début. Tout au long de cet exemple, des expressions comme celles-ci seront fournies avec le préfixe = inclus, pour faciliter le collage directement dans la zone de saisie de la valeur de propriété. Si une telle expression est insérée dans l’éditeur d’expression, le préfixe = doit être omis.

Créer une solution Linx pour l’application de messagerie

Ouvrez le concepteur Linx et créez un nouveau projet. Nommez la solution Messaging_Appet nommez le projet par défaut Serveur. Supprimer la valeur par défaut Processus du projet Serveur.

Dépendances de l’application de messagerie

Nous aurons besoin des plugins Linx suivants (de la boîte à outils sur la droite) pour implémenter notre serveur de messagerie:

  • DU REPOS, pour le service Web qui hébergera notre API Web.
  • Base de données, pour les outils MongoDB de lecture et d’écriture de données.

Paramètres de l’application de messagerie

Lors de la mise en œuvre de notre application de messagerie, nous ferons référence à plusieurs reprises à des éléments tels que la connexion à la base de données et l’URL de base de notre serveur API Web. De plus, ces valeurs auraient des valeurs différentes dans les différents sandbox de déploiement d’un système réel. Certaines autres propriétés de notre système, par exemple, si notre API Web doit afficher des erreurs de serveur ou non, auraient également des valeurs différentes dans les différents bacs à sable de déploiement d’un système réel. Linx fournit la configuration de la solution Réglages, pour gérer des paramètres comme ceux-ci.

Ajoutez les paramètres suivants:

Nom

Type

Valeur

Database_connection

Chaîne

mongodb: // localhost / Messaging_App

Server_base_URL

Chaîne

http: // localhost: 8095 / messaging_app / api

Show_server_errors

Booléen

Vrai

Notez que la partie de base de votre connexion à la base de données peut différer, selon la configuration de votre environnement. Connectez-vous à votre base de données avec un outil comme Robo 3T pour établir le format correct.

L’URL de base du serveur ci-dessus suppose que le port 8095 est disponible dans votre environnement. Sinon, utilisez un autre port disponible. Cela suppose également que le nom d’hôte localhost est configuré dans votre environnement. Sinon, vous devrez peut-être utiliser une adresse IP à la place. Par exemple 127.0.0.1 pour votre machine locale, ou utilisez la commande ipconfig pour déterminer l’adresse IP de votre réseau local.

Données API Web

Afin de déplacer les données des utilisateurs et des messages dans et hors des méthodes de l’API Web et de la base de données, nous devons définir exactement à quoi ressemblent les données des utilisateurs et des messages. Ajoutez un nouveau dossier au projet Serveur et nommez-le Les données.

Ajoutez un nouveau type personnalisé au dossier Data et nommez-le Utilisateur. Ajoutez les propriétés suivantes au type d’utilisateur:

Nom

Type

_id

Chaîne

Email

Chaîne

Prénom

Chaîne

Nom de famille

Chaîne

Ajoutez un nouveau type personnalisé au dossier Data et nommez-le Message. Ajoutez les propriétés suivantes au type de message:

Nom

Type

_id

Chaîne

Identifiant d’utilisateur

Chaîne

Texte

Chaîne

Expédié

DateHeure

Est lu

Booléen

Définir une API Web dans Linx

Développez le plugin REST dans la boîte à outils Plugin sur la droite. Ajouter un SimpleRESTHost to le projet Serveur et définissez-y les propriétés suivantes:

Propriété

Valeur

Nom

Service Web

URI de base

= $. Settings.Server_base_URL

Afficher les erreurs de serveur

= $. Paramètres.Show_server_errors

Modifier le Web_service Opérations property et ajoutez les opérations suivantes:

Nom

Chemin

Méthode

Demander un corps

Corps de réponse

Add_user

/ add_user

Publier

Server.Data.User

Aucun

Get_users

/ get_users

Avoir

Aucun

liste

Envoyer le message

/envoyer le message

Publier

Serveur.Data.Message

Aucun

Get_messages_for_user

/ get_messages_for_user / {User_ID}

Avoir

Aucun

liste

Lire le message

/ read_message / {Message_ID}

Avoir

Aucun

Serveur.Data.Message

Modifier le Paramètres de chaîne de requête propriété de l’opération Get_messages_for_user et ajoutez le paramètre de chaîne de requête suivant:

sauver le paramètre de chaîne de requête nouvellement ajouté et enregistrez les opérations. Les gestionnaires d’opérations sont ajoutés à Web_service pour chacune des opérations définies, dans l’Explorateur de solutions.

Implémenter la méthode Web Add_User

Pour implémenter Add_user, nous vérifions d’abord si l’adresse e-mail de l’utilisateur spécifié existe déjà dans notre base de données, car nous avons une règle selon laquelle les adresses e-mail en double ne sont pas autorisées. Si tel est le cas, nous renvoyons une erreur pour l’indiquer. Sinon, nous persistons avec l’utilisateur spécifié.

Sélectionnez le gestionnaire Add_user. Ajouter un MongoDBRead de la boîte à outils Plugin au concepteur Add_user et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Retrieve_user_by_email

Chaîne de connexion

= $. Settings.Database_connection

Collection

Utilisateur

Opération

Trouver

Requete

{E-mail: “@ {$. Input.Data.body.Email}”}

Le type de sortie

Server.Data.User

Options de retour

Première ligne, sinon ligne vide

Ajouter un Sinon à partir de la boîte à outils, après Retrieve_user_by_email, et nommez-le If_email_exists. Modifier son Conditions propriété et ajoutez une condition nommée Vrai, avec la valeur:

=Retrieve_user_by_email != $.System.Null

Ajouter un ThrowException de la boîte à outils au chemin True de If_email_exists, et nommez-le Throw_error. Réglez son Message propriété à:

="A user with email address " + $.Input.Data.body.Email + " already exists."

Ajouter un MongoDBWrite après If_email_exists et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Persist_new_user

Chaîne de connexion

= $. Settings.Database_connection

Collection

Utilisateur

Opération

Insérer

Les données

= $. Input.Data.body

Tester la méthode Web Add_User

Testons maintenant Add_user. Lancez Postman et ajoutez une nouvelle collection nommée Application de messagerie. Gérez les environnements, en haut à droite, et ajoutez un environnement, également nommé Application de messagerie. Ajoutez-y une nouvelle variable nommée Server_base_URL, et définissez sa VALEUR INITIALE sur l’URL de base du service Web, dans notre cas http: // localhost: 8095 / messaging_app / api. Puisque le chemin de Add_user est / add_user, nous l’appellerons à {{Server_base_URL}}/add_user.

Ajoutez une demande à la collection d’applications de messagerie, avec les informations suivantes:

Nom

Add_user

Méthode HTTP

PUBLIER

URL

{{Server_base_URL}} / add_user

Format du corps

brut

Type de contenu corporel

JSON

Le corps du texte

{

“Prénom”: “Joe”,

“Nom”: “Bloggs”,

“E-mail”: “joe.bloggs@example.com”

}

Notez que le texte du corps de la requête est une instance de format JSON du type User, que nous définissons comme type de corps de requête dans la définition de notre opération Add_user.

Dans Linx Designer, sélectionnez le Web_service dans l’Explorateur de solutions et DÉBOGUER depuis la barre d’outils. Une fois le débogueur prêt, DÉBUT depuis la barre d’outils. Une fois le service Web démarré, notre API Web écoute à http: // localhost: 8095 / messaging_app / api.

Envoyer la requête Add_user dans Postman. Si la requête aboutit, le code de réponse HTTP doit être 200 OK. Lancez Robo 3T et connectez-vous à votre serveur de base de données. L’utilisateur nouvellement créé doit apparaître dans la collection User de la base de données Messaging_App.

Envoyez à nouveau la demande Add_user. Le code de réponse HTTP doit être 500 Erreur de serveur interne, avec une erreur indiquant que l’adresse e-mail spécifiée existe déjà dans le système. Ajoutez un autre utilisateur avec le corps de requête suivant:

ARRÊTEZ et FERMEZ le débogueur dans Linx Designer.

Implémenter la méthode Web Get_Users

Sélectionnez le gestionnaire Get_users. Ajouter un MongoDBRead au concepteur Get_users et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Retrieve_users

Chaîne de connexion

= $. Settings.Database_connection

Collection

Utilisateur

Opération

Trouver

Le type de sortie

Server.Data.User

Options de retour

Liste des lignes

Ensuite, ajoutez un SetValue à partir des fonctions Linx standard de la barre d’outils Plugin et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Set_response

Cible

= $. Données de sortie

Modifiez la propriété Source et définissez la propriété ResponseBody sur=Retrieve_users.

Tester la méthode Web Get_Users

Dans Postman, ajoutez une autre demande à la collection d’applications de messagerie, avec les informations suivantes:

Nom

Get_users

Méthode HTTP

AVOIR

URL

{{Server_base_URL}} / get_users

Dans Linx Designer, sélectionnez Web_service et redémarrez le débogueur. Envoyer la requête Get_users dans Postman. La liste actuelle des utilisateurs doit être renvoyée au format JSON.

Arrêtez et fermez le débogueur dans Linx Designer.

Implémenter la méthode Web Send_Message

Pour implémenter Send_message, nous vérifions d’abord si l’utilisateur spécifié existe dans notre base de données car nous avons une règle selon laquelle un message doit être destiné à un utilisateur. Sinon, nous renvoyons une erreur pour l’indiquer. Sinon, nous tamponnons le Expédié heure sur le message, puis le persister.

Sélectionnez le gestionnaire Send_message. Ajouter un MongoDBRead au concepteur Send_message et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Retrieve_user_by_ID

Chaîne de connexion

= $. Settings.Database_connection

Collection

Utilisateur

Opération

Trouver

Requete

{_id: ObjectId (“@ {$. Input.Data.body.User_ID}”)}

Le type de sortie

Server.Data.User

Options de retour

Première ligne, sinon ligne vide

Ajouter un Sinon, et nommez-le If_user_found. Modifier son Conditions propriété et ajoutez une condition nommée Faux, avec la valeur: = Retrieve_user_by_ID == $ .System.Null

Ajouter un ThrowException au chemin False de If_user_found, et nommez-le Throw_error. Définissez son Message propriété à: = “Utilisateur avec ID” + $ .Input.Data.body.User_ID + “introuvable.”

Ajoutez une instance du Message type de données de l’Explorateur de solutions, après If_user_found, et définissez les propriétés suivantes:

Propriété

Valeur

Nom

nouveau message

Valeur

= $. Input.Data.body

Ajouter un SetValueet définissez les propriétés suivantes:

Propriété

Valeur

Nom

Set_new_message_sent_time

Cible

= nouveau_message.Sent

La source

= $. System.CurrentDateTime

Ajouter un MongoDBWrite, et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Persist_new_message

Chaîne de connexion

= $. Settings.Database_connection

Collection

Message

Opération

Insérer

Les données

= nouveau_message

Tester la méthode Web Send_Message

Dans Postman, ajoutez une demande avec les informations suivantes:

Nom

Envoyer le message

Méthode HTTP

PUBLIER

URL

{{Server_base_URL}} / send_message

Format du corps

brut

Type de contenu corporel

JSON

Le corps du texte

{

“User_ID”: “5faa6094bc6e2d10a89fcbaf”,

“Texte”: “Bonjour tout le monde.”

}

Comme précédemment, le texte du corps de la requête est une instance de format JSON du type Message, que nous définissons comme type de corps de requête dans la définition de notre opération Send_message.

Dans Linx Designer, sélectionnez Web_service et redémarrez le débogueur.

Envoyer la demande Send_message dans Postman. Cette demande doit échouer avec le code d’état HTTP 500 et une erreur pour indiquer que l’utilisateur avec l’ID spécifié est introuvable. En effet, le User_ID dans l’exemple de corps de demande Send_message, mis en évidence en rouge ci-dessus, provient de ma base de données. Vous devrez changer cela pour utiliser la valeur correcte de votre base de données.

Dans Robo 3T, modifiez le document du premier utilisateur de la collection User. Copiez la valeur du ObjectIdet remplacez User_ID dans le corps de la demande Send_message dans Postman.

Envoyez à nouveau la demande Send_message. Cette fois, le code de réponse HTTP doit être 200 OK. Lancez Robo 3T et connectez-vous à votre serveur de base de données. Le message nouvellement envoyé doit apparaître dans la collection Message.

Envoyez à nouveau la demande Send_message. Cela devrait réussir car il n’y a pas de violation de clé naturelle.

Arrêtez et fermez le débogueur dans Linx Designer.

Implémenter la méthode Web Get_Messages_for_User

Pour implémenter Get_messages_for_user, nous vérifions d’abord qu’une valeur a été fournie pour l’ID utilisateur car il s’agit d’un paramètre obligatoire. Sinon, nous renvoyons une erreur pour l’indiquer. Sinon, nous vérifions si une valeur a été fournie pour le paramètre Is_read, qui est facultatif. Si tel est le cas, nous formaterons un filtre de requête pour le champ Is_read de la collection de messages dans la base de données. Ensuite, nous récupérons les messages par ordre décroissant de temps d’envoi et nous les renvoyons.

Sélectionnez le gestionnaire Get_messages_for_user. Ajouter un Sinon au concepteur Get_messages_for_user et nommez-le If_user_ID_is_empty. Modifiez sa propriété Conditions et ajoutez une condition nommée Vrai, avec la valeur: = $. Input.Data.User_ID == $ .System.Null || $ .Input.Data.User_ID.Trim () == “”

Ajouter un ThrowException au chemin True de If_user_ID_is_empty et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Throw_error

Message

User_ID est requis.

Ajouter un Chaîne variable des plugins Linx standard, après If_user_ID_is_empty, et nommez-la is_read_query_filter. Ajouter un Sinon, et nommez-le If_is_read_parameter_has_value. Modifiez sa propriété Conditions et ajoutez une condition nommée True, avec la valeur:

= $. Input.Data.Is_read! = $ .System.Null && ($ .Input.Data.Is_read.Trim (). ToLower () == “false” || $ .Input.Data.Is_read.Trim () .ToLower () == “vrai”)

Ajouter un SetValue au chemin True de If_is_read_parameter_has_value et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Set_is_read_query_filter

Cible

= is_read_query_filter

La source

= “, ” Is_read “:” + $ .Input.Data.Is_read

Ajouter un MongoDBRead après If_is_read_parameter_has_value et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Retrieve_messages_by_user_ID

Chaîne de connexion

= $. Settings.Database_connection

Collection

Message

Opération

Trouver

Requete

{

User_ID: “@ {$. Input.Data.User_ID}”

@ {is_read_query_filter}

}

Trier

{Envoyé: -1}

Le type de sortie

Serveur.Data.Message

Options de retour

Liste des lignes

Ajouter un SetValue, et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Set_response

Cible

= $. Données de sortie

Modifiez la propriété Source et définissez la propriété ResponseBody sur = Retrieve_messages_by_user_ID

Tester la méthode Web Get_Messages_for_User

Dans Postman, ajoutez une autre demande avec les informations suivantes:

Nom

Get_messages_for_user

Méthode HTTP

AVOIR

URL

{{Server_base_URL}} / get_messages_for_user / 5faa6094bc6e2d10a89fcbaf? Is_read = false

Dans la demande Paramètres de la requête Get_messages_for_user, ajoutez un paramètre avec KEY Est lu et VALUE faux.

Dans Linx Designer, sélectionnez le Web_service et démarrez le débogueur.

Envoyer la requête Get_messages_for_user dans Postman. Cette demande devrait réussir mais ne renverra aucun message. En effet, l’ID utilisateur dans l’exemple d’URL de requête Get_messages_for_user, mis en évidence en rouge ci-dessus, provient de ma base de données. Vous devrez changer cela pour utiliser la valeur correcte de votre base de données.

Dans Robo 3T, modifiez le document de l’utilisateur dans la collection User, auquel nous avons envoyé des messages précédemment. Copiez la valeur du ObjectIdet remplacez l’ID utilisateur dans l’URL de la requête Get_messages_for_user dans Postman. Envoyez à nouveau la demande Get_messages_for_user. La liste actuelle des messages pour l’utilisateur spécifié doit être renvoyée au format JSON.

Arrêtez et fermez le débogueur dans Linx Designer.

Implémenter la méthode Web Read_Message

Pour implémenter Read_message, nous essayons de récupérer le message par l’ID de message fourni. Si le message n’est pas trouvé, nous renvoyons une erreur pour l’indiquer. Cela couvrira le cas où le Message_ID, qui est un paramètre obligatoire, n’a pas été fourni. Sinon, nous vérifions si le message a déjà été lu. Sinon, nous le marquons comme lu. Ensuite, nous renvoyons le message.

Sélectionnez le gestionnaire Read_message. Ajouter un MongoDBRead au concepteur Read_message et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Retrieve_message_by_ID

Chaîne de connexion

= $. Settings.Database_connection

Collection

Message

Opération

Trouver

Requete

{_id: ObjectId (“@ {$. Input.Data.Message_ID}”)}

Le type de sortie

Serveur.Data.Message

Options de retour

Première ligne, sinon ligne vide

Ajouter un Sinon, et nommez-le If_message_found. Modifiez sa propriété Conditions et ajoutez une condition nommée Faux, avec la valeur: = Retrieve_message_by_ID == $ .System.Null

Ajouter un ThrowException sur le chemin False de If_message_found et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Throw_error

Message

= “Message avec ID” + $ .Input.Data.Message_ID + “introuvable.”

Ajouter un autre Sinon après If_message_found, et nommez-le If_message_is_read. Modifiez sa propriété Conditions et ajoutez une condition nommée False, avec la valeur: = Retrieve_message_by_ID.Is_read == false

Ajouter une instance d’un message type de données à partir de l’Explorateur de solutions, vers le chemin False de If_message_is_read, et définissez les propriétés suivantes:

Propriété

Valeur

Nom

lire le message

Valeur

= Retrieve_message_by_ID

Ajouter un SetValue au chemin False de If_message_is_read et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Mark_message_as_read

Cible

= read_message.Is_read

La source

Vrai

Ajouter un MongoDBWrite au chemin False de If_message_is_read et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Persist_read_message

Chaîne de connexion

= $. Settings.Database_connection

Collection

Message

Opération

Remplacer

Les données

= read_message

Ajouter un SetValue après If_message_is_read, et définissez les propriétés suivantes:

Propriété

Valeur

Nom

Set_response

Cible

= $. Données de sortie

Modifiez la propriété Source et définissez la propriété ResponseBody sur = Retrieve_message_by_ID

Tester la méthode Web Read_Message

Dans Postman, ajoutez une autre demande avec les informations suivantes:

Nom

Lire le message

Méthode HTTP

AVOIR

URL

{{Server_base_URL}} / read_message / 5faa7e92bc6e2d10a89fd093

Dans le concepteur Linx, sélectionnez le Web_service et démarrez le débogueur.

Envoyer la requête Read_message dans Postman. Cette demande doit échouer avec une erreur indiquant qu’un message avec l’ID spécifié est introuvable. En effet, l’ID de message dans l’exemple d’URL de demande Read_message, surligné en rouge ci-dessus, provient de ma base de données. Vous devrez changer cela pour utiliser la valeur correcte de votre base de données.

Dans Robo 3T, modifiez le document du premier message de la collection Message. Copiez la valeur du ObjectIdet remplacez l’ID de message dans l’URL de la requête Read_message dans Postman.

Envoyez maintenant à nouveau la demande Read_message. Le message avec l’ID spécifié doit être renvoyé au format JSON.

Arrêtez et fermez le débogueur dans Linx Designer.

Voila! Bien joué.

Close Menu