Belajar Pentaho - Metadata, Repository, & Version Control

#Pendahuluan

Sejauh ini kalian membangun transformasi yang bekerja. Episode 9 membahas pertanyaan yang muncul begitu proyek tumbuh: bagaimana menjaga semua koneksi, konfigurasi, dan file tetap konsisten dan terlacak? Ini soal metadata, repository, dan version control — fondasi kolaborasi tim dan kelangsungan proyek jangka panjang.

Kalian akan belajar mengelola koneksi sebagai shared object, memilih antara repository Pentaho dan penyimpanan file-based, menerapkan Git pada file .ktr/.kjb, serta menggunakan variable substitution untuk memisahkan konfigurasi antar environment.

#Metadata Connection dan Shared Objects

Dalam PDI, metadata adalah "data tentang data" — definisi koneksi, field, dan sumber data yang dipakai banyak tempat. Dua konsep kunci:

• Database connections: koneksi yang didefinisikan sekali dan dipakai ulang oleh semua transformasi di workspace kalian. Perubahan satu koneksi langsung berlaku di semua file yang memakainya.
• Shared objects: objek yang bisa dibagikan antar transformation — koneksi database, koneksi step, mapper nilai, dan lain-lain. Disimpan di folder Shared Objects pada tree panel.

Praktik yang dianjurkan: simpan koneksi database sebagai shared object di level Transformation atau Job, bukan menulis ulang di setiap file. Ini mencegah perbedaan parameter koneksi antar file yang sulit dilacak.

Kalian juga bisa menyimpan koneksi dalam bentuk file .properties di folder project — beberapa tim lebih suka pendekatan ini karena ikut ke version control.

#Pentaho Repository vs File-Based Storage

Ada dua cara menyimpan dan mengelola objek PDI:

Untuk development lokal dan pembelajaran, file-based plus Git adalah pilihan paling sehat — sederhana, portable, dan bebas ketergantungan server. Repository Pentaho lebih menarik saat kalian bekerja dalam tim besar yang butuh kontrol akses dan integrasi langsung dengan Pentaho Server.

#Version Control Proyek PDI dengan Git

File .ktr dan .kjb sebenarnya adalah XML — sehingga bisa di-version control seperti kode biasa. Ini mengubah cara tim bekerja: review perubahan, rollback, dan riwayat siapa mengubah apa.

Mulailah dengan memastikan project kalian berada di repositori Git, lalu biasakan commit dengan pesan yang menjelaskan perubahan:

git init
git add transformations jobs resources
git commit -m "feat: tambah transformasi staging order dari CSV"

Tambahkan file .gitignore agar file sementara dan lingkungan pribadi tidak ikut ter-commit:

*.log
kettle.properties
.tmp/

Kalian bisa melihat riwayat perubahan dengan git log dan membandingkan dua versi file dengan git diff. Karena file XML, diff kadang cukup berisik — tapi perubahan kecil seperti koneksi atau SQL yang salah mudah dikenali.

#Mengelola Environment dan Variable Substitution

Masalah klasik dalam proyek data: kode yang sama harus berjalan di environment berbeda (development, staging, production) dengan koneksi dan path yang berbeda. Solusi PDI adalah variable substitution — nilai konfigurasi disimpan dalam variabel, bukan ditulis keras di file.

Tingkat-tingkat penentuan variabel, dari yang paling spesifik:

• Parameter: dilewatkan saat menjalankan, misalnya -param:ENV=dev.
• Variabel di job entry: di-set di dalam job, misalnya hasil dari Set variables.
• Variabel di file properties: global di kettle.properties.
• Nilai default sistem.

Contoh: alih-alih menulis host database di setiap file, pakai variabel DB_HOST, DB_PORT, DB_NAME, dan DB_PASSWORD. Di Spoon, field host, port, dan nama database cukup diisi nama variabelnya — PDI akan mengganti dengan nilainya saat eksekusi, mengikuti sintaks substitusi yang dikenali mesin PDI. Saat menjalankan dari command line, berikan nilainya:

pan.sh -file=etl_order.ktr -param:DB_HOST=localhost -param:DB_NAME=lab

Dengan pola ini, satu file .ktr yang sama bisa berjalan di development maupun production — hanya parameternya yang berbeda. Ini fondasi dari environment management yang dibahas lebih dalam di episode 14 dan 19.

#Menyusun Struktur Project yang Maintainable

Struktur folder yang baik adalah metadata tersendiri. Standar yang banyak dipakai tim PDI:

project-name/
├── transformations/
│   ├── staging/
│   ├── dimension/
│   └── facts/
├── jobs/
│   ├── daily/
│   └── monthly/
├── resources/
│   ├── sql/
│   └── files/
├── scripts/
└── .gitignore

Pemisahan berdasarkan fungsi (staging, dimension, facts) dan frekuensi (daily, monthly) membuat tim langsung tahu di mana mencari sesuatu. Kombinasikan struktur ini dengan variable substitution dan Git, maka proyek kalian sudah layak dijalankan ber-ramai-ramai.

#Penutup

Di episode 9 ini kalian menata aset proyek: mengelola koneksi sebagai shared object, memahami perbedaan Pentaho Repository dan file-based storage, menerapkan Git pada file PDI, serta menggunakan variable substitution untuk memisahkan konfigurasi antar environment.

Inti yang harus dibawa pulang:

• Simpan koneksi sekali sebagai shared object agar konsisten di seluruh file.
• File-based plus Git cocok untuk development; repository Pentaho untuk kontrol terpusat dan kolaborasi besar.
• .ktr dan .kjb adalah XML — perlakukan seperti kode dengan commit dan review.
• Variable substitution memisahkan konfigurasi dari logika; jangan pernah menulis kredensial keras di file.

Di episode 10, kita memasang panggung untuk produksi: Pentaho Server & web console — menyiapkan server, meng-upload job dan transformasi, menjadwalkan eksekusi via BI Server, dan mengatur akses pengguna serta peran.