Ab Initio Graph EBM Advertising Management bagian utama

42

BAB IV IMPLEMENTASI DAN PENGUJIAN

4.1 Implementasi Implementasi aplikasi EBM Advertising Management ini meliputi layanan penawaran yang dijalankan. Aplikasi dapat dijalankan secara Batch yaitu berkala sesuai jadwal atau schedule yang di pasang di crontab yang berjalan dibawah sistem operasi Linux Red Hat atau secara continuous terus menerus dan berjalan sebagai service. Pada contoh imlementasi ini aplikasi dijalankan secara berkala dengan menggunakan crontab. Aplikasi ini merupakan satu kesatuan proses, dimana proses dijalankan dan akan berhenti ketika apa yang di proses sudah selesai. Aplikasi ini dibangun dalam sati Ab Initio Graph dimana didalamnya terdapat berbagai komponen yang saling terkait menggambarkan aliran data dan proses. Berikut ini adalah gambaran satu kesatuan komponen dalam satu Ab Initio Graph.

Gambar 4.1

Ab Initio Graph EBM Advertising Management bagian utama.

43

Pada gambar 4.1 terdapat satu grup yang tidak memiliki alur data, yaitu bagian All Lookups yaitu adalah bagian yang tidak terdapat dalam DFD hanya pengelompokan table-table data source yang digunakan pada aplikasi EBM ini.

Gambar 4.2

Lookups sumber data EBM Advertising Management

Pada gambar 4.1 dapat dijelaskan bahwa terdapat 6 proses utama sebagaimana digambarkan pada Gambar 3.12 DFD (Data Flow Diagram) diagram overview EBM Advertising Management yaitu antara lain: 1. Subscribe Data Ialah bagian yang membaca usage queue dari proses ETL yang mengambil data dari CDR billing usage yang didalamnya adalah log transaksi pelanggan ketika melakukan event. Didalam proses itu juga terdapat validasi SLA yang dilakukan untuk mengeliminasi data-data yang sudah kadaluarsa.

44

Gambar 4.3

Sub Sistem Subscribe Data

Usage queue yang dibuat oleh ETL proses ada di dalam direktori /disk21/data/XLDW/mfs/mfs_16way/Processing/NRT_USG/queue/usage_ftr_q

pada komponen

batch subscribe masukan informasi direktori queue yang dihasilkan oleh usage event beserta record format dari queue tersebut agar data bisa dibaca dan diteruskan ke komponen selanjutnya. Dari gambar 4.2 dapat diketahui bahwa data yang sudah dibaca oleh komponen Batch Subscribe kemudian dilakukan filtering record untuk pengecekan data yang masuk sudah kadaluarsa atau tidak, yaitu dengan membandingkan jam pada sistem dengan informasi jam pada record yang masuk. Jika data tidak memenuhi SLA yang ditentukan maka record-record tersebut akan dibuang ke Trash, jika data yang masuk memenuhi SLA yang telah ditentukan, maka record-record tersebut akan dilanjutkan sebagai input dari komponen selanjutnya.

45

Gambar 4.4

Parameter dan Record Format Batch Subscribe

Record format dari batch subscribe adalah sama dengan record format dari usage queue. Record format dari data usage queue ini dapat dilihat pada Table 1. 2. CLM Campaign Ialah merupakan bagian Advertising Management untuk CLM (Customer

Lifecycle

Management)

perbedaan

dengan

Advertising

Management yang lain adalah, didalam CLM terdapat whitelist atau daftar target nomor-nomor yang akan diberikan penawaran. Biasanya adalah pelanggan-pelanggan yang sudah mendapati pengawalan atau termasuk dalam segmentasi tertentu yang mendapatkan perhatian khusus. Sebagai contoh adalah pelanggan-pelanggan yang masa aktifnya akan habis, maka disiapkan penawaran yang menarik agar tetap melakukan pembelian pulsa untuk memperpanjang masa aktifnya.

46

Gambar 4.5

Sub Sitem CLM Advertising Management

Pada sub sistem ini terdapat dua proses utama yaitu bagian validasi terhadap penawaran yang ada dan satu lagi adalah bagian pengecekan hold out. Proses validasi ada pada komponen Reformat & Filter, validasi yang dilakukan adalah antara lain: a. Pengecekan Blue List, jika record yang masuk ini dilakukan pengecekan subscriber_id terdapat pada daftar Blue List, maka tidak diperbolehkan untuk mendapatkan penawaran apapun. Contoh pelanggan yang menjadi bagian dari Blue List adalah pelanggan VIP, Premium, atau pelanggan yang pernah komplen untuk tidak mau menerima penawaran apapaun. b. Pengecekan White List, jika record yang masuk ini dilakukan pengecekan subscriber_id tidak ditemukan pada daftar list yang sudah ditentukan maka record akan terbuang keluar port reject dari komponen ini. c. Pengecekan lokasi, apabila pengecekan pertama lolos selanjutnya dilakukan pengecekan lokasi. Proses ini terdapat beberapa proses join salah satunya dengan data BTS untuk mengetahui detail lokasi dari informasi CGI yang terdapat pada record usage. Jika BTS yang ada dalam record usage event tersebut ada dalam penawaran yang sudah ditentukan, maka proses selanjutnya adalah mengambil data isi pesan dari SMS penawaran tersebut lalu dilanjutkan ke proses selanjutnya yaitu validasi Hold Out.

47

d. Didalam proses validasi pada komponen ini juga memuat validasivalidasi yang lain seperti pengecekan apakah penawaran itu berdasarkan usage event tertentu (SMS, Voice, GPRS), apakah lokasi yang divalidasi adalah grup beberapa BTS atau untuk lokasi Kota tertentu. Detail validasi dapat dilihat pada daftar lampiran program. Sebelum melanjutkan proses pada validasi Hold Out, dari gambar 4.4 terdapat komponen “Gather” adalah komponen yang merubah tingkah laku dari data yang diproses. Dikarenakan data yang diproses tidaklah sedikit, maka proses untuk validasi dilakukan secara parallel, yaitu memecah data agar dapat dilakukan proses secara bersama-sama pada komponen dan pemrograman yang sama namun berbeda resource (CPU, Memory, Disk). Lalu pada komponen “Gather” ini menggabungkan data yang terpecah-pecah ini menjadi serial satu kesatuan data, sehingga data dapat dilakukan pengecekan secara sekuensial pada proses validasi Hold Out. Proses

pengecekan

hold

out

ini

tidaklah

rumit,

hanya

membadingkan data yang masuk setelah dilakukan validasi sebelumnya dengan data hold out yang menyimpan informasi apakan suatu nomor sudah pernah dilakukan pengiriman SMS penawaran, jika sudah apakah masih dalam masa karantina. Kalau tidak ada didalam data hold out tersebut dan tidak dalam masa karantina maka SMS penawaran akan dilanjutkan kepada proses Publish SMS. Disamping itu juga melakukan proses update ke dalam tabel Hold Out memasukan nomor yang baru saja dikirim kedalam daftar karantina.

48

3. RO Campaign (Retail Outlet)

Gambar 4.6

Sub Sistem RO Advertising Management

Secara fungsional, RO Advertising Management itu tidak jauh berbeda dengan CLM Advertising Management, hanya saja yang membedakan adalah tabel-tabel pendukungnya berbeda serta pada CLM terdapat whitelist yaitu daftar target nomor berdasarkan segmentasi bisnis tertentu, sedangkan pada RO Campaign tidak terdapat whitelist jadi penawaran hanya dikelompokan pada lokasi tertentu, siapapun kecuali yang masuk dalam Blue List ketika berada pada lokasi yang masuk dalam kelompok yang mendapatkan penawaran maka pelanggan itu akan menerima penawaran, yang tentu saja tidak sedang dalam masa karantina didalam Hold Out. RO Advertising Management ini dibuat untuk memberikan penawaran kepada pelanggan yang penawaranya ada relevansi kepada penjualan Retail Outlet, misalnya untuk menawarkan pembelian suatu produk pada Retail Outlet tertentu dengan memberikan bonus kepada pelanggan yang melakukan pembelian produk tersebut di Retail Outlet yang ditunjuk oleh XL. Advertising Management ini lebih ditujukan untuk meningkatkan penjualan (sales) dari produk-produk XL yang berhubungan secara langsung dengan Retail Outlet.

49

4. XL Event Advertising Management

Gambar 4.7

Sub Sistem XL Event Advertising Management

Secara fungsional, XL Event Advertising Management ini tidak berbeda dengan RO Campaign, yang membedakan hanya tabel-tabel pendukungnya saja. XL Event Advertising Management ini dibedakan dengan RO Campaign karena memang kebutuhan secara bisnis berbeda, sehingga akan memudahkan untuk mendapatkan laporan bisnis terkait dengan penawaran tertentu sesuai segment bisnis masing masing. XL Event Advertising Management ini dipersiapkan untuk membantu promosi kegiatan-kegiatan XL diluar untuk menarik perhatian pengunjung.

5. Publish SMS Adalah bagian yang mendistribusikan SMS dari berbagai sumber (CLM, RO, XL Event) dikelompokan menjadi satu kesatuan dengan format yang sama, yang membedakan hanyalah isi didalam record akan dibedakan berdasarkan tipe penawaranya.

Gambar 4.8

Sub Sistem Publish SMS

50

Pada gambar 4.7 terdapat proses reformat yang merubah format dari proses sebelumnya menjadi format yang sesuai dengan queue dari SMS publisher. Lalu ada proses replikasi data yang digunakan untuk menuliskan informasi pengirman SMS tersebut kedalam log file. Dan terdapat juga komponen partition by round robin ini digunakan untuk memecah semua record yang masuk secara serial atau sekuensial agar bisa diproses secara parallel pada SMS Publisher. Setelah data dikirim berupa queue, SMS Publiser akan meneruskan permintaan pengiriman SMS ke FDA.

6. Application Logging Setiap komponen dalam Ab Initio memiliki fitur pengelompokan pesan error dan log. Dengan memberikan parameter error group yang sama pada setiap komponen, maka log akan terkelompokan kedalam satu proses yang tidak terpecah pecah.

Gambar 4.9

Subs Sistem Application Logging

Terdapat dua sumber data yang diproses dalam Application Logging ini, yaitu pesan error dan log informasi. Masing masing diberikan kondisi, jika aplikasi sedang jalan dengan mode debugging, maka log akan ditulis di file, jika tidak akan dibuang ke Trash.

51

4.2 Lingkungan Implementasi Lingkungan implementasi adalah lingkungan pembuatan aplikasi EBM Advertising Management. Lingkungan implementasi ini meliputi lingkungan perangkat lunak dan perangkat keras. Perangkat lunak yang digunakan adalah tools data processing Ab Initio dengan XFR sebagai bahasa pemrograman Ab Initio dibawah komponen komponen yang terbentuk dari bahasa C. Flat file sebagai tabel-tabel pendukung yang nantinya akan di load di memory sebagai lookup untuk mempercepat proses validasi. Untuk perangkat keras yang digunakan memiliki spesifikasi sebagai berikut: Komputer Server

:

Server HP (Hewlett-Packard)

Sistem Operasi

:

Red Hat Linux x86 64bit

Prosesor

:

Six Core AMD Opetron 2.6 Ghz

CPU Core

:

48 Core

Memori

:

192 GB

Hard Disk

:

24 Disk Partition, Setiap partisi berkapasitas sekitar 700 GB, total sekitar 16 TB.

4.3 Implementasi Aplikasi Pada proses pengujian diperlukan file-file lookups pendukung yang tertera pada rancangan LRS (Logical Record Structure) Gambar 3.17, adapun file-file pendukung yang harus disiapkan antara lain: 1. BTS Data Direktori semua lookup ada di $AI_SERIAL_LOOKUP yang otomatis di export ke dalam environment variable oleh sandbox. Sehingga dapat dipanggil dengan mudah. Di file ini didefinisikan semua BTS data sebagai kepustakaan informasi referensi data-data BTS seluruhnya.

52

Gambar 4.10 Pendefinisian data pada btsdata.txt Nama file dari data BTS adalah btsdata.txt, file ini berupa teks file biasa dengan data didalamnya terformat sama seluruh konten didalamnya. Format record-nya sama dengan definisi yang ada pada Table 2 hanya karena berupa teks jadi setiap kolom harus dipisahkan dengan karakter tertentu, dalam hal ini dipisahkan dengan karakter titik koma (;).

2. CLM White List Daftar nomor-nomor calon penerima SMS penawaran didefinisikan pada file CLM_WHITE_LIST.txt. Pendefinisian daftar nomor disini hanya berupa nomor, kode penawaran dan masa penawaran berlangsung.

Gambar 4.11 Pendefinisian data pada CLM White List

3. CLM Campaign Daftar penawaran-penawaran yang disiapkan untuk dikirim ke pelanggan

tertentu

dan

area

tertentu

didefinisikan

pada

file

CLM_CAMPAIGN_V5b.txt. Di file ini hanya memuat kode penawaran dan teks SMS yang akan dikirimkan.

53

Gambar 4.12 Pendefinisian data pada CLM Campaign

4. CLM Hold Out Didalam file CLM_HOLDOUT.txt ini tersimpan data nomornomor yang sudah mendapatkan penawaran serta berapa lama masa karantinanya. Setiap ada nomor yang dikirim SMS penawaran akan menambahkan data pada file ini.

Gambar 4.13 Pendefinisian data pada CLM Hold Out

Dalam pengujian ini nomor testing dimasukan kedalam penawaran yang akan dikirimkan ketika pelanggan sedang berada pada area yang memiliki jaringan 3G dan ditawarkan diskon untuk pembelian paket 3G. Setelah data-data pendukung disiapkan semua, tinggal menjalankan program.

Gambar 4.14 Jadwal eksekusi program di crontab

Program dijalankan setiap 10 menit sekali, pada setiap program jalan akan mengambil usage queue yang sudah tersedia dan memproses validasi serta pengiriman SMS berdasarkan apa yang sudah didefinisikan sebelumnya. Proses

54

dijalankan secara background jadi tidak perlu menggunakan GDE untuk menjalankanya, namun proses tersebut juga memiliki log tacking yang dapat dilihat di GDE hanya sekedar untuk menganalisa suatu proses.

Setelah program dijalankan maka aplikasi akan membentuk log file yang bisa dibaca secara langsung. Log dibentuk setiap aplikasi dijalankan.

Gambar 4.15 Daftar log aplikasi yang berjalan

55

Setelah aplikasi jalan terus menerus, nomor-nomor yang ada didalam daftar penawaran tersebut akan mendapatkan penawaran jika melakukan usage event dilokasi yang sudah ditentukan.

Gambar 4.16 Log SMS yang terkirim

Gambar 4.17 SMS yang diterima di handphone pelanggan

Dari gambar 4.16 dapat diketahui bahwa aplikasi memproses data usage event pada pukul 09:06 pagi dan sms diterima oleh pelanggan setelah 9 menit kemudian, jadi SMS yang diterima dengan penawaran yang masih relevan dengan keadaan pelanggan di area 3G masih lebih bisa diterima pelanggan dari pada penawaran ini dikirimkan kepada pelanggan yang tidak diketahui sedang berada dimana. Akan sangat tidak relevan jika penawaran dilakukan oleh sistem sebelumnya dengan memberikan penawaran paket 3G tetapi jika pelanggan yang menerima sedang berada di tempat yang jauh ke pedalaman dan hanya dapat menerima sinyal 2G (GPRS).

56

4.4 Pengujian Pengujian aplikasi ini menggunakan metode pengujian black box yang terfokus pada persyaratan fungsional aplikasi yang telah di buat. Hal ini dimaksudkan agar apabila ditemukan error pada dapat mudah mencari penyebabnya permasalahan. Black-Box yaitu test case program berdasarkan pada spesifikasi sistem, input dari data testing diharapkan bisa menemukan output yang salah, perencanaan tes dapat dimulai pada awal proses dari aplikasi. Pengetesan Sistem, dilakukan secara bertahap dengan melihat berbagai keberhasilan dan kegagalan apa saja yang dihasilkan oleh sistem. Pengetesan sistem biasanya dilakukan setelah selesai pengetesan program. Pengetesan sistem dilakukan untuk mengecek ulang dan memeriksa kekompakan antar komponen sistem yang dimplementasi agar sesuai dengan apa yang diharapkan. 4.4.1 Rencana Pengujian Rencana pengujian ini meliputi: Tabel 7 Rencana Pengujian Requirement Pengujian sumber data

Butir Uji Menjalankan program dan memastikan sumber data dapat diproses dengan baik Pengujian data Whitelist Memastikan whitelist data dengan format yang benar serta memastikan target nomor dapat menerima penawaran dengan benar Pengujian BTS / Grup Memastikan data BTS dalam format Lokasi yang benar serta validasi BTS yang sedang dalam masa penawaran valid untuk mendapatkan penawaran tersebut Pengujian CLM Campaign Memastikan data CLM Campaign dalam format yang benar serta memvalidasi penawaran yang ada dapat berjalan dengan baik dan benar Pengujian Tipe Penawaran

Memastikan penawaran yang ada sesuai antara tipe penawaran dengan informasi yang masuk dari sumber data

57

Pengujian Hold Out

Memastikan data yang masuk dan akan diberikan penawaran tidak dalam masa hold out sehingga dapat menerima pesan SMS

Pengujian Pengiriman SMS

Memastikan data yang dikirim kepada SMS Publisher dengan format yang benar sehinga SMS dapat terkirim

4.4.2 Kasus Dan Hasil Pengujian Pengujian ini dilakukan dengan menguji validasi terhadap data-data yang akan dimasukkan kedalam sistem. a. Pengujian Sumber Data Pengujian sumber data adalah pengujian untuk memvalidasi sumber data dalam format yang benar dan dapat diproses oleh sistem dengan baik. Sumbersumber data antara lain event trigger, BTS data, CLM Campaign, CLM Whitelist.

Tabel 8 Pengujian Sumber Data

Data Masukan Membaca sumber data

Klik Play Program

Tombol Stop Program

Membaca sumber data

Kasus dan Hasil Pengujian Yang Pengamatan Kesimpulan Diharapkan Sumber data Data dapat [X] Diterima dalam format diproses sesuai [] Ditolak yang benar dengan kebutuhan sistem Data masuk kedalam sistem

Data mengalir dan terproses pada setiap komponen Tombol Stop Program

[X] Diterima [] Ditolak

Program Stop [X] Diterima dan [] Ditolak membatalkan proses Kasus dan hasil pengujian (Data Salah) Sumber data Data tidak dapat [X] Diterima dalam format diproses dan [] Ditolak yang salah program keluar dengan error

58

b. Pengujian Whitelist Tabel 9 Pengujian Whitelist

Data Masukan Membaca Whitelist data

Validasi whitelist

Kasus dan hasil pengujian Yang Pengamatan Kesimpulan Diharapkan Sumber data Data dapat [X] Diterima dalam format diproses sesuai [] Ditolak yang benar dengan kebutuhan sistem Data masuk kedalam sistem, dan dilanjutkan pada proses berikutnya

Data mengalir dan terproses pada komponen berikutnya


Kasus dan hasil pengujian (Data Salah) Membaca Sumber data Data tidak dapat [X] Diterima Whitelist data dalam format diproses dan [] Ditolak yang salah program keluar dengan error Validasi Whitelist

Data yang masuk tidak dalam whitelist

Data tidak dapat diproses karena tidak dalam whitelist dan di reject dan ditulis kedalam log


c. Pengujian BTS Data Tabel 10 Pengujian BTS Data

Data Masukan Membaca BTS data

Kasus dan hasil pengujian Yang Pengamatan Kesimpulan Diharapkan Sumber data Data dapat [X] Diterima dalam format diproses sesuai [] Ditolak yang benar dengan kebutuhan sistem

59

Validasi BTS

Data BTS Data mengalir [X] Diterima termasuk dalam dan terproses [] Ditolak list yang pada komponen mendapatkan berikutnya penawaran, dan dilanjutkan pada proses berikutnya Kasus dan hasil pengujian (Data Salah) Membaca BTS Sumber data Data tidak dapat [X] Diterima data dalam format diproses dan [] Ditolak yang salah program keluar dengan error Validasi BTS

Data yang masuk tidak dalam list yang mendapatkan penawaran

Data tidak dapat diproses karena tidak dalam list dan di reject dan ditulis kedalam log


d. Pengujian CLM Campaign Tabel 11 Pengujian CLM Campaign Kasus dan hasil pengujian Data Masukan Yang Pengamatan Kesimpulan Diharapkan Membaca CLM Sumber data Data dapat [X] Diterima Campaign data dalam format diproses sesuai [] Ditolak yang benar dengan kebutuhan sistem Validasi CLM Campaign

Data masuk Data mengalir [X] Diterima dalam list dan terproses [] Ditolak penawaran, dan pada komponen dilanjutkan pada berikutnya proses berikutnya Kasus dan hasil pengujian (Data Salah) Membaca CLM Sumber data Data tidak dapat [X] Diterima Campaign data dalam format diproses dan [] Ditolak yang salah program keluar dengan error

60

Validasi CLM Campaign

Data yang masuk tidak dalam list penawaran



e. Pengujian Tipe Penawaran Tabel 12 Pengujian Tipe Penawaran Kasus dan hasil pengujian Data Masukan Yang Pengamatan Kesimpulan Diharapkan Validasi Tipe Data yang Data mengalir [X] Diterima Penawaran masuk sesuai dan terproses [] Ditolak dengan tipe pada komponen penawaran yang berikutnya ada, dan dilanjutkan pada proses berikutnya Kasus dan hasil pengujian (Data Salah) Validasi Tipe Data yang Data tidak dapat [X] Diterima Penawaran masuk tidak diproses karena [] Ditolak sesuai dengan tidak dalam tipe tipe penawaran penawaran yang benar dan di reject dan ditulis kedalam log

f. Pengujian Hold Out Tabel 13 Pengujian Hold Out

Data Masukan Membaca Hold Out data

Kasus dan hasil pengujian Yang Pengamatan Kesimpulan Diharapkan Sumber data Data dapat [X] Diterima dalam format diproses sesuai [] Ditolak yang benar dengan kebutuhan sistem

61

Validasi Hold Out

Data masuk Data mengalir [X] Diterima dalam tidak dan terproses [] Ditolak sedang dalam pada komponen masa hold out, berikutnya dan dilanjutkan pada proses berikutnya Penulisan Hold Menambahkan List nomor yang [X] Diterima Out data list nomor ditambahkan [] Ditolak yang baru saja masuk ke file mendapatkan dan dilanjutkan penawaran agar pada proses tidak dikirim berikutnya pesan penawaran berikutnya Kasus dan hasil pengujian (Data Salah) Membaca Hold Sumber data Data tidak dapat [X] Diterima Out data dalam format diproses dan [] Ditolak yang salah program keluar dengan error Validasi Hold Out

Data yang masuk sedang dalam masa hold out.



g. Pengujian Pengiriman SMS Tabel 14 Pengujian Pengiriman SMS

Data Masukan Menulis SMS data

Kasus dan hasil pengujian Yang Pengamatan Diharapkan SMS data dalam Data dapat format yang diproses sesuai benar dengan kebutuhan sistem, dan dilanjutkan untuk dikirim SMS

Kesimpulan [X] Diterima [] Ditolak

62

Kasus dan hasil pengujian (Data Salah) Menulis SMS SMS data dalam Data tidak dapat [X] Diterima data format yang diproses dan [] Ditolak salah program keluar dengan error

4.4.3 Kesimpulan Hasil Pengujian Berdasarkan hasil dari pengujian kasus uji coba di atas maka dapat di tarik kesimpulan bahwa Perangkat Lunak secara garis besar dapat mengeluarkan hasil sesuai dengan yang diharapkan.

Ab Initio Graph EBM Advertising Management bagian utama

Recommend Documents