Ajout d'un bot télégramme au projet - "Projet Java de A à Z"

Salutations, mes chers amis. Oui, oui, exactement amis. Je suis déjà tellement familier avec cette série d'articles que les personnes qui écrivent régulièrement leur gratitude dans les commentaires et/ou montrent qu'elles ont lu et compris le matériel sont déjà devenues proches. Vous et moi avançons des deux côtés vers le même objectif. Vous voulez comprendre, mais je veux expliquer. Et nous avons le même objectif final : une candidature écrite qui vous est compréhensible du début à la fin. Vous avez peut-être déjà entendu parler d’une grande partie de ce que je vais décrire dans cet article. Je ne pense pas que je vais vous dire quelque chose de nouveau et d’extraordinaire (mais dans le cadre du projet il faut savoir/répéter cela). Au printemps, j'ai écrit un bot pour moi-même, nous nous appuierons donc sur ses « modèles ».

Nous écrivons JRTB-2

Nous ferons la même chose que dans l'article avec la tâche JRTB-0 :

1. Nous mettons à jour la branche principale du projet local en utilisant la combinaison ctrl + t .
2. A partir de la branche principale, nous créons :
3. Ajoutez un robot.
4. Nous créons un nouveau commit avec une description de ce qui a été fait et le transmettons à GitHub.
5. Créez une pull request pour la branche principale et vérifiez-la à nouveau. Nous attendons que la construction soit terminée (actions github), fusionnons-la dans la branche principale.
6. Fermez la tâche correspondante.

Qu'est-ce qu'un robot de télégramme

Nous, développeurs, pouvons imaginer travailler avec un robot télégramme comme celui-ci : nous utilisons leur client pour travailler avec eux. Nous avons une bibliothèque prête à l'emploi pour le travail. Il existe un ensemble d'actions après lesquelles le robot Telegram saura qu'il est associé à notre programme. Et déjà dans le programme, nous apprendrons comment recevoir des lettres, des commandes et les traiter d'une manière ou d'une autre. Il existe une commande dans les robots télégrammes : elle commence par une barre oblique « / ». Après cela, nous écrivons immédiatement le mot ensemble, et cela sera considéré comme une commande. Par exemple, il y a deux commandes que tout le monde devrait connaître :

• /start — commencez à travailler avec le bot ;
• /stop - termine le travail avec le bot.

Nous ferons le reste nous-mêmes. Permettez-moi de faire une réservation tout de suite : nous ferons exactement ce que et de la manière que j'ai appris. Et en travaillant avec un bot, je suis sûr qu'il sera possible de faire mieux. Et si quelqu’un veut le faire, je n’en serai qu’heureux et je soutiendrai cette entreprise de toutes les manières possibles. À propos, la toute première chose qui serait cool, c'est que quelqu'un m'explique comment programmer la description des commandes via du code, et non via les paramètres du bot dans le télégramme. Je n'ai pas appris ça. Nous avons plusieurs articles sur notre ressource qui décrivent comment créer un bot de base : aujourd'hui, nous allons faire quelque chose de similaire. Si vous avez d'autres questions, je vous recommande de parcourir cet article.

Créer un bot avec BotFather

Pour connecter un bot, vous devez d'abord le créer. Telegram a une approche : créer un bot avec son propre nom unique. Il sera également accompagné d'un token (une grosse chaîne qui fonctionne comme un mot de passe). J'ai déjà créé un bot pour JavaRush - @javarush_community_bot . Ce bot est toujours vide et ne peut rien faire. L'essentiel est qu'il y ait _bot à la fin du nom . Pour montrer comment faire, je vais créer un bot sur lequel nous testerons nos fonctionnalités. En termes de projets réels, il s’agirait d’un environnement de test. Et notre principal sera l'environnement de production (prod - production, c'est-à-dire l'environnement réel sur lequel le projet sera exécuté). Bien entendu, il serait possible d'ajouter un autre environnement - un environnement sandbox : un bac à sable commun, plus modifiable et accessible à tous les participants au développement. Mais cela ne fera que compliquer la situation au stade de la création du projet. Pour l'instant, créons deux autres robots pour les tests et pour l'environnement sandbox. La première étape consiste à créer (enregistrer) un bot dans Telegram lui-même. Nous devons trouver le bot : @BotFather et lui écrire la commande : /newbot Ensuite, on nous demande de donner un nom à ce bot. Puisqu'il s'agit d'un bot pour tester des tâches, son nom sera approprié : [TEST] JavarushBot Il est maintenant temps de donner un nom unique sous lequel il pourra toujours être trouvé - son nom d'utilisateur : test_javarush_community Comme je l'ai dit plus haut, vous devez ajouter le _bot suffixe pour le nom d'utilisateur, donc on écrit à nouveau : test_javarush_community_bot Et c'est tout ! Le bot a été créé. Désormais, en utilisant le nom d'utilisateur et le jeton, il peut être connecté à notre projet. Bien entendu, pour le bon fonctionnement du serveur de test, je n'afficherai pas le token (essentiellement un mot de passe pour accéder au bot) de ce bot pour une consultation publique.

Nous connectons le bot au projet

Nous n'inclurons pas la bibliothèque comme d'habitude, mais profiterons immédiatement de notre squelette - SpringBoot. Il a quelque chose comme Starter. En incluant la bibliothèque, nous pouvons l'utiliser pour faire savoir à SpringBoot que nous souhaitons configurer correctement le projet. Si nous devions suivre la voie habituelle, décrite à de nombreux endroits, nous aurions besoin de créer quelque part une configuration qui ressemblerait à ceci :

ApiContextInitializer.init();
TelegramBotsApi telegramBotsApi = new TelegramBotsApi();
try {
  telegramBotsApi.registerBot(Bot.getBot());
} catch (TelegramApiRequestException e) {
  e.printStackTrace();
}

Ici, un objet est créé avec lequel vous pouvez établir une connexion avec le bot. Dans notre cas, le démarreur que nous voulons connecter fera tout pour nous quelque part « sous le capot » (c'est aussi une traduction d'une expression fréquemment utilisée en informatique - sous le capot). Voici un lien vers ce démarreur . Vous pouvez immédiatement voir à partir du fichier README.md de quoi il s’agit, pourquoi et comment l’utiliser. Pour le connecter, il suffit d'ajouter cette dépendance en mémoire. C'est tout :) Voici la dépendance requise :

<dependency>
        <groupId>org.telegram</groupId>
        <artifactId>telegrambots-spring-boot-starter</artifactId>
        <version>5.0.1</version>
    </dependency>

Nous l'ajoutons à notre mémoire. Nous installons la version comme prévu et mettons à jour le projet Maven. Sur la base de la description, il nous suffit de créer une nouvelle classe, d'hériter de TelegramLongPollingBot et d'ajouter cette classe au contexte d'application de notre SpringBoot. Le contexte d'application est l'endroit où sont stockés les objets créés pour exécuter le projet. Pour ajouter une classe, vous devez utiliser l'une des annotations : @Component, @Service, @Repository, @Controller. Ou l'annotation @Bean si elle est créée via une méthode dans une classe de configuration (c'est-à-dire dans une classe marquée avec l'annotation Configuration). Je comprends que tout cela puisse encore paraître incompréhensible. Mais quand vous commencerez à comprendre, vous verrez qu'il n'y a rien de compliqué là-bas. Pour comprendre rapidement Spring Boot, je recommande un livre sympa - Spring In Action 5e édition. Si j'en ai envie, je peux écrire une série d'articles basés sur ce livre. Retournons. Dans le package qui contient JavarushTelegramBotApplication, nous créons le package bot , qui contiendra notre bot télégramme. Son nom sera JavaRushTelegramBot :

package com.github.javarushcommunity.jrtb.bot;

import org.telegram.telegrambots.bots.TelegramLongPollingBot;
import org.telegram.telegrambots.meta.api.objects.Update;

/**
* Telegrambot for Javarush Community from Javarush community.
*/
@Component
public class JavarushTelegramBot extends TelegramLongPollingBot {

   @Override
   public void onUpdateReceived(Update update) {

   }

   @Override
   public String getBotUsername() {
       return null;
   }

   @Override
   public String getBotToken() {
       return null;
   }
}

Cette classe était abstraite et trois méthodes devaient être implémentées. Parlons-en plus en détail :

• onUpdateReceived(Update update) - c'est le point d'entrée où les messages des utilisateurs arriveront. Toute nouvelle logique viendra d’ici ;
• getBotUsername() - ici, vous devez ajouter le nom d'utilisateur de notre bot auquel nous nous connecterons ;
• getBotToken() - et ceci, par conséquent, est le jeton du bot.

C’est essentiellement comme un identifiant et un mot de passe pour un site. Nous n’écrirons pas explicitement cette valeur pour l’instant. C'est ce qu'on appelle le « codage en dur » (c'est-à-dire lier une valeur particulière - comme d'habitude, du papier calque à partir du code dur anglais). Tu ne devrais pas faire ça. Nous irons dans l'autre sens - nous écrirons ces données dans la classe application.properties et les lirons à partir d'ici. Pourquoi est-ce nécessaire ? Ensuite, pour qu'au démarrage de l'application, nous puissions définir ces valeurs en externe. C'est flexible, c'est vrai. Accédez au fichier src/main/resources/application.properties. Là, nous trouverons des noms pour ces variables. Les fichiers avec l'extension .properties sont lus comme une structure clé-valeur séparée par « = », chaque paire étant une ligne distincte. J'ai donc trouvé ces variables :

• bot.nom d'utilisateur ;
• bot.token .

Voici à quoi cela ressemblera : SpringBoot a une excellente annotation - @Value. S'il est utilisé correctement, il extraira les valeurs du fichier application.properties. Nous mettons à jour le projet avec ceci :

package com.github.javarushcommunity.jrtb.bot;

import org.springframework.beans.factory.annotation.Value;
import org.telegram.telegrambots.bots.TelegramLongPollingBot;
import org.telegram.telegrambots.meta.api.objects.Update;

/**
* Telegram bot for Javarush Community from Javarush community.
*/
@Component
public class JavarushTelegramBot extends TelegramLongPollingBot {

   @Value("${bot.username}")
   private String username;

   @Value("${bot.token}")
   private String token;

   @Override
   public void onUpdateReceived(Update update) {

   }

   @Override
   public String getBotUsername() {
       return username;
   }

   @Override
   public String getBotToken() {
       return token;
   }
}

On voit que nous avons transmis la valeur de la variable à l'annotation. Et lorsque SpringBoot crée notre objet bot, les valeurs seront extraites des propriétés (encore une fois, papier calque de l'anglais - propriétés). Nous y sommes presque. Vous devez faire en sorte que le bot réponde à quelque chose. Par conséquent, mettons à jour la méthode onUpdateReceived . Nous devons récupérer le message arrivé au bot et le renvoyer. De cette façon, nous saurons que le bot fonctionne. Pour ce faire, nous écrirons grossièrement et rapidement ce qui est nécessaire :

@Override
public void onUpdateReceived(Update update) {
   if(update.hasMessage() && update.getMessage().hasText()) {
       String message = update.getMessage().getText().trim();
       String chatId = update.getMessage().getChatId().toString();

       SendMessage sm = new SendMessage();
       sm.setChatId(chatId);
       sm.setText(message);

       try {
           execute(sm);
       } catch (TelegramApiException e) {
           //todo add logging to the project.
           e.printStackTrace();
       }
   }
}

Tout ici est extrêmement simple : on vérifie que le message existe réellement, on extrait donc le message lui-même ( message ) et l'identifiant du chat ( chatId ) dans lequel se déroule la correspondance. Ensuite, nous créons un objet pour envoyer un message SendMessage , lui transmettons le message lui-même et l'ID de discussion - c'est-à-dire quoi envoyer au bot et où. Nous en avons déjà assez. Ensuite, nous exécutons la méthode main dans la classe JavarushTelegramBotApplication et recherchons notre bot dans Telegram : à partir des journaux, nous voyons que le bot a démarré. Alors, il est temps d'aller sur Telegram et d'écrire au bot : On clique sur démarrer et on reçoit immédiatement une réponse : Écrivons encore quelques conneries pour vérifier : Et ça y est, à ce stade on peut dire que notre tâche JRTB-2 est terminée . Vous ne pouvez pas encore vraiment écrire de tests ici, nous allons donc tout laisser tel quel. Ensuite, vous devez créer un nouveau commit : Faites attention au nom du commit : encore une fois j'attire votre attention là-dessus. Un commit contient d'abord le nom de la tâche, puis une description plus détaillée de ce qui a été fait. Cliquez sur Commit et Push... et confirmez en cliquant à nouveau sur Push : Accédez à notre projet . Comme auparavant, GitHub a déjà vu la nouvelle branche et propose de créer une pull request pour main. On ne résiste pas et on le crée : comme d’habitude, on a déjà choisi un label, un projet et on me l’a confié. Enfin, cliquez sur Créer une demande de tirage. Attendons un peu pendant que la construction se déroule - et c'est tout, la pull request est prête à être fusionnée :

Gestion des versions

J'ai en quelque sorte raté le point selon lequel nous devons faire du versioning. Pour ce faire, nous apporterons quelques changements supplémentaires dans notre branche. Nous retournons à IDEA et regardons la version du projet en mémoire : La version est 0.0.1-SNAPSHOT . Il s'agit de la version de service. Et nous commencerons par mettre à jour la version du projet à chaque nouveau problème résolu. Jusqu'à ce que nous atteignions MVP, la version sera accompagnée du suffixe -SNAPSHOT. Quel sera le schéma de versioning ? XYZ-INSTANTANÉ Où :

• X - mise à jour de la version majeure, contient souvent des problèmes de compatibilité descendante avec la version précédente ;
• Y - pas de très gros changements, entièrement compatible avec la version précédente ;
• Z est un compteur de défauts que nous avons trouvés et réparés.

Sur cette base, nous aurons la première version - 0.1.0-SNAPSHOT - c'est-à-dire que nous n'avons pas encore eu de mises à jour majeures, juste un peu de tout, et nous n'avons pas encore atteint MVP, il y a donc un suffixe -SNAPSHOT . Modifions cela dans la mémoire : Accédez au fichier RELEASE_NOTES, où nous décrirons les modifications apportées au projet à chaque nouvelle version : Notre première entrée. Désormais, à chaque mise à jour de version ultérieure, nous décrirons ici ce qui s'est exactement passé. Nous commettons ce cas, écrivons une description : JRTB-2 : version du projet mise à jour et ajoutée à RELEASE_NOTES Tout est exactement comme avant. Nous attendons que la construction soit terminée et que nous puissions fusionner nos modifications. Seulement ici, ce sera un peu différent. Je veux m'assurer que chaque tâche de la branche principale est un commit distinct, donc le simple fait de pousser une demande d'extraction de fusion ne fonctionnera pas pour nous. Git a l'option git squash, qui rassemble tous les commits en un seul et les fusionne. Nous sélectionnons cette option : Cliquez sur Squash and Merge, et on nous propose d'éditer le message, qui sera au final : Très pratique et surtout, ce qui est demandé. D'ailleurs, je n'ai pas vu une telle fonctionnalité sur bitbucket =/ Confirm the merge. Il ne reste plus qu'à changer le statut de la tâche en Terminé dans notre tableau, à écrire un commentaire avec un lien vers la pull request et à le fermer : Notre tableau ressemble maintenant à ceci :

Conclusion

Aujourd'hui, nous avons créé étape par étape un robot de télégramme et l'avons implémenté dans notre projet SpringBoot. Le bot fonctionne et donne des réponses. Nous avons immédiatement accédé aux données du bot via les propriétés. Plus à venir : nous ferons un gros morceau - exécuter JRTB-3 - en ajoutant un modèle de commande pour notre projet. Ah, encore une chose... Je vous ai dit que je ne publierais pas le token afin qu'il ne soit pas utilisé. Mais comme j'écrivais l'article vers minuit et après le travail, il s'est avéré que j'avais posté un token valide dans le référentiel, et GitGuardian m'en a parlé dans une lettre : Merci à eux pour cela ! Que faire maintenant? Il ne sera plus possible de le supprimer de git, car même si je télécharge un nouveau commit sans ce token, il restera toujours dans l'ancien. Mais je ne veux pas supprimer et annuler le commit. Je suis donc allé désactiver le jeton du BotFather déjà mentionné. Le jeton est désormais là, mais il n'est plus valide. Abonnez-vous à mon compte GitHub pour voir tout le code avant de publier l'article. Merci à tous d'avoir lu, à bientôt.

Une liste de tous les matériaux de la série se trouve au début de cet article.