Dalam serangkaian artikel, kami, tim Pengembangan Permata, akan berbicara tentang bekerja dengan "Gosuslugi" di sisi lain layar dan bagaimana mengatur interaksi yang efektif antara badan pemerintah dengan portal.
Skema umum interaksi melalui SMEV
Peserta interaksi
Bayangkan "Gosuslugi" adalah toko yang menampilkan layanan untuk warga dan organisasi. Permintaan "pembeli" untuk suatu layanan dikirimkan ke otoritas terkait melalui sistem interaksi elektronik antar departemen (SMEV). Sistem mentransfer pesan antara portal dan departemen.
Pekerjaan melalui SMEV dilakukan dengan menggunakan protokol SOAP ( Simple Object Access Protocol - protokol sederhana untuk mengakses objek).
Peserta dalam interaksi, seperti di toko, dibagi menjadi pemasok dan konsumen. Pemasok adalah sistem informasi (SI) yang memberikan informasi atas permintaan, dan konsumen adalah sistem yang meminta informasi.
Satu dan IS yang sama dapat bertindak dalam dua peran sekaligus. Misalnya, dalam proses menyediakan layanan, Anda perlu memberi tahu portal tentang perubahan statusnya. Dalam hal ini, pemasok-IS berperan sebagai konsumen - ia melakukan pertukaran informasi berdasarkan status.
Jenis informasi
Peserta bertukar data melalui jenis informasi ( protokol pertukaran ) - aturan untuk pembentukan paket data untuk transmisi dari satu peserta ke peserta lainnya.
Contoh bagus dari jenis informasi tersebut adalah Sensus Penduduk Seluruh Rusia 2020 . Data sensus dikirimkan ke otoritas eksekutif federal dalam bentuk elektronik. Dalam data yang diterima, terdapat struktur informasi yang jelas: nama, jenis kelamin, tanggal lahir, kewarganegaraan, status perkawinan. Juga, dalam kerangka jenis informasi, tanggapan dijelaskan yang harus diterima jika pemrosesan permintaan berhasil.
Pada Juni 2020, lebih dari 1000 industri (pekerja) dan 2000 spesies uji telah terdaftar di SMEV.
Pertukaran data di lingkungan industri untuk semua jenis informasi dilakukan melalui saluran komunikasi yang aman. Semua data yang dikirimkan disertai dengan tanda tangan digital elektronik, dengan bantuan SMEV mengidentifikasi peserta dalam interaksi.
Data ditransmisikan melalui SOAP, dengan setiap pesan menjadi struktur bersarang:
Jenis informasi dibagi menjadi dua kelompok - sederhana dan universal . Pertimbangkan skema pertukaran data untuk jenis informasi sederhana:
Diagram menunjukkan bahwa data formulir ditampilkan langsung di amplop pertukaran data. Karena itu, muncul batasan: perlu untuk mengembangkan struktur blok data, permintaan / respons untuk setiap jenis informasi tersebut.
Pertukaran dengan jenis informasi universal dapat direpresentasikan sebagai berikut:
Sekilas, skema ini mungkin tampak lebih rumit, tetapi menunjukkan perbedaan mendasar, yang pada akhirnya menyederhanakan interaksi antara peserta dalam tipe informasi universal (UDS). Data formulir khusus dikirim dalam lampiran pada amplop SMEV, dan tanda UMC, yang memungkinkan pengidentifikasian jenis informasi, dikirim langsung di dalam amplop dan memiliki struktur yang sama untuk pesawat apa pun:
- Nomor aplikasi portal dan informasi yang memungkinkan untuk mengidentifikasi layanan;
- unit target tempat pengguna mengajukan layanan.
Data formulir yang diisi oleh pengguna portal dikemas dalam lampiran ke pesan utama.
Dengan demikian, Anda dapat memformalkan penyediaan hampir semua layanan tanpa harus melalui pendaftaran jenis informasi baru yang sulit.
Antrian pesan dan proses komunikasi
Selama komunikasi, pesan ditempatkan dalam antrian permintaan masuk dan antrian respon yang masuk . Intinya, antrian adalah wadah yang berisi pesan menurut jenis informasi.
Interaksi dengan antrian terjadi menggunakan permintaan khusus. Mereka dijelaskan lebih rinci dalam pedoman untuk bekerja dengan SMEV. Kami hanya mencatat bahwa berkat antrian, pertukaran data asinkron menjadi mungkin: konsumen dapat meninggalkan permintaan informasi, dan penyedia dapat mengirim tanggapan.
Ingat: untuk mengambil pesan dari antrian, Anda harus mengonfirmasi penerimaan dengan permintaan Ack. Jika tidak, SMEV akan menganggap pesan tidak terkirim dan akan mengembalikannya ke antrean 15 menit setelah pengambilan.
Setiap permintaan dapat menerima respons berhasil atau tidak berhasil.
Bayangkan diri kita sendiri berperan sebagai penyedia informasi: atas permintaan, kami mengeluarkan pengguna dengan rencana tata kota sebidang tanah, dan di dalam departemen kami ada beberapa divisi teritorial, beberapa di antaranya tidak menyediakan layanan seperti itu sama sekali. Misalkan pengguna portal, saat membentuk aplikasi untuk layanan, menunjukkan unit yang tidak menyediakan layanan. Situasi ini dapat muncul karena dua alasan:
- Ada ketidaksesuaian antara data referensi di portal dan pemasok;
- Kecocokan yang diperlukan sama sekali tidak tersedia di pengaturan sistem pemasok.
Dalam kedua kasus tersebut, penyedia harus menanggapi permintaan tersebut sehingga pihak penerima dapat memahami bahwa permintaan tersebut gagal dan mungkin mengambil tindakan. Tanggapan atas permintaan tersebut dibuat dalam paket data khusus dengan informasi tentang alasan penolakan.
Respons yang berhasil mengasumsikan skenario di mana hasil layanan berupa sekumpulan file (yang cukup umum). Sebelum mengirimkan hasilnya, file harus diunggah ke penyimpanan file SMEV berdasarkan server FTP. Nama file dan checksumnya harus disimpan dalam paket yang dikirim melalui SOAP. Dengan demikian, ada dua operasi transfer data yang perlu dihubungkan dengan konteks umum - informasi file.
Dalam praktiknya, ada kasus ketika, selama interaksi, SMEV dalam mode layanan, dan permintaan peserta ternyata gagal dan perlu dikirim ulang. Kegagalan harus dicatat dan permintaan harus dikirim kembali.
Rumusan masalah
Dengan mempertimbangkan fitur-fitur di atas, tim kami harus memastikan integrasi IS pelanggan dengan "Gosuslugi" melalui jenis informasi universal . Sistem informasi pelanggan - IAS "Gradostroystvo" . Dengan bantuannya, pengguna dari departemen yang bertanggung jawab atas penyediaan layanan dapat mengumpulkan paket dokumen dan menghasilkan hasil untuk transmisi lebih lanjut ke portal melalui SMEV.
Jadi, SMEV, seperti pepatah tentang kata-kata dalam lagu tersebut, tidak bisa lepas dari solusi masalah integrasi dengan portal layanan publik. Tapi ini yang terbaik: berkat sistemnya, semua peserta memiliki lingkungan interaksi universal. Ini memungkinkan Anda untuk mengandalkan standar tertentu dan tidak menemukan kembali roda.
Di artikel berikutnya, kita akan melihat bagaimana, di sisi penyedia informasi, mengatur pemrosesan pernyataan berdasarkan data pengguna menggunakan mesin otomatisasi proses bisnis Inti Alur Kerja.