관리 포털 가이드
Red Hat 3scale API Management와 관련된 측면을 관리합니다.
초록
머리말 링크 복사링크가 클립보드에 복사되었습니다!
이 안내서는 관리 포털에서 사용 가능한 기능을 사용하여 3scale 설치를 관리하는 데 도움이 됩니다.
I 부. 계정 설정 링크 복사링크가 클립보드에 복사되었습니다!
1장. 계정 구성 링크 복사링크가 클립보드에 복사되었습니다!
계정을 생성한 후 회사에 대한 기본 정보를 업데이트합니다. 위치를 설정하고 연락처 정보를 추가하십시오.
The account view is only visible to administrators, not to members.
1.1. 회사 정보 추가 링크 복사링크가 클립보드에 복사되었습니다!
새 계정을 생성한 후에는 다음 단계를 통해 회사 정보를 추가합니다.
- 상단 탐색 모음 오른쪽에 있는 톱니바 아이콘을 클릭합니다. 개요 창이 표시됩니다.
- 계정 세부 정보 제목 옆에 있는 편집 링크를 클릭합니다.
- 계정 정보를 입력합니다.
여기에서 지정한 주소에는 다음 두 가지 전략이 있습니다.
- 유료 계획에 있는 경우, 당사는 청구 목적으로 이 주소를 사용합니다.
- 청구 및 결제 모듈을 사용하는 경우, 이 주소는 사용자가 송장에 표시되는 주소입니다.
1.2. 원하는 시간대를 선택합니다. 링크 복사링크가 클립보드에 복사되었습니다!
동일한 페이지에서 모든 시스템 디스플레이에서 사용할 시간대를 선택할 수도 있습니다. 이 설정은 분석 그래프에 영향을 미칩니다. 그러나 청구 주기 계산은 UTC 시간에 따라 수행됩니다.
2장. 3scale 관리 포털용 Red Hat Single Sign On 링크 복사링크가 클립보드에 복사되었습니다!
이 안내서에서는 Red Hat 3scale API Management Admin Portal을 통해 RH-SSO(Red Hat Single Sign-On)를 구성하고 사용하는 방법에 대한 정보를 제공합니다.
2.1. RH-SSO 또는 Auth0 멤버 인증 활성화 링크 복사링크가 클립보드에 복사되었습니다!
3scale은 멤버 및 관리자를 위해 (SS0)에서 단일 기호 인증을 지원합니다.
3scale 관리 포털은 각각 여러 ID 중개 및 멤버 페더레이션 옵션을 지원하는 다음 SSO 공급자를 지원합니다.
여러 SSO 멤버 인증 유형을 활성화할 수 있습니다.
RH-SSO 또는 Auth0에 추가된 사용자만 SSO를 통해 3scale 관리 포털에 액세스할 수 있습니다. 역할 또는 사용자 그룹에 의한 액세스를 추가로 제한하려면 RH-SSO 또는 Auth0 지원 포털에서 해당 단계를 단계별로 참조해야 합니다.
선택한 공급자를 통해 SSO를 설정한 후에는 3scale 관리 포털에서 구성하고 활성화해야 합니다.
2.1.1. rh-SSO 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 문서의 개발자 포털 인증 섹션에 설명된 대로 구성된 RH-SSO 인스턴스 및 영역입니다.
2.1.2. Auth0 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- Auth0 서브스크립션 및 계정
2.1.3. RH-SSO 활성화 링크 복사링크가 클립보드에 복사되었습니다!
관리자로 3scale 관리 포털의 다음 단계를 수행하여 RH-SSO 또는 Auth0을 활성화합니다.
- 사전 요구 사항에 강조된 기본 SSO 공급자가 올바르게 구성되었는지 확인합니다.
계정 설정에서 SSO 통합으로 이동합니다.
- 페이지 오른쪽 상단에 있는 톱니바퀴 아이콘을 클릭합니다.
- Account Settings (gear icon) > Users > SSO Integration으로 이동하여 New SSO Integration 을 클릭합니다.
- 드롭다운 목록에서 SSO 공급자를 선택합니다.
SSO를 구성할 때 제공된 필요한 정보를 입력합니다.
- 클라이언트
- 클라이언트 시크릿
- 영역 또는 사이트
- 인증 공급자 생성을클릭합니다.
테스트 중에 콜백 URL 불일치가 발생하면 오류 메시지에 표시된 콜백 URL을 Auth0 허용 콜백 URL에 추가합니다.
2.2. 3scale에서 RH-SSO 사용 링크 복사링크가 클립보드에 복사되었습니다!
SSO를 구성한 경우, 구성원은 연결된 IdM(Identity Provider)에서 계정 자격 증명을 사용하여 로그인할 수 있습니다.
다음 단계에 따라 SSO를 사용하여 3scale 관리 포털에 로그인합니다.
3scale 로그인 페이지로 이동합니다.
https://<organization>-admin.3scale.net/p/login- IdP로 3scale 인증
- 필요한 경우 필요한 정보를 입력하여 등록하십시오.
성공적으로 등록하면 API 공급자 조직 아래에 멤버 계정이 있고 자동으로 로그인됩니다.
2.3. 3scale 로그인을 RH-SSO 옵션으로 리디렉션 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 RH-SSO를 통해 IdM(Identity Provider) 로그인 창으로의 리디렉션에 대해 설명합니다. 3scale API Management 관리자는 3scale 계정에 선택적 SSO(Single Sign-On) 로그인 페이지를 통해 액세스할 수 있도록 하려면 다음 단계를 완료합니다.
2.3.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 3scale 2.7
- 개발자 포털 문서의 RH-SSO 구성 섹션에 설명된 대로 구성된 RH-SSO 인스턴스 및 영역.
RH-SSO를 3scale과 통합하려면 먼저 작동하는 RH-SSO 인스턴스가 있어야 합니다. 설치 지침은 RH-SSO 문서( RH-SSO 7.2 설치 )를 참조하십시오.
2.3.2. 필수 단계 링크 복사링크가 클립보드에 복사되었습니다!
- 3scale 관리 포털의 3scale 관리 포털 섹션의 Red Hat Single Sign-On에 따라 RH-SSO 설정에 대한 지침을 액세스하고 따릅니다.
RH-SSO 관리자에게 보안 로그를 위해 RH-SSO 내의 리디렉션을 기반으로 하는 3scale URL을 제공합니다. 다음 URL 형식을 사용합니다.
https://<organization>-admin.3scale.net/auth/<system_name>/bounce<system_name>은 관리 포털의 SSO 통합 세부 정보 페이지를 통해 가져올 수 있습니다.https://<organization>.3scale.net/p/admin/account/authentication_providers/<ID>참고: & lt;ID& gt;는 RH-SSO 통합을 식별합니다.
이전 단계에서 얻은 다음 SSO 통합 세부 정보가 표시됩니다.
callback URL
https://<organization>.3scale.net/auth/keycloak_0123456aaaaa/callback- 여기서 keycloak_0123456aaaa 는 시스템 이름이고, URL에서 사용됩니다.
- RH-SSO의 새 URL 주소로 이동하여 3scale 계정에 안전하게 로그인합니다.
3장. 사용자 및 권한 관리 링크 복사링크가 클립보드에 복사되었습니다!
초대 기능은 Pro 및 Enterprise 고객만 사용할 수 있습니다.
API의 워크로드를 공유하려면 조직의 팀 구성원을 초대하여 3scale 관리자 포털에 액세스할 수 있습니다. 아래 지침은 3scale 관리 포털에 대한 액세스 권한을 하나 이상의 팀 구성원에게 제공하는 방법을 설명합니다.
사용자와 함께, 귀하의 팀 구성원을 참조합니다. 3scale 관리 포털에는 다음 두 가지 유형의 사용자가 있습니다.
- 관리자: 모든 영역 및 서비스에 대한 전체 액세스 권한을 가지며 다른 멤버를 초대할 수 있습니다(프로필에서 허용하는 경우).
- 멤버: 제품 영역(예: DestinationRule, 개발자 포털) 및 엔터프라이즈 고객인 경우 서비스에 대한 액세스가 제한됩니까.
SSO(Single Sign-On) 통합을 통해 새 3scale 사용자를 생성하는 경우 이 사용자는 기본적으로 SSO 토큰 콘텐츠에 관계없이 member 역할을 갖습니다. 3scale은 해당 역할을 SSO 역할에 매핑하지 않습니다.
3.2. 초대 보내기 링크 복사링크가 클립보드에 복사되었습니다!
사용자 목록에서 새 팀 멤버를 초대할 수 있습니다. 초대를 보내려면:
- 목록 오른쪽 상단에 있는 Invite 사용자 링크를 클릭합니다.
- 초대할 사용자의 이메일 주소를 입력하고 보내기 를 클릭합니다.
-
전송 확인으로 창의 오른쪽 상단에 메시지가 표시됩니다:
초대가 성공적으로 전송되었습니다.
입력한 주소로 초대 이메일이 전송됩니다. 이메일이 도착하지 않으면 수신자의 이메일 계정에 스팸으로 표시되지 않았는지 확인하십시오.
또한 사용자 > 초대에서 전송된 초대의 목록 및 상태를 확인할 수 있습니다.
3.3. 초대 수락 링크 복사링크가 클립보드에 복사되었습니다!
새 관리자 또는 멤버는 초대 이메일의 링크를 클릭하고 프로세스를 완료하려면 양식을 작성해야 합니다. 양식을 제출하면 해당 계정이 활성화됩니다.
3.4. 새로운 사용자에게 권한을 부여 링크 복사링크가 클립보드에 복사되었습니다!
팀 멤버에게 제공할 수 있는 두 가지 주요 유형의 권리가 있습니다.
- 영역별: 분석, 청구 또는 개발자 관리 등.
- 서비스별: 모든 서비스 중 멤버에게 액세스할 수 있는 서비스 제공 참고: 이 기능은 엔터프라이즈 고객만 사용할 수 있습니다.
새 사용자 권한을 부여하려면 사용자 메뉴에서 해당 권한을 선택하고 편집 을 클릭하여 새 사용자를 편집합니다. 다음과 같은 사용자 역할이 있습니다.
- 관리자 권한을 변경하면 관리자 포털을 완전히 제어할 수 있습니다.
멤버에 대한 권한을 변경하면 팀 멤버가 액세스할 수 있는 영역과 서비스를 선택할 수 있습니다.
- 멤버로 , 해당 지역과 관련된 사용 가능한 모든 서비스를 나열하려면 영역을 선택합니다.
관리 포털의 특정 영역에 대한 액세스 권한을 부여하면 구성원에게 동등한 API에만 액세스할 수 있습니다.
- 개발자 계정: 계정 관리 API에 대한 액세스 권한 부여
- analytics: NSX API에 대한 액세스 권한 부여
- 청구: Azure API에 대한 액세스 권한 부여
4장. 알림 링크 복사링크가 클립보드에 복사되었습니다!
알림은 Red Hat 3scale API Management 사용자 인터페이스 및 3scale API와의 상호 작용에서 시작됩니다. 개발자는 관리자 및 기타 멤버 및 3scale에 대한 평가를 트리거할 수 있습니다. 액세스 권한이 있는 API에 대한 API 알림만 받습니다.
4.1. 알림 유형 링크 복사링크가 클립보드에 복사되었습니다!
다양한 유형의 알림이 있습니다.
- 계정
- 청구
- 애플리케이션
- 서비스 서브스크립션
- 사용 경고
4.2. 가시성 링크 복사링크가 클립보드에 복사되었습니다!
admin 사용자는 모든 알림에 액세스할 수 있습니다.
멤버 사용자는 액세스 권한이 부여된 영역의 알림에만 액세스할 수 있습니다. 예를 들어, 멤버는 청구 섹션에 액세스할 수 있는 경우에만 청구와 관련된 알림에 액세스할 수 있습니다.
엔터프라이즈 계정 의 경우 멤버 사용자는 액세스 권한이 부여된 서비스 활동에 대한 알림만 액세스할 수 있습니다.
4.3. 이메일별 알림 구독 링크 복사링크가 클립보드에 복사되었습니다!
서브스크립션은 개인 정보이며 해당 알림을 수신하는 사용자만 수정할 수 있습니다. 서브스크립션을 편집하려면 다음을 수행합니다.
- 내비게이션 바의 계정 설정 (gear icon)으로 이동합니다. > 개인 > Notification preferences.
- 수신하려는 알림을 선택합니다.
- Update Notification preferences를 클릭합니다.
4.4. 웹 알림 링크 복사링크가 클립보드에 복사되었습니다!
이메일 알림 외에도 대시보드에서 마지막 활동에 대한 정보를 찾을 수 있습니다.
5장. 개인 설정 링크 복사링크가 클립보드에 복사되었습니다!
개인 설정에서 기본 설정을 팀 구성원으로 편집할 수 있습니다. 관리자인 경우 계정 기본 설정을 편집할 수도 있습니다. 계정 구성 튜토리얼을 확인하십시오.
개인 설정을 편집하려면 다음을 수행합니다.
- 탐색 모음에서 별점 아이콘을 클릭합니다.
왼쪽 패널에서 개인 으로 이동합니다. 여기에서 편집할 수 있는 세 가지 유형의 설정이 있습니다.
- 개인 정보: 이름, 이메일, 비밀번호 등
- 토큰: 3scale API(임시 관리, 계정 관리, analytics)에 대해 인증하기 위해 액세스 토큰을 생성하고 ActiveDocs(대화형 문서)를 사용하여 사용해 보십시오. 3scale 토큰 에 대해 자세히 알아보십시오.
- notification preferences : 수신하려는 알림을 선택합니다. 참고: 엔터프라이즈 고객인 경우, 멤버인 경우 지역 및 서비스에 따라 필터링됩니다. 즉, 액세스 권한이 부여된 영역 및 서비스에 대한 알림만 구독할 수 있습니다. 알림 기본 설정에 대한 자세한 내용은 여기에서 확인하십시오.
6장. 토큰 링크 복사링크가 클립보드에 복사되었습니다!
이 튜토리얼에는 3scale 토큰에 대한 정보가 포함되어 있습니다. 즉, 해당 토큰의 정의, 작동 방식 및 생성 방법이 포함되어 있습니다.
3scale에는 두 가지 유형의 토큰(사용자가 생성한 액세스 토큰)과 서비스 토큰 (3scale에서 새 서비스를 생성할 때 자동으로 생성됨)이 있습니다.
6.1. 액세스 토큰 링크 복사링크가 클립보드에 복사되었습니다!
액세스 토큰을 사용하면 API 공급자 관리자 및 멤버가 3scale API(임의, 계정 관리, analytics)에 대해 인증하고 ActiveDocs(대화형 문서)를 사용하여 해당 API를 사용해 볼 수 있습니다.
액세스 토큰은 읽기 및 쓰기 액세스 또는 읽기 전용을 제공할 수 있습니다.
고려해야 할 중요한 사항은 액세스 토큰이 작동하는 방식이며, 이는 해당 멤버의 권한에 따라 이루어집니다. 관리자는 3scale API 모두에 대해 인증하기 위한 토큰을 생성할 수 있습니다. 멤버는 관리 포털의 다른 부분에 액세스할 수 있는 권한으로 제한됩니다. 예를 들어 멤버가 LimitRangeing 영역에 액세스할 수 없는 경우Membering API에 대해 인증하기 위해 토큰을 만들 수 없습니다.
6.2. 액세스 토큰 생성 링크 복사링크가 클립보드에 복사되었습니다!
액세스 토큰은 토큰 페이지에서 생성할 수 있습니다. 토큰을 생성하려면 다음 단계를 따르십시오.
- 탐색 모음에서 별점 아이콘을 클릭합니다.
- 개인 > 토큰으로 이동합니다.
- 액세스 토큰 추가를 클릭합니다.
- 이름을 지정하고 하나 이상의 범위를 선택하고 토큰에 대한 권한을 선택합니다.
- 새 토큰을 저장하려면 액세스 토큰 만들기를 클릭합니다.
멤버인 경우 계정 관리자가 액세스할 수 있는 API만 모든 API가 표시되지 않을 수 있습니다.
필요한 만큼의 액세스 토큰을 생성할 수 있습니다. 보안상의 이유로 토큰이 3scale에 저장되지 않습니다. 새 토큰을 생성할 때 토큰을 저장하라는 경고 메시지가 표시되므로 이 토큰을 사용하여 3scale API에 요청할 수 있습니다.
토큰이 손실되면 삭제하는 것이 좋습니다.이를 삭제하면 비활성화되고 유효하지 않게 렌더링됩니다. 새 토큰을 만드는 것이 좋습니다.
6.3. 액세스 토큰 사용 링크 복사링크가 클립보드에 복사되었습니다!
액세스 토큰을 사용하여 3scale API를 호출할 때 액세스 권한이 있는 서비스에 의해 결과가 필터링됩니다.
예를 들어 APIcast 자체 관리를 배포할 때 APIcast API 게이트웨이가 계정 관리 API를 사용하여 서비스 구성을 가져올 수 있도록 액세스 토큰이 필요합니다.
이 작동 방식은 조직이 3scale에서 3scale 서비스를 설정하는 경우이며, 멤버로 2 및 3에는 액세스할 수 있지만 계정 관리 API에 액세스할 수도 있습니다. 또한 토큰을 생성하고 계정 관리 API에 요청할 때 서비스 1을 사용하는 애플리케이션만 받습니다.
동일한 예제에 따라 계정 관리 API에 액세스할 수 있지만 제로 서비스에 액세스할 수 있는 경우 호출을 수행할 때 "액세스 거부됨" 오류가 발생합니다.
6.3.1. 서비스 토큰 링크 복사링크가 클립보드에 복사되었습니다!
서비스 토큰은 3scale Service Management API에 대해 인증하는 데 사용됩니다. 서비스 토큰은 3scale에서 새 서비스를 생성할 때 자동으로 생성되며 서비스당 고유합니다. 이는 3scale 계정 사용자 간에 공유됩니다.
Admin Portal의 Dashboard: 계정 설정(gear icon) > 개인 > 토큰에서 사용자가 액세스할 수 있는 서비스의 서비스 토큰 을 찾을 수 있습니다.
II 부. 멀티 테넌시 링크 복사링크가 클립보드에 복사되었습니다!
7장. 멀티 테넌시 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat 3scale API Management를 사용하면 단일 온프레미스 배포에 3scale 계정의 여러 개의 독립적인 인스턴스가 존재할 수 있습니다. 계정은 서로 독립적으로 작동하며 서로 정보를 공유할 수 없습니다.
7.1. 마스터 관리자 포털 링크 복사링크가 클립보드에 복사되었습니다!
마스터 관리자는 마스터 관리 포털 및 API 엔드포인트를 통해 Red Hat 3scale API Management 계정을 모니터링하고 관리합니다. 표준 관리 포털 과 마찬가지로 마스터 관리 포털에는 배포의 모든 계정에 대한 정보가 포함되어 있으며 고유한 계정 페이지를 통해 계정 및 사용자를 관리할 수 있습니다.
계정 관리자 작업에 대한 자세한 내용은 계정 설정 가이드를 참조하십시오.
7.1.1. 마스터 관리 포털에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
마스터 관리 포털에 액세스하려면 온-프레미스 설치 프로세스 중에 마스터 관리 포털에 대해 구체적으로 정의된 인증 정보 및 URL을 사용해야 합니다.
마스터 관리 포털 URL은 ECDHETER _NAME (기본적으로 템플릿에서master ) 및 WILDCARD_DOMAIN 으로 구성됩니다.
<MASTER_NAME>.<WILDCARD_DOMAIN>
Master 플래그로 마스터 관리 포털을 확인할 수 있습니다.
7.1.2. 마스터 관리 포털을 통해 계정 추가 링크 복사링크가 클립보드에 복사되었습니다!
마스터 관리자 포털을 통해 계정을 추가하려면 다음 단계를 따르십시오.
- 마스터 관리 포털에 로그인합니다.
- 계정으로 이동합니다.
- 생성을 클릭합니다.
사용자에게 필요한 정보를 표시합니다.
- 사용자 이름
- 이메일
- 암호
- 비밀번호 확인
조직에 필요한 정보를 표시합니다.
- 조직/그룹 이름
- 생성을 클릭합니다.
이러한 단계를 수행한 후 Red Hat 3scale은 조직/그룹 이름 필드를 기반으로 계정에 대한 계정 하위 도메인을 생성합니다. 또한 생성한 계정의 세부 정보가 포함된 페이지를 볼 수 있습니다.
7.1.3. 마스터 관리 포털을 사용하여 단일 게이트웨이 생성 링크 복사링크가 클립보드에 복사되었습니다!
마스터 관리 포털을 사용하면 THREESCALE_PORTAL_ENDPOINT 환경 변수를 구성하여 모든 테넌트에 대한 단일 게이트웨이를 생성할 수 있습니다. 이는 OpenShift 템플릿과 함께 배포된 기본 apicast 및 게이트웨이가 이러한 방식으로 구성된 SaaS(Hosteded 3scale)의 호스팅 APIcast와 유사합니다.
apicast- production
마스터 관리 포털을 사용하여 단일 게이트웨이를 생성하려면 다음 단계를 따르십시오.
-
3scale 프로젝트에서
system-master-apicast시크릿에서 ACCESS_TOKEN의 값을 가져옵니다. 또는 마스터 관리 포털에서 새 액세스 토큰을 생성할 수 있습니다. APIcast를 배포할 때 다음 명령을 사용합니다.
THREESCALE_PORTAL_ENDPOINT="https://<ACCESS_TOKEN>@<public url to master admin portal>/master/api/proxy/configs"-
URL의 끝은
/master/api/proxy/configs와 같습니다. 이는 master 가 기본/admin/api/services.json과 비교하여 다른 엔드포인트에구성을 보유하고 있기 때문입니다.
-
URL의 끝은
7.2. 계정 관리 링크 복사링크가 클립보드에 복사되었습니다!
마스터 관리 포털 또는 API 호출을 통해 계정을 관리할 수 있습니다.
7.2.1. 마스터 관리 포털을 통해 계정 관리 링크 복사링크가 클립보드에 복사되었습니다!
마스터 관리 포털을 통해 계정을 관리하려면 다음을 수행해야 합니다.
- 마스터 관리 포털에 로그인합니다.
- 계정 페이지로 이동합니다.
- 관리할 그룹 또는 조직을 선택합니다.
마스터 관리 포털의 계정 페이지에서 admin 테넌트 계정을 가장하거나 테넌트 계정을 일시 중단하는 등의 관리 작업을 수행할 수 있습니다. 다음 계정 속성을 관리할 수도 있습니다.
- 애플리케이션
- 사용자
- 초대
- 그룹 멤버십
- 조직/그룹 이름
7.2.1.1. 추가 정보 링크 복사링크가 클립보드에 복사되었습니다!
- 테넌트 계정에 대한 자세한 내용은 3scale 용어집 을 참조하십시오.
7.2.2. API 호출을 통해 계정 관리 링크 복사링크가 클립보드에 복사되었습니다!
Master Admin API 호출을 통해 계정을 관리할 수 있습니다. 이러한 호출에 대한 정보는 마스터 관리 포털의 오른쪽 상단에 있는 질문 표시(?) 아이콘을 클릭한 다음 3scale API Docs 를 선택하여 마스터 API 섹션을 참조하십시오.
7.3. 멀티 테넌시 하위 도메인 이해 링크 복사링크가 클립보드에 복사되었습니다!
동일한 OpenShift 클러스터 도메인 아래에 있는 여러 계정의 결과로 개별 계정 이름은 OpenShift 클러스터 도메인 이름을 하위 도메인으로 추가합니다. 예를 들어 example.com 도메인이 있는 클러스터에서 user 라는 계정 경로는 다음과 같이 표시됩니다.
user.example.com
표준 다중 테넌트 배포에는 다음이 포함됩니다.
- 마스터 관리자
ECDHETER
_NAME 매개변수로 정의된 마스터관리 포털 경로:<MASTER_NAME>.<WILDCARD_DOMAIN>- 계정 관리자
TENANT_NAME매개변수로 정의된 계정 관리자 포털 경로:<TENANT_NAME>-admin.<WILDCARD_DOMAIN>계정의 개발자 포털 경로:
<TENANT_NAME>.<WILDCARD_DOMAIN>프로덕션 및 스테이징 내장 APIcast 게이트웨이의 경로:
<API_NAME>-<TENANT_NAME>-apicast-staging.<WILDCARD_DOMAIN> <API_NAME>-<TENANT_NAME>-apicast-production.<WILDCARD_DOMAIN>This example illustrates the output users and routes of a standard multitenant deployment of 3scale:---- --> Deploying template "3scale-project/3scale-api-management" for "amp.yml" to project project3scale API Management --------- 3scale API Management main systemLogin on https://user-admin.3scale-project.example.com as admin/xXxXyz123 ... * With parameters: * ADMIN_PASSWORD=xXxXyz123 # generated * ADMIN_USERNAME=admin * TENANT_NAME=user ... * MASTER_NAME=master * MASTER_USER=master * MASTER_PASSWORD=xXxXyz123 # generated ... --> Success Access your application via route 'user-admin.3scale-project.example.com' Access your application via route 'master-admin.3scale-project.example.com' Access your application via route 'backend-user.3scale-project.example.com' Access your application via route 'user.3scale-project.example.com' Access your application via route 'api-user-apicast-staging.3scale-project.example.com' Access your application via route 'api-user-apicast-production.3scale-project.example.com' Access your application via route 'apicast-wildcard.3scale-project.example.com' ... ----
마스터 관리자가 추가한 추가 계정에는 해당 이름에 따라 하위 도메인이 할당됩니다.
7.4. 테넌트 계정 삭제 링크 복사링크가 클립보드에 복사되었습니다!
7.4.1. 관리 포털을 통해 계정 삭제 링크 복사링크가 클립보드에 복사되었습니다!
이 절차를 통해 계정은 삭제 예정되어 있으며 15 일 후에 삭제됩니다. 이 기간 동안 삭제 예정되어 있습니다.
- 사용자는 계정에 로그인할 수 없습니다.
- 계정을 편집할 수 없지만 마스터는 승인된 상태로 계정을 다시 시작할 수 있습니다.
또한 실제 삭제와 유사하게 테넌트 도메인(admin 도메인 및 개발자 포털)을 사용할 수 없습니다.
사전 요구 사항
절차
- 계정 목록을 보려면 계정으로 이동합니다.
- 삭제할 계정을 클릭합니다.
- 계정 이름 옆에 있는 편집 을 클릭합니다.
- 계정 세부 정보 페이지에서 삭제 아이콘을 클릭합니다.
- 삭제를 확인합니다.
7.4.2. 콘솔을 통해 테넌트 삭제 링크 복사링크가 클립보드에 복사되었습니다!
즉시 영향을 미치는 계정을 삭제하려면 콘솔을 통해 계정을 삭제할 수 있습니다.
다음 명령으로 콘솔을 엽니다.
oc rsh -c system-master "$(oc get pods --selector deploymentconfig=system-app -o name)" bundle exec rails console다음 줄로 즉시 삭제하십시오.
tenant = Account.find(PROVIDER_ID) tenant.schedule_for_deletion! DeleteAccountHierarchyWorker.perform_later(tenant)각 행이 작동하는 방법은 다음과 같습니다.
-
1행: 계정을 찾아서 변수
테넌트에 저장합니다. - 2행: 삭제 계정을 예약합니다. 이는 관리자 포털을 통해 삭제를 예약하지 않은 경우에만 필요합니다.
- 3 줄은 삭제할 계정을 예약했거나 일시 중지된 경우에만 백그라운드 프로세스에서 테넌트를 삭제합니다. 계정이 승인된 상태인 경우 삭제는 처리되지 않습니다.
-
1행: 계정을 찾아서 변수
7.5. 테넌트 계정 재시작 링크 복사링크가 클립보드에 복사되었습니다!
테넌트 계정을 다시 시작하면 삭제 예약된 계정을 복원해야 합니다. 삭제하도록 예약한 후 최대 15일 후에 테넌트 계정을 다시 시작할 수 있습니다.
계정을 다시 시작한 후 다음을 수행하십시오.
- 이전 앱은 모두 존재합니다.
- 모든 과거의 통계가 남아 있습니다.
- 유효해야 하는 모든 토큰이 다시 유효합니다.
- 앱의 인증을 다시 시작합니다.
사전 요구 사항
- 마스터 관리자 계정에 로그인합니다.
절차
- 계정 목록을 보려면 계정으로 이동합니다.
- 재개할 계정을 클릭합니다.
- 계정 세부 정보에서 다시 시작을 클릭합니다.
- 확인 을 클릭하여 계정을 다시 시작하려는지 확인합니다.Click OK to confirm you want to resume the account.
III 부. 서비스 검색 링크 복사링크가 클립보드에 복사되었습니다!
8장. 서비스 검색 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat 3scale API Management의 서비스 검색 기능을 사용하면 OpenShift에서 서비스를 가져올 수 있습니다.
8.1. 서비스 검색 정보 링크 복사링크가 클립보드에 복사되었습니다!
Service Discovery를 사용하면 동일한 OpenShift 클러스터에서 실행 중인 검색 가능한 API 서비스를 스캔하고 관련 API 정의를 3scale로 자동으로 가져올 수 있습니다.
API 통합 및 Open API Specification을 언제든지 업데이트한 후 클러스터와 다시 동기화할 수도 있습니다.
Service Discovery는 다음과 같은 기능을 제공합니다.
- 클러스터 API를 사용하여 검색에 올바르게 주석이 달린 서비스를 쿼리합니다.
- 클러스터 내부의 내부 끝점을 사용하여 서비스에 액세스하도록 3scale을 구성합니다.
- Open API Specification (Swagger) 버전 2.0을 3scale ActiveDocs로 가져옵니다.
- OpenShift 및 Red Hat Single Sign-On(RH SSO) 권한 부여 흐름을 지원합니다.
- Fuse 버전 7.2부터 Red Hat Fuse와 함께 작동합니다.
검색 가능한 서비스를 가져오면 해당 네임스페이스가 유지됩니다.
- 온프레미스 설치 시 3scale의 경우 3scale API 공급자에 자체 네임스페이스 및 서비스가 있을 수 있습니다. 검색된 서비스는 3scale 기존 및 네이티브 서비스와 공존할 수 있습니다.
- Fuse 검색 가능 서비스는 Fuse 프로덕션 네임스페이스에 배포됩니다.
8.1.1. 검색 가능한 서비스에 대한 기준 링크 복사링크가 클립보드에 복사되었습니다!
3scale 서비스 검색에서 찾을 수 있도록 API 서비스가 다음 기준을 충족해야 합니다.
API 사양의
Content-Type헤더는 다음 값 중 하나여야 합니다.-
application/swagger+json -
application/vnd.oai.openapi+json -
application/json
-
OpenShift Service Object YAML 정의에는 다음 메타데이터가 포함되어 있습니다.
-
discovery.3scale.net레이블: (필수) "true"로 설정합니다. 3scale은 선택기 정의를 실행하여 검색이 필요한 모든 서비스를 찾을 때 이 레이블을 사용합니다. 다음 주석은 다음과 같습니다.
discovery.3scale.net/discovery-version: (선택 사항) 3scale 검색 프로세스의 버전입니다.discovery.3scale.net/scheme: (필수) 서비스가 호스팅되는 URL의 스키마 부분입니다. 가능한 값은 "http" 또는 "https"입니다.discovery.3scale.net/port: (필수) 클러스터 내의 서비스의 포트 번호입니다.discovery.3scale.net/path: (선택 사항) 서비스가 호스팅되는 URL의 상대 기본 경로입니다. 경로가 root인 "/"에 있을 때 이 주석을 생략할 수 있습니다.discovery.3scale.net/description-path: 서비스에 대한 OpenAPI 서비스 설명 문서의 경로입니다.예를 들어 다음과 같습니다.
metadata: annotations: discovery.3scale.net/scheme: "https" discovery.3scale.net/port: '8081' discovery.3scale.net/path: "/api" discovery.3scale.net/description-path: "/api/openapi/json" labels: discovery.3scale.net: "true" name: i-task-api namespace: fuse
-
관리 권한이 있는 OpenShift 사용자인 경우 OpenShift 콘솔에서 API 서비스의 YAML 파일을 볼 수 있습니다.
- Applications> Services 를 선택합니다.
-
i-task-api와 같은 서비스를 선택하여 세부 정보 페이지를 엽니다. - Actions> Edit YAML 을 선택하여 YAML 파일을 엽니다.
- 보기를 완료하면 취소 를 선택합니다.
8.2. 서비스 검색 구성 링크 복사링크가 클립보드에 복사되었습니다!
3scale 관리자는 OAuth 서버를 사용하거나 사용하지 않고 서비스 검색을 구성할 수 있습니다.
사전 요구 사항
- 3scale 2.7을 OpenShift 클러스터에 배포해야 합니다(버전 3.11 이상).
- OpenShift에 3scale을 배포하려면 3scale-amp-openshift-templates 를 사용해야 합니다.
- Service Discovery 3scale을 사용하려는 3scale 사용자는 OpenShift 클러스터에 액세스할 수 있어야 합니다.
8.2.1. OAuth 서버로 구성 링크 복사링크가 클립보드에 복사되었습니다!
OAuth(Open Authorization) 서버를 사용하여 3scale Service Discovery를 구성하는 경우 사용자가 3scale에 서명할 때 이러한 상황이 발생합니다.
- 사용자가 OAuth 서버로 리디렉션됩니다.
- 사용자가 OAuth 서버에 아직 로그인하지 않은 경우 사용자에게 로그인하라는 메시지가 표시됩니다.
- 사용자가 SSO를 사용하여 3scale 서비스 검색을 구현하는 것이 처음인 경우 OAuth 서버에서 관련 작업을 수행할 수 있는 권한 부여를 요청합니다.
- 사용자가 3scale로 다시 리디렉션됩니다.
OAuth 서버를 사용하여 서비스 검색을 구성하려면 다음 옵션이 있습니다.
8.2.1.1. OpenShift OAuth 서버 사용 링크 복사링크가 클립보드에 복사되었습니다!
3scale 시스템 관리자는 사용자가 OpenShift 내장 OAuth 서버를 사용하여 3scale을 개별적으로 인증하고 승인하여 API를 검색할 수 있습니다.
3scale용 OpenShift OAuth 클라이언트를 생성합니다. OpenShift 인증에 대한 자세한 내용은 OAuth 클라이언트를 참조하십시오.
$ oc project default $ cat <<-EOF | oc create -f - kind: OAuthClient apiVersion: v1 metadata: name: 3scale secret: "<choose-a-client-secret>" redirectURIs: - "<3scale-master-domain-route>" grantMethod: prompt EOF3scale Service Discovery 설정 파일을 엽니다.
$ oc project <3scale-project> $ oc edit configmap system다음 설정을 구성합니다.
service_discovery.yml: production: enabled: true authentication_method: oauth oauth_server_type: builtin client_id: '3scale' client_secret: '<choose-a-client-secret>'검색 가능한 서비스가 포함된 클러스터 프로젝트를 볼 수 있는 적절한 권한이 사용자에게 있는지 확인합니다.
<user> 으로 표시되는 관리자 사용자에게 검색할 서비스가 포함된 < namespace > 프로젝트에 대한 보기 권한을 부여하려면 다음 명령을 사용합니다.
oc adm policy add-role-to-user view <user> -n <namespace>configmap을 수정한 후system-app및system-sidekiqPod를 재배포하여 변경 사항을 적용해야 합니다.oc rollout latest dc/system-app oc rollout latest dc/system-sidekiq롤아웃 상태를 확인하여 완료되었는지 확인합니다.
oc rollout status dc/system-app oc rollout status dc/system-sidekiq
추가 참고
기본적으로 OpenShift OAuth 세션 토큰은 OpenShift 토큰 옵션에 표시된 대로 24시간 후에 만료됩니다.
8.2.1.2. RH-SSO 서버 사용(Keycloak) 링크 복사링크가 클립보드에 복사되었습니다!
시스템 관리자는 사용자가 3scale을 개별적으로 인증하고 승인하여 OpenShift용 Red Hat Single Sign-On 서비스를 검색할 수 있습니다. RH-SSO 배포를 OpenShift의 권한 부여 게이트웨이로 사용하도록 OpenShift를 구성하는 예는 이 워크플로 를 참조하십시오.
Red Hat OAuth 서버(Keycloak)에서 3scale용 OAuth 클라이언트를 생성합니다.
참고클라이언트 구성에서
사용자이름이 OpenShift가 계정을 연결할 수 있도록preferred_username에 매핑되는지 확인합니다.3scale 서비스 검색 설정을 편집합니다.
$ oc project <3scale-project> $ oc edit configmap system이러한 설정이 구성되어 있는지 확인합니다.
service_discovery.yml: production: enabled: true authentication_method: oauth oauth_server_type: rh_sso client_id: '3scale' client_secret: '<choose-a-client-secret>'검색 가능한 서비스가 포함된 클러스터 프로젝트를 볼 수 있는 적절한 권한이 사용자에게 있는지 확인합니다.
예를 들어 <
namespace> 프로젝트에 대해 <user> 보기 권한을 부여하려면 다음 명령을 사용합니다.oc adm policy add-role-to-user view <user> -n <namespace>-
configmap을 수정한 후system-app및system-sidekiqPod를 재배포하여 변경 사항을 적용해야 합니다.
추가 정보:
- 토큰 수명: 기본적으로 세션 토큰은 Keycloak - 세션 및 토큰 시간 제한에 표시된 대로 1분 후에 만료됩니다. 그러나 시간 제한을 허용 가능한 값으로 1일로 설정하는 것이 좋습니다.
8.2.2. OAuth 서버 없이 구성 링크 복사링크가 클립보드에 복사되었습니다!
OAuth 서버 없이 3scale 서비스 검색을 구성하려면 3scale Single Service Account를 사용하여 OpenShift API 서비스에 인증할 수 있습니다. 3scale 단일 서비스 계정은 사용자 수준의 권한 부여 계층 없이 서비스 검색 클러스터에 원활한 인증을 제공합니다. 3scale 테넌트 관리 사용자는 3scale을 통해 API 서비스를 검색하면서 클러스터에 대한 액세스 수준이 모두 동일합니다.
절차
3scale 프로젝트가 현재 프로젝트인지 확인합니다.
$ oc project <3scale-project>편집기에서 3scale 서비스 검색 설정을 엽니다.
$ oc edit configmap system다음 설정이 구성되었는지 확인합니다.
service_discovery.yml: production: enabled: <%= cluster_token_file_exists = File.exists?(cluster_token_file_path = '/var/run/secrets/kubernetes.io/serviceaccount/token') %> bearer_token: "<%= File.read(cluster_token_file_path) if cluster_token_file_exists %>" authentication_method: service_account다음 옵션 중 하나를 통해 검색 가능한 서비스가 포함된 프로젝트를 볼 수 있도록 3scale 배포
amp서비스 계정에 관련 권한을 제공합니다.view클러스터 수준 권한을 사용하여 3scale 배포amp서비스 계정을 부여합니다.oc adm policy add-cluster-role-to-user view system:serviceaccount:<3scale-project>:amp- OpenShift에 설명된 대로 보다 제한적인 정책을 적용합니다.
8.3. 서비스 검색 링크 복사링크가 클립보드에 복사되었습니다!
OpenAPI Specification (OAS, Swagger 사양이라고도 함)에 해당하는 새 API 서비스를 찾을 수 있습니다. 해당 서비스는 3scale 관리를 위해 클러스터에서 검색됩니다.
사전 요구 사항
-
OpenShift 관리자가 OpenShift 클러스터에 대한 서비스 검색을 구성했습니다. 예를 들어, Fuse Online API의 경우 OpenShift 관리자는 Fuse Online 서비스의
CONTROLLERS_EXPOSE_VIA3SCALE환경 변수를true로 설정해야 합니다. - 3scale 관리자는 8.1절. “서비스 검색 정보” 에 설명된 대로 서비스 검색에 대한 3scale 배포를 구성했습니다.
- API의 서비스 이름과 해당 네임스페이스(OpenShift 프로젝트)를 알고 있습니다.
- 3scale 관리자는 API 서비스 및 해당 네임스페이스를 보는 데 필요한 권한을 3scale 사용자 또는 서비스 계정(구성된 인증 모드에 따라)에게 부여했습니다. 자세한 내용은 8.4절. “OpenShift 프로젝트에 대한 3scale 액세스 권한 부여” 에서 참조하십시오.
- API 서비스는 3scale이 설치된 동일한 OpenShift 클러스터에 배포됩니다.
- API에는 8.1절. “서비스 검색 정보” 에 설명된 대로 서비스 검색을 활성화하는 올바른 주석이 있습니다.
절차
- 3scale 관리 포털에 로그인합니다.
- 관리 포털의 대시보드에서 새 API 를 클릭합니다.
OpenShift에서 가져오기 를 선택합니다.
- OAuth 토큰이 유효하지 않은 경우 OpenShift 프로젝트 관리자가 3scale 사용자에 대한 액세스 권한을 부여 해야 합니다.
-
Namespace 필드에서 API가 포함된 OpenShift 프로젝트를 지정하거나 선택합니다(예:
fuse). -
Name 필드에 해당 네임스페이스 내의 OpenShift 서비스 이름을 입력하거나 선택합니다(예:
i-task-api). - 서비스 생성을 클릭합니다.
-
새 API 서비스가 비동기식으로 3scale로 가져올 때까지 기다립니다. 관리 포털의 오른쪽 상단에 메시지가 표시됩니다.
서비스는 곧 제공됩니다. 완료되면 알림이 전송됩니다.
다음 단계
API 관리에 대한 자세한 내용은 Red Hat 3scale API Management 설명서를 참조하십시오.
8.4. OpenShift 프로젝트에 대한 3scale 액세스 권한 부여 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift 프로젝트 관리자는 OAuth 토큰이 유효하지 않은 경우 3scale 사용자가 네임스페이스에 액세스하도록 권한을 부여할 수 있습니다.
사전 요구 사항
- OpenShift 프로젝트 관리자로 자격 증명이 있어야 합니다.
-
OpenShift 관리자가 OpenShift 클러스터에 대한 서비스 검색을 구성했습니다. 예를 들어, Fuse Online API의 경우 OpenShift 관리자는 Fuse Online 서비스의
CONTROLLERS_EXPOSE_VIA3SCALE환경 변수를true로 설정해야 합니다. - 3scale 관리자는 8.1절. “서비스 검색 정보” 에 설명된 대로 서비스 검색에 대한 3scale 배포를 구성했습니다.
- API 서비스 이름과 OpenShift 프로젝트의 네임스페이스를 알고 있습니다.
- API 서비스는 3scale이 설치된 동일한 OpenShift 클러스터에 배포됩니다.
- API에는 8.1절. “서비스 검색 정보” 에 설명된 대로 서비스 검색을 활성화하는 올바른 주석이 있습니다.
절차
- Authenticate를 클릭하여 이 옵션 링크를 활성화합니다.
- 네임스페이스 관리자 자격 증명을 사용하여 OpenShift에 로그인합니다.
- 3scale 사용자에게 액세스 권한을 승인하려면 선택한 권한 허용을 클릭합니다.
다음 단계
API 관리에 대한 자세한 내용은 Red Hat 3scale API Management 설명서를 참조하십시오.
8.5. 서비스 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 서비스의 현재 정의를 사용하여 3scale에서 기존 API 서비스를 업데이트(refresh)할 수 있습니다.
사전 요구 사항
이전에 클러스터에서 서비스를 가져오거나 검색했습니다.
절차
- 3scale 관리 포털에 로그인합니다.
- API 서비스의 개요 페이지로 이동합니다.
- Source: OpenSource 옆에 있는 Refresh 링크를 클릭합니다.
- 새 API 서비스가 비동기식으로 3scale로 가져올 때까지 기다립니다.
IV 부. 액세스 제어 링크 복사링크가 클립보드에 복사되었습니다!
9장. API 정의 (Methods and Metrics) 링크 복사링크가 클립보드에 복사되었습니다!
API 제품 및 백엔드 수준 모두에서 메서드 및 지표를 추가하여 API를 정의할 수 있습니다. API 제품은 하나 이상의 API 백엔드가 번들로 제공됩니다. 제품 수준에서 방법 및 메트릭을 사용하면 모든 제품의 애플리케이션 계획에 대한 제한 및 가격 규칙을 설정할 수 있습니다. 백엔드 수준에서 방법 및 메트릭을 사용하여 백엔드를 번들하는 모든 제품의 애플리케이션 계획의 제한 및 가격 규칙을 설정할 수 있습니다.
지표 는 제품 및 백엔드 수준 모두에서 API의 사용량을 추적하는 데 적합합니다. 히트 는 각 API에 존재하는 기본 제공 메트릭이며 API의 히트를 추적하는 데 사용됩니다. Hits 메트릭에서 방법을 정의하여 API 사용 추적을 더 세분하게 수행할 수 있습니다. 메서드로 트래픽을 보고하면 메서드 및 Hits 메트릭에 대한 카운터가 자동으로 증가합니다. API 백엔드의 각 끝점 또는 끝점 및 HTTP 메서드의 조합을 정의할 수 있습니다. API의 끝점을 여기에 정의된 메서드에 매핑하는 방법은 매핑 규칙 섹션을 참조하십시오.
히트와 별도로 API 사용을 측정하기 위해 새 메트릭을 정의하고 다른 단위로 사용량을 보고할 수 있습니다. 단위는 quantifiable이어야 하며 메가바이트, CPU 시간, API에서 반환된 요소 수 등과 같은 비즈니스 목표에 대한 의미를 적용해야 합니다. CPU 시간 또는 mb 와 같은 히트 이외의 모든 메트릭은 기본적으로 3scale에 포함되지 않으며 사용자가 구성한 외부 서비스에서 주기적으로 호출한 끝점을 사용하여 보고해야 합니다.
메서드 및 메트릭도 API를 패키징하는 스캐폴딩입니다. 각 애플리케이션 계획을 사용하면 각 메서드 및 메트릭에 대해 다양한 사용 제한 및 가격 규칙을 정의할 수 있습니다. 지표 및 방법에 보고된 사용량에 대한 자세한 내용은 API 분석 섹션을 참조하십시오.
추가 리소스
API 제품 및 백엔드에 대한 자세한 내용은 3scale 시작하기를 참조하십시오.
9.1. 방법 및 메트릭 추가 링크 복사링크가 클립보드에 복사되었습니다!
제품 또는 백엔드에 새 방법을 추가하려면 다음 단계를 따르십시오.
- [gradle_product_name] > 통합 > 방법 및 지표 또는 [your_backend_name] > 방법 및 지표 로 이동합니다.
- 메서드 목록 오른쪽 위에 있는 새 메서드 링크를 클릭합니다.
매개변수를 지정합니다.
- 친숙한 이름은 방법에 대한 간단한 설명이며 3scale 관리 포털의 다른 섹션에 표시됩니다. 이 이름은 제품에 고유해야 합니다.
-
시스템 이름은 3scale Service Management API를 통해 사용량을 보고하는 데 사용할 메서드의 이름입니다. 또한 고유해야 하며 영숫자 문자, 밑줄
_, 하이픈-및 슬래시/앞에 공백만 포함해야 합니다. 그 외에는 시스템 이름이 어떻게 보일지 자유롭게 결정할 수 있습니다. 엔드포인트 (/status)와 정확히 동일하거나, 예를 들어 메서드와 경로(GET_/status)를 포함할 수 있습니다. Description 필드는 메서드에 대한 자세한 설명에 사용할 수 있으며 선택 사항입니다.
- 마지막으로 Create Method 를 클릭합니다.
나중에 메서드 정의를 변경할 수 있습니다. 메서드 이름(메서드 )을 클릭하고 필드를 업데이트하고 Update Method를 클릭합니다.
방법 및 메트릭의 시스템 이름 변경 또는 삭제에 매우 주의하십시오. 이러한 변경으로 인해 메서드의 이전 시스템 이름을 가리키는 매핑 규칙이 있는 경우 이미 배포된 3scale 통합을 중단할 수 있습니다.
새 지표를 생성하려면 New 지표 를 클릭하고 필요한 매개변수를 제공합니다. 단위를 지정할 때 단일 noun (예: "hit")을 사용합니다. analytics 차트에서 자동으로 복수형이기 때문입니다.
이러한 새로운 방법과 메트릭은 현재 및 향후의 모든 계획에서 사용할 수 있습니다. 이제 [gradle _product_name] > 애플리케이션 > 애플리케이션 계획 > [plan_you_want_to_edit]로 이동하여 각 계획에서 제한 및 가격 규칙을 편집할 수 있습니다.
9.2. 메서드 및 메트릭 자동 가져오기 링크 복사링크가 클립보드에 복사되었습니다!
API에 끝점이 많이 있는 경우 3scale에서 메서드 및 메트릭을 자동으로 생성하는 두 가지 추가 방법을 제공합니다.
10장. 애플리케이션 계획 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션 계획에서는 API 소비자에게 허용할 수 있는 다양한 액세스 권한 집합을 정의합니다. 이러한 매개변수는 속도 제한부터 액세스할 수 있는 방법과 어떤 기능을 활성화할지 결정할 수 있습니다.
10.1. 애플리케이션 계획 생성 방법 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 3scale 계정이 생성되면 Basic 및 Unlimited의 두 가지 계획이 제공됩니다. 이러한 항목을 유지 및 편집하거나 직접 만들 수 있습니다. 필요한 만큼 계획을 생성할 수 있습니다.
새 애플리케이션 계획을 생성하려면 다음 단계를 따르십시오.
- [ your_product_name] > Applications > Application Plans 로 이동합니다.
- Create Application Plan 버튼을 클릭합니다.
-
Create Application Plan페이지에서 새 계획에 대한 이름과 시스템 이름(시스템 이름이어야 함)을 입력합니다. - 애플리케이션에 API에 액세스하기 전에 승인이 필요한 경우 승인이 필요한 애플리케이션 확인란을 선택합니다.
10.2. 기본 애플리케이션 계획 설정 링크 복사링크가 클립보드에 복사되었습니다!
모든 계획을 생성한 후 사용자가 애플리케이션을 등록하기 위해 등록할 때 기본 계획을 선택할 수 있습니다.
기본 애플리케이션 계획을 선택하려면 다음을 수행합니다.
- [ your_product_name] > Applications > Application Plans 로 이동합니다.
- Default Plan 의 드롭다운 목록에서 계획을 선택합니다.
기본 애플리케이션 계획을 표시하지 않는 경우 새 사용자가 API에 대한 액세스 권한을 등록하면 기본적으로 애플리케이션을 생성하지 않습니다. 즉, 사용자는 API에 액세스할 수 없습니다.
11장. 매핑 규칙 링크 복사링크가 클립보드에 복사되었습니다!
메서드 및 메트릭을 추가하여 API를 정의한 후 매핑 규칙 페이지에서 정의한 메서드에 API 엔드포인트 또는 경로를 매핑할 수 있습니다. 이렇게 하려면 다음을 수행합니다.
- [gradle_product_name] > 통합 > 매핑 규칙으로 이동합니다.
- Add Mapping Rule 링크를 클릭합니다.
- HTTP 메서드, 패턴, 메트릭(또는 메서드) 및 증분을 선택합니다.
- Create Mapping Rule 버튼을 클릭합니다.
매핑 규칙을 확인하려면 [gradle_product_name] > 통합 > 방법 및 지표 로 이동합니다. 각 방법과 메트릭은 Mapped 열에 확인 표시가 있어야 합니다.
12장. 프로비저닝 유료 계획 링크 복사링크가 클립보드에 복사되었습니다!
API를 수익화하는 가장 일반적인 방법 중 하나인 제품 또는 백엔드는 사용량에 따라 서브스크립션 요금을 정의하는 것입니다. 이 섹션에서는 애플리케이션 계획을 사용하여 가격 계층을 프로비저닝하는 방법과 유료 계획을 설정하는 방법에 대해 중점적으로 설명합니다. 또한 해당 계정 및 제품 및 백엔드 수준에서 가격 규칙을 적용할 수 있습니다.
이러한 주제는 이 장의 다음 섹션에서 다룹니다.
12.1. 가격 모델 결정 링크 복사링크가 클립보드에 복사되었습니다!
첫 번째 결정은 가격 모델의 계층을 구별하는 방법입니다. 계층은 볼륨 또는 사용량, API 기능, 다른 리소스에 대한 액세스 또는 조합에 따라 구동될 수 있습니다.
- 볼륨 / 사용량. 계층 간 차이를 구별하는 가장 일반적인 방법은 볼륨 기반입니다. 볼륨에는 일반적으로 고객과의 가치와 강력한 상관관계가 있고 서비스 비용이 있기 때문입니다. 제품 호출에 글로벌 적중 횟수를 적용하거나 메서드 수준에서보다 세부적인 측정을 적용할 수 있습니다. 볼륨 드라이버 는 글로벌 적중 메트릭의 수준 또는 히트 아래의 개별 방법에 적용됩니다. 여러 가격 규칙을 모든 메트릭에 적용할 수 있습니다. 히트 계산은 1 개월 청구 주기에 따라 누적됩니다.
- 기능. 계층에 따라 제품 일부에 대한 액세스를 활성화하거나 비활성화할 수 있습니다. 이는 표준 수준과 프리미엄 수준을 구별하는 좋은 방법입니다.
- 리소스. 또한 고객에게 가치를 제공하는 기타 리소스에 대한 액세스 권한(예: 사용자 수, 사용자 수, 기가바이트) 또는 트랜잭션 값에 따라 계층을 생성할 수도 있습니다. 리소스 드라이버 는 볼륨 드라이버와 유사하지만 사용자 정의 메트릭에 적용됩니다.
가격 드라이버를 결정하면 계층이 플랫 속도 서브스크립션, 변수 속도 또는 일회 전하를 기반으로 할지 여부를 결정해야합니다. 위의 세 가지 가격 결정 드라이버는 모두 off 또는 monthly flat rate 서브스크립션과 호환됩니다. 가격을 결정하는 경우 히트 볼륨이나 리소스 소비량을 기준으로 결정되는 경우 가격에 대한 변수 요소가 있습니다.
12.2. 가격 규칙을 사용하여 애플리케이션 계획 구성 링크 복사링크가 클립보드에 복사되었습니다!
새 애플리케이션 계획을 생성하거나 기존 애플리케이션을 편집할 수 있습니다. 새 애플리케이션 계획을 생성할 때 초기 비용 또는 플랫 비율 서브스크립션을 입력할 수 있습니다.
편집 애플리케이션 보기에서 초기 비용 및 서브스크립션을 입력하거나 수정할 수 있습니다.
다음으로 12.1절. “가격 모델 결정” 에서 선택한 가격 드라이버를 설정합니다.
- [ECDHE_product_name] > 개요 > 애플리케이션 > 애플리케이션 계획으로 이동합니다.
- 애플리케이션 계획 이름을 클릭합니다.
- Metrics, Methods, Limits &ECDHE Rules 로 이동합니다. 여기에서는 총 적중 수준, 메서드의 세분성 또는 모든 사용자 지정 메트릭에서 가격을 정의할 수 있습니다.
일부 항목이 메트릭으로 이미 있는 경우 항목을 편집할 수 있습니다.
가격 책정 규칙 설정을 완료하면 애플리케이션 업데이트 계획 을 클릭합니다.
12.3. 추가 가격 계층 생성 링크 복사링크가 클립보드에 복사되었습니다!
단일 애플리케이션 계획을 사용하여 API 유료 계획을 정의할 수 있습니다. 일반적으로 모든 가격 책정 규칙이 볼륨 또는 리소스 드라이버에 의해 정의되는 경우입니다. 그러나 개발자 커뮤니티의 다른 세그먼트에 대해 별도의 계획을 제공하려면 더 많은 애플리케이션 계획을 추가합니다.
가장 쉬운 방법은 애플리케이션 계획 개요 페이지에서 첫 번째 애플리케이션 계획을 복사하는 것입니다. 이렇게 하면 기존 메트릭 및 가격 규칙이 모두 미리 채워집니다. 처음으로 전체 계획을 만들기 위해 더 많은 주의를 기울이면 계획 복사 기능으로 더 많은 시간을 절약할 수 있습니다.
12.4. 유료 계획 프로비저닝 링크 복사링크가 클립보드에 복사되었습니다!
계획을 프로비저닝하려면 개발자가 새 애플리케이션을 생성하고 새 유료 계획 중 하나를 선택해야 합니다. 관리 콘솔에서 이 작업을 수행할 수도 있습니다. 기존 애플리케이션의 경우 기존 계획에서 새 유료 계획 중 하나로 변경할 수도 있습니다.
12.5. 참고 자료 링크 복사링크가 클립보드에 복사되었습니다!
플랫 비율 계획과 함께 속도 제한을 사용하여 계층을 구별하는 것이 일반적입니다. 이는 프로비저닝 속도 제한에서 설명됩니다.
13장. 프로비저닝 속도 제한 링크 복사링크가 클립보드에 복사되었습니다!
속도 제한을 사용하면 API 리소스, 제품 및 백엔드에 대한 액세스를 제한할 수 있습니다. 애플리케이션 계획을 사용하여 별도의 개발자 세그먼트에 대해 다른 제한을 구성할 수 있습니다.
비율 제한이 있으면 이러한 제한은 3scale 백엔드에 대한 권한 부여 요청 호출을 수행할 때 개발자가 수신하는 응답을 제어합니다.
13.1. 애플리케이션 계획 구성 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션 계획이 아직 정의되어 있지 않은 경우 먼저 생성합니다. 그렇지 않으면 속도 제한을 설정할 계획을 선택하고 편집 을 클릭합니다.
애플리케이션 계획 생성에 대한 자세한 내용은 애플리케이션 계획을 참조하십시오.
13.2. 속도 제한 설정 링크 복사링크가 클립보드에 복사되었습니다!
속도 제한을 설정하려면 다음을 수행합니다.
- [ move_product_name] > 개요 > 애플리케이션 > 애플리케이션 계획으로 이동합니다.
- 구성할 애플리케이션 계획의 이름을 클릭합니다.
- Metrics, Methods, Limits,Limit Rules 로 스크롤합니다.
- 제한을 클릭합니다.
- 제품 또는 백엔드 수준에 대한 제한을 구성합니다.
- 필요한 제한 설정을 완료하면 애플리케이션 업데이트 계획 을 클릭하여 변경 사항을 저장합니다.
13.3. 새로운 속도 제한을 실행으로 설정 링크 복사링크가 클립보드에 복사되었습니다!
이제 비율 제한이 정의되었으므로 다음이 수행됩니다.
- 경고가 구성된 경우 알림 전송 시기를 결정하는 데 새 제한이 사용됩니다.
- 3scale 백엔드에 대한 호출 수를 초과하면 제한이 고려되고 관련 오류 메시지가 표시됩니다. APIcast 오류 메시지에 대한 자세한 내용은 오류 메시지 구성을 참조하십시오.
속도 제한이 작동하면 대시보드의 한도에 도달하는 사용자를 볼 수 있으므로 잠재적인 계획 업그레이드 후보를 빠르고 쉽게 확인할 수 있습니다. 소프트 및 하드 제한에 대한 자세한 내용은 고급 경로의 애플리케이션 계획으로 API 액세스 정책 구성에서 시작하기 가이드를 참조하십시오.
13.4. 더 많은 정보 링크 복사링크가 클립보드에 복사되었습니다!
속도 제한을 설정하는 것 외에도 동일한 메트릭에 대한 변수 가격 규칙을 설정할 수도 있습니다.
V 부. 청구 링크 복사링크가 클립보드에 복사되었습니다!
14장. LimitRange 설정 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 문서에서는 LimitRangeing 기능이 3scale에서 작동하는 방법에 대해 설명합니다.
청구 설정은nateging & Gateway 및ECDHE Card Policies 로 나뉩니다. 두 가지 모두 관리 포털에서>페이딩에서 확인할 수 있습니다.
14.1. 청구 모드(Charging & Gateway) 링크 복사링크가 클립보드에 복사되었습니다!
3scale에 대한 청구는 일정 월에 기반하며 Prepaid and *Postpaid 일 수 있습니다.
- Prepaid mode에서 모든 고정요금 및 설정요금은 월 초 또는 청구 기간의 시작 부분에 청구됩니다. 변수 비용은 항상 다음 달의 시작 부분에 계산 및 청구됩니다.
- Postpaid mode에서는 다음 달 초에 모든 고정 요금과 변수 비용이 청구됩니다.
자세한 내용은 Automated billing process 를 참조하십시오.
14.2. 번식 활성화 (Charging & Gateway) 링크 복사링크가 클립보드에 복사되었습니다!
이 설정은 카드 거래를 가능하게 합니다. 이 설정이 설정되어 있으면 선택한 결제 게이트웨이를 사용하여 모든 송장이 청구됩니다. 이 설정을 해제하면 청구가 발생하고 송장이 발행되지만 실제 결제 거래는 발생하지 않습니다.
14.3. 별점 (Charging & Gateway) 링크 복사링크가 클립보드에 복사되었습니다!
청구 및 카드 거래를 수행할 통화를 선택합니다. 귀하의 결제 게이트웨이에 의해 선택된 통화가 지원되는지 확인하십시오. 이 설정은 글로벌이며 모든 송장 및 트랜잭션에 적용됩니다. 다른 개발자 계정에 대해 다른 설정을 설정할 수 없습니다.
14.4. 송장 발주 (Charging & Gateway) 링크 복사링크가 클립보드에 복사되었습니다!
Invoice footnote 필드에 도입된 텍스트는 모든 IRQ 송장 하단에 표시됩니다. 이 필드를 사용하여 고객의 배당 및 청구 정책에 대한 추가 정보를 제공할 수 있습니다.
각주의 텍스트가 변경되면 IRQ가 이미 생성된 송장에는 자동으로 적용되지 않습니다. 그러나 송장의 IRQ를 다시 생성하여 변경 사항을 적용할 수 있습니다.
14.5. 어떻게 해야 하는지 확인할 수 있는 텍스트입니다. (Charging & Gateway) 링크 복사링크가 클립보드에 복사되었습니다!
이 필드는 청구된 계정의 경우 IRQ 송장에 텍스트 메시지를 추가하는 데 사용됩니다. 이 행은ECDHE / Sales hieradata가 명시적으로 0으로 설정된 경우에만 표시됩니다. 그렇지 않으면 표시되지 않습니다. 이 텍스트는 관리 포털의 송장 페이지에도 표시됩니다.
이 설정에 대한 자세한 내용은 please see more about this setting inECDHE / SalesECDHE 섹션에서 참조하십시오.
14.6. 송장 ID(Charging & Gateway)에 대한 청구 기간 링크 복사링크가 클립보드에 복사되었습니다!
3scale의 송장에는 두 가지 유형의 ID가 있습니다.
- 실제 ID
- 데이터베이스의 송장을 고유하게 식별하는 것은 무엇입니까. 이는 송장 URL(예: https://<dashboard_domain>/buyers/accounts/<acount_id>/invoices/<invoice_id> )에 표시되는 숫자 ID입니다.
- 친숙한 ID
- 송장에 표시되는 ID는 사용자에게 친숙한 식별자입니다. 3scale 계정별로 고유해야 하지만 기술적으로 친숙한 ID를 보유할 수 있습니다. 시스템에서 중복 ID를 식별하는 경우 경고가 표시됩니다. 이 송장 ID는 이미 사용 중이며 변경될 수 있습니다. 24시간 이상 친숙한 ID가 수정 사항으로 표시되는 경우 지원 팀에 문의하십시오.
이 설정은 송장의 Friendly ID 형식을 정의합니다.
- monthly(기본값)
-
YYY-MM-XXX, 즉 ID에는 년, 월 및 송장 수가 포함됩니다. 예: 2018-02-00000013 - 연간
-
YYY-XXX, 즉 연도와 숫자만 포함됩니다. 예: 2018-00000001
송장 ID에 대한 billinging 기간을 월간 에서 연간 로 변경하는 유일한 영향은 친숙한 ID 형식을 변경하는 것이며 청구 주기 기간은 변경되지 않습니다. 3scale API Management에서 월간 청구만 지원됩니다. 회계 부서에서 이러한 요구사항이 있는 경우 송장 ID의 형식을 연간로 변경할 수 있습니다.
연간 요금을 청구해야 하는 경우 청구를 수동으로 처리해야 합니다. 새 송장을 생성하고 연간 비용으로 라인 항목을 추가할 수 있습니다. 연간 배당을 사용하려는 경우 애플리케이션 계획을 자유롭게 설정하여 송장이 생성되지 않도록 하고/또는 매달 자동으로 청구되도록 할 수 있습니다.
14.7. 직불 카드 정책 링크 복사링크가 클립보드에 복사되었습니다!
여기에서 다음 페이지의 경로를 구성할 수 있습니다.
- 법률 약관 페이지
- 개인 정보 보호 페이지
- Rescalation 페이지
14.8. 개인 정보 보호 카드 게이트웨이 링크 복사링크가 클립보드에 복사되었습니다!
3scale은 카드 거래를 위해 다음과 같은 결제 게이트웨이와 통합됩니다.
- Braintree
- 스트라이프
14.8.1. 스트라이프 통합(권장) 링크 복사링크가 클립보드에 복사되었습니다!
이 단계를 완료하면 계정에 대한 결제 게이트웨이로 Stripe을 구성하게 됩니다. 이를 통해 개발자는 귀하의 카드 정보를 입력할 수 있으며 계산된 송장에 따라 Stripe을 통해 자동으로 API에 액세스할 수 있습니다.
유료 API에 대해 대금 카드 과충을 활성화하는 경우 한 가지 주요 단계는 결제 게이트웨이를 설정하는 것입니다. 3scale 계정과 함께 사용할 수 있는 대체 결제 게이트웨이가 여러 가지가 있습니다. 여기에서는 Stripe의 단계를 다룹니다.
14.8.1.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
이러한 단계를 시작하기 전에 Stripe 계정을 열어야 합니다.
14.8.1.2. Stripe에서 API 키 가져오기 링크 복사링크가 클립보드에 복사되었습니다!
Stripe 계정에 로그인하고 https://dashboard.stripe.com/account/apikeys 에서 API 키를 가져옵니다. 두 개의 키가 필요합니다. "비밀" 1과 "공개" 1개입니다. 테스트를 수행할 때 "테스트" 세트와 "라이프트"를 시작할 준비가 되면 "라이브" 세트를 사용하십시오.
14.8.1.3. 3scale에서 설정 구성 링크 복사링크가 클립보드에 복사되었습니다!
이러한 API 키 사용을 시작하도록 3scale에 지시해야 합니다. 이렇게 하려면 3scale 관리 포털에 로그인하고ECDHE > go to makeging & Gateway 로 이동합니다.
Enabled 플래그가 활성화되지 않은 경우 활성화한 후 저장을 클릭합니다.
페이지 하단에 게이트웨이라는 드롭다운이 표시되어야 합니다. Stripe로 변경하십시오.
드롭다운 아래의 양식은 두 개의 필드를 표시하도록 변경됩니다. Stripe API 키를 삽입하고 저장을 클릭합니다.
결제 게이트웨이를 변경할 때 몇 가지 경고가 표시될 수 있습니다. 이는 예상입니다. 내용을 읽고 나타나는 경우 이를 수락하십시오.
이제 결제 게이트웨이가 설정되어 있지만 사용자는 CMS에서 구성되지 않았기 때문에 아직 사용하지 못할 수 있습니다. 개발자 포털로 이동하여 왼쪽 탐색 창에서ECDHE Gateway / Show라는 템플릿을 클릭합니다.
아직 없는 경우 "braintree_blue" %} : {% 전에 다음 코드를 추가하십시오.
{% when "stripe" %}
<p><a href="{{ current_account.edit_stripe_billing_address_url }}">Edit billing address</a></p>
{% if current_account.has_billing_address? %}
{% stripe_form "Edit Credit Card Details" %}
{% else %}
<p>After entering billing address, the option to enter credit card will be enabled.</p>
{% endif %}
마지막으로 저장 및 게시를 클릭합니다. 이제 사용자가 Stripe 게이트웨이를 사용하여 비용을 결제할 수 있어야 합니다.
3scale에서 데이터와 Stripe의 데이터를 매핑하려면 3scale-[PROVIDER_ID]-[DEVELOPER_ACCOUNT_ID]로 구성된 metadata.3scale_account_reference 라는 Stripe 필드를 사용할 수 있습니다.
14.8.2. Braintree 통합 링크 복사링크가 클립보드에 복사되었습니다!
이러한 단계는 API 사용을 청구하기 위해 Braintree 게이트웨이를 설정하는 단계입니다.
14.8.2.1. Braintree에서 API 키 가져오기 링크 복사링크가 클립보드에 복사되었습니다!
Braintree 로 계정을 개설해야 합니다. 게이트웨이 및 Merchant 계정 및 Vault가 필요합니다. 선택적인 추가 기능으로, USA Express 카드를 결제 방법으로 허용하도록 선택할 수 있습니다.
시작하려면 Braintree 계정에 로그인합니다. 그런 다음 계정 > MyUser 영역에서 API 키를 찾습니다.
API 키 페이지가 계속 개인 키를 숨기므로 볼 옵션을 선택합니다.
마지막으로 3scale 청구 설정에 필요한 공개 키, 개인 키 및 Merchant ID가 있습니다.
14.8.2.2. 3scale에서 설정 구성 링크 복사링크가 클립보드에 복사되었습니다!
이러한 API 키 사용을 시작하도록 3scale에 지시해야 합니다. 이렇게 하려면 3scale 관리 포털에 로그인하고ECDHE > tileing >ECDHEging & Gateway 로 이동합니다.
청구 페이지에 지정된 통화 유형이 Braintree 가맹점 계정에 사용된 통화 유형과 일치하는지 확인합니다.
Enabled 플래그가 활성화되지 않은 경우 활성화한 후 저장을 클릭합니다.
페이지 하단에 게이트웨이라는 드롭다운이 표시되어야 합니다. Braintree (Blue Platform)로 변경하십시오.
드롭다운 아래의 양식은 두 개의 필드를 표시하도록 변경됩니다. Braintree 키를 삽입하고 저장을 클릭합니다.
결제 게이트웨이를 변경할 때 몇 가지 경고가 표시될 수 있습니다. 이는 예상입니다. 표시되는 경우 읽고 수락하십시오.
이제 사용자는 Braintree 게이트웨이를 사용하여 비용을 청구할 수 있습니다.
3scale의 데이터로 Braintree의 데이터를 매핑하려면 3scale-[PROVIDER_ID]-[DEVELOPER_ACCOUNT_ID]로 구성된 customer.id 라는 Braintree 필드를 사용할 수 있습니다.
14.8.2.2.1. 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
계정이 샌드 박스 모드에 있고 문제가 발생하는 경우 이를 production으로 변경해야 합니다.
15장. 가격 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 API 사용을 위해 개발자를 부과할 수 있는 다양한 방법에 대해 설명합니다.
- 설정 비용
- 는 서비스에 대한 서브스크립션에 한 번 부과되며 다른 계획으로 전환할 때 부과되지 않습니다. 서브스크립션의 첫 달 동안 송장/credit 카드에만 표시됩니다. 애플리케이션 계획, 서비스 계획 및 계정 계획에서 구성할 수 있습니다.
- 월 단위 비용
- 월 단위로 청구되는 반복 비용이 발생합니다. 월 중순에 서브스크립션이 발생한 경우 이러한 문제가 발생합니다. 종종 "수정된 비용"이라고 합니다. 애플리케이션 계획, 서비스 계획 및 계정 계획에서 구성할 수 있습니다.
- 변수 비용
- 애플리케이션 계획에서 구성된 각 방법/지표에 적용되는 가격 규칙에서 파생되는 비용입니다. API 사용을 기반으로 하므로 청구 기간이 만료되었을 때만 사전에 알 수 없습니다. 애플리케이션 계획에서만 사용할 수 있습니다.
예제
If you have a plan with monthly cost of $10, but want to charge your developer a $5 setup fee. The initial charge would be for $15, while all subsequent charges would be for $10.
15.1. 가격 규칙 링크 복사링크가 클립보드에 복사되었습니다!
가격 규칙은 각 API 요청 비용을 정의합니다. 동일한 메트릭에 대한 여러 가격 정책 규칙은 가격 규칙이 적용되는 경우의 범위를 나눕니다. 가격 규칙은 일정 월을 기반으로하며 카운터는 각 달의 첫 번째 날의 00:00 UTC로 재설정됩니다.
예시 1
Until 100 calls per month (from 1 to 100) each API call can be charged at $0.04, and starting from the call 101 (from 101 to infinity) the calls are charged at $0.10.
예시 2
The first 1000 calls are not charged (cost $0), because they are included in the plan which has a monthly fixed cost. Starting from call 1001, each call is charged at $0.50.
예시 3
Calls from 1 to 100 are charged at $0.30, 100 to 500 – at $0.40, and 500 and further – at $0.50.
가격 책정 규칙은 메트릭 및 방법에 대해 정의됩니다. 실제 API 요청은 매핑 규칙을 통해 이러한 메트릭 및 메서드에 매핑됩니다.
15.2. 가격 규칙 설정 링크 복사링크가 클립보드에 복사되었습니다!
- [Remote_API_service] > 애플리케이션 > 애플리케이션 계획으로 이동합니다.
- 기존 애플리케이션 계획을 선택하거나 새 애플리케이션 계획을 생성합니다.
- Metrics, Methods, Limits &ECDHE Rules 섹션에서 'x' 를 클릭하여 가격 섹션을 엽니다.
- 새 가격 규칙을 클릭합니다.
- From, To, Cost per Unit 값을 설정하고 가격 책정 규칙 만들기를 클릭합니다.
마지막 두 단계를 반복하여 필요한 모든 가격 규칙 범위를 만듭니다.
To 필드를 비워 두면 규칙을 "에서 무한"으로 설정합니다.
최대 10진수 수는 메트릭 비용의 경우 4로 설정됩니다. 숫자가 더 많은 10진수로 추가되면 10진수가 4개인 숫자로 반올림됩니다.
15.3. 기존 가격 규칙 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
- 편집을 클릭합니다.
- 장치당 From, To, Cost per Unit 필드를 적절하게 조정합니다.
- 업데이트 가격 규칙을 클릭합니다.
16장. 청구 링크 복사링크가 클립보드에 복사되었습니다!
청구 프로세스는 유료 서비스에 가입한 경우 개발자 계정 아래에 송장을 생성합니다. 송장은 구성된 결제 게이트웨이를 사용하여 청구됩니다.
16.1. 송장 나열 링크 복사링크가 클립보드에 복사되었습니다!
meeting > billing > Earning by month 섹션에서 상태에 따라 해당 월에 발행된 모든 송장의 합계로 계산되는 귀하의 여가 및 접수에 대한 개요를 확인할 수 있습니다.
- 합계
- 취소를 제외한 모든 송장
- 프로세스 중
- open, Finalized 및 Pending invoices
- Overdue
- 실패 및 무료 송장
- 유료
- 유료 송장
특정 달을 클릭하면 해당 월에 대한 모든 송장을 나열할 수 있습니다.
또한 invoices 목록을 see the list of invoices by going to make your ID, where you can find invoices by their ID (friendly ID), 계정 이름, 달 및 상태별로 필터링 할 수 있습니다.
특정 개발자 계정의 송장은 IRQ > 계정 > 계정 > [선택된 계정] 에서 계정 세부 정보 페이지의 X Invoices 에서 확인할 수 있습니다. 여기서 X는 계정의 송장 수입니다.
16.2. 송장 보기 링크 복사링크가 클립보드에 복사되었습니다!
송장 목록에서 송장 ID를 클릭하면 송장 세부 정보가 표시됩니다.
16.2.1. 송장 세부 정보 링크 복사링크가 클립보드에 복사되었습니다!
제목에는 송장 월과 연도가 포함되며, 송장이 수동으로 또는 자동 청구 프로세스 (예: 2018년 2월 용 Invoice)에 의해 생성되었는지 여부도 표시됩니다.
아래의 세부 정보 블록은 송장, 송장 상태, 송장이 완료 및 발행된 날짜 및 예정일 및 청구일 시의 친숙한 ID를 보여줍니다. IRQ가 이미 생성 된 경우pdf를 다운로드 할 수있는 링크도 표시됩니다.
Issued by and Issued to blocks은 API 공급자의 이름과 개발자 계정을 적절하게 표시합니다.
라인 항목이 있는 블록 아래에는 전체 비용의 계산과 총 비용의 계산이 포함되고 "ECDHE/SalesECDHE가 0%"임을 나타내는 텍스트가 표시되면 여기에도 표시됩니다.
송장의 Transactions 블록에서 거래 상태, 타임스탬프, 참조 번호, 결제 게이트웨이 및 금액에서 제공하는 메시지 등 모든 보안 카드 거래 시도 목록을 확인할 수 있습니다. 참조 번호를 사용하여 결제 게이트웨이 관리자 콘솔에서 트랜잭션을 찾을 수 있습니다.
16.2.2. 송장 편집 링크 복사링크가 클립보드에 복사되었습니다!
송장이 Open 또는 Finalized 상태인 경우 송장의 몇 가지 세부 사항을 편집할 수 있습니다.
송장 보기의 오른쪽 상단에 있는 편집 링크를 클릭하면 친숙한 ID 및 청구 기간을 변경할 수 있습니다.
또한 송장 라인 항목을 추가 및 삭제할 수 있습니다 (예: 계산된 비용 - total,knative/영업 과세, total withECDHE/sales Atomic). 새 줄 항목을 추가하려면 추가를 클릭하고 이름, 이름(비용에 영향을 미치지 않음), 설명 및 비용을 입력합니다.
송장 보기 하단의 링크는 송장에 대한 작업을 트리거할 수 있습니다 - 송장의 현재 상태에 따라 다른 작업을 사용할 수 있습니다(예: IRQ 생성, Issue invoice, Issue invoice, RegenerateECDHE, euroge, Mark as paid etc. 이러한 작업 (Digital 관련 제외)은 송장의 상태를 변경합니다.
16.3. 송장 상태 링크 복사링크가 클립보드에 복사되었습니다!
송장은 다음 상태 중 하나에 있을 수 있습니다.
- open
- 송장이 생성되었지만 자동화된 계산이 아직 완료되지 않았습니다.
- 종료됨
- 송장에는 현재 청구 기간이 모두 추가됩니다.
- 보류
- 송장은 개발자에게 발행되었으며 결제를 기다리고 있습니다.
- Unpaid
- 송장이 실패한 경우 청구되지 않았지만 자동 재시도 대기 중입니다.
- 유료
- 송장이 성공적으로 청구되었습니다.
- 실패
- 송장이 제대로 청구되지 않아 자동 재시도가 더 이상 시도되지 않습니다.
- 취소
- 관리자가 취소했습니다.
16.4. 자동 청구 프로세스 링크 복사링크가 클립보드에 복사되었습니다!
3scale에서는 청구 프로세스가 매일 실행됩니다. 청구 흐름에 따라 송장을 생성하고, 상태를 변경하고, 구성된 결제 게이트웨이를 사용하여 요금을 수행합니다.
청구 흐름은 Prepaid 및 Postpaid 모드와 약간 다르며 3scale에서 청구가 일정 월에 따라 결정되므로 해당 월의 첫날에 발생하는 특별한 이벤트가 있습니다.
16.4.1. 각 달의 첫 날 링크 복사링크가 클립보드에 복사되었습니다!
postpaid
- 이전 달의 변수 비용: 오픈 송장에 대한 비용이 행 항목으로 포함됩니다.
- 지난 한 달 동안 오픈 송장을 종료
- 현재 월에 대한 cost fixed costs: Open state에서 현재 월에 대한 새 송장을 만듭니다.
prepaid
- FlexVolume 고정 비용 (현재 달)
- subscription 변수 비용(이전 달)
알림은 월 초에 종료 된 송장에 대한 API 관리자에게 전송되므로 송장을 검토하고 필요한 조정을 할 수 있습니다.
매일 수행되는 모든 작업은 위에서 설명한 작업과 함께 월의 첫날에도 발생합니다.
16.4.2. 매일 링크 복사링크가 클립보드에 복사되었습니다!
- expired expired trial and new contract that have not yet been billed: 현재 월에 대한 오픈 상태의 문의가 생성됩니다.
- Prepaid only: 열려 있는 모든 송장을 완료: 상태가 Finalized 로 변경됩니다.
문제 송장: 보류 중으로 상태 변경
- 송장은 일반적으로 2018년 1월 1일 후에 발행됩니다. 송장의 " 실행 중" 날짜는 현재 날짜로 설정되고 "위험이 청구될 때" 일은 Issued On + 2일로 설정됩니다.
- 개발자에게 송장이 발행되면 해당 사용자는 이메일 알림을 받으며 개발자 포털에서 발행된 송장을 볼 수 있습니다.
유료 송장
- 무급 및 보류 중 상태의 송장은 현재 날짜 또는 이전 날짜가 있는 경우 부과됩니다.
- 결제에 실패한 경우 송장 상태가 Unpaid 로 변경됩니다. 경쟁은 3 일 후에 다시 시도됩니다. 3번 재시도에 실패한 후 송장 상태가 실패로 변경되고 더 이상 과금이 복구되지 않습니다.
만료된 email에 대한 알림
- 대금이 곧 만료될 개발자 계정은 이메일 알림이 전송됩니다.
16.4.3. 자동 및 수동 송장 링크 복사링크가 클립보드에 복사되었습니다!
자동 청구 프로세스에서 생성하는 송장에는 송장 헤더에 (자동으로 생성) 레이블이 있습니다. 예: 2019년 1월 용 안내(자동으로 생성된)
수동으로 생성된 송장은 송장 세부 정보 페이지에서 (ECDHEly created) 로 표시됩니다.
자동화된 청구 프로세스에서는 현재 달 동안 기존 송장을 열린 상태로 사용하여 추가 행 항목을 만들 수 있지만 자동으로 생성된 송장만 사용할 수 있습니다. 수동으로 생성된 송장은 자동 청구 프로세스에 의해 업데이트되지 않습니다.
16.4.4. 중간 개월 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션(또는 계정/서비스 서브스크립션)이 월 중순으로 업그레이드되면 월에 남은 일 수에 따라 월간 비용이 부과됩니다. 애플리케이션 계획에 구성된 제한은 업그레이드되지 않습니다.
애플리케이션을 무료로 유료 계획으로 업그레이드하는 경우 다음 번에 청구가 실행되는 경우 월간 예상 비용을 포함하여 새 송장이 생성됩니다.
유료 계획에서 더 많은 유료 계획으로 애플리케이션을 업그레이드할 때 해당 동작은 다음과 같은 몇 가지 요인에 따라 달라집니다.
- 이전 버전: Prepaid or Postpaid
- 계획 변경 시
16.4.4.1. 사전 청구 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션 계획이 생성된 대로 청구일(금요일(UTC) 오전 8시) 에서 변경된 경우 이전에 송장이 발생하지 않았으므로 이전 계획의 고정 비용이 송장에 포함되어 있으며 'Refund' 라인 항목으로 할인됩니다. 새 계획의 고정 비용도 송장에 추가됩니다.
예: 달의 첫날 계획 A (200$)에 가입 한 고객은 같은 날 계획 B (300$)로 업그레이드했습니다. 이 경우 하나의 송장이 생성되고 다음 줄 항목이 포함됩니다.
Expand 설명 cost 고정 비용 (Plan A')
200
비용 절감 (Plan A')
-200
애플리케이션 업그레이드 ('Plan A' to 'Plan B')
300
합계
300
고객이 한 달의 다른 날짜에 가입한 경우 200의 비용 및 감불이 부과됩니다.
이 애플리케이션에 대해 송장이 이미 발행된 후 애플리케이션 계획이 변경된 경우:
업그레이드 의 경우 개발자는 두 가지 송장을 발행합니다. 하나는 초기 비용이며 다른 하나는 업그레이드에 사용됩니다.
예: 달의 첫날 계획 A (200$)에 등록한 고객은 월 중순에 계획 B (300$)로 업그레이드했습니다. 다음 송장이 생성됩니다.
Expand 설명 cost 고정 비용 (Plan A')
200
합계
200
Expand 설명 cost 비용 절감 (Plan A')
-100
애플리케이션 업그레이드 ('Plan A' to 'Plan B')
150
합계
50
두 번째 송장에서는 청구 기간 중 업그레이드가 이루어지므로 감축된 비용(100$) 및 새로운 비용(150$)이 계산됩니다.
- 애플리케이션 다운그레이드 (비용이 낮은 계획 변경)는 현재 지원되지 않습니다.
16.4.4.2. postpaid billing 링크 복사링크가 클립보드에 복사되었습니다!
Postpaid billing mode에서 하나의 송장이 발행되며, Refund 및 Application upgrade line 항목이 포함됩니다.
중요: 이 동작은 2018년 4월 20일에 도입되었으며 다음과 같은 변경 사항이 적용됩니다.
- 애플리케이션이 생성된 동일한 날 업그레이드되었을 때 송장에 초기 비용(초기 애플리케이션 계획)이 포함되지 않은 버그가 수정되었습니다.
- 이전에는 새 계획과 이전 계획 비용의 차이를 포함하여 애플리케이션 업그레이드에 한 줄 항목만 추가되었습니다. 예를 들어 위의 사전 청구 섹션(플랜 A - 200$에서 계획 B - 300$로 애플리케이션 업그레이드)에 설명된 시나리오 2에서 두 번째 생성된 송장은 다음과 같습니다.
| 설명 | cost |
|---|---|
| 애플리케이션 업그레이드 ('Plan A' to 'Plan B') | 50 |
| 합계 | 50 |
여기서 50$는 새 계획과 이전 계획의 예상 비용(150$ - 100$)의 차이입니다.
2018년 4월 20일 이후부터 계산은 송장에 보다 명확하게 반영되며 (별도금 및 비용 포함) 총비용은 이전과 동일하게 유지됩니다.
16.5. 계정당 청구/하차 사용/차지 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
자동 청구 프로세스에서는 유료 서비스에 가입된 모든 개발자 계정에 대해 송장을 생성합니다. 배상은 전 세계적으로 활성화되거나 비활성화될 수 있습니다. 과금에 대한 자세한 내용은 청구 설정 구성을 참조하십시오.
개발자 계정당 청구 및 청구를 활성화하거나 비활성화할 수도 있습니다. 이러한 작업을 수행하려면 DestinationRule > Accounts > listing 로 이동하여 변경할 그룹/Org. 아래의 개발자 계정을 클릭한 다음 해당 버튼을 클릭합니다(/비활성화).
- 월간 청구가 활성화/비활성화됨
- 월간 구독이 활성화/비활성화됨
과금이 비활성화되고 청구가 활성화되면 개발자에게 송장이 발행되지만 청구는 청구되지 않습니다. 이 기능은 (예: 경유 전송)을 개별적으로 처리하는 경우에 유용합니다.
둘 다 비활성화되어 있는 경우 개발자는 발행되거나 청구되지 않습니다.
청구가 비활성화되고 과금이 활성화되면 개발자에게 새로운 송장이 발행되지 않지만 모든 미결한 항목(보류 중 및 실패)이 계속 부과됩니다.
여기 LimitRange ing Status 블록에 있는 경우 해당 카드 세부 정보가 계정에 구성되어 있는지도 확인할 수 있습니다. 카드 세부 정보가 설정되어 있는 경우 월 및 카드 만료 연도가 표시됩니다. 카드 세부 정보가 있으면 개발자 포털의 등록 및 계획 변경에 영향을 미칠 수 있습니다( 16.9절. “직불 카드 흐름”참조).
16.6. 시험 기간이 있는 계획 링크 복사링크가 클립보드에 복사되었습니다!
지정된 기간(일)에 대한 유예 기간(일)을 지연하기 위한 유료 계획에 대해 시험 기간(일)을 설정할 수 있습니다.
상태 열에서 애플리케이션의 평가판 기간 상태를 볼 수 있습니다. "live - trial expires in the trial period", and in the application details page in the Trial days left field.
시험 기간 동안 애플리케이션은 제한 없이 계획에 정의된 모든 기능 및 사용 제한을 사용할 수 있습니다.
시험 기간이 설정되면 취소 또는 연장할 수 없습니다. 다른 계획으로 업그레이드하면 시험일 카운터가 재설정되지 않습니다.
시험 기간이 만료되기 10일 전에는 향후 시험 만료를 알리는 개발자 계정으로 이메일 알림이 전송됩니다. 이 이메일의 템플릿은ECDHE > Messages > Email Templates 에서 구성할 수 있습니다. : 애플리케이션 계획에 대해"Application trial period expired for buyer ", and "Service trial period expired for the service plans with trial period". 개발자는 현재 계획을 유지하거나 다른 계획으로 전환하거나 서브스크립션을 취소하기로 결정한 경우 API 공급자에게 문의해야 합니다.
시험 기간이 끝나면 다음 시간 자동 청구 실행 ( 16.4절. “자동 청구 프로세스”참조) 개발자는 애플리케이션 또는 서비스가 현재 사용 중인 계획에 따라 비용이 청구됩니다. 이 애플리케이션은 시험 기간이 만료된 후에도 차단되거나 일시 중지 되지 않으며 계속 작동합니다.
기술적으로 시험 기간을 무료 계획에 설정할 수 있지만 기능이 유용성이 손실되므로 권장되지 않습니다.
16.7. ECDHE 비율/영업렬화 링크 복사링크가 클립보드에 복사되었습니다!
VAT( VAT)는 유럽 연합 내에서 판매된 재화 및 서비스에 적용되는 세율입니다. 다른 국가에는 비슷한 세율이 있습니다(예: 판매세). API 서비스 사용을 위해 고객을 부과하는 API 공급자는 종종 세무를 부과하고 기존 규정을 준수하기 위해 송장에 반영해야 합니다.
3scale 청구는 구성된 경우 송장에 automatically included를 포함할 수 있습니다.
16.7.1. ECDHE 속도 필드 구성 링크 복사링크가 클립보드에 복사되었습니다!
please rate is the number (in percentage) that will be applied to the total cost in the invoice. dashboard를 구성하려면 관리 포털에서 다음 단계를 수행합니다.
- ECDHE & gt; 계정 > 필드 정의로 이동합니다.
- 계정 섹션에서 생성 을 클릭합니다.
-
[새 필드] 드롭다운 목록에서
vat_rate를 선택합니다. - 레이블 값을 설정합니다.
개발자의 Required,Read only 또는 Hidden 필드가 필요한지 여부를 나타내도록 확인란을 구성합니다.
참고: "Choices" 필드는 문자열만 허용하므로 이 필드를 사용할 수 없습니다.
- 생성을 클릭합니다.
16.7.2. ECDHE 코드 필드 구성 링크 복사링크가 클립보드에 복사되었습니다!
request_name_number는 다음과 같이 표시됩니다. Restic 코드를 구성하려면 대시보드의 관리 포털에서 다음 단계를 수행합니다.
- ECDHE & gt; 계정 > 필드 정의로 이동합니다.
- 계정 섹션에서 생성 을 클릭합니다.
-
[새 필드] 드롭다운 목록에서
vat_code를 선택합니다. - 레이블 값을 설정합니다.
- 개발자의 Required,Read only 또는 Hidden 필드가 필요한지 여부를 나타내도록 확인란을 구성합니다.
- 생성을 클릭합니다.
16.7.3. 계정의 value 설정 링크 복사링크가 클립보드에 복사되었습니다!
kubevirt 코드 및ECDHE rate 필드가 추가되면 개발자 계정 편집 양식에서 해당 값을 설정할 수 있습니다. 필드 정의에서 선택한 확인란에 따라 필드를 표시하고 개발자 포털의 개발자가 편집할 수도 있습니다.
code는 임의의 string일 수 있습니다.
*율은 숫자여야 합니다. 정수 또는 10진수가 허용되며(예: 21, 23.5 등)는 cost에 포함될 비용의 백분율을 나타냅니다.
16.7.4. Available 관련 정보 링크 복사링크가 클립보드에 복사되었습니다!
0이 아닌 rate가 구성된 개발자 계정에 대한 송장이 생성되면 송장에는 다음 라인 항목이 포함됩니다.
_Total cost (without <VAT rate>)_ +
_<VAT rate> Amount_ +
_Total cost (<VAT rate> <VAT rate value>% included)_
<VAT rate >는 IRQ rate 필드에 대해 라벨 세트로 교체되며 < VAT rate value >는 송장이 발행된 계정에 대해 구성된 값입니다.
request 코드는 label이 포함된 invoice 버전에 포함되어 있으며, Label은ECDHE 코드 필드 정의에서 라벨로 지정됩니다. 값은 개발자 계정 세부 정보에 설정된 값에 해당합니다.
vat_rate 및 vat_code 필드는 3scale 계정 관리 API에서 읽고 작성할 수도 있습니다.
16.8. 개발자 포털 보기 링크 복사링크가 클립보드에 복사되었습니다!
개발자는Create card information을 관리하고 개발자 포털에서 해당 송장을 볼 수 있습니다.
개발자가 개발자 포털의 청구 관련 요소를 볼 수 있도록 IRQ > 개발자 포털의 재무 전환 > 기능 gettingsible 상태가 될 수 있어야 합니다.
로그인한 사용자는 설정 > 대입 카드 세부 정보에서 직불 카드 세부 정보를 업데이트할 수 있습니다. 구성된 결제 게이트웨이에 따라 양식이 다를 수 있으며 사용자는 청구 주소를 먼저 입력해야 할 수 있습니다.
직불 카드 세부 정보는 3scale 데이터베이스에 저장되지 않습니다. 이러한 세부 정보는 결제 게이트웨이에 의해 관리됩니다. 카드 번호의 마지막 4자리만 결제 게이트웨이에서 제공하는 만료일 및 3scale 데이터베이스에 저장됩니다.
개발자는 개발자 포털에는 하나의 카드 카드만 가질 수 있습니다.
개발자 포털에서 개인 카드 세부 정보를 삭제할 수 없습니다. 카드 세부 정보를 삭제하려는 개발자 계정의 사용자는 API 공급자에게 시스템에서 email 카드 세부 정보를 삭제하도록 요청해야 합니다.
송장을 보려면 사용자가 Settings > Invoices 로 이동하여 각 송장에 대한 세부 정보를 표시하거나 invoice IRQ를 다운로드할 수 있습니다.
16.9. 직불 카드 흐름 링크 복사링크가 클립보드에 복사되었습니다!
16.9.1. 유료 계획 구독하기 링크 복사링크가 클립보드에 복사되었습니다!
개발자가 유료 계획에 등록하면 애플리케이션 자격 증명을 볼 수 있기 전에 해당 카드 세부 정보를 입력해야 합니다. 개발자가 처음으로 개발자 포털에 로그인하면 카드 세부 정보 페이지로 리디렉션됩니다. 다른 개발자 계정 페이지에 액세스하려고 하면 IRQ 카드 세부 정보 페이지로 다시 리디렉션됩니다.
해당 개발자 포털 템플릿을 사용자 지정하여 Liquid 태그를 사용하여 해당 카드 세부 정보 탭을 제외한 모든 메뉴 항목을 숨길 수 있습니다.
current_account Liquid drop은 email 카드 세부 정보가 없는 경우 true를 반환하지만 필요한 경우 true 를 반환하는 requires_credit_card_now 메서드를 노출하지만(관리자 포털에서 prompting이 구성된 경우에만 필요)이고 그렇지 않으면 false 입니다.
하위 메뉴 및 users_ menu 의 메뉴 항목 및 기타 사용자 인터페이스 요소를 다음과 같은 조건으로 래핑하여 숨길 수 있습니다.
{% unless current_account.requires_credit_card_now? %}
...
{% endunless %}
16.9.2. 유료 계획으로 무료 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
기존 애플리케이션의 계획 변경에는 개발자가 직접 계획 변경을 요청하거나 계획 변경을 요청하는 등 다양한 옵션을 구성할 수 있습니다. 애플리케이션이 무료로 유료 계획으로 업그레이드되는 경우 업그레이드하기 전에 개발자가 해당 카드 세부 정보를 입력해야 합니다. 이 설정은 다음 설정에 따라 [ECDHE_product_name] > 통합 > 설정,애플리케이션 계획 변경 섹션에서 구성할 수 있습니다.
변경 계획 변경, 그렇지 않은 경우 직접 변경 계획:
- 계획 변경
요청 - 유료 계획 요청
개발자가 변경 사항을 요청할 수 있는 경우에만 첫 번째 옵션을 선택하고 대금 카드 세부 정보를 입력한 후 수동으로 업그레이드를 수행합니다.
유료 계획으로 업그레이드하기 전에 거래 카드 세부 정보를 입력해야 개발자에게 알리는 경우 두 번째 옵션을 선택합니다. 계획 선택기 위젯에서 개발자는 "파일 이름 카드 세부 정보"를 가리킬 때까지 계획을 변경할 수 없습니다."라는 메시지가 표시됩니다.
16.10. "billing address" 필드 링크 복사링크가 클립보드에 복사되었습니다!
개발자가 개발자 포털의 email Card Details에 청구 주소를 입력하면 이 주소는 "legal" 계정 주소와 별도로 저장됩니다.
기본적으로 법률 주소는 발급 대상 필드의 송장에 표시됩니다. 그러나 개발자에게 법률 주소가 구성되어 있지 않지만 청구 주소만 있는 경우 후자의 송장에서 사용됩니다. 조직 이름은 이 경우 주소의 일부로 간주됩니다.
기본적으로 청구 주소는 관리 포털 또는 제품 API에 표시되지 않지만 다음과 같이 추가할 수 있습니다.
- ECDHE & gt; 계정 > 필드 정의로 이동합니다.
- 계정 블록에서 생성 을 클릭합니다.
- 드롭다운 목록에서 'billing_address'를 선택하고 레이블을 추가하고 읽기 전용 확인란을 선택한 다음 만들기를 클릭합니다.
이제 계정 관리 API 및 Webhook에서 계정의 XML 모델에 < billing_address > 필드가 표시됩니다. 해당 청구 주소는 계정에서 읽기 전용으로 표시되고 관리자 포털의 계정 편집 페이지가 표시됩니다.
청구 주소는 개발자 포털의 개발자가 카드 세부 정보 섹션에서 변경할 수 있습니다. 관리자는 관리 포털에서 청구 주소를 변경할 수 없지만 다음 필드( "추가 필드")를 사용하여 계정 관리 API의 계정 편집 끝점을 사용하여 이렇게 할 수 있습니다.
billing_address_name
billing_address_address1
billing_address_address2
billing_address_country
billing_address_city
billing_address_state
billing_address_zip
billing_address_phone
17장. 이메일 알림 링크 복사링크가 클립보드에 복사되었습니다!
청구와 관련된 다양한 이벤트가 API 공급자 및 개발자를 위한 이메일 알림과 관련이 있습니다.
17.1. 공급자 알림 링크 복사링크가 클립보드에 복사되었습니다!
3scale 계정(admins and members with billinging permission)은 계정 설정에서 청구 와 관련된 알림(상위 오른쪽의 아이콘) > 개인 > 알림 브릿지 섹션에서 구독하거나 구독 취소할 수 있습니다.
- 작업 필요: 송장 검토
- 청구 주기가 종료되기 전에 며칠 전에 발송되므로 송장을 고객에게 보내기 전에 검토할 수 있습니다.
- 고객 다운그레이드
- 고객이 월간 고정 가격으로 계획을 변경할 때 전송됩니다.
- 카드 만료
- 고객의 카드 만료가 곧 만료될 때 전송됩니다.
- 제공 오류 (retry)
- 결제에 실패할 때 전송되어 무료 송장을 작성하고 다시 시도합니다.
- 과금 오류 (final)
- 최종 결제 재시도에 실패할 때 전송되어 송장이 실패했습니다.
참고: 3scale 계정의 모든 관리자는 청구에 관한 알림을 받습니다.
17.2. 개발자 이메일 링크 복사링크가 클립보드에 복사되었습니다!
개발자 계정으로 전송된 이메일 알림은ECDHE > Messages > Email Templates 에서 구성할 수 있습니다. 다음 이메일을 사용할 수 있습니다.
- 구매자에 대한 카드 만료 알림
- 카드 발급이 곧 만료될 때 전송됩니다.
- 구매에 대한 송장이 성공적으로 청구되었습니다.
- 송장이 성공적으로 청구될 때 발송됩니다.
- 구입자가 재시도를 위한 송장 청구 실패
- 송장이 실패한 경우 발송되고 송장이 Unpaid state에 있을 때 전송되며, 이는 위약이 다시 발송됨을 의미합니다.
- 다시 시도하지 않은 구매에 대한 송장 청구 실패
- 3차에 송장이 실패했으며 송장이 Failed 상태로 전달되어 다시 시도하지 않습니다.
- 구매에 대한 예정된 송장 청구
- 개발자에 대한 송장이 발행될 때 전송됩니다.
개발자 계정의 모든 관리자 사용자는 위의 알림을 받습니다.
17.2.1. 청구 이메일 주소 링크 복사링크가 클립보드에 복사되었습니다!
재무 지원 이메일 필드의 청구 관련 문제 (예: billing@example.com ), Messages > Support Emails 에서 고객이 연락할 수 있는 이메일 주소를 구성할 수 있습니다.
이메일 템플릿은 Liquid 드롭 {{ provider.finance_support_email }} 가 있는 이메일 주소를 참조합니다.
18장. 청구 API 링크 복사링크가 클립보드에 복사되었습니다!
VolumeSnapshot API는 일반적인 청구 프로세스를 자동화하는 방법을 제공합니다.
tileing API의 모든 엔드포인트는 문서 (?) > 3scale API Docs > Thanosing API 의 관리 포털에서 확인할 수 있습니다.
LimitRangeing API에는 다음 요구 사항을 충족하는 유효한 액세스 토큰이 필요합니다.
- 공급자 계정의 admin 사용자 또는 "Billing" 권한이 있는 member 사용자에 속해야 합니다.
- "Billing API" 범위가 포함되어야 합니다.
송장 ID가 매개 변수로 필요한 경우 Friendly invoice ID가 아닌 송장 ID를 나타냅니다.
API 끝점의 XML 응답은 대부분 자체 설명이며 Invoice의 필드는 웹 및 IRQ 표현과 동일한 정보를 나타냅니다.
응답의 일부 주요 필드:
- creation_type: 3scale 자동 청구 프로세스로 생성된 송장 의 ' ECDHE ' 또는 ' 백리'' 값을 가질 수 있습니다.
- 공급자: API 공급자의 세부 정보(관리자 계정)는 송장의 섹션에 해당합니다.
- 구매자: 개발자 계정의 세부 사항은 송장 섹션에 발급되어 있습니다.
송장의 XML 표현에는 라인 -items 필드 아래에 라인 항목 목록도 포함되어 있습니다.
일부 라인 항목 (일반적으로는 이름, 설명, 수량 및 비용)을 제외하고 자동으로 생성된 항목의 경우 다음을 확인할 수 있습니다.
type: 라인 항목의 유형은 다음과 같은 값을 가질 수 있습니다.-
lineitem
::PlanCost- 고정 계획 비용을 위한 라인 항목용 -
lineitem::VariableCost- 변수 비용을 위한 라인 항목용
-
lineitem
-
metric_id: 변수 비용 줄 항목의 경우 - 비용이 연결된 메트릭의 ID -
contract_id: 비용이 관련된 서비스 또는 애플리케이션의 ID
VI 부. 개발자 계정 관리 링크 복사링크가 클립보드에 복사되었습니다!
19장. 개발자 추가 링크 복사링크가 클립보드에 복사되었습니다!
다음은 API에 액세스하기 위해 새 개발자 계정을 추가하는 단계입니다.
개발자를 수동으로 초대하도록 워크플로를 구성한 경우 새 개발자를 추가하는 방법을 설명합니다.
19.1. 새 개발자 계정 생성 링크 복사링크가 클립보드에 복사되었습니다!
- 관리 포털의 ECDHE 섹션에서 계정 링크를 따릅니다.
- 생성을 클릭합니다.
관리자는 일부 필수 필드도 건너뛸 수 있습니다. 사용자를 안전하게 계정에 초대하려면 암호 필드를 건너뛸 수도 있습니다. 그러나 이 기본 관리자 계정의 이메일은 모든 사용자 간에 고유해야 합니다.
19.2. 애플리케이션 설정 링크 복사링크가 클립보드에 복사되었습니다!
계정에 대한 앱 키를 미리 구성하려는 경우 개발자 대신 애플리케이션을 추가할 수도 있습니다. 그렇지 않으면 개발자가 수행할 초기 단계 중 하나로 두십시오.
19.3. 개발자에게 알립니다. 링크 복사링크가 클립보드에 복사되었습니다!
개발자에게 이메일 초대를 수동으로 보내거나 단계에 따라 초대 개발자 기능을 사용할 수 있습니다.
20장. 개발자 승인 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 등록 워크플로의 모든 단계에 대해 승인을 수행하는 방법을 보여줍니다.
수동 승인 단계를 통해 등록 워크플로를 구현했으면 몇 가지 옵션이 있습니다. 승인 프로세스는 트리거 및 승인 상태에 따라 약간 다릅니다. 이메일 알림이 표시되면 다음 섹션의 지침을 따르십시오. 그렇지 않으면 계정, 서비스 또는 애플리케이션을 승인할지 여부에 따라 달라집니다.
20.1. 이메일 알림에서 승인 링크 복사링크가 클립보드에 복사되었습니다!
개발자 중 하나에 승인이 보류 중인 항목이 있음을 알리는 이메일 알림을 수신하면 해당 항목의 URL을 브라우저로 복사하고 붙여넣을 수 있으며 승인을 위해 페이지로 직접 이동합니다.
20.2. 계정 승인 링크 복사링크가 클립보드에 복사되었습니다!
특정 계정을 검색하거나 "종료"(승인을 위해) 상태에 있는 모든 계정을 필터링하려면 DestinationRule > Accounts > listing로 이동합니다. 보류 중인 계정만 표시하려면 State (상태) 목록에서 "Pending"를 선택하고 Search 를 클릭합니다.
각 행에서 직접 개별 승인을 수행하거나 한 번에 여러 행을 선택하고 대량 승인을 수행할 수 있습니다.
20.3. 서비스 승인 링크 복사링크가 클립보드에 복사되었습니다!
특정 서브스크립션을 서비스에 검색하거나 "종료"(승인용) 상태에 있는 모든 서브스크립션을 필터링하려면ECDHE > Accounts > Subscriptions로 이동합니다.
서브스크립션을 보려면 FlexVolume > 계정 > 사용 규칙에서 서비스 계획을 활성화합니다.
한 번에 하나의 서브스크립션 또는 여러 개를 선택하고 대규모 승인을 수행할 수 있습니다.
20.4. 애플리케이션 승인 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션을 검색하거나 "종료"(승인용) 상태에 있는 모든 애플리케이션을 필터링하려면 다음을 수행합니다.
- ECDHE > ; 애플리케이션 > 목록 으로 이동합니다.
- State (상태) 드롭다운 목록에서 "pending"을 선택하고 Search 를 클릭합니다.
한 번에 하나의 애플리케이션 또는 여러 애플리케이션을 선택하고 대규모 승인을 수행할 수 있습니다.
개발자 계정의 세부 정보 페이지에서 시작하여 승인하려는 애플리케이션을 선택한 다음 애플리케이션 세부 정보 페이지에서 승인할 수도 있습니다.
21장. 앱 계획 변경 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 계정, 서비스 또는 애플리케이션에 대한 계획을 변경할 수 있습니다.
관리자는 언제든지 개발자에 대한 계획을 변경하거나 개발자가 시작하는 계획 변경 요청에 대한 응답으로 변경할 수 있습니다.
변경 계획 단계는 변경 중인 계획 유형에 따라 약간 다릅니다.
21.1. 계정 계획 변경 링크 복사링크가 클립보드에 복사되었습니다!
특정 계정을 검색하거나 필터링하려면 DestinationRule > ; 계정 > 목록으로 이동합니다.
한 번에 하나 이상의 행을 선택하고 계획을 변경할 수 있습니다.
21.2. 서비스 계획 변경 링크 복사링크가 클립보드에 복사되었습니다!
특정 서브스크립션을 서비스에 검색하거나 필터링하려면ECDHE > 계정 > 서브스크립션으로 이동합니다.
설정 페이지에서 서비스 계획을 활성화한 경우에만 서브스크립션을 볼 수 있습니다.
한 번에 하나 또는 여러 서브스크립션을 선택하고 계획을 변경할 수 있습니다.
21.3. 애플리케이션 계획 변경 링크 복사링크가 클립보드에 복사되었습니다!
특정 애플리케이션을 검색하거나 필터링하려면 DestinationRule > ; 애플리케이션 > 목록으로 이동합니다.
한 번에 하나 또는 여러 애플리케이션을 선택하고 계획을 변경할 수 있습니다.
또 다른 시나리오는 개발자 계정의 세부 정보 페이지에서 시작하는 것입니다. 여기에서 계획을 변경할 애플리케이션을 선택합니다. 애플리케이션 세부 정보 페이지에서 계획을 변경할 수 있습니다.
21.3.1. 더 많은 정보 링크 복사링크가 클립보드에 복사되었습니다!
다른 표준 계획으로 변경하는 대신 특정 앱에 대해서만 변경을 수행하려는 경우 사용자 지정 계획 기능을 사용할 수 있습니다.
22장. 개발자 문의 링크 복사링크가 클립보드에 복사되었습니다!
이 가이드에서는 3scale 및 외부를 통해 특정 애플리케이션을 관리하는 개발자 계정을 확인한 다음 해당 애플리케이션과 통신하는 방법을 설명합니다.
API 작업 중에 API를 사용하는 개발자에게 문의해야 할 수도 있습니다.
22.1. 시스템에서 관련 애플리케이션 및 계정을 찾습니다. 링크 복사링크가 클립보드에 복사되었습니다!
해당 애플리케이션을 관리하는 계정과 개발자가 이미 알고 있는 경우 아래와 같이ECDHE > 계정 > 계정 > 목록의 계정 페이지에서 해당 계정으로 이동합니다.
애플리케이션 ID 또는 API 키만 있는 경우ECDHE > 계정 > 목록 의 계정 페이지에서 검색 상자를 사용하여 관련 계정을 찾을 수 있습니다. 애플리케이션 검색에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
22.2. 개발자에게 내부 메시지 전송 링크 복사링크가 클립보드에 복사되었습니다!
아래와 같이 계정 프로필 페이지에 있으면 메시지 아이콘을 클릭합니다.
여기에서 생성된 메시지는 계정 시스템 대시보드로 모두 전송됩니다. 여기서 계정의 모든 개발자가 해당 내용을 볼 수 있으며, 해당 계정 내에 admin 상태가 있는 개발자 계정의 사용자에게 이메일로 전송됩니다.
22.3. 다른 방법의 연락처 링크 복사링크가 클립보드에 복사되었습니다!
긴급 상황이며 이메일이 귀하의 목적에 맞게 충분히 빠르지 않을 경우 가입시 개발자가 제출한 연락처 정보를 사용할 수도 있습니다.
- 회사 계정 페이지에서 (단일 연락처 정보를 포함 할 수 있지만 전화 번호를 포함 할 수 있습니다)
- 사용자 파일에 대한 개발자/사용자 관련 정보
등록시 전화 번호를 필수 필드로 만들 수 있습니다.
23장. 계획 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션을 완료하면 특정 개발자의 애플리케이션 계획을 사용자 지정했습니다.
애플리케이션 계획은 개발자 커뮤니티의 다양한 세그먼트에 표준 정책을 적용하는 좋은 방법입니다. 그러나 고유한 요구 사항에 따라 개별 개발자의 표준 계획을 사용자 지정할 수 있는 유연성이 있습니다.
계획이 사용자 정의되면 원래 계획에 대한 링크가 손실됩니다. 원래 계획을 변경하면 사용자 정의 계획이 이러한 변경 사항을 상속하지 않습니다. 따라서 효과적으로 관리할 수 없는 사용자 지정 계획을 너무 많이 사용하기 전에 이 사용자 정의 기능을 사용하지 않아야 합니다.
개발자는 현재 청구 기간이 이미 진행 중이므로 다음 가격 계층으로 업그레이드하지 않고 현재 제한을 늘리려고 합니다. 사용자 지정은 제한 및 변수 비용만 부과할 수 있도록 하여 이러한 상황을 처리하는 좋은 방법이 될 수 있습니다. 또한 다음 청구 달의 업그레이드를 권장하는 데 도움이 됩니다.
23.1. 계정 선택 링크 복사링크가 클립보드에 복사되었습니다!
관심 있는 개발자 계정의 세부 정보 페이지를 보려면 다음을 수행합니다.
- ECDHE > ; 계정 > 목록으로 이동합니다.
- 개발자 계정 선택
23.2. 애플리케이션 선택 링크 복사링크가 클립보드에 복사되었습니다!
사용자 지정할 계획이 있는 애플리케이션을 선택합니다.
23.3. 애플리케이션 계획 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
옵션을 "customize"로 선택합니다. 이렇게 하면 이 계정이 소유한 애플리케이션에 대해 모든 계획 요소를 사용자 지정할 수 있는 페이지가 제공됩니다.
23.3.1. 더 많은 정보 링크 복사링크가 클립보드에 복사되었습니다!
계획을 사용자 정의하기 위해 단계를 수행하기 전에 새로운 표준 계획 (개발자 포털에 표시되지 않음)으로 더 잘 벗어나지 않는 경우 항상 먼저 고려하십시오. 그러면 표준 계획을 변경 하므로 개발자 파트너 중 하나 이상에 적용되는 경우 재사용의 이점을 얻을 수 있습니다.
24장. 활성화 등록 링크 복사링크가 클립보드에 복사되었습니다!
셀프 서비스 또는 수동 모드를 구현하여 개발자 등록을 구성합니다.
개발자의 워크플로우를 셀프 서비스 또는 수동 초대 전용으로 구성할 수 있습니다. 셀프 서비스 서명은 개발자가 개발자 포털을 통해 수행하지만 수동 초대는 관리자 포털을 통해 관리자가 처리합니다.
기본적으로 개발자는 직접 등록할 수 있습니다. 개발자 셀프 서비스를 활성화하는 경우 개발자 계정을 활성화하기 전에 관리자 승인이 필요할 수 있습니다.
이렇게 하려면ECDHE > 계정 > 설정 > 사용 규칙으로 이동합니다.
25장. 애플리케이션 검색 링크 복사링크가 클립보드에 복사되었습니다!
이 가이드가 끝나면 이름, API 키 또는 애플리케이션 식별자를 기반으로 관리 포털에서 애플리케이션을 빠르게 찾을 수 있습니다.
API 작업 중에 지원 목적으로 또는 구성을 변경하기 위해 또는 애플리케이션이 잘못 작동하고 비활성화되어야 하므로 API에 액세스하는 애플리케이션에 대한 정보를 빠르게 찾을 수 있어야 할 수 있습니다.
25.1. 필요한 정보 얻기 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션을 찾으려면 해당 애플리케이션이 속한 계정의 이름 또는 애플리케이션 이름이 필요합니다. 이 정보가 없는 경우 액세스 로그를 확인할 수 있습니다. 검색을 수행하려면 애플리케이션(ECDHE > 애플리케이션> 목록)으로 이동합니다.
식별자로 인증 유형을 검색하는 경우 다음 정보가 필요합니다.
- API 키 전용 인증 패턴의 경우: API 키
- 앱 ID 및 앱 키 인증 패턴의 경우: 앱 식별자(app 키로 검색은 지원되지 않음)
- OpenID Connect 인증 패턴의 경우: client_id(시크릿에 대한 검색은 지원되지 않음)
25.2. 애플리케이션 검색 링크 복사링크가 클립보드에 복사되었습니다!
지정된 애플리케이션을 검색하려면 애플리케이션 페이지(ECDHE >Applications > listing)로 이동하여 아래 이미지에 표시된 대로 검색 상자를 사용합니다.
25.3. 애플리케이션 정보에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
결과가 반환되면 액세스하려는 애플리케이션을 클릭합니다. 그러면 아래 이미지에 표시된 것과 같은 정보가 포함된 애플리케이션의 홈페이지로 이동합니다.
26장. 개발자 초대 링크 복사링크가 클립보드에 복사되었습니다!
이 단계를 완료하면 개발자 계정에 새 개발자 사용자를 추가합니다.
개발자 계정을 수동으로 생성할 때 관리 포털을 통해 개발자 사용자를 해당 계정에 초대할 수 있습니다.
- Audience > Accounts > Listing으로 이동합니다.
- 해당 계정을 선택합니다.
- "In invitationations"를 선택한 다음 Invite user 를 클릭합니다.
27장. 서비스에서 개발자 설명 취소 링크 복사링크가 클립보드에 복사되었습니다!
관리자는 서비스에서 개발자의 구독을 취소할 수 있습니다. 서비스 사용 중단 시 하나의 특정 개발자 또는 여러 개발자의 경우 이 작업을 수행해야 할 수 있습니다.
27.1. 서비스에서 단일 개발자 구독 취소 링크 복사링크가 클립보드에 복사되었습니다!
관리 포털을 통해 서브스크립션하는 서비스에서 단일 개발자 구독 취소:
- 관리 포털의 대시보드에서 DestinationRule > 계정 > 목록 > [ 계정 선택] > 서비스 서브스크립션 으로 이동합니다.
- 개발자가 삭제할 서비스에 대해 Unsubscribe 를 선택합니다.
27.2. 서비스에서 여러 개발자를 구독 취소 링크 복사링크가 클립보드에 복사되었습니다!
더 이상 사용되지 않거나 삭제된 서비스에서 여러 개발자를 취소하려면 대규모 작업을 수행합니다.
이 방법은 삭제되거나 일시 중지된 서비스에만 적용됩니다. 활성 서비스에서 대규모 서브스크립션 취소 작업을 수행할 수 없습니다.
- 대시보드에서:ECDHE > 계정 > 서브스크립션으로 이동합니다.
- 대량 상태 변경을 수행합니다.
- 서비스 드롭다운 메뉴를 사용하여 개발자의 구독을 취소할 서비스를 식별합니다.
- 왼쪽의 확인란을 사용하여 취소할 개발자를 선택합니다.
- Change State > Suspend 를 선택하여 선택한 개발자 서브스크립션을 일시 중지합니다.
서비스 계획을 활성화해야 합니다.
28장. 애플리케이션 일시 중단 링크 복사링크가 클립보드에 복사되었습니다!
이 가이드에서는 애플리케이션의 모든 키 및 액세스 토큰을 비활성화하는 방법을 설명합니다.
애플리케이션이 API를 잘못 사용하고 다른 트래픽에 영향을 미치는 경우 개발자에게 연락하여 코드 또는 구성을 수정하도록 요청하기 전에 해당 작업을 신속하게 중단해야 할 수 있습니다.
28.1. 애플리케이션 검색 링크 복사링크가 클립보드에 복사되었습니다!
계정 또는 애플리케이션 탭에서 또는 여기에 설명된 대로 검색하여 애플리케이션을 찾을 수 있습니다.
28.2. 애플리케이션 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션을 찾아서 애플리케이션 요약 페이지를 보려면 'State' 값 옆에 있는 일시 중지 아이콘을 클릭합니다. 이 작업은 API에서 애플리케이션을 즉시 비활성화하고 모든 키가 작동하지 않도록 일시 중지합니다. 이러한 애플리케이션 키를 사용한 호출은 제어 시스템에서 거부됩니다.
문제가 있는 동작이 수정되면 동일한 버튼을 사용하여 애플리케이션을 일시 정지할 수 있습니다.
에이전트에서 캐싱을 사용하는 경우 일시 중지 시간은 즉각적이 아니지만 짧은 시간 초과가 필요할 수 있습니다.
28.3. 개발자 연락처 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션 개발자에게 문의하는 방법은 워크플로우 및 정책에 따라 다릅니다. 동일한 페이지에서 계정 이름을 클릭하면 애플리케이션을 소유한 계정의 키 관리자를 식별할 수 있는 계정 보기로 이동할 수 있습니다. 표시된 대로 이메일 또는 전송 메시지 버튼을 클릭하여 사용자에게 대시보드 메시지를 생성할 수 있습니다.
29장. 애플리케이션 삭제 링크 복사링크가 클립보드에 복사되었습니다!
관리 포털을 통해 애플리케이션을 삭제하려면 다음 단계를 수행해야 합니다.
옵션 1: [gradle_API_name]의 모든 애플리케이션 목록에서 애플리케이션을 삭제합니다.
- 대시보드에서 [Remote_API_name] 을 클릭합니다.
- 개요 탭을 클릭합니다.
- 개요 페이지의 왼쪽 패널에서 애플리케이션을 클릭합니다.
- 목록 선택 .
- 애플리케이션을 클릭합니다.
- 애플리케이션 세부 정보가 포함된 페이지가 표시됩니다. 편집 을 클릭합니다.
- 애플리케이션을 삭제하려면 삭제를 클릭합니다.
- 확인 메시지가 표시됩니다. 확인을 클릭하여 삭제를 확인합니다.
옵션 2: 특정 애플리케이션 계획을 기반으로 애플리케이션을 삭제합니다.
- 관리 포털에서 대시보드 를 클릭합니다.
- API 를 선택합니다.
- 게시된 애플리케이션 계획에서 애플리케이션을 선택합니다.
- 애플리케이션을 클릭합니다.
- 애플리케이션 세부 정보가 포함된 페이지가 표시됩니다. 편집 을 클릭합니다.
- 애플리케이션을 삭제하려면 삭제를 클릭합니다.
- 확인 메시지가 표시됩니다. 확인을 클릭하여 삭제를 확인합니다.
또는 애플리케이션 삭제라는 작업을 통해 3scale API Docs를 통해 애플리케이션을 삭제 할 수도 있습니다.
30장. API 삭제 링크 복사링크가 클립보드에 복사되었습니다!
서비스를 삭제하여 API를 삭제할 수 있습니다. 서비스를 삭제하면 API의 애플리케이션, 애플리케이션 계획, 메트릭, 가격 규칙, 기능, 서비스 계획 및 서브스크립션이 제거됩니다.
API를 삭제하려면 다음을 수행합니다.
- [gradle_product_name] > 개요 > 편집으로 이동합니다.
- 서비스 삭제 섹션에서 서비스를 삭제할 링크를 클릭합니다.
VII 부. 분석 링크 복사링크가 클립보드에 복사되었습니다!
31장. API 분석 링크 복사링크가 클립보드에 복사되었습니다!
이 안내서는 API 분석을 조정하여 시간이 지남에 따라 주요 애플리케이션 및 추세를 보고 알아야 하는 항목을 추적할 수 있도록 설계되었습니다.
API 사용 방법을 아는 것은 트래픽을 관리하고, 최대 사용자를 프로비저닝하며, 상위 사용자를 식별하여 API를 통해 더 큰 성공을 달성하는 데 중요한 단계입니다.
31.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
이 가이드를 사용하기 전에 시작하기 섹션의 지침을 완료하십시오.
이 가이드에서는 기존 3scale 코드 플러그인 중 하나를 사용하여 통합을 수행한다고 가정합니다. 다른 통합 방법을 사용하여 유사한 흐름을 따를 수 있습니다. 사용 가능한 통합 옵션에 대한 자세한 내용은 설명서의 운영 APIcast 장을 확인하십시오.
31.2. 추적할 메트릭 및 방법 확인 링크 복사링크가 클립보드에 복사되었습니다!
3scale은 API 제품 통계에 대해 무한하게 확장 가능한 데이터 리포지터리 역할을 하며 API 제품에 대한 거의 모든 메트릭을 추적할 수 있습니다. 예를 들어 다음과 같습니다.
- hits/ECDHEs: API 제품에 대한 호출입니다. 히트는 기본적으로 모든 API의 메트릭으로 포함됩니다. 히트는 API 제품에 대한 전체 호출이거나 API 제품의 개별 메서드로 분류될 수 있습니다.
- 데이터 전송: API 제품을 통해 업로드 및 다운로드된 MB/GB의 데이터 양
- CPU 시간: API 제품에 대한 호출과 관련된 컴퓨팅 시간 (또는 기타 내부 리소스)
- 반환된 결과: 반환되는 레코드 수 또는 데이터 개체 수입니다.
- 디스크 스토리지: 계정에서 사용하는 총 디스크 스토리지
API 제품과 관련된 더 많은 메트릭을 추적할 수 있습니다. 3scale은 시간 경과에 따라 증가될 수 있는 수량에 따라 임의의 수의 메트릭과 방법을 추적할 수 있습니다.
31.3. 메트릭 및 방법 생성 링크 복사링크가 클립보드에 복사되었습니다!
지표를 선택한 후 관리 포털에서 등록합니다. [gradle_product_name] > 통합 > 방법 및 지표 로 이동합니다.
API에 메트릭 및 메서드를 추가할 수 있습니다. Friendly 이름과 시스템 이름을 지정합니다. 이 이름은 플러그인 구성에서 나중에 사용됩니다. 메서드 및 지표 생성에 대한 자세한 내용은 3scale에서 API 정의를 참조하십시오.
31.4. 보고서 설정 링크 복사링크가 클립보드에 복사되었습니다!
3scale 시스템을 추적 지표의 이름으로 구성하면 플러그인 설정에서 올바른 메트릭을 보고해야 합니다. 이 작업을 수행하는 정확한 방법은 사용 중인 플러그인 또는 통합 방법에 따라 다릅니다. 기본적으로 플러그인은 적중 (API 트랜잭션) 메트릭만 보고합니다.
일반적으로 이러한 단계를 수행해야합니다.
- 애플리케이션은 들어오는 API 호출에 의해 결정된 대로 적절한 지표/메서드 이름을 플러그인에 전달해야 합니다. metric/method 값과 필요한 증가는 플러그인이 노출하는 authorize 및/또는 report 메서드의 인수입니다.
- 3scale Service Management API를 사용하여 트래픽을 보고할 수도 있습니다. 3scale API ActiveDocs 섹션에서 다양한 엔드포인트에 대한 정보를 확인할 수 있습니다. 3scale ActiveDocs는 문서 → 3scale API Docs 섹션에 있는 관리 포털에서 사용할 수 있습니다.
특정 API 메서드의 트래픽을 보고할 때 지표 인수에서 메서드 시스템 이름을 사용합니다. 이렇게 하면 보고된 방법과 적중 지표에 대한 카운터가 자동으로 증가합니다.
31.5. 트래픽이 올바르게 보고됨 확인 링크 복사링크가 클립보드에 복사되었습니다!
API 및 3scale 연결이 설정되면 API로 트래픽을 보내고 API NSX 대시보드에 등록할 수 있습니다. 이 섹션의 단계를 수행하려면 기존 개발자 계정과 API 인증 정보가 포함된 애플리케이션이 필요합니다. 다음 단계에 따라 개발자 계정을 생성하고 API 자격 증명을 사용하여 애플리케이션을 가져옵니다.
- 시작하기 가이드 를 엽니다.
- ECDHE & gt; 애플리케이션 > 목록으로 이동하여 기존 애플리케이션 목록을 확인합니다.
- 이름을 클릭하여 애플리케이션을 선택합니다.
선택한 애플리케이션의 API 자격 증명을 찾습니다. 인증 정보는 선택한 인증 유형에 따라 다르며 사용자 키(API 키), 애플리케이션 ID 및 애플리케이션 키 또는 클라이언트 ID 및 클라이언트 시크릿일 수 있습니다. 사용 가능한 인증 모드에 대한 자세한 내용은 인증 패턴 문서를 참조하십시오.
그림 31.1. API 인증 정보
-
이러한 키를 사용하여 일반적인 방식으로 API를 호출합니다. 예를 들어 명령줄에서
cURL을 사용하거나 GET 메서드를 사용하는 API 끝점의 브라우저에서 입니다. 정확한 호출은 API 제품의 방법 구조에 따라 달라집니다. 이러한 호출의 트래픽은 API 제품의 NSX 섹션에 표시됩니다.
31.6. 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
NSX 섹션의 사용량 차트에 트래픽이 표시되지 않는 경우 다음 검사를 수행합니다.
authorize/report 호출이 올바르게 응답됩니까?
모든 플러그인은 사전 결정된 응답 코드가 있는 3scale 서비스 관리 API를 호출합니다. 유효한 키 호출에서 HTTP 코드 200 을 사용하여 응답을 반환해야 합니다. 보고서 호출은 코드 202 로 응답해야 합니다.
통합 오류 콘솔에 오류가 있습니까?
3scale에서 감지한 통합 오류의 로그는 [your_product_name] > analytics > Integration Errors 에서 확인할 수 있습니다.
올바른 메트릭과 메서드 이름이 사용됩니까?
실패의 가장 일반적인 이유는 보고서 호출에 전달된 메서드와 지표 이름이 관리 포털의 API 설정에서 생성된 이름과 일치하지 않기 때문입니다. 각 메트릭/메서드에 올바른 시스템 이름을 사용하고 있는지 확인합니다.
31.7. 분석을 보는 사용자 제어 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 사용량 통계는 관리 포털과 개발자 포털을 통해 애플리케이션을 생성한 개발자에게 API 공급자에 표시됩니다. (각 개발자는 자체 애플리케이션에 대한 사용량 통계만 볼 수 있습니다.) 개발자 포털에서 분석 보기를 숨길 수 있습니다. 개발자 포털 사용자 지정에 대한 자세한 내용은 개발자 포털 생성 섹션을 참조하십시오.
31.8. API 및 이메일 보고서를 통해 분석 데이터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
DestinationRule 섹션의 사용 그래프 외에도 API 제품의 분석 데이터를 가져오는 다른 방법이 있습니다.
Analytics API
3scale NSX API를 사용할 수 있습니다. XML 또는 JSON 형식으로 API 제품에 대한 모든 분석 데이터를 추출하는 유연한 방법입니다.
매일 및 매주 트래픽 보고서(SaaS만 해당)
이러한 보고서는 API 제품 및 상위 애플리케이션에 대한 새 구독자에 대한 정보를 포함하여 트래픽에 대한 집계된 데이터를 제공합니다. 관리 포털의 계정 설정(gear 아이콘) > 개인 > 알림 환경 설정에서 이러한 보고서를 활성화하려면ECDHE report 및 Weekly report 확인란을 찾습니다. 활성화된 경우 이러한 보고서는 3scale 계정의 admin 사용자에게 이메일로 전송됩니다.
CSV 내보내기(SaaS만 해당)
각 분석 보기 페이지에 다운로드 CSV 링크가 있으며 .csv 형식으로 사용량 통계를 다운로드할 수 있습니다.
32장. 분석 확장 링크 복사링크가 클립보드에 복사되었습니다!
이 문서에서는 내장된 Red Hat 3scale API Management 분석의 현재 기능을 확장하는 스크립트를 생성하는 방법을 설명합니다.
엔터프라이즈 계정에서만 계정 관리 및 DestinationRule API를 사용하면 원하는 형식으로 필요한 사용자 정의 정보를 가져오는 스크립트를 생성할 수 있습니다. 이 문서에서는 특정 사용 사례를 설명하지만 3scale에서 필요한 모든 데이터를 가져오는 데 동일한 방법을 사용할 수 있습니다.
32.1. 사용자 정의 스크립트의 이유 링크 복사링크가 클립보드에 복사되었습니다!
3scale은 API 대시보드에서 사용 가능한 기능을 지속적으로 개선합니다. 그러나 개발 계획보다 앞서 있을 수 있으며 아직 지원되지 않는 특정 요구 사항이 있을 수 있습니다.
API 관리 요구를 충족하기 위해 3scale은 항상 모든 데이터에 액세스할 수 있는 도구를 제공합니다. 그러나 사용자 지정 스크립트에는 약간의 비용이 듭니다. 스크립트를 작성하는 데 일부 리소스가 필요하지만 이 문서에 나와 있는 것처럼 비용이 너무 높지 않습니다. 더 중요한 것은ECDHE를 통해 생각할 수 있는 모든 사용 사례를 구현할 수 있는 완전한 유연성과 제어 기능을 제공합니다.
32.2. 실제 예 링크 복사링크가 클립보드에 복사되었습니다!
최근 고객은 3scale로 간소화된 방식으로 해결할 수 없는 매우 구체적인 요구 사항을 제시했습니다.
주당 수천 명의 새로운 개발자를 확보했습니다. 3scale API Management Platform으로 인해 이러한 성공을 유지할 수 있었습니다. 온보딩을 사용하면 개발자가 어려운 작업이 될 수 있습니다. 3scale은 주요 프로비저닝, 가입 워크플로 및 이메일 통신과 같은 필수 사항을 자동화할 수 있습니다. 지금까지는 매우 좋습니다.
그러나 3scale과 함께 할 수 없는 일이 있었습니다. 이는 매우 중요했습니다. 많은 사람이 온보딩하고 있기 때문에 API와의 참여를 기반으로 새 개발자를 분류하여 운영 및 마케팅팀이 새로운 개발자와 보다 효과적으로 상호 작용할 수 있는 간단한 방법이 필요했습니다.
이러한 기능은 적어도 필요한 수준의 세부 사항은 3scale 내장 분석 도구에서 아직 사용할 수 없습니다. 그러나 모든 데이터를 이미 사용할 수 있으므로 3scale 계정 및 analytics API를 사용하여 추출할 수 있습니다.
32.3. 예: 고객 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
지난 10 일 동안 무료 평가 계획에 가입 한 새로운 개발자가 얼마나 많은 다른 방법으로 가입했는지 알고 싶습니다.
먼저, 얼마나 많은 개발자가 가입했는지 알고 싶었지만 API를 사용하지 않았습니다. 이 정보로 하고 싶었던 내용은 이 문서에서 다루지 않지만 API 채택에 도움이 될 중요한 정보입니다.
두 번째, API를 사용한 개발자를 두 그룹으로 나누고자 했습니다.
- 10일의 첫 절반을 사용한 다음 API를 사용하여 중지한 후 일정 기간 동안 사용한 개발자입니다. 이 개발자는 이를 시도했지만 비활성화되었습니다.
- API를 일관되게 사용하고 있는 개발자입니다. 성장 또는 감소 비율을 알고 싶은 사람을 위해.
이 정보는 3scale 기본 제공 분석에서 확인할 수 있습니다. 문제는 집계된 것으로 표시할 수 있는 보기가 없기 때문에 전체 환경이 매우 번거롭다는 것입니다.
이 문제에 대한 일반적인 해결책은 이러한 분류가 향후 분석 개선의 일부가 될 것입니다. 그러나 지금 필요한 경우 문제를 해결하지 못합니다. 3scale에서는 릴리스 일정에 따라 필요한 모든 작업을 수행할 수 있는 도구를 제공합니다.
32.4. 실습 구현 링크 복사링크가 클립보드에 복사되었습니다!
32.4.1. 회수 레시피 링크 복사링크가 클립보드에 복사되었습니다!
이 레시피는 일반적으로 사용자 정의 작업을 수행하는 데 더 나은 결과를 제공합니다.
ActiveDocs와 함께 약간의 Tinker. 3scale ActiveDocs는 계정 설정 > 통합 > 3scale API 문서의 관리 포털에서 사용할 수 있습니다. 3scale에는 ActiveDocs로 사용 가능한 모든 API가 있으므로 브라우저에서 사용해 볼 수 있습니다. 이를 통해 귀하의 요구에 가장 적합한 요청을 찾고, 요청(curl과 같은)을 가져오고, 응답을 받을 수 있습니다. 예를 참조하십시오.
이는 분석을 확장하는 데 스크립트에서 사용할 모든 애플리케이션을 가져오는 API 요청의 ActiveDocs입니다.
- ActiveDocs를 사용하여 조사를 마쳤으면 원하는 스크립팅 언어(예: Ruby)에 요청을 배치합니다. ActiveDocs에서 제공하는 요청 및 응답으로 인해 API가 수행하는 작업을 더 쉽게 탐색할 수 없었습니다.
- 필요한 작업을 정확히 수행하는 스크립트가 있을 때까지 반복합니다. 확장 분석 예제의 경우 스크립트는 gist로 사용할 수 있습니다. 귀하의 계정에서 시도할 수 있습니다.
보행자로서, 이것은 진행하기에 가장 쉬운 방법입니다. ActiveDocs를 사용하면 API가 무엇을 할 수 있는지 빠르게 파악할 수 있습니다. 그런 다음 수행하려는 작업에 필요한 3개 또는 4개의 요청을 찾아 스크립트를 함께 배치하는 것은 문제일 뿐입니다.
32.4.2. 단계별 가이드 링크 복사링크가 클립보드에 복사되었습니다!
이 고객이 원하는 사용자 지정 분석을 달성하기 위한 단계는 다음과 같습니다.
- 전체 애플리케이션 목록을 검색합니다. 이 작업을 수행하려면 페이지 작성이 필요합니다.
def api_call_applications_list(domain, provider_key)
done = false
res = Array.new
page = 1
while !done
url = "https://#{domain}/admin/api/applications.xml?provider_key=#{provider_key}&page=#{page}&per_page=100"
page += 1
response = RestClient.get url
raise Exception.new("Wrong response code (#{response.code}) in request #{url}") if response.code!=200
document = Nokogiri::XML(response.to_str) done = document.xpath("applications/@current_page").text == document.xpath("applications/@total_pages").text
document.xpath("//application").each do |item|
app = Hash.new
app["created_at"] = DateTime.parse(item.xpath("created_at").text)
app["plan_name"] = item.xpath("plan/name").text
app["service_id"] = item.xpath("plan/service_id").text
app["account_id"] = item.xpath("user_account_id").text
app["id"] = item.xpath("id").text
res << app
end
end
return res
end
- 기준을 충족하지 않는 애플리케이션을 필터링합니다. 즉, 계획이 "예: 평가"여야 하며 10일보다 최신 상태여야 합니다.
def filter_applications(domain, provider_key, plan_name, num_of_days)
res = api_call_applications_list(domain, provider_key)
res.each do |item|
res.delete(item) if item["plan_name"] != plan_name
res.delete(item) if item["created_at"] > (DateTime.now - num_of_days)
end
return res
end
- 그런 다음 기준을 충족하는 각 애플리케이션에 대해 지난 10일 동안 애플리케이션의 히트 횟수를 의미합니다.
def api_call_application_usage(domain, provider_key, application_id, metric, from, to, granularity)
url = "https://#{domain}/stats/applications/#{application_id}/usage.xml?provider_key=#{provider_key}&metric_name=#{metric}&since=#{from}&until=#{to}&granularity=#{granularity}"
response = RestClient.get url
raise Exception.new("Wrong response code (#{response.code}) in request #{url}") if response.code!=200
document = Nokogiri::XML(response.to_str)
return document.xpath("//usage/data/values").text.split(",")
end
- 마지막으로 개발자의 정보가 계정 오브젝트에 저장되므로 계정에 애플리케이션을 상호 참조해야 합니다.
def api_call_account_read(domain, provider_key, account_id)
url = "https://#{domain}/admin/api/accounts/#{account_id}.xml?provider_key=#{provider_key}"
response = RestClient.get url
raise Exception.new("Wrong response code (#{response.code}) in request #{url}") if response.code!=200
document = Nokogiri::XML(response.to_str)
account = Hash.new
account["email"] = document.xpath("//users/user/email").text
account["name"] = document.xpath("//users/user/first_name").text + " " + document.xpath("//users/user/last_name").text
return account
end
이제 모든 것을 하나로 묶어야 합니다. 전체 스크립트를 gist로 가져오고 완료된 것입니다. 3scale 기본 제공 분석에서 아직 사용할 수 없는 정보를 가져오는 스크립트가 있습니다.
32.5. Appliust 링크 복사링크가 클립보드에 복사되었습니다!
3scale은 매우 편리합니다. 누구나 계약한 모든 서비스의 현재 기능을 확장할 수 있어야 합니다. 모든 기지를 커버 할 수 있다고 생각하는 것처럼, 우리는 매우 특별한 필요이거나 다른 기능을 구축하고 있기 때문에 특정 측면에서 항상 뒤처질 것입니다. 어떤 일이 있어도 즉시 가능하지 않을 때 차단되는 것을 피하고 싶습니다. 데이터에 대한 모든 액세스 권한과 완전한 API 툴셋을 제공하여 작업할 수 있습니다.
If you have scripts that you want to share with us and the rest of 3scale users, please send them. 저희는 이를 수집하고 공개해 주셔서 감사합니다.
33장. 기본 제공 분석 링크 복사링크가 클립보드에 복사되었습니다!
이 튜토리얼의 마지막에는 애플리케이션의 트래픽에 대한 시각적 정보를 찾을 수 있습니다.
API를 사용하는 각 애플리케이션에는 3scale 시스템에서 트래픽 추적이 있으며, 이는 API를 통해 관리 포털에서 볼 수 있을 뿐만 아니라 복구할 수 있습니다.
애플리케이션의 트래픽 분석을 보려면 다음을 수행합니다.
분석을 볼 애플리케이션으로 이동합니다.
DestinationRule > 계정 > 목록 또는ECDHE > 애플리케이션 > 목록 > 찾기 튜토리얼에서 설명한 대로 검색하여 애플리케이션을 찾을 수 있습니다.
애플리케이션의 개요 페이지를 검토합니다.
애플리케이션을 찾은 후에는 다음 이미지에 표시된 대로 애플리케이션에 대한 정보가 포함된 개요 페이지가 표시됩니다.
이미지에 레이블이 지정된 항목은 다음 정보에 해당합니다.
- 개발자가 지정한 애플리케이션의 이름입니다.
- 애플리케이션에 대해 캡처된 메타 데이터. 고급 섹션에서 캡처할 데이터를 설정하는 방법을 알아봅니다.
- 애플리케이션 상태 - 애플리케이션이 활성 또는 일시 중단됩니까?
- 현재 API 식별자, 키 및 애플리케이션에 있는 인증서입니다. 이 보기는 API를 3scale에 통합하는 데 사용된 인증 방법에 따라 다릅니다.
- 애플리케이션의 트래픽 통계 요약.
- 애플리케이션이 있는 애플리케이션 계획 및 속도 제한이 적용되는 방법에 대한 정보입니다.
애플리케이션 이름 위의 NSX 링크를 클릭합니다.
애플리케이션에 대한 사용 차트가 표시됩니다. 메트릭, 메서드 및 시간 범위를 제어하면 애플리케이션에 대한 다양한 유형의 데이터를 확인할 수 있습니다.
34장. 응답 코드 추적 링크 복사링크가 클립보드에 복사되었습니다!
이 튜토리얼에서는 3scale 시스템에서 응답 코드를 설정하고 사용하는 방법을 보여줍니다.
API에서 응답 코드를 추적하는 것은 클라이언트가 이를 사용하는 방법을 확인하고 서버에서 모든 것이 잘 작동하는지 실시간으로 확인할 수 있는 좋은 방법입니다.
응답 코드 추적 기능을 활성화하려면 Docker 또는 OpenShift 배포를 사용하여 APIcast 게이트웨이를 시작할 때 APICAST_RESPONSE_CODES 환경 변수를 1 또는 true 로 설정합니다.
활성화하면 APIcast 게이트웨이는 인증된 호출을 위해 업스트림 서비스에서 반환한 API 응답의 HTTP 상태 코드를 캡처하고 이를 서비스 관리 API( authrep 호출)로 보냅니다. 예제:
https://su1.3scale.net/transactions/authrep.xml?service_token={SERVICE_TOKEN}&service_id={SERVICE_ID}&user_key={USER_KEY}&usage%5Bhits%5D=1&log%5Bcode%5D=200"
이 예에서는log[code]=200 이 전송되므로 API가 200 상태 코드로 응답했습니다.
통합을 확인하려면 유효한 3scale 인증 정보를 사용하여 API를 호출한 다음, DestinationRule > Usage 페이지에서 호출이 올바르게 보고되었는지 확인해야 합니다.
- 응답 코드 추적은 모든 응답의 정확한 수를 나타내는 것은 아닙니다.
- 이 뷰의 값은 기간 동안 추세를 시각적으로 표시하는 것입니다.
-
응답 코드 추적 및 3scale 인증 캐싱 모드:
None은 지원되는 조합이 아닙니다.
지금까지 모든 것이 잘 진행 중인 경우 analytics > ;Response 코드 페이지로 이동합니다. 응답이 2xx, 4xx 또는 5xx인지에 따라 최신 트래픽이 색상으로 분할된 그래프를 볼 수 있어야 합니다.
그래프 도구를 사용하면 응답 코드의 기록을 볼 수 있습니다. 응답 코드 통계는 다른 기간과 다른 수준의 세분성도 확인할 수 있습니다. 간단히 시간 선택 표시줄을 클릭하고 필요에 맞는 기간과 세분성을 정의합니다.