THE PROTOCOL BUFFER AS DATA COMMUNICATION MEDIA ELECTRONIC SERVICES MANUSCRIPT SYSTEM

PROTOKOL BUFFER SEBAGAI MEDIA KOMUNIKASI DATA TATA NASKAH DINAS ELEKTRONIK

Ovan Sunarto Pulu ST., MMSI ovan@staff.gunadarma.ac.id

Manajemen Sistem Informasi Universitas Gunadarma Jl. Margonda Raya No. 100, Depok 16424, Jawa Barat

Abstrak

Protocol buffer (Protobuf) adalah sebuah metode serialisasi struktur data. Pemanfaatannya sebagai media komunikasi data sangat penting mengingat evolusi data atau perkembangan data yang terus-menerus terjadi, sehingga sangat krusial untuk dapat melakukan distribusi data secara lengkap dan detail pada sistem eksternal. Jika dibandingkan dengan metode komunikasi data yang lain seperti JSON, protobuf memiliki beberapa keunggulan yang jauh lebih baik seperti kompresi data secara otomatis, data yang diakses bisa mempunyai tipe data yang jelas, ketersediaan dokumentasi maupun adanya metadata pada skemanya. Sistem Tata Naskah Dinas Elektronik berusaha memanfaatkan kelebihan protobuf tersebut untuk mendorong efektifitas komunikasi data dalam mengelola naskah dinas dengan mengimplementasikan bahasa pemrograman Go sebagai gRPC server dan bahasa pemrograman PHP sebagai gRPC Stub.

Kata Kunci : Protocol buffer, gRPC

THE PROTOCOL BUFFER AS DATA COMMUNICATION MEDIA ELECTRONIC SERVICES MANUSCRIPT SYSTEM

Abstract

The protocol buffer (Protobuf) is a method of serializing data structure. Its usage as a data communication medium is very important considering the evolution of data, constant data changes, therefore it is crucial to carry out complete and detailed data distribution on the external system. When compared with existing communication methods such as JSON, protobuf has several superior advantages such as automatic data compression, the data being accessed have clear data type, availability of documentation and metadata in the scheme. The Electronic Service Manuscript System is trying to utilize the advantages of the protobuf to improve the effectiveness of data communication in managing official scripts by implementing the Go programming language as a gRPC server and the PHP programming language as a gRPC Stub.

Keywords: protocol buffer, gRPC

PENDAHULUAN

Dalam sebuah institusi terlebih pemerintahan hampir sudah pasti mempunyai naskah dinas dalam prakteknya baik secara offline maupun online. Naskah dinas ini bisa berupa surat masuk, surat keluar, memo, surat tugas, dll. Naskah ini dimaksudkan untuk berbagai keperluan internal maupun eksternal dari institusi tersebut baik itu sebagai penugasan maupun hanya sekedar pemberitahuan secara tertulis pada pihak tertentu sebagai komunikasi kedinasan. Berbagai macam kebutuhan dari fungsi ini mendorong adanya pertumbuhan data yang cukup signifikan besar yang berdampak langsung pada cara memanajemen data tersebut menjadi cukup kompleks dan hal ini bisa diperparah jika tidak ditunjang dengan infrastruktur yang cukup memadai.

Tata Naskah Dinas Elektronik (TNDE) adalah sebuah sistem manajemen naskah dinas yang diharapkan bisa menangani fleksibilitas dari berbagai kebutuhan penggunanya karena setiap institusi pasti mempunyai pedoman yang berbeda tentang penggunaan sistem ini seperti format naskah, layout hingga dengan hak akses. Dengan adanya tantangan ini fokus utama sistem ini harus bisa mengedepankan keluwesan dalam kustomisasi yang harus sejalan dengan kemampuannya dalam menangani beban data yang semakin bertambah sehingga menjadi penting untuk memperhatikan bagaimana sistem ini bisa bekerja dengan baik, dari sisi teknis harus bisa menerapkan berbagai perangkat maupun bahasa pemrograman yang sesuai.

Fokus utama dalam penelitian ini adalah bagaimana memaksimalkan penggunaan protocol buffer sebagai media komunikasi dalam pertukaran data. Distribusi data yang semakin cepat dan lengkap akan mendorong sistem ini bisa bekerja dengan sangat baik serta memudahkan dalam melakukan peningkatan sistem kedepannya dikarenakan sistem ini menggunakan mekanisme modular untuk setiap fitur yang digunakan. Protocol buffer menggunakan basis Remote Procedure Call (RPC) yang dicustom oleh sebuah perusahaan web raksasa yaitu google sebagai inisiatornya, karena menggunakan konsep yang mirip dengan RPC maka komunikasi data bisa lebih cepat sebagaimana proses kerja RPC yang langsung berinteraksi machine to machine METODE PENELITIAN

Application Programming Interface (API) memungkinkan adanya pertukaran data antar program dengan sangat fleksibel tanpa dibatasi oleh faktor bahasa pemrograman. salah satu metode komunikasi data ini adalah dengan menggunakan Protocol Buffer (protobuf) yang diinisiasi oleh Google pada tahun 2001 untuk keperluan sistem internalnya, kemudian pada tahun 2008 dirilis untuk public di bawah lisensi open source sehingga bisa dipergunakan oleh siapa saja. Protobuf melibatkan bahasa deskripsi antarmuka yang menggambarkan struktur data dan program untuk menghasilkan kode sumber dari deskripsi tersebut dalam melakukan komunikasi data. Struktur data dideskripsikan dalam bentuk file .proto dan dikompilasi dengan protoc ke dalam beberapa format bahasa pemrograman seperti Go, Java, Python dan bahasa pemrograman yang lain sehingga memudahkan para pengembang program untuk bisa melakukan integrasi.

Google membuat gRPC untuk memudahkan pemanfaatan fungsi-fungsi RPC dengan menggunakan protobuf. gRPC ada dua sisi yaitu sisi server dan client. Sisi server digunakan untuk menerima, memproses dan memberikan respon dari dan ke client sedangkan sisi client bertugas untuk mengirim dan menerima pesan dari server. Dalam penelitian ini menggunakan bahasa pemrograman Go sebagai gRPC Server dan bahasa pemrograman PHP untuk gRPC Stub.

Integrasi data pada sistem ini diuji coba dengan menggunakan salah satu sistem eksternal. Sistem

eksternal ini akan melakukan request data untuk pembuatan naskah maupun menampilkan daftar

naskah elektronik yang ada di dalam sistem TNDE ini dengan memanfaatkan service gRPC yang sudah di generate ke dalam bahasa pemrograman PHP yang berperan sebagai sisi client serta hanya dibatasi pada pengaksesan data salah satu naskah dinas korespondensi yaitu nota dinas atau biasa disingkat nodin.

NASKAH DINAS

Sesuai dengan peraturan Arsip Nasional Republik Indonesia Nomor 7 Tahun 2018 tentang tata naskah dinas dilingkungan Arsip Nasional Republik Indonesia (ANRI) menyatakan bahwa Naskah dinas adalah informasi tertulis sebagai alat komunikasi kedinasan yang dibuat dan diterima oleh pejabat yang berwenang di lingkungan ANRI dalam rangka penyelenggaraan tugas pemerintahan dan pembangunan. Terdapat beberapa jenis naskah dinas yang berlaku seperti Naskah dinas arahan, naskah dinas korespondensi, naskah dinas khusus dan yang lainnya. Salah satu jenis naskah dinas yang akan dibahas secara spesifik dalam penelitian ini adalah jenis naskah dinas korespondensi.

NASKAH DINAS KORESPONDENSI

Mengacu pada peraturan perundangan yang sama khususnya pada pasal 64 menyatakan bahwa Naskah dinas korespondensi terdiri dari Naskah dinas korespondensi intern dan naskah dinas korespondensi ekstern yang kemudian dilanjutkan dengan pasal 65 ayat 1 yang menyatakan bahwa naskah dinas korespondensi intern terdiri atas nota dinas, memorandum, lembar disposisi dan surat undangan intern. Secara spesifik nota dinas merupakan naskah dinas intern yang dibuat dan ditandatangani oleh pejabat yang berwenang berdasarkan lingkup fungsi, tugas, wewenang dan tanggung jawabnya di lingkungan instansi tersebut. Selanjutnya nota dinas dijelaskan lebih detail pada bagian sendiri di pasal 66 sampai dengan pasal 72.

Adapun struktur atau susunan dari nota dinas ini terdiri dari tiga bagian yaitu kepala, batang tubuh dan kaki sesuai dengan yang tertuang dalam pasal 68. Mengacu pada struktur tersebut menjadi dasar untuk penggambaran detail secara teknis sebagai upaya menerjemahkan proses pembuatan nota dinas tersebut kedalam sistem. Sistem bisa melakukan pemrosesan data sesuai dengan data yang diinput oleh penggunanya lewat form yang sudah disediakan berdasarkan acuan tersebut. Adapun entitas yang terdapat pada form tersebut digunakan untuk melakukan input data ke sistem sehingga penggambarannya dapat dideskripsikan seperti yang terlihat pada tabel berikut ini

Tabel Data Naskah Dinas

Nama Field Tipe Data Keterangan

Tanggal Naskah DATE Tanggal pembuatan nodin

Kode Unit Kerja STRING Kode unit kerja sesuai dengan

tujuan dari nodin

Pejabat Penandatangan STRING Nama pejabat penandatangan

nodin

Kepada STRING Nama penerima nodin

Dari STRING Nama pembuat nodin

Tembusan STRING Nama penerima tembusan

nodin

Lampiran FILE File yang berhubungan

dengan nodin

Perihal TEXT Deskripsi perihal tentang

nodin

Isi TEXT Deskripsi lengkap mengenai

nodin tersebut

Dilihat dari komponen field yang ada pada tabel tersebut maka secara spesifik bisa mendeskripsikan bahwa keterlibatan user dalam sistem tersebut terdiri dari beberapa kategori user seperti Pembuat Naskah, Pejabat penandatangan, tujuan naskah sampai dengan tembusan naskah tersebut. dari setiap kategori user tersebut, masing-masing mempunyai fungsi dan hak akses berbeda beda sesuai dengan posisinya. Itulah gambaran umum dari penginputan data pada sistem TNDE tersebut mengacu pada tabel diatas, basis data tersebut yang digunakan dan diolah oleh sistem sehingga bisa menghasilkan suatu output yang sesuai dengan keperluannya. Adapun output yang dimaksud bisa berupa file nodin yang sudah terformat dengan menggunakan format file pdf yang bisa di buka langsung pada aplikasinya atau bisa juga di unduh untuk di cetak secara manual sesuai dengan kebutuhan.

Evolusi Data

Semakin berkembangnya teknologi telah mendorong adanya evolusi data yang terjadi dari waktu ke waktu. berikut ini adalah perjalanan evolusi data yang akan berhubungan erat dengan pembahasan pada bagian selanjutnya.

Comma Separated Values (CSV) ​, yang mempunyai kelebihan seperti : Mudah dalam melakukan parsing data, mudah dibaca dan mudah dipahami. Namun selain dari kelebihan tersebut juga terdapat kekurangan seperti : Tipe data yang tidak bisa terduga, parsing data menjadi lebih rumit jika mengandung karakter koma serta nama kolom bersifat opsional.

Relational Table Definitions, ​seperti pada kebanyakan database relasional, data yang disimpan pada model ini mempunyai kelebihan antara lain : tipe data terjamin, data teralokasi dengan jelas di tabel. namu terdapat kekurangan seperti : data harus seragam, data yang ada di database akan mempunyai definisi data yang berbeda beda untuk setiap database

JSON (Javascript Object Notation) ​, memiliki kelebihan antara lain : Data bisa berupa apa saja

seperti array atau elemen yang berulang, menjadi format umum di dunia web, bisa dibaca dengan

baik oleh hampir sebagian besar bahasa pemrograman serta mudah untuk didistribusi lewat jaringan. adapun kekurangannya adalah : tidak adanya skema data, objek yang dihasilkan bisa menjadi sangat besar kapasitasnya karena terdapat pengulangan field, serta tidak ada komentar maupun metadata yang tersedia.

Protocol Buffers, ​mempunyai kelebihan seperti : Tipe data jelas, data dikompres secara otomatis, terdapat skema (file proto) yang digunakan untuk men generate code dan membaca data, dokumentasi dapat disisipkan di dalam skema, data bisa dibaca oleh berbagai macam bahasa pemrograman, skema data selalu mengalami perkembangan, lebih kecil dan lebih cepat dari XML serta code bisa tergenerate secara otomatis. adapun kekurangannya adalah : Dukungan Protobuf untuk beberapa bahasa pemrograman masih kurang, data tidak bisa dibuka dengan menggunakan text editor karena terkompresi.

gRPC

Menurut Kasun Indrasiri dalam bukunya yang berjudul gRPC Up and Running mengatakan bahwa gRPC adalah teknologi komunikasi antar proses yang memungkinkan kita untuk menghubungkan, meminta, mengoperasikan dan mendistribusikan pengujian aplikasi yang heterogen semudah seperti melakukan pemanggilan pada fungsi lokal. Pernyataan itu memberikan makna bahwa dengan menggunakan gRPC kita bisa membuat komunikasi data antar sistem bisa menjadi lebih cepat dan mudah dibandingkan dengan menggunakan metode yang lain dalam pengaplikasiannya.

Pada prakteknya sebelum membuat aplikasi yang menggunakan gRPC, yang perlu dilakukan adalah mendefinisikan antarmuka layanan yang akan digunakan termasuk mendefinisikan bagaimana layanan itu akan diakses, metode apa yang digunakan untuk berkomunikasi, parameter apa saja yang harus digunakan, format data yang digunakan akan seperti apa ketika menggunakan layanan tersebut dan lain sebagainya. Bahasa yang digunakan dalam pendefinisian layanan ini dikenal dengan nama Interface Definition Language (IDL). Dengan menggunakan bahasa tersebut kita bisa membuat perintah yang dapat berjalan di dua sisi yaitu server dan klien.

Disisi server yang dikenal dengan nama server skeleton yang berfungsi menyederhanakan logika program pada sisi server dengan menerapkan abstraksi komunikasi tingkat rendah serta disamping itu juga kita bisa membuat perintah di sisi klien yang dikenal dengan nama client stub.

Fungsi yang sudah didefinisikan pada IDL tersebut bisa dengan mudah diakses oleh klien secara

remote layaknya mengakses fungsi yang ada di mesin lokal. Framework gRPC menangani semua

kompleksitas yang berkaitan dengan fungsi, serialisasi data, komunikasi jaringan, autentikasi,

akses kontrol dan lain sebagainya. Untuk memahami penerapan konsep gRPC, berikut ini adalah

contoh gambaran skema komunikasi antar service yang menggunakan gRPC.

Gambar Konsep gRPC

Pada gambar konsep gRPC diatas terdapat satu file definisi struktur data yaitu dengan nama NodinDetail.proto. Setiap struktur data yang akan didefinisikan dalam IDL harus dalam bentuk format file .proto karena format inilah yang nantinya akan digunakan untuk men generate server skeleton dan client stub dengan menggunakan perintah protoc. gRPC server pada gambar tersebut menggunakan bahasa pemrograman Go sedangkan gRPC Stub yang ada di sisi klien menggunakan bahasa pemrograman PHP. komunikasi yang terjadi antara gRPC Stub dan gRPC server dilakukan melalui protocol buffer yang berjalan pada HTTP/2 atau generasi ke dua sebagai generasi terbaru. Kedua sisi (Server dan klien) tersebut menggunakan struktur data yang sama dalam pelaksanaanya sehingga jika terjadi perubahan skema pada struktur datanya maka akan mempengaruhi kedua sisi tersebut.

HASIL DAN PEMBAHASAN

Dalam penerapannya, pada sistem ini terdapat dua sistem yang saling berhubungan yaitu client

dan server. sisi client bertindak sebagai consumer yang akan menggunakan data dari TNDE

untuk digunakan sesuai dengan kebutuhannya, sedangkan sisi server adalah sistem TNDE itu

sendiri yang bertugas memanajemen data naskah yang diinput oleh consumer. Berikut ini adalah

diagram alir dari sistem TNDE secara umum.

Gambar Alur Informasi TNDE

Proses dimulai dari sisi client yang melakukan autentikasi ke sistem yang kemudian dilakukan pengecekan di sisi server, semua user yang akan mengakses data di server harus terdaftar pada sistem ini dikarenakan entitas tersebut merupakan hal yang sangat penting dalam kaitannya dengan sebuah naskah dinas. setelah server melakukan verifikasi akun yang diinput tersebut selanjutnya server akan memberikan respon balik ke sisi client untuk memberi tahu status akun tersebut. jika akun tersebut valid maka di sisi client akan diarahkan ke halaman dashboard utama.

di halaman ini terdapat menu yang bisa dipilih yaitu input nota dinas baru atau melihat daftar nota dinas yang sudah pernah dibuat. jika yang dipilih adalah menu input nota dinas maka server akan meminta client untuk mengisi form inputan nota dinas yang sudah didefinisikan sebelumnya secara lengkap karena jika ada bagian yang pengisiannya tidak sesuai maka secara otomatis server akan menolak data yang diinput tersebut sebaliknya jika data isian sudah sesuai dengan format yang diminta maka server akan melakukan penyimpanan data ke database sebagai record baru dengan memberikan data user tersebut sebagai identifikasinya. setelah proses penyimpanan data berhasil dilakukan oleh server selanjutnya server akan memberikan respon balik sebagai informasi dari hasil proses tersebut ke user. selanjutnya jika user memilih untuk melihat daftar nota dinas yang sudah pernah dibuat maka server akan melakukan query data ke database sesuai dengan permintaan dari user tersebut. hasil dari query ini akan dikembalikan ke client dalam bentuk data respon.

Dari pembahasan arus informasi dari diatas, terdapat aktivitas dari sisi user yang selalu

berinteraksi dengan server. Itu sebabnya identifikasi user menjadi penting untuk dipetakan

terlebih dahulu karena setiap data yang masuk ke server akan mempunyai hak akses yang berbeda beda pada setiap aksinya. data yang sama akan berbeda perlakuannya untuk level user yang berbeda, oleh sebab itu penentuan hak akses untuk setiap level tersebut harus dilakukan dengan cermat seperti yang terlihat pada tabel berikut ini:

Tabel User Role

Modul Level Aksi

View Create Update Delete Approve

Input Nodin Staff ✓ ✓ - - -

Sekretaris ✓ ✓ - - -

Pimpinan ✓ ✓ - - ✓

List Nodin Staff ✓ - ✓ ✓ -

Sekretaris ✓ - ✓ ✓ -

Pimpinan ✓ - ✓ ✓ ✓

Pada tabel user role tersebut terdapat tiga level user dalam berinteraksi dengan sistem ini. Ketiga level user tersebut mempunyai hak akses yang berbeda untuk setiap aksinya terhadap modul yang berhubungan. Terdapat dua modul utama untuk pengelolaan data nota dinas ini yaitu modul input Nodin, menu ini digunakan oleh user untuk melakukan input data baru nota dinas ke sistem TNDE dan modul yang kedua adalah List Nodin, menu ini bertujuan untuk memberikan daftar semua nota dinas yang sudah pernah dibuat oleh user tersebut pada sistem TNDE. Berikut akan dijelaskan secara rinci untuk penggunaan kedua modul tersebut.

Modul Input Nodin ​, pada modul ini untuk semua level user (staf, sekretaris, pimpinan) bisa mengakses menunya tanpa ada pembatasan serta bisa langsung membuat data baru nota dinas untuk bisa disimpan ke sistem TNDE, selain itu untuk aksi update dan delete tidak bisa langsung dieksekusi pada modul ini dikarenakan modul ini hanya digunakan untuk menginput data baru saja tanpa bisa mengupdate ataupun menghapus data yang sudah ada, kedua aksi tersebut terpisah dari modul ini dan sudah terdapat di modul list nodin. Selanjutnya untuk role pimpinan, level user ini bisa melakukan aksi approve yang tidak bisa dilakukan oleh level user manapun.

pada level user ini ketika seorang pimpinan membuat data nota dinas baru, dan bisa langsung

melakukan proses simpan dan approve pada satu proses yang sama sedangkan untuk level user

yang lain prosesnya akan secara otomatis hanya untuk simpan data saja, data yang berhasil

disimpan ini secara otomatis akan diarahkan oleh sistem menuju ke tujuan / penerima data

tersebut. Data yang baru diinput oleh user level staff ataupun sekretaris secara otomatis akan

masuk ke dashboard pimpinan terlebih dahulu untuk meminta persetujuan terlebih dahulu,

setelah pimpinan memberikan persetujuan dengan cara memanfaatkan fitur approve pada sistem

tersebut maka sistem akan membawa data tersebut ke penerima yang semestinya sesuai dengan

nama penerima yang tercantum pada form inputan data nota dinas tersebut. namun jika pimpinan

menolak data tersebut maka sistem akan mengembalikan data tersebut ke user staff atau

sekretaris sebagai pembuat data tersebut untuk bisa dilakukan perubahan pada data tersebut

sebelum bisa di submit ulang. Selain melanjutkan data tersebut ke penerima nota dinas tersebut, aksi persetujuan dari pimpinan ini juga akan memicu pengiriman data ke penerima yang lain yang berperan sebagai penerima tembusan nota dinas tersebut, penerima tembusan ini bisa menerima data hanya jika pada form penginputan data juga mencantumkan nama penerima tembusan karena pada bagian tersebut bersifat opsional maka bisa terjadi kemungkinan untuk mengabaikan penerima tembusan untuk data tersebut.

Modul ​List Nodin​, Modul ini digunakan oleh semua level user untuk melihat daftar data nota dinas yang sudah tersimpan di database. semua level user bisa melakukan aksi update maupun delete pada modul ini dengan kondisi aksi tersebut hanya bisa dilakukan pada data yang dibuat sendiri sedangkan untuk data yang tidak dibuat sendiri maka tidak bisa melakukan aksi update maupun delete, karena untuk user dengan level sekretaris dan pimpinan bisa melihat semua pengajuan data nota dinas yang diinput pertama kali oleh user staff sehingga hal tersebut bisa mengakibatkan kerentanan akan konsistensi data tersebut yang bisa memungkinan untuk terhapus maupun berubah. selanjutnya khusus untuk user dengan level pimpinan bisa melakukan approval data nota dinas pada modul ini.

DESAIN INTERFACE

Untuk bisa menguji konektivitas ke sistem TNDE maka harus ada desain interface yang bisa digunakan oleh user untuk melakukan interaksi tersebut, hal ini untuk memudahkan user dalam mengoperasikannya dikarenakan untuk sistem, TNDE sendiri tidak terdapat desain interface yang memadai dikarenakan hanya berupa service yang hanya bisa digunakan oleh program, itu sebabnya tampilan antarmuka ini menjadi sangat penting. Mengacu pada tabel data naskah dinas pada pembahasan sebelumnya maka layout yang disiapkan untuk data input sistem ini adalah seperti yang terlihat pada gambar dibawah ini.

Gambar Form Input Nota Dinas

Pada tampilan form input di atas terdapat tiga bagian yang saling berhubungan, yaitu bagian registrasi nota dinas kemudian bagian kedua adalah upload file dan yang terakhir bagian konfirmasi selesai. Pada bagian pertama user diminta untuk memasukan semua data yang ada pada form tersebut, semua tipe data dalam isian form tersebut mengikuti acuan pada tabel data naskah dinas, seperti pada field tanggal naskah ketika user menginput data di kolom tersebut secara otomatis sistem ajan menampilkan datepicker yang bisa dipilih oleh user, penggunaan datepicker pada kolom yang mengandung tanggal sangat penting dikarenakan format tanggal yang diinput haruslah sama untuk setiap data nota dinas tersebut ini juga memudahkan mapping data ke database yang hanya bisa menerima satu format data penanggalan untuk jenis data yang sama. format data yang digunakan adalah format data standar tanggal untuk database MySQL yaitu YYYY-MM-DD, format tersebut dimulai dari 4 digit tahun kemudian diikuti 2 digit bulan dan terakhir adalah 2 digit tanggal. Pada bagian Pejabat penandatangan, kepada dan tembusan fieldnya berupa droplist yang bisa diinput dengan huruf sesuai dengan tipenya pada aturan tabel sebelumnya, namun secara otomatis sistem akan mengkonversi nama tersebut sesuai dengan id unik dari setiap nama tersebut untuk memudahkan dalam manajemen relasi data di database. dan yang terakhir adalah kolom perihal dan isi yang berupa text editor sehingga memungkunkan user untuk bisa menginputkan karakter yang cukup banyak pada bagian ini.

Pada bagian kedua, terdapat form untuk mengupload file-file yang berhubungan dengan data nota dinas ini. pada prakteknya file yang diupload adalah hasil scan dokumen yang berhubungan dengan nota dinas dimaksud. di bagian ini user bisa melakukan upload file dengan memperhatikan beberapa ketentuan yang menjadi batasan seperti ukuran file, tipe file dan klasifikasi file. User bisa melakukan perubahan (Update, delete) pada file tersebut selama belum melakukan konfirmasi selesai, namun jika sudah melakukan konfirmasi selesai maka secara otomatis sistem akan mengunci semua perubahan pada data tersebut dan langsung mengarahkan pada halaman sukses input data. Setelah data berhasil disimpan maka proses selanjutnya akan mengacu pada tabel user role pada pembahasan sebelumnya untuk menentukan hak akses setiap user pada data tersebut.

Setelah user selesai melakukan input data selanjutnya sistem secara otomatis akan mengarahkan ke halaman daftar nota dinas untuk memudahkan perpindahan user tanpa harus di pilih manual oleh user, seperti yang sudah didefinisikan sebelumnya bahwa data nota dinas yang ditampilkan adalah sesuai dengan level masing-masing maka secara mandiri sistem akan melakukan filter pada proses query data ke database. Berikut ini adalah contoh daftar data nota dinas yang sudah tersimpan di database dan sudah disetujui oleh pimpinan yang bisa dilihat pada kolom status pada data tersebut. Di halaman ini user bisa melakukan aksi update maupun delete serta approve pada data tersebut sesuai dengan hak aksesnya mengacu pada tabel user role. Berikut ini adalah tampilan dari modul daftar nota dinas dimaksud

Gambar Daftar Nota Dinas

Pada gambar daftar nota dinas di atas bisa dilihat bahwa tidak semua field yang ada di form

inputan data nota dinas ada disitu namun di bagian paling kanan terdapat tombol yang salah

satunya untuk melihat data secara lebih lengkap karena di bagian ini hanya berupa daftar secara ringkas untuk merangkum data apa saja yang ada di database. Di Bagian ini terdapat penambahan kolom data baru yaitu Nomor Nodin, field ini akan secara otomatis terbentuk ketika status data sudah di approve oleh pimpinan

DEFINISI LAYANAN

Pembuatan service definition pada gRPC selalu berupa file dengan ekstensi proto. file inilah yang akan digunakan untuk men generate kode ke dalam berbagai macam bahasa program yang digunakan untuk melakukan interaksi dengan server sehingga pembuatan file ini sangat krusial mengingat skema yang terdapat pada file ini akan digunakan secara bersamaan oleh kedua sisi yaitu server dan klien. Berikut ini adalah penggalan proto file yang digunakan oleh layanan nota dinas dengan nama file NotaDinas.proto:

yntax "proto3";

s =

ackage tnde;

p

ption go_package "nodinpb";

o =

File proto yang dibuat untuk service nota dinas ini menggunakan konsep proto3 yang merupakan konsep terakhir pada saat penelitian ini dibuat. kemudian pada baris selanjutnya terdapat pendefinisian nama paket, perintah ini bertujuan untuk memberitahu protoc sebagai code generator untuk mendefinisikan nama paket pada hasil generate kode sesuai dengan nama paket yang sudah ditentukan pada file proto tersebut. Pada bahasa pemrograman Go, hal tersebut akan menjadi penamaan paket dalam file kode sumbernya sedangkan pada bahasa pemrograman PHP nama paket tersebut akan menjadi namespace di kode sumbernya. Selanjutnya terdapat perintah option go package, perintah ini untuk memberitahu protoc bahwa penamaan paket pada kode sumber hasil generate untuk bahasa pemrograman Go menggunakan nama paket pada perintah tersebut dan perintah itu hanya berlaku untuk kode sumber bahasa pemrograman Go saja tidak berlaku untuk kode sumber bahasa pemrograman yang lain. Hasil dari generate file tersebut ke kode sumber Go akan terlihat seperti dibawah ini

ackage nodinpb p

mport ( i

roto "github.com/golang/protobuf/proto"

p

rotoimpl "google.golang.org/protobuf/runtime/protoimpl"

p

… )

Kode sumber tersebut secara otomatis di generate dan akan mempunyai nama yang mirip dengan file protonya. pada dasarnya protoc akan memberikan penambahan kata pb pada akhir dari filenya sehingga menjadi NotaDinas.pb.go untuk kode sumber bahasa pemrograman Go. Kode program Go menggunakan library proto untuk bisa mengeksekusi prosedur yang sudah terbentuk tersebut sehingga pada penggalan kode diatas dilakukan proses import library yang dibutuhkan oleh program tersebut.

Sedangkan untuk hasil generate kode sumber tersebut ke dalam bahasa pemrograman PHP secara

struktur file akan terlihat seperti pada gambar berikut ini

Gambar Kode sumber PHP

Pada gambar kode sumber PHP tersebut terlihat bahwa hasil generate kode oleh protoc bukan hanya menghasilkan satu file seperti yang terdapat pada bahasa pemrograman Go namun membuat struktur file tersendiri. Struktur file ini secara otomatis terbentuk karena mengikuti skema yang sudah didefinisikan sebelumnya pada file proto. Pada file proto terdapat definisi package, maka ketika diterjemahkan ke dalam struktur pemrograman PHP ternyata nama package tersebut menjadi nama folder dengan nama Tnde yang didalamnya terdapat file dan folder yang lain. Didalam folder Tnde terdapat dua file dengan nama NotaDinas.php yang berisi fungsi-fungsi utama pada proses pemanggilan data nota dinas dan yang kedua adalah file NotaDinas_Date.php yang berfungsi untuk mengkonversi format tanggal pada fungsi utama, namun kode sumber tersebut tidak akan digunakan lagi untuk rilis berikutnya karena telah digantikan oleh file Date.php yang ada di folder NotaDinas.

Selanjutnya untuk bisa mengakses prosedur yang sudah didefinisikan maka pada file proto terdapat definisi data apa saja yang akan tersedia untuk bisa diakses, seperti yang terlihat pada gambar berikut ini

Gambar Skema Proto Nota Dinas

Pada gambar diatas terdapat pendefinisian nama message, pada protocol buffer kita

mendefinisikan message apa saja yang akan diterapkan. skema data dimulai dari id sampai

dengan isi, skema data id menggunakan tipe data integer untuk menampung datanya dan diberi

tag dengan angka 1. Nomor tag pada skema diatas digunakan oleh protocol buffer untuk

mengidentifikasi data, karena protocol buffer tidak menggunakan nama field sebagai

identifikasinya namun untuk nama field tersebut digunakan oleh program dalam kode sumber

yang dihasilkan. Pendefinisian tag ini harus memperhatikan aturan yang sudah ditetapkan seperti

tag 1 sampai 15 menggunakan 1 byte untuk encoding jadi sebaiknya untuk data yang mempunyai

frekuensi sering digunakan sebaiknya menggunakan tag yang ada di antara angka ini saja dan

yang berikutnya adalah tidak boleh menggunakan tag nomor 19000 sampai dengan 19999 karena

nomor tag pada jangkauan tersebut sudah digunakan oleh Google untuk keperluan khusus.

Selanjutnya pada baris berikutnya pendefinisian tanggal dengan tipe data Date dan mempunyai nomor tag 2. Dikarenakan skema pada file proto tidak mendukung tipe data tanggal yang bisa digunakan secara langsung maka sebaiknya tipe data ini dijabarkan lagi secara spesifik pada message yang baru. Tipe data Date ini menjadi message tersendiri untuk menjabarkan data apa saja yang ada di dalam tipe tersebut, pada bagian bawah kode diatas terdapat definisi message dengan nama Date yang isinya terdapat tiga field data yaitu year, month dan day. Definisi data yang seperti inilah yang membuat hasil dari proses generate ke bahasa pemrograman PHP bisa menjadi file terpisah karena dianggap sebagai sub fungsi tersendiri pada prakteknya.

Setelah skema data pada file proto sudah tersedia maka yang harus dilakukan selanjutnya adalah menjalankan proses generate dengan menggunakan perintah protoc untuk menghasilkan kedua output tersebut yaitu kode sumber Go dan kode sumber PHP. Perintah yang digunakan adalah sebagai berikut :

Bentuk umum : ​protoc [OPTION] proto_files Untuk men generate file Go perintahnya akan menjadi seperti ini

$ protoc --go_out=. NotaDinas.proto

Sedangkan untuk men generate kode sumber PHP perintahnya akan menjadi seperti ini

$ protoc --php_out=. NotaDinas.proto

Setelah perintah tersebut dijalankan maka secara otomatis akan terbentuk file baru untuk masing - masing bahasa pemrograman tersebut.

Kode sumber dalam bahasa Go berperan sebagai gRPC server maka harus menyediakan program utama yang digunakan untuk memproses data ke maupun dari database untuk dilanjutkan ke protobuf. Pemanggilan prosedur protobuf ini dilakukan di dalam fungsi main() pada kode sumber program Go tersebut.

KESIMPULAN DAN SARAN

Pemanfaatan protocol buffer untuk media komunikasi data memang sangat penting untuk mengantisipasi perubahan data yang sangat dinamis sehingga implementasi pada sistem pengarsipan naskah dinas ini bisa diperluas ke modul yang lain, karena pada penelitian ini hanya spesifik pada naskah dinas korespondensi lebih khusus lagi nota dinas. Fokus penelitian ini berdasarkan asumsi bahwa semakin tinggi pertumbuhan data maka akan memberikan dampak pada melemahnya proses komunikasi data pada sistem tersebut. Dan asumsi itu bisa terjawab dengan adanya penerapan gRPC pada sisi server sistem untuk mengurangi beban kerja ketika sedang melakukan pertukaran data, namun yang perlu dipertimbangkan lebih lanjut adalah seberapa penting akses data arsip ini dibutuhkan oleh sistem eksternal karena kalau hanya menjadi kebutuhan internal salah satu instansi tersebut sepertinya dirasa kurang sesuai dengan penerapan metode yang digunakan ini berhubung secara prinsip protocol buffer ini untuk mengantisipasi pertukaran data yang cukup cepat dan sering.

DAFTAR PUSTAKA

[1] Indrasiri, K., dan Danesh Karuppu. 2020. gRPC Up and Running : Building cloud native

application with Go and Java for Docker and Kubernetes. O'reilly.

[2] ANRI, Peraturan Arsip Nasional Republik Indonesia tentang Tata Naskah Dinas di

Lingkungan Arsip Nasional Republik Indonesia .

https://jdih.anri.go.id/peraturan/Perka_7_2018_Perka_Tata_Naskah_DInas.pdf [3] Blokdyk, G. 2018. Protocol Buffers A Complete Guide (Kindle Edition).

[4] Protocol Buffer Documentation

https://developers.google.com/protocol-buffers [5] Konsumer, D. 2018. Practical gRPC. O’reilly

[6] Dasar pemrograman Golang. https://dasarpemrogramangolang.novalagung.com