課金アダプターのサンプルについて
適用対象: Windows Azure Pack
課金アダプター のサンプルは、 から https://www.microsoft.com/en-us/download/details.aspx?id=41146入手できる Microsoft Visual Studio 2012 ソリューションです。 このサンプル アーキテクチャは、課金アダプター コア エンジンとシステム固有の課金アダプター コンポーネントの 2 つの部分で構成されています。 コア エンジンは、Windows Azure Pack Billing API と対話し、簡単に使用できるインターフェイスを提供します。 システム固有のコンポーネントは、コア エンジンからの選択インターフェイスの実装と組み合わせて、実際の課金システムと通信するクライアントで構成されます。 WHMCS と HostBill の 2 つのシステム固有の課金アダプターとクライアントが用意されています。 その他の課金システムの場合は、新しい実装を作成する必要があります。
コア エンジンには、状態を維持し、障害復旧をサポートする独自のデータベースがあります。 このサンプルで提供される 2 つのシステム固有の例には、ID マッピングのサポートを提供するデータベースが含まれます。 これらのデータベースは実装固有であり、独自の課金アダプターの実装を作成するときに必要ない場合があります。
重要
指定されたシステム固有の実装では、データベースを使用して ID マッピングを実行します。 Windows Azure Pack 識別子を特定の課金システム識別子にマップします。 課金システムで Windows Azure Pack 識別子を使用 (または格納) できる場合、実装の一部として ID マッピング データベースは必要ありません。
.jpeg "Windows Azure Pack 課金サンプル")
一般的なサンプルオブザベーション
課金アダプターは、Windows サービスまたはコンソール アプリケーションとして実行できます。 詳細については、「 課金アダプター のサンプルをビルドして実行する方法」を参照してください。
課金アダプターは、Windows Azure Pack 課金 API と課金システムに接続できる限り、任意の場所でホストできます。 いずれかのレスポンダー (Blocking API または Pricing API) が使用されている場合は、Windows Azure Pack も課金アダプターにアクセスできる必要があります。
課金アダプター コア エンジンには、従量制課金の使用を処理するための厳密に型指定されたインターフェイスが用意されています。 ただし、このサンプルで実装されているどちらの課金システムでも、追加のアドオンを取得せずにすぐに従量制課金の使用量を提供することはありません。
コア エンジンの側面
次に、コア エンジンの側面について説明します。 サンプル プロジェクトの詳細については、「Billing Adapter Core Engine サンプル ファイルについて」を参照してください。
簡略化 & 抽象化
コア エンジンは、Usage Rest API を介して収集された情報を厳密に入力することで、Billing Rest API の複雑さを使いやすいインターフェイスに抽象化します。 Usage Rest API の詳細については、「 Windows Azure Pack Usage Service Usage REST API リファレンス」を参照してください。
エラー処理
コア エンジンは、内部的に再試行を実行することで、システム固有の実装からエラーを抽象化します。 Windows Azure Pack から発生したエラー (ネットワーク障害など、一時的なエラーと見なされます) の場合、コア エンジンは正常な応答が返されるまで再試行を続けます。 課金アダプターから発生したエラー (一時的または永続的なエラー) の場合、コア エンジンは最大 5 回再試行します。 5 回経過すると、エラーは永続的と見なされ、コア エンジンは処理エンジンを停止し、システム管理者がエラーを分析して手動で修正するのを待機します。 コア エンジンは、エラー メッセージを Microsoft Windows イベント ログに書き込みます。 エンジンは、再試行の間に定義済みの時間スリープ状態になります。 app.config の詳細については、「 Billing Adapter Core Engine サンプル ファイルについて」を参照してください。
注意
エンジンは、イベントごとに最大 5 回システム固有の実装を呼び出すことができるため、実装はべき等である必要があります。
高可用性 & マスター/スレーブ選択
高可用性とスケーラビリティを実現するために、課金アダプターを複数のマシンにデプロイできます。 すべてのレスポンダー (ブロッキング API と価格 API) が有効になっている場合、すべてのインスタンスで実行されます。 マスター & スレーブの選択により、各プロセッサのインスタンス (通知イベントと使用状況レコード) が有効になっている場合は、プロセスとマシン間で一度に 1 つのインスタンスのみが実行されます。
ログ記録
ログは Microsoft イベント ビューアーで表示できます。 これらは、Microsoft-WindowsAzurePack.BillingAdapter チャネルの [アプリケーションとサービス ログ] セクションで使用できます。
状態管理
課金アダプター エンジンは、障害から回復できるように、必要な状態を独自のデータベースに保持します。 これにより、(システム固有の実装によって正常に処理された) 既に "コミットされた" イベントが複数回処理されないようにします。
システム固有コンポーネントの側面
このサンプルには、2 つの課金システム固有の実装 (WHMCS および HostBill 課金システム用) が含まれています。 別の課金システムがある場合は、課金アダプター インターフェイスの独自の実装を提供する必要があります。 独自の実装を記述するときは、いくつかのガイドラインに従う必要があります (以下を参照)。 これらのガイドラインは、提供されているシステム固有の実装で示されているため、既存の実装のいずれかをテンプレートとして使用し、ニーズに応じて変更することをお勧めします。
再試行の処理
コードはべき等または再入可能である必要があります。 要求の処理中にエラーが発生した場合、課金アダプター エンジンは要求の配信を再試行します。 実装では再試行を処理でき、処理されたイベントの半分をクリーン\修正できる必要があります。 含まれているサンプル実装では、課金システムに変更を加える前に、現在の課金システムの状態をチェックします。 また、マッピング データベースを利用して、イベントが既に正常に処理されたかどうかを検出します。
HostBill および WHMCS サンプルの側面
どちらのサンプル実装も、課金システム データベースと直接やり取りします (必要な API 呼び出しがないため)。 課金システム データベースの内部構造は、バージョン間で変更される可能性があります。つまり、サンプル実装が中断する可能性があります。 WHMCS サンプル実装は WHMCS バージョン 5.2.7 でテストされ、HostBill 実装は HostBill バージョン 4.9.8 でテストされました。 課金システムのバージョンが異なる場合は、互換性のために現在の実装を再テストする必要があります。 提供される実装では、app.config から想定されるバージョンを読み取ります (app.config の詳細については、「 課金アダプター Core エンジン サンプル ファイルについて」を参照してください)、課金システムのバージョンが予想されるバージョンと一致しない場合は実行されません。
どちらの実装も、イベント通知処理とブロッキング API レスポンダーを実装します。 HostBill では、価格レスポンダーも実装されます。