청구 승인 요청 처리
적용 대상: Windows Azure Pack
Windows Azure Pack 테넌트가 구독 또는 구독 추가 기능을 만들거나 삭제하는 경우 호스터의 청구 비즈니스 사례에 따라 요청을 승인하거나 거부해야 할 수 있습니다. Windows Azure Pack은 구독 및 구독 추가 기능 만들기 및 삭제를 승인하기 위한 REST 인터페이스를 정의합니다. 이는 청구 어댑터에 의해 구현되며 테넌트가 구독 또는 구독 추가 기능을 만들거나 삭제할 때마다 등록되면 호출됩니다. HTTP 응답 코드는 요청된 작업이 승인되었는지 여부를 나타냅니다. 400보다 높거나 같은 숫자는 거부됩니다. 400보다 낮은 숫자가 허용됩니다. 응답 본문의 내용은 무시됩니다.
청구 승인 REST API 엔드포인트
다음은 청구 어댑터가 구현해야 하는 청구 승인 REST API입니다.
필수 또는 청구로 등록된 경우 REST 호출이 차단되고 사용량 서비스에서 NotificationSubscribers 설정의 등록자에게 실시간으로 요청 알림으로 전송됩니다. 알림 이벤트 상태는 승인 보류 중입니다. 차단 구독자의 응답에 따라 작업이 승인되거나 거부됩니다. 차단 구독자가 등록되지 않은 경우 이벤트는 자동 승인되고 승인된 상태로 설정되고 사용 서비스 REST API를 통해 노출됩니다. 필수 및 청구 구독 유형에 대한 자세한 내용은 Windows Azure Pack 사용 현황 서비스를 구성합니다.
이러한 작업을 청구 시스템에 커밋하는 실제 신호는 알림 구독자로 등록되었는지 여부에 관계없이 REST API에 노출되는 이벤트입니다. 이 API를 통해 전송된 요청은 요청일 뿐이므로 아무 작업도 수행해서는 안 됩니다.
중요
Windows Azure Pack RTM 릴리스는 실시간 청구 승인 API에서 구독 업데이트 이벤트를 노출하며 해당 서비스의 모든 등록자는 해당 이벤트를 자동으로 승인해야 합니다.
청구 승인 REST API 엔드포인트를 등록하는 방법에 대한 자세한 내용은 Windows Azure Pack 사용 현황 서비스 구성을 참조하세요.
승인 요청 인증
청구 승인 REST API에는 최소한 기본 인증이 필요합니다.
승인 요청 처리
다음은 청구 어댑터로 전송된 구독 만들기 요청의 예입니다. 청구 어댑터가 보내는 HTTP 응답 코드는 승인을 나타내는 204이거나 요청 거부를 나타내는 403이어야 합니다.
POST /usage/subscriptions HTTP/1.1
Content-Type: application/json; charset=utf-8
Host: 10.121.217.127:8888
Content-Length: 564
Expect: 100-continue
{
"EventId": 6530,
"State": 2,
"Method": "POST",
"Entity": {
"SubscriptionID": "0a53e53d-1334-424e-8c63-ade05c361be2",
"SubscriptionName": "ExamplePlan",
"AccountAdminLiveEmailId": "user@example.com",
"ServiceAdminLiveEmailId": null,
"CoAdminNames": [
],
"AddOnReferences": [
],
"AddOns": [
],
"State": 0,
"QuotaSyncState": 0,
"ActivationSyncState": 0,
"PlanId": "Examphlztfpgi",
"Services": [
],
"LastErrorMessage": null,
"Features": null,
"OfferFriendlyName": null,
"OfferCategory": null,
"Created": "0001-01-01T00:00:00Z"
},
"EntityParentId": null,
"NotificationEventTimeCreated": "2013-09-25T00:32:08.8724845Z"
}
청구 어댑터가 이벤트를 수신하고 오류 메시지를 반환하는 경우 서비스 관리 API에서 이벤트가 성공적으로 완료되지 않습니다. 예상된 동작이 아닌 경우 청구 어댑터는 각 이벤트 알림에 대해 상태 코드 200을 다시 보내야 하며 나중에 처리하기 위해 오류를 기록해야 합니다. 수신되는 알 수 없는 이벤트는 200 상태 코드가 반환되어야 합니다.