9 BAB 3
PELAKSANAAN KERJA MAGANG
3.1 Kedudukan dan Koordinasi
Kedudukan yang dimiliki adalah sebagai software engineer Mobilepulsa, di bawah tim API. Tim API bertugas untuk mengembangkan produk API agar dapat diintegrasikan pada layanan pembayaran milik client. Pelaksanakan kerja magang turut dibimbing oleh seluruh anggota tim API, yang terdiri dari Martha Saphira selaku Project Manager, Gandhi Pranata selaku anggota, dan Devi Devani selaku pembimbing lapangan. Pekerjaan yang dilakukan setiap minggunya juga diberikan evaluasi dan dukungan dari Eddy Christiandy selaku CTO, melalui aplikasi Basecamp.
Koordinasi yang dilakukan bersama anggota tim API lainnya adalah melalui Telegram dan rapat online menggunakan Google Meeting. Rapat dilakukan setiap minggunya untuk memberitahu progress pekerjaan yang telah dilakukan ataupun kendala yang ditemui. Kemudian, project manager akan mengevaluasi dan memberi feedback terkait pekerjaan yang telah dilakukan dan menyampaikan target yang perlu dicapai minggu berikutnya. Pembimbing lapangan juga turut membantu dan membimbing. Setiap capaian pada fitur yang dikerjakan pada branch masing-masing, akan diperbaharui pada aplikasi remote repository Git sebagai kontrol versi menggunakan GitLab. Untuk memudahkan pemakaian, digunakan juga aplikasi Git GUI menggunakan GitKraken. Setelah fitur yang dikerjakan telah selesai, dibuat merge request untuk menggabungkan branch pada GitLab, yang akan dievaluasi oleh setiap anggota.
10 3.2 Tugas yang Dilakukan
Tugas yang dilakukan adalah mengerjakan proyek API Report, agar dapat digunakan oleh client melihat laporan transaksi pada developer.mobilepulsa.net dan mobilepulsa.com. Jenis transaksi yang dikerjakan pada proyek ini adalah transaksi postpaid. Laporan transaksi yang dihasilkan API memiliki 2 tipe, yaitu File dan API Pagination. Tipe File yang dimaksud adalah laporan berbentuk file CSV, dan tipe API Pagination yang dimaksud adalah laporan berbentuk respon API yang diberi pagination.
Proyek API Report memiliki 2 fitur, yaitu Generate Report dan Check Status. Fitur Generate Report berfungsi untuk membuat laporan dengan tipe File atau API Pagination. Laporan dengan tipe File diunggah ke cloud AWS S3. Di samping itu, fitur Check Status berfungsi untuk mengecek laporan dengan tipe File apakah sudah tersedia pada AWS S3. Jika laporan sudah tersedia, maka dikembalikan link untuk mengunduh file tersebut. Pembuatan fitur Generate Report dan Check Status dilakukan pada data palsu terlebih dahulu, sebelum pada data asli. Untuk memastikan fitur Generate Report dan Check Status berjalan dengan baik, dibuat fitur Feature dan Unit Testing untuk masing-masing fitur.
Pekerjaan yang dilakukan setiap minggunya terdapat pada Tabel 3.1.
Tabel 3.1 Realisasi kerja magang
Minggu Pekerjaan yang Dilakukan
1 Menginstal tools yang dibutuhkan Mencoba API di lokal
2 Membuat validasi request pada fitur Generate Report dan Check Status
3 Membuat tipe File dan API Pagination dengan data palsu pada fitur Generate Report
Membuat tipe File dengan data palsu pada fitur Check Status 4 Membuat tipe API Pagination dengan data asli pada fitur Generate
Report
11 Tabel 3.2 Realisasi kerja magang (lanjutan)
Minggu Pekerjaan yang Dilakukan
5 Membuat tipe File dengan data asli pada fitur Generate Report 6 Membuat tipe File dengan data asli pada fitur Generate Report 7 Membuat tipe File dengan data asli pada fitur Check Status 8 Membuat Feature dan Unit Testing pada fitur Generate Report 9 Membuat Feature dan Unit Testing pada fitur Check Status 10 Memperbaiki kode berdasarkan review yang diberikan 11 Menguji API setelah deployment
3.3 Uraian Pelaksanaan Kerja Magang
Secara garis besar, pelaksanaan kerja magang yang dilakukan dapat dibagi menjadi 3 bagian, yaitu proses pelaksanaan, kendala yang ditemukan, dan solusi atas kendala yang ditemukan. Penjelasan dari setiap bagian terdapat pada masing- masing subbab berikut.
3.3.1 Proses Pelaksanaan
Dalam pelaksanaan kerja magang, adapun hardware dan software yang digunakan untuk menyelesaikan tugas. Berikut adalah software yang digunakan selama proses pelaksanaan magang.
a. Laravel v7.27.0
b. XAMPP v7.4.2, dengan PHP v7.4.2, Apache v2.4.41, MariaDB v10.4.11, dan phpMyAdmin v5.0.1
c. PhpStorm v2020.2
d. Git v2.26.2 dan GitKraken v7.2.0 e. Insomnia Core v2020.2.2
f. Elasticsearch v7.8.0 dan Kibana 7.8.0
12 g. Redis Server v3.2.100
h. OpenVPN Connect v3.2.0 i. OS Windows 10 Home (64 bit) j. Google Chrome v85.0.4183.33
Hardware yang digunakan adalah laptop ASUS Vivobook S14, dengan spesifikasi sebagai berikut.
a. Processor Intel Core i7-8565U CPU @ 1.80GHz (8 CPU) b. RAM 8GB
c. SSD 256GB
Proses pelaksanaan magang dibagi menjadi 3 bagian, yaitu requirement, perancangan API, dan implementasi.
A. Requirement
API dapat menerima request yang dengan body request yang berbentuk JSON ataupun XML. Seluruh request dikirimkan dengan metode POST. Dalam 1 menit, request yang dapat diterima API dibatasi maksimal berjumlah 60. Hal ini dilakukan untuk menghindari denial of service (DoS) attack. API hanya dapat digunakan oleh user yang terdaftar pada developer.mobilepulsa.net. Setiap request juga memiliki signature masing-masing sebagai syarat authentikasi.
Sebelum diproses oleh API, dilakukan pengecekan terhadap request yang masuk.
Jika request memenuhi syarat dan tidak terjadi error pada saat runtime, maka kode respon sukses dikembalikan beserta keterangannya. Jika request tidak memenuhi syarat, maka kode respon error dikembalikan beserta keterangannya.
13 Terdapat 2 fitur yang dimiliki API, yaitu Generate Report dan Check Status.
Pada fitur Generate Report, data transaksi postpaid diambil dari Elasticsearch, yang terdiri dari id transaksi, waktu inquiry, waktu pembayaran, kode produk, id pelanggan, nama pelanggan, status transaksi, deskripsi produk, harga, harga jual, biaya admin, id reference, nomor pembayaran reference, dan jumlah tagihan.
Pencarian data lebih cepat menggunakan Elasticsearch, karena setiap data disimpan dengan struktur data tertentu yang optimal. Untuk mendapatkan data transaksi tertentu milik user tersebut, terdapat parameter yang wajib diisi pada body request, yaitu tanggal mulai transaksi, tanggal akhir transaksi, status transaksi, jenis transaksi, dan tipe laporan. Maksimal rentang waktu transaksi adalah 31 hari. Selain itu, terdapat parameter yang opsional untuk memfilter data transaksi, yaitu id transaksi, kode produk, id pelanggan, dan id inquiry. Query ke Elasticsearch dibuat dengan menggunakan library Elasticquent.
Laporan transaksi yang dibuat oleh fitur Generate Report memiliki tipe API Pagination atau File. Pada laporan berbentuk API Pagination, respon yang dikembalikan mencakup halaman sekarang, total halaman, total data, laporan transaksi per halaman, dan link untuk menuju halaman sebelum dan selanjutnya.
Respon API Pagination dibuat dengan menggunakan fungsi pagination yang disediakan Laravel. Jumlah data yang diambil maksimal berjumlah 500, dengan jumlah data setiap halaman maksimal berjumlah 10. Sedangkan, pada laporan berbentuk File, respon yang dikembalikan mencakup nama file CSV yang diproses beserta status dari file tersebut. Data transaksi diekspor menjadi CSV, menggunakan library Spout. Library ini digunakan karena dapat membuat file CSV secara cepat dan scalable. File yang berhasil diproses, kemudian diunggah
14 ke cloud AWS S3. AWS S3 merupakan sebuah object storage service yang menyediakan tempat penyimpanan dengan scalability, data availability, security, dan perfomance yang baik. Seluruh data diambil pada laporan dengan tipe File.
Proses pembuatan laporan dengan tipe File hingga pengunggahan ke AWS S3 dilakukan pada background job, agar API tidak perlu menunggu dan dapat langsung mengembalikan respon. Data yang diproses oleh background job, yang disimpan pada Redis. Pengunggahan file ke AWS S3 disimpan berdasarkan direktori setiap pengguna agar rapi. Pada fitur Check Status, pengecekan terhadap status laporan dengan tipe File dilakukan, berdasarkan parameter nama file yang wajib diisi pada body request. Jika file sudah tersedia pada AWS S3, maka respon yang dikembalikan mencakup link download sementara untuk file tersebut.
Untuk memastikan fitur Generate Report dan Check Status berjalan dengan baik, diperlukan Feature dan Unit Testing pada API. Feature Testing digunakan untuk mengecek respon setiap fitur, sedangkan Unit Testing digunakan untuk mengecek respon setiap bagian utama yang membentuk suatu fitur, yaitu controller, service, dan repository. Feature dan Unit Testing akan diterapkan sebagai pipelines CI/CD pada GitLab, untuk membatasi perubahan yang dapat dilakukan pada repository proyek. Perubahan yang dibuat harus lolos dari pipelines CI/CD sehingga resiko terjadinya perubahan yang tidak diinginkan dapat dihindari.
B. Perancangan API
Perancangan API dilakukan dengan menggunakan 4 jenis diagram UML, yaitu use case diagram untuk menggambarkan fungsionalitas sistem yang dapat
15 digunakan oleh aktor, activity diagram untuk menggambarkan alur kerja dari setiap use case, sequence diagram untuk menggambarkan interaksi antar bagian pada sistem dari setiap use case, dan class diagram untuk menggambarkan model dari objek-objek yang digunakan.
B.1. Use Case Diagram
API digunakan oleh user yang terdiri dari client, tim API, dan tim APPS, dan admin yang terdiri dari tim API. User dapat membuat laporan dengan tipe API Pagination dan File, dan mengecek status laporan dengan tipe File. Setiap request yang dikirimkan user divalidasi terlebih dahulu. Admin dapat melakukan Feature dan Unit Testing pada fitur Generate Report dan Check Status. Unit Testing yang dilakukan mencakup Controller Testing, Service Testing, dan Repository Testing. Rancangan use case diagram terdapat pada Gambar 3.1.
Gambar 3.1 Use Case Diagram
16 B.2. Activity Diagram
Activity diagram dibuat dari setiap use case yang dimiliki user dan admin.
Use case milik user terdiri dari Validate Request, Generate Report, Generate API Pagination, Generate File, dan Check Status. Sedangkan, use case milik admin terdiri dari perform Feature Testing, dan Unit Testing yang mencakup Controller Testing, Service Testing, dan Repository Testing.
1) Validate Request
Validasi request dilakukan terlebih dahulu sebelum mengerjakan Generate Report atau Check Status. Rate request yang diterima dibatasi sebanyak 60 request per menit. Jika melebihi batas rate request yang ditetapkan, maka dikembalikan respon berupa undefined error. Jenis konten request yang didukung adalah JSON dan XML. Jika konten request tidak didukung, maka dikembalikan respon berupa invalid content type. Metode yang digunakan untuk mengirimkan request adalah POST. Jika metode yang digunakan tidak diizinkan, maka dikembalikan respon berupa method not allowed. Inisialisasi request kemudian dilakukan. Format parameter pada body request dicek apakah terdapat field wajib yang kosong atau value yang diberikan tidak sesuai. Jika format parameter tidak mengikuti ketentuan, maka dikembalikan respon berupa invalid format beserta keterangan ketentuan yang dilanggar field tersebut.
Jenis transaksi yang dikerjakan adalah postpaid, sehingga rancangan diagram untuk transaksi prepaid tidak dibahas. Request yang lolos dari pengecekan awal, disimpan untuk diproses lebih lanjut. Jika terdapat field tanggal pada request, dilakukan pengecekan interval dari tanggal tersebut apakah melebihi 31 hari. Jika interval tanggal melebihi 31 hari, maka dikembalikan respon berupa
17 date interval cannot more than 31 days. Data user pada request kemudian diambil dari MySQL. Jika data user tidak ditemukan, maka dikembalikan respon berupa invalid data. Jika data user ditemukan, dilakukan pengecekan terhadap signature pada request apakah sama dengan signature yang dihasilkan sistem. Jika signature tidak sama, maka dikembalikan respon berupa wrong authentication.
Rancangan Activity Diagram Validate Request terdapat pada Gambar 3.2.
Gambar 3.2 Activity Diagram Validate Request 2) Generate Report
Laporan transaksi diproses berdasarkan data tipe laporan pada request.
Proses yang terjadi pada laporan dengan tipe file dilanjutkan pada Activity
18 Diagram Generate API Pagination, sedangkan proses yang terjadi pada laporan dengan tipe API Pagination dilanjukan pada Activity Diagram Generate File.
Setelah diproses, respon yang berbentuk array dikonversi menjadi JSON atau XML, sesuai dengan jenis konten pada request. Respon kemudian disimpan, dicetak pada log, dan dikembalikan kepada user. User menerima respon sukses sesuai request yang dikirimkan. Rancangan Activity Diagram Generate Report terdapat pada Gambar 3.3.
Gambar 3.3 Activity Diagram Generate Report 3) Generate API Pagination
Data transaksi milik user tersebut diambil dari Elasticsearch, berdasarkan field wajib dan opsional pada body request. Jika data transaksi kosong, maka dikembalikkan respon berupa data not found. Data transaksi kemudian diformat untuk penamaan field, urutan field, dan value pada field bill quantity. Pada transaksi postpaid, bill quantity berarti jumlah tagihan yang dibayar. Setiap kode
19 produk memiliki jenis periode tagihan masing-masing, yang disimpan pada Elasticsearch berbentuk string. String periode tagihan diolah menjadi integer yang merepresentasikan bill quantity.
Setelah diformat, data transaksi dibuat pagination dan diambil berdasarkan current page. Nilai current page terdapat pada parameter URI request. Jika current page lebih besar dari total page yang dimiliki pagination, maka dikembalikan respon berupa data not found. Data transaksi yang didapatkan berdasarkan current page, kemudian diformat menjadi respon untuk API Pagination. Rancangan Activity Diagram Generate API Pagination Report terdapat pada Gambar 3.4.
Gambar 3.4 Activity Diagram Generate API Pagination 4) Generate File
Laporan dengan tipe File dicek terlebih dahulu apakah sudah tersedia pada AWS S3 berdasarkan nama file. Nama file setiap laporan yang dibuat, diformat sesuai dengan field pada body request. Jika file sudah tersedia, maka diberi nilai true pada sebuah variabel FileExists. Jika file belum tersedia, maka dikembalikan
20 respon sementara pembuatan file dilakukan pada background job. Proses ini berjalan secara asynchronous, sehingga respon pertama kali yang dikembalikan berupa respon pending, yang menandakan file sedang dibuat. Nama file dan nilai variabel FileExists diformat menjadi respon untuk file.
Pembuatan file pada background job dibuat pada temporary file terlebih dahulu. Maksimal jumlah data yang dapat ditarik dari Elasticsearch adalah 10.000, sehingga dilakukan iterasi untuk mendapatkan seluruh data transaksi user tersebut. Setiap data batch kemudian diformat untuk penamaan field, urutan field, dan value pada field bill quantity. Setiap data batch ditulis pada file untuk setiap iterasinya. Setelah iterasi selesai, temporary file diunggah ke AWS S3, lalu dihapus dari storage pada proyek. Rancangan Activity Diagram Generate File Report terdapat pada Gambar 3.5.
Gambar 3.5 Activity Diagram Generate File
21 5) Check Status
Laporan dengan tipe File dicek apakah sudah tersedia pada AWS S3 berdasarkan nama file. Jika file sudah tersedia, maka dibuat link temporary untuk mengunduh file tersebut. Nama file dan link pengunduhan diformat menjadi respon yang berbentuk array. Respon kemudian dikonversi menjadi JSON atau XML, sesuai dengan jenis konten pada request. Respon disimpan, ditampilkan pada log, dan dikembalikan kepada user untuk Check Status. Rancangan Activity Diagram Check Status terdapat pada Gambar 3.6.
Gambar 3.6 Activity Diagram Check Status
6) Perform Feature Testing
Struktur respon JSON yang diharapkan dari Generate Report dan Check Status, ditetapkan terlebih dahulu. Setelah itu, dibuat sebuah record dummy user
22 pada MySQL untuk digunakan pada testing. Testing yang dilakukan mengecek respon sukses yang dikembalikan baik berbentuk JSON maupun XML, dan respon error berbentuk JSON yang dikembalikan untuk invalid content type, invalid format, dan wrong authentication.
Testing respon sukses berbentuk JSON dan XML dilakukan dengan mengirimkan request yang direncanakan ke API. Pada respon sukses berbentuk JSON, dilakukan pengecekan struktur respon JSON apakah sesuai dengan yang ditetapkan. Hal yang serupa juga dilakukan untuk testing respon error berbentuk JSON. Sedangkan pada respon sukses berbentuk XML, pengecekan respon XML dilakukan apakah mengandung kode pesan sukses. Rancangan Activity Diagram Perform Feature Testing terdapat pada Gambar 3.7.
Gambar 3.7 Activity Diagram Perform Feature Testing
23 7) Perform Controller Testing
Struktur respon JSON yang diharapkan dari Controller Generate Report dan check status, ditetapkan terlebih dahulu. Service yang digunakan pada Controller Generate Report dan Check Status dipalsukan dan ditetapkan return data yang diharapkan. Testing return data pada controller dilakukan dengan mengirimkan request yang direncanakan ke API. Kemudian, pengecekan dilakukan status kode HTTP yang dikembalikan dan struktur respon JSON apakah sesuai dengan yang ditetapkan. Setelah testing selesai, service palsu dibersihkan sebelum memasuki testing selanjutnya. Rancangan Activity Diagram Perform Controller Testing terdapat pada Gambar 3.8.
Gambar 3.8 Activity Diagram Perform Controller Testing
24 8) Perform Service Testing
Repository yang digunakan pada Service Generate Report dan Check Status dipalsukan dan ditetapkan return data yang diharapkan. Testing return data pada service dilakukan dengan menginstansiasi objek service. Kemudian, pengecekan return data dilakukan apakah tidak kosong, berbentuk array, dan mengandung kode pesan sukses. Setelah testing selesai, repository palsu dibersihkan sebelum memasuki testing selanjutnya. Rancangan Activity Diagram Perform Service Testing terdapat pada Gambar 3.9.
Gambar 3.9 Activtiy Diagram Perform Service Testing 9) Perform Repository Testing
Return data yang diharapkan dari tiap method pada Repository Generate Report dan Check Status ditetapkan terlebih dahulu. Model yang digunakan pada Service Generate Report dan Check Status dipalsukan dan ditetapkan return data dari method repository yang diharapkan. Testing return data pada method
25 repository dilakukan dengan menginstansiasi objek repository. Kemudian, pengecekan return data pada tiap method dilakukan apakah berbentuk object dan sesuai yang ditetapkan. Setelah testing selesai, model palsu dibersihkan sebelum memasuki testing selanjutnya. Rancangan Activity Diagram Perform Repository Testing terdapat pada Gambar 3.10.
Gambar 3.10 Activity Diagram Perform Repository Testing
B.3. Sequence Diagram
Sequence diagram dibuat dari setiap activity diagram. Terdapat 9 sequence diagram yang menggambarkan urutan kejadian dari setiap aktivitas, yaitu Validate Request, Generate Report, Generate API Pagination, Generate File, Check Status, Perform Feature Testing, Perform Controller Testing, Perform Service Testing, dan Perform Repository Testing.
26 1) Validate Request
Jumlah request yang diterima API dibatasi rate-nya sebanyak 60 request per menit. Jika jumlah request melebihi dari rate, pada request selanjutnya middleware mengembalikan respon undefined error sampai menit berikutnya.
Tipe konten pada request yang didukung adalah JSON atau XML, yang kemudian dikonversi menjadi array. Jika tipe konten tidak berupa JSON atau XML, maka middleware mengembalikan respon invalid content type. Setelah lolos dari middleware, request memasuki endpoint yang dituju, yang terdapat pada route.
Setiap endpoint hanya menerima request dengan metode POST. Jika request yang dikirimkan tidak dengan metode POST, maka route mengembalikan respon method not allowed. Setelah lolos dari route, request memasuki controller dipanggil pada route. Pada controller, dilakukan inisialisasi request dan dilakukan pengecekan tiap field request yang ada dengan pemanggilan fungsi rules() pada class request-nya. Jika format value pada field tertentu tidak mengikuti ketentuan, maka request mengembalikan respon invalid format. Request kemudian dikirimkan pada service untuk diproses lebih lanjut.
Service PostpaidService diinstansiasi dan value pada request disimpan pada properti service dengan pemanggilan fungsi composeRequest(request). Rentang waktu tanggal awal dan akhir yang diperbolehkan maksimal adalah 31 hari. Jika melebihi 31 hari, maka service mengembalikan respon date interval cannot more than 31 days. Data user kemudian dicari pada repository dengan pemanggilan fungsi findUserByUsername(username). Jika user ditemukan, maka dikembalikan objek user yang sesuai. Jika user tidak ditemukan, maka repository mengembalikan respon data not found. Signature yang terdapat dicek apakah
27 sesuai dengan objek user yang didapatkan dan format signature-nya dengan pemanggilan fungsi checkSignature(user, format). Jika signature tidak sesuai, maka service mengembalikan respon wrong authentication. Rancangan Sequence Diagram Validate Request terdapat pada Gambar 3.11.
Gambar 3.11 Sequence Diagram Validate Request 2) Generate Report
Terdapat 2 jenis laporan untuk diproses, yaitu API Pagination dan File. Jika jenis laporan berupa API Pagination, maka diinstansiasi Service APIPaginationReport yang menerima parameter berupa model, username, dan request. Jika jenis laporan berupa File, maka diinstansiasi Service FileReport yang
28 menerima parameter berupa model, username, request, dan filename. Service kemudian dijalankan dan menghasilkan respon. Respon diformat sesuai dengan tipe konten yang dikirimkan pada request dengan pemanggilan fungsi checkFormat(response) pada helper. Jika tipe konten berbentuk XML, maka dikembalikan respon berbentuk XML dengan pemanggilan fungsi convertToXML(response). Jika tipe konten berbentuk JSON, maka dikembalikan respon berbentuk JSON dengan pemanggilan fungsi convertToJSON(response).
Respon kemudian ditampilkan pada log dengan pemanggilan fungsi logAPIData(), dan dikembalikan kepada user. Rancangan Sequence Diagram Generate Report terdapat pada Gambar 3.12.
Gambar 3.12 Sequence Diagram Generate Report
29 3) Generate API Pagination
Data transaksi milik user tersebut dicari pada repository dengan pemanggilan fungsi getPascaTransactions(username, startDate, endDate, status, filter). Jika data ditemukan, maka dikembalikan objek data transaksi. Jika data tidak ditemukan, maka repository mengembalikan respon data not found. Objek data kemudian diformat dari segi urutan, penamaan indeks, dan value transaksi postpaid-nya dengan pemanggilan fungsi formatPascaTransaction(data) pada helper. Hasil objek data yang telah diformat kemudian diberi pagination sesuai jumlah data per halamannya dengan pemanggilan fungsi pagination(results, perPage) pada helper. Untuk menampilkan data pada halaman sekarang digunakan parameter page dibelakang URL endpoint. Jika halaman sekarang lebih kecil atau sama dengan total halaman yang ada, maka dikembalikan data pada halaman sekarang. Jika halaman sekarang lebih besar dari total halaman yang ada, maka dikembalikan respon data not found. Data kemudian diformat menjadi respon API pagination dengan formatAPIPaginationResponse(data). Rancangan Sequence Diagram Generate API Pagination terdapat pada Gambar 3.13.
Gambar 3.13 Sequence Diagram Generate API Pagination
30 4) Generate File
File dicek terlebih dahulu apakah sudah tersedia pada AWS S3 dengan melakukan pencarian pada nama file-nya. Jika file tidak ditemukan, maka file dianggap belum tersedia dan background job dijalankan. dengan pemanggilan fungsi dispatch(data, username, request, filename, folderPath, header).
Background job akan membuat file CSV dengan header dan mengunggahnya ke AWS S3 ke folder path yang telah ditetapkan. Jika file ditemukan, maka file dianggap sudah tersedia dan boolean fileExistsTrue diberi nilai true sebagai penanda. Filename dan fileExists kemudian diformat menjadi respon file dengan pemanggilan fungsi formatFileResponse(filename, fileExists) pada contract.
Sementara respon pertama kali dikembalikan, background job membuat file sementara. Background job kemudian menarik data batch transaksi awal dengan pemanggilan fungsi getAllTransactions(username, startDate, endDate, status, filter). Selanjutnya, dilakukan looping untuk memformat data transaksi dengan pemanggilan fungsi formatPascaTransactions(data) pada helper dan menulisnya pada file sementara. Looping dilanjutkan dengan mengambil data batch transaksi selanjutnya melalui pemanggilan fungsi getNextScroll(scrollId) sampai seluruh data batch. File sementara kemudian diunggah ke AWS S3 dan dihapus. Setelah selesai menjalankan tugasnya, background job kembali kepada service.
Rancangan Sequence Diagram Generate File terdapat pada Gambar 3.14.
31 Gambar 3.14 Sequence Diagram Generate File
5) Check Status
File dicek terlebih dahulu apakah sudah tersedia pada AWS S3. Jika file sudah tersedia, maka link temporary downloadURL ditetapkan. Filename dan downloadUrl diformat menjadi respon check status dengan pemanggilan fungsi formatCheckStatusResponse(). Respon diformat sesuai dengan tipe konten yang dikirimkan pada request dengan pemanggilan fungsi checkFormat(response) pada helper. Jika tipe konten berbentuk XML, maka dikembalikan respon berbentuk XML dengan pemanggilan fungsi convertToXML(response). Jika tipe konten berbentuk JSON, maka dikembalikan respon berbentuk JSON dengan
32 pemanggilan fungsi convertToJSON(response). Respon kemudian ditampilkan pada log dengan pemanggilan fungsi logAPIData(), dan dikembalikan kepada user. Rancangan Sequence Diagram Check Status terdapat pada Gambar 3.15.
Gambar 3.15 Sequence Diagram Check Status
6) Perform Feature Testing
Struktur respon sukses JSON diambil dari MockData dengan pemanggilan fungsi getJSONResponseStructure(). Record user dummy dibuat dengan pemanggilan fungsi factory(user) pada testing. Testing dilakukan dengan mengecek respon sukses untuk tipe konten JSON dan XML dengan pemanggilan fungsi testJSONResponse() dan testXMLResponse(), serta respon error untuk tipe konten JSON dengan pemanggilan fungsi invalidContentTypeJsonTest(url, sign),
33 invalidFormatJsonTest(url), dan wrongAuthenticationJsonTest(url, sign, data).
Parameter url berisi endpoint request dummy dikirimkan. Parameter sign berisi sign dari request dummy. Parameter data berisi nilai pada body request dummy.
Rancangan Sequence Diagram Perform Feature Testing terdapat pada Gambar 3.16.
Gambar 3.16 Sequence Diagram Perform Feature Testing
7) Perform Controller Testing
Struktur respon sukses JSON diambil dari MockData dengan pemanggilan fungsi getJSONResponseStructure(). Record user dummy dibuat dengan pemanggilan fungsi factory(user) pada test. Return data dari objek service diambil dari MockData. Objek service kemudian dipalsukan dengan pemanggilan fungsi mockClass(classService). Testing dilakukan dengan mengecek return data yang
34 dikembalikan dari controller. Objek service yang dipalsukan, dihapus dari enviroment testing sebelum masuk ke testing selanjutnya. Rancangan Sequence Diagram Controller Testing terdapat pada Gambar 3.17.
Gambar 3.17 Sequence Diagram Perform Controller Testing
8) Perform Service Testing
Return data dari objek repository diambil dari MockData. Objek repository kemudian dipalsukan dengan pemanggilan fungsi mockClass(repositoryClass).
Testing dilakukan dengan mengecek return data yang dikembalikan dari service.
Objek repository yang dipalsukan, dihapus dari enviroment testing sebelum masuk ke testing selanjutnya. Rancangan Sequence Diagram Service Testing terdapat pada Gambar 3.18.
35 Gambar 3.18 Sequence Diagram Perform Service Testing
9) Perform Repository Testing
Return data dari method yang terdapat pada repository diambil dari MockData. Objek model kemudian dipalsukan dengan pemanggilan fungsi mockClass(modelClass). Testing dilakukan dengan mengecek return data yang dikembalikan dari repository. Objek model yang dipalsukan, dihapus dari enviroment testing sebelum masuk ke testing selanjutnya. Rancangan Sequence Diagram Repository Testing terdapat pada Gambar 3.19.
Gambar 3.19 Sequence Diagram Perform Repository Testing
36 B.4. Class Diagram
Class diagram dibuat berdasarkan kebutuhan kelas pada setiap sequence diagram. Terdapat 14 jenis kelas utama yang digunakan pada perancangan API, yaitu Middleware, Exception, Contract, Helper, Trait, Request, Controller, Service, Job, Repository, Model, Feature Dan Controller Testing, Data Mock, serta Service dan Unit Testing.
1) Middleware
Middleware memiliki peran untuk melakukan penyaringan awal pada request sebelum masuk pada route. Terdapat 2 kelas yang menjadi bagian Middleware, yaitu ContentType dan ThrottleRequests. Rancangan Class Diagram Middleware terdapat pada Gambar 3.20.
Gambar 3.20 Class Diagram Middleware
a) ContentType
Kelas ini berfungsi untuk mengecek tipe konten request.
b) ThrottleRequests
Kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi untuk membatasi rate request.
2) Exception
Exception memiliki peran untuk menangani error handling pada API.
Terdapat 10 kelas yang menjadi bagian Exception, yaitu Exception,
37 ExceptionBaseAPI, TransactionNotFound, DataNotFound, InvalidContentType, InvalidDateInterval, WrongAuthentication, UndefinedError, ExceptionHandler, dan Handler. Rancangan Class Diagram Exception terdapat pada Gambar 3.21.
Gambar 3.21 Class Diagram Exception
a) Exception
Kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi sebagai base class dari semua kelas Exception.
b) ExceptionBaseAPI
Kelas ini merupakan kelas abstrak dan berfungsi sebagai parent class dari semua kelas Exception untuk API.
c) TransactionNotFound
Kelas ini berfungsi untuk membuat exception ketika data transaksi tidak ditemukan.
38 d) DataNotFound
Kelas ini berfungsi untuk membuat exception ketika data user tidak ditemukan.
e) InvalidContentType
Kelas ini berfungsi untuk membuat exception ketika tipe konten request dengan bentuk selain JSON dan XML.
f) InvalidDateInterval
Kelas ini berfungsi untuk membuat exception ketika rentang waktu tanggal awal dan akhir berjumlah lebih dari 31 hari.
g) WrongAuthentication
Kelas ini berfungsi untuk membuat exception ketika signature tidak sesuai dengan yang seharusnya.
h) UndefinedError
Kelas ini berfungsi untuk membuat exception ketika rate request lebih dari 60 request per menit.
i) ExceptionHandler
Kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi sebagai base class dari kelas handler.
j) Handler
Kelas ini berfungsi untuk menangani exception yang timbul pada aplikasi.
3) Contract
Contract memiliki peran untuk melakukan format respon. Terdapat kelas GenerateReportResponse yang menjadi bagian dari Contract. Rancangan Class Diagram Contract terdapat pada Gambar 3.22.
39 Gambar 3.22 Class Diagram Contract
a) GenerateReportResponse
Kelas ini berfungsi untuk memformat respon untuk Generate Report, baik API Pagination maupun File.
4) Helper
Helper memiliki peran untuk melakukan format return data. Terdapat 5 kelas yang menjadi bagian dari Helper, yaitu FormatContentType, FormatTransactions, FormatValue, FormatBillQuantity, dan FormatPagination.
Rancangan Class Diagram Helper terdapat pada Gambar 3.23.
Gambar 3.23 Class Diagram Helper
a) FormatContentType
Kelas ini berfungsi untuk memformat respon menjadi JSON atau XML.
b) FormatTransactions
Kelas ini berfungsi untuk memformat data transaksi yang diambil dari repository.
40 c) FormatValue
Kelas ini berfungsi untuk memformat field pada data transaksi yang diambil dari repository.
d) FormatBillQuantity
Kelas ini berfungsi untuk memformat field periode tagihan pada data transaksi yang diambil dari repository.
e) FormatPagination
Kelas ini berfungsi untuk memberikan pagination pada data transaksi yang diambil dari repository.
5) Trait
Trait memiliki peran untuk memungkinkan multiple inheritance pada suatu class. Terdapat 11 kelas yang menjadi bagian dari Trait, yaitu LoggingTrait, AuthenticationTrait, ValidateRequests, DispatchJobs, ShouldQueue, Dispatchable, InteractsWith-Queue, Queueable, SerializesModels, DatabaseTransactions, Elasticquent. Rancangan Class Diagram Trait terdapat pada Gambar 3.24.
Gambar 3.24 Class Diagram Trait
41 a) LoggingTrait
Kelas ini berfungsi untuk menampilkan respon pada log.
b) AuthenticationTrait
Kelas ini berfungsi untuk melakukan authentikasi pada user.
c) AuthorizeRequests
Kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi untuk melakukan authentikasi pada request.
d) ValidateRequests
Kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi untuk mengecek request.
e) DispatchJobs
Kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi untuk memulai menjalankan background job.
f) ShouldQueue, Dispatchable, InteractsWithQueue, Queueable, SerializesModels
Kelas-kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi untuk menjalankan background job pada queue.
g) DatabaseTransactions
Kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi untuk mengembalikan database ke susunan record semula. Dalam proyek ini digunakan setelah Feature dan Controller Testing selesai.
h) Elasticquent
Kelas ini merupakan kelas yang disediakan dari library Elasticquent dan berfungsi untuk menyediakan fungsi query ke Elasticsearch.
42 6) Request
Request memiliki peran untuk mengecek dan menginstansiasi objek request.
Terdapat 2 kelas yang menjadi bagian dari Request, yaitu GenerateReportRequest dan CheckStatusRequest. Rancangan Class Diagram Request terdapat pada Gambar 3.25.
Gambar 3.25 Class Diagram Request
a) GenerateReportRequest
Kelas ini berfungsi untuk mengecek dan menginstansiasi objek request untuk Generate Report.
b) CheckStatusRequest
Kelas ini berfungsi untuk mengecek dan menginstansiasi objek request untuk Check Status.
7) Controller
Controller memiliki peran untuk melakukan alur kerja dari aplikasi.
Terdapat 5 kelas yang menjadi bagian dari Controller, yaitu BaseController, Controller, ControllerAPI, GenerateReportController, dan CheckStatusController.
Rancangan Class Diagram Controller terdapat pada Gambar 3.26.
43 Gambar 3.26 Class Diagram Controller
a) BaseController
Kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi untuk sebagai base class dari semua kelas Controller.
b) Controller
Kelas ini berfungsi untuk melakukan multiple inheritance pada Trait yang dibutuhkan.
c) ControllerAPI
Kelas ini berfungsi sebagai parent class untuk semua kelas controller untuk API.
d) GenerateReportController
Kelas ini berfungsi untuk mengatur alur kerja Generate Report.
e) CheckStatusController
Kelas ini berfungsi untuk mengatur alur kerja Check Status.
44 8) Service
Service memiliki peran untuk menjalankan business logic dari Controller.
Terdapat 6 kelas yang menjadi bagian dari Service, yaitu ServiceBaseAPI, IAPIService, PostpaidReportService, APIPaginationReport, FileReport, dan CheckStatusService. Rancangan Class Diagram Service terdapat pada Gambar 3.27.
Gambar 3.27 Class Diagram Service
a) ServiceBaseAPI
Kelas ini merupakan kelas abstrak dan berfungsi sebagai parent class dari semua kelas Service untuk API.
b) IAPIService
Kelas ini berfungsi untuk sebagai interface dari semua kelas Service untuk API.
45 c) PostpaidReportService
Kelas ini berfungsi untuk memproses request Generate Report.
d) APIPaginationReport
Kelas ini berfungsi untuk memproses laporan dengan tipe API Pagination.
e) FileReport
Kelas ini berfungsi untuk memproses laporan dengan tipe File.
f) CheckStatusService
Kelas ini berfungsi untuk memproses request Check Status.
9) Job
Job memiliki peran untuk menjalankan background job pada queue.
Terdapat sebuah kelas yang menjadi bagian dari Job, yaitu GenerateFile.
Rancangan Class Diagram Job terdapat pada Gambar 3.28.
Gambar 3.28 Class Diagram Job
46 a) GenerateFile
Kelas ini berfungsi untuk membuat laporan dengan tipe File dan mengunggahnya ke AWS S3.
10) Repository
Repository memiliki peran untuk mengambil data dari model yang terhubung dengan database. Terdapat 5 kelas yang menjadi bagian dari Repository, yaitu RepoBase, IMsUserRepo, ITrPascaRepo, dan MsUserRepo, dan TrPascaRepo. Rancangan Class Diagram Repository terdapat pada Gambar 3.29.
Gambar 3.29 Class Diagram Repository
a) RepoBase
Kelas ini berfungsi sebagai parent class dari semua kelas Repository untuk API.
b) IUserRepo
Kelas ini berfungsi sebagai interface dari kelas UserRepo.
47 c) ITrPascaRepo
Kelas ini berfungsi sebagai interface dari kelas ITrPascaRepo.
d) UserRepo
Kelas ini berfungsi untuk mengambil data dari model User.
e) TrPascaRepo
Kelas ini berfungsi untuk mengambil data dari model TrPasca.
11) Model
Model memiliki peran untuk merepresentasikan tabel pada database.
Terdapat 3 kelas yang menjadi bagian dari Model, yaitu Model, User dan TrPasca.
Rancangan Class Diagram Model terdapat pada Gambar 3.30.
Gambar 3.30 Class Diagram Model
a) Model
Kelas ini merupakan kelas yang disediakan dari Laravel dan berfungsi untuk menjadi base class dari semua kelas Model.
b) User
Kelas ini berfungsi untuk merepresentasikan tabel terkait user pada database.
48 c) TrPasca
Kelas ini berfungsi untuk merepresentasikan tabel terkait data transaksi postpaid pada database.
12) Feature dan Controller Testing
Feature Testing memiliki peran untuk melakukan testing pada fitur Generate Report dan Check Status. Controller Testing memiliki peran untuk mengecek return data dari suatu controller. Terdapat 6 kelas yang menjadi bagian dari Feature Testing, yaitu TestCase, TestBase, GenerateReportControllerTest, GenerateReportTest, CheckStatusControllerTest, CheckStatusTest. Rancangan Class Diagram Feature dan Controller Testing terdapat pada Gambar 3.31.
Gambar 3.31 Feature dan Controller Testing
49 a) TestCase
Kelas ini merupakan kelas yang disediakan oleh Laravel dan berfungsi sebagai base class dari seluruh kelas Testing.
b) TestBase
Kelas ini berfungsi sebagai parent class dari seluruh kelas Feature dan Controller Testing untuk API.
c) GenerateReportTest
Kelas ini berfungsi untuk mengecek respon dari fitur Generate Report.
d) GenerateReportControllerTest
Kelas ini berfungsi untuk mengecek return data dari Controller GenerateReportController.
e) CheckStatusTest
Kelas ini berfungsi untuk mengecek respon dari fitur Check Status.
f) CheckStatusControllerTest
Kelas ini berfungsi untuk mengecek return data dari Controller CheckStatusController.
13) Data Mock
Data Mock memiliki peran untuk menyediakan return data yang diharapkan dari Unit Testing (Controller Testing, Service Testing, Repository Testing).
Terdapat 6 kelas yang menjadi bagian dari DataMock, yaitu MockCheckStatusStructure, MockPostpaidReportStructure, MockUserRepo, MockTrPascaRepo, MockCheckStatusService, dan MockPostpaidReportService.
Rancangan Class Diagram Data Mock terdapat pada Gambar 3.32.
50 Gambar 3.32 Class Diagram Data Mock
a) MockCheckStatusStructure
Kelas ini berfungsi untuk mengambil return data dari Controller CheckStatusController.
b) MockPostpaidReportStructure
Kelas ini berfungsi untuk mengambil return data dari Controller GenerateReportController.
c) MockUserRepo
Kelas ini berfungsi untuk mengambil return data dari repository terkait data user.
d) MockTrPascaRepo
Kelas ini berfungsi untuk mengambil return data dari repository terkait data transaksi postpaid.
e) MockCheckStatusService
Kelas ini berfungsi untuk mengambil return data dari Service CheckStatusService.
f) MockPostpaidReportService
Kelas ini berfungsi untuk mengambil return data dari Service PostpaidReportService.
51 14) Service dan Repository Testing
Service Testing memiliki peran untuk mengecek return data dari suatu service. Repository Testing memiliki peran untuk mengecek return data dari suatu repository. Terdapat 5 kelas yang menjadi bagian dari Service dan Repository Testing, yaitu TestCase, PostpaidReportServiceTest, CheckStatus- ServiceTest, TrPascaRepoTest, UserRepoTest. Rancangan Class Diagram Service dan Repository Testing terdapat pada Gambar 3.33.
Gambar 3.33 Class Diagram Service dan Repository Testing a) TestCase
Kelas ini merupakan kelas yang disediakan oleh Laravel dan berfungsi sebagai base class dari seluruh kelas Testing.
b) PostpaidReportServiceTest
Kelas ini berfungsi untuk mengecek return data dari Service PostpaidReportService.
c) CheckStatusServiceTest
Kelas ini berfungsi untuk mengecek return data dari Service CheckStatusService.
52 d) TrPascaRepoTest
Kelas ini berfungsi untuk mengecek return data dari setiap method pada Repository TrPascaRepo.
e) UserRepoTest
Kelas ini berfungsi untuk mengecek return data dari setiap method pada Repository UserRepo.
C. Implementasi
Implementasi dilakukan dengan membuat dokumentasi penggunaan dan menguji API.
C.1. Dokumentasi
Terdapat 2 endpoint yang merepresentasikan fitur Generate Report dan Check Status.
1) Generate Report
Fitur Generate Report digunakan untuk membuat laporan dengan tipe File atau API Pagination. Endpoint yang digunakan adalah /report/generate. Parameter field yang terdapat pada Request Generate Report dapat dilihat pada Tabel 3.2 sedangkan parameter field yang terdapat pada Response Generate Report dapat dilihat pada Tabel 3.3 (API Pagination) dan Tabel 3.4 (File).
Tabel 3.3 Dokumentasi Request Parameter Generate Report
Field Jenis Nilai Sifat Deskripsi
username String Wajib Username yang terdaftar pada database
start_date String Wajib Tanggal awal laporan
53 Tabel 3.2 Dokumentasi Request Parameter Generate Report (lanjutan)
Field Jenis Nilai Sifat Deskripsi
end_date String Wajib Tanggal akhir laporan
status String Wajib Status transaksi
type String Wajib Jenis transaksi
method String Opsional Tipe laporan
filter Array Wajib Filter laporan berdasarkan:
tr_id
product_code customer_id ref_id
sign String Wajib Hasil fungsi hash md5() dari
username+api_key+type
Tabel 3.4 Dokumentasi Response Parameter Generate API Pagination Report
Field Jenis Nilai Deskripsi
current_page Integer Halaman sekarang
total_page Integer Total halaman
total_data Integer Total data
report Array Array berisi laporan
report[x][tr_id] Integer Id transaksi
report[x][inquiry_datetime] String Tanggal transaksi inquiry report[x][finish_datetime] String Tanggal transaksi selesai report[x][product_code] String Kode produk
report[x][customer_id] String Id customer report[x][customer_name] String Nama customer report[x][status] Integer Status transaksi report[x][nominal] String Deskripsi produk
report[x][price] Integer Harga awal
report[x][selling_price] Integer Harga jual
report[x][admin] Integer Biaya admin
report[x][ref_id] String Id reference
report[x][ref_bill_payment] String Id payment report[x][bill_qty] Integer Kuantitas tagihan
next_page_url String Link ke page sebelum
prev_page_url String Link ke page sesudah
rc String Kode respon
message String Pesan
54 Tabel 3.5 Dokumentasi Response Parameter Generate File Report
Field Jenis Nilai Deskripsi
filename String Nama file laporan
rc String Kode respon
message String Pesan
2) Check Status
Fitur Generate Report digunakan untuk mengecek status laporan dengan tipe File. Endpoint yang digunakan adalah /report/check-status. Parameter field yang terdapat pada Request Check Status dapat dilihat pada Tabel 3.5, sedangkan parameter field yang terdapat pada Response Check Status dapat dilihat pada Tabel 3.6.
Tabel 3.6 Dokumentasi Request Parameter Check Status
Field Jenis Nilai Sifat Deskripsi
username String Wajib Username yang terdaftar pada database
filename String Wajib Nama file laporan
sign String Wajib Hasil fungsi hash md5() dari
username+api_key+filename
Tabel 3.7 Dokumentasi Response Parameter Check Status
Field Jenis Nilai Deskripsi
filename String Nama file laporan
downloadUrl String Link untuk mengunduh
laporan jika file sudah tersedia
rc String Kode respon
message String Pesan
C.2. Pengujian API
Pengujian API dilakukan dengan mengirimkan request ke API dengan tool Insomnia, dan menjalankan Feature dan Unit Testing dengan library PHPUnit, pada endpoint lokal.
55 1) Request ke API
Request yang dikirimkan terdiri dari Request Generate Report untuk tipe laporan API Pagination dan File, Request Check Status, dan request yang tidak valid. Pada Request Generate Report dan Check Status, dikirimkan request berbentuk JSON dan XML untuk menunjukkan apakah request berhasil untuk kedua tipe konten. Pada request yang tidak valid, hanya dikirimkan request berbentuk JSON untuk menunjukkan apakah validasi request sudah sesuai.
a) Request Generate API Pagination Report
Request yang dikirimkan untuk membuat laporan berbentuk API Pagination mengembalikan respon sukses. Hasil respon terdapat pada Gambar 3.34 (respon JSON) dan Gambar 3.35 (respon XML).
Gambar 3.34 Uji Generate API Pagination Report berbentuk JSON
56 Gambar 3.35 Uji Generate API Pagination Report berbentuk XML b) Request Generate File Report
Request yang dikirimkan untuk membuat laporan berbentuk file mengembalikan respon proses pertama kali. Background job untuk memproses file kemudian berjalan pada Redis. Setelah laporan file berhasil dibuat, request dikirimkan lagi dan API mengembalikan respon sukses.
Hasil respon sukses terdapat pada Gambar 3.36 (respon JSON) dan Gambar 3.37 (respon XML), serta respon proses terdapat pada Gambar 3.38 (respon JSON) dan Gambar 3.39 (respon XML). Tampilan background job yang berjalan pada Redis terdapat pada Gambar 3.40.
Gambar 3.36 Uji Generate File Report berbentuk JSON (respon sukses)
57 Gambar 3.37 Uji Generate File Report berbentuk XML (respon sukses)
Gambar 3.38 Uji Generate File Report berbentuk JSON (respon proses)
Gambar 3.39 Uji Generate File Report berbentuk XML (respon proses)
Gambar 3.40 Uji background job pada Redis c) Request Check Status
Request yang dikirimkan untuk membuat laporan berbentuk file mengembalikan respon proses jika file belum tersedia. Setelah laporan file tersedia, request dikirimkan lagi dan API mengembalikan respon sukses.
Hasil respon sukses terdapat pada Gambar 3.41 (respon JSON) dan
58 Gambar 3.42 (respon XML), serta respon proses terdapat pada Gambar 3.43 (respon JSON) dan Gambar 3.44 (respon XML).
Gambar 3.41 Uji Check Status berbentuk JSON (respon sukses)
Gambar 3.42 Uji Check Status berbentuk XML (respon sukses)
Gambar 3.43 Uji Check Status berbentuk JSON (respon proses)
Gambar 3.44 Uji Check Status berbentuk XML (respon proses)
59 d) Request Invalid Format
Request dengan penamaan dan nilai field yang tidak valid sesuai dengan rule setiap field dikirimkan. API kemudian mengembalikan respon invalid format. Hasil respon invalid format terdapat pada Gambar 3.45.
Gambar 3.45 Uji Validation Invalid Format berbentuk JSON e) Request Invalid Data
Request dengan username yang tidak terdaftar pada database dikirimkan.
API kemudian mengembalikan respon invalid data. Hasil respon invalid data terdapat pada Gambar 3.46.
Gambar 3.46 Uji Validation Invalid Data berbentuk JSON
60 f) Request Wrong Authentication
Request dengan signature yang tidak cocok dengan hasil hash yang seharusnya dikirimkan. API kemudian mengembalikan respon wrong authentication. Hasil respon wrong authentication terdapat pada Gambar 3.47.
Gambar 3.47 Uji Validation Wrong Authentication berbentuk JSON g) Request Date Interval Cannot More Than 31 Days
Request dengan rentang waktu tanggal awal dan tanggal akhir lebih dari 31 hari dikirimkan. API kemudian mengembalikan respon date interval cannot more than 31 days. Hasil respon date interval cannot more than 31 days terdapat pada Gambar 3.48.
Gambar 3.48 Uji Validation Date Interval Cannot More Than 31 Days berbentuk JSON
61 h) Request Data Not Found
Request dengan filter yang menyebabkan transaksi tidak dapat ditemukan, dikirimkan. API kemudian mengembalikan respon data not found. Hasil respon data not found terdapat pada Gambar 3.49.
Gambar 3.49 Uji Validation Date Not Found berbentuk JSON i) Request Page Not Found
Request dengan endpoint yang salah dikirimkan. API kemudian mengembalikan respon page not found. Hasil respon page not found terdapat pada Gambar 3.50.
Gambar 3.50 Uji Validation Page Not Found berbentuk JSON j) Request Method Not Allowed
Request dengan method yang tidak didukung dikirimkan. API kemudian mengembalikan respon method not allowed. Hasil respon method not allowed terdapat pada Gambar 3.51.
62 Gambar 3.51 Uji Validation Method Not Allowed berbentuk JSON k) Request Undefined Error
Request dengan jumlah yang melebihi batas rate dikirimkan. API kemudian mengembalikan respon undefined error. Hasil respon undefined error terdapat pada Gambar 3.52.
Gambar 3.52 Uji Validation Undefined Error berbentuk JSON
2) Feature dan Unit Testing
Feature dan Unit Testing yang dijalankan dengan PHPUnit, berhasil lolos dari setiap assertion pada setiap test case. Pada Feature Testing, test case yang diterapkan mencakup testing respon sukses berbentuk JSON dan XML untuk fitur Generate Report dengan tipe laporan API Pagination, respon proses berbentuk JSON dan XML untuk fitur Check Status, dan respon error berbentuk JSON, yaitu invalid content type, invalid format, dan invalid date interval.
Pada Unit Testing, test case diterapkan untuk Controller Testing, Service Testing, dan Repository Testing. Pada Controller Testing, test case yang diterapkan mencakup return data untuk Controller GenerateReportContoller
63 dengan tipe laporan API Pagination, dan return data sukses untuk Controller CheckStatusController. Pada Service Testing, test case yang diterapkan mencakup return data untuk Service PostpaidReportService dengan tipe laporan API Pagination, dan return data proses untuk Service CheckStatusService. Pada Repository Testing, test case yang diterapkan mencakup return data untuk method getPascaTransactions pada Repository TrPascaRepo, dan return data untuk method findUserByUsername pada Repository UserRepo. Tampilan Feature dan Unit Testing yang dijalankan pada PHPUnit terdapat pada Gambar 3.53.
Gambar 3.53 Uji Feature dan Unit Testing dengan PHPUnit
3.3.2 Kendala yang Ditemukan
Kendala yang ditemukan selama melaksanakan kerja magang adalah sebagai berikut.
a. Pengerjaan proyek menggunakan framework, tools, library yang belum pernah digunakan sebelumnya.
b. Pengerjaan proyek harus mengikuti prinsip clean code yang belum pernah diterapkan sebelumnya.
c. Pengerjaan proyek membutuhkan pemahaman pada transaksi postpaid yang belum diketahui sebelumnya.
64 3.3.3 Solusi atas Kendala yang Ditemukan
Solusi yang ditemukan selama melaksanakan kerja magang adalah sebagai berikut.
a. Mempelajari penggunaan framework, tools, dan library melalui dokumentasi resmi pada website, video dan website tutorial, serta bertanya kepada pembimbing lapangan dan anggota tim API lainnya.
b. Mempelajari struktur dan penulisan kode yang rapi pada proyek API lainnya yang dikelola oleh tim API, serta bertanya kepada pembimbing lapangan dan anggota tim API lainnya.
c. Mempelajari transaksi postpaid melalui dokumentasi produk dan website developer.mobilepulsa.net, serta bertanya kepada pembimbing lapangan dan anggota tim API lainnya.
