Dans une série d'articles, nous, l'équipe de développement de Gems, parlerons de travailler avec "Gosuslugi" de l'autre côté de l'écran et comment organiser une interaction efficace des organismes gouvernementaux avec le portail.
Schéma général d'interaction via SMEV
Participants à l'interaction
Imaginez que "Gosuslugi" soit un magasin présentant des services pour les citoyens et les organisations. La demande de service de «l'acheteur» est transmise aux autorités compétentes via le système d'interaction électronique interministérielle (SMEV). Le système transfère les messages entre le portail et le service.
Le travail via SMEV est réalisé en utilisant le protocole SOAP ( Simple Object Access Protocol - un protocole simple pour accéder aux objets).
Les participants à l'interaction, comme dans un magasin, sont divisés en fournisseurs et consommateurs. Le fournisseur est un système d'information (SI) qui fournit des informations sur demande, et le consommateur est un système qui demande des informations.
Un seul et même SI peut jouer deux rôles à la fois. Par exemple, lors du processus de fourniture d'un service, vous devez informer le portail d'un changement de son statut. Dans ce cas, le fournisseur du SI joue le rôle d'un consommateur - il procède à des échanges d'informations par statuts.
Types d'informations
Les participants échangent des données par le biais de types d'informations ( protocoles d'échange ) - règles pour la formation de paquets de données à transmettre d'un participant à un autre.
Le recensement de la population panrusse de 2020 est un bon exemple du type d'information . Les données du recensement sont transmises aux autorités exécutives fédérales sous forme électronique. Dans les données reçues, il existe une structure claire des informations: nom, sexe, date de naissance, citoyenneté, état matrimonial. De même, dans le cadre du type d'information, la réponse est décrite qui doit être reçue si le traitement de la demande a abouti.
En juin 2020, plus de 1000 espèces industrielles (travailleurs) et 2000 espèces testées ont été enregistrées dans SMEV.
L'échange de données dans un environnement industriel pour tous types d'informations se fait via des canaux de communication sécurisés. Toutes les données transmises sont accompagnées d'une signature numérique électronique, à l'aide de laquelle SMEV identifie les participants à l'interaction.
Les données sont transmises via SOAP, chaque message étant une structure imbriquée:
Les types d'informations sont divisés en deux groupes - simples et universels . Considérez un schéma d'échange de données pour un type d'information simple:
Le diagramme montre que les données du formulaire sont affichées directement dans les enveloppes d'échange de données. De ce fait, une limitation apparaît: il est nécessaire de développer la structure du bloc de données, requête / réponse pour chacun de ces types d'informations.
L'échange par un type universel d'informations peut être représenté comme suit:
À première vue, le schéma peut sembler plus compliqué, mais il met en évidence une différence fondamentale, qui simplifie finalement l'interaction entre les participants au type universel d'information (UIC). Des données de formulaire spécifiques sont transmises en pièce jointe à l'enveloppe SMEV, et les signes UMC, qui permettent d'identifier le type d'informations, sont transmis directement dans l'enveloppe et ont la même structure pour tout aéronef:
- Numéro d'application du portail et informations permettant d'identifier le service;
- unité cible à laquelle l'utilisateur demande le service.
Les données du formulaire remplies par l'utilisateur du portail sont regroupées dans une pièce jointe au message principal.
Ainsi, vous pouvez formaliser la fourniture de presque tous les services sans avoir à passer par l'enregistrement difficile d'un nouveau type d'informations.
Files d'attente de messages et processus de communication
Pendant la communication, les messages sont placés dans les files d'attente de demandes entrantes et les files d'attente de réponses entrantes . En substance, les files d'attente sont des conteneurs qui contiennent des messages par type d'information.
L'interaction avec les files d'attente se produit à l'aide de demandes spéciales. Ils sont décrits plus en détail dans les lignes directrices pour travailler avec SMEV. On constate seulement que grâce aux files d'attente, l'échange de données asynchrone devient possible: le consommateur peut laisser une demande d'informations, et le fournisseur peut poster une réponse.
N'oubliez pas: pour récupérer un message de la file d'attente, vous devez confirmer sa réception avec une demande d'acquittement. Sinon, SMEV considérera le message comme non livré et le renverra dans la file d'attente 15 minutes après la récupération.
Chaque demande peut recevoir une réponse réussie ou non.
Imaginons-nous dans le rôle d'un fournisseur d'informations: sur demande, nous délivrons à l'utilisateur un plan d'urbanisme d'un terrain, et au sein de notre département il existe plusieurs divisions territoriales dont certaines ne fournissent pas du tout un tel service. Supposons qu'un utilisateur du portail, lors de la création d'une application pour un service, indique une unité qui ne fournit pas le service. Cette situation peut survenir pour deux raisons:
- Il y avait un écart entre les données de référence sur le portail et le fournisseur;
- La correspondance requise n'est tout simplement pas disponible dans les paramètres système du fournisseur.
Dans les deux cas, le fournisseur doit répondre à la demande afin que la partie réceptrice puisse comprendre que la demande a échoué et éventuellement prendre des mesures. La réponse à une telle demande est faite dans un paquet de données spécial contenant des informations sur la raison du refus.
Une réponse réussie suppose un scénario dans lequel le résultat du service est un ensemble de fichiers (ce qui est assez courant). Avant d'envoyer le résultat, il est nécessaire de télécharger les fichiers dans le stockage de fichiers SMEV basé sur le serveur FTP. Les noms de fichiers et leurs sommes de contrôle doivent être capturés dans le paquet envoyé via SOAP. Ainsi, il existe deux opérations de transfert de données qui doivent être liées par un contexte commun: les informations de fichier.
En pratique, il existe des cas où, lors de l'interaction, le SMEV est en mode service, et les demandes du participant s'avèrent être un échec et nécessitent un ré-envoi. L'échec doit être enregistré et la demande doit être resoumise.
Formulation du problème
Compte tenu des caractéristiques ci-dessus, notre équipe devait assurer l'intégration du SI du client avec «Gosuslugi» par un type d'information universel . Système d'information du client - IAS "Gradostroystvo" . Avec son aide, les utilisateurs des services responsables de la fourniture de services peuvent collecter des paquets de documents et générer des résultats pour une transmission ultérieure au portail via SMEV.
Ainsi, SMEV, comme dans le dicton sur les paroles de la chanson, ne peut être exclue de la solution du problème de l'intégration avec le portail des services publics. Mais c'est pour le mieux: grâce au système, tous les participants disposent d'un environnement d'interaction universel. Cela vous permet de vous fier à un certain standard et de ne pas réinventer la roue.
Dans les prochains articles, nous verrons comment, du côté du fournisseur d'informations, organiser le traitement des relevés en fonction des données utilisateur à l'aide du moteur d'automatisation des processus métiers Workflow Core.