Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.

Understanding organizations

組織 (organization) とは、Apigee Edge での最上位レベルのコンテナです。組織には、すべての API プロキシと関連リソースが含まれています。このトピックの残りの部分では、組織について詳しく解説しますが、ここでは、いくつかの実用的なポイントを紹介します。

  • デフォルトでは、ユーザーの組織名は、「仮想ホスト」で説明するように、API プロキシを呼び出すために使用される URL に含まれます。例:
    http(s)://<your_org_name>-<environment>.apigee.net/proxy_base_path/...
  • ユーザーの組織名は、Edge 管理 UI の URL に含まれます。例えば、「apigeedocs」と呼ばれる組織の場合、管理 UI の URL は次のようになります。
  • 自分が 1 つの組織しか作っていない場合でも、特別の権限を持ったユーザーまたは管理者として他の組織に属することが可能です。Edge 管理 UI では、複数の組織に属する場合は、「Organization」ドロップダウンで各組織を切り替えることができます。
  • Organization Administrator ロールを持つユーザーとして管理 API を呼び出す場合、組織はほとんどの呼び出しでパスに必須の要素です。例えば、次の管理 API cURL リクエストは組織内の全 API プロキシのリストを返します。
    curl https://api.enterprise.apigee.com/v1/organizations/<your_org_name>/apis -u <org_admin_email_address>

組織の構成要素

Edge アカウントを作成すると、組織が Edge によって自動で作成されます。作成されると、組織へのユーザーの追加、API プロキシや API 製品の作成、デベロッパやアプリの登録ができるようになります。

次の図に、Edge の組織モデルの主要コンポーネントを示します。このモデルは、ユーザーの API、API 製品 (product)、アプリ、およびアプリ開発者が Edge 内でどのように関連しているかを定義するものです。

このモデルには、Apigee Edge のすべての機能が示されているわけではありません。マネタイズまたは API BaaS を使用する場合、モデルに追加のコンポーネントがあります。詳細については、「Understand monetization」および「API BaaS」を参照してください。

クラウドのお客様がアカウントに対する組織の追加や削除を実施するには、Apigee サポートへの連絡が必要です。

Edge for Private Cloud のお客様の場合、組織の削除や追加はシステム管理者が実施できます。詳細については、Edge の操作ガイドを参照してください。Apigee の ftp サイト ftp://ftp.apigee.com/ に用意されています。

組織名

組織の名前が Edge ユーザー名になります。いったん作成された組織名は変更できません。

組織名は、API プロキシへの URL の一部、および Edge 管理 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

組織の構成要素

以下の表に、組織モデルの構成要素の詳細を示します。

構成要素 説明

Organization

各 Apigee アカウントは、Apigee Edge 上の 1 つまたは複数の組織に対応しています。 組織には、API プロキシ、API 製品、API パッケージ、アプリ、デベロッパなど、すべての構成要素の表現が含まれます。

アカウント所有者は、1 つの組織に制限されません。例えば、アカウント所有者が異なるアプリデベロッパコミュニティーを支援する複数組織の定義者またはメンバーである、という状況が考えられます。

無料の Edge アカウントで作成できる組織は 1 つだけです。ただし、無料アカウント所有者でも、複数の既存の組織のメンバーになれます。

Environment 組織内の API プロキシ用のランタイム実行コンテキスト。環境 (environment) の詳細については、次のセクションを参照してください。

User

アカウント作成者が自動的に管理者であるような環境では、複数のユーザーを作成できます。ユーザーは、組織の API チームの構成員です。API チームには、管理者、API プロキシや API 製品の作成者、分析などの統計情報を監視するユーザーなどを含められます。

ユーザーに応じて、役割やアクセス権限を変えられます。例えば、一部のユーザーを組織管理者として定義し、組織とその構成要素を変更する権限を持たせる一方で、別のユーザーには API プロキシや API 製品を作成する権限を与えつつ、他のユーザーを変更する権限を与えないようにできます。

ユーザーは複数の組織のメンバーになれます。例えば、Apigee Edge に複数の組織を定義して異なるデベロッパコミュニティを支援することが考えられます。一方、内部的には、同じ人物が API プロキシや API 製品を構築しており、したがってすべての組織のメンバーになっています。

ユーザーになるのに、Apigee アカウントを作成する -- つまり Apigee 組織を作成する -- 必要はありません。管理者が既存の組織に追加できます。

Apigee Edge には全ユーザーが https://enterprise.apigee.com という URL でログインします。

API プロキシ

組織に属するユーザーは、1 つまたは複数の API プロキシを作成します。API プロキシは、公に利用できる HTTP エンドポイントからバックエンドサービスへの対応関係を定義します。また、API プロキシの構成を通じて、セキュリティ保護 (OAuth など) の提供、メッセージの変換 (XML から JSON へなど)、バックエンドサービスへのトラフィックの制限などの有用な操作を、リクエストやレスポンスに対してサービスコールアウトを使用して含めることもできます。

Edge は、API プロキシの分析に使用するデータを収集します。

API 製品

組織のユーザーは、1 つ以上の API 製品を作成します。API 製品とは、API プロキシにサービスプランを組み合わせたバンドルです。サービスプランでは、API プロキシに対するアクセス制限の設定、セキュリティ保護の提供、監視や分析の許可などの機能を提供できます。

Edge は、API 製品の分析に使用するデータを収集します。

デベロッパ

組織には、組織によって定義された API (が API 製品にまとめられたもの) を使用するアプリを構築する、1 人または複数のデベロッパが属します。デベロッパは API を使用しますが、組織では API の作成をはじめ、どのような操作もできません。

デベロッパは、社内の人材でも、パートナでも、API へのアクセスに料金を払っている外部デベロッパでも構いません。

デベロッパがアプリを登録して API にアクセスするための API キーを受け取るには、その前に組織に登録される必要があります。 組織でデベロッパをどのように追加、更新、削除するかは、API プロバイダが決めます。Edge 管理 UI を使用して手動で追加したり、Web サイト経由で登録できるようにデベロッパポータルを作成したり、Edge 管理 API を使用して独自の登録メカニズムを定義したりできます。 

デベロッパは Edge にアカウントを持っている必要がなく、ほとんどのデベロッパは Edge について何も知らなくて構いません。デベロッパが Edge にアカウントを持っている場合、それは一般に別組織のユーザーとして、または Edge API Services を使用するためです。

アプリのデベロッパは、API に加えて、Edge Advanced API Services にもアクセスできます。Edge Advanced API Services は、柔軟な NoSQL データストアや、ソーシャルグラフ、位置情報、ユーザー管理、プッシュ通知、パフォーマンス監視などの機能を提供します。

API デベロッパは組織に登録されるので、デベロッパとデベロッパによる API の使用に関する分析情報を Edge で監視および収集できます。

アプリ

デベロッパは、API を使用するクライアントアプリを 1 つまたは複数作成します。

デベロッパは、アプリを組織に登録する必要があります。Edge における App はデベロッパによる実際のアプリの表現で、API へのリクエストのたびに渡す API キーをデベロッパに提供します。

すべてのアプリが組織に登録されるので、アプリとアプリによる API の使用に関する分析情報を Edge で監視および収集できます。

API キー/OAuth トークン

API に定義した認証メカニズムに応じて、アプリは API へのリクエストのたびに API キーを渡します。 渡されたキーが有効の場合、リクエストは許可されます。Edge はシンプルな API キー、two-legged OAuth、three-legged OAuth などに対応しています。

API プロバイダは、デベロッパがアプリを登録する手段を定義する必要があります。 アプリを登録してもらうことで、API へのアクセスに必要なキーをデベロッパに返すからです。

デベロッパはアプリの登録時に、単一の API 製品にアクセスするか、複数の API 製品にアクセスするかを選択できます。デベロッパによる実際のアプリでは同じキーを使用して、そのアプリ (Edge におけるデベロッパアプリの登録表現) に関連付けられているすべての API 製品にアクセスします。

キーを取り消してデベロッパアプリが API にアクセスできないようにすることは (デベロッパアプリの登録表現が組織に残存していても) 随時できます。または、キーに時間制限を設けて、デベロッパが所定の期間後にキーを更新しなければならないようにできます。

環境について

環境とは、組織における API プロキシのランタイム実行コンテキストです。環境にアクセスできるようにするには、環境に API プロキシを展開する必要があります。API プロキシは単一の環境にも複数の環境にも展開できます。

組織には、複数の環境を含められます。例えば、1 つの組織に「dev」、「test」、「prod」といった環境を定義できます。 

Edge のクラウドベースの展開に組織を初めて作成すると、組織に 2 つの環境 (「prod」と「test」) が自動的に作成されます。環境を追加で作成する場合は、Apigee サポートにお問い合わせください。

Edge for Private Cloud インストールの場合、デフォルトでは組織も環境も作成されていません。インストールプロセスの一環として作成する必要があります。詳細については、Edge のインストールガイドを参照してください。プライベート FTP アカウントまたは Apigee のサポートポータル「Libraries」に用意されています。

組織は、一部の Apigee 機能のスコープになります。例えば、key-value-map (KVM) データは組織レベルで利用でき、これは環境に展開された API プロキシが KVM から同じデータを取得することを意味します。キャッシュ処理や Edge の資格情報コンテナのスコープは、組織にしたり、組織内の特定の環境にしたりできます。Apigee の分析データは、組織と環境の組み合わせで区分されます。

以下の図は、組織内で管理する主なエンティティーを示しています。組織内でグローバルに定義されるエンティティーや、特定の環境について定義されるエンティティーがあります。

Help or comments?