BAB I PENDAHULUAN
1.6. Ruang Lingkup
Dalam pembuatan skripsi ini penulis membatasi permasalahan seperti :
1. Sistem yang dirancang berupa Application Programming Interface berbasis website.
2. Menggunakan metode Load Balancer untuk membagi beban traffic server.
3. Output sistem ini merupakan SMS ke nomor handphone tujuan dan laporan pengiriman pada dashboard.
6
Menurut Janner Simarmata dalam Nurlela (2013:21) menegaskan “SMS merupakan aplikasi untuk transmisi teks kecil melalui standar GSM (Global Sistem for Mobile Communication)”.
SMS atau Short Messages Services ini merupakan teknologi yang menyediakan layanan pengiriman dan penerimaan per pesanan antar ponsel. SMS dikenalkan pertama kali sekitar tahun 1992 di Eropa. Data yang mampu ditampung juga terbatas pada SMS. Satu SMS hanya dapat menampung maksimal 140 bytes data, jadi satu SMS dapat menampung 160 karakter latin dan 70 karakter non latin, Dukungan sebagian besar bahasa di semua negara, termasuk juga Cina, Korea, Arab, dan Jepang (Murti & Listiyono, 2009).
B. SMS Gateway
Menurut Ben Forta dalam Nurlela (2013:22) menegaskan bahwa “SMS Gateway adalah suatu platform yang menyediakan mekanisme untuk menghantar dan menerima pesan dari peralatan Mobile (HP, ponsel, dan lain-lain)”.
“SMS Gateway yaitu suatu sistem yang menjembatani (gateway) antara ponsel dengan sistem yang menjadi server dengan SMS sebagai informasinya” (Murti &
Listiyono, 2009). “SMS Gateway bisa disebut pintu gerbang bagi penyebaran informasi menggunakan SMS. Penyebaran pesan dapat dilakukan ke banyak nomor secara otomatis dan cepat yang terhubung dengan database nomor ponsel tanpa harus mengetik banyak nomor dan pesan dari ponsel karena semua nomor akan diambil secara otomatis dari database.” (Alvin & Gusrianty, 2019).
C. API
Menurut M. Ichwan dan Fifin Hakiky dalam (Alvin & Gusrianty, 2019) menerangkan
Application Programming Interface (API) atau Antarmuka Pemrograman Aplikasi adalah sekumpulan perintah, fungsi, dan protokol yang dapat digunakan oleh programmer saat membangun perangkat lunak untuk sistem operasi tertentu. API dikembangkan karena adanya tren industri yang baru, yaitu distributed Sistem, untuk menyediakan layanan yang efisien, meningkatkan reliability dan availability, dan kelebihan lain untuk integrasis sistem.
D. PHP
Menurut MADCOMS PHP atau Hypertext Preprocessor merupakan “script language (bahasa skrip) yang dapat disisipkan ke dalam HTML. PHP sering kali digunakan untuk membuat situs webite yang dinamis.” (Ayu & Permatasari, 2018)
“Untuk membuat website yang dinamis diperlukanlah PHP. Karena PHP merupakan server-side scripting, maka sintaks PHP akan dieksekusi di server lalu hasilnya diteruskan ke browser dalam format HTML. Dan juga PHP merupakan bahasa komersial ataupun gratis (free) dan bersifat opensource” (Ayu & Permatasari, 2018; Lavarino, 2016).
Berikut merupakan kelebihan PHP menurut (Lavarino, 2016):
a. PHP merupakan Bahasa pemograman script tanpa kompilasi.
b. Tingkat akses lebih cepat.
c. Lifecycle yang tinggi sehingga mengikuti perkembangan zaman.
d. Memiliki support akses ke beberapa database yang bersifat komersial.
E. UML
Windu dan Grace menyatakan “UML merupakan bahasa standar yang diperuntukkan untuk menspesifikasi, mendokumentasi, dan membangun sebuah perangkat lunak. Mengembangkan sistem berorientasi objek dan alat untuk
pendukung pengembangan sistem merupakan metodologi UML” (Suendri, 2018).
Menurut D. B. Naga Muruga (2019:3) menjelaskan tentang pengertian UML (Unified Modeling Language) merupakan “Standard language untuk menentukan, memvisualisasikan, membangun artefak perangkat lunak”.
UML adalah alat dalam perancangan sistem yang berorientasi kepada objek.
Filosofi dari kemunculan UML ini terinspirasi oleh konsep dari permodelan Object Oriented (OO), karena pada konsep ini seperti kehidupan yang nyata didominasi oleh objek dan dinotasikan atau digambarkan dalam simbol-simbol yang spesifik maka dari itu Object Oriented (OO) mempunyai proses yang standar dan juga independen.
Tujuan utama diagram UML ialah untuk membantu tim pengembangan proyek dalam berkomunikasi, juga mengeksplorasi potensi design, dan memvalidasi software architecture design atau pembuat program (Haviluddin 2011).
Berikut konsep-konsep dasar UML:
“UML mendefinisikan bermacam-macam diagram seperti Use Case Diagram, Class Diagram, Statechart Diagram, Activity Diagram, Sequence Diagram, Collaboration Diagram, Component Diagram, dan Deployment Diagram”
(Dharwiyanti and Wahono 2003).
Pada penelitian ini, hanya digunakan beberapa diagram di antaranya:
a. Use Case Diagram
Menggambarkan berbagai macam fungsi yang merupakan gambaran ekspektasi dari sebuah sistem. Pada use case ditekankan “apa” yang dilakukan atau diperbuat sistem bukan “bagaimana”. Use case merepresentasikan interaction antara Actor dengan Sistem. Use case juga merupakan sebuah pekerjaan, contohnya kasus login ke dalam sistem, diperlukan untuk membuat sebuah daftar belanja, dan lainnya.
b. Class Diagram
Sebuah spesifikasi yang menghasilkan sebuah objek juga merupakan bagian inti dari pengembangan sistem dan desain yang berorientasi objek. Class menggambarkan keadaan seperti properti/atribut dari suatu sistem, juga menawarkan
service untuk memanipulasikan keadaan tersebut (metode/fungsi). Penggambaran class diagram meliputi structure juga deskripsi dari class, package dan object beserta relasi satu dengan yang lain seperti containment, inheritance, association, dan lain-lain.
Terdapat 3 area utama, yaitu Name (dan stereotip), Attribute, Method. Attribute, Method memiliki sifat sebagai berikut:
1) Private, luar class tidak dapat memanggil hanya class yang bersangkutan.
2) Protected, hanya bisa dipanggil oleh class yang bersangkutan saja dan child yang mewarisinya .
3) Public, siapa saja dapat memanggil class tersebut.
c. Activity Diagram
Menggambarkan flow (alur) aktivitas dalam sistem yang dirancang, bagaimana masing-masing flow berawal, decision atau keputusan yang mungkin akan terjadi, dan bagaimana flow berakhir.
Menggambarkan activity diagram menggunakan standar UML yaitu segi empat dengan sudut yang membulat. Penggunaan decision untuk menggambarkan behaviour dalam kondisi tertentu. Untuk mengilustrasikan beberapa proses paralel (fork & join) menggukan titik sinkronisasi yang dapat berupa titik, garis yang horizontal dapat juga vertikal. Activity diagram bisa dibagi menjadi beberapa objek swimlane dalam menggambarkan objek yang bertanggung jawab untuk aktivitas tertentu.
d. Sequence Diagram
Penggambaran interaksi antar beberapa objek di dalam juga di sekeliling sistem (termasuk display, pengguna, dan sebagainya) berbentuk message yang dijelaskan terhadap waktu. Sequence diagram terdiri dari dimensi horizontal (objek terkait) dan
dimensi vertikal (waktu). Sequence diagram biasanya digunakan untuk memvisualkan rangkaian atau skenario tahapan yang dilakukan sebagai response atau tanggapan dari event yang menghasilkan keluaran tertentu. Diawali dari pemicu aktivitas tersebut, lalu proses, perubahan yang terjadi secara internal dan keluaran yang dihasilkan.
Setiap objek, termasuk juga aktor, memiliki lifeline yang vertikal. Message atau pesan digambarkan sebagai garis panah dari dan ke satu objek lainnya. Fase berikutnya, message dipetakan menjadi operasi/metode dari class. Activation bar melihatkan lamanya implementasi sebuah proses, umumnya diawali dengan sebuah message yang diterima.
Standar UML memiliki icon khusus untuk objek yang memiliki sifat khusus seperti controller, boundary dan persistent entity.
e. Deployment Diagram
Memvisualisasikan detail komponen yang di-deploy pada infrastruktur sistem, yang mana komponen terletak (pada server, mesin atau hardware apa), bagaimana network capabilities pada lokasi tersebut, spesifikasi server, dan lainnya yang memiliki sifat fisik.
Sebuah node merupakan server, perangkat workstation, atau hardware lain yang digunakan untuk penyebaran komponen pada lingkungan sebenarnya. Hubungan antar sebuah node dan persyaratan atau requirement bisa didefinisikan pada diagram ini.
F. HaProxy
“HaProxy adalah perangkat lunak opensource untuk menunjang load balancer dan proxy untuk TCP dan HTTP. Satu server yang terinstal HAProxy sebagai
gateway load balancing bertugas membagi beban request dari user kepada beberapa server utama.” (Rahmatulloh & MSN, 2017).
2.2. Penelitian Terkait
Dalam penyusunan skripsi ini, penulis mendapatkan beberapa inspirasi dan mereferensikan dari beberapa penelitian yang telah dilakukan yang memiliki keterkaitan latar belakang masalah pada skripsi ini. Berikut ini penelitian terdahulu yang berhubungan dengan skripsi ini, diantaranya:
Penelitian yang dilakukan oleh Efrizal Zaida (2014) tentang “Penentuan Strategi High Availability Dalam Menjamin Ketersediaan Aplikasi Dan Data”, pada penelitian ini bertujuan untuk menentukan strategi dalam penerapan High Availability yang paling tepat menggunakan pendekatan Analytical Hierarchy Process (AHP). Failover, load balancing, mirror dan virtualisasi merupakan alternatif penentuan strategi High Availability.
Penelitian yang dilakukan oleh Sampurna Dadi Riskiono dan Donaya Pasha (2017) tentang “Analisis Metode Load Balancing Dalam Meningkatkan Kinerja Website E-Learning”, pada penelitian tersebut menggunakan model penjadwalan bertipe round robin. load balancer yang mendistribusikan permintaan layanannya sama rata ke seluruh server nyata tanpa memedulikan kapasitas dari server atau pun beban permintaan layanan. Dari pengujian yang telah dilakukan, menunjukkan penerapan load balancing dalam meningkatkan kinerja berhasil diimplementasikan dengan melihat nilai waktu respons yang lebih kecil dibanding dengan penggunaan server tunggal.
Penelitian yang dilakukan oleh Sampurna Dadi Riskiono, Selo Sulistyo , dan Teguh Bharata Adji (2017) tentang “Kinerja Metode Load Balancing Dan Fault Tolerance Pada Server Aplikasi Chat”, penerapan metode load balancing dapat
memperkecil nilai dari waktu respons serta dapat juga meningkatkan nilai throughput ketika permintaan di atas 3000 koneksi sistem masih dapat melayani permintaan dari pengguna dibandingkan tanpa load balancing di mana server hanya mampu melayani permintaan sampai dengan 3000 koneksi. Artinya sistem dapat terhindar dari kelebihan beban yang datang dari pengguna.
Penelitian yang dilakukan oleh Andi Rosano, Nur Ali Farabi, dan Aliffah Kusumaningrum (2018) tentang “Perancangan Sistem Internet Banking (I-Bank) Menggunakan One-Time-Password (OTP) Untuk Pengamanan Transaksi (Studi Kasus Bank Mega, Tbk)”, pada penelitian ini mengimplementasikan konsep pengamanan financial transactions dengan sandi sekali pakai atau One-Time-Password (OTP). Kode OTP nantinya akan dikirimkan menggunakan SMS (short message format) yang terhubung ke SMS Gateway server.
Dari penelitian-penelitian tersebut, akan dibuatkan sebuah aplikasi berbasis web tentang SMS Gateway untuk One-Time-Password (OTP) seperti penelitian yang dilakukan oleh Andi Rosano, Nur Ali Farabi, dan Aliffah Kusumaningrum (2018), maupun untuk pengiriman pesan lainnya, dalam penelitian ini juga kami menggunakan metode load balancing dengan tipe round robin untuk membagi beban traffic pada server secara berimbang, serta metode failover untuk proses pengiriman ke provider SMS Gateway seperti yang dilakukan oleh Efrizal Zaida (2014), Sampurna Dadi Riskiono, Selo Sulistyo , dan Teguh Bharata Adji (2017), dan Sampurna Dadi Riskiono dan Donaya Pasha (2017). Dengan harapan penelitian ini dapat digunakan oleh perusahaan sebagai solusi untuk mencegah terjadinya server down akibat traffic tinggi pada saat program promo dan bermasalahnya salah satu provider SMS Gateway yang menyebabkan gagal terkirimnya pesan dengan
dilakukannya Switch (Penggantian) Provider secara otomatis, maupun secara manual.
14
BAB III
ANALISIS SISTEM BERJALAN
3.1. Tinjauan Institusi / Perusahaan
PT.KB FINANSIA MULTI FINANCE adalah perusahaan yang bergerak di dalam bidang pembiayaan sejak tahun 1994 dan memperoleh ijin usaha dari Menteri Keuangan (sekarang Otoritas Jasa Keuangan) berdasarkan surat No.460/KMK.017/1994 tanggal 14 September 1994.
3.1.1. Sejaran Institusi / Perusahaan
Sejak 1994 PT.KB FINANSIA MULTI FINANCE mendirikan brand Kreditplus dengan fokus pelayanan pembiayaan motor, mobil, dan peralatan berat. Dalam waktu 24 tahun ini, perhatian utama Kreditplus adalah memenuhi kebutuhan dan kenyamanan nasabah dalam menggunakan layanan kami. Untuk memenuhi kedua hal tersebut, mulai dari 2014 Kreditplus telah mulai proses digitalisasi dengan tujuan menjadi penyedia layanan digital finance terbaik di Indonesia.
Kreditplus memulai proses digitalisasi dengan membangun kerjasama dengan website e-commerce sebagai payment gateway. Kemudian Kreditplus membuat sistem pengajuan kredit secara digital dengan inovasi E-Form. Saat ini Kreditplus sedang membangun ekosistem terintegrasi agar dapat menyediakan layanan bagi nasabah yang dapat digunakan secara Mudah, Cepat dan Aman. Dalam ekosistem terintegrasi tersebut nasabah dapat melakukan pengajuan kredit hingga pembayaran angsuran terakhir dari mana saja, kapan saja.
Produk dan layanan lain yang saat ini disediakan oleh Kreditplus termasuk pembiayaan multi guna untuk berbagai macam produk elektronik dan furniture, dan pinjaman dana dengan agunan kendaraan untuk berbagai macam kebutuhan Anda.
3.1.2. Visi dan Misi Institusi / Perusahaan 1. Visi Perusahaan
Menjadi Perusahaan Pembiayaan Penyedia Solusi dan Layanan Pembiayaan Berbasis Teknologi Terbaik di Indonesia
2. Misi Perusahaan
a. Menyediakan Solusi dan Layanan Pembiayaan kepada Masyarakat Menggunakan Teknologi untuk Meningkatkan Kualitas Hidup Masyarakat b. Membangun Kerangka Kerja untuk Setiap Orang Belajar, Berkembang dan
Bekerja, Menciptakan Nilai dan Potensi Pertumbuhan 3.1.3. Struktur Organisasi Institusi / Perusahaan
Gambar III.1 Struktur Organisasi
1. President Director
a. Memimpin perusahaan dengan menerbitkan kebijakan-kebijakan perusahaan atau institusi.
b. Memilih, menetapkan, dan mengawasi tugas dari karyawan dan kepala bagian atau wakil direktur.
c. Menyampaikan laporan kepada pemegang saham atas kinerja perusahaan.
2. Director Of Business Support
a. Memimpin dan bertanggung jawab pada program bisnis perusahaan.
b. Mendukung karyawan dengan menilai kapasitas dan kinerja perusahaan.
c. Mengevaluasi pengembangan rencana bisnis strategis.
3. Director Of Marketing
a. Mengarahkan karyawan untuk meningkatkan seluruh sumber daya yang ada secara optimal.
b. Melakukan pengawasan dan pengendalian atas seluruh kinerja manajemen pemasaran, penjualan, dan promosi bagi kepentingan perusahaan.
c. Membuat laporan kegiatan kepada presiden direktur sebagai pertanggungjawaban seluruh aktivitas manajemen pemasaran, penjualan, dan promosi.
4. Head of Technology
a. Bertanggung jawab dalam keseluruhan proses yang berkaitan dengan departemen IT.
b. Memastikan semua sistem IT berjalan lancar dan memutuskan solusi jika terjadi permasalahan.
c. Bertanggung jawab melakukan pengembangan dan peningkatan sistem informasi dan teknologi.
5. Head Of Business Development
a. Meriset pasar, mencari peluang pelanggan baru, dan menjaga hubungan dengan pelanggan.
b. Bekerja sama dengan divisi lain seperti divisi teknis untuk memenuhi kebutuhan pelanggan/pasar.
c. Menyusun dan mempresentasikan rencana pengembangan bisnis.
6. Head Of Business Operation
a. Bertanggung jawab agar operasional cabang berjalan dengan baik.
b. Monitoring KPI (Key Performance Indicator).
c. Mengukur efisiensi sistem dan prosedur.
7. Head Of Marketing and Product Development
a. Mempersiapkan seluruh data yang dibutuhkan untuk dasar analisa bagi divisi product development
b. Membuat report secara berkala mengenai kinerja cabang dan program marketing secara harian, mingguan dan bulanan
c. Melakukan pengajuan kebutuhan cabang (SMS Blast, Material Promosi, dll.) 8. Developer
a. Memodifikasi software yang ada untuk memperbaiki kerusakan dan untuk mengembangkan kinerjanya.
b. Mengembangkan dan mengarahkan pengujian sistem software dan prosedur validasi, pemrograman, dan dokumentasi
c. Berkolaborasi dengan analis sistem (system analyst), programmer, dan pekerja lainnya untuk mendesain sistem & aplikasi, dan untuk memperoleh informasi mengenai limitasi dan kapabilitas proyek, serta persyaratan dari projek tersebut
9. IT Infrastructure
a. Bertanggung jawab dalam menyiapkan, memelihara, memperbaiki server yang dimiliki perusahaan.
b. Bertanggung jawab memelihara jaringan.
10. IT Helpdesk & Support
a. Memastikan kalau aplikasi-aplikasi yang dipakai oeh si user berfungsi seperti yang seharusnya.
b. Mengecek dan memperbaiki bila sewaktu-waktu ada masalah pada jaringan komputer user
c. Mengecek dan update setiap pembaharuan sistem operasi maupun aplikasi yang dijalankan oleh user
11. Product Owner
a. Bertanggung jawab dengan produk atau aplikasi yang dipegang nya.
b. Berkoordinasi dengan divisi lain dalam kelancaran produk nya.
c. Memastikan product nya bias diterima dengan baik oleh user.
3.2. Proses Bisnis Sistem
Pengiriman SMS OTP (One Time Password) dilakukan oleh marketing dilapangan sebelum Konsumen tanda tangan persetujuan aplikasi pengajuan. Apabila konsumen tidak menerima sms dalam waktu satu menit, maka marketing dilapangan bisa mengirim kembali SMS OTP (One Time Password) dengan batas tiga kali permintaan.
Gambar III. 2
Activity Diagram Proses Bisnis Sistem 3.3. Spesifikasi Dokumen Sistem Berjalan
1. Nama Dokumen : Form Pengajuan Software Aktivasi API SMS Fungsi : Request Akses API
Sumber : Product Owner Tujuan : Departemen IT
Periode : Tidak Tentu, tergantung kebutuhan PO Media : E-Mail
Bentuk : Lampiran A-1
20
BAB IV
RANCANGAN SISTEM DAN PROGRAM USULAN
4.1. Analisis Kebutuhan Software
Analisa kebutuhan Software yang akan dikembangkan dalam penelitian ini yaitu untuk mengetahui cara kerja API SMS Gateway dengan menerapkan metode Load Balancer dan Failover yang akan digunakan di PT.KB FINANSIA MULTI FINANCE.
4.1.1. Tahapan Analisa
Dalam penelitian ini supaya sesuai dengan keinginan pengguna dan bisa berjalan dengan baik maka diperlukan analisa terhadap sistem. Dengan tujuan untuk memperjelas konsep dari perancangan dengan unsur-unsur yang terlibat, berikut adalah spesifikasi kebutuhan (sistem requirement) dari API SMS Gateway dengan metode load balancing dan failover yaitu :
A1. Admin dapat mengelola data aplikasi yang memiliki izin untuk akses API A2. Admin dapat mengelola pengaturan provider SMS Gateway utama.
A3. Admin dapat mencetak hasil laporan pengiriman SMS.
4.1.2. Use Case Diagram 1. Use Case Diagram
Gambar IV. 1 Use Case Diagram Berikut deskripsi use case diagram Admin yaitu :
Tabel IV. 1
Deskripsi Use Case Diagram Mengelola Data Aplikasi
Use Case Name Mengelola Data Aplikasi
Requirements Admin Login Aplikasi
Goal
Admin dapat mengelola Data Aplikasi yang mempunyai izin untuk mengakses API
Pre-Conditions Admin melakukan login dengan role
Admin Post-Conditions
Data yang telah ditambahkan akan tersimpan serta dapat dirubah dan dihapus
Primary Actors Admin
Main Flow/Basic Path
1. Sistem menampilkan halaman login 2. Admin memilih menu Data Aplikasi 3. Admin dapat menambah, merubah,
dan menghapus Data Aplikasi
4. Sistem menyimpan semua perubahan data
Alternatif Flow/Invarian 1 Jika data tidak valid sistem akan menampilkan pesan kesalahan.
Tabel IV. 2
Deskripsi Use Case Diagram Mengelola Pengaturan API
Use Case Name Mengelola Pengaturan API
Requirements Admin Login Aplikasi
Goal
Admin dapat mengelola Pengaturan API, untuk mengatur Provider utama yang akan digunakan untuk mengirim SMS.
Pre-Conditions Admin melakukan login dengan role
Admin
Post-Conditions Data yang ada hanya dapat dirubah
Primary Actors Admin
Main Flow/Basic Path
1.Sistem menampilkan halaman login 2.Admin memilih menu Pengaturan API 3.Admin dapat merubah Pengaturan
API
4.Sistem menyimpan semua perubahan data
Alternatif Flow/Invarian 1 Jika data tidak valid sistem akan menampilkan pesan kesalahan.
Tabel IV. 3
Deskripsi Use Case Diagram Mencetak Laporan Pengiriman SMS
Use Case Name Mencetak laporan pengiriman SMS
Requirements Admin Login Aplikasi
Goal Admin dapat mencetak laporan hasil
pengiriman SMS
Pre-Conditions Memasukan tanggal periode laporan pada form periode
Post-Conditions Data yang ditampilkan dapat dicetak
Primary Actors Admin
Main Flow/Basic Path
1. Sistem menampilkan halaman login 2. Admin memilih menu Laporan 3. Admin dapat mencetak laporan
pengiriman SMS.
Alternatif Flow/Invarian 1 -
4.1.3. Activity Diagram 1. Login
Gambar IV. 2 Activity Diagram Login
2. Mengelola Data Aplikasi
Gambar IV. 3
Activity Diagram Mengelola Data Aplikasi
3. Pengaturan API
Gambar IV. 4
Activity Diagram Pengaturan API
4. Cetak Laporan Pengiriman SMS
Gambar IV. 5
Activity Diagram Cetak Laporan Pengiriman SMS
4.2. Desain 4.2.1. Basis Data
1. Entity Relationship Diagram (ERD)
Gambar IV. 6
Entity Relationship Diagram (ERD) 2. Logical Record Structure (LRS)
Gambar IV. 7 Logical Record Structure
3. Spesifikasi File
a. Spesifikasi Tabel Data Aplikasi Nama Database : sms_gateway Nama File : data_aplikasi Tipe File : file master Kunci Field : id_aplikasi
Tabel IV. 4
Spesifikasi File Tabel Data Aplikasi
No Elemen Data Nama Field Type Size Keterangan 1 Id Aplikasi id_aplikasi Varchar 20 Primary Key 2 Client key client_key Varchar 50
3 Nama aplikasi nama_aplikasi Varchar 75
b. Spesifikasi Tabel Log SMS
Nama Database : sms_gateway Nama File : log_sms Tipe File : file master Kunci Field : id_logsms
Tabel IV. 5
Spesifikasi File Tabel Log SMS
No Elemen Data Nama Field Type Size Keterangan
1 ID Log id_log Int 25 Primary Key
2 ID Aplikasi id_aplikasi Int 25 Foreign Key
3 Nomor Hp no_hp Varchar 15
4 Isi Pesan Text Varchar 255
5 Nama Server Server Varchar 75 6 Nama Provider Provider Varchar 75 7 Response Provider Response Json
4.2.2. Arsitektur Perangkat Lunak 1. Class Diagram
Gambar IV. 8 Class Diagram
2. Sequence Diagram
Gambar IV. 9 Sequence Diagram Login
Gambar IV. 10
Sequence Diagram Data Aplikasi
Gambar IV. 11
Sequence Diagram Pengaturan API
Gambar IV. 12
Sequence Diagram Cetak Laporan
3. Component Diagram
Gambar IV. 13
Component Diagram Dashboard SMS Gateway 4. Deployment Diagram
Gambar IV. 14 Deployment Diagram API
Gambar IV. 15
Deployment Diagram Dashboard 4.2.3. Antarmuka Pengguna
Gambar IV. 16 Halaman Masuk
Gambar IV. 17 Tampilan Halaman Utama
Gambar IV. 18 Halaman Data Aplikasi
Gambar IV. 19 Form Data Aplikasi
Gambar IV. 20
Tampilan Halaman Pengaturan API
Gambar IV. 21 Tampilan Halaman Laporan
Gambar IV. 22 Halaman Cetak Laporan
Gambar IV. 23
Tampilan Input dan Response dari API 4.3. Code Generation
<?php
namespace App\Classes;
use Config;
use GuzzleHttp\Client;
public function sendSMS($message, $handphone) {
$status = (new
Setting)->select('config_priority')->where('id_pengaturan',1)->first();
$providers = ($status->config_priority == 'medansms' ? ['medansms','websms'] : ['websms','medansms']);
$res = $this->sendMedanSMS($message, $handphone);
if($status_send === false){
public function sendMedanSMS($message, $handphone) {
$setting = (new
Setting)->select('config_priority','balasan')->where('id_pengaturan',1)->first();
Log::info("[Send Message] >getStatusCode()."
// Log::info($e->getResponse()->getStatusCode()."
".$e->getResponse()->getBody());
public function sendWebSMS($message, $handphone) {
$setting = (new
Log::info("[Send Message] >getStatusCode()."
".$response->getBody());
Log::error($e);
// Log::info($e);
// Log::info($e->getResponse()->getStatusCode()."
".$e->getResponse()->getBody());
Pada penelitian ini pengujian sistem menggunakan metode black box testing.
Pengujian ini memiliki tujuan untuk melihat apakah keluaran yang dihasilkan sudah sesuai dengan yang diharapkan oleh pengguna atau tidak. Hasil pengujiannya dapat dilihat pada table dibawah ini :
Tabel IV. 6
database
Form diisi semua Sistem akan menyimpan data
Form diisi kosong Sistem akan memunculkan pesan kesalahan
Valid/Sesua i Harapan
5
Cetak laporan Klik tombol cetak Sistem akan menampilkan data
7 Kirim data ke Mengosongkan Sistem akan Valid/Sesua
4.5. Pendukung
Pada tahap pendukung akan menjelaskan mengenai publikasi web dan spesifikasi Hardware dan Software yang digunakan dalam penelitian ini.
4.5.1. Publikasi WEB
Untuk publikasi web Implementasi Metode Load Balancer dan Failover API SMS Gateway ini sebenarnya untuk digunakan oleh perusahaan secara internal dan merupakan rahasia perusahaan, namun kami menyewa server untuk keperluan simulasi dan pembelajaran kedepannya. Berikut adalah alamat situs simulasinya :
Tabel IV. 7
Tabel Alamat Situs Simulasi
Alamat Situs Keterangan
Skripsi.junandia.id Digunakan sebagai Dashboard dan server Basis Data
Skripsi.junandia.id Digunakan sebagai Dashboard dan server Basis Data