So, sudah hampir 2 minggu sejak kerja di Tbilisi, Georgia, badan saya selalu kelelahan tiap pulang kerja. Entah karena lokasi tbilisi yang berada di dataran tinggi dan dekat daerah pegunungan sehingga udara disini lebih tipis, yang klo tidak salah dulu semasa di sekolah saya pernah membaca daerah seperti ini membuat tubuh kita bekerja lebih keras untuk merebut oksigen, atau karena energi yang dikeluarkan ditempat kerja jauh lebih berat dibandingkan tempat-tempat sebelumnya.
Sebetulnya saya sangatlah beruntung bisa dipercaya untuk meng-handle project HLRD/NT-HLR di Georgia, padahal pengalaman HLRD hanya belajar secara cepat di lapangan waktu handle project HLRi Tanzania. Walaupun HLRD bisa dibilang teknologi yang dibangun diatas HLRi dengan tambahan Apertio sebagai databasenya (LDAP Based), namun tetap saja umumnya suatu project akan mempertimbangkan pengalaman dari konsultan yang dicari.
So, here I am, memulai petualangan baru di salah satu negara caucasia.
Tipikal orang eropa adalah smart dan disiplin. Setelah customer Tanzania yang penuh office politik dan pressure sana sini, sekarang mendapatkan customer yang curiousity-nya cukup tinggi, didukung dengan background mereka tentang dunia IT yang cukup baik. Engineernya fasih menggunakan Linux, bahkan terbiasa membaca file melalui hex viewer, dan juga memahami programming dengan baik. Team leader customer adalah orang yang sudah cukup tua, mungkin hampir 60 tahun umurnya (kakek-kakek) tapi cerdas mengenai programming. Kebetulan disini ada masalah yang harus ditangani melalui patch software, dan sang kakek ingin tahu lebih dalam mengenai isi patch tersebut serta mekanisme kerja sistem saat ini secara mendetail dan low-level plus dimana posisi patch tersebut akan dilakukan.
Jadilah akhirnya saya ubek-ubek sistem dengan modal beragam dokumentasi (thx buat salah satu rekan di project Indonesia yang sering kasih dokumentasi lengkap 
) plus support dari NSN Germany. Inti masalah mungkin tidak bisa diceritakan disini karena sifatnya vendor propriatary, tapi hal menarik disini adalah masalah pointer.
Salah satu isi teknologi dari sistem yang dihandle saat ini adalah SOAP (Simple Object Access Protocol), dimana terdapat SOAP Client dan SOAP server. SOAP client akan menghandle suatu proses yang disebut trigger dan merupakan hasil dari suatu proses di database, dalam hal ini LDAP. Teknologi C-NTDB dari apertio menggunakan in-memory execution, yang berarti segalanya di load ke memory, dalam hal ini harddisk hanya menjadi tempat penyimpanan untuk hal-hal seperti sistem operasi. Proses ini sangat cepat, dan karena sangat cepat sehingga SOAP Client yang dibatasi untuk meng-handle hasil transaksi setiap range waktu tertentu untuk kemudian dikirimkan ke SOAP Server tidak dapat langsung memproses hasil transaksi database tersebut. Alhasil, digunakan metode temporary storage didalam disk yang biasa disebut buffer.
Secara logis, hasil transaksi yang tidak bisa dihandle oleh SOAP Client karena jumlahnya yang terlalu besar akan masuk ke suatu file buffer terlebih dahulu, kemudian jika ada slot kosong dari proses SOAP Client yang aktif maka proses tersebut akan membaca dari file buffer untuk kemudian dikirim request nya ke SOAP Server. Standard procedure dan semua orang sudah tau tentang algoritma seperti ini.
Yang menjadi pertanyaan spesifik dari customer adalah bagaimana internal proses dari SOAP Client tersebut, dimana SOAP Client menggunakan suatu file pointer sebagai acuan mengenai data yang ada di dalam file buffer. Bagaimana mekanisme SOAP Client dalam menggunakan file pointer untuk mengetahui di segment mana dalam file buffer letak request selanjutnya yang belum di proses ke SOAP server?!
Pertanyaan yang harus saya jawab dengan menggunakan terminologi programming kepada customer.
Yang kemudian lucu adalah ketika customer dengan rasa ingin tahu tinggi tersebut bermain-main dengan file buffer serta file pointernya. File buffer adalah text file yang size maximumnya bisa 1 GB, sedangkan file pointer adalah binary, yang jika dibuka dengan hexa viewer / di dump dengan hexdump hasilnya seperti berikut:
$ file DEFAULT.msgBuf.ptr DEFAULT.msgBuf.ptr: data $ hexdump HLR-RR-DEL-DEFAULT.msgBuf.ptr 0000000 5340 0a0f 0000 0000 6f2f 7470 732f 6664 0000010 742f 706d 732f 616f 2f70 4c48 2d52 5252 0000020 442d 4c45 442d 4645 5541 544c 6d2e 6773 0000030 7542 0066 0000 0000 0000 0000 0000 0000 0000040 0000 0000 0000 0000 0000 0000 0000 0000 * 0000070 ee2d 00d6 0000 0000 0000 0000 0000 0000 * 0000090 0000 0000 0000 0000 0000 0000 0000 0000 * 00000b0
Pertanyaan customer cukup sederhana, jika file pointer tersebut mengatur SOAP Client untuk mengambil request yang mengantri dari suatu file text dalam disk, seharusnya file pointer tersebut berisi informasi yang bisa dilihat. Tapi pada kenyataannya dalam bentuk hexa diatas hanya ada informasi mengenai absolute path (offset 0×00000008 – 0×00000033) dari file buffer serta ukuran (offset 0×00000070 – 0×00000073) file bufer tersebut, tidak ada informasi mengenai segment keberapa yang harus diambil oleh SOAP Client dari file buffer untuk dieksekusi.
Well, untuk masalah ini saya katakan bahwa dalam suatu sistem ada file-file khusus yang hanya bisa dibaca oleh suatu proses atau aplikasi tertentu, tapi tidak bisa dibaca oleh aplikasi lain. Awalnya mereka bersikeras bahwa suatu file walaupun binary tetap saja hanyalah kumpulan bit, yang jelas-jelas terlihat diatas bahwa selain absolute path serta informasi file size tidak ada data lain, yang berarti seharusnya NSN memiliki penjelasan lain yang masuk akal bahwa masalah saat ini bukan datang dari file pointer tersebut melainkan mungkin ada bug lain, seperti layaknya kernel linux yang seharusnya open terhadap dunia tapi terkadang di-patch secara diam-diam oleh core developer tanpa ada changelog yang jelas .
Dari NSN support jawabannya juga sama dengan perkiraan saya sebelumnya, file pointer adalah spesifik untuk SOAP Client, dan hanya SOAP Client yang bisa membaca informasi didalamnya dan mengerti bagaimana menggunakan informasi tersebut. Hal ini akhirnya saya sampaikan pada customer dan bilang sama mereka “you have to accept that” hehe..
Huff, tiap hari sebisa mungkin saya gunakan untuk mempelajari dengan baik sistem HLRD ini, semakin banyak masalah maka semakin banyak hal yang bisa digali dan itu akan mempercepat proses belajar disini. Semoga saja untuk short-term kontrak disini (rencana cuma sampai lebaran, dan saya serta istri sudah mempertimbangkan untuk tidak extend jika ada tawaran karena disini kurang nyaman terutama bagi muslim) banyak hal yang bisa didapatkan untuk digunakan sebagai modal project-project berikutnya di negara lain. Amin.
.
Recent Comments