Noções básicas sobre as organizações

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

Uma organização é o contêiner de nível superior no Apigee. Ela contém todos os proxies de API e recursos relacionados. Embora o restante deste tópico seja mais focado em organizações, veja alguns pontos práticos:

Depois de criada, não é possível renomear uma organização.
O nome da sua organização está no URL da IU da Apigee. Exemplo:
```
https://apigee.google.com/organizations/ORG_ID
```
Quando você faz chamadas com a API Apigee, a organização é uma parte obrigatória do caminho na maioria das chamadas. Por exemplo, a solicitação curl a seguir retorna uma lista de todos os proxies de API em uma organização que usa a API Organizations:
```
curl https://apigee.googleapis.com/v1/organizations/YOUR_ORG_ID/apis
```
É possível criar apenas uma organização, mas você pode pertencer a outras organizações como usuário ou administrador com permissões específicas. É possível alternar para uma organização diferente, conforme descrito na seção Como alternar entre suas organizações.
Uma organização da Apigee não é igual a uma organização do Google Cloud. Se houver possibilidade de ambiguidade, este documento especifica que a "organização" é uma organização da Apigee.

Vídeo: assista a um breve vídeo para saber como as organizações oferecem suporte a uma arquitetura multilocatária para o gerenciamento de API.

Tipos de organização

Existem dois tipos de organizações:

Paga: uma organização permanente com escalonabilidade total. Também conhecida como organização de produção. As organizações pagas incluem aquelas criadas como parte de um modelo de preços de assinatura ou de pagamento por utilização da Apigee.
Avaliação: uma organização de autosserviço temporária para testar a Apigee. Também conhecidas como eval orgs, essas organizações têm limite de tempo e não têm a escalonabilidade e a flexibilidade das organizações de produção.

Consulte também Comparar organizações pagas e de avaliação.

Ciclo de vida da organização de avaliação

As organizações de avaliação têm uma duração limitada:

Dia 0: crie a organização de avaliação.
Dia 30: o Google envia um aviso por e-mail sobre a expiração da avaliação.
Dia 60: o Google exclui a organização de avaliação.

Componentes da organização

A imagem a seguir mostra os principais componentes do modelo organizacional do Apigee. Esse modelo define como suas APIs, produtos de API, aplicativos e desenvolvedores de aplicativos estão relacionados na Apigee.

Diagrama hierárquico mostrando a organização como a raiz de uma implantação da Apigee.

Esse modelo não mostra todos os recursos da Apigee, mas indica que a organização é a raiz de uma implantação.

A tabela a seguir descreve os componentes do modelo organizacional em mais detalhes:

Componente	Descrição
Organização	Cada organização da Apigee pertence a um projeto do Google Cloud, e um projeto pode conter no máximo uma organização. Uma organização contém ambientes, proxies de API, produtos de API, pacotes de API, apps e usuários. Os proprietários de contas não estão limitados a uma única organização. Alguns proprietários de contas podem definir ou ser membros de várias organizações compatíveis com diferentes comunidades de desenvolvedores de aplicativos. Observação: as contas que sem assinatura são limitadas a criar apenas uma organização, mas você ainda pode ser membro de várias organizações existentes.
Ambientes e grupos de ambiente	Um ambiente é um ambiente de software isolado, em uma organização, em que você implanta proxies de API. É possível criar vários ambientes em uma organização. Um grupo de ambientes é um conjunto de ambientes com um ou mais nomes de host. O nome do host faz parte do URL usado para chamar proxies da API implantados em qualquer ambiente no grupo de ambientes.
Proxy de API	Um proxy de API é uma interface entre as solicitações de entrada e os serviços de back-end. A entidade de proxy contém as instruções e políticas que a Apigee executa ao processar solicitações de clientes e respostas do back-end.
Produto de API	Uma entidade para publicar APIs. Os produtos de API são publicados no portal do desenvolvedor para consumo por desenvolvedores externos. Um produto de API apresenta uma interface para acessar uma ou mais APIs publicadas. A interface (que pode ser descrita com uma especificação OpenAPI) pode incluir uma combinação de uma ou mais solicitações de API processadas por um ou mais proxies de API. Os usuários de uma organização criam produtos de API. Ao fazer isso, eles podem anexar metadados arbitrários a cada produto de API. Um tipo de metadados usado com frequência pode definir um plano de serviços, que pode especificar limites de acesso em chamadas de API, estabelecer requisitos de segurança, permitir monitoramento e análises, além de fornecer recursos adicionais. O Apigee coleta dados para análise sobre produtos de API.
Provedor de API	A pessoa ou entidade que cria e gerencia proxies e produtos de API. Os desenvolvedores de apps clientes acessam essas APIs publicadas.
Desenvolvedor de apps	Uma organização contém um ou mais desenvolvedores que criam os aplicativos que consomem as APIs (publicadas produtos de API) definidas pela organização. Os desenvolvedores consomem APIs, mas não podem criar APIs nem realizar outras ações na organização. Os desenvolvedores podem ser internos, parceiros ou externos, que podem ou não pagar pelo acesso às APIs. Os desenvolvedores são como clientes que usam suas APIs. Os desenvolvedores precisam ser registrados na organização antes de registrar um aplicativo e receber uma chave para acessar APIs. Como provedor de API, cabe a você determinar como adicionar, atualizar ou remover desenvolvedores da organização. É possível adicioná-los manualmente por meio da IU, criar um portal do desenvolvedor para registrá-los em um site ou definir seu próprio mecanismo de registro usando a API Apigee.
App Apigee (ou app)	Os desenvolvedores criam um ou mais apps clientes que consomem sua APIs. Desenvolvedores que criam aplicativos cliente que chamam APIs que exigem verificações de credenciais (como chaves de API ou tokens OAuth) precisam primeiro criar um registro de app na sua organização. Um registro de app fornece ao desenvolvedor a chave de API, um par de chave/secret ou outras credenciais que precisam ser usadas quando o aplicativo cliente chama suas APIs. Como todos os apps estão registrados na sua organização, é possível usar a Apigee para monitorar e coletar informações analíticas sobre o app e o uso das APIs.

Outros componentes da Apigee que não são mostrados são as chaves de API e os tokens do OAuth.

A Apigee é compatível com diferentes tipos de autenticação, como uma chave de API simples, OAuth de duas etapas, OAuth de três etapas e outros.

Se o provedor de API especificar a verificação de chave de API como mecanismo de autorização, o aplicativo cliente precisará transmitir uma chave a cada solicitação às suas APIs. Se essa chave for válida, a Apigee permitirá a solicitação. Como alternativa, se o provedor de API especificar a verificação de token OAuth como mecanismo de autorização, o aplicativo cliente precisará primeiro receber um token OAuth e depois transmiti-lo a cada solicitação às suas APIs. Se esse token for válido, a Apigee permitirá a solicitação. Outros esquemas de autorização personalizados são possíveis.

Como um provedor de API, você precisa definir uma maneira de os desenvolvedores registrarem os aplicativos. Cada registro de app terá uma ou mais chaves ou credenciais associadas. Se você permitir que os desenvolvedores registrem os próprios aplicativos em um portal, eles poderão recuperar a chave ou a credencial necessária para acessar suas APIs, em uma experiência conveniente e de autoatendimento.

No momento do registro do aplicativo, os desenvolvedores podem optar por acessar um único produto de API ou vários. O app de um desenvolvedor usa a mesma chave/credencial para acessar todos os produtos de API associados ao app.

A qualquer momento, é possível revogar a chave para que o aplicativo do desenvolvedor não tenha mais acesso às APIs (mesmo que a representação registrada do aplicativo do desenvolvedor ainda exista na organização). Ou você pode definir uma expiração em uma chave para que o desenvolvedor precise atualizá-la após um período específico.

Usuários da Apigee

Os usuários da Apigee formam a equipe da API da organização, que pode incluir pessoas como administradores, proxy de API e criadores de produtos de API, ou usuários que monitoram análises e outras estatísticas. Os usuários finais são pessoas que utilizam os apps criados pelos desenvolvedores da Apigee. Na maioria dos casos, essa documentação usa o termo "usuário" para se referir a um usuário da Apigee.

Os administradores podem adicionar usuários a uma organização.

Usuários diferentes podem ter papéis e privilégios de acesso diferentes. Por exemplo, defina alguns usuários como administradores da organização e administradores de operações com privilégios para modificar a organização e os componentes dela. Defina outros usuários com permissões para criar proxies e produtos de API, mas sem os privilégios para modificar outros usuários.

Os usuários podem ser membros de várias organizações. Por exemplo, para sua empresa, você pode definir várias organizações na Apigee para oferecer suporte a diferentes comunidades de desenvolvedores. No entanto, internamente, as mesmas pessoas criam todos os proxies e produtos de API e, portanto, são membros de todos os organizações.

Você não precisa criar uma organização da Apigee para ser um usuário. Um administrador pode adicioná-lo a uma organização existente.

Todos os usuários fazem login na Apigee pela IU da Apigee.

Direitos

Os direitos da organização vão depender se a organização paga usa o modelo de preços de assinatura ou pagamento por utilização.

Direitos de assinatura

Organizações: o direito da organização é expresso em unidades. Ao receber um direito de unidade organizacional, é possível usá-lo para ativar uma única organização nova em qualquer região que você quiser ou estender uma organização para uma única nova região (usando a expansão do nome de domínio). Para fins de direitos, uma organização em N regiões consome N unidades organizacionais. Por exemplo, se comprar quatro novas unidades organizacionais, você vai poder fazer o seguinte:

Expandir uma organização em quatro novas regiões
Ou expandir cada uma das duas organizações atuais em duas novas regiões
Ou criar quatro novas organizações, cada uma disponível em uma região.

O direito total de unidade organizacional é o agregado do nível de assinatura com os pacotes de organização relevantes.

Ambientes: os direitos do ambiente também são expressos em unidades. Eles não dependem dos direitos da organização e se comportam de maneiras diferentes. Há um processo de duas etapas para usar um direito de unidade de ambiente: primeiro, você cria um ambiente e depois o anexa a uma organização. Um ambiente conta com o direito à unidade de ambiente quando é anexado a uma organização.

O uso de unidades de ambiente é calculado como o número de ambientes usados em todas as organizações e regiões. Em outras palavras, um ambiente provisionado em duas regiões para uma organização consumirá duas unidades de ambiente do seu direito.

O direito total da unidade de ambiente é o agregado do direito fornecido no nível de assinatura com o direito adicional obtido por meio de pacotes de ambiente ou organizações. Ao comprar um pacote de organizações, você recebe uma unidade organizacional e um número de unidades de ambiente. Qualquer direito de unidade de ambiente adicionado por um pacote organizacional é independente de qualquer organização criada ou expandida. Os direitos de unidade de ambiente adicionados por pacotes da organização são somados ao direito total de unidade de ambiente. Para adicionar mais unidades de ambiente sem comprar outras unidades organizacionais, compre um pacote de ambiente.

Para entender melhor, consulte Direitos de assinatura.

Direitos de pagamento por utilização

Organizações: o modelo de pagamento por utilização dá os proprietários da conta a uma única organização.

Ambientes: as autorizações de ambiente não dependem das autorizações da organização. Elas também se comportam de maneira diferente porque há um processo de duas etapas para que sejam utilizadas: primeiro, você cria um ambiente e depois o vincula a uma organização. Os ambientes não são contabilizados nos seus limites de autorização até que estejam vinculados a uma organização.

Em outras palavras, o número de ambientes contabilizados é o número de ambientes que foram vinculados a uma organização.

O modelo de pagamento por utilização inclui o direito de 85 ambientes em todas as regiões.

Para entender melhor, consulte Direitos ao pagamento por utilização.