一連の記事では、Gems Developmentチームが、画面の反対側にある「Gosuslugi」の操作と、政府機関とポータルとの効果的な相互作用を調整する方法について説明します。
SMEVを介した相互作用の一般的なスキーム
インタラクション参加者
「Gosuslugi」が市民や組織向けのサービスを展示している店だと想像してみてください。サービスの「購入者」リクエストは、部門間電子インタラクション（SMEV）のシステムを介して関連当局に送信されます。システムはポータルと部門の間でメッセージを転送します。
SMEVを介した作業は、SOAPプロトコル（Simple Object Access Protocol-オブジェクトにアクセスするための単純なプロトコル）を使用して実行されます。
店舗の場合と同様に、インタラクションの参加者はサプライヤとコンシューマに分けられます。サプライヤーは要求に応じて情報を提供する情報システム（IS）であり、コンシューマーは情報を要求するシステムです。
1つの同じISが同時に2つの役割を果たします。たとえば、サービスを提供する過程で、ステータスの変更についてポータルに通知する必要があります。この場合、ISサプライヤは消費者の役割を果たし、ステータスごとに情報交換を行います。
情報の種類
参加者は、情報の種類（交換プロトコル）を介してデータを交換します-ある参加者から別の参加者に送信するためのデータパケットの形成に関する規則。
情報の種類の良い例は、2020年の全ロシア人口センサスです。国勢調査データは、電子形式で連邦執行当局に送信されます。受け取ったデータには、名前、性別、生年月日、市民権、婚姻状況など、明確な情報構造があります。また、情報タイプのフレームワーク内で、要求の処理が成功した場合に受信する必要がある応答が記述されています。
2020年6月の時点で、1000を超える産業（労働者）と2000の試験種がSMEVに登録されています。
産業環境でのあらゆる種類の情報のデータ交換は、安全な通信チャネルを介して実行されます。送信されるすべてのデータには電子デジタル署名が添付されており、SMEVはその助けを借りて対話の参加者を識別します。
データはSOAPを介して送信され、各メッセージはネストされた構造になります。
情報の種類は、シンプルとユニバーサルの2つのグループに分けられます。単純なタイプの情報のデータ交換スキームについて考えてみます。
この図は、フォームデータがデータ交換エンベロープに直接表示されていることを示しています。このため、制限があります。データブロックの構造、そのようなタイプの情報ごとの要求/応答を開発する必要があります。
ユニバーサルタイプの情報による交換は、次のように表すことができます。
一見、このスキームはより複雑に見えるかもしれませんが、根本的な違いを示しており、最終的にはユニバーサルタイプの情報（UIC）の参加者間の相互作用が簡素化されます。特定のフォームデータはSMEVエンベロープに添付されて送信され、情報のタイプを識別できるUMCサインはエンベロープで直接送信され、どの航空機でも同じ構造になります。
- ポータルアプリケーション番号とサービスの識別を可能にする情報。
- ユーザーがサービスを申請するターゲットユニット。
ポータルユーザーが入力したフォームデータは、メインメッセージの添付ファイルにパッケージ化されています。
したがって、新しいタイプの情報の難しい登録を経ることなく、ほとんどすべてのサービスの提供を形式化することができます。
メッセージキューと通信プロセス
通信中、メッセージは着信要求キューと着信応答キューに配置されます。本質的に、キューは情報のタイプごとのメッセージを含むコンテナです。
キューとの相互作用は、特別な要求を使用して発生します。これらについては、SMEVを使用するためのガイドラインで詳しく説明されています。キューのおかげで、非同期データ交換が可能になることに注意してください。消費者は情報の要求を残すことができ、プロバイダーは応答を投稿できます。
注意：キューからメッセージを取得するには、Ackリクエストでメッセージの受信を確認する必要があります。それ以外の場合、SMEVはメッセージが未配信であると見なし、取得後15分でキューに戻します。
各リクエストは、成功または失敗した応答を受け取ることができます。
情報提供者の役割を想像してみてください。リクエストに応じて、土地区画の都市計画計画をユーザーに発行します。部門内にはいくつかの地域区分があり、その一部はそのようなサービスをまったく提供していません。ポータルユーザーが、サービスのアプリケーションを作成するときに、サービスを提供しないユニットを示したとします。この状況は、次の2つの理由で発生する可能性があります。
- ポータルの参照データとサプライヤの間に不一致がありました。
- 必要な一致は、サプライヤのシステム設定では利用できません。
いずれの場合も、プロバイダーは要求に応答して、受信側が要求が失敗したことを理解し、場合によってはアクションを実行できるようにする必要があります。このような要求への応答は、拒否の理由に関する情報を含む特別なデータパケットで行われます。
正常な応答は、サービスの結果がファイルのセットであるシナリオを想定しています（これは非常に一般的です）。結果を送信する前に、FTPサーバーに基づいてSMEVファイルストレージにファイルをアップロードする必要があります。ファイル名とそのチェックサムは、SOAPを介して送信されるパケットに取り込む必要があります。したがって、共通のコンテキストでリンクする必要がある2つのデータ転送操作（ファイル情報）があります。
実際には、対話中にSMEVがサービスモードになり、参加者の要求が失敗であることが判明し、再送信が必要になる場合があります。失敗を記録し、要求を再送信する必要があります。
問題の定式化
上記の機能を考慮して、私たちのチームは、ユニバーサルタイプの情報によって顧客のISと「Gosuslugi」の統合を確実にする必要がありました。顧客の情報システム-IAS「Gradostroystvo」。その助けを借りて、サービスの提供を担当する部門のユーザーは、ドキュメントのパッケージを収集し、SMEVを介してポータルにさらに送信するための結果を生成できます。
したがって、SMEVは、曲の単語についての発言のように、公共サービスのポータルとの統合の問題の解決から除外することはできません。しかし、これは最善です。システムのおかげで、すべての参加者は普遍的な相互作用環境を持っています。これにより、特定の標準に依存し、車輪を再発明する必要がなくなります。
次の記事では、情報プロバイダー側で、Workflow Coreビジネスプロセス自動化エンジンを使用して、ユーザーデータに従ってステートメントの処理を整理する方法について説明します。