SAP BTP Cockpit 문제: 다섯 가지 문제와 해결 방법

SAP BTP Cockpit이 오류를 쏟아 낸다면 다섯 가지 중 하나일 가능성이 높습니다. 서비스 키로 받은 401은 거의 언제나 자격 증명이 아니라 OAuth 요청의 문제입니다. Integration Suite의 Internal Server Error는 대개 역할 컬렉션 누락이나 오래된 세션을 뜻합니다. 끊어진 링크는 서브계정이 바뀌기 전에 설정한 부스터에서 옵니다. CAP 데스티네이션 실패는 대개 이름 불일치나 바인딩 누락입니다. 그리고 트라이얼 계정에서 어제까지 돌던 앱은 하룻밤 사이에 데이터베이스를 잃었을 수 있습니다. 이 가이드는 Cloud Foundry 서브계정에서 일하는 개발자와 통합 컨설턴트를 위한 것입니다. 아래 분류표를 보면 무엇을 먼저 확인해야 하는지 알 수 있습니다.

SAP BTP Cockpit에서 빨간 오류 배너를 처음 봤을 때는 제가 뭔가 잘못했다고 생각했습니다. 잘못된 링크, 만료된 세션 같은 것이요.

서너 번째가 되자 저만의 문제가 아니라는 것이 분명해졌습니다.

그 뒤 몇 주 동안 노트를 한 권 두고 뭔가 깨질 때마다 적었습니다. Integration Suite를 열 때 나는 Internal Server Error. 유효해 보이는데도 연결을 거부하는 데스티네이션. 어제는 되다가 오늘은 멈춘 앱. 패턴이 보이기 시작했습니다. 쓸 만하게 문서화된 것은 거의 없었고, Cockpit 자체도 단서를 거의 주지 않습니다.

증상	가장 유력한 원인	먼저 확인할 것
서비스 키로 API를 호출할 때 401 Unauthorized	잘못된 grant type, 토큰 URL 또는 누락된 authorities	토큰을 디코딩해 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 environment는 SAP의 멀티클라우드 기반 위에서 동작하며, 이는 2020년부터 신규 고객의 기본값이었습니다. 이전의 Neo 환경은 보안 및 컴플라이언스 업데이트만 받으며, SAP는 종료 시점을 2028년 12월 31일로 정했습니다. 아래의 거의 모든 문제는 Cloud Foundry의 문제입니다.

오래된 가이드를 읽는 사람을 여전히 헷갈리게 하는 이름 변경이 두 가지 있습니다. 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. Grant type. 대부분의 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. client credentials에서는 토큰에 해당 서비스 인스턴스에 부여된 스코프만 담깁니다. API가 요구하는 역할이 인스턴스에 없으면 토큰은 받지만 API는 여전히 거부합니다. 요청이 아니라 인스턴스 파라미터에서 고치십시오(예를 들어 Integration Suite API 플랜 인스턴스의 역할).
5. Audience. 토큰은 받았는데 API가 거부한다면 토큰을 디코딩해 aud 클레임을 읽으십시오. 호출하는 API와 맞지 않는다면 다른 서비스 인스턴스의 키를 쓰고 있는 것입니다.

Integration Suite를 열면 빨간 “Internal Server Error” 배너가 뜹니다. 로그는 없습니다. 새로고침하고 다른 브라우저로 열어도 결과는 같습니다.

서비스를 한동안 쓰지 않은 뒤에 자주 일어납니다. 아침에 열어 두고 몇 시간 자리를 비웠다가 다시 쓰는 경우입니다. SAP 커뮤니티 스레드와 지식 베이스는 흔한 원인으로 역할 컬렉션 누락과 오래된 세션 두 가지를 짚습니다.

대개 해결되는 방법:

1. 역할 컬렉션을 확인하십시오. 테넌트를 설정하려면 사용자에게 Integration_Provisioner가 필요하고, 그 안에서 일하려면 해당 PI_ 역할 컬렉션(관리자, 통합 개발자, 비즈니스 전문가)이 필요합니다. 서브계정의 Security에서 할당하십시오.
2. 완전히 로그아웃하십시오. 역할 변경은 새로 로그인해야 세션에 반영됩니다. BTP와 Integration Suite 탭을 모두 닫고 로그아웃한 뒤 다시 로그인하십시오.
3. BTP 도메인의 쿠키를 삭제하십시오. 새로 로그인해도 오류가 남아 있다면 해 보십시오. 오래된 세션 쿠키는 세션보다 오래 살아남을 수 있습니다.
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을 북마크하는 것입니다. 깨끗한 브라우저 프로필에서 세션을 하나만 쓰십시오. 링크가 세 번에 한 번씩 실패하면 플랫폼을 믿지 않게 되고 우회 방법을 만들기 시작합니다. 북마크는 가장 값싼 우회 방법입니다. 아직 길을 찾는 중이라면 제 BTP Cockpit 안내가 기본적인 탐색을 다룹니다.

CAP 앱을 배포하고 Cockpit에서 데스티네이션을 구성했는데도 요청은 “destination not found”나 인증 오류로 실패합니다. 데스티네이션은 목록에 있습니다. 앱도 실행 중입니다. 오류 메시지는 쓸 만한 곳을 가리키지 않습니다.

SAP의 CAP 문서는 이것이 어떻게 연결되어야 하는지 분명히 설명합니다. 원격 서비스는 package.json(또는 .cdsrc.json)의 cds.requires 아래에 kind와 함께 선언하고, 데스티네이션 이름은 credentials.destination 아래에 넣습니다. 앱은 또한 Destination 서비스와 XSUAA 양쪽에 바인딩되어 있어야 합니다. 실패의 대부분은 이 사슬의 어딘가가 끊긴 것입니다.

1. 01cds.requires원격 서비스, 그 kind, 데스티네이션 이름을 선언
2. 02Production 프로파일배포 후 데스티네이션 자격 증명을 보유
3. 03서비스 바인딩앱이 Destination과 XSUAA에 바인딩됨
4. 04Cockpit의 데스티네이션cds.requires와 xs-app.json의 이름과 대소문자까지 동일
5. 05원격 서비스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이나 principal propagation은 시나리오에 필요할 때만 쓰십시오
대상에 도달할 수 있는지조차 불확실	앱을 디버깅하기 전에 Cockpit에서 데스티네이션의 “Check Connection”을 사용하십시오

이를 잘 다루는 팀은 앱마다 짧은 데스티네이션 체크리스트를 유지합니다. 설정이 복잡해서가 아닙니다. 이름, 바인딩, OData kind에 대한 잘못된 가정 하나가 조용히 실패하고, 막는 것보다 찾는 데 훨씬 오래 걸리기 때문입니다.

어제는 잘 돌던 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 요청 때문입니다. 흔한 원인은 잘못된 grant type(기술적 접근에는 client_credentials를 사용), 서비스 키와 맞지 않는 토큰 URL, 토큰 호출의 잘못된 헤더입니다.

토큰은 받았는데 API가 여전히 거부한다면 토큰을 디코딩하십시오. aud 클레임이 API와 일치하는지, 스코프가 맞는지 확인하십시오. client credentials에서는 스코프가 서비스 인스턴스에 부여된 authorities에서 나오므로, 누락된 역할은 인스턴스 파라미터에서 고치십시오.

BTP Cockpit에서 Integration Suite를 열 때 Internal Server Error가 나는 원인은 무엇입니까?

대개 역할 컬렉션 누락이나 오래된 세션입니다. 사용자에게 Integration_Provisioner와 필요한 PI_ 역할 컬렉션이 있는지 확인하십시오. 그런 다음 BTP 탭을 모두 닫고 로그아웃했다가 다시 로그인하십시오. 새 역할은 새로 로그인해야 적용되기 때문입니다.

계속되면 BTP 도메인의 쿠키를 삭제하고 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 트라이얼 계정에서 유료 플랜으로는 언제 옮겨야 합니까?

한도 때문에 시간을 잃기 시작할 때입니다. 앱이나 데이터베이스를 하나 이상 돌리거나 데모나 테스트에 안정적인 가동 시간이 필요하다면, 트라이얼은 아끼는 것보다 마찰이 더 큽니다.

얻는 것은 새 기능이 아니라 안정성과 더 선명한 자원 가시성입니다. 프리 티어 플랜이 있는 프로덕티브 계정이 좋은 중간 단계입니다. 나중에 아무것도 다시 만들지 않고 그 플랜을 유료로 업그레이드할 수 있습니다.