SAP RAP dan SAP CAP adalah dua model pengembangan utama di SAP BTP untuk membangun ekstensi S/4HANA yang modern dan upgrade-safe. Keduanya mendukung prinsip Clean Core, tetapi dirancang untuk skenario yang berbeda. Artikel ini menjelaskan perbedaannya secara praktis dan membantu Anda memutuskan kapan memakai RAP, kapan memakai CAP, atau kapan menggabungkan keduanya.
Mengapa Clean Core jadi standar baru SAP
Selama bertahun-tahun, kustomisasi SAP identik dengan modifikasi langsung pada objek standar lewat ABAP klasik, user-exit, dan enhancement yang menempel di inti sistem. Pendekatan ini membuat setiap upgrade menjadi proyek besar yang berisiko: kode kustom bisa rusak, butuh regresi panjang, dan biaya pemeliharaannya menumpuk.
Dengan SAP S/4HANA dan SAP BTP, SAP mendorong paradigma Clean Core — menjaga inti sistem tetap standar dan bersih, sementara seluruh kustomisasi dibangun sebagai ekstensi yang terpisah dan hanya berkomunikasi melalui API resmi (released API). Hasilnya: sistem yang mudah di-upgrade, siap cloud, dan lebih tahan masa depan. Dua model pengembangan yang menjadi fondasi pendekatan ini adalah RAP dan CAP.
Clean Core bukan soal "tidak boleh kustomisasi", melainkan soal di mana dan bagaimana kustomisasi itu dibangun agar tidak mengunci Anda dari upgrade.
Apa itu SAP RAP?
RAP (ABAP RESTful Application Programming Model) adalah model pengembangan resmi SAP untuk membangun service dan aplikasi berbasis ABAP secara modern. RAP berjalan on-stack — di dalam SAP S/4HANA atau di ABAP Environment pada SAP BTP — sehingga sangat dekat dengan data dan logika bisnis SAP.
RAP dibangun di atas beberapa pilar teknologi:
- Core Data Services (CDS) — untuk memodelkan data dan mendefinisikan service secara deklaratif.
- Behavior Definition & Implementation — untuk logika transaksional (create, update, delete, validasi, aksi, determinasi).
- Service Definition & Binding — untuk mengekspos model sebagai service
OData(V2/V4). - SAP Fiori Elements — untuk menghasilkan UI standar dari metadata, nyaris tanpa coding front-end.
RAP modern dipakai bersama ABAP Cloud — model pemrograman ABAP yang hanya mengizinkan penggunaan released API dan objek yang upgrade-safe. Inilah yang membuat ekstensi RAP tetap selaras dengan Clean Core: Anda menulis ABAP, tetapi dengan pagar yang menjaga sistem tetap bersih.
RAP unggul untuk aplikasi transaksional yang erat dengan proses inti SAP — misalnya ekstensi proses pengadaan, approval, atau objek bisnis kustom yang butuh konsistensi transaksi dan kedekatan dengan tabel S/4HANA.
Apa itu SAP CAP?
CAP (Cloud Application Programming Model) adalah framework SAP untuk membangun aplikasi dan service cloud-native yang berjalan side-by-side di SAP BTP — terpisah dari core S/4HANA. CAP bersifat agnostik dan berpusat pada model: Anda mendefinisikan data dan service dengan CDS, lalu mengimplementasikan logika dengan Node.js (JavaScript/TypeScript) atau Java.
Karakteristik utama CAP:
- Berpusat pada CDS — satu bahasa pemodelan untuk data dan service, sama seperti RAP.
- Polyglot & cloud-native — berjalan sebagai aplikasi di Cloud Foundry atau Kyma (Kubernetes) di SAP BTP.
- Database fleksibel — mendukung SAP HANA Cloud, PostgreSQL, atau SQLite untuk pengembangan lokal.
- Integrasi mudah — kaya akan kemampuan menyambung ke layanan eksternal, event, dan API.
CAP unggul untuk aplikasi baru yang cloud-native — portal pelanggan/supplier, microservice, dashboard, aplikasi yang menggabungkan data dari banyak sistem (tidak hanya SAP), atau solusi yang ingin memanfaatkan ekosistem open-source secara penuh.
RAP vs CAP: perbandingan langsung
Keduanya menghasilkan service OData, mendukung Fiori, dan menjunjung Clean Core. Perbedaannya terletak pada lokasi eksekusi, bahasa, dan kedekatan dengan core SAP:
| Dimensi | SAP RAP | SAP CAP |
|---|---|---|
| Jenis ekstensi | On-stack / in-app (di dalam S/4HANA atau ABAP Environment) | Side-by-side (aplikasi terpisah di SAP BTP) |
| Bahasa | ABAP Cloud + CDS | CDS + Node.js atau Java |
| Runtime | ABAP Platform / ABAP Environment (Steampunk) | Cloud Foundry / Kyma (Kubernetes) |
| Kedekatan dengan data SAP | Sangat dekat (akses langsung, transaksi native) | Lewat API/OData ke S/4HANA |
| Paling cocok untuk | Ekstensi transaksional inti, objek bisnis SAP | Aplikasi cloud-native, integrasi lintas sistem, portal |
| Database | SAP HANA (via S/4HANA) | HANA Cloud, PostgreSQL, SQLite |
| UI | SAP Fiori Elements | SAP Fiori Elements / UI5 / framework lain |
| Keahlian tim | Developer ABAP | Developer JavaScript/Java & cloud |
| Clean Core | Ya (via released API & ABAP Cloud) | Ya (terpisah dari core secara native) |
Kapan memakai RAP, kapan CAP?
Tidak ada jawaban tunggal — pilihan bergantung pada konteks. Panduan praktisnya:
Pilih RAP bila…
- Ekstensi sangat transaksional dan erat dengan proses inti S/4HANA (mis. tambahan field, logika validasi, objek bisnis baru di atas data SAP).
- Anda butuh konsistensi transaksi dan performa akses data SAP secara native.
- Tim Anda kuat di ABAP dan ingin bergerak ke ABAP Cloud secara upgrade-safe.
- Aplikasi akan tampil mulus di dalam SAP Fiori Launchpad S/4HANA.
Pilih CAP bila…
- Anda membangun aplikasi baru yang cloud-native atau microservice.
- Solusi perlu menggabungkan data dari banyak sistem (SAP dan non-SAP).
- Tim Anda lebih kuat di JavaScript/TypeScript atau Java dan ekosistem open-source.
- Anda butuh fleksibilitas database atau ingin men-deploy di Kubernetes (Kyma).
- Beban kerja sebaiknya tidak membebani core S/4HANA.
Menggabungkan RAP dan CAP dalam satu arsitektur
Dalam praktik enterprise, RAP dan CAP bukan pilihan yang saling meniadakan. Arsitektur yang matang sering memakai keduanya: RAP untuk ekstensi yang harus dekat dengan transaksi SAP, dan CAP untuk lapisan aplikasi cloud-native di atasnya. Karena keduanya mengekspos service OData/REST dan sama-sama berbasis CDS, mereka mudah saling terhubung.
Contoh: sebuah portal supplier dibangun dengan CAP (side-by-side, skalabel, terbuka untuk pihak eksternal), sementara logika persetujuan purchase order yang harus konsisten dengan dokumen di S/4HANA dibangun dengan RAP. Keduanya berkomunikasi via API resmi — inti SAP tetap bersih, dan setiap bagian memakai teknologi paling tepat untuk tugasnya.
Poin Penting
- RAP = ekstensi ABAP on-stack, dekat dengan core S/4HANA, untuk skenario transaksional.
- CAP = aplikasi cloud-native side-by-side di SAP BTP, polyglot (Node.js/Java), untuk solusi terbuka & integrasi.
- Keduanya berbasis CDS, menghasilkan OData, mendukung Fiori, dan menjunjung Clean Core.
- Arsitektur terbaik sering menggabungkan keduanya, bukan memilih salah satu.
- Kunci upgrade-safe: hanya pakai released API, jangan modifikasi objek standar.
Bagaimana memulai dengan benar
Transisi ke RAP dan CAP bukan sekadar soal teknologi, tetapi soal tata kelola ekstensi: memilah mana yang harus on-stack, mana yang side-by-side, dan memastikan setiap ekstensi memakai API resmi agar inti tetap bersih. Kesalahan arsitektur di awal akan mahal diperbaiki di kemudian hari.
Ilmuprogram membantu perusahaan menjalankan ini dengan benar melalui pendekatan Quality-Driven Methodology — mulai dari assessment, blueprint arsitektur, hingga implementasi. Tim kami mengerjakan enhancement SAP dengan pendekatan Clean Core (RAP via ABAP Cloud maupun CAP side-by-side), konsultasi & implementasi SAP ERP / S/4HANA, serta pelatihan SAP BTP & Clean Core agar tim internal Anda mandiri membangun ekstensi yang upgrade-safe.
Jika Anda sedang merencanakan ekstensi S/4HANA atau migrasi dari kustomisasi ABAP klasik, mendiskusikan arsitektur sejak awal akan menghemat banyak biaya dan risiko di masa depan.