組織とは、Apigee Edge での最上位レベルのコンテナです。組織にはすべての API プロキシと関連リソースが含まれています。このトピックの残りの部分では組織について詳しく解説しますが、ここではいくつかの実用的なポイントを紹介します。
- デフォルトでは、ユーザーの組織名は、仮想ホストについてで説明しているように、API プロキシを呼び出すために使用される URL に含まれています。次に例を示します。
http(s)://your_org_name-environment.apigee.net/proxy_base_path/...
- ユーザーの組織名は Edge 管理 UI の URL に含まれています。たとえば、次の URL には
docs組織の API プロキシが表示されています。
- 自分が作成した組織が 1 つのみでも、特別の権限を持つユーザーまたは管理者として他の組織に所属できます。Edge 管理 UI では、複数の組織に属している場合は、組織の切り替えで説明しているように、別の組織に切り替えることができます。
- 組織管理者のロールを持つユーザーとして管理 API を呼び出す場合、組織はほとんどの呼び出しでパスに必須の要素です。たとえば、次の管理 API cURL リクエストでは、組織内のすべての API プロキシのリストが返されます。
curl https://api.enterprise.apigee.com/v1/organizations/your_org_name/apis -u org_admin_email_address
動画: API 管理のマルチテナンシー アーキテクチャが組織でどのようにサポートされているかについて説明している短い動画をご覧ください。
組織の構成要素
ユーザーが Edge アカウントを作成すると、Edge はそのユーザーの組織を自動的に作成します。組織が作成されると、組織へのユーザーの追加、API プロキシや API プロダクトの作成、デベロッパーやアプリの登録ができるようになります。
次の図は Edge の組織モデルの主要コンポーネントを示しています。このモデルでは、ユーザーの API、API プロダクト、アプリ、アプリ デベロッパーが Edge 内でどのように関連しているかを定義しています。
このモデルに示されていない Apigee Edge の機能もあります。Monetization を使用している場合は、このモデルに追加のコンポーネントがあります。詳しくは、Monetization についてをご覧ください。
組織名
組織の名前が Edge ユーザー名です。作成した後に組織名を変更することはできません。
組織名は、API プロキシへの URL の一部になり、Edge Management API へのリクエストを作成するときの URL の一部になります。たとえば、API プロキシへのアクセスに使用される通常の URL は以下の形式です。
http://org-name-env.apigee.net/v1/weather/forecastrss
ここで
- org-name は組織の名前です。
- env は API のデプロイ環境で、test または prod のいずれかです。
例:
http://myorg-test.apigee.net/v1/weather/forecastrss
組織の構成要素
以下の表に、組織モデルの構成要素の詳細を示します。
| 構成要素 | 説明 |
|---|---|
|
組織 |
各 Apigee アカウントは、Apigee Edge 上の 1 つまたは複数の組織にマッピングされています。組織には、API プロキシ、API プロダクト、API パッケージ、アプリ、デベロッパーなどのすべての構成要素の表現が含まれています。 アカウント所有者は 1 つの組織に制限されません。たとえば、アカウント所有者が、異なるアプリ デベロッパー コミュニティを支援する複数の組織を定義することも、そのメンバーであることもできます。 |
| 環境 | 組織内の API プロキシ用のランタイム実行コンテキスト。環境について詳しくは、次のセクションをご覧ください。 |
|
ユーザー |
アカウント作成者が自動的に管理者であるような環境では、複数のユーザーを作成できます。ユーザーは組織の API チームの構成員です。API チームには、管理者、API プロキシや API プロダクトの作成者、分析や他の統計情報をモニタリングするユーザーなどを含めることができます。 ユーザーに応じて、ロールやアクセス権限を変えることができます。たとえば、一部のユーザーを、組織とその構成要素を変更する権限を持つ組織管理者やオペレーション管理者として定義し、他のユーザーを、API プロキシや API プロダクトを作成する権限を持つが、他のユーザーを変更する権限を持たないユーザーとして定義します。 ユーザーは複数の組織のメンバーになることができます。たとえば、ある企業で Apigee Edge に複数の組織を定義して、異なるデベロッパー コミュニティを支援することが考えられます。一方、内部的には、同じ人物がすべての API プロキシや API プロダクトを構築しているため、すべての組織のメンバーになっています。 ユーザーになるために Apigee アカウント（Apigee 組織）を作成する必要はありません。管理者は既存の組織にユーザーを追加できます。 すべてのユーザーは https://enterprise.apigee.com にアクセスして Apigee Edge にログインします。 |
|
API プロキシ |
組織に属するユーザーは 1 つまたは複数の API プロキシを作成します。API プロキシでは、一般公開される HTTP エンドポイントとバックエンド サービスのマッピングを定義します。また、セキュリティ保護（OAuth など）、メッセージの変換（XML から JSON へなど）、バックエンド サービスへのトラフィックの制限など、リクエスト、レスポンス、サービス コールアウトに対して有用なオペレーションを含めるように、API プロキシを構成することもできます。 Edge は API プロキシの分析のためにデータを収集します。 |
|
API プロダクト |
組織に属するユーザーは 1 つまたは複数の API プロダクトを作成します。API プロダクトとは、API プロキシにサービスプランを組み合わせたバンドルです。サービスプランでは、API プロキシに対するアクセス制限の設定、セキュリティ保護の提供、モニタリングや分析の許可などの機能を提供できます。 Edge は API プロダクトの分析のためにデータを収集します。 |
|
デベロッパー |
組織には、その組織によって定義されている（API プロダクトとしてまとめられた）API を使用するアプリを構築する、1 人または複数のデベロッパーが属しています。デベロッパーは API を使用しますが、API の作成や組織での他の操作を行うことはできません。 デベロッパーは、社内の人員、パートナー、API へのアクセスに料金を支払っている外部デベロッパーのいずれでも構いません。 デベロッパーは、API にアクセスするための API キーを受け取る前に、組織に登録されている必要があります。組織内でデベロッパーをどのように追加、更新、除外するかの判断は API プロバイダに任されています。API プロバイダは、Edge 管理 UI を使用して手動でデベロッパーを追加することも、ウェブサイトを介してデベロッパーを登録できるようにデベロッパー ポータルを作成することも、Edge 管理 API を使用して独自の登録メカニズムを定義することもできます。 デベロッパーは Edge のアカウントを持っている必要はなく、ほとんどのデベロッパーは Edge について何も知らなくて構いません。デベロッパーが Edge のアカウントを持っている場合、そのアカウントは通常、別の組織のユーザーとしてのアカウントであるか、または Edge API サービスを使用するためのアカウントです。 |
|
アプリ |
デベロッパーは、API を使用するクライアント アプリを 1 つまたは複数作成します。 デベロッパーは自分のアプリを組織に登録する必要があります。Edge における App は、デベロッパーの実際のアプリの表現であり、それによって、API へのすべてのリクエストを通すための API キーがデベロッパーに提供されます。 すべてのアプリは組織に登録されているため、アプリとアプリによる API の使用に関する分析情報を Edge でモニタリングおよび収集できます。 |
|
API キー / OAuth トークン |
API に対して定義している認可メカニズムに応じて、アプリは API へのすべてのリクエストとともに API キーを渡します。そのキーが有効であれば、そのリクエストは許可されます。Edge では、シンプルな API キー、Two-legged OAuth、3-legged OAuth など、さまざまなタイプの認証がサポートされています。 API プロバイダは、デベロッパーが自分のアプリを登録する手段を定義する必要があります。アプリを登録してもらうことで、API へのアクセスに必要なキーをデベロッパーに返すためです。 デベロッパーはアプリの登録時に、1 つの API プロダクトにアクセスするか、複数の API プロダクトにアクセスするかを選択できます。デベロッパーの実際のアプリでは同じキーを使用して、そのアプリ（Edge におけるデベロッパーのアプリの登録表現）に関連付けられているすべての API プロダクトにアクセスします。 API プロバイダは、デベロッパーのアプリが API にアクセスできないように、（そのデベロッパーのアプリの登録表現が組織に残存していても）そのキーをいつでも取り消すことができます。または、デベロッパーが所定の期間後にキーを更新しなければならないように、キーに時間制限を設定することもできます。 |
環境について
「環境」は、組織内の API プロキシのランタイム実行コンテキストです。環境にアクセスできるようにするには、その環境に API プロキシをデプロイする必要があります。ある特定の API プロキシを、単一の環境または複数の環境にデプロイできます。
組織には、複数の環境を含められます。たとえば、1 つの組織に dev、test、prod の環境を定義できます。
組織は、一部の Apigee 機能でのスコープになります。たとえば、Key-Value マップ（KVM）データは組織レベルで使用可能にできるため、どの環境にデプロイされている API プロキシでも KVM から同じデータを取得できます。キャッシングなどの一部の機能では、スコープを組織や組織内の特定の環境に設定できます。Apigee の分析データは組織と環境の組み合わせごとに分割されています。
次の図は、組織内でユーザーが管理する主なエンティティを示しています。組織内でグローバルに定義されるエンティティや、特定の環境に対して定義されるエンティティもあります。
