在一系列文章中，我们，宝石开发团队，将讨论在屏幕另一端与“ Gosuslugi”一起工作以及如何安排政府机构与门户之间的有效互动。
通过SMEV进行交互的一般方案
互动参与者
想象一下，“ Gosuslugi”是一家为公民和组织提供服务的商店。服务的“买方”请求通过部门间电子交互（SMEV）系统传输到相关当局。系统在门户网站和部门之间传输消息。
通过SMEV进行的工作是使用SOAP协议（简单对象访问协议-用于访问对象的简单协议）进行的。
互动的参与者（例如商店）分为供应商和消费者。供应商是一个根据请求提供信息的信息系统（IS），而消费者是一个请求信息的系统。
一个相同的IS可以同时扮演两个角色。例如，在提供服务的过程中，您需要将其状态更改通知门户。在这种情况下，IS供应商扮演着消费者的角色-它按状态进行信息交换。
信息类型
参与者通过信息类型（交换协议）交换数据-形成数据包的规则，用于从一个参与者传输到另一个参与者。
信息类型的一个很好的例子是2020年全俄人口普查。人口普查数据以电子形式传输到联邦行政机关。在收到的数据中，信息结构清晰：姓名，性别，出生日期，公民身份，婚姻状况。同样，在信息类型的框架内，描述了如果请求处理成功则应接收的响应。
截至2020年6月，SMEV已注册了1000多个工业（工人）和2000种测试物种。
工业环境中所有类型信息的数据交换都是通过安全的通信通道进行的。所有传输的数据均附有电子数字签名，借助SMEV，SMEV可以识别交互中的参与者。
数据通过SOAP传输，每个消息都是嵌套结构：
信息的类型分为简单和通用两类。考虑一种用于简单信息类型的数据交换方案：
该图显示了表单数据直接显示在数据交换信封中。因此，出现了局限性：有必要开发数据块的结构，针对每种此类信息的请求/响应。
通用信息交换可以表示如下：
乍一看，该方案可能看起来更复杂，但是它展示了一个根本的区别，最终简化了通用信息类型（UIC）参与者之间的交互。特定的表格数据在SMEV信封的附件中传输，允许识别信息类型的UMC标志直接在信封中传输，并且对于任何飞机都具有相同的结构：
- 门户网站的申请号和信息，以识别服务；
- 用户向其申请服务的目标单位。
门户网站用户填写的表单数据打包在主消息的附件中。
因此，您几乎可以正式提供几乎所有服务，而不必经历对新型信息的艰难注册。
消息队列和通信过程
在通信期间，消息被放置在传入请求队列和传入响应队列中。本质上，队列是按信息类型包含消息的容器。
与队列的交互使用特殊请求发生。有关使用SMEV的准则中对它们进行了更详细的描述。我们仅注意到，由于有了队列，异步数据交换成为可能：消费者可以留下信息请求，而供应商可以发布响应。
切记：要从队列中提取消息，您必须通过Ack请求确认接收。否则，SMEV将认为邮件未送达，并将在检索后15分钟将其返回到队列。
每个请求可以收到成功或失败的响应。
让我们想象一下自己是信息提供者的角色：根据要求，我们向用户发布一块土地的城市规划计划，并且在我们部门内有几个区域划分，其中一些根本不提供这样的服务。假设门户用户在形成服务应用程序时表示未提供服务的细分。出现这种情况有两个原因：
- 门户网站上的参考数据与供应商之间存在差异。
- 供应商的系统设置中根本没有所需的匹配项。
在任何一种情况下，提供者都必须响应该请求，以便接收方可以了解该请求失败并可能采取措施。对这种请求的响应是在特殊数据包中进行的，其中包含有关拒绝原因的信息。
成功的响应假设一种情况，其中服务的结果是一组文件（这是很常见的）。发送结果之前，有必要将文件上传到基于FTP服务器的SMEV文件存储中。必须在通过SOAP发送的数据包中捕获文件名及其校验和。因此，有两种数据传输操作需要通过公共上下文链接-文件信息。
在实践中，有时在交互过程中SMEV处于服务模式，并且参与者的请求被证明是失败的，需要重新发送。必须记录失败，并且必须重新提交请求。
问题的提法
考虑到上述功能，我们的团队必须通过通用信息确保客户的IS与“ Gosuslugi”集成。客户的信息系统-IAS“ Gradostroystvo”。在其帮助下，负责提供服务的部门的用户可以收集文件包并生成结果，以通过SMEV进一步传输到门户。
因此，就像关于歌曲中的话语那样，SMEV不能排除在与公共服务门户集成的解决方案中。但这是最好的：多亏了该系统，所有参与者都拥有一个通用的交互环境。这样，您就可以依靠特定的标准而不必重新发明轮子。
在以下文章中，我们将研究信息提供者方面如何使用Workflow Core业务流程自动化引擎基于用户数据来组织语句的处理。