1 SISTEM INFORMASI PEMBIBITAN KELAPA SAWIT BERBASIS RESOURCE-ORIENTED ARCHITECTURE (ROA) STUDI KASUS PT. SASARAN EHSAN MEKARSARI IMAM ABU DAUD SEKOLAH...
SISTEM INFORMASI PEMBIBITAN KELAPA SAWIT BERBASIS RESOURCE-ORIENTED ARCHITECTURE (ROA) STUDI KASUS PT. SASARAN EHSAN MEKARSARI
IMAM ABU DAUD
SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR BOGOR 2013
i! !
ii
!
ii !
!
iii
PERNYATAAN MENGENAI TESIS DAN SUMBER INFORMASI Dengan ini saya menyatakan bahwa tesis Sistem Informasi Pembibitan Kelapa Sawit Berbasis Resource-Oriented Architecture (ROA) Studi Kasus PT. Sasaran Ehsan Mekarsari adalah karya saya dengan arahan dari komisi pembimbing dan belum diajukan dalam bentuk apa pun kepada perguruan tinggi manapun. Sumber informasi yang berasal atau dikutip dari karya yang diterbitkan maupun tidak diterbitkan dari penulis lain telah disebutkan dalam teks dan dicantumkan dalam Daftar Pustaka di bagian akhit tesis ini. Bogor, Februari 2013
Imam Abu Daud NIM G651100121
iii !
iv !
iv !
!
v
ABSTRACT IMAM ABU DAUD. Oil Palm Nursery Information System based on Resourceoriented Architecture (ROA) case study PT. Sasaran Ehsan Mekarsari. Supervised by SRI NURDIATI and YANDRA ARKEMAN. This research present an application of Resource Oriented Architecture with RESTful web service style at oil palm research station, PT. Sasaran Ehsan Mekarsari. The system consist of two major systems: Nursery Information System (IS) and Geographics Information System (GIS), with each part of the system built with two foundations: back-end and front-end. The experiment resulted that these RESTful design can be applied both at IS and GIS. The web service made Nursery Information System (IS) could cooperate easily with Geographics Information System (GIS) and vice versa to accommodate company needs. Standardized data format made the communication among each system run easier and open the scalability of the system at the future. Keywords: Web service, Resource Oriented Architecture, RESTful, Geographics Information System
v !
vi !
vi !
!
vii
RINGKASAN IMAM ABU DAUD. Sistem Informasi Pembibitan Kelapa Sawit Berbasis Resource-Oriented Architecture (Roa) Studi Kasus Pt. Sasaran Ehsan Mekarsari. Dibimbing oleh SRI NURDIATI dan YANDRA ARKEMAN. PT. Sasaran Ehsan Mekarsari adalah perusahaan yang bergerak di bidang riset dan pembibitan kelapa sawit. Proses bisnis yang terjadi dimulai dari bibit mulai ditanam, dirawat, hingga dipersiapkan untuk diteliti lagi atau dijual ke konsumen. Luasnya areal kebun penelitian menyebabkan kebutuhan akan monitoring terhadap kegiatan yang terjadi di perusahaan harus dilakukan secara remote. Pengembangan sistem harus dilakukan sehingga monitoring secara realtime dan dari manapun dapat dilakukan. Visualisasi terhadap keadaan lapang pun harus dapat dilakukan untuk membantu proses pengambilan keputusan. Visualisasi diwujudkan dalam bentuk Sistem Informasi Geografis (SIG). Upaya pengembangan aplikasi sistem informasi seringkali dilakukan tanpa perencanaan yang baik dan benar, sehingga aplikasi dikembangkan berdasarkan hasil analisis dan disain dari fungsi organisasi secara lokal. Akhirnya banyak terdapat pulau-pulau sistem informasi (SI) dalam organisasi. Keterpisahan ini menyebabkan setiap aplikasi sulit berkomunikasi dengan lainnya sehingga berdampak tidak terintegrasinya data dan informasi yang ada, yang pada akhirnya berakibat pada rendahnya tingkat kertersediaan, konsistensi, dan efektifitas data dan informasi yang ada. Sistem informasi yang beragam memerlukan arsitektur yang mengatur bagaimana aplikasi yang satu dengan yang lainnya dapat saling berkomunikasi dan bertukar data. Representational State Transfer (REST) merupakan salah satu cara untuk mengimplementasikan Resource Oriented Architecture (ROA) sehingga komunikasi antar sistem dapat dilakukan lebih mudah. ROA merupakan bentuk kongkrit dari RESTful web service sebagai salah satu cara untuk memecahkan permasalahan menjadi solusi: komposisi dari URI, HTTP, dan XML yang saling bekerja sama. RESTful web service menerjemahkan operasi Create Read Update Delete (CRUD) terhadap basis data ke dalam interface HTTP berupa POST, GET, PUT, dan DELETE. Setiap entitas pada domain permasalahan dipetakan oleh REST ke dalam bentuk resource yang dalam penelitian ini akan direpresentasikan dalam bentuk XML. PT SEM memiliki divisi perusahaan yaitu: kebun (garden), gudang (warehouse), pabrik (factory), administrasi dan pemasaran (marketing) dan kepegawaian (human resource). Setiap divisi tersebut memiliki fungsi dan proses yang saling terkait. Entitas pada setiap domain tersebut dianalisis sehingga menghasilkan sebanyak 56 entitas. Selanjutnya pemetaan seluruh entitas terhadap Uniform Resource Identifier (URI) resource dilakukan menggunakan template URI {domain}/{resource}/{subresource}/{parameter} sehingga diperoleh sebanyak 75 URI yang menjadi URI resource tersebut. Selanjutnya dirancang interface untuk setiap URI tersebut beserta representasi resource menggunakan XML. Asosiasi antara resource yang satu dan lainnya dirancang menggunakan hypermedia. Sistem yang menggunakan resource ini menjadi back-end SI.
vii !
viii !
Front-end SI akan menjadi titik masuk data ke sistem. Sistem front-end berfungsi menerjemahkan data yang dikirim oleh pengguna ke bentuk representasi yang didukung oleh back-end sistem informasi. Sistem ini juga berfungsi sebaliknya, menerjemahkan representasi dalam bentuk XML ke bentuk yang dapat dimengerti secara langsung oleh pengguna. Sistem dikembangkan menggunakan bahasa pemrograman PHP dengan framework CodeIgniter. Sistem diimplementasikan menggunakan konsep Model View Controller (MVC). Model yang dihasilkan tidak berkomunikasi dengan sistem basis data melainkan dengan REST Application Programming Interface (API) dari back-end sistem informasi. Back-end SIG dikembangkan menggunakan Geoserver dan PostgreSQL. Sistem dapat menampilkan tema-tema: tanaman siap panen, siap polinasi, dan tanaman induk terpilih. Tema tersebut merupakan hasil pengolahan data di backend SI yang dikombinasikan dengan data spasial pada back-end SIG. Peta yang ditampilkan oleh back-end SIG adalah peta statis karena bersumber dari tabel basis data yang terpisah dari back-end sistem informasi. Tampilan peta secara real-time dapat diwujudkan dengan cara melakukan pembaruan terhadap isi dari tabel yang ada di back-end GIS setiap kali peta hendak ditampilkan oleh front-end SIG. Front-end SIG melakukan request terhadap back-end SI sesuai tema yang dimaksud, kemudian sistem ini akan memperbarui isi tabel di back-end SIG. Tabel yang terbaru menyebabkan peta yang dihasilkan oleh back-end SIG menjadi sesuai dengan kondisi lapangan (realtime). Pengujian sistem dilakukan empat tahap: pengujian back-end SI, front-end SI, back-end SIG, dan front-end SIG. Pengujian pada tahap pertama dilakukan menggunakan peramban Google Chrome dengan addon Postman. Pengujian dilakukan untuk menyimulasikan proses komunikasi client-server menggunakan format data XML. Pengujian tahap kedua dilakukan untuk menguji seluruh operasi pembacaan, penyimpanan, dan penghapusan data yang ada pada seluruh domain perusahaan serta keluaran dari peta yang dihasilkan. Pengujian tahap ketiga dilakukan dengan melihat tema peta dengan cara melakukan modifikasi terhadap data lalu melihat hasil yang ditampilkan oleh peta melalui Geoserver. Pengujian terakhir dilakukan dengan membuka peta melalui peramban. Berdasarkan hasil penelitian yang dilakukan, berhasil dibuat sistem informasi yang heterogen yang berkomunikasi satu sama lain. Sistem informasi yang dikembangkan menggunakan REST web service terbukti mempermudah pengembangan dan integrasi komponen sistem yang berjumlah cukup banyak. Sistem informasi geografis yang ada dengan mudah dapat berkomunikasi dengan mengolah data yang ada pada sistem informasi lainnya menggunakan web service tersebut. Penambahan atau pengurangan komponen sistem informasi geografis dapat dilakukan lebih mudah karena keterikatan antara komponen yang rendah. Keterikatan yang rendah tersebut menyebabkan efek yang ditimbulkan menjadi minimal. Penelitian lanjutan dapat dilakukan dengan menambahkan fitur pencarian berdasarkan atribut dari resource dan memanfaatkan model yang telah ada kemudian diimplementasikan penambahan modul baru menggunakan perangkat keras lain seperti smartphone, tablet, dan lain-lain.
SISTEM INFORMASI PEMBIBITAN KELAPA SAWIT BERBASIS RESOURCE-ORIENTED ARCHITECTURE (ROA) STUDI KASUS PT. SASARAN EHSAN MEKARSARI
IMAM ABU DAUD G 651100121
Tesis Sebagai Salah Satu Syarat untuk Melakukan Penelitian dan Penulisan Tesis Guna Memperoleh Gelar Magister Komputer pada Progam Studi Ilmu Komputer
SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR BOGOR 2013
xi !
xii !
! ! ! ! ! ! ! ! ! !
Penguji pada Ujian Tesis :
Sony H. Wijaya, S.Kom., M.Kom.
xii !
!
xiii
xiii !
xiv !
xiv !
!
xv
RIWAYAT Penulis dilahirkan di Bogor pada tanggal 27 Oktober 1985, dari pasangan Bapak Djuanda dan Ibu Sriwati. Penulis merupakan putra kelima dari enam bersaudara. Pada tahun 1998, penulis lulus dari SD Negeri Babakan 3 Bogor, lalu pada tahun yang sama melanjutkan pendidikan di SMP NEGERI 3 Bogor. Pada tahun 2001, penulis lulus dari SLTP dan melanjutkan sekolah di SMU Negeri 1 Bogor hingga tahun 2004. Pada tahun yang sama penulis berkesempatan untuk melanjutkan studinya di Institut Pertanian Bogor (IPB) melalui jalur Undangan Seleksi Masuk IPB (USMI) sebagai mahasiswa S1 Departemen Ilmu Komputer, Fakultas Matematika dan Ilmu Pengetahuan Alam. Pada tahun 2008 Penulis lulus dari S1 Departemen Ilmu Komputer, Fakultas Matematika dan Ilmu Pengetahuan Alam. Pada tahun 2008 – 2012 penulis bekerja sebagai staf Teknologi Informasi di PT. Sasaran Ehsan Mekarsari. Pada tahun 2013 hingga saat tulisan ini dibuat, penulis bekerja sebagai konsultan perangkat lunak di PT. Xsis Mitra Utama.
xv !
xvi !
xvi !
!
xvii
PRAKATA Alhamdulillahi Rabbil ‘alamin, puji dan syukur penulis panjatkan kepada Allah SWT atas segala curahan rahmat dan karunia-Nya sehingga tugas akhir ini dapat diselesaikan. Dalam menyelesaikan tugas akhir ini penulis mendapatkan banyak sekali bantuan, bimbingan dan dorongan dari berbagai pihak. Oleh karena itu, penulis ingin mengucapkan terima kasih kepada semua pihak yang telah membantu dalam penyelesaian tugas akhir ini, antara lain: 1 Kedua orangtua tercinta, bapak Djuanda dan mamah Sri atas segala do’a, kasih sayang, dan dukungannya, 2 Ibu Sri Nurdiati, selaku pembimbing pertama atas bimbingan dan arahannya selama pengerjaan tugas akhir ini, 3 Bapak Yandra Arkeman, selaku pembimbing kedua atas bimbingan dan arahannya selama pengerjaan tugas akhir ini, 4 Bapak Sony Hartono Wijaya, Bapak Wisnu Ananta Kusuma selaku penguji dan pemberi masukan terhadap laporan tugas akhir ini, 5 Bapak Toto Haryanto dan seluruh staff Ilmu Komputer IPB atas bantuan dan motivasinya dalam penyelesaian administrasi, 6 Gibtha Fitri Laxmi atas bantuan, perhatian, dan motivasinya selama pengerjaan tugas akhir ini, 7 Pak Welli, Bu Ira, Mas Lungguh, Pak Totok, Pak Gito, dan seluruh pegawai perusahaan atas kerjasama dan dukungannya, 8 Semua teman seperjuangan Pascasarjana Ilkom 12, Penulis juga mengucapkan terima kasih kepada semua pihak yang telah membantu selama pengerjaan penyelesaian tugas akhir ini yang tidak dapat disebutkan satu-persatu. Semoga penelitian ini dapat memberi manfaat. Bogor, Februari 2013
Imam Abu Daud
xvii !
xviii!
xviii !
!
xix
DAFTAR ISI Halaman DAFTAR GAMBAR ........................................................................................... xxi DAFTAR TABEL .............................................................................................. xxiii DAFTAR LAMPIRAN ....................................................................................... xxv BAB I PENDAHULUAN ....................................................................................... 1 1.1 Latar Belakang ............................................................................................ 1 1.2 Rumusan Permasalahan .............................................................................. 2 1.3 Tujuan Penelitian ........................................................................................ 3 1.4 Manfaat Penelitian ...................................................................................... 3 1.5 Ruang Lingkup Penelitian .......................................................................... 4 BAB II TINJAUAN PUSTAKA ............................................................................. 5 2.1 Resource-oriented Architecture (ROA) ...................................................... 5 2.2 Representational State Transfer (REST) .................................................... 6 2.3 Application state dan Resource State.......................................................... 9 2.4 Hypermedia As The Engine Of Application State (HATEOAS) ................ 9 2.5 Template URI ............................................................................................ 10 2.6 Kode respon HTTP ................................................................................... 11 2.7 HTTP header ............................................................................................ 12 2.8 Uniform Resource Identifier (URI)........................................................... 14 2.9 Web Service............................................................................................... 15 2.10 Kelapa sawit (Elaeis) .............................................................................. 15 2.11 Metode Waterfall .................................................................................... 16 BAB III METODE PENELITIAN........................................................................ 19 3.1 Lokasi Penelitian....................................................................................... 19 3.2 Langkah Penelitian ................................................................................... 19 3.2.1 Studi kebutuhan .................................................................................. 20 3.2.2 Identifikasi masalah ............................................................................ 20 3.2.3 Analisis Kebutuhan Sistem ................................................................ 20 3.2.4 Desain sistem ...................................................................................... 20 3.2.5 Implementasi sistem ........................................................................... 24 3.2.6 Pengujian sistem ................................................................................. 24 xix !
xx !
3.2.7 Dokumentasi ....................................................................................... 25 BAB IV HASIL DAN PEMBAHASAN ............................................................... 27 4.1 Domain permasalahan ............................................................................... 27 4.1.1 Kebun (garden) ................................................................................... 28 4.1.2 Gudang (warehouse) ........................................................................... 30 4.1.3 Pabrik (factory) ................................................................................... 31 4.1.4 Pemasaran dan Administrasi (marketing) ........................................... 33 4.1.5 Kepegawaian (human resources)........................................................ 34 4.2 Analisis kebutuhan .................................................................................... 34 4.2.1 Kebun (garden) ................................................................................... 35 4.2.2 Gudang (warehouse) ........................................................................... 36 4.2.3 Pabrik (factory) ................................................................................... 36 4.2.4 Pemasaran dan Administrasi (marketing) ........................................... 37 4.2.5 Kepegawaian (human resources)........................................................ 37 4.2.6 Direktur ............................................................................................... 38 4.3 Perancangan .............................................................................................. 38 4.3.1 Identifikasi Resource .......................................................................... 38 4.3.2 Pemetaan Resource ............................................................................. 40 4.3.3 Penentuan Uniform Interface .............................................................. 44 4.3.4 Desain representasi yang dikirim ke server ........................................ 45 4.3.5 Format representasi yang dikembalikan dari server ........................... 48 4.3.6 Integrasi resource menggunakan hypermedia .................................... 49 4.3.7 Kode respon dari server ...................................................................... 50 4.4 Implementasi front-end Sistem Informasi (SI).......................................... 52 4.5 Implementasi back-end Sistem Informasi Geografis (SIG) ...................... 53 4.6 Implementasi front-end Sistem Informasi Geografis (SIG) ...................... 54 4.7 Implementasi integrasi sistem ................................................................... 55 4.8 Pengujian Sistem ....................................................................................... 56 BAB V SIMPULAN DAN SARAN ..................................................................... 67 5.1
DAFTAR PUSTAKA ............................................................................................ 69!
xx !
DAFTAR GAMBAR Halaman 1 Representasi photo yang berisi hypermedia jenis link (Allamaraju 2010) ........ 10 2 Catatan respon dari pembacaan resource (Richardson & Ruby 2007) .............. 14 3 Varietas kelapa sawit (Pahan 2010) ................................................................... 16 4 Metodologi pengembangan perangkat lunak waterfall (Sommerville 2010) .... 16 5 Kerangka penelitian ........................................................................................... 19 6 Tahap perancangan back-end sistem informasi (Richardson & Ruby 2007) ..... 21 7 Proses perkecambahan bibit kelapa sawit .......................................................... 31 8 Use case kebutuhan SI pembibitan kelapa sawit ............................................... 35 9 Template pemetaan URI terhadap resource yang ada........................................ 40 10 Rancangan representasi XML untuk dikirim ke server ................................... 45 11 Representasi XML pada resource panen tandan .............................................. 46 12 Ilustrasi request menggunakan POST (pembuatan resource baru).................. 47 13 Ilustrasi request menggunakan GET (pembacaan) .......................................... 47 14 Ilustrasi request menggunakan PUT (pengubahan) ......................................... 47 15 Ilustrasi request menggunakan DELETE (penghapusan) ................................ 48 16 Ilustrasi format representasi hasil pembacaan resource................................... 49 17 Implementasi hypermedia pada representasi resource .................................... 50 18 Front-end sistem informasi sebagai penengah komunikasi ............................. 52 19 Rancangan tampilan back-end sistem informasi .............................................. 53 20 Rancangan tampilan front-end sistem informasi.............................................. 54 21 Proses pembaruan informasi tema peta x ......................................................... 55 22 Arsitektur sistem .............................................................................................. 55 23 Hasil pengujian resource /garden/bunch/1 ...................................................... 57 24 Tampilan peta, (a) peta tanaman terpilih dari basis data asli, (b) salah satu baris telah ditambahkan ................................................................................. 63 xxi! !
xxii !
xxii !
!
xxiii
DAFTAR TABEL Halaman 1 Uniform Resource Interface yang digunakan pada RESTful HTTP (Roth 2012) 7 2 Pemetaan URI di pembibitan (domain: /nursery/*) ..................................... 41 3 Pemetaan URI di pembibitan prenursery (domain: /prenursery/*) ........... 41 4 Pemetaan URI di pembibitan mainnursery (domain: /mainnursery/*) ...... 41 5 Pemetaan URI di kebun (domain: /garden/*) .............................................. 42 6 Pemetaan URI di gudang (domain: /warehouse/*) ...................................... 42 7 Pemetaan URI di pabrik (domain: /factory/*) ............................................. 43 8 Pemetaan URI di pemasaran (domain: /marketing/*) ................................... 43 9 Pemetaan URI di kepegawaian (domain: /hr/*) ............................................ 44 10 Rancangan interface pada komunikasi antara client dan server ...................... 44 11 Struktur tabel panen tandan (tree_harvesting) ................................................. 46 12 Kode respon dari server untuk operasi menggunakan interface GET ............. 50 13 Kode respon dari server untuk operasi menggunakan interface PUT ............. 51 14 Kode respon dari server untuk operasi menggunakan interface POST ........... 51 15 kode respon dari server untuk operasi menggunakan interface DELETE ....... 51 16 Parameter pengujian resource dari garden/bunch/1 ........................................ 57 17 Parameter pengujian pembuatan resource baru dari garden/bunch/................ 58 18 Parameter pengujian penyuntingan resource dari garden/bunch/1 ................. 59 19 Parameter pengujian penghapusan resource dari garden/bunch/1 .................. 60 20 Skenario umum pengujian kode respon pada interface GET........................... 60 21 Skenario umum pengujian kode respon pada interface PUT ........................... 60 22 Skenario umum pengujian kode respon pada interface POST......................... 61 23 Skenario umum pengujian kode respon pada interface DELETE ................... 62
xxiii !
xxiv!
xxiv !
!
xxv
DAFTAR LAMPIRAN Halaman 1 Kegiatan pembibitan di perusahaan ................................................................... 73 2 Diagram domain bisnis di perusahaan ............................................................... 74 3 Rancangan template URI ................................................................................... 80 4 Back-end SI menggunakan Google Chrome (addon Postman).......................... 89 5 Front-end SI ....................................................................................................... 90 6 Back-end SIG menggunakan Geoserver ............................................................ 91 7 Front-end SIG menampilkan tema peta pohon terpilih ..................................... 92
xxv !
xxvi!
xxvi !
BAB I PENDAHULUAN 1.1
Latar Belakang Pemanfaatan teknologi informasi untuk mendukung tercapainya tujuan
bisnis organisasi diwujudkan melalui implementasi aplikasi sistem informasi pada berbagai fungsi organisasi. Upaya pengembangan sistem informasi seringkali dilakukan tanpa perencanaan yang baik dan benar, sehingga aplikasi dikembangkan berdasarkan hasil analisis dan desain dari fungsi organisasi secara lokal. Akhirnya banyak terdapat pulau-pulau sistem informasi dalam organisasi. Keterpisahan ini menyebabkan setiap aplikasi sulit berkomunikasi dengan lainnya sehingga berdampak rendahnya tingkat ketersediaan, konsistensi, dan efektivitas data dan informasi yang ada. Sistem informasi yang beragam memerlukan arsitektur yang mengatur bagaimana aplikasi yang satu dengan yang lainnya dapat saling berkomunikasi dan bertukar data. Resource-oriented Architecture (ROA) merupakan sebuah konsep arsitektur perangkat lunak yang mendefinisikan penggunaan sumberdaya (resources) untuk memenuhi kebutuhan suatu perangkat lunak. Resource ini tidak hanya dapat digunakan oleh sistem yang menaunginya namun dapat digunakan juga oleh sistem lain yang berbeda, sehingga pertukaran informasi atau resource antar sistem relatif lebih mudah diimplementasikan. Representational State Transfer (REST) merupakan salah satu cara untuk mengimplementasikan ROA pada sistem yang beragam supaya lebih mudah beradaptasi dengan perubahan lingkungan yang cepat. Penelitian REST telah dilakukan sebelumnya seperti yang dilakukan oleh Hamad et al. (2010) dan Pautasso et al. (2008). Industri pembibitan dan penelitian bibit kelapa sawit merupakan salah satu perusahaan berskala besar yang memiliki proses operasional yang kompleks. Proses bisnis tersebut membuat aliran informasi harus terus mengalir dari proses hulu hingga hilir, mulai dari penanaman hingga bibit siap dijual, ditambah lagi dengan proses bisnis pendukung lainnya seperti sumber daya manusia, keuangan, pembukuan dan sebagainya. Setiap bagian fungsional dari perusahaan tidak dapat dipisahkan dari bagian lainnya.
1! !
!
2
PT. Sasaran Ehsan Mekarsari adalah perusahaan bersama antara Sasaran Ehsan Utama Sdn Bhd (Malaysia) dan PT Mekar Unggul Sari (Indonesia) yang bergerak di bidang riset dan pembibitan kelapa sawit. Proses bisnis yang terjadi dimulai dari bibit mulai ditanam, dirawat, hingga dipersiapkan untuk diteliti lagi atau dijual ke konsumen. Besarnya jumlah tanaman yang dikelola dan aktivitas yang terjadi di perusahaan menyebabkan besarnya jumlah data yang perlu diolah, sehingga menjadikan kebutuhan akan manajemen data yang baik dan berkesinambungan menjadi suatu keharusan. Luasnya areal kebun penelitian menyebabkan kebutuhan akan monitoring terhadap kegiatan yang terjadi di perusahaan harus dilakukan secara remote. Pengembangan sistem harus dilakukan sehingga monitoring secara real-time dan dari manapun dapat dilakukan. Visualisasi terhadap keadaan lapang pun harus dapat dilakukan untuk membantu proses pengambilan keputusan, visualisasi diwujudkan dalam bentuk Sistem Informasi Geografis (SIG) yang menampilkan hasil pengolahan data dari kegiatan operasional pada Sistem Informasi (SI). 1.2
Rumusan Permasalahan Sebagai pemain baru dalam penelitian bibit kelapa sawit, PT. Sasaran Ehsan
Mekarsari (SEM) telah memiliki sistem informasi yang mengelola data di perusahaan tersebut. Sistem yang ada hanya terbatas pada pengelolaan informasi produksi dan belum menyentuh proses bisnis lainnya, selain itu sistem masih belum berjalan sepenuhnya karena hal-hal berikut ini: 1.
Tingginya perubahan fungsional sistem, tercatat sejak tahun 2009 hingga 2011 sistem telah mengalami tiga kali revisi berkenaan dengan parapihan data tanaman yang ada.
2.
Kebutuhan analisis data yang ada saat ini masih dalam taraf sederhana, potensi akan kebutuhan analisis yang lebih mendalam sangat besar, dengan sistem yang ada saat ini akan sulit untuk pengembangan lebih lanjut.
3.
Jumlah staf pengembang sistem informasi yang terbatas menyebabkan pengembangan sistem dilakukan secara bertahap, begitu pula dengan revisi yang dilakukan terhadap sistem yang sedang berjalan.
!
!
4.
3
Perkembangan teknologi pemrograman dalam beberapa tahun terakhir menyebabkan bahasa permograman yang ada sangat cepat berubah dan tidak sesuai dengan bahasa pemrograman sebelumnya.
1.3
Tujuan Penelitian Penelitian ini bertujuan merancang arsitektur back-end sistem beserta front-
end yang digunakan pada sistem informasi pembibitan kelapa sawit. Arsitektur dirancang berdasarkan konsep Resource-oriented Architecture (ROA) yang diimplementasikan dalam bentuk sistem informasi berbasis Representational State Transfer (REST). Pengembangan sistem informasi dilakukan pula pada front-end sistem yang digunakan untuk menguji fungsionalitas back-end sistem yang ada. Secara lebih detail, tujuan yang hendak dilakukan pada penelitian ini diantaranya: 1. Membangun back-end dan front-end sistem informasi (SI) yang digunakan untuk mengelola data operasional perusahaan. 2. Membangun back-end dan front-end dari sistem informasi geografis (SIG) yang menampilkan beberapa tema peta yang menggambarkan keadaan lapangan. 3. Mengintegrasikan SIG dan SI menggunakan web service. 1.4
Manfaat Penelitian Sistem informasi yang dihasilkan diharapkan dapat memberikan beberapa
manfaat, baik bagi pengembang sistem, pengguna sistem, maupun manajemen. Secara umum, manfaat yang dapat diperoleh diantaranya: 1.
Adanya
sistem
informasi
dan
sistem
informasi
geografis
untuk
mempermudah operasional maupun manajerial perusahaan. 2.
Terintegrasinya aplikasi dari beberapa fungsi perusahaan sehingga efektivitas, efisiensi, dan waktu kerja menjadi lebih optimal.
3.
Revisi atau penambahan terhadap elemen dari sistem dapat dilakukan dengan penuh pertimbangan dan diharapkan dapat memberikan dampak yang minimal terhadap sistem yang sedang berjalan.
4.
Pemeliharaan sistem dapat dilakukan lebih mudah, backup ataupun restore dapat dilakukan dalam kondisi yang terkontrol.
5.
Integrasi dengan perangkat lunak dari luar dapat dilakukan lebih mudah karena menggunakan protokol standar.
!
!
4
6.
Pengembangan sistem untuk media lain seperti tablet atau smartphone lebih mudah dilakukan karena proses bisnis dan penyimpanan data telah tersedia di server.
1.5
Ruang Lingkup Penelitian Penelitian dilakukan dengan mengambil studi kasus pada pembibitan dan
pabrik pengolahan bibit kelapa sawit di PT. SEM. Kebutuhan fungsional yang dicakup terdiri atas fungsi utama pada perusahaan pada bulan Januari 2012. Kebutuhan non fungsional seperti security dan user priviledge tidak diimplementasikan pada penelitian ini. Sistem hanya melakukan operasi CRUD: Create (tulis), Read (baca), Update (sunting), dan Delete (hapus) terhadap basis data yang ada.
!
BAB II TINJAUAN PUSTAKA
2.1
Resource-oriented Architecture (ROA) Resource adalah segala sesuatu yang dapat disimpan pada komputer dan
direpresentasikan dalam bentuk aliran bit: dokumen, record pada basis data, atau hasil akhir dari eksekusi suatu algoritme. Resource akan bermanfaat jika ia memiliki minimal sebuah Uniform Resource Identifier (URI) supaya dapat diakses. ROA merupakan bentuk kongkrit dari RESTful web service sebagai salah satu cara untuk memecahkan permasalahan menjadi solusi: komposisi dari URI, HTTP, dan XML yang saling bekerja sama (Richardson & Ruby 2007). Resource merupakan abstraksi utama pada REST. Resource dapat statis, yang berarti tidak berubah dari waktu ke waktu, atau dapat pula bersifat dinamis yang terus berubah seiring dengan waktu (Roth 2012). ROA memiliki dua buah fitur utama, yaitu addressability dan statelessness. Addressabililty berarti bahwa sebuah aplikasi dikatakan addressable jika aplikasi tersebut menampakkan data yang dimilikinya sebagai suatu resource dan memiliki URI sendiri, misalnya sebuah URI tentang resource jelly fish: http://www.google.com/search?q=jellyfish.
URI yang addressable
memungkinkan pencatatan terhadap URI tersebut sehingga jika akan digunakan lagi, yang perlu dilakukan hanya mengetik URI tersebut pada peramban. Anggap saja website google tidak addressable, maka tidak mungkin menyimpan URI tersebut pada sebuah catatan, sebaliknya harus dilakukan secara manual: membuka peramban, ketik www.google.com di peramban, ketik 'jellyfish' pada kotak pencarian, lalu klik tombol 'Penelusuran Google'. Fitur kedua yaitu statelessness yang berarti bahwa semua request HTTP yang terjadi harus dilakukan dalam keadaan terisolasi. Saat client melakukan request kepada server, maka request tersebut harus berisi semua informasi yang dibutuhkan oleh server untuk memprosesnya lebih lanjut. Server tidak boleh bergantung pada informasi request sebelumnya yang dilakukan oleh client tersebut. Secara praktik hal ini jika dihubungkan dengan sifat addressability, maka berarti bahwa state dari server dapat dijadikan resource dan memiliki URI tersendiri.
5! !
!
6
2.2
Representational State Transfer (REST) Menurut Higashino et al. (2009) web service yang berbasis teknologi SOAP
telah menghasilkan aplikasi pada banyak bidang. SOAP didesain untuk transparansi komunikasi dan keterikatan yang rendah antar aplikasi. SOAP tidak lepas dari kelemahan karena dikritik karena kompleksitas dan spesifikasi yang harus dipenuhi terlalu banyak. Selain itu permasalahan teknis yang terlalu terikat pada satu vendor tertentu menjadikan keterikatan rendah yang tidak dapat terwujud (Pautaso, Zimmermann, Leymann 2008). Representational State Transfer (REST) adalah suatu gaya arsitektur yang bertujuan untuk meminimalkan latensi dan komunikasi jaringan, sementara pada saat yang bersamaan berusaha untuk memaksimalkan independensi dan skalabilitas dari implementasi komponen (Fielding 2000). REST berkembang bersamaan dengan berkembangnya teknologi web, sehingga sering digunakan bersamaan dengan teknologi Hypertext Transfer Protocol (HTTP), oleh alasan inilah implementasi REST menggunakan teknologi HTTP disebut Restfull HTTP. Sebagai sebuah gaya arsitektur pengembangan sistem, REST memiliki aturan yang menjadi ciri dasarnya (Fielding 2000): 1.
Client-server Terdapat interface seragam antara client dan server. Hal ini berarti client tidak berurusan dengan hal teknis yang menjadi tanggung jawab server, misalnya database, bahasa pemrograman, dll. Hal ini bertujuan untuk portability atau kemudahan migrasi pada client. Pada sisi lain, server tidak berurusan dengan hal teknis pada client, misalnya tampilan sistem atau state dari aplikasi client sehingga pengembangan sistem pada server menjadi lebih sederhana dan lebih mudah dikembangkan (scalable). Server dan client dapat diganti dan dikembangkan secara terpisah selama interface yang digunakan diantara keduanya tidak diubah.
2.
Stateless Komunikasi client-server selanjutnya dibatasi dengan aturan tidak diperbolehkannya state dari suatu client disimpan pada server. Setiap request dari client harus disertai dengan seluruh informasi yang dibutuhkan oleh server untuk memproses request tersebut. Hal ini bertujuan supaya
!
!
7
server menjadi lebih tidak tergantung pada client sehingga mudah diganti terutama saat terjadi kegagalan jaringan (reliability). 3.
Cacheable Respon yang diberikan kepada client dapat disimpan sementara dalam cache client. Hal ini berakibat bahwa respon yang diberikan oleh server harus menyertakan informasi/metadata tentang kemampuan resource tersebut untuk disimpan sementara atau tidak. Hal ini bertujuan untuk mengurangi jumlah komunikasi yang ada sehingga meningkatkan performa server.
4.
Layered System Client tidak perlu tahu apakah server yang melayani request-nya merupakan server utama ataukah bukan. Hal ini bertujuan untuk meningkatkan skalabilitas server misalnya menambahkan server untuk melakukan load balancing dan cache yang dapat diakses siapapun.
5.
Code on Demand Client server dapat mengkustomisasi fungsionalitas dari client dengan mengirimkan kode yang dapat dieksekusi di client, misalkan javascript.
6.
Uniform Interface Simplifikasi arsitektur sistem yang dikembangkan berdasarkan REST dilakukan salah satunya dengan menggunakan Uniform Resource Interface seperti pada Tabel 1. Interface ini terdiri atas sekumpulan operasi yang telah terdefinisi untuk mengakses dan memanipulasi resource. Interface yang sama dapat digunakan pada resource yang berbeda, dan tidak tergantung pada resource yang digunakan.
Tabel 1 Uniform Resource Interface yang digunakan pada RESTful HTTP (Roth 2012) Nama Pemanfaatan Sifat GET Menerima representasi (retrieve) Safe, idempotent DELETE Menghapus resource Idempotent PUT Memperbarui resource dengan mengganti yang Idempotent lama POST Membuat resource baru atau sub-resource baru dengan id dikelola oleh server
!
!
8
Fielding (2000) membagi sifat operasi tersebut menjadi safe dan idempotent. Operasi bersifat safe berarti saat suatu request dilakukan terhadap server, maka state dari resource yang diminta tidak berubah. Operasi GET termasuk safe karena saat suatu request dilakukan terhadap suatu resource, resource tersebut akan tetap sama. Di sisi lain operasi PUT termasuk tidak safe karena saat request dilakukan menggunakan operasi tersebut maka resource tersebut menjadi berubah. Operasi bersifat idempotent berarti hasil dari operasi yang sukses tidak tergantung dari jumlah operasi tersebut dieksekusi, misalkan operasi PUT untuk memperbarui suatu resource dapat dilakukan berulang kali dengan hasil akhir yang sama. Berbeda dengan PUT, operasi POST tidak bersifat idempotent yang berarti jika suatu operasi POST dikirimkan lebih dari sekali, hasil akhirnya bisa saja terdapat duplikasi resource pada server. Hal tersebut disebabkan karena operasi POST digunakan untuk menciptakan resource baru tanpa melihat id spesifik pada client. Fielding (2000) menjelaskan beberapa batasan yang menjadi ciri khas dari arsitektur REST: 1.
Identifikasi dari resource, yang berarti setiap resource yang ada harus memiliki identitas yang standar, misalnya menggunakan URI.
2.
Manipulasi resource dilakukan melalui representasi. Resource asli tidak diberikan kepada client melainkan representasinya dalam bentuk XML, JSON, ataupun HTML. Representasi tersebut terdiri atas data dan metadata yang menjelaskan data, misalnya sebuah instansi content-type pada header HTTP merupakan atribut dari metadata.
3.
Pesan yang mendefinisikan dirinya sendiri, server akan mengolah request yang dikirim kepadanya melalui metadata yang ada pada request tersebut, misalnya melalui header dari request tersebut.
4.
Hypermedia sebagai pengatur transisi dari state. Transisi dari suatu state dilakukan menggunakan hypermedia. Implementasi REST (RESTful) menjadikan beberapa aplikasi dapat
berkomunikasi dan bekerja sama. Melalui web service tersebut, setiap aplikasi pada web memiliki potensi untuk mencapai aplikasi lainnya. Saat aplikasi bertukar informasi melalui standard web service, mereka dapat berkomunikasi secara
!
!
9
terpisah dan lepas dari sistem informasi, pemograman, processor, dan protokol internal (Breitman et al. 2007). Menurut Filho & Ferreira (2009), pendekatan REST pada dasarnya terdiri dari lima konsep (resource, representasi, uniform identifier, unified interface, dan lingkup
eksekusi),
dan
tiga
prinsip
(adressability,
statelessness,
dan
keterhubungan). Hal yang membedakan RESTful dengan web service lainnya adalah linkup dari request dan response harus didefinisikan saat operasi berlangsung. 2.3
Application state dan Resource State Richardson & Ruby (2007) menjelaskan state berarti suatu keadaan dari
suatu informasi yang tersimpan pada suatu sistem di waktu tertentu. Sebagai contoh, jika terdapat suatu resource bernama order, akan terdapat dua keadaan/state dari resource tersebut: order telah terkirim atau order belum terkirim. Suatu resource jarang sekali hanya memiliki satu state dari waktu ke waktu. Perubahan suatu state tersebut disebut state transition dan bagian dari sistem yang mengatur transisi state tersebut disebut sebagai state engine. State pada REST terdiri atas dua tipe: application state dan resource state. Application state berada pada mesin client, sedangkan resource state berada pada mesin server. Application state dapat digambarkan sebagai suatu kondisi dari aplikasi yang dijalankan di client, pada kasus pencarian menggunakan mesin pencari (search engine), halaman hasil pencarian yang sedang dibuka oleh client dapat dikatakan sebagai application state. Resource state dapat dikatakan sebagai persistence dari resource yang ada dan terletak di server. Application state dari client yang satu dengan yang lain bisa berbeda, sebaliknya resource state dari seluruh client adalah sama. 2.4
Hypermedia As The Engine Of Application State (HATEOAS) W3C Glosary Dictionary (2003) mendefinisikan hypertext sebagai teks yang
mengandung tautan ke teks lainnya. Hypermedia adalah istilah yang digunakan untuk hypertext yang mengacu tidak hanya kepada teks, tapi suara, video, grafik, dan lain-lain. HATEOAS (Hypermedia As The Engine Of Application State) adalah aturan yang membedakan arsitektur aplikasi berbasis REST dengan aplikasi lain yang
!
10 !
berbasis client-server. Prinsip dasarnya adalah client berinteraksi dengan aplikasi jaringan melalui hypermedia yang diberikan secara dinamis oleh server (Fielding 2000). Filosofi pemanfaatan hypermedia adalah membuat aplikasi client dapat menelusuri seluruh resource yang ada di server maupun melakukan modifikasi terhadap state dari resource yang ada walaupun tanpa adanya antarmuka sehingga dapat dilakukan oleh aplikasi yang berjalan tanpa manusia. HATEOAS terdiri atas dua jenis: link dan form. Link adalah atribut dari suatu resource yang berisi suatu hypermedia. Form adalah suatu representasi yang dikirim oleh server dalam bentuk yang deskriptif. Bentuk tersebut berisi semua informasi yang dibutuhkan oleh client untuk melakukan manipulasi terhadap resource state di server. Komunikasi diawali oleh client dengan cara melakukan suatu request menggunakan URI statis yang sederhana. Interaksi lanjutan dari aksi sebelumnya akan dilakukan berdasarkan representasi resource yang dikembalikan oleh server dan relasi link (hypermedia) yang ada di dalamnya. Perubahan application state yang ada di client dilakukan melalui pemilihan link yang tersedia di dalam representasi yang dikirim oleh server seperti pada Gambar 1 berikut.
Gambar 1 Representasi photo yang berisi hypermedia jenis link (Allamaraju 2010) 2.5
Template URI Pada RFC 6570 (2012), template URI adalah sekumpulan karakter kompak
yang mendeskripsikan jangkauan dari suatu URI melalui ekspansi variabel. Sebagai
contoh,
URI
http://www.example.com/marketing/
customer/{id} adalah URI yang salah, karena mengandung karakter yang
tidak diizinkan pada URI, yaitu kurung kurawal {}, namun demikian URI tersebut adalah template URI yang sah. Karakter {id} adalah variabel yang dapat diganti dengan nilai lain yang mendefinisikan id dari customer.
!
!
2.6
11
Kode respon HTTP Salah satu fitur utama arsitektur REST adalah pemanfaatan kode respon
HTTP (HTTP response code). RFC 2616 (Fielding et al. 1999) membagi kelompok kode menjadi beberapa bagian sesuai dengan informasi yang diberikan: 1xx (meta), 2xx (success), 3xx (redirection), 4xx (client-side error), dan 5xx (server-side error). Kode 1xx merupakan kelompok respon yang digunakan pada negosiasi antara client dengan server. Kode 2xx mengindikasikan operasi yang dilakukan antara client dengan server berhasil dilakukan. Kelompok ini terdiri atas: 1.
200 (Ok). Kode ini mengindikasikan server sukses melakukan operasi yang diminta oleh client.
2.
201 (Created). Server mengirimkan kode ini jika resource telah tersimpan/tercipta sesuai dengan request yang dikirim oleh client.
3.
204 (No Content). Kode ini biasanya merupakan respon dari operasi PUT, POST, atau DELETE saat server tidak ingin mengembalikan representasi apapun kepada client. Dapat pula digunakan untuk operasi GET terhadap resource yang ada namun memiliki representasi yang kosong. Kelompok 3xx (Redirection) menginformasikan kepada client bahwa client
harus melakukan operasi lainnya hingga request dapat diproses sampai selesai. Kelompok 4xx merupakan kelompok kode yang menandakan terjadi kesalahan yang bersumber pada client. Kelompok ini terdiri atas: 1.
400 (Bad Request). Merupakan kode generik dari kesalahan yang disebabkan oleh client.
2.
401 (Unauthorized). Kode ini mengindikasikan resource yang diminta oleh client merupakan resource yang membutuhkan otoritas tertentu yang tidak disertakan oleh client. Kode ini juga berarti client harus mengulangi request yang dilakukannya dengan menyertakan akun otorisasi yang dibutuhkan.
3.
403 (Forbidden). Kode ini berarti server tidak mengijinkan client untuk mengakses resource yang dituju. Hal ini dapat berarti karena resource tersebut hanya tersedia pada saat-saat tertentu atau hanya dapat diakses oleh alamat IP tertentu.
!
12 !
4.
404 (Not Found). Kode ini mengindikasikan bahwa URI yang diberikan tidak dapat dipetakan kepada resource yang ada, dengan kata lain resource pada URI yang diberikan tidak ada.
5.
405 (Method Not Allowed). Kode ini mengindikasikan resource yang dituju tidak mendukung operasi menggunakan interface yang diberikan oleh client. Sebagai contoh, resource yang hanya dapat dibaca akan mengembalikan kode 405 (Method Not Allowed) saat client melakukan operasi selain GET.
6.
406 (Not Acceptable). Kode ini diberikan saat server tidak dapat memenuhi permintaan format representasi yang diminta oleh client.
7.
409 (Conflict). Kode ini diberikan saat client melakukan request untuk mengubah state dari resource menjadi tidak konsisten. Sebagai contoh menghapus suatu resource yang memiliki sub-resource yang tidak kosong.
8.
415 (Unsupported Media Type). Server mengirimkan kode ini untuk memberitahukan client yang mengirimkan representasi data yang tidak dimengerti. Sebagai contoh client mengirimkan representasi dalam format JSON, sedangkan server hanya menerima format XML.
9.
417 (Expectation Failed). Saat client meminta izin server untuk mengirimkan suatu representasi kepada server, namun server tidak mau menerima representasi yang diberikan oleh client, maka server akan mengirimkan kode ini.
Kelompok kode 5xx menandakan terjadi suatu permasalahan yang disebabkan oleh server atau pada proxy yang digunakan. Kelompok ini terdiri atas: 1.
500 (Internal Server Error). Kode ini merupakan kode generik dari respon kesalahan yang terjadi oleh server.
2.
503 (Service Unavailable). Kode ini berarti web service yang dituju oleh client sedang bermasalah. Server berjalan namun karena suatu hal server tidak dapat menangani request dari client.
2.7
HTTP header HTTP header merupakan komponen dari header suatu pesan yang
dikirimkan (request) dan diterima (response) pada protokol HTTP (RFC 2616). Header ini merupakan parameter dari transaksi yang terjadi antara client dengan
!
!
13
server pada transaksi HTTP. Beberapa header yang umum digunakan diantaranya (Richardson & Ruby 2007): a. Accept. Client menggunakan ini untuk menginformasikan kepada server format representasi yang diharapkan dikirim oleh server. b. Authorization. Header ini mengandung informasi otorisasi seperti username dan password yang dikodekan menggunakan skema yang disepakati antara client dan server. c. Connection. Header ini digunakan oleh proxy yang menghubungkan oleh server dengan client, proxy HTTP selanjutnya akan menghapus header ini saat representasi diteruskan kepada client. d. Content-Encoding. Header ini menjelaskan pengkodean yang digunakan pada representasi response yang diberikan oleh server. e. Content-Length. Header ini berisi ukuran dari representasi data yang dikirimkan. f. Content-Type. Header ini berisi jenis representasi yang ada pada request. g. Date. Pada request yang berasal dari client, header ini berisi waktu request dikirimkan. Pada response yang diberikan oleh server, header ini berisi waktu response tersebut dikirim oleh server. h. Expires. Header ini memberi tahu client atau proxy diantara client dan server, bahwa respon yang diberikan oleh server dapat disimpan sementara (cache) hingga periode tertentu. i. Host. Header ini berisi nama domain dari URI. Saat request dilakukan pada http://www.example.com/page.html, maka header ini akan berisi www.example.com:80.
j. Last-Modified. Header ini berisi waktu terakhir resource tersebut mengalami perubahan. k. User-Agent. Header ini menginformasikan jenis perangkat lunak yang digunakan saat melakukan request. l. WWW-Authenticate. Header ini digunakan bersamaan dengan kode respon 401 (“Unauthorized”). Hal ini berarti server mengharapkan client mengulangi request tersebut dengan menyertakan akunnya beserta skema autentikasi yang digunakan.
!
14 !
2.8
Uniform Resource Identifier (URI) URI atau yang lebih dikenal dengan URL (Uniform Resource Locator)
merupakan frase yang terdiri atas sekumpulan karakter yang digunakan untuk mengidentifikasi suatu nama atau sumberdaya (resource). Identifikasi tersebut memungkinkan terjadinya interaksi berdasarkan representasi resource melalui jaringan menggunakan protokol tertentu (Berners et al. 2005). Misalkan seseorang memasukkan URL di peramban: http://www.example.com/hello.txt. Peramban dapat memanipulasi resource dengan menghubungi server lokasi tempat resource tersebut berada (www.example.com) dengan cara mengirimkan sebuah operator "GET" yang menuju ke arah resource /hello.txt pada server tersebut. Selanjutnya server akan memberikan respon sesuai dengan permintaan yang diberikan kepadanya. Catatan respon dari client yang mengakses resource dapat dilihat pada Gambar 2.
Gambar 2 Catatan respon dari pembacaan resource (Richardson & Ruby 2007) URI pada ROA harus didesain sedemikian rupa sehingga URI tersebut memiliki beberapa sifat berikut (Richardson & Ruby 2007): a.
URI harus deskriptif URI dan resource yang direpresentasikan harus memiliki hubungan secara intuitif. Berikut contoh URI yang baik:
URI harus merepresentasikan paling banyak sebuah resource URI harus didesain untuk merepresentasikan maksimal sebuah resource, tapi sebuah resource dapat direpresentasikan oleh lebih dari satu URI. Pengaksesan /resource/sales/2004/Q4 mungkin akan memiliki hasil yang sama dengan /resource/sales/Q42004, namun keduanya bukanlah resource yang berbeda.
!
!
15
2.9 Web Service Seperti pendahulunya, seperti Common Request Broker Architecture (CORBA), Remote Method Invocation (RMI) dan Distributed Component Object Model (DCOM), web service adalah sekumpulan standard dan metode pemrograman untuk berbagi data antara aplikasi perangkat lunak yang berbeda. Web service adalah sistem perangkat lunak yang didesain untuk mendukung interaksi antar mesin melalui jaringan. Web service memiliki interface khusus yang menjelaskan layanan yang ada melalui format yang dapat diproses oleh mesin. Sistem lain dapat berinteraksi dengan web servis melalui prosedur yang ditentukan menggunakan pesan SOAP, XML, ataupun standard web lainnya (W3C 2004). 2.10 Kelapa sawit (Elaeis) Tanaman kelapa sawit diklasifikasikan sebagai berikut (Pahan 2010): Divisi
:
Embryophyta Siphonagama
Kelas
: Angiospermae
Ordo
: Monocotyledonae
Famili
: Arecaceae
Subfamili : Cocoideae Genus
: Elaeis
Spesies
: E. guineensis Jacq. E. oleifera (H.B.K) Cortes E. odora
Kelapa sawit yang dibudidayakan terdiri atas dua jenis: E. guineensis dan E. oleifera. Jenis pertama yang terluas dibudidayakan orang secara komersial di Afrika, Amerika Selatan, Asia Tenggara, Pasifik Selatan, serta beberapa daerah lain dengan skala yang lebih kecil. Kedua spesies kelapa sawit ini memiliki keunggulan masing-masing: E. guineensis memiliki produksi yang sangat tinggi dan E. oleifera memiliki tinggi tanaman yang rendah. Penangkar seringkali melihat tipe kelapa sawit berdasarkan ketebalan cangkang, yang terdiri atas: Dura, Pisifera, dan Tenera (Gambar 3).
!
16 !
Gambar 3 Varietas kelapa sawit (Pahan 2010) Dura merupakan sawit yang buahnya memiliki cangkang tebal yaitu sekitar 2-8 mm sehingga dianggap memperpendek umur mesin pengolah namun biasanya tandan buahnya besar-besar. Pisifera buahnya tidak memiliki cangkang, sehingga tidak memiliki inti (kernel) yang menghasilkan minyak ekonomis dan bunga betinanya steril sehingga sangat jarang menghasilkan buah. Tenera adalah persilangan antara induk Dura dan jantan Pisifera. Jenis ini dianggap bibit unggul sebab melengkapi kekurangan masing-masing induk dengan sifat cangkang buah tipis sekitar 0,5-4 mm namun bunga betinanya tetap steril.! 2.11 Metode Waterfall Model ini adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Fase waterfall menurut Sommerville (2010) dapat dilihat pada Gambar 4.
Gambar 4 Metodologi pengembangan perangkat lunak waterfall (Sommerville 2010) a.
Requirements analysis and definition Mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan
!
!
17
dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap. b.
System and software design Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap. Desain dilakukan menggunakan UML sebagai pemodelan sistem.
c.
Implementation and unit testing Desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit.
d.
Integration and system testing Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).
e.
Operation and maintenance Mengoperasikan
program
dilingkungannya
dan
melakukan
pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya. Kekurangan utama dari model ini adalah kesulitan dalam mengakomodasi perubahan saat proses telah berjalan. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase selanjutnya. Masalah dengan model waterfall lainnya yaitu: 1.
Perubahan sulit dilakukan karena sifatnya yang kaku.
2.
Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.
3.
Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.
!
BAB III METODE PENELITIAN
3.1
Lokasi Penelitian Penelitian dilakukan di PT. Sasaran Ehsan Mekarsari (PT. SEM) yang
beralamat di Jalan Raya Cileungsi, Jonggol Km. 3, Cileungsi Bogor. Penelitian dilakukan pada kantor tersebut karena aktivitas perusahaan seluruhnya dilakukan di sana, seperti lahan pembibitan (Seed Garden), pabrik seleksi (Seed Garden Factory), gudang, dan kantor pusat administrasi (Head Office). Terpusatnya aktivitas mempermudah pengumpulan data yang dibutuhkan pada penelitian ini. 3.2
Langkah Penelitian Pengembangan perangkat lunak dilakukan menggunakan metode waterfall,
dengan proses analisis kebutuhan diperoleh dengan cara menurunkan spesifikasi kebutuhan fungsional/non-fungsional dari sistem yang sedang berjalan ditambah dengan hasil wawancara dengan management PT. SEM. Kerangka penelitian dapat dilihat pada Gambar 5.
Gambar 5 Kerangka penelitian
19! !
20 !
3.2.1 Studi kebutuhan Analisis kebutuhan merupakan suatu tahapan dalam pengembangan perangkat lunak untuk menggali segala bentuk informasi dari awal sampai akhir dengan harapan dapat mengetahui kendala-kendala yang dihadapi. Pada tahapan ini akan digunakan untuk melakukan wawancara mengenai kondisi yang ada sekarang dan masalah yang dihadapi dengan kondisi yang ada beserta harapan untuk memperbaharui kondisi yang ada. Stakeholder yang terkait pada perusahaan akan dilakukan wawancara untuk melakukan verifikasi terhadap kebutuhan sistem yang akan dikembangkan. 3.2.2 Identifikasi masalah Pada tahapan ini, sudah dapat ditentukan beberapa permasalahan yang ada, baik itu merupakan perbaikan dari sistem yang lama ataupun penambahan suatu proses bisnis yang semakin maju. Pengidentifikasian masalah ini terjadi selama masa wawancara dan penurunan kebutuhan dari sistem yang ada. 3.2.3 Analisis Kebutuhan Sistem Analisis terhadap kebutuhan sistem dilakukan berdasarkan studi pustaka dan literatur mengenai konsep REST dan ROA yang dibutuhkan selama penelitian. Pada tahap ini proses reverse engineering (penurunan) kebutuhan fungsional dan non-fungsional sistem dianalisis. Hasil analisis akan didokumentasikan dalam tabel kebutuhan sistem. 3.2.4 Desain sistem Desain sistem secara keseluruhan dilakukan di tahap ini. Arsitektur dikembangkan menggunakan konsep Representational State Transfer (REST). Desain terdiri atas tiga bagian besar sistem: back-end sistem informasi (services provider), back-end sistem informasi geografis (services composer), dan front-end sistem
informasi
(services
consumer).
Dokumentasi
sistem
dilakukan
menggunakan Unified Modelling Language (UML) berupa diagram kelas yang menggambarkan keterhubungan antar entitas yang ada pada sistem yang akan dibangun. Desain sistem terdiri atas tiga tahap: perancangan back-end sistem informasi, back-end GIS, dan front end sistem informasi. Perancangan back-end sistem informasi dilakukan dalam beberapa tahap sesuai dengan Gambar 6.
!
!
21
Gambar 6 Tahap perancangan back-end sistem informasi (Richardson & Ruby 2007) ! Tahap pertama yaitu perancangan back-end sistem informasi. Tahap ini dilakukan dalam beberapa tahap yaitu: 1.
Identifikasi resource melalui entitas yang ada Pada tahap ini dihasilkan diagram domain (domain diagram) yang menggambarkan entitas yang terlibat pada proses bisnis di perusahaan. Diagram domain ini kemudian digunakan sebagai dasar dalam penentuan kandidat resource yang dibutuhkan pada server.
2.
Pemetaan URI untuk setiap resource yang ada Setiap resource yang ada akan dikelompokkan menurut divisi perusahaan tempat entitas tersebut berada. Selanjutnya penamaan URI untuk setiap resource yang ada dilakukan berdasarkan domain perusahaan tersebut sehingga URI dari setiap resource akan berbentuk hirarki, contoh: /marketing/customer
yang
diperuntukkan
bagi
customer
yang
merupakan entitas pada bagian marketing. 3.
Penentuan uniform interface yang digunakan Perancangan uniform interface yang dibutuhkan untuk setiap resource dilakukan pada tahap ini. Secara spesifik, pada tahap ini setiap resource telah memiliki URI-nya masing-masing sehingga rancangan interface yang digunakan secara teknis diberlakukan terhadap URI tersebut. Interface yang akan digunakan pada penelitian ini terdiri atas GET, POST, PUT, dan DELETE. Operasi yang didefinisikan terhadap setiap interface yaitu: a) Interface GET melakukan pembacaan terhadap URI yang diberikan kepada server. Pembacaan yang dilakukan dapat ditujukan kepada seluruh resource yang berdasarkan URI tersebut atau terhadap resource tertentu dengan id spesifik. Saat operasi dilakukan terhadap parameter
!
22 !
yang bukan id, maka data yang dikembalikan dari server adalah resource dengan pengelompokkan berdasarkan parameter yang diberikan. Sebagai contoh URI /prenursery/stock/age akan menghasilkan pembacaan resource /stock/ (stok) yang dikelompokkan berdasarkan /age (usia). Selain itu operasi GET dapat pula dilakukan terhadap sub-resource dari suatu resource seperti /marketing/order_item/order/{order} yang berarti operasi dilakukan terhadap /order_item/ yang merupakan sub-resource dari /order/{order}, dengan {order} adalah suatu identifier. b) Interface POST digunakan untuk melakukan operasi pembuatan resource baru pada URI yang diberikan kepada server. Interface ini dapat pula digunakan untuk menambah item dari suatu resource yang memiliki hubungan
dengan
resource
/marketing/order/ /order_item/,
lainnya.
Sebagai
contoh
resource
didalamnya mengandung satu atau lebih resource
operasi modifikasi terhadap item dari /order/ dalam
hal ini adalah /order_item/ dapat dilakukan dengan menyertakan identitas {order} yang merujuknya. Operasi menggunakan interface POST
pada
URI
/marketing/order_item/order/123
berarti
penambahan item baru terhadap resource /order/ dengan nomor order 123.
c) Interface PUT digunakan untuk melakukan pengubahan terhadap resource tertentu. Operasi dilakukan dengan menyertakan id dari resource yang ingin diubah pada parameter URI yang dikirim kepada server. Sama halnya dengan interface POST, PUT dapat dilakukan terhadap sub-resource dari suatu resource tertentu dengan cara menyertakan id dari resource yang merujuknya. d) Interface DELETE digunakan untuk melakukan penghapusan terhadap resource tertentu. Operasi dilakukan dengan menyertakan id dari resource yang ingin dihapus pada parameter URI yang dikirim kepada server.
!
!
23
4. Perancangan format representasi yang dikirim ke server. Komunikasi antara client dan server dilakukan berdasarkan uniform interface yang telah dirancang pada tahap sebelumnya. Selanjutnya pada tahap ini dilakukan perancangan format representasi yang akan digunakan oleh client dalam mengirimkan data kepada server. Aturan format representasi yang dihasilkan pada tahap ini akan menjadi pedoman bagi client dalam melakukan komunikasi pengubahan (PUT) dan pembuatan baru (POST) untuk resource yang ada terutama dalam hal atribut yang ada untuk setiap resource. 5.
Perancangan format representasi yang dikembalikan dari server. Pada tahap ini dilakukan perancangan format representasi yang dikembalikan oleh server terhadap setiap operasi yang dilakukan untuk setiap resource. Hasil dari tahap ini adalah dokumentasi format representasi yang dapat digunakan oleh client dalam menerima dan membaca resource yang ada.
6.
Integrasi antara satu resource dengan resource lainnya menggunakan hypermedia Perancangan hubungan antara resource yang satu dengan lainnya dilakukan pada tahap ini. Setiap resource yang mengandung resource lainnya akan direpresentasikan menggunakan konsep hypermedia yang pada dasarnya berupa tautan/link ke resource yang dirujuk tersebut. Diagram domain yang dihasilkan sebelumnya digunakan lagi pada tahap ini sebagai rujukan keterhubungan antara resource yang satu dengan lainnya.
7.
Perancangan kode respon dari server Pada tahap ini dirancang kode respon hasil komunikasi antara client dengan server. Perancangan yang akan dilakukan meliputi kode respon yang menunjukkan kesuksesan suatu request maupun kesalahan-kesalahan yang dapat terjadi saat komunikasi berlangsung. Kode respon yang digunakan berdasarkan standard HTTP 1.1 (Fielding et al. 1999). Tahap kedua adalah perancangan back-end GIS yang akan dilakukan
menggunakan framework yang telah ada dalam mengolah data spasial. Selanjutnya perancangan fitur yang disediakan oleh back-end GIS tersebut
!
24 !
ditentukan pada tahap ini yang selanjutnya akan menjadi masukan bagi front-end sistem informasi. Tahap ketiga adalah perancangan front end sistem informasi. Perancangan akan dilakukan menggunakan framework dengan tujuan merefleksikan fitur yang ada dari kedua back-end yang ada. Front-end akan dikembangkan berbasis web yang menampilkan hasil transaksi data dengan kedua back-end yang ada. Frontend sistem tidak akan melakukan banyak proses bisnis karena berperan sebagai client dari web service sehingga rancangan yang dihasilkan pada tahap ini adalah rancangan antarmuka sistem informasi yang pada akhirnya berhubungan langsung dengan pengguna. 3.2.5 Implementasi sistem Implementasi
akan
dikembangkan
menggunakan
beberapa
bahasa
pemrograman dan pada platform yang beragam. Services provider yang berfungsi sebagai back-end sistem informasi dikembangkan menggunakan framework Restler (PHP), services composer yang mengolah data GIS diimplementasikan menggunakan framework geoserver (JAVA), dan front-end yang langsung berinteraksi dengan pengguna akan dikembangkan menggunakan framework Code Igniter (PHP). Sistem operasi yang digunakan adalah empat buah Ubuntu yang diletakkan pada virtual machine. Implementasi front-end sistem informasi digunakan sebagai prove of concept (POC) dari arsitektur sistem secara keseluruhan. 3.2.6 Pengujian sistem Sistem
akan
diuji
menggunakan
data
contoh
(dummy)
yang
merepresentasikan data aktifitas kegiatan penelitian di perusahaan tersebut. Pengujian akan dilakukan secara sederhana yaitu pengujian black box terhadap seluruh fungsi yang tersedia pada back-end sistem informasi dan back-end-gis. Pengujian sistem dilakukan pada front-end sistem informasi menggunakan peramban Google Chrome dengan addon Postman. Pengujian yang dilakukan terdiri atas: 1. Pengujian terhadap keberhasilan transaksi yang dilakukan antara client dan back-end sistem informasi. Pengujian dilakukan dengan melakukan request
!
!
25
dan melihat hasil response yang diberikan sesuai dengan skenario yang dibuat. 2. Pengujian terhadap tema peta dengan melakukan request terhadap back-end GIS dan memeriksa hasil yang diberikan. 3. Pengujian terhadap kode respon yang diberikan oleh server terhadap situasi tertentu. 3.2.7 Dokumentasi Tahap ini merupakan proses pembuatan dokumentasi sistem yang terdiri atas deskripsi arsitektur back-end SI, front-end SI, back-end SIG, dan front-end SIG. Dokumentasi yang dihasilkan akan bermanfaat bagi stakeholder yang memiliki kepentingan terhadap sistem informasi yang ada. Dokumentasi arsitektur akan menjadi panduan bagi pengembang sistem dalam melakukan modifikasi terhadap sistem. Dokumentasi front-end akan menjadi panduan bagi pengguna yang berinteraksi dengan sistem secara langsung.
!
! 26 !
!
BAB IV HASIL DAN PEMBAHASAN
Wawancara dilakukan terhadap setiap penanggung jawab divisi perusahaan yang
terdiri
atas
kebun,
gudang,
pabrik,
administrasi/pemasaran,
dan
kepegawaian. Pada wawancara tersebut dihasilkan gambaran proses bisnis yang terjadi di perusahaan. Hal-hal lain seperti rencana di lima tahun ke depan seperti implementasi smartphone pun menjadi harapan dari implementasi sistem yang sedang diteliti. Wawancara dilakukan mulai dari awal tahun 2012 hingga bulan Agustus 2012 dan menghasilkan daftar kebutuhan dari sistem beserta detail lainnya. Setelah dilakukan wawancara dan pengumpulan informasi kebutuhan sistem dari sistem yang sedang berjalan, diperoleh beberapa informasi yang akan digunakan sebagai dasar perancangan dan pengembangan sistem yang akan dibangun. Wawancara lanjutan dilakukan kepada setiap penanggung jawab bagian di setiap divisi perusahaan untuk memverifikasi gambaran proses bisnis hasil wawancara sebelumnya dengan hasil analisis terhadap sistem yang sedang berjalan. Pada bagian ini juga diidentifikasi permasalahan-permasalahan yang ada yang menjadi kendala dalam implementasi pada sistem yang berjalan. Secara garis besar, hasil wawancara dan analisa terhadap sistem yang sedang berjalan dijelaskan pada bagian selanjutnya. 4.1
Domain permasalahan PT. Sasaran Ehsan Mekarsari (PT. SEM) merupakan perusahaan yang
bergerak di bidang pembibitan dan penelitian kelapa sawit. Secara garis besar, perusahaan ini melakukan penelitian kelapa sawit yang dimulai dari bibit hingga tanaman dewasa. PT. SEM memiliki beberapa divisi perusahaan di dalamnya yaitu: 1. Kebun (garden) 2. Gudang (warehouse) 3. Pabrik (seed garden factory – SGF) 4. Administrasi dan pemasaran (marketing) 5. Kepegawaian (human resources)
27! !
28 !
Setiap divisi dari perusahaan saling berhubungan satu sama lain sebagai sebuah kesatuan sehingga segala proses yang terjadi di perusahaan dapat berjalan lancar. Setiap bagian tersebut memiliki fungsi dan tugas masing-masing seperti uraian berikut ini: 4.1.1 Kebun (garden) Bagian kebun merupakan bagian utama dari PT. SEM, karena pada bagian inilah kegiatan pembibitan dan penelitian berlangsung. Aktivitas yang dilakukan di kebun sesuai hasil wawancara terdiri atas beberapa bagian, mulai dari pembibitan hingga pemanenan. Pengelompokkan menjadi satu domain didasarkan pada hasil wawancara sebagai berikut: “Kebun dimulai dengan penerimaan kecambah dari pabrik, lalu ditanam di pembibitan prenursery, dan seterusnya hingga dipanen beberapa tahun kemudian. Walau prosesnya cukup panjang, namun pengelolaannya masih dilakukan di bawah mandor kebun”. Tahapan yang terjadi pada kebun adalah: a) Pembibitan prenursery Aktivitas ini berfokus pada proses pembibitan awal yang dimulai dari bibit belum tumbuh hingga menjadi kecambah berusia 3 bulan. Setelah kecambah tersebut sudah berusia 3 bulan maka proses berlanjut pada bagian pembibitan mainnursery (repotting). Aktivitas yang terjadi pada pembibitan prenursery yaitu: •
Penyiapan kantong plastik (polibeg), kegiatan pengisian kantong plastik dengan tanah sebagai persediaan media tanam bibit.
•
Penanaman bibit, kegiatan penanaman bibit ke dalam kantong polibeg kecil.
•
Repotting, proses pemindahan bibit dari kantong polibeg kecil ke kantong polibeg besar pada pembibitan mainnursery.
•
Penyeleksian bibit rusak/mati, proses pemilihan bibit yang rusak/mati dan menyingkirkannya dari lahan pembibitan.
•
Penjualan bibit, pemindahan bibit dari lahan pembibitan untuk dijual ke konsumen.
•
!
Sensus pokok, perhitungan jumlah tanaman berdasarkan usia dan varietasnya.
!
29
b) Pembibitan mainnursery Aktivitas lanjutan dari prenursery yang berfokus untuk memelihara dan membesarkan tanaman hingga siap tanam di medan sesungguhnya. Kegiatan pembibitan mainnursery akan berlangsung selama 9 bulan sehingga tanaman yang keluar dari tahap ini dapat ditanam atau dijual ke konsumen. Aktivitas yang terjadi pada tahap ini yaitu: •
Penanaman bibit, kegiatan penanaman bibit ke dalam kantong polibeg kecil.
•
Transplanting, proses pemindahan bibit dari kantong polibeg kecil ke kantong polibeg besar pada pembibitan mainnursery.
•
Penyeleksian bibit rusak/mati, proses pemilihan bibit yang rusak/mati dan menyingkirkannya dari lahan pembibitan.
•
Penjualan bibit, pemindahan bibit dari lahan pembibitan untuk dijual ke konsumen.
•
Sensus pokok, perhitungan jumlah tanaman berdasarkan usia dan varietasnya
c) Perawatan Kegiatan perawatan dilakukan per tanaman yang ada di kebun. Perawatan terdiri dari beberapa jenis dan dilakukan secara periodik maupun insidental (perawatan khusus). d) Penanaman tanaman Kegiatan penanaman dilakukan di kebun pada titik tanam yang kosong atau belum ditempati. Tanaman yang ditanam bisa berasal dari mainnursery maupun tanaman dewasa dari luar perusahaan. e) Penanaman tanaman pengganti/sulam/replanting Kegiatan replanting dilakukan karena tanaman tertentu di kebun telah tidak produktif lagi ataupun sudah mati sehingga perlu diganti dengan tanaman baru. Penanaman ini dilakukan pada titik tanam yang telah ditempati namun tanaman yang menempati tersebut tidak produktif lagi. f)
Pembungkusan (bagging) Kegiatan pembungkusan dilakukan pada tandan/janjang (buah sawit betina)
yang bertujuan sterilisasi tandan dari polen/serangga. Kegiatan ini dilakukan per tandan pada tandan yang sudah siap dikawin.
!
30 !
g) Polinasi Kegiatan polinasi tandan yang telah dibungkus/bagging dilakukan sekitar 12 hari setelah tandan dibungkus. Kegiatan polinasi dilakukan menggunakan serbuk sari/polen dari tanaman sawit pejantan (Pisifera). Tandan yang telah dikawinkan selanjutnya dibungkus lagi supaya terhidar dari serangan hama. h) Pemanenan Setelah sekitar 5 bulan tandan dipolinasi, tandan yang siap dipanen dipotong dan diambil yang selanjutnya akan diproses lebih lanjut. Selain tandan betina, tandan jantan yang berasal dari pohon sawit pejantan (Pisifera) dipanen juga sesuai dengan jadwal yang ada. i)
Sensus Bunga Kegiatan sensus dilakukan setiap minggu terhadap seluruh tanaman yang ada
di kebun. Kegiatan ini bertujuan mencatat jumlah tandan yang ada beserta keadaannya pada setiap pohon. j)
Seleksi Pohon Induk Pohon induk sawit adalah pohon sawit yang memenuhi kriteria tertentu yang
menunjukkan tanaman tersebut memiliki kualifikasi untuk dijadikan sumber bibit. Tidak semua tanaman yang menghasilkan bibit sawit dijadikan sebagai sumber bibit. Pohon yang telah menjadi pohon induk akan diberikan perhatian lebih dibandingkan lainnya. Setiap aktivitas yang terjadi di kebun merupakan rangkaian dari perjalanan hidup bibit sawit tersebut, yang dimulai dari pembibitan prenursery hingga bibit tersebut tertanam sebagai pohon induk dan menghasilkan bibit lainnya yang siap ditanam atau dijual ke konsumen. 4.1.2 Gudang (warehouse) Gudang adalah tempat yang difungsikan untuk menyimpan barang sementara sebelum barang digunakan. Barang yang disimpan di gudang adalah semua jenis barang mulai dari bahan kimia, spare part, pupuk, dan sebagainya. Pada gudang terjadi beberapa aktivitas berikut :
!
!
31
a) Pembelian barang Pembelian barang baru atau barang lama yang sudah aus dilakukan dalam dua tahap: permohonan pembelian yang selanjutnya jika disetujui akan diproses pembelian dan barang yang datang akan dicatat. b) Pengeluaran barang Barang yang ada pada gudang akan keluar melalui dua tahap: bon permintaan barang yang selanjutnya jika disetujui maka barang akan dikeluarkan dan dicatat. c) Stock Opname Perhitungan stok atau jumlah yang ada pada setiap barang di gudang dilakukan setiap bulan yang selanjutnya akan dilaporkan kepada bagian Adminsitrasi. 4.1.3 Pabrik (factory) Buah sawit/tandan yang telah dipanen selanjutnya akan diproses di pabrik. Berbeda dengan pengolahan pada kebun produksi, output dari pabrik pengolahan ini bukanlah minyak sawit, tapi outputnya adalah biji yang siap tanam. Secara garis besar, tahap yang dilalui oleh setiap biji yang ada dimulai dari seleksi awal hingga seleksi akhir seperti pada Gambar 7.
Gambar 7 Proses perkecambahan bibit kelapa sawit
!
32 !
Pabrik pengolahan terdiri atas beberapa proses: a) Serah terima tandan Proses pengolahan diawali dengan penyerahan tandan hasil panen (tandan betina) dari bagian kebun ke bagian pabrik. Pada tahap ini, biji tandan sudah terlepas dari batang tandan, namun masih dalam keadaan yang kotor sehingga perlu dibersihkan dan diseleksi pada tahap selanjutnya. b) Seleksi biji Biji sawit yang sudah terlepas dari tandannya akan dibersihkan dan diberi fungsida untuk mencegah jamur. Seleksi dilakukan terhadap biji yang afkir atau kosong sehingga biji yang akan diproses selanjutnya merupakan bibit yang baik. Pada tahap ini dilakukan pembungkusan biji sawit dan pelabelan bungkus tersebut berdasarkan sumber tandannya. Label ini selanjutnya akan menjadi identitas dari kantong tersebut pada beberapa tahap selanjutnya. Setiap tandan bisa saja terdiri atas dua atau lebih kantong dengan identitas yang sama, hal tersebut didasarkan pada dasarnya sumber mereka sama sehingga walaupun berada pada kantong yang berbeda namun sumber tandannya adalah sama. c) Ruang dingin Kantong biji sawit selanjutnya dapat masuk ke ruang dingin untuk disimpan sementara atau lebih lama jika pesanan terhadap biji sawit belum adasehingga proses perkecambahan perlu diperlambat. Pencatatan dilakukan dua kali, yaitu pada saat masuk dan keluar dari ruang ini, serta pemeriksaan terhadap biji yang mati atau berjamur harus dilakukan saat bibit keluar dari ruang dingin. Biji yang ada pada ruangan ini dapat bertahan hingga mencapai 2 tahun. d) Ruang panas Kantong biji sawit dapat masuk ke ruang panas jika bijinya hendak dikecambahkan untuk dijual atau ditanam. Pencatatan dilakukan terhadap kantong yang masuk maupun keluar dari ruangan ini serta pemeriksaan dilakukan saat bibit keluar dari ruang panas untuk menyingkirkan bibit yang kosong atau berjamur. Biji sawit berada pada ruangan ini selama kurang lebih 35 hari.
!
!
33
e) Perkecambahan Biji sawit yang siap berkecambah kemudian akan dimasukkan dalam ruang germinasi atau perkecambahan selama kurang lebih 30 hari hingga biji sudah berkecambah. Selanjutnya biji yang sudah berkecambah akan dipisahkan dari kantongnya dan disimpan di ruang dingin hingga kuota biji yang telah berkecambah mencukupi. Pencatatan dilakukan secara periodik untuk melihat perkembangan kecambah supaya tidak terlalu tinggi sehingga dapat langsung dipindahkan ke ruang dingin atau diproses ke tahap selanjutnya. Pemeriksaan terhadap biji yang kosong dan berjamur dilakukan untuk menghindari penyebaran jamurnya. Tidak semua biji yang dikecambahkan dapat tumbuh pada satu tahap, kadang beberapa biji harus dimasukkan ulang ke ruang panas lalu masuk lagi ke ruang germinasi pada putaran berikutnya supaya dapat tumbuh, proses ini disebut recycle. f) Seleksi akhir Kecambah yang siap ditanam selanjutnya diseleksi ulang dan disiapkan untuk penanaman di lahan sendiri (pembibitan prenursery) atau dipersiapkan untuk pengiriman ke lokasi pelanggan. 4.1.4 Pemasaran dan Administrasi (marketing) Divisi pemasaran dan administrasi pada PT. SEM berada pada bagian yang sama. Pada bagian ini berlangsung kegiatan sebagai berikut: a) Penjualan kecambah Proses penjualan kecambah sawit dilakukan secara bertahap mulai dari datangnya pesanan dari pelanggan (sales order), yang selanjutnya dilanjutkan dengan pembuatan kontrak kerjasama (contract) antara kedua belah pihak dan pengiriman tagihan (invoice) kepada pelanggan tersebut. Dilanjutkan dengan pembayaran down payment sesuai kontrak (payment) hingga pengiriman kecambah ke lokasi pelanggan. •
Pemesanan, pada tahap ini pihak adminstrasi akan memastikan jumlah persediaan kecambah yang siap dijual. Proses pemesanan hingga realisasi pengiriman membutuhkan waktu yang paling cepat sekitar 3 bulan jika ada persediaan di ruang penyimpanan (ruang dingin). Proses dilanjutkan bila jumlah yang diinginkan mencukupi.
!
34 !
•
Pembuatan kontrak perlu dilakukan antara perusahaan dengan pelanggan yang berisi jadwal pengiriman dan aturan pembayaran tagihan supaya pengiriman dan pembayaran dapat dilakukan sesuai dengan rencana.
•
Tagihan akan dikirimkan yang berisi sejumlah uang yang harus dibayarkan pada awal kerjasama (down payment) yang selanjutnya dilakukan pencatatan pembayaran setelah pelanggan melunasi tagihan tersebut.
•
Proses perkecambahan dilakukan dan proses pengiriman dilakukan dengan membuat berita acara pengiriman dan berita acara penerimaan yang nanti diisi pelanggan saat kiriman telah sampai.
b) Pembelian barang Sebagai sebuah perusahaan, pembelian barang kebutuhan operasional maupun non operasional dilakukan untuk berbagai keperluan. Pembelian dapat saja dilakukan atas dasar permohonan pembelian dari divisi gudang maupun pembelian kebutuhan non operasional seperti workshop, sponsorship, aset non gudang, dll. Pembayaran akan dilakukan terhadap tagihan yang datang kepada perusahaan supaya pengiriman barang dapat dilakukan. 4.1.5 Kepegawaian (human resources) Administrasi kepegawaian yang dilakukan tidak seluruhnya oleh PT. SEM. Sebagai bagian dari PT. Mekar Unggul Sari, maka transaksi keuangan yang dilakukan berkenaan dengan kepegawaian masih dilakukan terpusat. Kegiatan yang dilakukan terbatas pada aktivitas absensi kepegawaian dan perjalanan dinas. 4.2
Analisis kebutuhan Berdasarkan domain permasalahan tersebut dan spesifikasi sistem
sebelumnya, diperoleh beberapa poin hasil dari analisis kebutuhan sistem. Secara umum, kebutuhan sistem ditunjukkan pada Gambar 8.
!
!
35
Gambar 8 Use case kebutuhan SI pembibitan kelapa sawit 4.2.1 Kebun (garden) Kebutuhan fungsional sistem untuk bagian kebun yang terdiri atas pembibitan prenursery, pembibitan mainnursery hingga kebun induk, terdiri atas penyimpanan dan manajemen data dari: •
penyiapan polibeg kosong.
•
penggunaan polibeg.
•
pembibitan prenursery dan mainnursery yang terdiri atas aktivitas penanaman bibit, repotting, transplanting, seleksi bibit rusak/mati, penjualan bibit, dan hasil sensus bibit.
•
perawatan tanaman di kebun penelitian, baik perawatan periodik maupun insidental.
!
•
penanaman pohon baru atau penggantian pohon yang rusak (replanting).
•
pembungkusan, penyerbukan, dan panen tanaman betina (Dura).
•
pemanenan polen dari pohon jantan (Pisifera).
•
sensus bunga pohon yang dilakukan setiap minggu.
36 !
•
registrasi pohon-pohon yang terseleksi sebagai pohon induk.
•
stok bibit sesuai usia pada pembibitan prenursery dan mainnursery. Selain itu pada bagian ini dibutuhkan sistem informasi geografis yang
ditujukan untuk memperlihatkan/visualisasi aktivitas maupun keadaan kebun. Sistem SIG tersebut harus dapat memperlihatkan beberapa hal berikut: •
Menampilkan peta aktivitas pembungkusan tandan.
•
Menampilkan peta aktivitas penyerbukan tandan.
•
Menampilkan peta aktivitas pemanenan tandan.
•
Menampilkan informasi pada pohon terpilih secara interaktif.
4.2.2 Gudang (warehouse) Pada bagian gudang, sistem harus dapat menyimpan dan mengatur data dari aktivitas yang terjadi ada gudang sebagai berikut: •
Slip Permintaan Barang (SPB) yang dikeluarkan oleh pihak gudang kepada pihak perusahaan dalam rangka pembelian barang baru.
•
Tanda Terima Gudang (TTG) yang diperoleh dari pemasok/pengirim barang yang dibeli.
•
Bon Permintaan Barang (BPB) yang dikeluarkan oleh pihak perusahaan untuk konsumsi barang di gudang
•
Slip Keluar Barang (SKB) yang dikeluarkan oleh pihak gudang untuk mencatat barang keluar.
•
Hasil pemeriksaan stok barang di gudang.
4.2.3 Pabrik (factory) Kebutuhan akan pencatatan data pada bagian pabrik terutama diperuntukkan sebagai data historis bibit/kecambah yang diproses pada lokasi tersebut. Pencatatan ditujukan salah satunya supaya informasi produktivitas tanaman penghasil kecambah tersebut dapat diketahui persentase keberhasilan bibitnya dikecambahkan dan persentase kegagalan perkecambahannya, oleh sebab itu pada pabrik pengolahan dibutuhkan sistem yang dapat menyimpan dan mengatur data dari aktivitas berikut:
!
•
penyerahan tandan dari pihak kebun,
•
hasil seleksi awal dan pembungkusan ke dalam kantong biji,
!
37
•
kantong biji yang masuk atau keluar dari ruang dingin,
•
kantong biji yang masuk atau keluar dari ruang panas,
•
hasil pemeriksaan perkecambahan pada ruang germinasi,
•
hasil seleksi akhir biji untuk dijual atau ditanam kembali di pembibitan.
4.2.4 Pemasaran dan Administrasi (marketing) Divisi administrasi dan pemasaran berada pada domain proses yang sama. Pada perusahaan ini beberapa proses bisnis masih dilakukan secara terpusat pada perusahaan induk sehingga kebutuhan yang diperlukan pada sistem menjadi lebih sederhana dan terbatas. Divisi pemasaran membutuhkan sistem yang dapat menyimpan dan mengatur data/aktivitas berikut: •
daftar pelanggan aktif maupun calon pelanggan,
•
daftar pemasok barang,
•
surat kontrak pembelian bibit/kecambah,
•
surat permintaan pembelian (purchase order),
•
pesanan bibit/kecambah,
•
pengiriman bibit/kecambah,
•
laporan penerimaan pengiriman bibit/kecambah (Berita Acara Penerimaan),
•
tagihan dari pemasok atau ke pelanggan.
4.2.5 Kepegawaian (human resources) Divisi kepegawaian tidak melakukan seluruh proses kepegawaian karena masih dikelola oleh perusahaan induk seperti penggajian, pengangkatan, kontrak kerja, dll. Adapun yang dilakukan oleh PT. SEM terbatas pada beberapa hal berikut: •
Menyimpan data karyawan di perusahaan.
•
Menyimpan data perjalanan dinas karyawan.
•
Menyimpan data kehadiran karyawan beserta lemburnya. Secara lebih teknis, kebutuhan fungsional lainnya yang diperlukan yaitu
sistem dikembangkan berbasis web sehingga dapat diakses melalui peramban.
!
38 !
4.2.6 Direktur Sebagai posisi tertinggi, pihak direktur membutuhkan sistem yang dapat menampilkan peta hasil data insidental (perawatan spesifik) dan periodik. Peta akan diakses dari peramban supaya dapat diakses dimanapun dan kapanpun. 4.3
Perancangan
4.3.1 Identifikasi Resource Berdasarkan proses bisnis yang ada di PT. SEM, maka dapat dirangkumkan entitas dan aktivitas yang terlibat di dalamnya menggunakan diagram domain (Lampiran 1). Pada tahap ini entitas dari diagram domain dijadikan dasar dalam identifikasi resource. Berikut ini hasil identifikasi entitas yang akan menjadi resource: a) Pembibitan prenursery • Polibeg • Bibit • Stok Bibit • Penanaman Bibit • Repotting Bibit • Seleksi Bibit • Penjualan Bibit • Sensus Bibit b) Pembibitan mainnursery • Bibit • Stok Bibit • Penanaman Bibit • Transplanting Bibit • Seleksi Bibit • Penjualan Bibit • Sensus Bibit c) Kebun • • • • • •
!
Pohon Tandan Polen Perawatan Penanaman Replanting
!
39
• Pembungkusan Tandan Betina • Polinasi • Panen Tandan Betina • Panen Polen • Sensus Bunga • Seleksi Pohon d) Gudang • Surat Permintaan Barang (SPB) • Tanda Terima Gudang (TTG) • Bon Permintaan Barang (BPB) • Slip Keluar Barang (SKB) • Material/Peralatan • Stok Material/Peralatan e) Pabrik • Serah Terima Tandan • Tandan • Kantong Tandan • Seleksi Awal • Pendinginan (Ruang Dingin) • Pemanasan (Ruang Panas) • Pengecambahan (Ruang Germinasi) • Seleksi Penjualan f) Pemasaran dan Administrasi • Pelanggan • Pemasok • Pesanan • Kontrak • Pembelian Barang • Tagihan ke Pelanggan • Tagihan dari Pemasok • Pembayaran dari Pelanggan • Pembayaran ke Pemasok • Surat Jalan Pengiriman • Berita Acara Penerimaan g) Kepegawaian • • • •
!
Pegawai Perjalanan Dinas Divisi Perusahaan Presensi
40 !
4.3.2 Pemetaan Resource Berdasarkan resource dari setiap domain tersebut, maka pemetaan terhadap seluruh entitas kepada URI resource perlu dilakukan. Pemetaan dilakukan menggunakan template URI pada Gambar 9 (Gregorio et al. 2012): {domain}/{resource}/{subresource}/{parameter} Domain
: Domain dari perusahaan
Resource
: Nama resource
Sub Resource : Nama sub-resource (jika ada) Parameter
: Parameter URI (jika ada)
Gambar 9 Template pemetaan URI terhadap resource yang ada Template tersebut terdiri atas beberapa bagian sebagai berikut: •
Domain, merupakan nama dari bagian bisnis di perusahaan seperti /garden (kebun),
/warehouse
(gudang),
/marketing
(pemasaran),
/hr
(kepegawaian), dll. Domain diperlukan sebagai cara pengelompokkan resource berdasarkan aktivitas yang dilakukan pada bagian tersebut. Hal tersebut bertujuan agar URI yang dihasilkan akan lebih mudah dipahami. •
Resource, merupakan nama dari resource itu sendiri, misalkan /customer yang merupakan hasil pemetaan dari entitas pelanggan (customer).
•
Sub-resource, beberapa entitas terdiri atas beberapa hirarki sehingga diperlukan pengelompokan berdasarkan hirarkinya. Sebagai contoh resource/bunch (tandan) memiliki subresource /ready_harvest (tandan siap panen), yang berarti resource sistem akan memberikan list tandan yang siap dipanen.
•
Parameter, merupakan bagian yang terdapat pada URI yang menunjukkan komponen spesifik dari resource yang ada, misalnya id pada pembacaan suatu resource. Parameter sangat bergantung pada interface yang diberikan. Pada beberapa interface seperti GET dan POST, parameter dapat dikosongkan untuk menunjukkan list dari seluruh resource yang ada pada URI yang diberikan, namun dapat juga diberikan untuk menunjukkan
!
!
41
resource yang lebih detail. Pada interface PUT dan DELETE, parameter id merupakan keharusan. Gambaran umum rancangan URI hasil pemetaan entitas terhadap resource yang diperlukan dalam sistem informasi tersebut akan terdiri atas beberapa bagian. Bagian pemetaan tersebut terdiri dari pemetaan URI di pembibitan (Tabel 2), pembibitan prenursery (Tabel 3), pembibitan mainnursery (Tabel 4), kebun (Tabel 5), gudang (Tabel 6), pabrik (Tabel 7), pemasaran (Tabel 8) dan kepegawaian (Tabel 9). Tabel 2 Pemetaan URI di pembibitan (domain: /nursery/*) No
URI
Deskripsi
NU.1
/seedling
Bibit sawit (tanaman kecil)
Tabel 3 Pemetaan URI di pembibitan prenursery (domain: /prenursery/*) No
URI
Deskripsi
PN.1
/polybag_production
Pembuatan polibeg
PN.2
/polybag_usage
Pemakaian polibeg
PN.3
/stock
Stok bibit
PN.4
/cultivation
Penanaman kecambah ke pembibitan
PN.5
/repotting
Repotting bibit ke pembibitan prenursery
PN.6
/census
Seleksi bibit yang rusak, sakit, atau mati
PN.7
/sale
Penjualan bibit
PN.8
/stock_age
Stok bibit sesuai usia (bulan)
Tabel 4 Pemetaan URI di pembibitan mainnursery (domain: /mainnursery/*)
!
No
URI
Deskripsi
MN.1
/stock
Stok bibit
MN.2
/cultivation
Penanaman bibit ke kebun
MN.3
/transplanting
Transplanting bibit ke pembibitan mainnursery
MN.4
/census
Seleksi bibit yang rusak, sakit, ataupun mati
MN.5
/sale
Penjualan bibit
MN.6
/stock_age
Stok bibit sesuai usia (bulan)
42 !
Tabel 5 Pemetaan URI di kebun (domain: /garden/*) No
URI
Deskripsi
GA.1
/upkeep
Perawatan pohon
GA.2
/item_goods_tree_upkeep
Item dari perawatan
GA.3
/upkeep_type
Tipe perawatan
GA.4
/replanting
Replanting pohon
GA.5
/item_goods_replanting
Item dari replanting
GA.6
/bagging
Pembungkusan tandan betina
GA.7
/pollination
Penyerbukan tandan
GA.8
/harvesting
Panen tandan betina
GA.9
/pollen_harvesting
Panen tandan jantan/pollen
GA.10
/selection
Seleksi pohon induk pilihan
GA.11
/tree
Pohon di kebun
GA.12
/bunch
Tandan jantan dan betina dari pohon
GA.13
/pollen
Pollen pohon
GA.14
/block
Blok tanam
GA.15
/crossing
Asal crossing tanaman
GA.16
/parental
Parental tanaman
GA.17
/variety
Jenis tanaman (Dura, Pisifera, dll)
Tabel 6 Pemetaan URI di gudang (domain: /warehouse/*)
!
!
No
URI
Deskripsi
WH.1
/goods
Barang berupa material/peralatan di gudang
WH.2
/goods_unit
Satuan barang
WH.3
/spb
Surat Permintaan Barang
WH.4
/item_spb
Item SPB
WH.5
/ttg
Tanda Terima Gudang
WH.6
/item_ttg
Item TTG
WH.7
/skb
Slip Keluar Barang
WH.8
/item_skb
Item SKB
WH.9
/bpb
Bon Permintaan Barang
WH.10 /item_bpb
Item BPB
WH.11 /stock
Stok barang di gudang
!
43
Tabel 7 Pemetaan URI di pabrik (domain: /factory/*) No
URI
Deskripsi
FA.1
/consignment
Serah terima tandan
FA.2
/bunch_bag
Kantong tandan
FA.3
/selection
Seleksi awal
FA.4
/cooling
Pendinginan di Ruang Dingin
FA.5
/heating
Pemanasan di Ruang Panas
FA.6
/germination
Pengecambahan
FA.7
/saleable
Seleksi penjualan
Tabel 8 Pemetaan URI di pemasaran (domain: /marketing/*)
!
No
URI
Deskripsi
MA.1
/customer
Pelanggan/pembeli perusahaan
MA.2
/supplier
Pemasok barang/jasa dari luar
MA.3
/order
Pesanan bibit/kecambah
MA.4
/item_order
Item pemesanan
MA.5
/contract
Kontrak antara pelanggan dengan perusahaan
MA.6
/invoice_customer
Tagihan yang pelanggan
MA.7
/item_invoice_customer
Item tagihan pelanggan
MA.8
/invoice_supplier
Tagihan dari pemasok
MA.9
/item_invoice_supplier
Item tagihan pemasok
MA.10
/payment_customer
Pembayaran tagihan oleh pelanggan
MA.11
/item_payment_customer
Item pembayaran pelanggan
MA.12
/payment_supplier
Pembayaran pemasok
MA.13
/item_payment_supplier
Item pembayaran pelanggan
MA.14
/delivery
Surat jalan pengiriman (delivery order)
MA.15
/item_delivery
Item pengiriman
MA.16
/bap
Berita Acara Penerimaan (BAP)
MA.17
/item_bap
Item berita acara penerimaan
MA.18
/procurement
Pembelian barang kepada pemasok
MA.19
/item_procurement
Item pembelian barang ke pemasok
ditujukan
tagihan
ke
kepada
44 !
No
URI
Deskripsi
MA.20
/file
Berkas lampiran kontrak
Tabel 9 Pemetaan URI di kepegawaian (domain: /hr/*) No
URI
Deskripsi
HR.1
/employee
Pegawai perusahaan
HR.2
/travel
Perjalanan dinas pegawai
HR.3
/presence
Presensi pegawai
HR.4
/item_presence
Item presensi pegawai
HR.5
/division
Divisi perusahaan
4.3.3 Penentuan Uniform Interface Pada tahap ini rancangan interface ditetapkan untuk setiap resource yang tersedia. Interface perlu ditetapkan sebagai panduan dalam melakukan komunikasi antara penyedia resource (server) dan pemakai resource (client). Secara garis besar rancangan yang dihasilkan ada pada Tabel 10 berikut: Tabel 10 Rancangan interface pada komunikasi antara client dan server Interface GET
Parameter /{id}
Penjelasan Pembacaan resource tertentu sesuai dengan URI dan {id} yang diberikan. Contoh: /marketing/order/123
GET
/
Pembacaan tanpa parameter dapat dilakukan dan akan mengembalikan seluruh resource yang tersimpan pada server untuk resource tersebut. Contoh: /marketing/order
GET
/{id}/{attr}
Pembacaan atribut {attr} dari resource dengan identitas {id}. Contoh: /marketing/order/123/date
POST
/
Penyimpanan/pembuatan resource yang baru sesuai dengan URL yang diberikan sebagai tujuannya. Client harus menyertakan seluruh informasi yang dibutuhkan oleh server untuk
!
!
45
Interface
Parameter
Penjelasan memproses informasi tersebut. Contoh: /marketing/order
PUT
/{id}
Pengubahan resource yang ada dengan id benilai {id}, client harus menyertakan informasi yang diubah. Contoh: /marketing/order/123
DELETE
/{id}
Penghapusan resource yang ada dengan id bernilai {id}. Contoh: /marketing/order/123
Pemilihan empat interface tersebut didasarkan pada penggunaannya yang cukup mudah dan sering digunakan (Richardson & Ruby 2007). 4.3.4 Desain representasi yang dikirim ke server Rancangan representasi yang dikirim kepada server terdiri atas entitasentitas yang diperlukan saat client melakukan request yang berisi pembuatan resource baru dan pengubahan resource yang ada. Rancangan yang terbentuk akan menjadi acuan bagi client dalam melakukan request menggunakan interface POST dan PUT. Pada operasi pembacaan ataupun penghapusan suatu resource tidak membutuhkan penyertaan entitasnya karena semua informasi yang dibutuhkan dalam proses pembacaan atau penghapusan telah ada pada URI yang diberikan. Rancangan representasi XML dari resource yang dikirim ke server dapat dilihat pada Gambar 10. Nilai Atribut Nilai Atribut [ Nama Relasi 1URL dari resource 1 Nama Relasi mURL dari resource m ]
1 n
yang dimaksud
yang dimaksud
Gambar 10 Rancangan representasi XML untuk dikirim ke server
!
46 !
Representasi yang disiapkan berisi atribut dari resource yang bersangkutan. Entitas link dapat kosong atau tidak dimasukkan ke dalam representasi XML yang dikirim jika resource tersebut tidak merujuk atau tidak memiliki relasi pada resource lainnya. Saat relasi ada maka relasi tersebut dimasukkan ke dalam entitas link dengan nilai href berisi URL dari resource yang dirujuk. Informasi yang diberikan pada saat pengubahan resource diperbolehkan tidak berisi seluruh atribut yang ada, namun pada operasi pembuatan resource baru harus berisi seluruh atribut dari resource tersebut. Rancangan dapat diturunkan dari desain basis data yang dihasilkan pada tahap analisis sehingga struktur data yang dikirimkan ke server saat melakukan suatu request memilik karakter yang mirip dengan struktur tabelnya namun tidak harus identik. Sebagai contoh pada resource yang merepresentasikan aktivitas panen tandan (tree harvesting) yang terletak pada URL /garden/harvesting memiliki struktur tabel seperti pada Tabel 11. Tabel 11 Struktur tabel panen tandan (tree_harvesting) Kolom
Tipe data
Keterangan
id
Integer
ID dari data
bunch_label
Characters(45)
Label dari tandan
date
Date(YYYY-MM-DD)
Tanggal aktivitas panen
weight
Integer
Bobot tandan dalam kg
Representasi yang dapat dikirimkan kepada server saat melakukan request pembuatan data, menggunakan format XML seperti pada Gambar 11.
Gambar 11 Representasi XML pada resource panen tandan Proses yang terjadi saat client melakukan beberapa operasi terhadap resource panen dapat dilihat pada beberapa ilustrasi seperti ilustrasi request
!
!
47
menggunakan POST (Gambar 12), GET (Gambar 13), PUT (Gambar 14), dan DELETE (Gambar 15).
Gambar 12 Ilustrasi request menggunakan POST (pembuatan resource baru)
Gambar 13 Ilustrasi request menggunakan GET (pembacaan)
Gambar 14 Ilustrasi request menggunakan PUT (pengubahan)
!
48 !
Gambar 15 Ilustrasi request menggunakan DELETE (penghapusan) Pada ilustrasi tersebut terjadi komunikasi antara client dan server. Pertama, client mengirimkan data panen tandan menggunakan format XML. Informasi dikirim
melalui
interface
/garden/harvesting.
POST
melalui
URI
panen
tandan
pada
Setelah sampai di server, informasi tersebut diproses
dan disimpan. Informasi dikirim balik kepada client yang berisi URI dari resource baru yang telah tersimpan beserta kode respon hasil dari operasi yang telah dilakukan. Identitias ini selanjutnya dapat digunakan sebagai id dalam melakukan operasi lainnya seperti operasi GET (Gambar 13), PUT (Gambar 14), dan DELETE (Gambar 15). Server juga memberikan kode respon 201 (Resource Created) yang menandakan bahwa resource baru telah tersimpan dengan sukses. Kode lainnya dapat diberikan sesuai dengan hasil proses yang dilakukan oleh server terhadap informasi yang diberikan kepadanya. Sebagai contoh untuk data panen yang sama, namun dikirimkan ke URI yang salah akan akan memberikan kode respon 404(“Not Found”) yang berarti resource pada URI yang diberikan tidak ditemukan sehingga proses tidak dapat dilakukan. 4.3.5 Format representasi yang dikembalikan dari server Format representasi yang dikembalikan oleh server kepada client yang memintanya menggunakan interface GET pada dasarnya sama dengan format representasi yang digunakan untuk membuat resource baru. Beberapa atribut ditambahkan sebagai referensi kepada client tentang representasi yang diterimanya. Atribut yang ditambahkan yaitu: id dan self. Id adalah identitas dari resource tersebut, sedangkan self adalah hypermedia yang merujuk pada URI resource tersebut seperti yang ditunjukkan oleh Gambar 16.
!
!
49
Gambar 16 Ilustrasi format representasi hasil pembacaan resource Pada interface PUT dan POST, representasi yang dikembalikan adalah URI dari resource yang telah diubah/dibuat. Pada interface DELETE, tidak ada representasi yang dikembalikan oleh server karena resource yang dituju pada dasarnya telah dihapus. 4.3.6 Integrasi resource menggunakan hypermedia Integrasi resource yang satu dengan lainnya diwujudkan menggunakan konsep HATEOAS. Resource yang memiliki hubungan dengan resource lainnya akan memiliki entitas berupa hypermedia yang berisi URI dari resource rujukannya tersebut. Hubungan antara resource satu dengan lainnya digambarkan pada elemen rel pada hypermedia yang ada. Sebagai contoh pada Gambar 17, representasi yang dikembalikan oleh server mengandung entitas berbentuk URI yang menunjukkan entitas tersebut sebuah hypermedia. Resource bernama /garden/harvesting/ /garden/bunch/
(panen tandan) memiliki hubungan dengan resource
(tandan), sedangkan resource /garden/bunch/ (tandan)
merujuk lagi kepada resource /garden/tree/ (pohon), dan seterusnya. Informasi tautan antara resource yang satu dengan lainnya dapat diproses lebih lanjut oleh client untuk mengetahui informasi lebih lanjut tentang entitas yang dituju.
!
50 !
Gambar 17 Implementasi hypermedia pada representasi resource Implementasi hypermedia dilakukan untuk mengurangi kesalahan yang ditimbulkan oleh client terutama pada format URI dari suatu resource yang dikirimkan. Selain itu, manfaat utama yang dapat diperoleh adalah pengubahan yang dilakukan terhadap sistem yang ada dapat dilakukan lebih terisolasi dan terkontrol, karena URI yang berisi rujukan terhadap suatu resource ditangani seluruhnya oleh server. Hal tersebut memungkinkan penambahan atau pengurangan terhadap rujukan/fitur dari suatu resource menjadi lebih mudah. 4.3.7 Kode respon dari server Perancangan kode respon dilakukan sebagai rujukan dari komunikasi yang terjadi antara client dengan server. Rancangan kode respon yang digunakan pada penelitian ialah operasi GET (Tabel 12), PUT (Tabel 13), POST (Tabel 14) dan DELETE (Tabel 14). Tabel 12 Kode respon dari server untuk operasi menggunakan interface GET Kode Deskripsi
!
200
Resource yang dituju ada
204
Resource yang dituju ada, tapi tidak memiliki konten (masih kosong)
401
Operasi tidak dapat dilakukan karena client tidak memiliki otoritas
404
Resource yang dituju tidak ada
406
Terjadi bila client meminta representasi dalam format yang tidak
!
51
didukung server 500
Terjadi kesalahan lain yang terjadi di server
Tabel 13 Kode respon dari server untuk operasi menggunakan interface PUT Kode Deskripsi 200
Resource berhasil diubah.
401
Operasi tidak dapat dilakukan karena client tidak memiliki otoritas
404
Resource yang dituju tidak ada.
409
Resource tidak dapat diubah karena konflik dengan resource lain.
415
Server tidak mendukung format representasi yang dikirimkan
500
Terjadi kesalahan lain yang terjadi di server
Tabel 14 Kode respon dari server untuk operasi menggunakan interface POST Kode Deskripsi 201
Resource baru berhasil dibuat.
400
Representasi yang dikirimkan memiliki format yang salah
401
Operasi tidak dapat dilakukan karena client tidak memiliki otoritas
404
Resource yang dituju tidak ada.
409
Resource yang ingin dibuat mengalami konflik dengan resource lain yang telah ada
415
Server tidak mendukung format representasi yang dikirimkan
500
Terjadi kesalahan lain yang terjadi di server
Tabel 15 kode respon dari server untuk operasi menggunakan interface DELETE Kode Deskripsi 200
Resource berhasil dihapus.
401
Operasi tidak dapat dilakukan karena client tidak memiliki otorisasi
404
Resource yang dituju tidak ada.
500
Terjadi kesalahan lain yang terjadi di server
!
Kode respon seperti 401, 404, dan 500 merupakan kode respon yang dapat muncul dari seluruh interface yang ada karena merupakan respon dari proses yang tidak tergantung dari jenis interface yang digunakan. Setelah rancangan tersebut selesai, implementasi akan dilakukan dengan cara menyisipkan kode tersebut pada respon yang dikembalikan oleh server. Pada
!
52 !
operasi seperti pembacaan, penulisan, dan pembuatan resource baru, server akan merespon dengan representasi resource dalam bentuk XML dan memberikan kode respon pada header sebagai metadatanya. Implementasi dilakukan secara implisit pada kode pemrograman bersamaan dengan saat pengiriman representasi resource tersebut. 4.4
Implementasi front-end Sistem Informasi (SI) Front-end SI akan menjadi titik masuk data ke sistem. Sistem front-end SI
menjadi penyambung komunikasi antara pengguna dengan sistem melalui tampilan berbasis web yang dapat dioperasikan secara langsung (Gambar 18).
Gambar 18 Front-end sistem informasi sebagai penengah komunikasi Sistem front-end sekaligus berfungsi menerjemahkan data yang dikirim oleh pengguna ke bentuk representasi yang didukung oleh back-end sistem informasi. Sistem ini juga berfungsi sebaliknya, menerjemahkan representasi data dalam bentuk XML ke bentuk yang dapat dimengerti secara langsung oleh pengguna. Sistem ini dikembangkan menggunakan bahasa pemrograman PHP dengan framework Code Igniter. Sistem diimplementasikan menggunakan konsep Model View Controller (MVC). Model yang dihasilkan tidak berkomunikasi dengan sistem basis data melainkan dengan back-end sistem informasi yang berada pada komputer yang bebeda menggunakan protokol HTTP. Data yang terkirim ke sistem front-end ini disimpan pada server lainnya, yaitu server back-end. Sistem menerjemahkan data yang diperoleh dari pengguna ke XML, lalu mengirimkannya kepada back-end sistem informasi yang berada pada komputer yang berbeda. Pembacaan data yang berasal dari sistem back-end dalam bentuk XML pun diterjemahkan ke dalam format data PHP sebelum ditampilkan kepada pengguna.
!
!
4.5
53
Implementasi back-end Sistem Informasi Geografis (SIG) Sistem dikembangkan menggunakan Geoserver 2.2 dan basis data
PostgreSQL 9.1 dengan ekstensi Postgis 2. Geoserver merupakan aplikasi server yang ditulis menggunakan bahasa Java yang ditujukan untuk melakukan manajemen data spasial. Pemilihan basis data PostgreSQL karena sistem harus dapat menampilkan tema kebun tertentu. Tema yang ada harus berdasarkan data yang tersimpan pada back-end sistem informasi. Penggunaan PostgreSQL menjadikan komunikasi antara back-end sistem informasi dengan back-end sistem informasi geografis dapat dilakukan lebih mudah. Perancangan back-end sistem informasi geografis pada penelitian ini dapat dilihat pada Gambar 19.
Gambar 19 Rancangan tampilan back-end sistem informasi Tema yang ada merupakan hasil pengolahan data di back-end sistem informasi yang disimpan pada tabel khusus di PostgreSQL. Setiap tema memiliki tabelnya masing-masing sehingga untuk tema Pohon terpilih, pohon siap polinasi, dan pohon siap panen memiliki tabel masing-masing list_individu_terpilih, list_individu_siap_polinasi,
!
dan
list_individu_siap_panen
di
basis
data
54 !
PostgreSQL. Tabel tersebut selanjutnya akan diproses oleh Geoserver untuk ditampilkan dalam bentuk peta pada peramban seperti pada Gambar 19. 4.6
Implementasi front-end Sistem Informasi Geografis (SIG) Peta yang ditampilkan oleh back-end SIG adalah peta statis karena
bersumber dari tabel basis data yang terpisah dari back-end sistem informasi. Tampilan peta secara real-time dapat diwujudkan dengan cara melakukan pembaruan terhadap isi dari tabel yang ada di back-end GIS setiap kali peta hendak ditampilkan oleh front-end SIG. Rancangan tampilan front-end sistem informasi memiliki komponen: header, sidebar, body, dan footer sesuai ilustrasi pada Gambar 20. Header berisi informasi dan logo perusahaan. Sidebar berisi navigasi terhadap setiap komponen sistem informasi. Body berisi data tabular dan form pengisian/pengubahan data yang diperlukan. Footer berisi informasi pendukung lainnya.
Gambar 20 Rancangan tampilan front-end sistem informasi Sistem ini (front-end SIG) akan melakukan request terhadap back-end SI sesuai tema yang dimaksud, kemudian sistem ini akan memperbarui isi tabel di back-end SIG. Tabel yang terbaru menyebabkan peta yang dihasilkan oleh backend SIG menjadi sesuai dengan kondisi lapangan (real-time). Proses pembaruan dan penampilan peta sesuai dengan Gambar 21.
!
!
55
Gambar 21 Proses pembaruan informasi tema peta x 4.7
Implementasi integrasi sistem Hasil akhir sistem terdiri atas dua sistem utama: Sistem Informasi (SI) dan
Sistem Informasi Geografis (SIG). Masing-masing sistem tersebut terdiri dari dua komponen utama: back-end dan front-end. Masing-masing komponen dari tiap sistem saling berkomunikasi menggunakan web service yang telah dirancang seperti terlihat pada Gambar 22.
Gambar 22 Arsitektur sistem
!
56 !
Sistem diimplementasikan pada komputer dengan spesifikasi sebagai berikut: 1.
Processor: Intel Core i5 2500K
2.
Memory: 8 GB
3.
Hardisk: Corsair Force GT 60 GB Sistem diimplementasikan dalam bentuk mesin virtual menggunakan
VirtualBox 4.1.22 dengan sistem operasi Ubuntu 10.4 LTS (front-end SI, backend SI, dan front-end SIG) dan Ubuntu 12.04 LTS (back-end SIG). Penggunaan sistem operasi yang berbeda untuk back-end SIG disebabkan kompabilitas dari basis data yang lebih baik pada versi tersebut. Implementasi secara detail untuk setiap komponen yaitu: 1.
Front-end SI (http://web.sem): PHP 5.4 dengan framework CodeIgniter 2.0
2.
Back-end SI (http://api.sem): PHP 5.4 dengan framework Restler 2, MySQL
3.
Front-end SIG (http://gis.sem): PHP 5.3 dengan framework CodeIgniter 2.0, Openlayers
4.
Back-end SIG (http://geoserver.sem): Geoserver 2.2, PostgreSQL 9.1 dengan ekstensi Postgis 2
4.8
Pengujian Sistem Pengujian sistem dilakukan dua tahap: pengujian back-end SI dan pengujian
front-end SI. Pengujian pada tahap pertama dilakukan menggunakan peramban Google
Chrome
dengan
add-on
Postman.
Pengujian
dilakukan
untuk
mensimulasikan proses komunikasi client-server menggunakan format data XML. Seluruh resource yang ada pada back-end SI diuji untuk setiap interface yang tersedia dan tidak tersedia. Pengujian terhadap interface yang tidak tersedia ditujukan untuk melihat kode respon yang diberikan apakah sesuai dengan rancangan atau tidak. 4.8.1 Pengujian operasi pada back-end SI Skenario pengujian yang dilakukan adalah melakukan operasi baca, tulis, sunting, dan hapus terhadap seluruh resource (URI) yang ada. Seluruh resource tersebut terdiri dari setiap resource dari setiap domain yang ada: garden,
!
!
57
marketing, factory, warehouse, dan human resources. Sebagai contoh untuk domain garden, diuji pembacaan terhadap resource yang bernama bunch (buah). Pengujian dilakukan dengan membuka peramban Google Chrome dengan addon Postman, lalu mengisi parameter berikut (Tabel 16) sebagai skenario pengujian. Tabel 16 Parameter pengujian resource dari garden/bunch/1 Parameter Nilai URL
http://api.sem/v1/garden/bunch/1
Interface
GET
Body Headers
Authorization: Basic c2VtOmxldG1laW4=
Hasil yang diperoleh menggunakan parameter tersebut adalah seperti pada Gambar 23. Hasil menunjukkan beberapa hal. Pertama, status yang bernilai “200” yang menunjukkan operasi berhasil dilakukan. Kedua adalah resource yang dikembalikan oleh server yang berisi representasi XML dari resource tersebut. Hasil pengujian pembacaan terhadap seluruh resource adalah berhasil.
Gambar 23 Hasil pengujian resource /garden/bunch/1 Pengujian terhadap operasi penulisan dilakukan dalam tiga tahap: 1. Pembacaan terhadap seluruh resource yang ada untuk membuktikan resource yang akan dibuat belum ada di sistem.
!
58 !
2. Pengiriman data XML ke server menggunakan interface POST dan kode respon yang diterima dari server harus bernilai “201” yang menunjukkan resource tersebut berhasil dibuat. 3. Pembacaan terhadap resource baru tersebut untuk menunjukkan bahwa resource tersebut saat itu telah ada. Parameter yang digunakan pada pengujian penulisan baru dari resource /garden/bunch/ terdapat pada Tabel 17. Pada operasi pembuatan baru, id dari resource yang hendak dibuat tidak dimasukkan pada URL karena id tersebut dibangkitkan secara otomatis oleh server. Hasil pengujian penulisan terhadap seluruh resource adalah berhasil. Tabel 17 Parameter pengujian pembuatan resource baru dari garden/bunch/ Parameter Nilai URL
http://api.sem/v1/garden/bunch/
Interface
POST
Body
0001treehttp://api.sem/v1/garden/tree/g10101d
Headers
Authorization: Basic c2VtOmxldG1laW4=
Pengujian terhadap operasi penyuntingan dilakukan dalam tiga tahap: 1. Pembacaaan terhadap resource tersebut untuk menunjukkan resource yang ingin disunting telah ada sebelumnya. 2. Pengiriman representasi XML terhadap URL resource tersebut yang memiliki isi berbeda dengan isi pada tahap pertama. Kode respon yang diterima harus bernilai “200” yang menunjukkan bahwa resource yang ada telah berhasil disunting.
!
!
59
3. Pembacaan terhadap resource tersebut untuk menunjukkan bahwa resource tersebut telah berubah sesuai dengan representasi XML yang dikirim pada tahap kedua. Parameter yang digunakan pada operasi penyuntingan ditunjukkan pada Tabel 18. Pada dasarnya parameternya mirip dengan operasi pembuatan baru, bedanya terletak pada URL yang dituju telah memuat id dari resource yang bersangkutan. Perbedaan lainnya adalah body dari operasi penyuntingan tidak harus berisi seluruh atribut dari resource tersebut. Atribut yang ingin disunting sajalah yang dimasukkan pada body. Hasil pengujian penulisan terhadap seluruh resource adalah berhasil, baik penyuntingan seluruh atribut resource maupun sebagian dari atribut yang ada. Tabel 18 Parameter pengujian penyuntingan resource dari garden/bunch/1 Parameter Nilai URL
http://api.sem/v1/garden/bunch/
Interface
PUT
Body
0002
Headers
Authorization: Basic c2VtOmxldG1laW4=
Pengujian terhadap operasi penghapusan dilakukan dalam tiga tahap: 1. Pembacaan resource yang ingin dihapus untuk menunjukkan bahwa resource tersebut sebelumnya telah ada, dan hendak dihapus. 2. Pengiriman operasi menggunakan interface DELETE terhadap URL resource tersebut. Kode respon yang diterima dari server harus bernilai “200” yang menunjukkan bahwa proses penghapusan berhasil dilakukan. 3. Pembacaan terhadap resource yang telah dihapus pada tahap kedua. Hasil kode respon yang diterima harus “404” yang berarti resource yang dibaca pada tahap ini tidak ditemukan karena telah terhapus. Parameter yang digunakan pada penghapusan ditunjukkan pada Tabel 19. Pada operasi penghapusan yang berhasil, server tidak mengirim body kepada
!
60 !
client, yang dikirim hanya kode “200” yang menunjukkan operasi berhasil. Hasil pengujian penghapusan terhadap seluruh resource adalah berhasil. Tabel 19 Parameter pengujian penghapusan resource dari garden/bunch/1 Parameter Nilai URL
http://api.sem/v1/garden/bunch/1
Interface
DELETE
Body Headers
Authorization: Basic c2VtOmxldG1laW4=
4.8.2 Pengujian kode respon pada back-end SI Setiap kode respon yang telah didefinisikan sebelumnya diuji dengan sekenario yang berbeda-beda sedemikian hingga kode tersebut muncul sesuai dengan yang diharapkan. Pengujian dilakukan terhadap seluruh resource yang ada dan untuk semua interface yang digunakan. Secara garis besar, pengujian setiap interface dilakukan menggunakan kode respon seperti GET (Tabel 20), PUT (Tabel 21), POST (Tabel 22), dan DELETE (Tabel 23). Tabel 20 Skenario umum pengujian kode respon pada interface GET Kode Skenario
Status
200
Membaca resource yang ada. Server memberikan kode “200” beserta representasi XML dari resource yang bersangkutan
Berhasil
204
Resource di basis data dikosongkan, kemudian dilakukan pembacaan terhadap resource tersebut. Server memberikan kode “204” tanpa ada tambahan representasi resource.
Berhasil
401
Pembacaan dilakukan tanpa menyertakan header untuk otorisasi
Berhasil
404
Pembacaan resource yang tidak ada atau membaca resource dengan id tertentu yang tidak ada pada basis data
Berhasil
406
Pembacaan dengan header tambahan berupa permintaan format representasi lain seperti CSV, XLS, dll yang tidak didukung oleh server (server hanya mendukung XML)
Berhasil
500
Server dikondisikan error sehingga tidak dapat melayani segala macam operasi
Berhasil
Tabel 21 Skenario umum pengujian kode respon pada interface PUT
!
!
61
Kode Deskripsi
Status
200
Penyuntingan terhadap resource dilakukan, saat server merespon dengan kode “200” kemudia diperiksa di basis data apakah telah berubah sesuai proses suntingan. Saat data di basis data berubah maka kode “200” tersebut adalah benar
Berhasil
401
Operasi dilakukan tanpa menyertakan header untuk otorisasi
Berhasil
404
Penyuntingan suatu resource dengan id yang tidak terdaftar di sistem
Berhasil
409
Penyuntingan dilakukan dengan mengubah id dengan id yang telah terdaftar sehingga server mendeteksi potensi duplikasi
Berhasil
415
Body representasi data yang dikirim dalam bentuk selain XML, misalnya JSON dan CSV
Berhasil
500
Server dikondisikan error sehingga tidak dapat melayani segala macam operasi
Berhasil
Tabel 22 Skenario umum pengujian kode respon pada interface POST Kode Deskripsi
Status
201
Pembuatan suatu resource yang berhasil seharusnya memberikan kode “201”
Berhasil
400
Body yang dikirim saat pembuatan resource dirancang memiliki atribut yang tidak lengkap sehingga server mengirimkan kode “400”
Berhasil
401
Operasi dilakukan tanpa menyertakan header untuk otorisasi
Berhasil
404
Pembuatan resource dengan URL ditujukan pada resource yang tidak terdaftar di sistem, misalnya
Berhasil
/garden/weeding
!
409
Pembuatan suatu resource dengan nama atau id yang telah terdaftar sebelumnya. Misalnya /garden/bunch/1 memiliki atribut label bernilai “abc”, sistem diuji dengan mencoba membuat resource di /garden/bunch dengan label berisi “abc”
Berhasil
415
Pengiriman representasi data dalam format yang tidak didukung oleh server, misalnya CSV
Berhasil
500
Server dikondisikan error sehingga tidak dapat melayani segala macam operasi
Berhasil
62 !
Tabel 23 Skenario umum pengujian kode respon pada interface DELETE Kode Deskripsi
Status
200
Penghapusan salah satu resource, kemudian diperiksa di basis data apakah telah berhasil dihapus. Saat data berhasil dihapus dan server memberikan kode “200” maka kode tersebut valid
Berhasil
401
Operasi dilakukan tanpa menyertakan header untuk otorisasi
Berhasil
404
Pengujian dengan mencoba menghapus suatu resource dengan id yang tidak terdaftar pada sistem
Berhasil
500
Server dikondisikan error sehingga tidak dapat melayani segala macam operasi
Berhasil
Kode respon yang memiliki makna sama adalah kode 401, 404, dan 500 terlepas dari jenis operasi yang dilakukan. Hal tersebut disebabkan karena kode tersebut merupakan respon terhadap kesalahan yang dilakukan/terjadi terlepas dari operasi yang dilakukan. Sebagai contoh kode 500 yang terjadi akibat kesalahan konfigurasi server atau kode pemrograman, akan menyebabkan segala bentuk operasi menjadi gagal dan tidak dapat diolah. 4.8.3 Pengujian operasi pada back-end SIG Pengujian dilakukan untuk memastikan Geoserver telah terkoneksi dengan basis data PostgreSQL dan menampilkan data spasial yang dimaksud. Pengujian koneksi dilakukan dengan cara sederhana yaitu mematikan basis data lalu mencoba menjalankan Geoserver untuk menampilkan peta yang dimaksud. Geoserver harus tidak dapat menampilkan peta karena koneksi terputus. Pengujian keabsahan tampilan peta dilakukan dengan cara menghapus baris yang ada pada basis data dengan tujuan melihat perubahan yang dimunculkan oleh Geoserver seperti pada Gambar 24. Pada Gambar 24(a) tanaman terpilih ditampilkan pada peta. Titik berwarna abu-abu yang ditunjuk oleh panah merah dalam kondisi sebagai tanaman tidak terpilih. Selanjutnya satu baris ditambahkan pada basis data yang berisi daftar tanaman yang terpilih, kemudian dilakukan pemuatan ulang peta tersebut untuk melihat perubahan yang terjadi pada peta. Pengujian berhasil saat peta yang ditampilkan telah merefleksikan keadaan pada basis data yang ada, yaitu titik berwarna hijau (Gambar 24b).
!
!
63
(a)
(b) Gambar 24 Tampilan peta, (a) peta tanaman terpilih dari basis data asli, (b) salah satu baris telah ditambahkan 4.8.4 Pengujian operasi pada front-end SIG Pengujian dilakukan dengan menjalankan aplikasi front-end SI lalu memilih bagian peta dan memeriksa peta yang ditampilkan oleh peramban. Pengujian dianggap berhasil ketika peta yang ditampilkan merefleksikan keadaan pada basis data. 4.8.5 Pengujian operasi pada front-end SI Pengujian tahap selanjutnya adalah pengujian sistem utuh yang merupakan hasil dari kerjasama antara keempat sistem yang ada: back-end SI, back-end SIG, dan front-end SIG. Pengujian dilakukan untuk menguji seluruh operasi
!
64 !
pembacaan, penyimpanan, dan penghapusan data yang ada pada seluruh domain perusahaan. Skenario yang digunakan untuk pengujian front-end SI adalah dengan melakukan operasi pembacaan, pembuatan, penyuntingan, dan penghapusan terhadap setiap resource yang ada melalui sistem yang ada. Secara garis besar pengguna adalah sebagai berikut: a. Skenario membuka sistem pada peramban Skenario
:
Pengguna membuka peramban lalu memasukkan URL http://api.sem/v1/
Kondisi berhasil
:
Sistem ditampilkan pada peramban tersebut
Kondisi gagal
:
Peramban tidak menampilkan sistem pada peramban
Hasil
:
Berhasil
b. Skenario menampilkan data kosong Skenario
:
Pengguna membuka salah satu modul pada domain tertentu dengan kondisi basis data yang kosong/belum terisi
Kondisi berhasil
:
Sistem ditampilkan tanpa data apapun
Kondisi gagal
:
Sistem ditampilkan dengan data
Hasil
:
Berhasil
c. Skenario menambah data baru Skenario
:
Pengguna menekan tombol “tambah data” pada sistem, kemudian mengisi form yang ada.
Kondisi berhasil
:
Sistem menampilkan notifikasi bahwa data berhasil ditambahkan, kemudian data tersebut ditampilkan pada tabel yang sebelumnya kosong
Kondisi gagal
:
Sistem tidak memberikan respon apapun
Hasil
:
Berhasil
d. Skenario menyunting data pada tabel
!
Skenario
:
Pengguna memilih salah satu baris pada tabel kemudian memilih tombol “Ubah data”, kemudian mengisi form yang ada.
Kondisi berhasil
:
Sistem menampilkan notifikasi bahwa data berhasil disunting, kemudian data tersebut ditampilkan pada tabel sesuai dengan penyuntingan sebelumnya
!
65
Kondisi gagal
:
Sistem tidak memberikan respon apapun
Hasil
:
Berhasil
e. Skenario menghapus data baru Skenario
:
Pengguna memilih salah satu baris pada tabel kemudian memilih tombol “Hapus data”
Kondisi berhasil
:
Sistem menampilkan notifikasi bahwa data berhasil dihapus, kemudian data tersebut hilang dari tabel
Kondisi gagal
:
Sistem tidak memberikan respon apapun
Hasil
:
Berhasil
!
4.8.6 Pengujian integrasi sistem Seluruh sistem yang ada dinyalakan menggunakan VirtualBox, lalu pada sistem operasi host dilakukan operasi pembacaan, penulisan, penyuntingan dan penghapusan data melalui front-end SI untuk melihat konsistensi data yang ada. Sistem dianggap berhasil ketika perubahan yang dilakukan melalui front-end SI dapat dilayani oleh front-end SI dan memiliki hasil yang sama dengan basis data. Pada beberapa modul dengan ketergantungan tinggi sistem harus dapat menampilkan/tidak menampilkan data sesuai dengan state dari data tersebut. Segala penambahan/pengurangan data pada suatu modul harus dapat diolah dengan benar pada modul lain yang tergantung pada modul tersebut. Sebagai contoh modul panen, sistem harus dapat menampilkan tanaman yang buahnya telah dimasukkan dalam modul polinasi. Saat buah tersebut telah masuk ke basis data panen, maka sistem harus tidak menampilkan buah tersebut dari pilihan buah yang siap dipanen. Pengujian pada tahap ini telah berhasil karena modul sistem dapat menunjukkan hasil pengolahan data dari sistem informasi lainnya. Pengujian terhadap SIG dilakukan dengan menambah/menghapus identitas tanaman yang ditampilkan pada peta untuk melihat perubahan yang terjadi secara langsung pada peta yang ada. Hasil pengujian menunjukkan peta yang diakses melalui front-end SI menampilkan kondisi sesuai dengan basis data (yang sedang diuji).
!
66 !
4.9 Dokumentasi Dokumentasi yang ada terdiri atas dua buah: dokumentasi teknis dan dokumentasi perancangan. Dokumentasi perancangan dapat dilihat pada Lampiran diagram domain (Lampiran 2) dan Lampiran perancangan URI (Lampiran 3), sedangkan dokumentasi teknis diletakkan langsung pada sistem operasi dari sistem yang bersangkutan. Dokumentasi teknis berisi konfigurasi sistem beserta konfigurasi jaringan supaya sistem dapat berjalan dan berkomunikasi dengan sistem lainnya seperti konfigurasi akun basis data, format data, dan konfigurasi spesifik basis data (Postgre SQL).
!
BAB V SIMPULAN DAN SARAN
5.1
Simpulan Penelitian berhasil menganalisis dan mengimplementasikan dua buah sistem
informasi: sistem informasi operasional (SI) dan sistem informasi geografis (SIG). Pada penelitian ini juga berhasil membuat kedua sistem yang heterogen dapat berkomunikasi satu sama lain dengan lancar. Sistem informasi yang dikembangkan menggunakan REST web service terbukti mempermudah pengembangan dan integrasi komponen sistem yang berjumlah sekitar 95 resource. Sistem informasi geografis yang ada dapat berkomunikasi dengan mengolah data yang ada pada sistem informasi lainnya menggunakan web service tersebut karena standard komunikasi data yang ada. Penambahan atau pengurangan komponen sistem informasi geografis dapat dilakukan lebih mudah karena keterikatan antara komponen yang rendah. Keterikatan yang rendah tersebut menyebabkan efek yang ditimbulkan menjadi minimal. 5.2
Saran Penelitian lanjutan perihal kemampuan pencarian (query) terhadap resource
berdasarkan atribut yang dimiliki beserta penggunaan format representasi resource lainnya seperti JSON, CSV, dan sebagainya yang selanjutnya dianalisis performa dan fleksibilitas dari sistem yang ada. Penelitian terhadap performa dan efisiensi dari model yang ada beserta penerapan aspek-aspek teknis seperti security, load-balancing, cache-server, proxy dan teknologi server yang sedang berkembang lainnya. Pengembangan sistem lebih lanjut perlu dilakukan oleh perusahaan terhadap implementasi sistem berbasis mobile menggunakan model yang ada, dengan memanfaatkan perangkat keras yang terdapat pada perangkat mobile tersebut seperti GPS, kamera, sms, dan lainnya untuk membuktikan kemampuan adaptasi dari model yang ada.
67! !
!
68 !
!
DAFTAR PUSTAKA Breitman K, Casanova MA, Truszkowski W. 2007. Semantic Web: Concepts, Technologies and Applications. Springer. London, UK. Berners LT, Fielding R, Mesinter L. 2005. Uniform Resource Identifier (URI): Generic Syntax. The Internet Engineering Task Force (IETF), RFC3986. CodeIgniter. http://www.codeigniter.com [1 Juli 2012]. Fielding R. 2000. Architectural Styles and the Design of Network-based Software Architectures,Doctoral dissertation, University of California, Irvine. Fielding R et al. 1999. Hypertext Transfer Protocol -- HTTP/1.1. Internet Engineering Task Force (IETF). http://www.ietf.org/rfc/rfc2616.txt [1 Juli 2012]. Filho OFF, Ferreira MAGV. 2009. Semantic Web Service: A RESTful Approach. University of São Paulo, Polytechnic School São Paulo, Brazil. Geoserver. http://www.geoserver.org. Gregorio J et al. 2012. Uri Template. Internet Engineering Task Force (IETF). http://tools.ietf.org/html/rfc6570 [1 Juli 2012] . Hamad H, Saad M, Abed R. 2010. Performance Evaluation of RESTful Web Services for Mobile Devices. Computer Engineering Department. Islamic University of Gaza, Palestine. Higashino WA, Toledo BF, Capretz MAM. 2009. REST and Resource Oriented Architecture. Proceedings First International Symposium on Services Science ISSS’09, Logos, Berlin. Pahan I. 2010. Panduan lengkap kelapa sawit, manajemen agribisnis dari hulu hingga hilir. Jakarta: Penebar Swadaya. Pautasso C, Zimmermann O, Leymann F. 2008. RESTful Web Services vs. "Big" Web Services: Making the Right Architectural Decision. WWW 2008 / Refereed Track: Web Engineering - Web Services Deployment. Beijing, China. Richardson L, Ruby S. 2007. Restful web service. O’Reilly Media. Roth G. 2012. RESTful HTTP in practice, pada Rest eMAG. Sommerville I. 2010. Software engineering / Ian Sommerville. — 9th ed. Addison-Wesley.
69! !
70 !
Ubuntu Debian-derived Linux distribution. http://www.ubuntu.com [1 Juli 2012]. W3C Working Group Note 11 February 2004. Web Services Architecture. W3C. 2003. W3C Glossary and Dictionary. http://www.w3.org/2003/glossary/ [1 Juli 2012].
!
! ! ! ! ! ! ! ! ! ! ! ! ! !
LAMPIRAN
71! !
! 72 !
!
!
Lampiran 1 Kegiatan pembibitan di perusahaan
!
73
74 !
Lampiran 2 Diagram domain bisnis di perusahaan 2.1. Pembibitan
!
!
Lampiran 2 Diagram domain bisnis di perusahaan 2.2. Kebun
!
75
76 !
Lampiran 2 Diagram domain bisnis di perusahaan 2.3. Gudang
!
!
Lampiran 2 Diagram domain bisnis di perusahaan 2.4 Pabrik (Seed Garden Factory)
!
77
78 !
Lampiran 2 Diagram domain bisnis di perusahaan 2.5. Pemasaran dan administrasi
!
!
79
Lampiran 2 Diagram domain bisnis di perusahaan 2.6 Kepegawaian
!
!
80 !
Lampiran 3 Rancangan template URI Interface yang digunakan terdiri dari GET, PUT, POST, dan DELETE. Interface GET digunakan untuk membaca suatu resource, PUT digunakan untuk memodifikasi resource, POST digunakan untuk membuat resource baru, dan DELETE digunakan untuk menghapus resource. Request terhadap URI membutuhkan parameter id pada interface GET, PUT, dan DELETE karena beroperasi terhadap resource spesifik. Pada interface POST dilakukan tanpa menuliskan id pada URI resource yang bersangkutan, karena id tersebut akan dibangkitkan oleh server. Request menggunakan GET dapat dilakukan tanpa menuliskan id dan akan memberikan hasil berupa list dari seluruh resource yang ada pada URI tersebut. Penelitian ini menghasilkan sebanyak 95 template URI beserta interface yang dapat dilakukan terhadapnya pada tabel berikut. Setiap URI memiliki parameter tertentu. URI dengan parameter {*id} berarti dapat tidak memiliki parameter sama sekali. URI yang tidak memiliki interface POST, PUT, atau DELETE akan berakibat pengembalian kode respon 405 (Method not allowed).
!
!
Bunch Bag Consignment Cold Room Germinating Heating Room Sale Selection
