BAB III ANALISIS DAN PERANCANGAN

BAB III ANALISIS DAN PERANCANGAN Kondisi pengolahan data yang telah dijabarkan sebelumnya pada bab 1 (satu) memiliki keterkaitan terhadap permasalahan yang teridentifikasi. Yaitu permasalahan terkait desain database, keamanan data, dan pemrosesan data yang lama. 1 2 Ambil Row Data Table Raw Decode Database MySQL Filtering Data, dll.. 3 Decode Aplikasi Pengolah Data Aplikasi Data Parser 5 Tabel Data Element Pembentuk 4 DML Ambil Row Data Database MySQL Aplikasi Pengolah Data Gambar 3.1 Contoh Model Pengolahan Data Dengan Aplikasi 23

24 Untuk desain pengolahan data di luar database: 1 2 Ambil Row Data Table Raw Decode Database MySQL Filtering Data, dll.. Aplikasi Pengolah Data Gambar 3.2 Model pengolahan di luar database Model ini dari sisi keamanan lebih baik, dikarenakan data tersimpan dalam database dalam bentuk ter-encode. Level aplikasi yang bertanggungjawab melakukan pemrosesan (decode) data. Permasalahan lamanya pemrosesan data akan terjadi dengan desain ini. Problem tersebut disebabkan karena untuk melakukan proses DML terhadap data (komparasi, filtering, dll) data mentah perlu diambil dari database tanpa dilakuan pembatasan terlebih dahulu. Sebagai contoh, pada database terdapat 1000 data, maka untuk melakukan pencarian data dengan kriteria tertentu (misalnya Data Element 2 (PAN) bernilai 1234 ) maka seluruh data akan diambil terlebih dahulu dari database, kemudian diproses di sisi aplikasi untuk selanjutnya dilakukan pembacaan data PAN dan dilakukan pengecekan sesuai dengan kriteria yang dimaksud. Model berikutnya adalah model pengolahan data di dalam database:

25 1 2 Table Raw Decode Database MySQL Aplikasi Data Parser 4 Proses Pengolahan Dengan Query Tabel Data Element Pembentuk 3 DML Aplikasi Pengolah Data Database MySQL Gambar 3.3 Model pengolahan di dalam database Pendekatan dengan model ini memberikan keunggulan, yaitu proses DML benar-benar dapat dilakukan di level database. Permasalahan yang teridentifikasi adalah: 1. Perlu ada sebuah proses data parser yang pada intinya adalah melakukan proses decode data, sebelum database siap untuk dipergunakan 2. Desain database tetap, menyebabkan untuk pengembangan produk baru memerlukan perubahan struktur database. Dalam hal ini adalah penambahan field terkait penambahan Data Element baru yang dipergunakan 3. Data transaksi tersimpan dalam bentuk terang menjadi celah keamanan Dari kedua model tersebut di atas serta permasalahan yang teridentifikasi, penulis dapat menyimpulkan bahwa solusi masalah adalah dengan memindahkan proses decode pada level database. Sehingga database dapat melakukan operasi DML terhadap data secara langsung. Hal ini akan memperkecil pengambilan data secara keseluruhan dari database.

26 Dari segi keamanan akan menjaga data transaksi dalam keadaan terencode di dalam database. Namun disisi lain dengan adanya fungsi ini maka dengan mudah proses decode data dilakukan tanpa menggunakan aplikasi di luar database. Menyebabkan isu keamanan tetap menjadi hal perlu dikaji lebih jauh. Dari segi desain database menjadi lebih fleksibel untuk pengembangan selanjutnya. Perubahan struktur database dapat dihindarkan, karena pada database hanya cukup menampung sebuah data dalam bentuk ter-encode. 3.1 Rancangan Solusi Memindahkan proses decode di level database MySQL dapat dilakukan dengan pembuatan User Defined Function (UDF) MySQL. Dengan menambah sebuah fungsi internal MySQL untuk melakukan decode. Decode Table Raw Filtering Data, dll.. Ambil Row Data Database MySQL Aplikasi Pengolah Data Gambar 3.4 Model pengolahan data dengan solusi Perancangan solusi ini akan terdiri dari 2 bagian utama yaitu: 1. Melakukan perancangan algoritma decoder Algoritma decode perlu dibangun untuk selanjutnya dapat diimplementasikan dalam bentuk UDF MySQL. Perancangan modul ini akan dibahas pada subbab 3.4.

27 2. Melakukan perancangan UDF sebagai wrapper dari fungsi decoder Untuk mengenalkan fungsi decoder kepada database engine MySQL, perlu dilakukan pembuatan sebuah shared library mengikuti standar spesifikasi UDF MySQL. Perancangan modul ini akan dibahas pada subbab 3.2 dan 3.3. 3.2 Deskripsi Umum Perangkat Lunak Perangkat lunak yang dibangun akan melayani dan mengenalkan MySQL kepada fungsi baru untuk kebutuhan decode message secara langsung (internal database engine). Sehingga diharapkan pada tingkat aplikasi tidak perlu melakukan proses decode data, namun cukup mengirimkan query kepada MySQL. Hal ini diharapkan dapat menyelesaikan permasalahan yang sebelumnya telah teridentifikasi. Perangkat lunak yang dimaksud akan diberdayakan oleh MySQL pada saat fungsi baru tersebut dipergunakan dalam sebuah query data menggunakan standar SQL yang ada. Spesifikasi umum perangkat lunak yang dibangun: 1. Mampu melakukan decode message ; dalam artian mampu melakukan kalkulasi nilai sebuah Data Element pada suatu data message. 2. Mampu memberikan informasi hasil decode sebuah Data Element. 3. Mampu memberikan informasi status sebuah Data Element ada atau tidak. 4. Mampu memberikan pesan error jika ditemukan message ISO- 8583 yang tidak sesuai spesifikasi standar. 5. Perangkat lunak yang dibangun akan mengikuti spesifikasi pengembangan pustaka User Defined Function MySQL. Berikut merupakan skema umum perangkat lunak yang menggambarkan alur proses umum perangkat lunak yang dikembangkan.

28 Client MySQL MySQL Database Engine Decoder Applikasi External Mengeksekusi fungsi melalui query (SQL) Mengenal fungsi Decode, dan melakukan passing data ke fungsi Decoder Melakukan fungsi decode dan mengembalikan hasilnya Applikasi External Menerima hasil query Menerima output dari modul decoder dan mengembalikan hasil kepada client Gambar 3.5 Alur Umum Proses Aplikasi 3.3 Model Use Case Dikarenakan aktor dalam sistem yang dikembangkan merupakan database engine MySQL maka penggambaran use case atau interaksi dengan system yang dikembangkan mengikuti standar pengembangan UDF MySQL. Dimana akan selalu terdapat 3 (tiga) use case. 3.3.1 Diagram Use Case Diagram use case yang menggambarkan use case yang ada, yang akan dipergunakan oleh aktor (database engine MySQL) dapat digambar sebagai berikut.

29 System Fungsi Init Fungsi Main MySQL Server Fungsi Deinit Gambar 3.6 Diagram Use Case Secara umum akan selalu terdapat tiga fungsi yang dapat dilakukan oleh aktor. Yaitu fungsi init, fungsi main, dan fungsi deinit. Pada saat fungsi init aktor akan melakukan inisiasi fungsi decoder ISO- 8583, sehingga fungsi dapat dikenali oleh MySQL server. Fungsi main merupakan inti proses decode yang akan mengembalikan nilai data element dari sebuah data. Fungsi deinit merupakan fungsi yang akan dipergunakan oleh aktor setelah fungsi inti dipanggil. 3.3.2 Definisi Aktor Terdapat 1 (satu) aktor dalam perangkat lunak ini yaitu database engine MySQL, dimana aktor ini akan melakukan inisialisasi fungsi, memanggil fungsi utama dan melakukan deinisialisasi fungsi. 3.3.3 Definisi Use Case ID Use Case Deskripsi UC-1 Inisialisai Fungsi Aktor DBE MySQL melakukan inisialisasi fungsi decode untuk menentukan jumlah, tipe parameter pada fungsi decode, tipe output fungsi dan

30 melakukan alokasi memori yang dibutuhkan UC-2 Pemanggilan Fungsi Decode Aktor DBE MySQL melakukan pemanggilan fungsi decode dengan parameter yang sebelumnya didefinisikan UC-3 Finalisasi Fungsi Aktor DBE MySQL melakukan finalisasi sehingga seluruh alokasi memori dibebaskan 3.3.4 Skenario Use Case ID Nama Use Case Deskripsi : UC-1 : Inisialisasi Fungsi : Aktor DBE MySQL melakukan inisialisasi fungsi decode untuk menentukan jumlah, tipe parameter pada fungsi decode, tipe output fungsi dan melakukan alokasi memori yang dibutuhkan Aksi Aktor Skenario Normal 1. Aktor menerima query dengan fungsi decode iso8583 dari client 2. Aktor melakukan pengecekan apakah fungsi yang dimaksud ada 3. Aktor manggil fungsi Init Skenario Alternatif 1. Aktor menerima query dengan fungsi decode iso8583 dari client Aksi Sistem / Perangkat Lunak 4. Modul decoder melakukan pengecekan jumlah parameter yang dikirim oleh aktor 5. Modul decoder menginformasilan parameter yang terdapat dalam modul

31 2. Aktor melakukan pengecekan apakah fungsi yang dimaksud ada 3. Aktor manggil fungsi Init 4. Jumlah parameter input dari aktor kurang, modul menginformasikan bahwa ada parameter yang kurang ID Nama Use Case Deskripsi : UC-2 : Pemanggilan Fungsi Decode : Aktor DBE MySQL melakukan pemanggilan fungsi decode dengan parameter yang sebelumnya didefinisikan Aksi Aktor Skenario Normal 1. Aktor memanggil fungsi decode dengan parameter input berupa text atau field dengan data ISO- 8583, serta nomor data element yang akan didecode Aksi Sistem / Perangkat Lunak 2. Modul melakukan proses decode dan mengembalikan nilai data element yang dimaksud ID Nama Use Case Deskripsi : UC-3 : Finalisasi Fungsi : Aktor DBE MySQL melakukan finalisasi sehingga seluruh alokasi memori dibebaskan Aksi Aktor Skenario Normal 1. Aktor telah selesai dalam melakukan pemanggilan fungsi decode 2. Aktor memanggil finalisasi fungsi Aksi Sistem / Perangkat Lunak 3. Modul melakukan pembebasan seluruh alokasi memori yang telah dipergunakan

32 3.4 Rancangan Algoritma Decoder Format data :1987 secara umum akan selalu terdiri dari 3 (tiga) bagian yaitu Message Type Identification, Bitmap, dan Data Element. Bitmap sendiri memiliki dua kemungkinan yaitu 64-bit atau 128-bit. Untuk mempermudah perancangan penulis melakukan pengambilan contoh data dalam format :1987 untuk selanjutnya dipergunakan dalam proses perancangan algoritma. Tabel 3.1 Contoh Data :1987 0200323E8001288010000110000000500000000317121200002050121200 0317000578132710042804246212345678901234567=1212000000230579 A1B2C3D4FFFFFFFFFFFFFFFF Untuk proses decode message perlu pertama dilakukan adalah membaca Bitmap, karena dari informasi ini maka diketahui keberadaaan serta cara pembacaan data berikutnya (Data Element). Berikut merupakan alur proses algoritma yang digambarkan dalam diagram blok: Data Pembacaan Data MTI Pembacaan Data Element Pembacaan Data Bitmap Proses berulang Gambar 3.7 Alur Proses Algoritma

33 3.4.1 Pembacaan Data Message Type Indicator Pembacaan Message Type Indicator (MTI) dari sebuah raw message ISO- 8583 dapat dilakukan dengan menggunakan algoritma yang sederhana. Hal tersebut dikarenakan konten data ini bersifat statik, dalam artian panjang data tidak berubah-ubah. Seperti yang telah dijelaskan pada bab sebelumnya, MTI terdiri dari empat karakter atau empat byte data yang merepresentasikan tipe message serta fungsinya. Berikut merupakan algoritma untuk membaca informasi data MTI pada sebuah message. Dalam algoritma berikut diasumsikan message ISO- 8583 terdapat dalam sebuah veriable string IsoMsg. MTI:=Substring(IsoMsg,1,4); Substring merupakan fungsi dasar dalam operasi String dalam beberapa bahasa pemrograman generasi ke 3. 3.4.2 Pembacaan Data Bitmap Data Bitmap merupakan data dalam representasi Octet String yang menginformasikan keberadaan data element dalam sebuah message. Keberadaan data element dapat dilihat dari nilai bit pada data Bitmap. Nilai bit ke-n menandakan keberadaan data element ke-n. Nilai bit on atau 1, menandakan data element ada, dan sebaliknya nilai bit off menandakan bahwa data element tidak ada. Sebagai contoh, nilai Bitmap: 7F343321AB57FF67. Dalam representasi biner dapat dilihat pada Tabel 3.2. Tabel 3.2 Contoh Interpretasi Bitmap 7F Bit 1 2 3 4 5 6 7 8 Nilai 0 1 1 1 1 1 1 1 34 Bit 9 10 11 12 13 14 15 16 Nilai 0 0 1 1 0 1 0 0

34 Tabel 3.2 Contoh Interpretasi Bitmap (lanjutan) 33 Bit 17 18 19 20 21 22 23 24 Nilai 0 0 1 1 0 0 1 1 21 Bit 25 26 27 28 29 30 31 32 Nilai 0 0 1 0 0 0 0 1 AB Bit 33 34 35 36 37 38 39 40 Nilai 1 0 1 0 1 0 1 1 57 Bit 41 42 43 44 45 46 47 48 Nilai 0 1 0 1 0 1 1 1 FF Bit 49 50 51 52 53 54 55 56 Nilai 1 1 1 1 1 1 1 1 67 Bit 57 58 59 60 61 62 63 64 Nilai 0 1 1 0 0 1 1 1 Dari data biner tersebut diperoleh bahwa data element yang ada adalah data element: 2, 3, 4, 5, 6, 7, 8, 11, 12, 14, 19, 20, 23, 24, 27, 32, 33, 35, 37, 39, 40, 42, 44, 46, 47, 48, 49, 50, 51,52, 53, 54, 55, 56, 58, 59, 62, 63, dan 64. Pembacaan data bitmap akan ditangani oleh fungsi cekbit. Input parameter adalah data bitmap dalam tipe Int64 dan posisi bit yang akan dilakukan pengecekan. Hasil dari fungsi ini adalah sebuah byte yang bernilai 1 jika bit bersangkutan ada dan 0 jika bit bersangkutan tidak ada. Pada spesifikasi standar dikenal ada dua macam data bitmap yaitu primary dan secondary. Keberadaan secondary bitmap ditandai dengan kondisi nilai bit pada posisi ke-1 sebuah primary bitmap bernilai 1. 3.4.3 Pembacaan Data Element Seperti yang telah disampaikan dalam bab II, mengenai data element pada. Setiap versi dapat memiliki set panjang data element yang berbeda. Pada tugas akhir ini penulis membatasi versi hanya mengacu kepada versi :1987. Sehingga untuk pembacaan data element akan mengacu kepada set panjang data element :1987.

35 Pembacaan data element merupakan proses berulang yang bergantung kepada jumlah data element yang terdapat pada data bitmap. Algoritma pembacaan data element dapat dinyatakan sebagai: For i:=1 to 64 do Begin If CekBitmap(Bitmap, i)=1 then Begin BacaDataElement( Message ) End End Untuk dapat membaca sebuah data element diperlukan paramater posisi data element serta panjangnya. Penentuan posisi hanya dapat dilakukan dengan melakukan penelusuran panjang data element sebelumnya. Sedangkan panjang data element perlu dilakukan dengan melakukan mapping set panjang data element. Pada tugas akhir ini penulis menggunakan sebuah array integer satu dimensi untuk menampung mapping panjang data element. Untuk membedakan panjang sebuah data element dinamis LLVAR atau LLLVAR mapping array akan berisi -2 (LLVAR) atau -3 (LLLVAR). Berikut merupakan algoritma untuk prosedur pembacaan data element: Function BacaDataElement( MsgISO, NoDataElement) -> String For i:=1 to NoDataElement do Begin If CekBitmap(Bitmap, i)=1 then Begin If MapDataElement(i)=-2 then PosisiDataElement <- PosisiDataElement+2+InfoPanjangDinamis PanjangDataElement <- InfoPanjangDinamis Else If MapDataElement(i)=-3 then PosisiDataElement <- PosisiDataElement+3+InfoPanjangDinamis PanjangDataElement <- InfoPanjangDinamis Else PosisiDataElement <- PosisiDataElement + MapDataElement(i) PanjangDataElement <- MapDataElement(i) BacaDataElement <- Copy( MsgISO, PosisiDataElement, PanjangDataElement) End End Implementasi pembacaan data element terdapat pada fungsi GetBitValue pada lampiran source code.

36 3.5 Rancangan Modul Library UDF Modul library UDF MySQL akan sepenuhnya mengikuti spesifikasi perancangan shared library UDF MySQL. Hal ini perlu karena hanya dengan cara ini modul decoder dapat diperkenalkan atau didaftarkan pada Server MySQL. 3.5.1 Fungsi Init Decoder Mengikuti standar MySQL fungsi akan selalu dipanggil pertama kali ketika sebuah query SQL memanggil fungsi decoder. Untuk proses inisiasi akan dilakukan pengecekan terkait input yang diberikan pada saat query SQL dilakukan telah sesuai dengan aturan atau belum. Fungsi decoder memiliki 2 (dua) buah parameter input yaitu message (string) dan nomor Data Element (integer) yang akan diambil. Start Cek jumlah parameter. Apakah 2 atau kurang. Jumlah = 2 Benar Cek parameter 1, merupakan String Benar Cek parameter 2, merupakan integer Return error Benar End Return sukses Gambar 3.8 Diagram Flowchart Untuk Init Decoder

37 3.5.2 Fungsi Decoder Fungsi ini akan dipanggil ketika fungsi Init Decoder menghasilkan nilai sukses. Fungsi decoder akan mengenkapsulasi proses decode yang telah didefinisikan sebelumnya. Fungsi decoder akan memiliki 2 (dua) buah parameter input yaitu: 1. Message (String) Parameter ini akan menampung message dalam bentuk encoded yang selanjutnya akan dilakuan decode. Nilai parameter ini merupakan input dari query SQL yang berupa text. Pada level query SQL, nilai parameter ini dapat langsung dilempar melalui fungsi maupun mengacu kepada sebuah field dalam database. 2. Nomor Data Element (Integer) Parameter ini akan menampung index Data Element yang akan diambil datanya dari sebuah data text. Pada level query SQL, nilai parameter ini dapat langsung dilempar melalui fungsi maupun mengacu kepada sebuah field dalam database. Sebagai output atau hasil dari fungsi decoder adalah sebuah nilai String dari Data Element dari Message.