CAPでマルチテナントなサービスを作成する

マルチテナントなサービスとは

SAP BTPにおけるマルチテナントなサービスとは、サービスを提供するサブアカウント（プロバイダー）以外のサブアカウント（コンシュマー）から利用可能なサービスのことを指します。サービスはプロバイダーのサブアカウントで実行され、コンシュマーのサブアカウントがSaaS的に利用するという形態になります。

Help Portal | Developing Multitenant Applications in the Cloud Foundry Environmentより引用

CAPでマルチテナントなサービスを作成する

2023年6月のリリースで、CAPireのドキュメントが大幅に更新されました。ドキュメントに沿って行けば、デプロイまでこぎつけられます。

補足：サイドカーについて
最近のCAPのマルチテナントの特徴は、メインのサービスに加えてサイドカーと呼ばれるサービスが作られることです。このためにプロジェクトに"mtx"というフォルダが追加されます。サイドーカーはテナントのサブスクライブ、アンサブスクライブといったリソースに負荷がかかるオペレーションをメインのサービスから切り離して実行するためのサービスです。

この記事では、ドキュメントに書かれていない以下の太字のステップについて説明します。デプロイ先はCloud Foundry、データベースはSAP HANA Cloudとします。

1. プロジェクトを生成
2. Multitenancyを有効化
3. Dependencyをインストール
4. ローカルで実行
5. デプロイ
6. コンシュマーのテナントでサブスクライブ
7. ルートの追加
8. リダイレクト用URLの追加

手順

この記事を書くために作成したプロジェクトは以下のGitHubリポジトリにあります。

前提

@sap/cdsのバージョンは7.0.2を使用しています。その他のモジュールのバージョンは以下の通りです。

@sap/cds: 7.0.2
@sap/cds-compiler: 4.0.2
@sap/cds-dk: 7.0.2
@sap/cds-dk (global): 7.0.1
@sap/cds-fiori: 1.0.0
@sap/cds-foss: 4.0.2
@sap/cds-hana: 2.0.0
@sap/cds-mtxs: 1.9.1
@sap/eslint-plugin-cds: 2.6.3
Node.js: v16.19.0

5. デプロイ

デプロイする前に、データベースに何を使うのかを指定する必要があります。ここではSAP HANA Cloudを使うため以下のコマンドでデータベースを指定します。

cds add hana --for production

その結果、以下の設定が追加されます。従来はhdbというモジュールによりHANA Cloudをサポートしていましたが、2023年6月に@sap/cds-hanaがリリースされ、今後はこちらを使用するようになっています。

package.json

  "dependencies": {
    ...
    "@sap/cds-hana": "^2"
  },
  ...
  "cds": {
    "profile": "with-mtx-sidecar",
    "requires": {
      "multitenancy": true,
      "[production]": {
        "auth": "xsuaa",
        "db": "hana"
      }
    }
  }

上記の設定後、ドキュメントの通り以下のコマンドでビルド、デプロイします。

App routerを追加

cds add approuter --for production

mta.yamlを追加

cds add mta

npmのdependencyをフリーズ

npm update --package-lock-only
npm update --package-lock-only --prefix mtx/sidecar

ビルド、デプロイ

mbt build -t gen --mtar mta.tar
cf deploy gen/mta.tar -f

6. コンシュマーのテナントでサブスクライブ

コンシュマー用のサブアカウントを新たに作成します。このサブアカウントでは、Cloud Foundryを有効化する必要はありません。ここでは"tenant"というサブアカウントを作成しました。

Service Marketplaceで対象のサービスを探し、Createをクリックします。

Createをクリックしてサブスクライブします。

サブスクライブが完了したら、Go to Applicationをクリックします。

この時点では404 Not Foundというエラーになってしまいます。これは、指定されたURLに対応するルートがまだ存在しないためです。

7. ルートの追加

プロバイダーのサブアカウントのCloud FoundryスペースでRoutesメニューを開き、New Routeをクリックします。

"Not Found"になったURLからホスト名、ドメインを以下のとおりに取得してルートに設定します。

次に、作成したルートにアプリケーションをマッピングします。

ApplicationにApp router（-srvや-mtxとつかないもの）を指定します。

※ここではマニュアルで行いましたが、サブスクライブ時にCloud FoundryのAPIを使用して自動でルートを登録することも可能です。方法は以下の動画をご参照ください。
また、カスタムドメインを使用している場合はホストとカスタムドメインのひもづけを事前に行うため、個別のルートの登録は不要です。このためCAPの中では自動的にルートを登録する仕組みになっていないのかもしれませんね。

再度アプリケーションのURLを開くと、App routerによりログインを求められます。

ログインすると、以下の画面になります。リダイレクト先のURLのドメインが許可されていないためにエラーになっています。

8. リダイレクト用URLの追加

リダイレクト先のURLを許可する設定をxs-security.jsonに追加します。

  "oauth2-configuration": {
    "redirect-uris": [
      "https://*.cfapps.us10-001.hana.ondemand.com/**"
    ]
  }

全体では以下のようになります。

再度ビルド、デプロイを行います。サービスのURLを開くと今度は"Not Found"となります。

app/index.htmlの代わりに/odata/v4/<サービス名>/$metadataを指定するとメタデータが取得できます。

Not Foundとなるのは、App routerの設定（xs-app.json）で指定されているwelcomFileが存在しないためです。対応としてここではwelcomFileの設定を削除してしまいます。

これにより、サービスのURLを開いたときによく知っているCAPのサービス画面が表示されるようになります。

おわりに

この記事では私がつまづいた順序をそのまま再現していますが、本来ステップ7と8はコンシュマーがサブスクライブする前に実施しておくべきです（ルートの登録は自動化、またはカスタムドメインを使うことが望ましい）。そうしないと「サブスクライブしたのに使えない！」ということになってしまいます。

今回は基本的なマルチテナントアプリケーションの作成、デプロイ方法を紹介しましたが、「ルートの自動登録はどうするのか」「Destinationサービスを使いたいとき（各コンシュマーで異なる宛先の設定とする）ときはどうするのか」など、まだ気になる点があります。検証したらまた記事にしたいと思います。