SAP CPI API Management基礎：APIプロキシとポリシーを運用する方法

SAP CPI（Cloud Integration）で作成したiFlowを外部システムや社内アプリケーションから利用させる場合、iFlowのURLをそのまま公開するのではなく、API Managementを前段に配置してAPIプロキシ経由で公開する構成が実務的です。APIプロキシを境界に置くことで、認証、レート制限、ヘッダー制御、ログ取得、バックエンドURLの隠蔽を一元的に管理できます。

この記事では、SAP Integration SuiteのAPI Managementを使うときの構成、初期設計、代表的なポリシー、テスト、監視、障害切り分けを順番に整理します。iFlowそのものの作成手順は、先にSAP CPI iFlow基礎を確認すると、API公開との役割分担を理解しやすくなります。

01API Managementの役割

API Managementは、クライアントからのリクエストを受け付け、必要な検証や制御を行ってからCloud IntegrationのiFlowへ転送するレイヤーです。主な構成要素は、公開エンドポイントを持つAPIプロキシ、転送先を定義するターゲットエンドポイント、処理を追加するポリシー、APIを利用するアプリケーションまたは開発者向けの管理単位です。

APIプロキシのURLとバックエンドのiFlow URLを分離すると、iFlowの配置やURLを変更しても利用者側の接続先を維持できます。また、利用者ごとの認証情報や利用量をAPI Management側で管理し、iFlowのロジックに認証処理を過度に埋め込まずに済みます。

API ManagementとiFlowは競合する機能ではありません。公開境界の制御はAPI Management、業務メッセージの処理はCloud Integrationという分担にすると、設計と障害調査の範囲が明確になります。

02APIプロキシの設計

APIプロキシを作成する前に、公開するAPIの契約を決めます。最低限、HTTPメソッド、リソースパス、クエリパラメータ、リクエストとレスポンスの形式、HTTPステータス、認証方式、タイムアウト、再実行時の扱いを文書化します。

たとえば、受注照会APIであれば、GET /orders/{orderId} のようにリソースを表すパスを定義し、成功時のレスポンス、対象データがない場合の404、入力不備の400、認証失敗の401、権限不足の403を使い分けます。業務エラーをすべて200で返す設計は、監視や再実行の判断を難しくするため、HTTPステータスと業務エラーコードの対応を先に決めておくことが重要です。

APIプロキシの設計では、次の項目を個別に確認します。

• 公開用のベースパスとバージョン表記
• 接続先iFlowのURLと認証情報
• クライアント認証の方式
• リクエストサイズと呼び出し頻度の上限
• 必須ヘッダー、相関ID、Content-Type
• エラー本文に含める情報の範囲
• 個人情報や業務機密をログへ出力する範囲
• 後方互換性を保つバージョン管理方法

バージョンはURLの /v1、ヘッダー、メディアタイプなどで表現できます。既存の利用者がいる場合は、後からフィールドを削除せず、非推奨期間と終了日を通知して段階的に切り替えます。

03ポリシーの基本

ポリシーは、APIプロキシの処理フローに追加する制御単位です。実際に設定するポリシーは、認証方式、利用者数、公開範囲、バックエンドの処理能力、監査要件によって決めます。

代表的なポリシーの用途は次のとおりです。

• APIキーやOAuthトークンの検証
• クライアント単位またはアプリケーション単位のレート制限
• リクエストとレスポンスへのヘッダー追加・削除
• バックエンドURLや資格情報の保護
• JSON、XML、URLパラメータなどのメッセージ変換
• 許可するHTTPメソッドやコンテンツタイプの制限
• 相関IDの付与とトレース用ヘッダーの引き継ぎ

認証と認可は分けて考えます。認証は呼び出し元を確認する処理で、認可はその呼び出し元が特定のAPIや操作を実行できるかを判定する処理です。APIキーだけで利用者を識別し、業務データへのアクセス範囲をiFlow側で判定する構成もありますが、責任分界を設計書に明記してください。

レート制限は、単純に大きな値を設定すればよいものではありません。バックエンドの処理能力、ピーク時間の呼び出し数、再試行による増幅、バッチ処理の有無を確認し、クライアント単位とAPI全体の両方で上限を設けます。制限に到達した場合は、429と再試行の目安を返す設計が運用しやすくなります。

04認証と資格情報の管理

公開APIでは、TLSによる通信保護に加えて、呼び出し元を識別する認証方式を選択します。代表的な方式にはAPIキー、OAuth 2.0、クライアント証明書があります。外部パートナーが多く、トークンの有効期限や権限を管理したい場合はOAuth 2.0が適しています。閉じたネットワーク内でシステム間認証を厳格に行う場合は、クライアント証明書を検討します。

APIキーを採用する場合は、キーをソースコード、iFlowの固定値、URLクエリに埋め込まず、管理対象の資格情報として保管します。キーの発行者、利用者、発行日、用途、失効日を台帳に記録し、定期的にローテーションします。

OAuthトークンを利用する場合は、トークンの検証先、スコープ、発行者、対象者、有効期限を確認します。トークンの内容を信頼して業務権限を決める場合は、発行元との契約と検証条件を明確にします。

認証情報を更新したときは、APIプロキシだけでなく、接続先iFlow、宛先設定、証明書チェーン、監視用の疎通テストも確認します。資格情報のローテーションは、利用者への通知、旧情報の有効期間、切り戻し手順まで含めて作業計画にします。

05iFlowとの接続設定

APIプロキシからiFlowへ転送する際は、ターゲットURL、HTTPメソッド、認証情報、タイムアウト、TLS証明書、必要なヘッダーを確認します。iFlow側では、API Managementから渡される相関IDや利用者情報を処理に利用するかを決定します。

Cloud IntegrationのiFlowをAPIのバックエンドにする場合、iFlowのエンドポイント認証とAPIプロキシの公開認証を分けて設定します。外部利用者がAPIプロキシの認証を通過しても、プロキシからiFlowへの接続が認証されなければリクエストは成功しません。

バックエンドにIDocを送る構成では、APIのJSONやXMLをIDoc形式へ変換し、必要な制御レコードや必須項目を設定します。IDoc連携の設計はSAP CPI IDoc連携基礎も参照できます。値変換や固定値の管理にはSAP CPI Value MappingとContent Modifierが役立ちます。

接続テストは、次の順番で行うと原因を分離できます。

1. iFlowを直接呼び出し、バックエンド処理が成立することを確認する
2. APIプロキシから認証なしで呼び出し、期待する401または403になることを確認する
3. 正しい認証情報で呼び出し、プロキシからiFlowまで到達することを確認する
4. 不正なメソッド、必須項目不足、過大なペイロードを送信する
5. レート制限、タイムアウト、バックエンドエラーの応答を確認する
6. 相関IDを使ってAPI ManagementとCloud Integrationのログを突合する

06テストと障害切り分け

APIの障害は、クライアント、APIプロキシ、ポリシー、ネットワーク、iFlow、接続先SAPシステムのどこでも発生します。最初にHTTPステータス、発生時刻、相関ID、呼び出し元、APIプロキシ名、バックエンド応答を記録します。

認証エラーでは、クライアントが送信したAuthorizationヘッダー、トークンの期限、APIプロキシに設定した検証条件を確認します。403の場合は、認証が成立した後のスコープや利用者権限を確認します。404では、プロキシのベースパスと実際のリソースパスを分けて確認すると、URLの組み立てミスを見つけやすくなります。

500系のエラーでは、まずAPI Managementのポリシー実行結果とターゲットへの到達状況を確認し、その後にCloud Integrationのメッセージ処理ログを調査します。iFlowの処理ログは、SAP CPI監視とエラーハンドリング基礎に沿って、相関ID、メッセージID、処理ステップ、例外内容を記録すると追跡しやすくなります。

ログには、アクセストークン、パスワード、個人情報、業務上の機密値を出力しない設計にします。本文全体を保存するのではなく、リクエストサイズ、ステータス、処理時間、相関ID、エラーコードなど、調査に必要な情報へ絞ります。

07運用監視の設計

API公開後は、単なる稼働確認だけでなく、利用量、エラー率、レイテンシ、レート制限到達数、認証失敗数、バックエンド障害数を継続的に確認します。監視項目ごとに、警告しきい値、重大しきい値、通知先、一次対応、エスカレーション先を決めます。

監視では、API Management側のアクセス状況とCloud Integration側のiFlow処理状況を別々に見るだけでなく、相関IDで一つのトランザクションとして追跡します。API Managementで成功していてもiFlowの業務処理が失敗する場合があるため、HTTPステータスだけで正常と判断しないことが重要です。

定期運用では、次の確認を実施します。

• APIキー、証明書、OAuthクライアントの有効期限
• APIプロキシとiFlowのデプロイ状態
• レート制限と実際の利用量
• 4xx、5xx、タイムアウトの推移
• バックエンドの応答時間と接続失敗
• 監査ログと機密情報マスキング
• 非推奨APIの利用状況
• 障害時の再送と重複登録の防止

変更作業では、ポリシー変更、バックエンドURL変更、認証情報更新、証明書更新、iFlow更新を分離して記録します。複数の変更を同時に行うと、障害発生時に原因を特定しにくくなるため、変更単位ごとに疎通テストと切り戻し条件を設定します。

08本番公開前のチェックリスト

本番公開前は、機能テストだけでなく、異常系と運用系を含めて確認します。特に認証情報、エラー応答、ログ、再試行の扱いは、公開後の影響が大きい項目です。

• API仕様書と実装のパス、メソッド、ステータスが一致している
• 認証なし、期限切れ、権限不足のリクエストが適切に拒否される
• 正常系と入力不備のレスポンス形式が定義されている
• APIキーやトークンがログやエラー本文に出力されない
• レート制限とペイロード上限が検証されている
• タイムアウト時のクライアント再試行方針が決まっている
• 相関IDでプロキシとiFlowのログを追跡できる
• 証明書と資格情報の更新担当者、期限、手順が登録されている
• iFlowやバックエンド障害時の通知先が決まっている
• APIバージョンの廃止条件と利用者への通知方法が定義されている

API Managementは、APIを公開するための画面設定だけで完結する機能ではありません。API契約、認証、ポリシー、iFlow、バックエンド、監視、変更管理を一つの運用設計として扱うことで、障害の影響範囲を抑え、利用者にも安定した接続先を提供できます。