Layanan Backend CRM BUMN

Ringkasan

Layanan backend untuk sebuah BUMN besar, dibangun sebagai bagian dari PT. Noxus Ideata Prima. Sistem ini adalah platform Customer Relationship Management (CRM) enterprise, dibangun untuk menggantikan sistem billing lama dengan arsitektur modular yang modern — mencakup manajemen akun, manajemen pengguna, dan manajemen produk & promo.

flowchart TB
    subgraph Client["Klien"]
        FE["React SPA<br/>satu shell untuk semua modul bisnis"]
    end

    subgraph Gateway["Reverse Proxy (Nginx)"]
        NG["Rute berdasarkan path prefix<br/>per domain bisnis"]
    end

    subgraph Services["Microservices Bisnis (Spring Boot)"]
        ACC["Layanan Manajemen Akun"]
        UM["Layanan Manajemen Pengguna"]
        PP["Layanan Produk & Promo"]
        NOTIF["Layanan Notifikasi"]
    end

    subgraph Shared["Shared Libraries (Maven)"]
        COMMON["Common Library<br/>security, JWT/LDAP, approval engine, notification client"]
        CRM["Common CRM Library<br/>entity + repository JPA untuk seluruh skema"]
        BASE["Common Base Library<br/>base entity, generic filter/spec framework"]
    end

    subgraph Infra["Infrastruktur"]
        ORA[("Oracle DB")]
        KAFKA{{"Kafka<br/>topic notifikasi"}}
        MINIO[("Object Storage<br/>lampiran")]
        LDAP[("LDAP / Active Directory")]
    end

    FE --> NG
    NG --> ACC & UM & PP & NOTIF

    ACC --> COMMON & CRM
    UM --> COMMON & CRM
    PP --> COMMON & CRM
    CRM --> BASE

    ACC & UM & PP & CRM --> ORA
    ACC & UM & PP -->|publish event| KAFKA --> NOTIF
    NOTIF -->|push real-time| FE
    ACC & UM & PP --> MINIO
    UM --> LDAP

Setiap layanan bisnis di-deploy dan di-scale secara independen (Helm chart-nya masing-masing di Kubernetes), namun ketiganya berbagi satu skema Oracle yang sama melalui shared JPA library, bukan mendefinisikan entity sendiri-sendiri — sehingga model data dan sebagian besar logika security/approval terpusat di satu tempat, bukan terduplikasi di tiap layanan.

Masalah

• Sistem billing lama bersifat rigid dan sulit dikembangkan seiring pertumbuhan bisnis.
• Data sensitif (akun, harga, promo, kontrak) membutuhkan proses approval berjenjang yang bisa dilacak sebelum perubahan apa pun bisa diterapkan.
• Data billing lama selama bertahun-tahun harus dipindahkan ke sistem baru tanpa mengganggu operasional harian.

Solusi

• Layanan modular, masing-masing bertanggung jawab atas satu area bisnis (akun, pengguna, produk & promo), sehingga tim bisa membangun dan merilis secara independen.
• Approval workflow bawaan: setiap perubahan sensitif diarahkan ke approver yang tepat sebelum berlaku, lengkap dengan audit trail.
• Notifikasi real-time sehingga approver dan requester langsung mendapat info begitu keputusan dibutuhkan atau dibuat.
• Migrasi data bertahap yang memindahkan data lama ke sistem baru secara aman, menandai data yang perlu ditinjau manual alih-alih memblokir keseluruhan proses.

Approval Workflow (dipakai bersama di semua modul)

sequenceDiagram
    participant U as Pengguna
    participant SVC as Layanan Bisnis<br/>(Account/Product/User)
    participant APR as Approval Engine<br/>(Common Library)
    participant DB as Oracle DB
    participant KAFKA as Kafka
    participant NOTIF as Layanan Notifikasi
    participant APV as Approver

    U->>SVC: Kirim perubahan
    SVC->>DB: Simpan/update record bisnis (pending)
    SVC->>APR: Daftarkan permintaan approval
    APR->>DB: Insert record approval (WAITING_FOR_APPROVAL)
    APR->>KAFKA: publish notification.create
    KAFKA->>NOTIF: consume event
    NOTIF-->>APV: notifikasi real-time
    APV->>SVC: Buka detail record
    SVC->>APR: Cek apakah user saat ini adalah approver
    APR-->>SVC: true / false
    SVC-->>APV: Tampilkan detail approval (hanya jika approver yang berwenang)
    APV->>SVC: Approve / Reject
    SVC->>DB: Update riwayat approval + status record
    SVC->>KAFKA: publish notification.broadcast (keputusan)
    KAFKA->>NOTIF: consume
    NOTIF-->>U: beri tahu requester atas keputusan

Engine yang sama menangani approval untuk semua domain — approver di level saat ini ditentukan dengan mencocokkan posisi yang dibutuhkan oleh approval hierarchy dengan posisi user yang mengajukan/menyetujui, sehingga aksi approval hanya muncul untuk user yang memang berwenang di level tersebut.

Model Data Sederhana

erDiagram
    CUSTOMER ||--o{ ACCOUNT : "memiliki"
    ACCOUNT ||--o{ SERVICE_AGREEMENT : "memiliki"
    ACCOUNT ||--o{ PROMO : "menerima"
    PRODUCT ||--o{ PRODUCT_VERSION : "versioned (copy-on-write)"
    PRODUCT_VERSION ||--o{ PRICING : "diberi harga"
    PRODUCT_VERSION ||--o{ TERMS_OF_SERVICE : "diatur oleh"
    EMPLOYEE ||--o{ POSITION_ASSIGNMENT : "ditugaskan"
    POSITION_ASSIGNMENT }o--|| POSITION : "menempati"
    POSITION ||--o{ APPROVAL_HIERARCHY : "level approval"
    APPROVAL ||--o{ APPROVAL_HISTORY : "jejak keputusan"
    ACCOUNT ||--o{ APPROVAL : "butuh approval (via kategori)"
    PRODUCT_VERSION ||--o{ APPROVAL : "butuh approval (via kategori)"
    PROMO ||--o{ APPROVAL : "butuh approval (via kategori)"

Relasi ke APPROVAL bersifat konseptual, bukan foreign key literal — tabel approval menyimpan record ID generik plus kolom kategori yang menandai domain asalnya, dipakai bersama oleh semua modul bisnis. Produk mengikuti pola copy-on-write versioning: setiap perubahan membuat baris product-version baru, bukan mengubah baris yang sudah ada.

Kontribusi Utama

• Membangun API endpoint inti untuk manajemen akun, service agreement, dan harga/promo.
• Menyelesaikan masalah sinkronisasi data antar layanan yang berbagi data yang sama.
• Berkontribusi pada upaya migrasi data dari sistem lama ke sistem baru.
• Memenuhi standar keamanan dan kualitas kode tingkat enterprise yang disyaratkan untuk klien BUMN.