See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/328487390

Analisis Model Arsitektur Microservice Pada Sistem Informasi DPLK

Article · October 2018

CITATION READS

1 1,130

2 authors:

Ghifari Munawar Ade Hodijah

Politeknik Negeri Bandung Politeknik Negeri Bandung
8 PUBLICATIONS   1 CITATION    7 PUBLICATIONS   4 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Penelitian Pemula 2016 View project

Penelitian Pemula 2015 View project

All content following this page was uploaded by Ghifari Munawar on 24 October 2018.

The user has requested enhancement of the downloaded file.

 Publikasi Jurnal & Penelitian Teknik Informatika e-ISSN : 2541-2019
Volume 3 Nomor 1, Oktober 2018 p-ISSN : 2541-044X

Analisis Model Arsitektur Microservice

Pada Sistem Informasi DPLK
Ghifari Munawar Ade Hodijah
Jurusan Teknik Komputer dan Informatika Jurusan Teknik Komputer dan Informatika
Politeknik Negeri Bandung Politeknik Negeri Bandung
Bandung Bandung
ghifari.munawar@polban.ac.id adehodijah@jtk.polban.ac.id

Abstract— Penelitian didasari oleh keberhasilan proses migrasi dari sistem monolitik ke
dalam arsitektur microservice pada beberapa penelitian sebelumnya melalui metode
identifikasi kandidat microservice. Pada penelitian ini, peneliti melakukan identifikasi
microservice pada sistem informasi Dana Pensiun Lembaga Keuangan (DPLK) melalui 6
(enam) tahapan migrasi yang dimulai dari analisa setiap subsistem monolitik terhadap fungsi
bisnis dan tabel database. Sistem DPLK dikembangkan dengan arsitektur monolitik dan
memiliki beberapa modul sistem, diantaranya sistem pendaftaran nasabah, sistem pengelolaan
investasi, sistem pengelolaan bisnis, sistem pelaporan, dlsb. Banyaknya tanggung jawab yang
perlu dikelola dalam sistem DPLK menyebabkan sistem akan sulit untuk beradaptasi terhadap
perubahan kebutuhan. Kompleksitas inilah yang akan dipecah dalam beberapa service melalui
pendekatan microservices. Sehingga diharapkan dengan mengembangkan model arsitektur
microservices ini, sistem informasi DPLK dapat lebih adaptif (adaptability) terhadap
perubahan kebutuhan (requirement changes) sistem untuk kedepannya.

Keywords—microservice; requirement changes; adaptability

pengelolaan sistem kedepannya menjadi lebih adaptif

I. PENDAHULUAN
Sistem informasi enterprise pada umumnya
dibangun dengan pendekatan monolitik, dimana
aplikasi terbungkus dalam satu package besar, dan
ketika terjadi perubahan (requirement changes) pada
salah satu bagian kode program, akan berpengaruh
besar terhadap kode program lainnya. Saat ini
pendekatan monolitik telah bergeser menjadi
pendekatan terdistribusi, dimana aplikasi dibagi
menjadi bagian-bagian kecil yang berfungsi spesifik
(high cohesion) dan tidak bergantung pada komponen
program lainnya (loose coupling), dengan
dikembangkannya service melalui antarmuka API
(application programming interface) [1]. Salah satu
tantangan yang muncul pada arsitektur monolitik
adalah kemampuan adaptasi terhadap perubahan
kebutuhan sistem (requirement changes) terutama
dalam pengelolaan kompleksitas kode, dan
maintainability-nya, dimana hal ini akan
menyebabkan bottleneck pada proses
pendistribusiannya karena tingkat dependensi yang
tinggi (tightly coupling) [2]. Oleh karenanya perlu
mempertimbangkan alternatif arsitektur lain agar
terhadap perubahan (requirement changes).
Arsitektur microservice merupakan alternatif
arsitektur yang lebih terukur dan lebih fleksible. Pada
arsitektur microservice, sistem informasi dirancang
untuk terdistribusi dan menyediakan layanan secara
lebih fokus dan spesifik. Permasalahan besar akan
dipecah menjadi beberapa solusi kecil yang disusun
dalam satu service, dimana setiap service memiliki
tanggung jawabnya sendiri [3]. Dengan pendekatan ini,
suatu sistem informasi akan terdiri dari beberapa
service yang dapat dikelola dan didistribusikan secara
independent, hal ini akan lebih memudahkan sistem
untuk beradaptasi terhadap perubahan kebutuhan.
Berdasarkan beberapa penelitian sebelumnya, (1)
Microservice sebagai sebuah arsitektur sistem yang
terdistribusi telah menunjukkan peningkatan kualitas
pada aspek resiliensi dengan studi kasus sistem
manajemen asosiasi/keanggotaan, evaluasi model
dilakukan melalui pembuatan proof of concept dari
modifikasi arsitektur software yang terdistribusi
berbasis microservice dan Docker-container [4].
Kualitas resiliensi ini dibuktikan ketika beberapa node

232
 Publikasi Jurnal & Penelitian Teknik Informatika e-ISSN : 2541-2019
Volume 3 Nomor 1, Oktober 2018 p-ISSN : 2541-044X

service mengalami gangguan, sistem dapat tetap Koreksi Iuran

berjalan sebagaimana mestinya. Proses migrasi dari Penempatan Investasi
sistem berbasis monolitik menjadi sistem berbasis Perpanjangan Penempatan Investasi
Pencairan Investasi
microservice dilakukan melalui 15 langkah Open Business Date
(Microservices Migration Patterns). (2) Penelitian [6] Investasi
Close Business Date
telah mengembangkan metode migrasi dari arsitektur EOD
monolitik ke arsitektur microservice melalui 6 (enam) EOM
tahapan, dimana studi kasusnya adalah sistem EOY
perbankan yang mengelola 3,5 juta data nasabah dan Pengelolaan Pengelolaan Bisnis
hampir 2 juta transaksi perharinya. Identifikasi  Pengelolaan Produk
microservice telah berhasil dilakukan dengan  Pengelolaan Instrumen Keuangan
 Pengelolaan Paket Investasi
menganalisa keterhubungan pada setiap subsistem
 Pengelolaan Kode Transaksi
(SS), fungsi bisnis (F,B), dan tabel database (D).  Pengelolaan Biaya Administrasi
Penelitian ini mencoba mengadopsi metode  Pengelolaan Premi Asuransi
 Pengelolaan Kalendar Hari Libur
migrasi yang diusulkan [6] untuk menganalisa model
Pengelolaan Mitra
arsitektur microservice pada sistem informasi dana  Pengelolaan Regulator
pensiun lembaga keuangan (DPLK) dengan tujuan  Pengelolaan Institusi Bank
agar dapat meningkatkan kemampuan adaptasi sistem  Pengelolaan Institusi DPLK
informasinya. Proses bisnis DPLK mengacu kepada  Pengelolaan counterpart
aturan pemerintah, yakni PP Nomor 77 tahun 1992  Pengelolaan Institusi Agen
tentang Dana Pensiun Lembaga Keuangan. Sistem Penjualan
informasi DPLK dikembangkan dengan arsitektur  Pengelolaan Cabang Agen
Penjualan
monolitik dan memiliki beberapa modul sistem,  Pengelolaan Agen Penjual
diantaranya sistem pendaftaran nasabah, sistem  Pengelolaan Target Agen Penjual
pengelolaan investasi, sistem pengelolaan bisnis dan Pengelolaan User
sistem pelaporan. Sistem ini mengelola data sensitif Pengelolaan API
terkait data keuangan nasabah, aturan pencairan dana,  Pengelolaan API
historis transaksi, dll. Banyaknya tanggung jawab  Pengelolaan Client
yang perlu dikelola dalam sistem menyebabkan  Pengelolaan Mapping API
sistem sulit untuk beradaptasi terhadap penyesuaian Pengelolaan Hak Akses
 Pengelolaan Group Akses
kebutuhan. Kompleksitas inilah yang akan dipecah  Pengelolaan Group Menu
dalam beberapa service dengan pendekatan  Pengelolaan User Akses
microservices. Sehingga diharapkan dengan model Pengelolaan Framework
ini, sistem informasi DPLK dapat lebih mudah  Pengelolaan Modul
beradaptasi terhadap perubahan kebutuhan untuk  Pengelolaan Menu
kedepannya.  Pengelolaan Dependecies
 Pengelolaan Jobs
Alur proses pada tiap-tiap modul sistem  Pengelolaan Codes
digambarkan dengan model flowchart. Alur ini  Pengelolaan System Options
menggambarkan aliran proses yang terjadi pada suatu  Pengelolaan System Parameters
kegiatan. Secara umum modul pada sistem DPLK Laporan Laporan Kepesertaan
terbagi kedalam 5 (lima) subsistem, seperti terlihat  Laporan Peserta DPLK
 Laporan Kandidat Peserta Pensiun
pada Tabel I.
 Laporan Peserta Pensiun
 Laporan Peserta Pindahan dari
TABEL I. DAFTAR SUBSISTEM DAN MODUL SISTEM DPLK DPLK Lain
Laporan Transaksi
Subsistem Modul  Laporan Seluruh Transaksi
Kepesertaan Permohonan Pendaftaran Perusahaan  Laporan Iuran
Pendaftaran Peserta  Laporan Penarikan
Pendaftaran Peserta Pindahan  Laporan Pencairan
Upload Peserta Kolektif Laporan Dana Kelolaan
Penambahan Kode Peserta Baru  Laporan Penempatan
Perubahan Data Peserta  Laporan Jatuh Tempo
Setor Tunai Iuran  Laporan Pencairan
Upload Iuran
Permohonan Pencairan II. METODE PENELITIAN
Transaksi Penarikan Iuran
Pengalihan Ke DPLK Lain Agar penelitian dapat dilaksanakan dengan baik,
Cetak Buku Tabungan maka disusunlah tahapan-tahapan penelitian sebagai
Cetak Rekening Koran berikut :
233
 Publikasi Jurnal & Penelitian Teknik Informatika e-ISSN : 2541-2019
Volume 3 Nomor 1, Oktober 2018 p-ISSN : 2541-044X

Publikasi / Melakukan Jurnal Ilmiah yang

9 Seminar publikasi / sudah
Ilmiah seminar ilmiah dipublikasikan.

III. TAHAPAN MIGRASI

Terdapat 6 (enam) tahapan migrasi untuk

melakukan identifikasi microservice dari sistem
monolitik. Berikut tahapannya [6]:
GAMBAR I. METODOLOGI PENELITIAN
a) Petakan tabel database tb1 ϵ D kedalam
TABEL II. TAHAPAN PENELITIAN subsistem ss1 ϵ S. Setiap subsistem mewakili
sebuah area bisnis (ai) dari organisasi O.
Fas
Jenis Kegiatan Keterangan Target Luaran
e

Tahap Persiapan
Studi Memahami kondisi
permasalahan permasalahan yang
Studi mengenai sistem timbul dari sistem
1
Permasalahan informasi DPLK informasi DPLK
yang saat ini yang saat ini
berjalan berjalan.
Kajian pustaka
dari berbagai
sumber terkait Memahami lingkup GAMBAR II. PEMETAAN TABEL DATABASE PADA
proses analisis, teoritis dan praktis SUBSISTEM [6]
Kajian
2 perancangan untuk solusi
Pustaka
arsitektur sistem, permasalahan dalam
microservice, penelitian. b) Buat grafik ketergantungan (V, E) dimana
teknologi cloud, node (vertices) menggambarkan facades (fci ϵ
dll
Melakukan F), fungsi bisnis (bfi ϵ B), atau tabel database
pengumpulan data
Dokumen Teknis, (tbi ϵ D), dan garis (edges) menggambarkan:
pada objek (i) panggilan dari facades ke fungsi bisnis; (ii)
Petunjuk
Pengumpulan penelitian, berupa
3 Penggunaan Sistem, panggilan diantara fungsi bisnis; dan (iii)
Data dokumentasi
Source Code
teknis, petunjuk
Aplikasi Existing. akses dari fungsi bisnis ke tabel database.
penggunaan
sistem, dll.
Satu subsistem bisa memiliki lebih dari satu
facades dan satu facades bisa memanggil
Tahap Pelaksanaan
lebih dari satu fungsi bisnis dan satu fungsi
Menganalisa bisnis bisa memanggil lebih dari satu fungsi
model arsitektur
Analisa monolitik yang Arsitektur Monolitik bisnis lainnya atau memanggil lebih dari satu
4 Arsitektur sesuai dengan pada Sistem tabel database. Dimana facades merupakan
Sistem Existing sistem informasi Existing. entry point dari sistem yang memanggil
DPLK yang saat
ini berjalan. fungsi bisnis dan fungsi bisnis merupakan
Perancangan
Merancang methods yang mewakili implementasi sebuah
arsitektur Model Arsitektur business rules dan bergantung pada tabel
Model
5 microservice Microservice yang
Arsitektur
berdasarkan hasil dikembangkan database.
Microservice
analisis
Menguji model
Pengujian Hasil Pengujian
6 arsitektur yang
Model Model
dikembangkan
Tahap Pelaporan
Menyusun jurnal
ilmiah sesuai
Penyusunan
7 dengan hasil Draft Jurnal Ilmiah
Jurnal Ilmiah
temuan pada
penelitian.
Laporan Kemajuan
Membuat laporan
Penelitian, Laporan
penelitian, baik
Penyusunan Akhir Penelitian, dan
laporan progress,
8 Laporan Laporan
dan laporan akhir
Penelitian Pertanggung
serta pertanggung
Jawaban Dana
jawaban dana. GAMBAR III. GRAFIK KETERGANTUNGAN ANTAR
Penelitian. VERTICES (V) [6]

234
 Publikasi Jurnal & Penelitian Teknik Informatika e-ISSN : 2541-2019
Volume 3 Nomor 1, Oktober 2018 p-ISSN : 2541-044X

c) Identifikasi pasangan (fci, tbj) dimana fci ϵ F Gateway API merupakan sebuah intermediate
dan tbj ϵ D, dan terdapat jalur (path) dari fci layer diantara client dan server, yakni sebuah
ke tbj pada grafik ketergantungan. komponen baru yang menangani panggilan
(request) dari client dan mensikronisasi
d) Pilih pasangan (fci, tbj) yang diidentifikasi panggilan ke microservice M dan fc1' (fc1
pada langkah sebelumnya untuk setiap versi baru tanpa source code, karena source
subsistem ssi pada langkah ke-1, dimana tbj ϵ code tersebut telah diekstrak dan
ssi. diimplementasikan ke microservice M).
e) Identifikasi kandidat yang akan diubah Terdapat tiga kasus yang harus
menjadi microservice. Untuk setiap pasangan dipertimbangkan ketika sinkronisasi:
(fci, tbj), sebuah kandidat microservice (M) i) Ketika input dari fc1’ adalah output dari
didefinisikan sebagai berikut: M atau input dari M adalah output dari
 Name: nama service sesuai pola fc1’.
[subsystemname].[processname].
ii) Ketika input dari M dan fc1’ sama
 Purpose: satu kalimat yang dengan input API gateway dan urutan
menggambarkan tujuan bisnis utama intansiasi tidak diperhatikan.
dari operasi, yang secara langsung
terkait dengan domain entitas database iii) Ketika harus membagi fc1’ menjadi dua
yang diakses. fungsi fc1’ dan fc1” dan microservice M
 Input/Output: operasi pada harus dipanggil setelah fc1’ dan sebelum
microservice memerlukan data sebagai fc1”.
input untuk menghasilkan output.
Jika sinkronisasi panggilan dapat dilakukan
 Features: business rules untuk seperti kasus (i) dan (ii), maka identifikasi
penggunaan microservice, yang microservice M sebagai “strong candidate”,
digambarkan sebagai kata kerja tetapi jika sinkronisasi panggilan hanya bisa
(action), objek (terkait dengan tabel seperti kasus (iii) maka identifikasi
database), dan pelengkap. microservice M sebagai “candidate with
 Data: tabel database yang digunakan additional effort”. Selain itu, jika business
microservice. rule yang diimplementasikan pada
Identifikasi microservice ini diterapkan untuk microservice perlu mempebaharui data di tbi ϵ
hanya satu subsistem dari sistem monolitik ssx dan tbj bukan ϵ ssx dalam lingkup
yang menangani operasi pada setiap tabel transaksi yang sama, maka identifikasi
database. Sedangkan subsistem dengan microservice M sebagai “non candidate”.
memiliki tabel yang muncul pada lebih dari
satu daftar subsistem maka tidak akan
dilakukan identifikasi microservice untuk IV. HASIL IDENTIFIKASI MICROSERVICE
subsistem tersebut. Selanjutnya, setelah setiap Berikut tahapan identifikasi microservice dari
pasangan (fci, tbj) teridentifikasi sebagai sistem informasi DPLK:
kandidat microservice kemudian buat
database sendiri untuk tabel dari subsistem A. Identifikasi Subsistem dan Tabel Database
kandidat microservice dan hilangkan
Langkah #1, terdapat 5 subsistem yang
subsistem kandidat microservice dari sistem S
didefinisikan, yakni Kepesertaan (KP), Transaksi (TR),
(setelah gateway API dibuat pada langkah 6).
Investasi (INV), Pengelolaan (PG), dan Pelaporan
Berikut kriteria subsistem non-kandidat
(RPT), serta 88 tabel database. Pada tahapan ini, tabel
microservice:
pada database dipetakan kepada masing-masing
 Subsistem yang berbagi tabel database subsistemnya, dimana tabel tersebut digunakan oleh
yang sama. subsistem tersebut. Disamping itu, terdapat pula tabel
 Microservice yang mewakili operasi data yang digunakan oleh lebih dari 1 (satu)
yang berada ditengah operasi lain. subsistem. Hasil pemetaan tabel database pada
subsitem secara menyeluruh dapat dilihat pada Tabel
 Operasi yang melibatkan lebih dari satu
III.
subsistem pada sebuah transkasi
(misalnya, transaksi transfer uang dari TABEL III. PEMETAAN SUBSISTEM DAN TABEL DATABASE
subsistem rekening check ke subsistem
rekening tabungan). KP TR INV PG RPT
approvals transaction investme products members
f) Buat gateway API untuk setiap facades approval_hi transaction_ nt instruments member_
story codes investme packet diversions
sebagai migrasi microservice untuk client. nt_extens
cifs transaction_ packet_details transaction_

235
 Publikasi Jurnal & Penelitian Teknik Informatika e-ISSN : 2541-2019
Volume 3 Nomor 1, Oktober 2018 p-ISSN : 2541-044X

member_co fees ion counterpart_ codes TABEL IV. ANALISIS KETERGANTUNGAN VERTICES (V)
des accounts escrows products transaction_
corporates member_co investme transaction_code fees Subsistem Facades Function Func Data
nt_accrua
contacts des s fees (v) tion Base
ls
addresses approvals investme fees investments Calls (e)
additionals approval_hi nt_histori holidays investment_ (e)
documents story es users extensions CorporateController 22 14 8
bank_accou upload investme sessions investment_ KP
nt_details
RuleController 20 12 9
nts upload_det roles managers
streams TR UploadController 12 10 5
pics ails regulators escrows
rules equation_t
transacti
dplks
INV StreamController 13 8 4
ons ProductController 14 9 4
rule_formul rx_ banks
operatio
as histories
nals insurances InstrumentController 16 11 5
accounts operatio bank_counterpa PacketController 15 9 3
option_valu nal_detai rts CountProdController 14 13 6
es ls investment_ HolidayController 19 7 3
banks managers UserController 17 11 4
insurances agent_institutio SessionController 14 7 3
members ns RoleController 14 11 5
member_ac agent_branch RegulatorController 14 8 3
counts agents DplkController 14 8 3
member_di apis
BankCountController 13 9 4
versions clients
AgentInstController 12 7 3
heirs modules
menus
PG AgentBranchController 13 9 4
contacts AgentController 13 9 4
addresses ApiController 13 9 4
bank_accounts ClientController 15 10 4
documents ModuleController 14 9 4
pics MenuController 16 11 5
heirs GoalController 12 8 4
goals AppSettingController 12 8 4
additionals ReportController 20 10 4
notifications CodeController 11 8 4
approval_settin OptionController 13 10 5
gs
SysParamController 14 8 3
reports
TransController 13 7 3
report_template
s
upload_settings
jobs Setelah analisis ketergantungan didapatkan,
codes kemudian dilakukan proses identifikasi kandidat
rule_formulas
options microservice, seperti terlihat pada Tabel IV.
option_values
system_parame
ters TABEL V. KANDIDAT MICROSERVICE PADA SUBSISTEM
translations
dashboard_setti KP TR INV PG
ngs Tables (v) 3 3 3 33
dashboard_role Functions (v) 42 12 13 355
s
Function Calls (e) 26 10 8 226
Database Accesses
Subsistem yang memiliki tabel database dengan 17 5 4 98
(e)
warna abu-abu tidak akan dilakukan analisis pada Kandidat
langkah selanjutnya. Hal ini dikarenakan tabel 2 1 1 22
Microservices
database tersebut muncul pada lebih dari satu daftar
subsistem (tabel database digunakan oleh lebih dari
satu subsistem). Dimana identifikasi microservice C. Identifikasi Pasangan Facades dan Tabel
yang dilakukan oleh [6] memastikan bahwa hanya Database
satu subsistem yang menangani operasi atau transaksi Langkah #3 dan #4, dari kandidat microservice
di setiap tabel database. yang telah terpilih pada langkah #2, selanjutnya
dilakukan dekomposisi fungsi-fungsi bisnis sesuai
B. Identifikasi Facades dan Fungsi Bisnis operasi/transaksi pada setiap tabel database. Sebagai
Langkah #2, dilakukan analisis ketergantungan contoh terlihat pada Gambar IV adalah grafik
fungsi bisnis (B) dan tabel database (D) berdasarkan ketergantungan pada subsistem Kepesertaan (KP)
facades (F) (entry point dari sistem) sesuai hasil antara façades (f), fungsi bisnis (b), dan tabel
analisis ketergantungan subsistem dan tabel database database (d) :
pada langkah #1 dengan mengabaikan tabel database
yang digunakan oleh lebih dari satu subsistem dengan
v-vertices; e-edges, seperti terlihat pada Tabel III.

236
 Publikasi Jurnal & Penelitian Teknik Informatika e-ISSN : 2541-2019
Volume 3 Nomor 1, Oktober 2018 p-ISSN : 2541-044X

ApprovalService approvals
ProcessService processes
FormulaService formulas
SystemParameter system
Service parameters
Transaksi (TR)
Upload
3 UploadService uploads
Controller
Investasi (INV)
Stream
4 StreamService streams
Controller
Pengelolaan (PG)
GAMBAR IV. GRAFIK KETERGANTUNGAN PADA 5 Product ProductService products
SUBSISTEM KEPESERTAAN (KP)
6 Instrument InstrumentService instruments
Keterangan :
Packet PacketService packets
CC CorporateController PR PacketRepository 7
Controller InstrumentService instruments
RC RuleController RR RuleRepository
CS CorporateService FR FormulaRepository Count CounterpartProduct counterpart
PS PacketService C Corporates 8 Prod Service products
RS RuleService P Packets Controller InstrumentService instruments
FS FormulaService R Rules
CR CorporateRepository F Formulas Holiday
9 HolidayService holidays
Controller
Grafik pada gambar IV menunjukan User UserService users
10
ketergantungan antara facades, fungsi bisnis, dan Controller RoleService roles
database pada subsistem kepesertaan (KP). CC Session
memanggil fungsi bisnis yang terdapat pada CS, 11 SessionService sessions
Controller
kemudian CS memanggil fungsi database yang RoleService roles
Role
tersimpan pada CR, dan CR mengakses database ke 12
Controller MenuService menus
tabel C, begitu pula dengan facades yang lain,
sehingga hubungan tersebut akan membentuk grafik Regulator
13 RegulatorService regulators
Controller
ketergantungan. Proses ini dilakukan pula pada
Dplk
subsistem lainnya. 14 DplkService dplks
Controller
Hasil dari proses ini dapat dilihat secara Bank CounterpartService counterparts
15 Count
menyeluruh pada Tabel VI. BankService banks
Controller
AgentService agents
TABEL VI. DEKOMPOSISI FUNGSI BISNIS PADA KANDIDAT
Agent agent
MICROSERVICE
16 AgentBranchService
Controller branches
Business AgentInstitution agent
No Façade (f) Tabel (d) Service institutions
Function (b)
Api
Kepesertaan (KP) 17 ApiService apis
Controller
CorporateService corporates ClientService clients
Client
member 18 ApiPermission api
MemberCodeService Controller
codes Service permissions
ApprovalService approvals MenuService menus
Menu
Corporate 19
ProductService products Controller ModuleService modules
1 Controller
PacketService packets Goal
20 GoalService goals
Controller
InsuranceService insurances App
ApprovalSetting approval
BankService banks 21 Setting
Service settings
Controller
AgentService agents
Report ReportService reports
RuleService rules 22
Rule Controller AgentService agents
2
Controller CorporateService corporates Code
23 CodeService codes
Controller

237
 Publikasi Jurnal & Penelitian Teknik Informatika e-ISSN : 2541-2019
Volume 3 Nomor 1, Oktober 2018 p-ISSN : 2541-044X

Option gulator Service Regulator find(),

24 OptionService options Regulat Object delete()
Controller
SysParam SystemParameter system or (output)
25 DplkServi Pengelo Pengelo DplkForm save(), dplk
Controller Service parameters
ce laan.Dpl laan (input), select(), s
Trans k Service DplkObject find(),
26 TranslationService translations
Controller Dplk (output) delete()
BankCou Pengelo Pengelo Counterpart save(), coun
nterpartS laan.Ba laan Form select(), terpa
Selanjutnya dilakukan pemilahan pada setiap ervice nkCoun Service (input), find(), rts
subsistem yang telah didefinsikan, identifikasikan (f1, terpart Counter Counterpart delete()
t1) facades terhadap tabel, dimana tabel tersebut part Object
(output)
merupakan anggota subsistem (t1 ϵ ss1). ApiServic Pengelo Pengelo ApiForm save(), apis
e laan.Api laan (input), select(),
D. Identifikasi Kandidat Microservice Service ApiObject find(),
Api (output) delete()
Langkah #5, terdapat 21 kandidat microservice ClientSer Pengelo Pengelo ClientForm save(), clien
dan berikut deskripsi kandidat microservice tersebut vice, laan.Cli laan (input), select(), ts,
ApiPermi ent Service ClientObject find(), api_p
yang diperoleh dari hasil dekomposisi fungsi-fungsi ssionServ Client (output) delete() ermi
bisnis pada setiap operasi tabel database di langkah ice ssion
#3 dan langkah #4, seperti terlihat pada Tabel VI. s
MenuServ Pengelo Pengelo MenuForm save(), men
ice, laan.Me laan (input), select(), us,
TABEL VII. DESKRIPSI KANDIDAT MICROSERVICE ModuleSe nu Service MenuObject find(), mod
rvice Menu (output) delete() ules
Facades Deskripsi Kandidat Microservice GoalServi Pengelo Pengelo GoalForm save(), goals
(Fungsi Tujua Input/ Dat ce laan.Go laan (input), select(),
Nama Fitur al Service GoalObject find(),
Bisnis) n Output a Goal (output) delete()
Corporate Kepeser Pengelo CorporateFo save(), corp Approval Pengelo Pengelo ApprovalSet save(), appr
Service taan.Cor laan rm (input), select(), orate SettingSe laan.Ap laan tingForm select(), oval_
porate Service Corporate find(), s rvice provalS Service (input), find(), setti
Corpora Object delete() etting Approv ApprovalSet delete() ngs
te (output) al ting Object
RuleServi Kepeser Pengelo RuleForm save(), rules Setting (output)
ce, taan.Rul laan (input), Rule select(), , ReportSer Pengelo Pengelo ReportForm save(), repo
Corporate e Service Object find(), corp vice laan.Re laan (input), select(), rts
Service Rule (output) delete() orate port Service Report find(),
s Report Object delete()
UploadSe Transak Pengelo UploadForm save(), uplo (output)
rvice si.Uploa laan (input), select(), ads CodeServi Pengelo Pengelo CodeForm save(), code
d Service Upload find(), ce laan.Co laan (input), select(), s
Upload Object delete() de Service Code Object find(),
(output) Code (output) delete()
StreamSe Investas Pengelo StreamForm save(), strea OptionSer Pengelo Pengelo OptionForm save(), optio
rvice i.Stream laan (input), select(), ms vice laan.Opt laan (input), select(), ns
Service Stream find(), ions Service Option find(),
Stream Object delete() Option Object delete()
(output) (output)
Counterp Pengelo Pengelo Counterpart save(), coun Translati Pengelo Pengelo TranslationF save(), trans
artProduc laan.Co laan Form select(), terpa onService laan.Tra laan orm (input), select(), latio
tService unterpa Service (input), find(), rt_pr nslation Service Translation find(), ns
rtProdu Counter Counterpart delete() oduc Translat Object delete()
ct part Object ts ion (output)
Product (output)
HolidaySe Pengelo Pengelo HolidayFor save(), holid
rvice laan.Hol laan m (input), select(), ays
iday Service Holiday find(),
Holiday Object delete()
E. Identifikasi API Gateway
(output) Langkah #6, berikut API gateway untuk setiap
UserServi Pengelo Pengelo UserForm save(), users
ce, laan.Use laan (input), User select(), ,
facades pada langkah #5 sebagai microservice yang
RoleServi r Service Object find(), roles dapat diakses oleh client, seperti terlihat pada Tabel
ce User (output) delete() VII.
SessionSe Pengelo Pengelo SessionForm save(), sessi
rvice laan.Ses laan (input), select(), ons
TABEL VIII. API GATEWAY
sion Service Session find(),
Session Object delete()
(output)
No. Daftar API Operasi HTTP
1 api/corporates GET, POST, PUT, DELETE
RoleServi Pengelo Pengelo RoleForm save(), roles
ce, laan.Rol laan (input), select(), , 2 api/rules GET, POST, PUT, DELETE
MenuServ e Service RoleObject find(), men 3 api/upload-transactions GET, POST, PUT, DELETE
ice Role (output) delete() us 4 api/streams GET, POST, PUT, DELETE
Regulator Pengelo Pengelo RegulatorFo save(), regul GET, POST, PUT, DELETE
5 api/counterpart-products
Service laan.Re laan rm (input), select(), ators
6 api/holidays GET, POST, PUT, DELETE

238
 Publikasi Jurnal & Penelitian Teknik Informatika e-ISSN : 2541-2019
Volume 3 Nomor 1, Oktober 2018 p-ISSN : 2541-044X

7 api/users GET, POST, PUT, DELETE Setelah model diimplementasikan, selanjutnya

8 api/sessions GET, POST, PUT, DELETE dilakukan pengujian microservice melalui 3 (tiga)
9 api/roles GET, POST, PUT, DELETE
model pengujian : (1) individual microservice (unit
10 api/regulators GET, POST, PUT, DELETE
test), (2) component test, dan (3) end-to-end test.
11 api/dplks GET, POST, PUT, DELETE
12 api/bank-counterparts GET, POST, PUT, DELETE
Unit test menguji potongan kecil dan terisolasi dari
13 api/apis GET, POST, PUT, DELETE fungsi (service), sementara component test melakukan
14 api/clients GET, POST, PUT, DELETE pengujian antarmuka eksternal dari layanan individual
15 api/menus GET, POST, PUT, DELETE atau pada tingkat pengujian subsistem dari kelompok
16 api/goals GET, POST, PUT, DELETE service, kemudian end-to-end test dilakukan untuk
17 api/approval-settings GET, POST, PUT, DELETE memastikan seluruh sistem telah bekerja, dimana
18 api/reports GET, POST, PUT, DELETE pada tahap ini semua fungsionalitas bisnis yang
19 api/codes GET, POST, PUT, DELETE dirancang diuji kinerjanya.
20 api/options GET, POST, PUT, DELETE
21 api/translations GET, POST, PUT, DELETE
REFERENCES
[1] Newman, S. (2015). Building Microservices. O’Reilly Media,
Inc.
V. KESIMPULAN DAN SARAN [2] Priyadarshini, S. (2017). Microservices Architecture.
International Research Journal of Computer Science (IRJCS),
Sampai saat ini, penelitian berhasil melakukan Issue 04, Volume 4.
identifikasi 21 microservice dari sistem monolitik [3] Messina, Antonio, dkk. (2016). A Simplified Database Pattern
sistem informasi DPLK menggunakan pendekatan 6 for the Microservice Architecture. The Eight International
(enam) langkah migrasi. Langkah migrasi dilakukan Conference on Advances in Databases, Knowledge, and Data
melalui analisis keterhubungan subsistem monolitik Applications.
terhadap facades (f) (entry points atau user interface [4] Suryotrisongko, Hatma. (2017). Arsitektur Microservice
untuk Resiliensi Sistem Informasi. Jurnal Sisfo Vol. 06 No.
untuk input data), tabel database (d) dan fungsi bisnis 02 hal. 235-250.
(b) atau method dari operasi tabel database tersebut [5] Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2015).
untuk setiap transaksi bisnis. Dapat dikatan bahwa Microservices Migration Patterns
pendekatan ini cukup efektif sebagai tahap awal dari [6] Levcovitz, A., Terra, R., Valente, M.T., (2017). Towards a
proses migrasi sistem monolitik ke microservice, Technique for Extracting Microservices from Monolithic
karena service yang memiliki ketergantungan pada Enterprise Systems.
lebih dari 1 (satu) subsistem tidak akan menjadi [7] Introduction to Spring Framework.
kandidat microservice, hal ini dilakukan untuk http://docs.spring.io/spring-
framework/docs/3.0.x/reference/overview.html. Diakses pada
meminimalisir resiko migrasi sistemnya. Tahapan : 10 Juni 2017.
berikutnya adalah menguji model arsitektur
[8] Fowler, M., Scott, K. (1999). UML Distilled Second Edition:
microservice yang telah dikembangkan. A Brief Guide to the Standard Object Modeling Language,
Addison Wesley Publisher.
Implementasi model arsitektur akan
dikembangkan sesuai dengan teknologi yang [9] Long, Josh. (2013). Spring Framework Live Lessons.
Addison-Wesley Professional.
digunakan pada sistem DPLK, yakni menggunakan
[10] Messina, Antonio, et.al. (2016). A Simplified Database
DBMS PostgreSQL, framework Springboot, Bahasa Pattern for the Microservice Architecture. The Eight
Pemrograman Java, serta Apache Tomcat sebagai International Conference on Advances in Databases,
WebServer. Pola komunikasi diimplementasikan Knowledge, and Data Applications.
menggunakan REST Service dengan format JSON.

239

View publication stats