CAPM with SAP HANA Cloud: Deployment Guide

From SQLite to HANA Cloud

Local development runs on SQLite — fast and disposable. Production on BTP means SAP HANA Cloud: real persistence, real transactions, multi-tenancy-ready. The deployment path is well-trodden; here's the whole thing.

The golden rule: develop against SQLite, deploy to HANA. CAP's database layer abstracts the difference — until you use HANA-specific features.

---

Step 1: Add the HANA configuration

Add the HANA deployer to your project:

cds add hana --for production

This adds @capire/hana dependencies, the db/deployer configuration, and an hdi-container resource entry for your mta.yaml.

---

Step 2: The MTA descriptor

Your mta.yaml needs three backend pieces:

modules:
  - name: bookshop-db-deployer
    type: hdb
    path: gen/db
    parameters:
      buildpack: com.sap.hana.hdbbuildpack
    requires:
      - name: bookshop-hdi-container

  - name: bookshop-srv
    type: nodejs
    path: gen/srv
    requires:
      - name: bookshop-hdi-container
      - name: bookshop-auth

resources:
  - name: bookshop-hdi-container
    type: org.cloudfoundry.managed-service
    parameters:
      service: hana
      service-plan: hdi-shared

The deployer module pushes your CDS models as HDI artifacts; the service module binds to the same HDI container at runtime.

---

Step 3: Build and deploy

mbt build
cf deploy mta_archives/bookshop_1.0.0.mtar

mbt build compiles the MTA archive (models → HDB artifacts, services → Node.js droplets). cf deploy pushes it to Cloud Foundry. Watch the deployer logs — table creation errors show up there.

---

HANA-specific considerations

• Case sensitivity — HANA folds unquoted identifiers to uppercase; CAP handles this, but native SQL needs care.
• Data types — Decimal, DateTime, and large strings map cleanly; exotic types need review.
• Initial data — .csv files in db/data deploy as HDI table-data artifacts. Great for reference data.
• Migrations — HDI redeploys are non-destructive for compatible changes; breaking changes need migration planning.

Keep db/ deployable from a clean checkout: anyone should be able to clone, build, and deploy without manual steps.

---

Rollback strategy

Every deployment plan needs an undo. With Cloud Foundry, the simplest rollback is redeploying the previous MTA archive — keep the last few .mtar files, don't delete them after a successful deploy.

Database changes complicate this: HDI redeploys are additive-friendly but won't reverse a dropped column. For risky schema changes, deploy the schema change first (backward compatible), then the code that uses it — the expand/contract pattern.

Test your rollback at least once in QA. A rollback procedure you've never run is a hope, not a plan.

---

Verify the deployment

After deploy: check the service URL, hit /odata/v4/catalog/Books, confirm data flows from HANA. Then set up the CI/CD pipeline so this becomes one command.

Deployment failing? Paste the deployer log excerpt in the comments.