BAB IV HASIL DAN PEMBAHASAN
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 <item> <number>0001</number> <label> g10101d -0001-2012</label> <link> <rel>tree</rel> <href>http://api.sem/v1/garden/tree/g10101d </href> </link> </item>
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 <item> <number>0002</number> </item>
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
! 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 /garden/weeding
Berhasil
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
! 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).
67! 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.
! 68 !
69! 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.
! 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].
71! ! ! ! ! ! ! ! ! ! ! ! ! ! ! LAMPIRAN
! 72 !
! 73
! 74
Lampiran 2 Diagram domain bisnis di perusahaan 2.1. Pembibitan
! 75
Lampiran 2 Diagram domain bisnis di perusahaan 2.2. Kebun
! 76
Lampiran 2 Diagram domain bisnis di perusahaan 2.3. Gudang
! 77
Lampiran 2 Diagram domain bisnis di perusahaan 2.4 Pabrik (Seed Garden Factory)
! 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).
81 Lampiran 3 Rancangan template URI
3.1 Template URI untuk domain factory
No Resource URI Interface GE T PO ST PU T DE L E T E
1 Bunch Bag factory/bunch_bag/{*id} v v v v
2 Consignment factory/consignment/{*id} v v v v
3 Cold Room factory/cooling/{*id} v v v v
4 Germinating factory/germinating/{*id} v v v v
5 Heating Room factory/heating/{*id} v v v v
6 Sale factory/saleable/{*id} v v v v
7 Selection factory/selection/{*id} v v v v
3.2 Template URI untuk domain human resource
No Resource URI Interface GE T PO ST PU T DE L E T E 1 Division hr/division/{*id} v v v v 2 Employee hr/employee/{*id} v v v v 3 Presence hr/presence/{*id} v v v v
4 Presence's Item hr/item_presence/{presence_id} v
Lampiran 3 Rancangan template URI 3.3 Template URI untuk domain prenursery
No Resource URI Interface GE T PO ST PU T DE L E T E 1 Cultivation prenursery/cultivation/{*id} v v v v
2 Polybag Production prenusery/polybag_production/{*id} v v v v
3 Polybag Usage prenursery/polybag_usage/{*id} v v v v
4 Repotting prenursery/repotting/{*id} v v v v
5 Sale prenursery/sale/{*id} v v v v
6 Stock prenursery/stock/{*id} v v v v
7 Stock by Age prenursery/stock_age/{*id} v v v v
3.4 Template URI untuk domain mainnursery
No Resource URI Interface GE T PO ST PU T DE L E T E 1 Census mainnursery/census/{*id} v v v v 2 Cultivation mainnursery/cultivation/{*id} v v v v !
83
Lampiran 3 Rancangan template URI
3.4 Template URI untuk domain mainnursery (lanjutan)!
No Resource URI Interface GE T PO ST PU T DE L E T E 1 Census mainnursery/census/{*id} v v v v 2 Cultivation mainnursery/cultivation/{*id} v v v v 3 Sale mainnursery/sale/{*id} v v v v 4 Stock mainnursery/stock/{*id} v v v v
5 Stock by Age mainnursery/stock_age/{*id} v v v v
3.5 Template URI untuk domain nursery
No Resource URI Interface GE T PO ST PU T DE L E T E 1 Seedling nursery/seedling/{*id} v v v v
Lampiran 3 Rancangan template URI 3.6 Template URI untuk domain warehouse
No Resource URI Interface GE T PO ST PU T DE L E T E 1 BPB warehouse/bpb/{*id} v v v v 2 BPB's item warehouse/item_bpb/{bpb_id} v 3 Goods warehouse/goods/{*id} v v v v
4 Goods' unit warehouse/goods_unit/{*id} v v v v
5 SKB warehouse/skb/{*id} v v v v 6 SKB's item warehouse/item_skb/{skb_id} v 7 SPB warehouse/spb/{*id} v v v v 8 SPB's item warehouse/item_spb/{spb_id} v 9 Stock warehouse/stock/{*id} v v v v 10 TTG warehouse/ttg/{*id} v v v v 11 TTG's item warehouse/item_ttg/{ttg_id} v
85 Lampiran 3 Rancangan template URI
3.7 Template URI untuk domain marketing
No Resource URI Interface GE T PO ST PU T DE L E T E 1 BAP marketing/bap/{*id} v v v v
2 BAP's item marketing/item_bap/{bap_id} v
3 Contract marketing/contract/{*id} v v v v
4 Contract's Attachment marketing/file/{file_id} v
5 Customer marketing/customer/{*id} v v v v
6 Delivery marketing/delivery/{*id} v v v v
7 Delivery's item marketing/item_delivery/{delivery_id} v
8 Customer's Invoice marketing/invoice_customer/{*id} v v v v
9 Customer's Invoice's item marketing/item_invoice_customer/{invoice_customer_id} v
10 Supplier's Invoice marketing/invoice_supplier/{*id} v v v v
11 Supplier's Invoice's item marketing/item_invoice_supplier/{invoice_suplier_id} v
12 Order marketing/order/{*id} v v v v
13 Order's item marketing/item_order/{order_id} v
14 Customer's payment marketing/payment_customer/{*id} v v v v
15 Customer's payment's item marketing/item_payment_customer/{payment_customer_id} v
16 Supplier's payment marketing/payment_supplier/{*id} v v v v