In a series of articles, we, the Gems Development team, will talk about working with "Gosuslugi" on the other side of the screen and how to arrange effective interaction of government bodies with the portal.
General scheme of interaction through SMEV
Interaction participants
Imagine that "Gosuslugi" is a store displaying services for citizens and organizations. The “buyer” request for a service is transmitted to the relevant authorities through the system of interdepartmental electronic interaction (SMEV). The system transfers messages between the portal and the department.
Work through SMEV is carried out using the SOAP protocol ( Simple Object Access Protocol - a simple protocol for accessing objects).
Participants in the interaction, as in a store, are divided into suppliers and consumers. The supplier is an information system (IS) that provides information upon request, and the consumer is a system that requests information.
One and the same IS can act in two roles at once. For example, in the process of providing a service, you need to notify the portal about a change in its status. In this case, the IS-supplier plays the role of a consumer - it carries out information exchange by statuses.
Types of information
Participants exchange data through types of information ( exchange protocols ) - rules for the formation of data packets for transmission from one participant to another.
A good example of the type of information is the 2020 All-Russian Population Census . Census data are transmitted to federal executive authorities in electronic form. In the data received, there is a clear structure of information: name, gender, date of birth, citizenship, marital status. Also, within the framework of the information type, the response is described that should be received if the processing of the request was successful.
As of June 2020, more than 1000 industrial (workers) and 2000 test species have been registered in SMEV.
Data exchange in an industrial environment for all types of information is carried out through secure communication channels. All transmitted data are accompanied by an electronic digital signature, with the help of which SMEV identifies the participants in the interaction.
Data is transmitted over SOAP, with each message being a nested structure:
The types of information are divided into two groups - simple and universal . Consider a data exchange scheme for a simple type of information:
The diagram shows that the form data is displayed directly in the data exchange envelopes. Because of this, a limitation appears: it is necessary to develop the structure of the data block, request / response for each such type of information.
Exchange by a universal type of information can be represented as follows:
At first glance, the scheme may seem more complicated, but it demonstrates a fundamental difference, which ultimately simplifies the interaction between participants in the universal type of information (UIC). Specific form data are transmitted in an attachment to the SMEV envelope, and the UMC signs, which allow identifying the type of information, are transmitted directly in the envelope and have the same structure for any aircraft:
- Portal application number and information allowing to identify the service;
- target unit to which the user applies for the service.
The form data filled in by the portal user is packaged in an attachment to the main message.
Thus, you can formalize the provision of almost any service without having to go through the difficult registration of a new type of information.
Message queues and communication process
During communication, messages are placed in the incoming request queues and the incoming response queues . In essence, queues are containers that contain messages by type of information.
Interaction with queues occurs using special requests. They are described in more detail in the guidelines for working with SMEV. We only note that thanks to queues, asynchronous data exchange becomes possible: the consumer can leave a request for information, and the provider can post a response.
Remember: to pick up a message from the queue, you must confirm receipt with an Ack request. Otherwise, SMEV will consider the message undelivered and will return it to the queue 15 minutes after retrieval.
Each request can receive either a successful or unsuccessful response.
Let's imagine ourselves in the role of a provider of information: upon request, we issue the user with a town-planning plan of a land plot, and within our department there are several territorial divisions, some of which do not provide such a service at all. Suppose a portal user, when forming an application for a service, indicated a unit that does not provide the service. This situation can arise for two reasons:
- There was a discrepancy between the reference data on the portal and the supplier;
- The required match is simply not available in the supplier's system settings.
In either case, the provider should respond to the request so that the receiving party can understand that the request failed and possibly take action. The response to such a request is made in a special data packet with information about the reason for the refusal.
A successful response assumes a scenario in which the result of the service is a set of files (which is quite common). Before sending the result, it is necessary to upload the files to the SMEV file storage based on an FTP server. The file names and their checksums must be captured in the packet that is sent over SOAP. Thus, there are two data transfer operations that need to be linked by a common context - file information.
In practice, there are cases when, during the interaction, the SMEV is in the service mode, and the participant's requests turn out to be a failure and require re-sending. The failure must be recorded and the request must be resubmitted.
Formulation of the problem
Taking into account the above features, our team had to ensure the integration of the customer's IS with "Gosuslugi" by a universal type of information . Information system of the customer - IAS "Gradostroystvo" . With its help, users of departments responsible for the provision of services can collect packages of documents and generate results for further transmission to the portal through SMEV.
So, SMEV, as in the saying about the words in the song, cannot be excluded from the solution of the problem of integration with the portal of public services. But this is for the best: thanks to the system, all participants have a universal interaction environment. This allows you to rely on a certain standard and not reinvent the wheel.
In the next articles, we will look at how, on the side of the information provider, to organize the processing of statements according to user data using the Workflow Core business process automation engine.