本文へスキップ

SAP BTP Cockpitの問題:5つの問題と対処法

SAP BTP Cockpitでは、401トークンエラー、Integration Suiteのエラー、リンク切れ、CAPのデスティネーション失敗、一晩で止まるトライアルアプリという5つの問題が繰り返し起きます。それぞれ、最初に何を確認すべきかを説明します。

デスクトップモニターとノートパソコンの横でコードを入力している開発者の後ろ姿
目次
  1. トリアージ:症状から最初の確認先へ
  2. 2024年から2026年にかけてBTPで変わったこと
  3. 問題1:サービスキーの認証情報で401 Unauthorizedになる
  4. 問題2:Integration Suiteを開くとInternal Server Errorになる
  5. 問題3:ナビゲーションの不具合とリンク切れ
  6. 問題4:CAPアプリでのデスティネーション失敗
  7. 問題5:トライアルと無償枠で、アプリが一晩で止まる
  8. よくある質問

SAP BTP Cockpitでエラーが出るなら、原因は5つのうちのどれかである可能性が高いです。サービスキーでの401は、ほぼ必ず認証情報ではなくOAuthリクエストの問題です。Integration SuiteのInternal Server Errorは、通常、ロールコレクションの不足か古いセッションを意味します。リンク切れは、サブアカウントが変わる前に設定したブースターが原因です。CAPのデスティネーション失敗は、たいてい名前の不一致かバインディングの欠落です。そして、トライアルアカウントで昨日まで動いていたアプリは、一晩でデータベースを失っている可能性があります。本ガイドは、Cloud Foundryサブアカウントで作業する開発者と連携コンサルタント向けです。下のトリアージ表で、最初に何を確認すべきかが分かります。

初めてSAP BTP Cockpitで赤いエラーバナーを見たとき、自分が何か間違えたのだと思いました。リンクが違うのか、セッションが切れたのか。

3、4回目になって、自分だけの問題ではないことがはっきりしました。

それから数週間、私はノートを付けて、何かが壊れるたびに書き留めました。Integration Suiteを開くとInternal Server Errorが出る。有効に見えるのに接続を拒むデスティネーション。昨日は動いて、今日は止まるアプリ。パターンが見えてきました。役に立つ形で文書化されているものはほとんどなく、Cockpit自体もほぼ何も手がかりをくれません。

症状最も可能性の高い原因最初に確認すること
サービスキーでAPIを呼ぶと401 Unauthorizedグラントタイプ、トークンURLの誤り、または権限の不足トークンをデコードして、audとscopeを読む
Integration Suiteを開くとInternal Server Errorロールコレクションの不足、または古いセッションユーザーのロールコレクションを確認し、その後で完全にログアウトする
ブースターやタイルが空白または誤ったページを開くブースターの実行後にサブアカウントが変更された代わりにCockpitのツリーからたどる
CAPアプリ:「destination not found」や認証エラー名前の不一致、バインディングの欠落、ODataのkindの誤りcds.requiresとxs-app.jsonを、Cockpitの名前と照合する
昨日は動いたのに今日は止まる(トライアル)HANA Cloudインスタンスが一晩で停止したSAP HANA Cloud Centralでデータベースインスタンスの状態を確認する

Cloud Foundry、Kyma、ABAP環境は、SAPのマルチクラウド基盤の上で動いています。これは2020年以降、新規顧客のデフォルトです。古いNeo環境に提供されるのはセキュリティとコンプライアンスの更新のみで、SAPは2028年12月31日をサンセットとしています。以下の問題のほぼすべては、Cloud Foundryの問題です。

古いガイドを読むと混乱しやすい名称変更が2つあります。SAP Launchpad serviceは、2023年1月にSAP Build Work Zone, standard editionになりました。また、SAP Buildの拡大に伴って多くのタイルとブースターが作り直されたため、2022年のスクリーンショットは今の画面と一致しないことがよくあります。

RISE with SAPでは、BTPは通常、契約に含まれるクレジットベースのエンタイトルメントとして提供されます。Cockpitは同じです。違うのは、グローバルアカウントを社内の誰が管理しているかです。新しいエンタイトルメントが必要になる前に、その人を探しておいてください。

サービスインスタンスを作成し、サービスキーを生成し、クライアントIDとシークレットをPostmanにコピーし、トークンURLを追加してリクエストを送ります。401。詳細はありません。

シークレットをもう一度コピーします。それでも失敗します。サービスに問題はありません。問題なのはOAuthのフローです。

確認する順番:

  1. グラントタイプ。 BTPのほとんどのサービスAPIへの技術的アクセスには、client_credentialsを使います。Postmanで明示的に設定してください。デフォルトを信用してはいけません。
  2. トークンURL。 サービスキーから取得します。tokenurlを提供するキーもあれば、XSUAAのurlを提供し、そこに/oauth/tokenを付け足すキーもあります。別のサブアカウントのものを流用してはいけません。
  3. ヘッダー。 直接トークンを取得する場合は、Content-Type: application/x-www-form-urlencodedとAuthorization: Basic <base64(clientid:clientsecret)>を送ります。
  4. 権限(authorities)。 クライアントクレデンシャルでは、トークンにはそのサービスインスタンスに付与されたスコープしか含まれません。APIが必要とするロールをインスタンスが持っていなければ、トークンは取得できても、APIは拒否します。直すのはリクエストではなく、インスタンスのパラメータです(たとえば、Integration Suite APIプランのインスタンスにあるロール)。
  5. オーディエンス(audience)。 トークンはあるのにAPIが拒否する場合は、トークンをデコードしてaudクレームを読みます。呼び出すAPIと一致しないなら、別のサービスインスタンスのキーを使っています。

Integration Suiteを開くと、赤い「Internal Server Error」のバナーが表示されます。ログはありません。再読み込みしても、ブラウザを変えても、結果は同じです。

サービスをしばらく使わないまま放置したあとに起きるのが普通です。朝に開き、数時間放置して、あとで再び使う、というパターンです。SAPのコミュニティスレッドとナレッジベースが挙げる原因は、ロールコレクションの不足と、古いセッションの2つです。

たいてい解決する対処:

  1. ロールコレクションを確認する。 テナントをセットアップするにはIntegration_Provisionerが、その中で作業するには関連するPI_ロールコレクション(管理者、インテグレーション開発者、ビジネスエキスパート)がユーザーに必要です。サブアカウントのSecurityで割り当ててください。
  2. 完全にログアウトする。 ロールの変更は、新たにログインして初めてセッションに反映されます。BTPとIntegration Suiteのタブをすべて閉じ、サインアウトして、もう一度サインインしてください。
  3. 再ログインしてもエラーが残る場合は、BTPドメインのCookieを削除してください。 古いセッションCookieは、セッションより長く残ることがあります。
  4. Cockpitのセッションは一つだけにする。 同じサブアカウントで複数のタブやブラウザプロファイルを使うと、このエラーとそっくりなセッション競合が起きます。

本当の問題は可視性です。Cockpitは何が失敗したのかを教えてくれないので、推測するしかなくなります。代わりに、このリストを順番に確認してください。連携プログラムが停滞する理由を広い視野で見るには、SAP Integration Suiteのデリバリー遅延についての私の記事をご覧ください。

「Go to Application」をクリックすると、空白の画面、汎用のランディングページ、意味の分からないリダイレクトが表示されます。

パターンがあります。

  1. ブースターのリンクは、ブースターの実行後にサブアカウントの構成が変わると壊れます。リダイレクト先が、もう存在しない場所を指します。
  2. Integration Suiteのタイルは、動くときもあれば、エラーになるときも、タイムアウトするときもあります。多くは前述のセッションが原因です。
  3. SAP Build Work Zoneのリンクは、サブスクリプションはあるのに、そのサイト用のロールコレクションがユーザーにない場合、「connection denied」と表示されます。
  4. 複数のタブやブラウザプロファイルでは、期限切れのコンテキストでリンクが開きます。

効果があるのは次のことです。Cockpitのツリー(サブアカウント、Services、Instances and Subscriptionsの順)をたどって移動し、Integration Suite、デスティネーション、Work Zoneの直接URLをブックマークします。クリーンなブラウザプロファイルで、セッションは一つだけ使います。リンクが3回に1回失敗するようになると、プラットフォームを信用しなくなり、回避策を作り始めます。ブックマークは、最も手軽な回避策です。まだCockpitの使い方を探している最中なら、基本的なナビゲーションは私のBTP Cockpitのウォークスルーで説明しています。

CAPアプリをデプロイし、Cockpitでデスティネーションを設定したのに、リクエストが「destination not found」や認証エラーで失敗します。デスティネーションは一覧に表示されています。アプリは動いています。エラーメッセージは、役に立つ場所を何も指してくれません。

SAPのCAPドキュメントは、どう接続すべきかを明確に説明しています。リモートサービスは、package.json(または.cdsrc.json)のcds.requiresの下にkind付きで宣言し、デスティネーション名はcredentials.destinationの下に置きます。アプリには、DestinationサービスとXSUAAの両方へのバインディングも必要です。失敗の大半は、この連鎖のどこかが途切れていることです。

CAPのデスティネーションの連鎖名前の誤り、バインディングの欠落、ODataのkindの誤りのどれかで連鎖の一か所が切れますが、エラーはどこなのかをほとんど教えてくれません。
  1. cds.requiresリモートサービス、そのkind、デスティネーション名を宣言
  2. 本番プロファイルデプロイ後にデスティネーションの認証情報を保持
  3. サービスバインディングアプリをDestinationとXSUAAにバインド
  4. Cockpit内のデスティネーションcds.requiresおよびxs-app.jsonと同じ名前、大文字小文字も含めて
  5. リモートサービスV2サービスにはodata-v2、V4にはodata

リクエストがリモートサービスに届く

症状対処
デスティネーションは一覧にあるが、アプリが見つけられないcds.requiresとxs-app.jsonのルートにある名前を、Cockpitのものと一字一句、大文字小文字も含めて比較する
ローカルでは動くが、デプロイ後に失敗する[production]プロファイルに実際にデスティネーションの認証情報があるか、アプリがDestinationとXSUAAにバインドされているかを確認する
リモートのOData V2サービスがエラーを返すV2サービスならkindをodata-v2、V4ならodataに設定する。双方が対応できるなら、V4を使う
UI5アプリはV2が必要だが、CAPサービスはV4@cap-js-community/odata-v2-adapterプラグインを追加する。旧来の@sap/cds-odata-v2-adapter-proxyは非推奨
認証情報が正しいのに認証に失敗するまずOAuth2ClientCredentialsかBasicAuthenticationで試す。SAMLやプリンシパル伝播は、シナリオで必要な場合のみ使う
そもそもターゲットに到達できるか分からないアプリをデバッグする前に、Cockpitでデスティネーションの「Check Connection」を使う

このあたりをうまく扱うチームは、アプリごとに短いデスティネーションのチェックリストを持っています。設定が複雑だからではありません。名前、バインディング、ODataのkindについての思い込みが一つ違うだけで、静かに失敗し、防ぐよりも見つけるほうがはるかに時間がかかるからです。

SAP BTP Cockpitは、何かが壊れたとき、ほとんどフィードバックを返してくれません。デバッグの大半は試行錯誤になります。パターンを知っておけば、何時間も節約できます。

昨日まで動いていたCAPアプリが、今はハングします。エラーはありません。Cockpitでは実行中と表示されます。再起動しても変わりません。

まずデータベースを確認してください。SAP自身のHANA Cloudトライアルのチュートリアルには、無償枠のインスタンスは毎晩停止され、作業する日ごとに再起動が必要だと書かれています。トライアルアカウント自体は、定期的にログインすれば最長90日間続きます。アプリは問題ありません。データベースが眠っているのです。

役に立つこと:

  1. コードのデバッグを始める前に、SAP HANA Cloud CentralでHANA Cloudインスタンスを再起動します。
  2. CLI(cf apps、cf services)を使うと、メモリとサービスの使用状況が分かります。CockpitのUIが示す情報ははるかに少ないです。
  3. 新しいサービスインスタンスを作成する前に、未使用のものを削除します。トライアルのクォータは、一つのアプリ単位ではなくアカウント全体に適用されます。
  4. デモ用とテスト用のワークロードは、別々のサブアカウントに置きます。

複数のアプリとデータベースを安定して動かす必要がある場合や、デモのために安定した稼働が必要な場合は、本番用アカウントに移行してください。本番用アカウントの無償枠プランは、作業内容を失わずに有償へアップグレードできます。トライアルアカウントではそれができません。

認証情報が正しく見えるのに、SAP BTPのサービスキーで401エラーになるのはなぜですか?

ほぼ必ず、認証情報ではなくOAuthリクエストの問題です。よくある原因は、グラントタイプの誤り(技術的アクセスにはclient_credentialsを使います)、サービスキーと一致しないトークンURL、トークン取得時のヘッダーの誤りです。

トークンは取得できるのにAPIが拒否する場合は、デコードしてください。audクレームがAPIと一致しているか、そしてスコープを確認します。クライアントクレデンシャルでは、スコープはサービスインスタンスに付与された権限から決まるため、ロールの不足はインスタンスのパラメータで直します。

BTP CockpitでIntegration Suiteを開くとInternal Server Errorになる原因は何ですか?

多くの場合は、ロールコレクションの不足か古いセッションです。ユーザーにIntegration_Provisionerと、必要なPI_ロールコレクションがあることを確認してください。そのうえで、BTPのタブをすべて閉じ、サインアウトして、もう一度サインインします。新しいロールは、新たにログインして初めて適用されるためです。

解消しない場合は、BTPドメインのCookieを削除し、Cockpitのセッションを一つだけにしてください。同じサブアカウントで複数のタブを開くと、同じエラーが起きます。

Cockpitではデスティネーションが正しく表示されているのに、CAPアプリが接続できないのはなぜですか?

たいていは名前の不一致です。cds.requiresとxs-app.jsonのルートにあるデスティネーション名は、大文字小文字も含めて、Cockpitと完全に一致している必要があります。

名前が正しいなら、アプリがDestinationサービスとXSUAAの両方にバインドされているか、[production]プロファイルに認証情報があるか、kindがリモートサービスに合っているか(V2ならodata-v2、V4ならodata)を確認してください。ターゲットに到達できるかは、Cockpitの「Check Connection」で確かめられます。

SAP BTPのトライアルアプリが一晩で動かなくなるのはなぜですか?

トライアルと無償枠のプランでは、リソースを節約するため、SAP HANA Cloudインスタンスが毎晩停止されます。アプリは動き続けますが、データベースに到達できません。作業する日ごとに、前もってSAP HANA Cloud Centralでインスタンスを再起動してください。

トライアルのクォータはCockpitでは見えにくいため、cf appsとcf servicesでメモリとサービスの使用状況を確認します。新しいインスタンスを作る前に、未使用のものを削除してください。

ブースターやタイルの中のリンクが空白のページになるのはなぜですか?

ブースターのリンクは、ブースターの実行後にサブアカウントの構成が変わると壊れます。リダイレクト先が、もう存在しない、あるいは完全には設定されていない場所を指しています。

代わりにCockpitのツリーからたどり、Integration Suite、デスティネーション、SAP Build Work Zoneの直接URLをブックマークしてください。毎日使うものについては、ブースターが生成したナビゲーションに頼らないでください。

BTPのトライアルアカウントから有償プランに移行すべきなのは、どんなときですか?

制限のせいで時間を取られるようになったときです。複数のアプリやデータベースを動かす場合、あるいはデモやテストのために安定した稼働が必要な場合、トライアルは節約できる以上の手間を生みます。

主な利点は新機能ではなく、安定性とリソースの見えやすさです。無償枠プランを使う本番用アカウントは、中間のステップとして適しています。あとで作り直すことなく、そのプランを有償にアップグレードできます。

Noel D'Costa

執筆者

Noel D'Costa

航空、政府、金融、小売、製造の各分野で、SAPとOracleのERPプログラムに25年携わってきました。財務出身です。経営陣とともに変革の範囲を誠実に定め、難航するプログラムを立て直し、本稼働後の最初の1年を乗り越えるシステムを構築します。

次のステップ

いまERPプログラムを進めていますか?

この記事が、いま進行中のプログラムに関わる内容だったなら、社内でさらに1週間分析を重ねるよりも、30分の対話のほうが多くの場合ずっと前に進めます。