... | ... | @@ -6,28 +6,6 @@ Modul ini merupakan salah satu bagian dari sistem CAPI-STIS. Aplikasi CAPI-STIS |
|
|
Modul revalidasi atau validasi bertingkat adalah modul yang dikerjakan oleh penulis. Pada modul ini akan diselesaikan beberapa permasalahan dalam penerapan Open Data Kit (ODK) pada bisnis proses BPS untuk menerapkan revalidasi atau validasi bertingkat pada ODK. Permasalahan pertama adalah pada ODK belum terdapat kelompok pengguna, berbeda dengan bisnis proses BPS biasanya ada beberap kelompok pengguna misalnya: Petugas Cacah Langangan (PCL), Petugas Monitoring Lapangan (PML), Kordinator Tim (Kortim), dll. Permasalahan kedua adalah tidak ada perbedaan aturan kuesioner untuk kelompok pengguna yang berbeda, misalnya ada isian yang dituju untuk PCL dan ada juga isian yang dituju untuk PML. Permasalahan ketiga adalah pada Open Data Kit belum terdapat fungsi pembaruan data, berbeda dengan pada bisnis proses BPS dimana PML/ Kortim hanya dapat memperbarui isian dari PCL. Permasalah keempat adalah belum ada sistem notifikasi/ pemberitahuan sebagai pendukung modul revalidasi atau validasi bertingkat.
|
|
|
Modul revalidasi atau validasi bertingkat yang dibuat oleh penulis diimplemtasikan kedalam empat buah aplikasi diantaranya :
|
|
|
|
|
|
### Rancangan Arsitektur
|
|
|
Modul validasi bertingkat merupakan sistem berbasis android dan web dengan megimplementasikan sistem ODK. Yang kemudian modul validasi bertingkat ini untuk diintegrasikan pada CAPI-STIS. Modul validasi bertingkat ini terdiri dari 4 aplikasi yang saling berintegrasi, keempat aplikasi ini adalah konverter xlsform menjadi xform, aplikasi ODK Collect/ klien, ODK Aggregate, dan server Notifikasi. Rancangan arsitektur sistem dapat dilihat dari 3 proses dibawah ini. Pada gambar terlihat bahwa tulisan yang berwarna hitam adalah fungsi yang telah ada pada ODK sebelum dilakukan penambahan modul validasi bertingkat dan warna merah adalah fungsi tambahan yang ditambahkan dalam modul validasi bertingkat. Berikut adalah 3 proses tersebut:
|
|
|
|
|
|
- Proses pembuatan dan pengunggahan xform
|
|
|
![Rancangan_Arsitektur_Part1_1_](/uploads/2bd09519dd50b6534e9ed07f7f3ac175/Rancangan_Arsitektur_Part1_1_.jpg)
|
|
|
|
|
|
Pada Gambar di atas, digambarkan arsitektur sistem mengenai pembuatan, pengunggahan xform, dan pengunduhan xform. Awalnya kuesioner dibuat dalam bentuk xlsform dengan format yang telah disesuaikan dengan modul validasi bertingkat. Setelah xlsform selesai maka xlsform diproses pada aplikasi konverter (flow 1). Hasil dari proses konverter adalah xform (flow 2). Xform ini kemudian diunggah ke ODK Aggregate (flow 3). Lalu jika ODK Collect ingin melakukan pencacahan maka ODK Collect tinggal melakukan pengunduhan xform dengan meminta ke ODK Aggregate (flow 4).
|
|
|
- Proses penyetoran data
|
|
|
![Rancangan_Arsitektur_Part2_1_](/uploads/ae979986bc7ce2411831f1797a05598b/Rancangan_Arsitektur_Part2_1_.jpg)
|
|
|
|
|
|
Pada Gambar di atas dijelaskan mengenai asitektur sistem usulan mengenai proses yang terjadi saat penyetoran data. Pada saat pencacah selesai melakukan pencacahan, maka pencacah dapat melakukan menyetoran data ke server ODK Aggregate (flow 5). Saat penyetoran data selesai ODK Aggregate menjalankan fungsi external service. Proses external service yang digunakan adalah external service yang tujuannya adalah server notifikasi (flow 6). Setelah data isian (berbentuk json) hasil external service Aggregate diterima oleh server notifikasi maka server notifikasi akan bertanya kepada Aggregate siapa yang berhak menerima notifikasi/ pemberitahuan mengenai penyetoran data ini (flow 7). Setelah server notifikasi menerima penerima notifiasi dari ODK Aggregtae maka Server notifikasi mengirim firebase notification message (fcm) ke ODK Collect penerima notifikasi (flow 8).
|
|
|
- Proses pembaruan data
|
|
|
![Rancangan_Arsitektur_Part3_1_](/uploads/e23668f7599529db0684015d8929f169/Rancangan_Arsitektur_Part3_1_.jpg)
|
|
|
|
|
|
Pada Gambar 52 menjelaskan mengenai arsitektur sistem usulan pembaruan data. Pada saat pengawas menerima notifikasi dari server notifikasi (pada arsitektur sebelumnya) pengawas terlebih dahulu harus mengunduh data isian dari ODK Aggregate (flow 9). Setelah mendapatkan isian maka pengawan akan melakukan pengecekan dan pengawasan isian. Setelah melakukan pengecekan dan pengawasan isian maka pengawas dapat memperbarui isian yang ada pada ODK Aggregate (flow 10). Saat isian diperbarui maka external service juga akan berjalan seperti sebelumnya. External service kemudian mengirim isian (dalam bentuk json) ke server notifikasi (flow 11). Setelah data external service diterima pada server notifikasi maka server notifikasi akan menanyakan ke Aggregate siapa yang berhak mengetahui bahwa isian tersebut telah diperbarui (flow 12). Setelah menerima penerima notifikasi maka server notifikasi akan mengirim firebase notification message (fcm) ke ODK Collect penerima.
|
|
|
|
|
|
### Rancangan basis data
|
|
|
|
|
|
Pada Basis Data ODK Aggregate diberikan pemodelan Entitty Rational Diagram, pada diagram ERD ini hanya ditampilkan tabel yang diubah atau ditampilkan dari basis data asli ODK Aggregate. Adapun perubahan atau penambahan tabel pada ODK Aggregate dapat dilihat sebagai berikut sebagai berikut:
|
|
|
|
|
|
![DatabaseODK_4](/uploads/a0c6f54032bd05fdeab2f2da01ce2501/DatabaseODK_4.jpg)
|
|
|
|
|
|
### Dependencies
|
|
|
|
|
|
### Instruksi Penggunaan |
|
|
\ No newline at end of file |