SAP HANA Development
SAP HANA XSA基礎：XS Advancedの構成とアプリケーション運用手順
SAP HANA on-premiseで利用するXS Advanced（XSA）の基本構成、XSCとの違い、MTA・HDIコンテナを使った開発、デプロイ、ログ確認、障害切り分けを実務向けに解説します。
XSAとは
XS Advanced（XSA）は、SAP HANA on-premise上でデータベースに近いアプリケーションを実行するためのアプリケーションプラットフォームです。アプリケーション、ルーティング、認証、サービス、データベース成果物を分離して管理できるため、複数の開発成果物を同じシステム上で運用できます。
XSAでは、アプリケーションを単一のサーバープロセスとして扱うのではなく、複数のサービスとランタイムコンポーネントの組み合わせとして扱います。代表的な要素は、XSAコントローラー、アプリケーションランタイム、ルーター、UAA、サービスブローカー、HDIコンテナです。
開発全体の位置付けを先に確認したい場合は、SAP HANA開発の全体像を参照してください。XSAだけでなく、SQLScript、計算ビュー、CDS、HDIを含む開発領域の関係を整理できます。
XSAで管理する主な単位
- Organization：XSA内の管理境界
- Space：アプリケーションとサービスを配置する作業領域
- Application：Node.js、Javaなどで実装した実行単位
- Service：認証、宛先、HDIコンテナなどの提供機能
- MTA：複数モジュールとサービスをまとめたデプロイ単位
実際の権限設計では、ユーザー、ロール、スペースの関係を最初に決めます。開発者がアプリケーションをデプロイできても、サービス作成や本番スペースへの操作まで許可する必要はありません。
XSAとXSCの違い
XSC（XS classic）は、SAP HANAリポジトリを中心にJavaScript、OData、静的コンテンツなどを管理する旧来型の実行方式です。一方、XSAはMTAを単位にアプリケーションとサービスを構成し、HDIコンテナを使ってデータベース成果物を分離します。
主な違いは次のとおりです。
| 観点 | XSC | XSA |
|---|---|---|
| 成果物の管理 | HANAリポジトリ中心 | ソースプロジェクトとMTA中心 |
| 実行単位 | XSエンジン上のアプリケーション | ランタイム上のアプリケーション |
| データベース配置 | リポジトリスキーマを利用 | HDIコンテナを利用 |
| 権限分離 | リポジトリとスキーマを中心に設計 | アプリケーション、サービス、コンテナを分離 |
| デプロイ | リポジトリ成果物を登録 | MTAまたはモジュールをデプロイ |
XSAへ移行・再設計する場合は、単純なファイルコピーではなく、アプリケーション、データベース成果物、認証、宛先、外部接続を別々に棚卸しします。特にXSCのスキーマアクセスをそのまま再現するのではなく、HDIのサービスバインディングとコンテナ間アクセスを基準に設計します。
XSAアプリケーションの構成
XSAアプリケーションでは、アプリケーションモジュールとデータベースモジュールを同じMTAに含める構成が一般的です。たとえば、Node.jsのサービスモジュール、アプリケーションルーター、HDIデータベースモジュールを組み合わせます。
典型的な処理の流れは次のとおりです。
- クライアントがアプリケーションルーターへアクセスする
- ルーターが認証サービスと連携する
- 認証済みリクエストをNode.jsまたはJavaアプリケーションへ転送する
- アプリケーションがサービスバインディングを通じてHDIコンテナへ接続する
- HDIコンテナ内のテーブル、ビュー、プロシージャを利用する
アプリケーションからデータベースへ接続する情報は、ソースコードに固定値として埋め込まず、サービスバインディングから取得します。接続情報や認証情報を環境変数、サービスキー、アプリケーション設定へどう渡すかを、開発環境と本番環境で明確に分けてください。
Node.jsやJavaからHANAへ接続する実装を確認する場合は、SAP HANAのNode.js・Java連携が役立ちます。接続プール、トランザクション、エラー処理をXSAアプリケーションへ組み込むときの前提を整理できます。
MTAの基本構造
MTAプロジェクトでは、通常、次のような役割を分けます。
- アプリケーションモジュール：API、画面、バッチなどを実行する
- データベースモジュール：テーブル、ビュー、シノニム、プロシージャを作成する
- アプリケーションルーターモジュール：URL、認証、ルーティングを制御する
- リソース定義：HDI、UAA、宛先などのサービスを宣言する
mta.yamlでは、モジュール、リソース、依存関係、環境変数を定義します。モジュール名とサービス名を安定させると、ログ確認や再デプロイ時の対象を特定しやすくなります。
HDIコンテナとデータベース成果物
HDIコンテナは、XSAアプリケーションが利用するデータベース成果物を専用のデプロイ境界で管理する仕組みです。設計時には、アプリケーションの技術ユーザーと、データベース成果物をデプロイするユーザーの役割を分けます。
データベースモジュールには、テーブル、ビュー、計算ビュー、プロシージャ、ロールなどを配置します。デプロイ後にアプリケーションが参照する権限は、コンテナ内のロールとサービスバインディングを組み合わせて付与します。
HDIの成果物設計を詳しく確認したい場合は、SAP HANA HDIコンテナの基礎を参照してください。コンテナ、デプロイ用ユーザー、実行時ユーザーの関係を分けて考えることが、権限エラーの防止につながります。
SAP HANAデータベースエクスプローラーは、HDIコンテナ内のスキーマ、テーブル、ビュー、SQL実行結果を確認する際に利用できます。SQLの実行場所と対象コンテナを確認してから、オブジェクトの存在や権限を調べます。
XSAへのデプロイ手順
デプロイ前には、対象スペース、サービスインスタンス、MTAの依存関係、アプリケーションのビルド成果物を確認します。デプロイ対象を本番スペースへ直接向けるのではなく、まず検証用スペースで同じサービス構成を再現します。
基本的な作業の流れは次のとおりです。
- XSA CLIで対象のXSA環境へログインする
- 対象のOrganizationとSpaceを選択する
- 必要なHDIや認証サービスを確認する
- MTAをビルドする
- MTAをデプロイする
- アプリケーションの状態、ルート、サービスバインディングを確認する
- エンドポイントへ接続して動作を検証する
XSA CLIでは、対象環境を確認してから操作します。代表的な確認例は次のとおりです。
xs login
xs target
xs apps
xs services
MTAのデプロイ後は、アプリケーションが起動していても、ルート、認証、サービスバインディング、データベース成果物のすべてが正常とは限りません。アプリケーションの状態だけで完了と判断せず、疎通テストとデータベース側の確認を続けます。
XSAの障害切り分け
障害時は、ブラウザのエラーだけで原因を判断せず、リクエスト経路に沿って確認します。最初にルーターへ到達しているか、次に認証が完了しているか、その後にアプリケーション、サービスバインディング、HDIコンテナの順で調べます。
アプリケーションが起動しない場合
xs appsで状態、インスタンス数、開始時刻を確認します。停止している場合は、アプリケーションログを取得し、起動コマンド、必須環境変数、サービスバインディング、依存ライブラリを確認します。
xs logs <app-name> --recent
xs events <app-name>
起動直後に停止する場合は、ポートの固定、接続情報の固定、書き込み可能なローカルファイルへの依存が原因になりやすい構成です。XSAのアプリケーションは、割り当てられたポートとサービスバインディングを利用する設計にします。
ルーティングまたは認証で失敗する場合
アプリケーションのURL、ルーター設定、認証サービス、コールバックURLを順番に確認します。認証後に403が返る場合は、ユーザー認証の成功だけでなく、アプリケーション側のスコープとロール割り当ても確認します。
データベース接続で失敗する場合
サービスインスタンスが対象スペースに存在すること、アプリケーションへ正しくバインドされていること、HDIコンテナのデプロイが完了していることを確認します。アプリケーションログに接続エラーが出ている場合は、接続先、証明書、ユーザー、コンテナ名を一つずつ照合します。
データベースオブジェクトの不足や権限エラーは、SAP HANAデータベースエクスプローラーで対象コンテナへ接続して確認します。アプリケーション用ユーザーとデプロイ用ユーザーを混同すると、オブジェクトが存在していても実行できない状態になります。
運用で確認するポイント
XSAを安定運用するには、アプリケーション、サービス、データベース成果物の変更を同じ記録で管理します。MTAのバージョン、デプロイ日時、対象スペース、変更されたサービス、ロール変更を残すと、障害発生時に直前変更を追跡できます。
定期的に確認する項目は次のとおりです。
- アプリケーションの稼働状態と再起動回数
- ルートと証明書の有効性
- UAAや関連サービスの状態
- HDIコンテナのデプロイ履歴
- サービスバインディングと不要なサービスキー
- アプリケーションログのエラー傾向
- データベースオブジェクトと実行権限
- スペースごとのユーザーとロール
開発環境で動作していたMTAを本番へ移すときは、環境固有のURL、サービス名、認証設定、接続先をパラメータ化します。秘密情報をソースコードやMTA定義へ直接記述せず、運用手順に沿って安全に登録します。
実務での設計判断
XSAアプリケーション開発では、最初にデータベース成果物とアプリケーションの境界を決めます。データベース側へ集約する処理、アプリケーション側で扱う処理、認証・認可の責任範囲を定義すると、後から権限やデプロイ順序を調整しやすくなります。
計算ビューやSQLScriptを利用する場合も、アプリケーションから直接スキーマを操作するのではなく、HDIコンテナで管理された成果物とロールを経由します。計算ビューの設計方針を確認する場合は、SAP HANA計算ビューの基礎も参照してください。
小さな変更でも、MTA全体の依存関係を確認してからデプロイします。アプリケーションだけを更新する変更と、HDI成果物やサービス構成を変更する更新では、検証項目とロールバック方法が異なります。デプロイ後のログ、ルート、認証、データベース接続を一連のチェックリストで確認すると、見落としを減らせます。