Belajar Pentaho - Error Handling & Debugging

#Pendahuluan

Semua pipeline akan gagal — itu bukan pertanyaan "jika", melainkan "kapan". Koneksi database terputus, file yang dibaca berganti format, data aneh memicu error. Yang membedakan engineer hebat bukan bebas dari error, melainkan kecepatan menemukan dan mengatasi masalah.

Episode ini membahas error handling dan debugging di PDI: bagaimana memastikan kegagalan tertangkap dengan benar, bagaimana menemukan akar masalah dengan preview dan breakpoint, serta bagaimana membaca log dan metrics untuk mempercepat diagnosis.

#Memahami Jenis Error di PDI

Error di PDI bisa dikelompokkan menjadi tiga, dan strategi penanganannya berbeda:

• Error saat membaca data: file tidak ditemukan, koneksi gagal, format tanggal tidak cocok. Ini paling sering terjadi saat kontrak data berubah.
• Error saat transformasi: konversi tipe gagal, pembagian dengan nol, atau data tidak cocok dengan aturan step. Biasanya baru muncul saat data aneh masuk.
• Error saat menulis data: kolom tidak cocok dengan tabel target, constraint unique dilanggar, atau disk penuh.

Sebagian besar error muncul di step tertentu dengan pesan yang sebenarnya cukup menjelaskan — selama kalian tahu di mana mencarinya. Kuncinya: jangan pernah mengabaikan log merah.

#Menangani Error dalam Transformasi

Dalam transformation, ada beberapa mekanisme penanganan error:

• Error handling per step: banyak step punya opsi tab Error handling untuk mengarahkan baris yang gagal ke output khusus, mirip pola baris valid vs invalid di episode 6.
• Step untuk deteksi: Filter rows dan Validator menangkap masalah sebelum error fatal terjadi.
• Logging berjenjang: menulis detail baris yang bermasalah ke file untuk investigasi lanjutan.

Pola terbaik adalah mencegah error dari muncul lebih dulu: validasi sejak awal, dan arahkan baris mencurigakan ke jalur yang jelas alih-alih membiarkannya meledak di tengah pipeline. Namun untuk error yang tak terhindarkan, pastikan ada jejak: tulis field kunci dan pesan error ke file log.

Saat menjalankan transformasi dari command line, kontrol level log sangat berguna. Gunakan level Debug untuk melihat detail stream saat mencari masalah:

pan.sh -file=mytrans.ktr -level=Debug -logfile=/tmp/mytrans_debug.log

Level log yang tersedia: Error, Minimal, Basic, Detailed, Debug, dan Rowlevel. Mulai dari Basic, naikkan ke Debug hanya saat investigasi, dan jangan lupa kembali ke level normal untuk produksi — -level=Basic hampir selalu cukup untuk run rutin.

Saat transformasi gagal, pesan error biasanya menunjuk ke step dan baris penyebabnya — misalnya ... at step 'Select values' .... Dua informasi ini adalah titik mulai investigasi: buka step itu, periksa field yang dicurigai dengan Preview, lalu telusuri nilainya dari sumber. Kebiasaan mencatat pesan error lengkap — bukan hanya kalimat terakhirnya — akan sangat membantu saat kalian bertanya di komunitas.

#Menangani Error dalam Job

Job punya mekanisme penanganan error yang berbeda karena sifatnya orkestrasi. Strategi utamanya:

• Hop failure: arahkan kegagalan ke jalur penanganan khusus — kirim email peringatan, panggil job recovery, atau catat ke log.
• Retry: beberapa job entry mendukung pengulangan otomatis dengan jeda, misalnya mencoba ulang koneksi yang sempat terputus.
• Job entry Simple evaluation: periksa kondisi sebelum melanjutkan, sehingga kegagalan kecil tidak menggulir ke langkah berikutnya yang lebih mahal.
• Abort: hentikan eksekusi dengan status failure secara terkendali, lengkap dengan pesan yang menjelaskan.

Standar industri yang harus kalian tiru: setiap job production punya jalur failure yang mengirim notifikasi dan mencatat konteks lengkap — job mana, step mana, jam berapa, dan pesan errornya. Episode 13 akan membahas logging dan observability secara menyeluruh.

#Preview Rows dan Breakpoint

Mekanisme debugging interaktif di Spoon adalah senjata utama kalian:

• Preview: klik kanan pada sebuah step dan pilih Preview untuk menjalankan transformasi sampai step tersebut dan menampilkan sampel baris yang mengalir. Ini cara tercepat memvalidasi setiap tahap.
• Breakpoint: klik kanan pada hop lalu pilih Set breakpoint. Saat transformasi dijalankan, eksekusi berhenti di titik itu dan Spoon menampilkan baris yang tertahan. Kalian bisa melanjutkan baris per baris atau membiarkan semuanya lewat.
• Inspect: saat breakpoint aktif, klik kanan hop dan pilih Inspect untuk melihat baris di titik tersebut.

Teknik ini memungkinkan kalian "berjalan bersama data" dan menemukan persis di step mana nilai mulai melenceng. Kombinasi preview di beberapa titik seringkali lebih efektif daripada membaca log panjang baris demi baris.

#Execution History sebagai Alat Perbandingan

Spoon menyimpan Execution history setiap transformasi yang dijalankan. Setelah beberapa kali run, bandingkan angka Step Metrics antar run: jika sebuah step mulai memproses lebih lambat atau error count-nya naik, kalian bisa mendeteksi degradasi sebelum kegagalan penuh. Ini semacam dashboard mini yang tidak perlu alat eksternal — cukup klik tab Execution History di panel bawah.

Latihan praktis: jalankan transformasi yang sama dengan data yang volumenya berbeda-beda, lalu amati bagaimana waktu dan jumlah baris berubah. Kemampuan membaca tren antar run inilah bekal kalian di episode 13, saat membahas monitoring dan observability secara menyeluruh.

#Menganalisis Step Log dan Performance Metrics

Saat transformasi berjalan, panel log dan tab Step Metrics memberi gambaran kesehatan tiap step. Hal-hal yang harus kalian perhatikan:

• Jumlah baris per step: lines input vs lines output — jika angka turun drastis di sebuah step, ada filter atau error yang memotong aliran.
• Kecepatan eksekusi: baris per detik — penurunan tiba-tiba menandakan bottleneck seperti lookup tanpa cache atau disk lambat.
• Error count per step: lokasi kegagalan yang sebenarnya, jauh lebih berguna daripada pesan error umum.
• Waktu eksekusi total: pembanding antar run untuk mendeteksi degradasi performa bertahap.

Untuk menemukan bottleneck, perhatikan step dengan active yang tinggi atau lines read yang melambat. Step yang menunggu — biasanya yang melakukan query database atau menulis disk — adalah tersangka utama.

#Best Practice Recovery

Saat transformasi benar-benar gagal di production, tujuannya adalah kembali sehat secepat mungkin tanpa korupsi data. Best practice-nya:

• Idempotensi: rancang transformasi agar aman dijalankan ulang. Gunakan truncate di awal jika full replace, atau kunci deduplikasi jika incremental, sehingga run kedua tidak menggandakan data.
• Log yang cukup: simpan log ke file dengan level Basic atau Detailed; pastikan berisi waktu, nama transformasi, dan pesan error.
• Dokumen rollback: tulis langkah pemulihan — misalnya "restore dari backup tabel staging" — di runbook (dibahas lengkap di episode 19).
• Jangan retry buta: sebelum menjalankan ulang, pahami dulu apakah kegagalan bersifat sementara (jaringan) atau permanen (format file berubah). Retry yang salah hanya mengulang kegagalan.
• Recovery bertahap: untuk volume besar, pertimbangkan proses per batch atau per tanggal, sehingga kegagalan hanya mengulang sebagian kecil data.

#Penutup

Di episode 7 ini kalian membekali diri menghadapi kegagalan: memahami jenis error di PDI, menangani error di transformation dan job, memakai preview dan breakpoint untuk debugging, menganalisis step log dan performance metrics, serta menerapkan best practice recovery yang aman.

Inti yang harus dibawa pulang:

• Error di PDI bisa dicegah sejak dini dengan validasi; yang tak terhindarkan harus meninggalkan jejak log.
• Preview dan breakpoint membuat kalian "berjalan bersama data" dan menemukan titik melenceng.
• Step Metrics mengungkap bottleneck: perhatikan jumlah baris dan kecepatan tiap step.
• Idempotensi adalah kunci recovery — transformasi harus aman dijalankan ulang.

Di episode 8, kita melebarkan jangkauan: advanced sources & targets — menghubungkan database, CSV, Excel, XML, JSON, dan REST API, memakai konektor Hadoop dan cloud storage, menulis ke data warehouse, serta memanfaatkan lookup dan caching untuk performa.