Belajar OpenClaw - Custom Extensions & Plugins

#Pendahuluan

Di episode 15 kalian menyetel performa OpenClaw — sizing, optimasi evaluasi, dan high availability. Sekarang bayangkan kebutuhan yang tidak bisa dipenuhi fitur bawaan: blokir transaksi karena customer masuk daftar hitam di database perusahaan, atau terapkan kebijakan khusus yang hanya berlaku untuk region tertentu. Apakah kalian harus menunggu rilis OpenClaw? Tidak — di episode 16 kalian menuliskannya sendiri.

Episode 16 membuka kotak perpanjangan: modul policy kustom, integrasi sumber data eksternal, dan hook evaluasi rule lanjutan. Ini adalah titik di mana OpenClaw berubah dari platform menjadi fondasi untuk logika organisasi kalian.

#Model Ekstensi OpenClaw

OpenClaw menawarkan dua cara memperluas kemampuan: modul policy dan plugin. Modul policy adalah unit logika evaluasi yang bisa dipanggil dari dalam rule — mirip fungsi yang memutuskan benar-salah atau nilai tertentu. Plugin lebih luas: bisa menangkap event, berinteraksi dengan data plane, atau menyediakan sink data baru.

Semua ekstensi didaftarkan ke control plane lewat resource terpusat. Karena didaftarkan dan bukan di-hardcode, ekstensi tetap bisa di-review, di-versioning, dan di-rollback lewat proses GitOps yang sudah kalian bangun di episode 9. Setiap ekstensi wajib dideklarasikan versinya — rilis baru tidak akan menyebar diam-diam:

apiVersion: openclaw.io/v1
kind: ExtensionRegistry
metadata:
  name: registry
  namespace: openclaw-system
spec:
  modules:
    - name: fraud-check
      version: 2.1.0
      source: ghcr.io/acme/openclaw-modules/fraud-check
    - name: geo-risk
      version: 1.4.0
      source: ghcr.io/acme/openclaw-modules/geo-risk

#Menulis Modul Policy Kustom

Modul policy menerima konteks request dan mengembalikan hasil evaluasi — misalnya allow, deny, atau skor risiko. Contoh modul sederhana yang memutuskan apakah transaksi melebihi limit harian seorang customer:

daily-limit.py

def evaluate(ctx):
    customer = ctx.lookup("customer_id")
    amount = ctx.lookup("amount")
    spent = ctx.data_store.get_daily_spend(customer)
    if spent + amount > ctx.get_config("daily_limit"):
        return {
            "decision": "deny",
            "reason": "daily_limit_exceeded",
        }
    return {"decision": "allow"}

Modul ini memakai dua fasilitas penting: ctx.lookup untuk mengambil atribut request, dan ctx.data_store untuk menarik data eksternal — jembatan menuju bagian berikutnya. Setelah modul ditulis, uji secara mandiri sebelum didaftarkan:

openclaw module test daily-limit.py \
  --input '{"customer_id": "u-42", "amount": 500}'
openclaw module lint daily-limit.py

Modul yang lolos uji baru didaftarkan, lalu dirujuk dari policy biasa:

apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: daily-limit
  namespace: openclaw-system
spec:
  scope: mesh
  rules:
    - module: daily-limit
      config:
        daily_limit: 1000000
  defaultAction: allow

#Mengintegrasikan Sumber Data Eksternal

Keputusan policy yang baik sering butuh data di luar cluster: daftar hitam, harga, kuota pelanggan. OpenClaw mendukung beberapa data source — database, HTTP webhook, hingga tabel yang disinkronkan berkala. Setiap sumber dideklarasikan, dan pemuatannya di-cache agar tidak membebani sumber aslinya:

apiVersion: openclaw.io/v1
kind: DataSource
metadata:
  name: blacklist-db
  namespace: openclaw-system
spec:
  type: postgres
  connection:
    host: postgres.data.svc
    database: risk
    credentialsSecret: risk-db-credentials
  refresh:
    intervalSeconds: 60
    cacheTtlSeconds: 55
  query: |
    SELECT id, region FROM blocked_entities
    WHERE status = 'active'

Dua hal yang wajib diperhatikan: kredensial diambil dari secret (bukan di-hardcode), dan ada refresh dengan interval serta TTL cache. Data yang basi menyebabkan keputusan salah; data yang terlalu sering di-refresh membebani database. Untuk data yang berubah jarang, sinkronisasi berkala lebih masuk akal daripada query per request.

Alternatif untuk data yang harus real-time adalah webhook lookup — data plane bertanya ke service eksternal saat evaluasi:

apiVersion: openclaw.io/v1
kind: DataSource
metadata:
  name: fraud-api
  namespace: openclaw-system
spec:
  type: webhook
  endpoint: http://fraud-service:8080/check
  timeoutMs: 150
  cacheTtlSeconds: 2

Perhatikan timeoutMs: 150 dan cacheTtlSeconds: 2: webhook yang lambat akan memperlambat setiap keputusan policy. Selalu pasang timeout pendek dan siapkan nilai fallback bila sumber tidak merespons — keputusan yang sedikit telat lebih baik daripada keputusan yang membuat request menggantung.

#Hook Evaluasi Rule Lanjutan

Untuk kontrol paling halus, OpenClaw menyediakan hook pada siklus hidup evaluasi. Hook dijalankan pada titik tertentu — sebelum evaluasi utama, setelah keputusan, atau saat ada efek samping seperti pemblokiran. Ini memungkinkan logika yang tidak nyaman dinyatakan sebagai rule:

apiVersion: openclaw.io/v1
kind: EvaluationHooks
metadata:
  name: observability-hooks
  namespace: openclaw-system
spec:
  preDecision:
    - module: enrich-context
  postDecision:
    - module: publish-decision
      config:
        topic: policy-decisions
  onDeny:
    - module: escalate-notify
      config:
        webhook: http://incident-bot:8080/hook

preDecision memperkaya konteks sebelum rule dinilai — misalnya menambahkan skor risiko dari webhook. postDecision mempublikasikan setiap keputusan ke sistem downstream. onDeny menjalankan aksi khusus saat request ditolak, seperti memberi tahu tim keamanan. Kombinasi hook dan modul memberi kebebasan untuk membangun perilaku yang benar-benar spesifik bagi organisasi — tanpa menunggu fitur rilis OpenClaw.

#Penutup

Episode 16 menunjukkan bahwa OpenClaw tidak berhenti di fitur bawaan: modul policy kustom menampung logika bisnis unik, data source eksternal menghidupkan policy dengan data nyata dari database dan webhook, dan hook evaluasi memberi kontrol pada setiap titik siklus keputusan. Platform kini bisa dibentuk sesuai kebutuhan, bukan sekadar dipakai.

Inti yang harus dibawa pulang:

• Bedakan modul policy (logika evaluasi) dan plugin (perpanjangan yang lebih luas); keduanya didaftarkan lewat registry.
• Tulis dan uji modul secara lokal dengan openclaw module test sebelum didaftarkan.
• Deklarasikan data source dengan interval refresh dan TTL cache yang disesuaikan jenis datanya.
• Pilih fail-closed atau fail-open secara sadar untuk setiap sumber eksternal.
• Gunakan hook preDecision, postDecision, dan onDeny untuk logika yang tidak cocok dinyatakan sebagai rule biasa.

Satu cluster sudah fleksibel, tapi bagaimana kalau organisasi kalian punya banyak cluster di beberapa cloud sekaligus? Di episode 17 kita keluar dari satu cluster: Multi-cluster & Hybrid Environments — manajemen policy lintas cluster, gateway routing untuk traffic multi-cluster, dan pertimbangan networking hybrid cloud. Sampai jumpa di sana!