Pricing & Scheduling Management

Di dalam Frog Cloud, skema penetapan harga untuk komponen Virtual Machine (VM) bersifat sangat dinamis. Admin memiliki wewenang untuk menetapkan harga komponen yang berbeda berdasarkan Lokasi Data Center (Location) atau berdasarkan Tingkatan Pengguna (Tier).

Karena fluktuasi harga Cloud bisa terjadi sewaktu-waktu, perubahan harga di Frog Cloud tidak terjadi seketika. Sistem menggunakan mekanisme Penjadwalan Harga (Price Change Schedule), di mana Admin menetapkan harga baru beserta Tanggal Berlaku (Effective Date).

Diagram Alur Penjadwalan Harga

1. Menarik Referensi Komponen

Sebelum Admin bisa mengatur harga, Frontend harus terlebih dahulu menarik daftar komponen dasar (seperti vCPU, RAM, Disk NVMe) yang akan dipasangkan harganya.

Request
GET /api/backoffice/component/components

Respons (200 OK): Backend akan mengembalikan daftar komponen yang tersedia. Setiap komponen memiliki atribut tipe (compute, storage) dan ID yang akan digunakan pada API selanjutnya.

2. Melihat Harga Berjalan (Current Pricing)

Untuk merender tabel harga saat ini, Frontend memanggil API berdasarkan konteksnya (Lokasi atau Tier). Harga yang dikembalikan oleh API ini adalah harga final yang sedang aktif detik ini.

Request (Berdasarkan Lokasi)
GET /api/backoffice/pricing/location/{location_id}

Request (Berdasarkan Tier)
GET /api/backoffice/pricing/tiers/{tier_id}

Respons (200 OK):

{
  "data": [
    {
      "id": 1,
      "location_id": 100,
      "component_id": 2,
      "price_per_hour": 15.5
    }
  ]
}

3. Menjadwalkan Harga Baru

Untuk mengubah harga komponen tertentu, Admin harus membuat Jadwal (Schedule). Admin wajib memasukkan monthly_price (Harga Bulanan), dan Backend secara otomatis akan menghitung turunan harga per-jamnya.

Request (Jadwal Harga Lokasi)
POST /api/backoffice/pricing/update-loc
Content-Type: application/json

Request Body
{
  "location_id": 100,
  "component_id": 2,
  "monthly_price": 50000,
  "effective_date": "2026-06-01T00:00:00Z"
}

Perhatian: Parameter effective_date (Tanggal Berlaku) harus menggunakan standar ISO-8601 dan tidak boleh berada di masa lalu.

Jika Anda ingin mengubah skema harga untuk Tier, gunakan endpoint POST /api/backoffice/pricing/update-tier dengan format body yang sama (tambahkan "tier_id" dan hilangkan "location_id").

4. Melihat Antrean Jadwal (Schedules)

Admin tentu ingin melihat daftar harga apa saja yang sedang "mengantre" untuk diterapkan di masa depan.

Request
GET /api/backoffice/pricing/schedule

Respons (200 OK): Backend akan mengembalikan array data antrean. Data ini sebaiknya dirender menjadi tabel di UI dengan kolom Effective Date dan status "Menunggu".

5. Membatalkan Jadwal Harga

Selama jadwal (schedule) belum mencapai effective_date (statusnya masih menunggu), Admin memiliki keleluasaan untuk membatalkan perubahan harga tersebut jika terjadi kesalahan input.

Request
DELETE /api/backoffice/pricing/cancel/{id}

(Ganti {id} dengan ID dari Price Schedule yang didapat dari API tabel antrean di atas).

Kondisi & Tindakan:

Sukses (200 OK): Jadwal dibatalkan dan dihapus permanen. Harga komponen tidak akan berubah pada tanggal yang ditentukan.
Error (400 Bad Request): Jika jadwal sudah terlanjur dieksekusi (melewati effective date), jadwal tidak bisa dibatalkan lagi.

Diagram Alur Penjadwalan Harga​

1. Menarik Referensi Komponen​

2. Melihat Harga Berjalan (Current Pricing)​

3. Menjadwalkan Harga Baru​

4. Melihat Antrean Jadwal (Schedules)​

5. Membatalkan Jadwal Harga​