Estás viendo la documentación de Apigee Edge.
Ve a la
Documentación de Apigee X. información
Una organización es el contenedor de nivel superior en Apigee Edge. Contiene todos los proxies de API y los recursos relacionados. Si bien en el resto de este tema se profundiza sobre las organizaciones, se presentan algunos puntos prácticos:
- De forma predeterminada, el nombre de tu organización está en la URL que se usa para llamar a los proxies de tu API, como
que se describe en Acerca de los hosts virtuales.
Por ejemplo:
http(s)://your_org_name-environment.apigee.net/proxy_base_path/...
- El nombre de tu organización está en la URL de la IU de administración de Edge. Por ejemplo, la siguiente URL muestra los proxies de API para la organización
docs:
- Si bien puedes haber creado solo una organización, puedes pertenecer a otras organizaciones como usuario o administrador con permisos específicos. En la IU de administración de Edge, si perteneces a más de una organización, puedes cambiar a una diferente como se describe en Cómo cambiar de una organización a otra.
- Cuando realizas llamadas con la API de Management como un usuario del Administrador de la organización
la organización es una parte obligatoria de la ruta en la mayoría de las llamadas. Por ejemplo, el siguiente
La solicitud cURL a la API de administración muestra una lista de todos los proxies de API en una organización:
curl https://api.enterprise.apigee.com/v1/organizations/your_org_name/apis -u org_admin_email_address
Video: Mira un video breve si deseas obtener información sobre cómo las organizaciones admiten una arquitectura multiusuario para la administración de API.
Componentes de la organización
Cuando creas una cuenta de Edge, Edge crea una organización automáticamente por ti. Una vez creado, puedes agregar usuarios a tu organización, crear proxies y productos de API, y registrar desarrolladores y apps.
En la siguiente imagen, se muestran los componentes principales del modelo de organización de Edge. Esta define la relación entre tus APIs, productos de APIs, apps y desarrolladores de apps Edge.
Este modelo no muestra todas las funciones de Apigee Edge. Si usas la monetización, entonces el modelo tendría componentes adicionales. Para obtener más información, consulta Descripción general de la monetización. Consulta Administra empresas y desarrolladores para obtener información sobre la administración de empresas y desarrolladores con la monetización.
Nombres de organizaciones
El nombre de la organización es:
- Organización de evaluación:
username-eval - Organización pagada: Definida por el usuario en el momento del aprovisionamiento inicial
Una vez creada, no puedes cambiar el nombre a una organización.
El nombre de la organización se vuelve parte de la URL de los proxies de tu API y de la URL cuando si haces una solicitud a la API de Edge Management Por ejemplo, una URL típica que se usa para acceder a una API proxy tiene la siguiente forma:
http://org-name-env.apigee.net/v1/weather/forecastrss
Donde:
- org-name es el nombre de tu organización.
- env es el entorno de implementación del proxy de API, que puede ser de prueba o prod.
Por ejemplo:
http://myorg-test.apigee.net/v1/weather/forecastrss
Componentes de la organización
En la siguiente tabla, se describen los componentes del modelo organizativo con más detalle:
| Componente | Descripción |
|---|---|
|
Organización |
Cada cuenta de Apigee se asigna a una o más organizaciones en Apigee Edge. El organización contiene una representación de todos los componentes, incluidos los proxies de API, los proxies de API productos, paquetes de API, apps y desarrolladores. Los titulares de las cuentas no están limitados a una sola organización. Algunos titulares de las cuentas pueden definir o ser miembros de varias organizaciones que admiten diferentes comunidades de desarrolladores de apps. |
| Entorno | Un contexto de ejecución del entorno de ejecución para los proxies de API en una organización. Consulta la sección a continuación para obtener más información sobre entornos. |
|
Usuario |
Dentro de una organización, la persona que crea la cuenta es automáticamente administrador, puedes crear más usuarios. Los usuarios conforman el equipo de API de la organización, que puede incluir a administradores, proxy de API y creadores de productos de API, usuarios que supervisan el análisis y otras estadísticas, y cualquier otro. Los distintos usuarios pueden tener diferentes roles y privilegios de acceso. Por ejemplo, define algunos usuarios como administradores de la organización y administradores de operaciones con privilegios para modificar la organización y sus componentes. Definir otros usuarios con permisos para lo siguiente: crear proxies de API y productos de API, pero sin los privilegios para modificar otras usuarios. Los usuarios pueden ser miembros de varias organizaciones. Por ejemplo, tu empresa podría definir varias organizaciones en Apigee Edge para brindar asistencia a diferentes comunidades de desarrolladores. Sin embargo, internamente, las mismas personas compilan todos los proxies y productos de API, y por lo tanto, los miembros de todas sus organizaciones. No es necesario crear una cuenta de Apigee, es decir, organización, para ser un usuario. Un administrador puede agregarte a una cuenta organización. Todos los usuarios acceden a Apigee Edge aquí: https://enterprise.apigee.com. |
|
proxy de API |
Los usuarios de una organización crean uno o más proxies de API. Un proxy de API define una asignación de un extremo HTTP disponible de forma pública a un servicio de backend. Los proxies de API también se pueden configurar para incluir seguridad (como OAuth), realizar transformaciones de mensajes (como XML a JSON), limitar el tráfico a los servicios de backend y realizar otras operaciones valiosas en la solicitud, la respuesta y con textos destacados de servicio. Edge recopila datos para análisis en proxies de API. |
|
Producto de API |
Los usuarios de una organización crean uno o más productos de API, en cuyo caso un producto de API se un paquete de proxies de API combinado con un plan de servicio. Ese plan de servicio puede establecer el acceso límites a los proxies de API, proporcionar seguridad, permitir la supervisión y el análisis y proporcionar funciones adicionales. Edge recopila datos para estadísticas de productos de API. |
|
Desarrollador |
Una organización contiene uno o más desarrolladores que compilan las apps que consumen las API (ensambladas en productos de API) definidas por la organización. Los desarrolladores consumen API, pero no pueden crear API ni realizar ninguna otra acción en la organización. Los desarrolladores pueden ser internos de tu empresa, pueden ser socios o pueden ser desarrolladores externos que paguen por el acceso a tus API. Los desarrolladores deben estar registrados en su organización antes de que puedan registrar una aplicación y recibir una clave de API para acceder a sus API. Como proveedor de API, depende de ti determinar cómo agregar, actualizar o quitar desarrolladores de tu organización. Puedes agregarlas de forma manual a través de la IU de administración perimetral, crear un portal para desarrolladores y registrarlos a través de un o definir tu propio mecanismo de registro mediante la administración perimetral en la API de Cloud. No es necesario que un desarrollador tenga una cuenta en Edge, y la mayoría necesitas saber algo sobre Edge. Si el desarrollador tiene una cuenta en Edge, esta es normalmente como un usuario de otra organización o para usar los servicios de la API de Edge. |
|
Aplicación |
Los desarrolladores crean una o más apps cliente que consumen tus APIs. Los desarrolladores deben registrar sus apps en tu organización. Una app de Edge es una de la app real del desarrollador que le proporciona una clave de API para pasar con cada solicitud a tus APIs. Como todas las apps están registradas en tu organización, puedes usar Edge para supervisar y recopilar información analítica sobre la aplicación y el uso que hace de sus APIs, |
|
Clave de API/token de OAuth |
Según el mecanismo de autorización que definas para tus APIs, la app pasa una clave de API junto con cada solicitud a tus APIs. Si esa clave es válida, se permite la solicitud. Edge admite diferentes tipos de autenticación, como una clave de API simple, OAuth de dos segmentos, OAuth de tres segmentos y más. Como proveedor de API, debes definir una forma para que los desarrolladores registren sus aplicaciones. Es registrar su aplicación que le devuelves al desarrollador la clave necesaria para acceder a tus API. En el momento del registro de la app, el desarrollador puede elegir acceder a una sola API o varios productos de API. La app real del desarrollador usa la misma clave para acceder todos los productos de API asociados con la app (la representación registrada del app del desarrollador en Edge). En cualquier momento, puedes revocar la clave para que la app del desarrollador ya no tenga acceso a tus API (aunque la representación registrada de la app del desarrollador siga existiendo en tu organización). O bien, puedes definir un límite de tiempo en una clave para que el desarrollador deba actualizarla después de un período específico. |
Acerca de los entornos
Un entorno es un contexto de ejecución del entorno de ejecución para los proxies de API de una organización. Debes implementar un proxy de API en un entorno para poder acceder a él. Puedes implementar un proxy de API en un solo entorno o en varios.
Una organización puede contener varios entornos. Por ejemplo, puedes definir un dev,
test y prod entorno en una organización.
La organización proporciona alcance para algunas capacidades de Apigee. Por ejemplo, mapa clave-valor (KVM) los datos pueden estar disponibles a nivel de la organización, lo que significa que los proxies de API implementados de ese entorno obtendría los mismos datos de KVM. Algunas capacidades, como el almacenamiento en caché, pueden tener alcance a la organización o a un entorno específico dentro de ella. Los datos de estadísticas de Apigee se particionan según una combinación de organización y entorno.
A continuación, se muestran las principales entidades que administras dentro de una organización, incluidas aquellas definidas globalmente en la organización y aquellos definidos específicamente en un entorno:
