Pembuatan API Base Interest untuk Modul Microservice Perhitungan Bunga pada PT Anabatic Technologies Tbk

(1)

Hak cipta dan penggunaan kembali:

Lisensi ini mengizinkan setiap orang untuk menggubah, memperbaiki, dan membuat ciptaan turunan bukan untuk kepentingan komersial, selama anda mencantumkan nama penulis dan melisensikan ciptaan turunan dengan syarat yang serupa dengan ciptaan asli.

Copyright and reuse:

This license lets you remix, tweak, and build upon work

non-commercially, as long as you credit the origin creator

and license it on your new creations under the identical

terms.

(2)

BAB III

PELAKSANAAN KERJA MAGANG

3.1 Kedudukan dan Koordinasi

Gambar 3.1 Bagan Kedudukan dan Koordinasi Proyek Perhitungan Bunga

Gambar 3.1 menunjukkan kedudukan dan koordinasi dalam proyek yang dikerjakan. Kedudukan yang diberikan saat kerja magang adalah sebagai back-end developer bersama dengan tiga peserta magang lain dalam departemen Product Research and Development Center, yang dikepalai oleh Bapak Trias Fikriansyah selaku Head of System Development yang juga merupakan mentor. Proyek pengerjaan modul perhitungan bunga dikepalai oleh Ibu Rahajeng Iga Titisari.

Pengerjaan proyek dibimbing oleh Bapak Heri Purwanto dan Bapak Taufik Muliahadi sebagai Team Lead. Di dalam proyek juga terdapat tester yang dijabat oleh Ibu Dhani Fatima Rahmawati.

Project Manager Rahajeng Iga Titisari

Team Lead Heri Purwanto &

Taufik Muliahadi

Developer (Magang) Frangky

Developer (Magang) Gabriella Putri

Developer (Magang) Joash Christian

Chandra

Developer (Magang) Willy Christian

Tester Dhani Fatima

Rahmawati

(3)

Koordinasi selama pengerjaan proyek dilakukan melalui beberapa cara sebagai berikut.

1. Skype, digunakan untuk komunikasi sehari-hari dan daily scrum meeting.

2. Redmine, sebagai aplikasi manajemen proyek.

3. Rapat di meeting room untuk melakukan sprint review.

3.2 Tugas Kerja Magang

Pada awal praktek kerja magang, tugas yang diberikan adalah mempelajari modul-modul pengenalan terhadap software dan framework yang akan digunakan, yang terdiri dari instalasi JDK, Apache Tomcat, Eclipse, Maven, Spring Framework, dan Hibernate Framework.

Setelah mempelajari modul, barulah dimulai pengerjaan proyek modul microservice untuk perhitungan bunga menggunakan bahasa pemrograman Java.

Deskripsi tugas yang dilakukan selama kerja magang setiap minggunya dijabarkan pada Tabel 3.1 berikut.

Tabel 3.1Aktivitas Kerja Mingguan Minggu

ke-

Jenis Pekerjaan yang dilakukan Mahasiswa

1 Mempelajari Spring, Spring Boot, PostgreSQL, Spring Security, Hibernate JPA, JPA Annotation, Hibernate Query Language

2 Membuat RESTful web service dari apa yang sudah dipelajari, review

3 Menambahkan custom security kedalam RESTful web service, review

4 Masuk Project, mempelajari mongoDB, Apache karaf, morphia, memindahkan code dari project sebelumnya ke project sekarang, membuat Javadoc

5 Masuk project baru, membuat entity, beserta DAO, Service dan API, sampai dengan test

6 Melanjutkan task pada minggu sebelumnya, dengan menghubungkan code dengan database, review, membuat CRUD RESTful web service untuk interest

(4)

Tabel 3.2 Aktivitas Kerja Mingguan (Lanjutan) Minggu

ke- Jenis Pekerjaan yang dilakukan Mahasiswa

7 Menggabungkan code dari developer lain, memperbaiki bug

8 Debugging bug yang ditemukan oleh tester, membuat Junit test, merapikan JavaDoc, membuat dan memperbaiki validation.

9 Melanjutkan CRUD dari entity yang sudah dibuat(update), memberikan detail seperti parameter, menyesuaikan method pada API, memperbaiki bug, review

10 Merapikan code dari bug yang ada, menaikkan coverage, merapikan annotation, membuat test

11 Mebuat method, pecahan dari update yang sudah dibuat, memperbaiki bug yang ditemukan tester, review

3.3 Uraian Kerja Magang

Urian kerja magang yang dilakukan selama proses kerja magang adalah sebagai berikut.

3.3.1 Proses Pelaksanaan

Pengembangan modul perhitungan bunga menggunakan model scrum dalam pengerjaannya. Scrum adalah sebuah model kerangka kerja, dimana tim developer berkolaborasi untuk mengatasi masalah adaptif yang rumit. Secara produktif dan kreatif scrum memiliki peluang untuk menaikan nilai produk setinggi mungkin (Scrum, 2019). Pada saat proses kerja magang, scrum dilakukan dengan membagi pekerjaan kedalam beberapa sprint, dengan durasi dua minggu.

Di akhir masa sprint, akan dilakukan sprint review untuk mempresentasikan pekerjaan yang sudah dilakukan dan merencanakan pekerjaan yang akan dilakukan untuk sprint selanjutnya. Setiap hari pada pukul 10.00 akan dilakukan daily scrum meeting untuk melaporkan setiap pekerjaan yang akan dilakukan pada hari itu kepada project manager.

(5)

Proyek yang dikerjakan selama masa magang adalah modul microservice untuk Perhitungan Bunga, pada bagian base_interest. Modul microservice untuk Perhitungan Bunga adalah modul yang tergabung dalam sebuah bundle untuk mengatur sistem perhitungan bunga tabungan dan bunga pinjaman, sehingga dapat dipakai oleh aplikasi client. Bagian base_interest merupakan perhitungan bunga dasar, yang juga berhubungan dengan bagian lain seperti interest_parameter dan account_interest_rate.

Proyek dikerjakan dalam bentuk RESTful web service dan dikerjakan dari sisi back-end, sehingga tidak mempunyai user interface. Modul microservice Perhitungan Bunga dibagi menjadi tiga bagian, yaitu persistence, service dan end- point secara berurutan.

Bagian Persistence berisi model dan DAO(Data Access Object). Model merupakan penghubung antara modul dengan database yang dipakai. Entitas yang terdapat dalam model, akan dihubungkan dari DAO menuju service agar dapat digunakan. Dibuat juga test untuk DAO, agar tidak terjadi bug karena inputan yang tidak sesuai, atau output yang tidak sesuai dengan spesifikasi.

Bagian Service memiliki sub-bagian yang cukup banyak, yaitu annotation, converter, DTO(Data Transfer Object) dan implementasi dari service itu sendiri.

DTO digunakan untuk mengubah tipe data menjadi string, agar dapat diberikan ke API pada bagian end-point, agar dapat ditampilkan. Implementasi berisi komponen untuk menghubungkan antara Persistence dan API melalui DTO.

Converter digunakan untuk mengubah DTO ke bentuk model dan juga sebaliknya.

Bagian dari End-point berisikan API yang akan digunakan pada saat program dijalankan. API yang dibuat terbagi menjadi dua method, yaitu method

(6)

POST yang berisi Get by Base Code, Get by Client ID, Get by ID, Insert, Edit, Update, dan method GET berisi Get All yang berfungsi untuk menampilkan semua data yang ada.

A. Struktur Tabel

Entity yang dikerjakan pada saat kerja magang adalah base_interest. Tabel base_interest digunakan untuk menyimpan data berupa informasi bunga dasar.

Struktur tabel base_interest akan dijabarkan pada tabel berikut.

Tabel 3.3 Detail Tabel base_interest

No. Nama Field Tipe Data Keterangan

1 id bigint ID tabel

2 authoriser varchar2 User otorisator

3 authorize_time timestamp Waktu otorisasi

4 created_by varchar2 Penginput

5 created_time timestamp Tanggal input

6 status varchar2 Status record

7 updated_by varchar2 Editor

8 updated_time timestamp Tanggal edit

9 version number Versi

10 client_id varchar2 ID client

11 effective_date timestamp Tanggal efektif

12 ref_id varchar2 ID referensi

13 base_code varchar2 Kode dasar

14 description bigint Deskripsi

15 rate numeric Decimal(5,2)

Tabel base_interest mempunyai relasi dengan tabel interest_parameter yang dikerjakan oleh peserta magang lain berupa relasi many to one. Satu Base Interest dapat dimiliki lebih dari satu Interest Parameter.

B. Pembuatan Kode

Modul microservice Perhitungan Bunga dikembangkan menggunakan spesifikasi berikut untuk membangun modul dalam bentuk RESTful web service.

(7)

1. Bahasa pemrograman Java dengan aplikasi Eclipse.

2. PostgreSQL sebagai sistem basis data.

3. Framework Hibernate 5 untuk menghubungkan antara model object- oriented dan relational database.

4. Apache Maven versi 3.7.0 sebagai tempat penyimpanan dependencies, agar modul dapat di-build secara otomatis.

5. Hibernate Validator versi 5.0.3 untuk logika validasi.

6. Junit versi 4.11 sebagai media unit testing framework untuk Java.

7. Apache Karaf versi 4.0.10 sebagai runtime environment yang digunakan untuk deploy modul pada server.

8. SonarQube sebagai halaman web untuk mengukur coverage dari proyek yang dikerjakan.

9. Redmine sebagai halaman web untuk manajemen proyek.

B.1 Membuat Tabel dan Class

Langkah pertama dalam pembuatan modul microservice adalah dengan membuat tabel dalam database, sesuai dengan struktur tabel yang telah ditentukan.

Setelah membuat tabel, maka dibuat class dengan anotasi @Entity sebagai penanda bahwa class tersebut merupakan entity. @Table diberikan untuk mendeklarasikan nama tabel, dalam kasus ini adalah “base_interest”. Anotasi @Id menandakan bahwa data tersebut bersifat unik. @GeneratedValue menandakan bahwa nilai dari tiap data tersebut tidak dimasukkan secara manual, melainkan otomatis dari sistem. @Column menjelaskan nama dari kolom pada tabel yang dihubungkan dengan class tersebut. Pada class ini dibuat getter untuk

(8)

mendapatkan data dari tabel pada database, dan setter untuk mengisi nilai pada variabel.

B.2 Implementasi pada Lapisan Persistence

Pada lapisan Persistence, ada tiga bagian yang dibuat, yaitu model, berisi class yang sudah dijelaskan pada poin C.1 dan DAO(Data Access Object) yang terdiri dari interface dan juga implementation. DAO dibagi menjadi dua bagian, untuk memisahkan antara akses data ke dalam class, dan juga akses data dari lapisan service.

DAO bagian implementasi, berisikan method-method yang digunakan untuk meminta data dari dalam database melalui class. Terdapat empat method pada implementasi DAO, yaitu Get by Client ID, Get by Base Code, Get Latest Effective Date, dan Check Update Entry. Method Get by Client ID berfungsi untuk mendapatkan data berupa list dataset yang mempunyai Client ID yang sama. Method Get by Base Code serupa dengan method sebelumnya, perbedaan terdapat pada parameter, yaitu bukan Client ID melainkan base code. Method Get Latest Effective Date berfungsi untuk menampilkan data dengan base code yang spesifik, dengan effective date di masa lalu, sampai dengan tanggal saat method digunakan. Method Check Update Entry berfungsi untuk mengecek data dengan base code tertentu yang diperbarui pada tanggal yang spesifik. Pada DAO, setiap method meminta data ke dalam database dalam bentuk query.

B.3 Membuat Data Transfer Object dan Method Konversi

DTO(Data Transfer Object) merupakan tempat untuk menampung data, yang nantinya akan dikonversi ke dalam bentuk string untuk ditampilkan dalam format JSON ataupun sebaliknya. DTO akan menampung data yang sudah

(9)

dimasukkan melalui aplikasi client dan akan dilanjutkan ke dalam database melalui class model. DTO juga menampung data yang disiapkan dari method pada lapisan service untuk dikembalikan ke aplikasi client. Komponen pada DTO sama dengan komponen pada class Model karena semua data pada DTO akan dilanjutkan ke model dengan mengubah tipe data menggunakan method konversi.

Method Konversi, berfungsi untuk mengubah tipe data pada data yang terdapat di DTO. Pengubahan tipe data, dilakukan dengan menetapkan nilai pada tiap variabel dalam DTO ke dalam tiap variabel pada model, dan sebaliknya. DTO dan juga Method konversi dibuat pada lapisan Service.

B.4 Implementasi pada Lapisan Service

Lapisan Service memiliki interface dan implementasi, seperti DAO.

Interface pada service adalah bagian yang dapat diakses dari lapisan endpoint, sedangkan bagian implementasi merupakan class dari lapisan service itu sendiri.

Service berperan mengatur data yang di-input oleh aplikasi client untuk diproses.

Proses akan dilakukan dengan mengambil data dari database atau meng-input data ke dalam database melalui interface DAO.

Terdapat empat method pada class service milik base_interest. Method tersebut adalah Get by Client ID, Update, Edit, dan Get by Base Code. Get by Client ID berfungsi untuk mengambil semua data dengan Client ID tertentu melalui DAO, agar dapat diteruskan dan ditampilkan pada aplikasi client. Get by Base Code berfungsi untuk mengambil semua data dengan base code yang spesifik melalui DAO, dan menampilkannya pada aplikasi client. Update berfungsi untuk memperbarui data dengan menambahkan baris baru ke dalam database. Method Update pada lapisan service memiliki beberapa exception, agar

(10)

data yang diperbarui tetap memenuhi persyaratan. Edit berfungsi untuk memperbarui data tanpa menambahkan baris baru ke dalam database.

B.5 Membuat API

Terdapat tujuh API dalam class API dari base_interest yang terbagi menjadi dua method, yaitu GET dan POST. Pada method GET, hanya terdapat satu API, yaitu Get All, dimana API akan me-request pada service untuk menampilkan semua data yang terdapat dalam tabel. Client tidak perlu memasukkan message body karena method yang dipakai adalah GET.

Pada method POST, client harus memasukkan input berupa message body dalam format JSON. Terdapat enam API yang masuk dalam method POST, yaitu Get by Client ID, Get by Base Code, Get by ID, Insert, Update, dan Edit. Setiap API yang berhasil dijalankan akan menghasilkan output sesuai API dengan status 200 OK. Namun jika ada kesalahan dalam input, maka akan dikembalikan status 400 Bad Request dengan error message yang memberi tahu letak kesalahan dalam input. Setiap API pada POST akan meneruskan input dan meneruskan output melalui interface service.

(11)

B.5.1 API Get All

Gambar 3.2 Flowchart Get All base_interest

API Get All merupakan fitur untuk menampilkan semua data yang terdapat pada database dalam bentuk JSON. Gambar 3.2 merupakan flowchart yang menjelaskan proses pengambilan data dari tabel base_interest, yang ditampilkan berupa data dalam bentuk JSON.

Tabel 3.4 Dokumentasi API Get All base_interest

URL GET /cxf/BaseInterest/

Response Body [{

"createdTime": <timestamp>, "createdBy": <varchar2>, "updatedTime": <timestamp>, "updatedBy": <varchar2>, "authoriser": <varchar2>, "authorizeTime": <timestamp>, "version": <number>,

"status": <varchar2>, "clientId": <varchar2>,

"effectiveDate": <timestamp>, "refId": <varchar2>,

"baseCode": <varchar2>, "description": <varchar2>, "rate": <decimal>,

"id": <bigint>

}]

Response Code 200 OK

(12)

Tabel 3.4 merupakan dokumentasi dari API Get All base_interest dengan method GET. API tersebut akan mengembalikan response code 200 OK jika berhasil dijalankan, dan mengembalikan response body sesuai dengan JSON yang terdapat pada Tabel 3.4.

Gambar 3.3 Screenshot API dan Hasil Get All base_interest

Gambar 3.3 merupakan tampilan dari program postman. Postman berperan sebagai Swagger UI untuk API Get All base_interest. API Get All base_interest tidak menerima parameter apapun melainkan merespon hasil berupa data base_interest dari database.

(13)

B.5.2 API Get by Client ID

Gambar 3.4 Flowchart API Get by Client ID

API Get by Client ID merupakan fitur untuk menampilkan semua data dengan Client ID tertentu yang terdapat pada database dalam bentuk JSON.

Gambar 3.4 merupakan flowchart yang menjelaskan proses pengambilan data dari tabel base_interest, yang ditampilkan berupa data dalam bentuk JSON.

Tabel 3.5 Dokumentasi API Get by Client ID

URL POST /cxf/BaseInterest/client

Parameter Body {

“clientId": <varchar2>

}

Response Body [

{

(14)

Tabel 3.6 Dokumentasi API Get by Client ID (Lanjutan)

"id": <bigint>

} ]

Tabel 3.5 merupakan dokumentasi dari API Get by Client ID dan parameter body yang harus dimasukkan dalam bentuk JSON dengan method POST. API tersebut akan mengembalikan response code 200 OK jika berhasil dijalankan, dan mengembalikan response body sesuai dengan JSON yang terdapat pada Tabel 3.5.

Gambar 3.5 Screenshot API dan Parameter Body Get by Client ID

Gambar 3.5 merupakan tampilan dari program postman untuk API Get by Client ID. Parameter dikirimkan dalam format JSON berisikan Client ID.

(15)

Gambar 3.6 Screenshot Hasil Get by Client ID

Gambar 3.6 merupakan tampilan program postman untuk API yang telah berhasil mengambil data base_interest dari database sesuai dengan Client ID pada parameter body.

B.5.3 API Get by Base Code

Gambar 3.7 Flowchart API Get by Base Code

API Get by Base Code merupakan fitur untuk menampilkan semua data dengan Base Code tertentu yang terdapat pada database dalam bentuk JSON.

(16)

Gambar 3.7 merupakan flowchart yang menjelaskan proses pengambilan data dari tabel base_interest, yang ditampilkan berupa data dalam bentuk JSON.

Tabel 3.7 Dokumentasi API Get by Base Code

URL POST /cxf/BaseInterest/base

Parameter Body {

“baseCode”:<varchar2>

}

Response Body [

{

"id": <bigint>

} ]

Tabel 3.6 merupakan dokumentasi dari API Get by Base Code dan parameter body yang harus dimasukkan dalam bentuk JSON dengan method POST. API tersebut akan mengembalikan response code 200 OK jika berhasil dijalankan, dan mengembalikan response body sesuai dengan JSON yang terdapat pada Tabel 3.6.

Gambar 3.8 Screenshot API dan Response Body Get by Base Code

(17)

Gambar 3.8 merupakan tampilan dari program postman untuk API Get by Base Code yang dimasukkan serta parameter yang dimasukkan dalam format JSON.

Gambar 3.9 Screenshot Hasil Get by Base Code

Gambar 3.9 merupakan tampilan program postman untuk API yang telah berhasil mengambil data base_interest dari database sesuai dengan Base Code pada parameter body.

(18)

B.5.4 API Get by ID

Gambar 3.10 Flowchart API Get by ID

API Get by ID merupakan fitur untuk menampilkan semua data dengan ID tertentu yang terdapat pada database dalam bentuk JSON. Gambar 3.10 merupakan flowchart yang menjelaskan proses pengambilan data dari tabel base_interest, yang ditampilkan berupa data dalam bentuk JSON.

Tabel 3.8 Dokumentasi API Get by ID

URL POST /cxf/BaseInterest/get

Parameter Body {

“id”:<bigint>

}

Response Body [

{

"createdTime": <timestamp>, "createdBy": <varchar2>, "updatedTime": <timestamp>, "updatedBy": <varchar2>, "authoriser": <varchar2>,

(19)

Tabel 3.9 Dokumentasi API Get by ID (Lanjutan)

"authorizeTime": <timestamp>, "version": <number>,

"id": <bigint>

} ]

Tabel 3.7 merupakan dokumentasi dari API Get by ID dan parameter body yang harus dimasukkan dalam bentuk JSON dengan method POST. API tersebut akan mengembalikan response code 200 OK jika berhasil dijalankan, dan mengembalikan response body sesuai dengan JSON yang terdapat pada Tabel 3.7.

Gambar 3.11 Screenshot API, Response Body, dan Hasil Get by ID

(20)

Gambar 3.11 merupakan tampilan dari program postman, dimana postman berperan sebagai Swagger UI untuk API Get by ID, Parameter Body beserta hasil dari pengambilan data base_interest dari database.

B.5.5 API Insert

Gambar 3.12 Flowchart API Insert

API Insert merupakan fitur create yang akan menyimpan data baru pada tabel base_interest. Gambar 3.12 merupakan flowchart yang menjelaskan tahap pemasukan data baru untuk tabel base_interest, dimulai dari penerimaan data berupa JSON hingga tersimpan dalam database. Sebelum data baru tersebut dimasukkan, sistem akan melakukan pengecekan terhadap base code dari data

(21)

baru tersebut, jika belum pernah ada base code serupa, maka data dapat dimasukkan ke dalam database.

Tabel 3.10 Dokumentasi API Insert

URL POST /cxf/BaseInterest/

Parameter Body {

"clientId": <varchar2>,

}

Response Body {

"id": <bigint>

}

Tabel 3.9 merupakan dokumentasi dari API Insert dan parameter body yang harus dimasukkan dalam bentuk JSON dengan method POST. API tersebut akan mengembalikan response code 200 OK jika berhasil dijalankan, dan mengembalikan response body sesuai dengan JSON yang terdapat pada Tabel 3.9.

(22)

Gambar 3.13 Screenshot API dan Response Body Insert

Gambar 3.13 merupakan tampilan dari program postman untuk API Insert.

API Insert menerima masukan parameter yang terdiri dari Client ID, effective date, ref ID, base code, description, dan rate dalam format JSON.

Gambar 3.14 Screenshot Hasil Insert

Gambar 3.14 merupakan tampilan program postman untuk hasil dari data yang dimasukkan melalui parameter body. Data yang dikembalikan terdiri dari data yang sudah dimasukkan, dengan tambahan data created time, created by, updated time, updated by, authorizer, authorize time, version dan status.

(23)

B.5.6 API Update

Gambar 3.15 Flowchart API Update

API Update merupakan fitur yang akan menyimpan pembaruan berupa data baru pada tabel base_interest. Gambar 3.15 merupakan flowchart yang menjelaskan tahap pembaruan data untuk tabel base_interest, dimulai dari penerimaan data berupa JSON hingga tersimpan dalam database. Sebelum data

(24)

baru tersebut dimasukkan, sistem akan melakukan pengecekan terhadap base code dari data baru tersebut, jika belum pernah ada base code serupa, maka data tidak dapat diperbarui ke dalam database. Selanjutnya dilakukan pengecekan terhadap effective date, apakah valid atau tidak. Jika berhasil, maka sistem akan memasukkan pembaruan data berupa data baru kedalam database, dan menampilkan hasil dari pembaruan tersebut dalam response body.

Tabel 3.11 Dokumentasi API Update

URL POST /cxf/BaseInterest/update

Parameter Body {

“clientId”:<varchar2>,

“effectiveDate”:<timestamp>, “refId”:<varchar2>,

“baseCode”:<varchar2>, “description”:<varchar2>, “rate”:<decimal>

}

Response Body {

"id": <bigint>

}

Tabel 3.10 merupakan dokumentasi dari API Update dan parameter body yang harus dimasukkan dalam bentuk JSON dengan method POST. API akan

(25)

menerima data baru melalui parameter body dalam bentuk JSON. Jika berhasil, API akan mengembalikan response code 200 OK jika berhasil dijalankan, dan mengembalikan response body sesuai dengan JSON yang terdapat pada Tabel 3.10.

Gambar 3.16 Screenshot API dan Response Body Update

Gambar 3.16 merupakan tampilan dari program postman untuk API Update yang dimasukkan serta parameter yang dimasukkan dalam format JSON.

Gambar 3.17 Screenshot Hasil Update

Gambar 3.17 merupakan tampilan program postman untuk hasil dari data yang dimasukkan melalui parameter body, yang tersimpan dalam bentuk data baru dengan ID yang baru di dalam database.

(26)

B.5.7 API Edit

Gambar 3.18 Flowchart API Edit

API Edit merupakan fitur yang akan menyimpan pembaruan dengan mengubah data yang sudah ada pada tabel base_interest. Gambar 3.18 merupakan flowchart yang menjelaskan tahap pembaruan data untuk tabel base_interest,

(27)

dimulai dari penerimaan data berupa JSON hingga tersimpan dalam database.

Sebelum data tersebut diperbarui, sistem akan melakukan pengecekan terhadap ID dari data tersebut, jika tidak ada ID serupa, maka data tidak dapat diperbarui ke dalam database. Selanjutnya dilakukan pengecekan terhadap kesamaan base code, karena base code yang telah ditentukan tidak dapat diubah. Dilakukan juga pengecekan terhadap effective date, apakah valid atau tidak. Jika berhasil, maka sistem akan memasukkan pembaruan data berupa kedalam database, dan menampilkan hasil dari pembaruan tersebut dalam response body tanpa membuat data baru.

Tabel 3.12 Dokumentasi API Edit

URL POST /cxf/BaseInterest/edit

Parameter Body {

“clientId”:<varchar2>,

“effectiveDate”:<timestamp>, “refId”:<varchar2>,

“baseCode”:<varchar2>, “description”:<varchar2>, “rate”:<decimal>,

“id”:<bigint>

}

Response Body {

"id": <bigint>

}

(28)

Tabel 3.9 merupakan dokumentasi dari API Edit dan parameter body yang harus dimasukkan dalam bentuk JSON dengan method POST. API akan menerima data baru melalui parameter body dalam bentuk JSON. Jika berhasil, API akan mengembalikan response code 200 OK jika berhasil dijalankan, dan mengembalikan response body sesuai dengan JSON yang terdapat pada Tabel 3.8.

Gambar 3. 19 Screenshot API dan Response Body Edit

Gambar 3.19 merupakan tampilan dari program postman untuk API Edit yang dimasukkan serta parameter yang dimasukkan dalam format JSON.

Gambar 3. 20 Screenshot Hasil Edit

Gambar 3.20 merupakan tampilan program postman untuk hasil dari data yang dimasukkan melalui parameter body. Data yang berhasil diperbarui, tidak

(29)

tersimpan dalam bentuk data baru, namun mengubah data yang dipakai untuk pembaruan.

B.6 Pembuatan Unit Test untuk Setiap Method

Setiap method yang dibuat pada lapisan persistence dan service akan diuji fungsionalitasnya dengan unit test menggunakan framework Junit. Unit test yang dibuat berdasarkan data sesuai dengan model yang dibuat pada lapisan persistence.

Unit test yang dibuat pada lapisan persistence ditujukan pada output yang dihasilkan, apakah sesuai pada saat output di pindahkan ke method pada DAO dengan satu set data valid yang telah disiapkan pada unit test.

Unit test yang dibuat pada lapisan service lebih ditujukan kepada fungsionalitas method. Tes dilakukan dengan cara memberikan data yang valid untuk menguji jika proses tidak akan memberikan exception pada input yang diberikan. Diberikan juga tes untuk menguji logika validasi, dengan memberikan data yang tidak valid, untuk menguji constraint yang berbeda-beda.

C. Dokumentasi

Dokumentasi dibuat agar orang selain developer yang terlibat dalam pengerjaan seluruh rangkaian modul microservice dapat mengerti maksud dari setiap kode yang ada. Dokumentasi yang diberikan, dapat berupa penjelasan pada awal kode, setelah nama class. Dokumentasi juga dapat dituliskan pada setiap method dalam interface dan class. Dokumentasi berisikan maksud dari suatu method atau class dibuat, juga parameter yang dibutuhkan untuk menjalankan suatu method dan data apa yang dikembalikan setelah method dijalankan. Nama developer juga dapat dituliskan untuk menginformasikan siapa yang menuliskan

(30)

kode tersebut. Dokumentasi dilakukan menggunakan format standar dokumentasi yang dihasilkan seara otomatis melalui Javadoc saat membuat comment di atas sebuah method.

3.3.2 Masalah yang Ditemukan

Beberapa kendala yang ditemukan saat melakukan kerja magang di PT Anabatic Tbk. adalah sebagai berikut.

1. Framework dan beberapa fitur yang digunakan dalam proyek, tidak pernah digunakan sebelumnya, sehingga membutuhkan waktu untuk mempelajari dan membiasakan diri.

2. Tutorial dan dokumentasi tentang framework dan beberapa fitur tersebut sedikit, yang memperlambat pengerjaan proyek.

3. Atribut dengan tipe data date yang seharusnya ditampilkan dengan format

“yyyy-mm-dd” selalu muncul dengan format “MM dd hh:mm:ss zzz yyyy” ataupun muncul berupa angka-angka acak.

4. Karena perbedaan operating system, maka terjadi perbedaan hasil saat compile, yang menyebabkan push ke Git tidak teratur dan terkesan lama.

3.3.3 Solusi Atas Masalah yang Ditemukan

Berdasarkan kendala yang ditemukan pada Subbab 3.3.2, berikut solusi yang dilakukan untuk mengatasi kendala tersebut.

1. Melakukan pelatihan dengan membuat proyek individu menggunakan framework dan fitur terkait agar terbiasa, dan bisa mengerjakan pengembangan modul dengan efisien.

2. Melakukan pembelajaran dengan mencari sumber secara online, dan bertukar referensi dengan pembimbing dan developer lainnya.

(31)

3. Membuat method untuk konversi tanggal, dengan menyimpan tanggal dalam string dengan format “yyyy-mm-dd”. DTO akan menyimpan format tanggal dalam bentuk string, sedangkan model akan menyimpan tanggal dalam tipe data Date.

4. Tetap mengerjakan task yang lain, walaupun tidak dapat melakukan test, pada satu waktu tertentu, push akan dilakukan, untuk melihat apakah terjadi error pada operating system lainnya. Jika ditemukan error, maka akan langsung diperbaiki.