En una serie de artículos, nosotros, el equipo de Desarrollo de Gems, hablaremos sobre cómo trabajar con "Gosuslugi" en el otro lado de la pantalla y cómo organizar la interacción efectiva de los organismos gubernamentales con el portal.
Esquema general de interacción a través de SMEV
Participantes de la interacción
Imagínese que "Gosuslugi" es una tienda que muestra servicios para ciudadanos y organizaciones. La solicitud del “comprador” de un servicio se transmite a las autoridades competentes a través del sistema de interacción electrónica interdepartamental (SMEV). El sistema transfiere mensajes entre el portal y el departamento.
El trabajo a través de SMEV se lleva a cabo utilizando el protocolo SOAP ( Simple Object Access Protocol , un protocolo simple para acceder a objetos).
Los participantes de la interacción, como en una tienda, se dividen en proveedores y consumidores. El proveedor es un sistema de información (SI) que proporciona información a pedido, y el consumidor es un sistema que solicita información.
Un mismo SI puede actuar en dos roles a la vez. Por ejemplo, en el proceso de proporcionar un servicio, debe notificar al portal sobre un cambio en su estado. En este caso, el proveedor de SI desempeña el papel de consumidor: lleva a cabo el intercambio de información por estados.
Tipos de informacion
Los participantes intercambian datos a través de tipos de información ( protocolos de intercambio ): reglas para la formación de paquetes de datos para su transmisión de un participante a otro.
Un buen ejemplo del tipo de información es el censo de población de toda Rusia de 2020 . Los datos del censo se transmiten a las autoridades ejecutivas federales en forma electrónica. En los datos recibidos hay una clara estructura de información: nombre, sexo, fecha de nacimiento, ciudadanía, estado civil. Asimismo, en el marco del tipo de información, se describe la respuesta que se debe recibir si el procesamiento de la solicitud fue exitoso.
A junio de 2020, se han registrado más de 1000 industriales (trabajadores) y 2000 especies de prueba en SMEV.
El intercambio de datos en un entorno industrial para todo tipo de información se realiza a través de canales de comunicación seguros. Todos los datos transmitidos van acompañados de una firma digital electrónica, con la que SMEV identifica a los participantes en la interacción.
Los datos se transmiten a través de SOAP, y cada mensaje es una estructura anidada:
Los tipos de información se dividen en dos grupos: simple y universal . Considere un esquema de intercambio de datos para un tipo simple de información:
El diagrama muestra que los datos del formulario se muestran directamente en los sobres de intercambio de datos. Debido a esto, aparece una limitación: es necesario desarrollar la estructura de un bloque de datos, solicitud / respuesta para cada tipo de información.
El intercambio por un tipo universal de información se puede representar de la siguiente manera:
A primera vista, el esquema puede parecer más complicado, pero demuestra una diferencia fundamental, que en última instancia simplifica la interacción entre los participantes en el tipo universal de información (UIC). Los datos específicos de los formularios se transfieren en un anexo al sobre SMEV, y los rótulos HCS que permiten identificar el tipo de información se transfieren directamente en el sobre y tienen la misma estructura para cualquier aeronave:
- Número de solicitud del portal e información que permita identificar el servicio;
- unidad de destino a la que el usuario solicita el servicio.
Los datos del formulario rellenados por el usuario del portal se empaquetan en un archivo adjunto al mensaje principal.
Así, puedes formalizar la prestación de casi cualquier servicio sin tener que pasar por el difícil registro de un nuevo tipo de información.
Colas de mensajes y proceso de comunicación
Durante la comunicación, los mensajes se colocan en las colas de solicitudes entrantes y las colas de respuestas entrantes . En esencia, las colas son contenedores que contienen mensajes por tipo de información.
La interacción con las colas se produce mediante solicitudes especiales. Se describen con más detalle en las directrices para trabajar con SMEV. Solo notamos que gracias a las colas, el intercambio de datos asincrónico se vuelve posible: el consumidor puede dejar una solicitud para recibir información y el proveedor puede publicar una respuesta.
Recuerde: para recoger un mensaje de la cola, debe confirmar la recepción con una solicitud de Ack. De lo contrario, SMEV considerará que el mensaje no se ha entregado y lo devolverá a la cola 15 minutos después de su recuperación.
Cada solicitud puede recibir una respuesta satisfactoria o no satisfactoria.
Imaginémonos en el rol de proveedor de información: previa solicitud, entregamos al usuario un plano urbanístico de un terreno, y dentro de nuestro departamento existen varias divisiones territoriales, algunas de las cuales no brindan tal servicio en absoluto. Supongamos que un usuario del portal, al crear una solicitud para un servicio, indicó una unidad que no brinda el servicio. Esta situación puede surgir por dos motivos:
- Hubo una discrepancia entre los datos de referencia en el portal y el proveedor;
- La coincidencia requerida simplemente no está disponible en la configuración del sistema del proveedor.
En cualquier caso, el proveedor debe responder a la solicitud para que la parte receptora pueda comprender que la solicitud falló y posiblemente tomar medidas. La respuesta a dicha solicitud se realiza en un paquete de datos especial con información sobre el motivo del rechazo.
Una respuesta exitosa supone un escenario en el que el resultado del servicio es un conjunto de archivos (lo cual es bastante común). Antes de enviar el resultado, es necesario cargar los archivos en el almacenamiento de archivos SMEV basado en un servidor FTP. Los nombres de los archivos y sus sumas de comprobación deben capturarse en el paquete que se envía a través de SOAP. Por lo tanto, hay dos operaciones de transferencia de datos que deben estar vinculadas por un contexto común: información de archivo.
En la práctica, hay casos en los que, durante la interacción, el SMEV está en modo de servicio y las solicitudes del participante resultan fallidas y requieren un reenvío. Se debe registrar el error y volver a enviar la solicitud.
Formulación del problema
Teniendo en cuenta las características anteriores, nuestro equipo tenía que asegurar la integración del SI del cliente con "Gosuslugi" mediante un tipo de información universal . Sistema de información del cliente - IAS "Gradostroystvo" . Con su ayuda, los usuarios de los departamentos responsables de la prestación de servicios pueden recopilar paquetes de documentos y generar resultados para su posterior transmisión al portal a través de SMEV.
Entonces, SMEV, como dice el refrán sobre la letra de la canción, no puede quedar excluido de la solución del problema de integración con el portal de servicios públicos. Pero esto es lo mejor: gracias al sistema, todos los participantes tienen un entorno de interacción universal. Esto le permite confiar en un cierto estándar y no reinventar la rueda.
En los próximos artículos, veremos cómo, por parte del proveedor de información, organizar el procesamiento de declaraciones de acuerdo con los datos del usuario utilizando el motor de automatización de procesos de negocio Workflow Core.