Friday, August 26, 2011

Migrasi PowerBuilder Application Server ke Enterprise Application Server

Wihartoyo     Friday, August 26, 2011    



Latar Belakang

PowerBuilder Application Server adalah feature yang disediakan oleh Sybase PowerBuilder untuk mengembangkan aplikasi  n-tier.  Dengan menggunakan fitur ini, seorang developer bisa mengembangkan server application dan client application dengan hanya menggunakan PowerBuilder.  Lebih jauh lagi, server yang dikembangkan dengan menggunakan fitur ini mempunyai reliabilitas yang cukup baik. Namun, ada masalah pada skalabilitasnya dimana selain bergantung kepada kapasitas windows operating systemnya juga bergantung pada kemampuan powerbuilder application server yang tidak bisa menghandle lebih dari 255.
Permasalahan berikutnya yang tidak kalah pentingnya adalah kenyataan bahwa fitur PowerBuilder  application server sudah tidak bisa lagi ditemui pada PowerBuilder versi terakhir.  PowerBuilder versi 7.0.3 adalah versi terakhir yang masih membawa fitur powerbuilder application server.  Sementara, PowerBuilder 7.0.3 adalah versi yang dioptimized untuk windows 9x . Windows XP masih bisa digunakan namun potensi kejadian error lebih banyak bila dibandingkan dengan Windows 9x.
Saat ini, sistem operasi windows yang umum dipakai adalah windows 7.  Sistem operasi ini, bila dilihat dari tampilannya akan membuat orang berfikir bahwa Microsoft telah membuat suatu lompatan lagi seperti  yang pernah dia lakukan dari Windows 3.1.1 ke Windows 9.5.  Apalagi bila mau memperhatikan perkembangan sampai munculnya windows 7 yang didului dengan Windows Vista yang kemudian dikenal sebagai produk gagal.  Artinya Windows 7 seakan dibuat untuk memperbaiki kegagalan windows vista.  Artinya lagi, Windows 7 berbeda dengan Windows Vista dan sangat berbeda dengan Windows XP apalagi windows 9x.
Dalam hal lain, memang Windows Emulator atau disingkat sebagai wine bisa menjalankan beberapa aplikasi windows dengan baik pada environment, apalagi Microsoft dengan Windows nya pada environment windows; tentunya Microsoft  akan tetap mempertahankan kompatibilitasnya terhadap aplikasi-aplikasi windows versi sebelum windows 7.  Namun dalam satu kesempatan pernah ketika membuka library yang berasal dari direktori yang berbeda dengan menggunakan PowerBuilder 7.0.3 pada Windows 7, yang muncul pada box library list hanya file-file library dari direktory terakhir. List File-file yang telah terbuka  yang berasal dari direktory lain sebelumnya hilang.  Suatu behaviour menyimpang yang dihasilkan oleh suatu fungsi yang sama.  Dalam hal ini, yang pasti adalah bahwa PowerBuilder menggunakan Windows API yang sama baik untuk windows 7 maupun XP.  Namun pada Window 7 ternyata memberikan respon yang berbeda.  Bagi saya, satu contoh kegagalan sudah sangat mencukupi  untuk mencurigai bahwa masih banyak kegagalan yang mungkin timbul.
Kegagalan-kegagalan yang mungkin muncul adalah kegagalan service di sisi server atau kegagalan operasional di sisi client.  Kegagalan-kegagalan ini akan muncul dari response yang mungkin berbeda pada Windows 7 dibanding pada Windows XP / 9x.
Dari paparan di atas sangat bisa dimengerti bahwa pencarian alternatif powerbuilder application server menjadi sangat mandatory.  Pada tulisan kali ini saya akan mencoba untuk mengambil alternatif dengan menggunakan Sybase EAServer.

Persiapan Migrasi
Dalam migrasi ini saya akan menggunakan PowerBuilder 10.5.2 dan Sybase EAServer 6.0.2 karena license produk yang ada adalah PowerBuilder 10.5 yang telah di patch menjadi 10.5.2.  Sedangkan EAServer 6.0.2 dipilih karena supportnya untuk PowerBuilder 10.5.2. Sebenarnya PowerBuilder 10.5.2 pun belum dioptimized  ke Windows 7, namun sampai saat ini saya belum menemukan perbedaan behaviour untuk PowerBuilder 10.5.2 di Windows 7 maupun di Windows XP.
EAServer dijalankan di atas Linux 2.6.  Hal ini dilakukan untuk mendapatkan value added dari migrasi aplikasi.

Proses Migrasi
Kenali  Object Yang akan Kita Migrasi
PowerBuilder adalah IDE yang telah mendukung OOP, dengan memperhatikan desain utama dari aplikasi yang akan kita migrasi maka kita bisa menentukan strategi migrasi dengan lebih baik.

Menghilangkan semua Visual Object.
Semua visual object yang umum digunakan pada PowerBuilder Application Server harus dihilangkan dan semua method yang mempergunakan visual object harus segera disesuaikan agar tidak lagi menggunakan visual object dimaksu.  Visual object tidak disupport oleh EAServer.

Hindari Penggunaan Global Variable
Global Variable dihilangkan atau dipersempit scope nya hanya menjadi instance variable dengan akses protected.  Karena scooping untuk Global dan Instance variable sangat berbeda, maka perlakukan terhadap instance variable yang mewakili Global variable dan benar-benar variable dengan akses global harus mendapatkan perhatian khusus.

Tipe Data Any tidak disupport oleh EAServer
Ganti semua ANY data type assignment menjadi STRING data type dan sesuaiakan perlakuan dari terhadap ANY menjadi  perlakuan terhadap STRING.

Hindari Pembentukan Method yang terlalu besar
Buang semua method yang tidak terpakai lagi karena EAServer mempunyai  keterbatasan terhadap pengelolaan script.  Apabila masih dianggap script terlalu besar saat di-deploy ke dalam sistem, maka berarti komponen harus dipecah.  Dalam hal ini penurunan method harus mendapatkan perhatian khusus agar satu siklus proses hanya terjadi pada satu komponen.

Sebenarnya method yang terlalu besar juga tidak efektif dan dalam tuning aplikasi juga tidak disarankan karena ini akan menimbulkan terbentuknya suatu blok dalam suatu routine yang sangat jarang dipanggil tetapi harus dibuka.

Perhatikan Masalah Encoding.
PowerBuilder untuk versi 8.0 dan sebelumnya menggunakan DBCS (Double Byte Character Sets) dalam menyimpan source code ke dalam file.  Namun mulai versi  9 penyimpanan source code dilakukan dengan menggunakan unicode, dan dalam hal ini adalah UTF16LE.

Hasil Percobaan Migrasi.
Dari hasil pengamatan awal terhadap komponen yang ada pada aplication server dapat disimpulkan bahwa beberapa komponen aktif hanya digunakan 1 komponen yang merupakan turunan terakhir, sehingga bisa disimpulkan bahwa pola penurunannya hanya 1 ke 1. Dan sebenarnya secara riil ini masih belum menggambarkan OOP karena tidak ada generalisasi maupun sebaliknya.  Dari turunan pertama sampai turunan terakhir tidak ada yang dikembangkan hanya menambahkan method.
Setelah dilakukan perubahan untuk meniadakan visual object, meniadakan global variable, type data ANY; saya coba untuk deploy.  Namun sayang masih memberikan pesan kegagalan deployment oleh karena kode terlalu besar.  Akhirnya, dengan memperhatikan pola penurunan yang ada dan karena saya tidak berani untuk mengurangi method yang ada, saya putuskan untuk memecah menjadi 3 buah komponen yang saling bebas dengan mengelompokkan dengan hanya berpatokan pada kemiripan nama methodnya. Kemudian saya coba deploy. Alhamdulillah semua lancar.
Sebagaimana pada PowerBuilder Application Server, eksekusi remote object oleh client ditrigger melalui proxy object yang merupakan skeleton dari server object.  Oleh karena itu, sebagai langkah selanjutnya saya harus menggenerate proxy object di sisi client dengan terlebih dahulu membuang seluruh proxy object yang telah ada.
Telah disebutkan tadi bahwa dalam project ini, saya memecah komponen menjadi 3 komponen saling bebas.  Oleh karena di sini ada 3 komponen yang saling bebas, untuk tetap menjaga behaviour client dari yang sebelumnya terkoneksi secara state-full dengan PowerBuilder Application Server, maka koneksi dengan EAServer juga tetap saya gunakan secara state-full.  Implikasi dari penggunaan state-full ini adalah jumlah koneksi database akan mengikuti jumlah instant yang diaktifkan, dan dalam hal ini ada 3 instan sesuai dengan jumlah komponen yang dideploy.  Oleh karena sebelumnya hanya ada satu komponen, sementara setelah migrasi ada tiga komponen, maka kode pada sisi client harus disesuiakan untuk menggunakan ketiga komponen tersebut dengan mengganti instan dari remote object itu disesuiakan dengan method yang ditrigger.
Setelah semua penyesuaian di sisi client dilakukan, saya mulai mencoba untuk melakukan koneksi client ke server. Koneksi berhasil, namun sayang menu gagal dibentuk karena adanya kegagalan eksekusi komponen di sisi server. Hal ini dilakukan adalah untuk memberikan fleksibilitas object (c.q. Datawindow) assignment sehingga ketika ada perubahan terhadap object dimaksud, tidak perlu melakukan kompilasi untuk dideploy ke server.  Kesalahan yang disampaikan adalah ‘bad UTF-8 data’ pada salah satu object yang melakukan proses ekstraksi source code memasuki environment server sebelum kemudian diassign ke object lain.  Permasalahan ini tidak muncul untuk server yang dideploy ke environment windows.
Lama permasalahan ini mendapatkan penyelesaiannya.  Bahkan ketika mencari ke forum pun hasilnya nihil. Akhirnya dengan melakukan coba-coba sendiri dengan tetap menjaga fleksibilitas sebagaimana dimakasud pada awal paragraf akhirnya tekniknya dirubah dari sebelumnya:

String ls_syntax,errorteks_e
Datastore ds
Integer error_e
Ds = create datastore
Ls_syntax = LibraryExport(“path_to\libfile.pbl”,dwObjectNameArg,ExportDataWindow!)
Error_e = ds.create(ls_syntax,errorteks_e)
If error_e  > 0 then
Ds.settransobject(sqlca)
End if
Dst...

Menjadi:

String ls_Liblist
Datastore ds

Ds = create datastore
lsLibList = GetLibraryList()
AddToLibraryList(“path_to\libfile.pbd”) àperhatikan PBD file bukan PBL file
Ds.dataobject = lower(dwObjectNameArg)
Dst,,,

--pada baris akhir kembalikan library list ke nilai semula
SetLibraryList(lsLibList)

Setlah semua yang perubahan semagaimana dimaksud di atas dilakukan, komponen dideploy ulang ke server.  Oleh karena secara skeleton tidak ada perubahan, proxy object tidak perlu digenerate ulang.
Client langsung dijalankan, dan koneksi berhasil. Menu bisa ditampilkan dengan baik yang berarti perubahan yang dilakukan telah memberikan hasil sesuai yang diharapkan. Namun, sampai  di sini belum semua tujuan terwujudkan.  Pada saat ini hanya ada satu client yang bisa konek.  Bahkan client dengan username lain sekalipun masih gagal melakukan koneksi.  Bahkan dalam beberapa kondisi  menyebabkan crash.  Namun setelah semua komponen propertiesnya diset untuk thread-safe dan support-transaction koneksi bisa dilakukan untuk lebih dari 1 client.

Kesimpulan

  1. Migrasi aplikasi yang telah dibangun dengan menggunakan PowerBuilder Application Sever adalah pilihan yang logis.
  2. Migrasi PowerBuilder Application Server ke EAServer memerlukan beberapa penyesuaian.
  3. Untuk migrasi ke server dengan environment Linux atau Unix harus dihindari pengolahan source code langsung di environment server oleh karena keterbatasan pengenalan encoding.
  4. Untuk environment windows permasalah encoding relatif tidak ada.
  5. Untuk aplikasi dengan session bean state-full maka harus ditentukan bahwa komponen yang melayani aplikasi harus thread-safe.


Catatan:
Pada bebarapa test demgan menggunakan sambungan 3G yang dibatasi sampai 19 kbps, aplikasi masih bisa menjalankan fungsinya.
Applikasi masih memerlukan perbaikan karena saat ini satu aplikasi berjalan membutuhkan 3 koneksi database.

Recommended