Compreender as organizações

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Uma organização é o contentor de nível superior no Apigee. A organização do Apigee contém todos os seus proxies de API e recursos relacionados. Embora o resto deste tópico aborde as organizações com mais detalhe, seguem-se alguns pontos práticos:

• Uma organização da Apigee é distinta e subsidiária de uma organização do Google Cloud. Quando cria uma organização para o Apigee X ou o Apigee Hybrid, esta é mapeada para exatamente um projeto do Google Cloud, e a organização do Apigee e o projeto do Google Cloud partilham um nome. Nem todos os projetos do Google Cloud têm uma organização do Apigee associada.
• Quando a documentação do Apigee usa o termo "organização", refere-se especificamente a uma organização do Apigee. A documentação do Apigee usa a expressão "organização do Google Cloud" para se referir à alternativa.
• Depois de criada, não pode mudar o nome de uma organização do Apigee.
• O nome da sua organização do Apigee é apresentado como o projeto no URL da secção do Apigee do Google Cloud console. Por exemplo:

  https://console.cloud.google.com/apigee/overview?project=ORG_ID

• Quando invoca chamadas REST para a API Apigee, o identificador da organização é uma parte obrigatória do caminho. Por exemplo, o seguinte pedido curl devolve uma lista de todos os proxies de API numa organização através da API organizations:

  curl https://apigee.googleapis.com/v1/organizations/ORG_ID/apis

• Embora possa ter criado apenas uma organização, pode ter autorização noutras organizações como utilizador ou administrador com autorizações específicas. Na consola da nuvem, pode mudar para uma organização diferente, conforme descrito em Alternar entre as suas organizações.

Nota: este vídeo foi gravado com uma versão anterior da IU do Apigee. No entanto, os conceitos continuam válidos.

Vídeo: veja um breve vídeo para saber como as organizações suportam uma arquitetura de multi-inquilinos para a gestão de APIs.

Tipos de organizações

Existem dois tipos de organizações:

• Pago: uma organização permanente com total escalabilidade. Também conhecido como uma organização de produção. As organizações pagas incluem as criadas como parte de uma subscrição ou de um modelo de preços do Apigee de pagamento mediante utilização.

• Avaliação: uma organização temporária self-service para testar o Apigee. Por vezes, denominadas organizações de avaliação, estas organizações têm um limite de tempo e não têm a escalabilidade nem a flexibilidade das organizações de produção.

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

Duração da avaliação da organização

As organizações de avaliação têm uma vida útil limitada:

1. Dia 0: crie a organização de avaliação.
2. Dia 30: a Google envia-lhe um email de notificação a alertar para a expiração iminente.
3. Dia 60: a Google elimina a organização de avaliação.

Organizações do Apigee na hierarquia do Google Cloud

O diagrama seguinte mostra a relação entre as organizações e os ambientes do Apigee, e os projetos e as pastas do Google Cloud.

Componentes numa organização

A imagem seguinte mostra os principais componentes do modelo organizacional do Apigee. Este modelo define a relação entre as suas APIs, produtos de API, apps e programadores de apps no Apigee.

Este modelo não mostra todas as funcionalidades do Apigee, mas destina-se a mostrar que a organização é a raiz de uma implementação.

A tabela seguinte descreve os componentes do modelo organizacional mais detalhadamente:

Componente	Descrição
Organização	Cada organização da Apigee pertence exatamente 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 utilizadores. Os titulares da conta não estão limitados a uma única organização. Alguns titulares de contas podem definir ou ser membros de várias organizações que suportam diferentes comunidades de programadores de apps.
Ambientes e grupos de ambientes	Um ambiente é um ambiente de software isolado, numa organização, onde implementa proxies de API. Pode criar vários ambientes numa organização. Um grupo de ambientes é um grupo de ambientes com um ou mais nomes de anfitrião. O nome do anfitrião faz parte do URL usado para chamar proxies de API implementados em qualquer ambiente no grupo de ambientes.
proxy de API	Um proxy de API é uma interface entre os pedidos recebidos e os serviços de back-end. A entidade de proxy contém as instruções e as políticas que o Apigee executa à medida que processa pedidos de clientes e respostas do back-end.
Produto da API	Uma entidade para APIs de publicação. Os produtos da API são publicados no portal do programador para consumo por programadores externos. Um produto de API apresenta uma interface para aceder a uma ou mais APIs publicadas. A interface (que pode ser descrita através de uma especificação OpenAPI) pode incluir uma combinação de um ou mais dos pedidos da API que são processados por um ou mais proxies de API. Os utilizadores numa organização criam produtos API. Ao fazê-lo, podem anexar metadados arbitrários a cada produto de API. Um tipo de metadados usado frequentemente pode definir um plano de serviço, que pode especificar limites de acesso em chamadas API, estipular requisitos de segurança, permitir a monitorização e as estatísticas, e oferecer funcionalidades adicionais. O Apigee recolhe dados para estatísticas sobre produtos de API.
Fornecedor de APIs	A pessoa ou a entidade que cria e gere proxies e produtos de API. Os programadores de apps de cliente acedem a estas APIs publicadas.
Programador de apps	Uma organização contém um ou mais programadores que criam as apps que consomem as APIs (publicadas como produtos de API) definidas pela sua organização. Os programadores consomem APIs, mas não podem criar APIs nem realizar outras ações na organização. Os programadores podem ser internos à sua empresa, parceiros ou programadores externos que podem ou não pagar pelo acesso às suas APIs. Pode considerar os programadores como clientes que usam as suas APIs. Os programadores têm de estar registados na sua organização antes de poderem registar uma app e receber uma chave de API ou outras credenciais do cliente que permitam o acesso às suas APIs. Como fornecedor de API, é da sua responsabilidade determinar como adicionar, atualizar ou remover programadores na sua organização. Pode adicioná-los manualmente através da IU, criar um portal do programador para os registar através de um Website ou definir e implementar o seu próprio mecanismo de registo através da API Apigee.
App Apigee (ou app)	Os programadores do Apigee criam uma ou mais apps de cliente que consomem as suas APIs. Os programadores que criam aplicações cliente que chamam APIs que requerem verificações de credenciais (como chaves de API ou tokens OAuth) têm primeiro de criar um registo de app na sua organização. Um registo de app fornece ao programador a chave da API, um par chave/segredo ou outras credenciais que têm de ser usadas quando a aplicação cliente chama as suas APIs. Uma vez que todas as apps estão registadas na sua organização, pode usar o Apigee para monitorizar e recolher informações analíticas sobre a app e a respetiva utilização das suas APIs.

Os componentes adicionais do Apigee que não são apresentados são as chaves de API e os tokens OAuth.

O Apigee suporta diferentes tipos de autenticação, como uma chave de API simples, OAuth de 2 passos, OAuth de 3 passos e outros.

Se o fornecedor da API especificar a validação da chave da API como o mecanismo de autorização, a aplicação cliente tem de transmitir uma chave da API com cada pedido às suas APIs. Se essa chave for válida, o Apigee permite o pedido. Em alternativa, se o fornecedor da API especificar a validação de tokens OAuth como o mecanismo de autorização, a aplicação cliente tem de obter primeiro um token OAuth e, em seguida, transmitir esse token com cada pedido às suas APIs. Se esse token for válido, o Apigee permite o pedido. É possível usar outros esquemas de autorização personalizados.

Como fornecedor de APIs, tem de definir uma forma de os programadores registarem as respetivas apps. Cada registo de app tem uma ou mais chaves ou credenciais associadas. Se permitir que os programadores registem as suas próprias aplicações através de um portal para programadores, o programador pode obter a chave ou a credencial necessária para aceder às suas APIs através de uma experiência autónoma conveniente.

No momento do registo da app, os programadores podem optar por aceder a um único produto de API ou a vários produtos de API. A app de um programador usa a mesma chave/credencial para aceder a todos os produtos de API associados à app.

Pode revogar a chave em qualquer altura para que a app do programador deixe de ter acesso às suas APIs (embora a representação registada da app do programador continue a existir na sua organização). Em alternativa, pode revogar um programador, caso em que todas as credenciais de quaisquer apps registadas para esse programador ficam inoperacionais. A revogação é reversível. No momento em que o Apigee cria a credencial da app, pode especificar uma data de validade para que o programador tenha de obter uma nova chave ou credencial após um período específico.

Utilizadores do Apigee

Os utilizadores do Apigee constituem a equipa de API da organização, que pode incluir pessoas como administradores, criadores de proxies de API e produtos de API, ou utilizadores que monitorizam estatísticas e outras estatísticas. Os utilizadores finais são pessoas que usam as apps criadas pelos programadores do Apigee. Na maioria dos casos, esta documentação usa o termo "utilizador" para se referir a um utilizador do Apigee.

Os administradores podem adicionar utilizadores a uma organização.

Os diferentes utilizadores podem ter diferentes funções e privilégios de acesso. Por exemplo, defina alguns utilizadores como administradores da organização e administradores de operações com privilégios para modificar a organização e os respetivos componentes, e defina outros utilizadores com autorizações para criar proxies de API e produtos de API, mas sem os privilégios para modificar outros utilizadores.

Os utilizadores podem ser membros de várias organizações. Por exemplo, a sua empresa pode definir várias organizações no Apigee para suportar diferentes comunidades de programadores, embora, internamente, as mesmas pessoas criem todos os proxies de API e produtos de API e, por isso, sejam membros de todas as suas organizações.

Não tem de criar uma organização do Apigee para ser um utilizador. Um administrador pode adicioná-lo a uma organização existente.

Na Google Cloud consola, aceda à página do Apigee.

Aceder ao Apigee

Concessões e faturação

Quer a organização paga use um modelo de preços de subscrição ou de pagamento mediante utilização, os itens que são medidos para fins de faturação são: ambientes, chamadas API e implementações de proxy.

Os planos de subscrição permitem-lhe pagar antecipadamente as concessões em troca de descontos significativos. Os planos de subscrição fazem sentido em volumes de consumo mais elevados, onde existem números maiores de ambientes, um volume elevado de chamadas API ou um grande número de proxies API sob gestão do Apigee. No modelo de pagamento mediante utilização, paga apenas pelos recursos que usa, mas não beneficia de descontos por volume.

Concessões de subscrição

Organizações	Pode ativar o Apigee em qualquer projeto do Google Cloud. Ao fazê-lo, cria uma organização da Apigee para esse projeto. Pode criar as organizações que quiser. Tal como não é necessário um direito nem um custo para criar um projeto do Google Cloud, não é necessário um requisito de direito para criar uma organização do Apigee.
Ambientes	A concessão para ambientes é expressa em unidades. Existe um processo de dois passos para usar uma autorização de unidade de ambiente: primeiro, cria um ambiente e, em seguida, associa esse ambiente a uma organização. Um ambiente é contabilizado para o seu direito de unidades de ambiente quando o ambiente foi associado a uma organização. Consulte os Limites para o número máximo de ambientes numa única organização. Pode optar por criar um ambiente do Apigee numa ou mais das regiões do Google Cloud disponíveis. Cada região para a qual um ambiente é mapeado consome uma unidade de ambiente da sua autorização. Um ambiente aprovisionado numa única região consome uma unidade de ambiente do seu direito. Um ambiente aprovisionado em duas regiões consome duas unidades de ambiente da sua concessão. A utilização total de unidades de ambiente é o agregado do número de unidades de ambiente usadas em todas as organizações. A sua concessão total de unidades de ambiente é a soma da concessão fornecida no seu Nível de subscrição, mais a concessão adicional obtida através de pacotes de ambientes. A Google aplica a concessão para ambientes. Não pode exceder o limite da concessão. Se tentar criar um ambiente que exceda o limite de autorização, recebe um erro. Pode expandir a sua concessão comprando pacotes de ambiente adicionais.
Chamadas da API	A Google contabiliza cada chamada API processada pelo Apigee. A sua concessão total de chamadas API é a soma da concessão fornecida no seu nível de subscrição mais a concessão adicional obtida através de pacotes de chamadas. No âmbito de um plano de subscrição, a Google não aplica o limite de autorização para chamadas de API. Se exceder o seu direito de chamadas de API, o Apigee continua a publicar chamadas de API. A Google fatura-lhe a utilização que exceda a autorização existente. Pode expandir a sua autorização de chamadas API em qualquer altura comprando pacotes de chamadas adicionais.
Implementações de proxy	A Google contabiliza cada proxy de API que implementar. A sua concessão total de implementação de proxy é a soma da concessão fornecida no seu nível de subscrição, mais a concessão adicional obtida através de pacotes de implementação de proxy. No âmbito de um plano de subscrição, a Google não limita as implementações de proxy à sua concessão. Se implementar mais proxies do que o permitido pela sua autorização, excedendo assim a autorização de implementação de proxies, o Apigee continua a permitir a implementação de novos proxies e continua a publicar chamadas API. A Google fatura-lhe a utilização que exceda a concessão existente. Pode expandir a sua autorização de implementação de proxy comprando pacotes de chamadas adicionais.

Para ver mais detalhes, consulte o artigo Direitos de subscrição.

Concessões de pagamento mediante utilização

Organizações	Pode ativar o Apigee em qualquer projeto do Google Cloud. Ao fazê-lo, cria uma organização da Apigee para esse projeto. Pode criar as organizações que quiser. Tal como não existe nenhum custo financeiro para criar um projeto do Google Cloud, ao abrigo do modelo de preços de pagamento conforme a utilização, não existe nenhum custo financeiro para criar uma organização do Apigee.
Ambientes	Pode anexar vários ambientes à sua organização do Apigee. Existe um processo de dois passos para usar um ambiente: primeiro, cria o ambiente e, em seguida, associa esse ambiente a uma organização. A Google fatura-lhe os ambientes que estão associados a uma organização. Pode criar até 85 ambientes numa única organização. Para ambientes multirregionais, a Google fatura-lhe cada região em que o ambiente está disponível. Pode escolher qualquer uma das regiões do Google Cloud disponíveis.
Chamadas da API	A Google contabiliza cada chamada API processada pelo Apigee. A Google fatura-lhe o número de chamadas API que os seus ambientes do Apigee processam. Não existe limite. O Apigee é dimensionado automaticamente e continua a publicar chamadas API, mesmo quando a carga aumenta.
Implementações de proxy	A Google contabiliza cada proxy de API que implementar. A Google fatura-lhe o número de proxies de API implementados nos seus ambientes do Apigee.

Para mais detalhes, consulte o artigo Direitos de pagamento conforme o uso.