PART 3 – Masih seputar nostalgia sebelum 2021

Mari kita ngopi sambil ngelanjutin ini ya gaes https://ciuslo.wordpress.com/2021/08/18/part-2-sebelum-2021/. Setelah barang kiriman berlaku nasional berjalan lancar, selanjutnya ada 2 lagi ni gaes yang paling berkesan.

Srutupp (sambil minum kopi).

PDE Internet berlaku nasional

Setelah PDE Manifes di luar kantor besar berjalan lancar kemudian semua kantor-kantor remote sudah pakai PDE di aplikasi impor dan ekspor akan berlaku secara nasional. Ini merupakan tantangan besar karena design awalnya untuk kantor-kantor remote.

Kemudian untuk PIB dan PEB yang lewat PDE belum dialirkan ke INSW, tambah lagi mbah nya sebagai kepala suku founding fathernya pindah kantor karena Promosi, jadi single fighter lagi untuk coding gaes.

Tanpa buang-buang waktu, ciuslo cari wangsit kemudian ketemu masalahnya adalah di titik antrian untuk memproses. FYI dulu awal testing kita pakai jmeter untuk stress tes, dengan varian data kirim dokumen ditambah sertifikat digital itu sangat mampu menangani lebih dari 100 kiriman data secara bersamaan.

Balik lagi ke pokok masalah, cara kerjanya begini : setelah data dikirim masuk mailbox (ibarat keranjang antrian). Antrian ini menggunakan cronJob yang berjalan beberapa menit memakan beberapa jumlah dokumen di mailbox, pengaturan jumlah per waktu di set di properties aplikasi.

Problem started(masalah terus, hahah) saat diputuskan mandatory nasional, masalah pemrosesan antrian, jumlah data lebih banyak daripada pemrosesan yang dilakukan cronJob akhirnya macet lagi macet lagi karena sikomo lewat.. (terawangan yg berujung nyata).

Pada bulatan 1 dan 2 diproses oleh scheduller

Masalah utamanya adalah Antrian (karena pengalaman yang kurang menyenangkan ini, saat mengembangkan aplikasi setelahnya ciuslo selalu menghindari proses utama tangani oleh scheduller/cron/job/timer kecuali benar-benar terpaksa).

skip-skip, Setelah kantor-kantor mulai menggunakan PDE mulai berasa antrian yang numpuk ditambah belum di urutkan, jadi dokumen terposes secara acak (ya elah masak udah masuk duluan keluarnya belakangan, ga adil dong!).

Akhirnya terbesit IDE untuk memecah menjadi beberapa cluster dengan mencontek arsitektur server aplikasi inhouse yaitu besar, madya dan kecil. Ya mulai lagi yakan kerja siang malam bagai kuda mirip zombie dijalani aja dengan ikhlas, hati pasti bahagia klo selesai dan setelah ujicoba pada manusia langsung eh (menghibur diri)… skip skip, intinya selesai ya kan!

Pada awalnya berjalan lancar beberapa bulan, hal ini menyelesaikan masalah, namun begitu mulai masuk kantor besar ternyata ada variasi ukuran dokumen. Karena jika dokumen yang itemnya banyak misal 1000 barang, maka proses mikirnya tentu berlangsung lebih lama.

Misal di mailbox ukuran dokumen besar maka pengiriman ke nsw akan lebih lama dari pada dokumen normal, setelah parsing ini hasil object dikirimkan ke sistem CEISA berpotensi locking. Kemudian, jika servicenya lambat dan belum dianggap selesai, dokumen akan diambil lagi, akibatnya database nya pasti ngos ngosan. Waktu itu jika terjadi locking seperti ini kita selesaikan secara adat, nanti solusi/obat permanennya dibahas dibawah ya.

Masalah selanjutnya ketergantungan dengan sistem lain(potensi deadlock jika ada perlambatan)

skip skip ….. sampai Pada akhirnya : karena semua dokumen dialirkan ke insw PDE ini dapat diilustrasikan sebagai kurir untuk menerima dan mengirimkan dokumen. Ketika terjadi kendala ke alamat tujuan, sementara kurir sudah memboking banyak dokumen dan belum selesai, sementara sudah ada kurir lain mengambil dokumen yang sama karena dianggap dokumen tadi belum selesai. Hal ini membuat locking database yang berulang-ulang, akhirnya deadlock.. Ga bisa dibiarkan begini terus, hampir tiap hari locking yang diselesaikan secara adat. meski udh di cluster, bahkan ada cluster yg ngecek ukuran file besar pun ga mampu menangani hal ini.

Alhamdulillah diberi ilham karena setelah dibalik kesulitan terdapat kemudahan, terbesit ide saat ambil list antrian, sebelum nilainya direturn ke daftar list prosesnya di tampung id nya untuk jadi parameter update dan jadi parameter “IN”. Kurir tadi selanjutnya ga akan mengambil dokumen yang sama karena kode sudah ditandai saat sukses diambil oleh kurir sebelumnya. Bingung ya, monggo konsultasi pribadi klo ada masalah yang sama nanti aku gambarkan diagramnya, jangan lupa bawa gulo kopi biar kaya konsultasi ke dukun ya. wkwkwkkk. 😀

Intinya setelah menerapkan metode ini sampai sekarang tahun 2021 bulan agustus db yg memproses antrian PDE internet belum pernah locking sampai dead lock.. Ya kuncinya itu jika tergantung dengan sistem lain kita tidak boleh menggunakan proses optimis, namun wajib di skenario alternatif untuk menghindari permasalahan ketika sistem lain tersebut melambat/bermasalah. Oh iya pernah server berhenti karena mailboxnya penuh storagenya ga muat hahaah, ga ada yang mantau klo udah jalan lancar masalah doang baru dicari, klo lancar dilupakan yakan hahaah….. Meski masih banyak yg belum sesuai ekspektasi dan masih jauh dari sempurna, akhirnya berjalan lancar sehingga membantu mengurangi belanja sebagai berikut :

Setelah 2017 ini ga ada lelang untuk PDE yang nilainya MMM tiap tahun, alhamdulillah bs sedikit berkontribusi untuk NKRI

Manifes PMK158

Ok lanjut ke cerita selanjutnya, setelah PDE Manifes lancar, temen sebelah mengajukan perubahan dasar hukum gaes. Dapat digambarkan proses perubahan yang cukup fundamental, yaitu penambahan nomenklatur NVOCC setara dengan Pengangkut. Klo ciuslo dan team dulu mengilustrasikan antara induk ayam dan telur, kaya gambar berikut :

Finally Answered! Which Came First, the Chicken or the Egg?

Ya bisa dilihat baik baik ya gambar diatas, menurut anda siapa yang duluan? Telur dulu? atau Ayam dulu? bingung kan?

Begitulah suasana kebatinan team developer saat itu menterjemahkan siapa yang dapat kirim duluan. Karena permintaannya adalah bisa duluan mana saja, ga perlu nunggu. Boleh ayam dulu, atau telur duluan, mintanya sama aja nanti sistem yang akan memasukkan ke kandang unggas klo sesuai dengan matrik kriteria yang tentunya menguras pikiran juga untuk mewujudkannya. bayangin kalo si sistem ngambek atau sekarat mau jadi apa??? seperti saran menkes terawan dulu saat awal corona menyerang yang bisa kita lakukan hanya berdoa..

Begitulah, sepertinya memang trend dunia sedang seneng dengan membuat hal yang sudah pasti menjadi ketidak pastian nih, sampai telur sama ayam duluan mana ga berani teges wajib duluan ayam misalnya, heheeh…

Ok lanjut ya apa bedanya manifes sebelum PMK 158 tadi? perbedaan utamanya yaitu di RKSP(konsep initial manifes sehingga sudah bisa menyampaikan posnya di RKSP) dan NVOCC tadi ilustrasi sebagai berikut (untuk detilnya bisa baca sendiri ya di PMK 158 ) :

Bersukur di aplikasi ini team yang menerjakan personilnya cukup ga seperti pengalaman project sebelumnya yang cius jalani dengan tim minimalis. skip… skip.. sampai akhirnya siap launcing ya bukan mancing,

Masalah selanjutnya adalah training ke user, terutama NVOCC ini yang jumlahnya sangat banyak, padahal sudah berhari-hari dan berbulan2 mengadakan training ke user saat implementasi ternyata masih banyak user baru. Berarti lumayan userfriendly aplikasi yang dibangun, karena langsung dipakai user baru untuk kerja ke production. heheeh

Bersukur saat migrasi sistem ini tidak terjadi kemacetan baik dari pelabuhan maupun bandara karena tidak dapat bongkar. Bisa dibayangkan klo terjadi kemacetan, berapa kerugian yang ditimbulkan. Jadi doa cius terkabul gaes, pelabuhan ga macet dan bandara ga numpuk karena migrasi sistem. Alhamdulillah….

Pelajaran dan hikmah yang dapat diambil adalah :

  1. Memaksimalkan resource server dan DB untuk mewujudkan induk cari telur/ telur cari induk
  2. Menambahkan nomenklatur baru perlu mengantisipasi jumlah user, jadi selain developer perlu trainer yang handal yang mengerti sistem dari kulit sampai jeroannya
  3. UX yang baik akan minimalkan kendala saat implementasi
  4. Tim yang ga minimalis minimal cukup akan mengurangi beban mental developer sehingga lebih bahagia
  5. Masih banyak lagi yang mungkin bisa cius ceritakan kalo sambil ngopi santai lagi ya gaes.

Karena sudah maghrib jadi sampai sini dulu. Sebenernya masih pengen ngetik banyak, tapi masih ada kesibukan lain nih gaes. (heleh so sibuk. wkwkwkk) Sampai jumpa di lain kesempatan ya…. Tetep semangat dan jangan lupa pesan buat sobat cius = > why so serious?????

One thought on “PART 3 – Masih seputar nostalgia sebelum 2021

  1. Very good and comprehensive writing..
    It is amazing how you could build such an impactful application in a very limited time & resources. Wish you a very successful years ahead!

    Like

Leave a comment