Referencia de configuración de proxy de API,Referencia de configuración de proxy de API

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Esta página se aplica a Apigee y Apigee híbrido .

Ver la documentación de Apigee Edge .

Como desarrollador que trabaja con Apigee, sus principales actividades de desarrollo consisten en configurar proxies de API que funcionan como proxy para API o servicios backend. Este documento es una referencia de todos los elementos de configuración disponibles para la creación de proxies de API.

Si está aprendiendo cómo crear proxies de API, se recomienda que comience con el tema Creación de un proxy de API simple .

Edite la configuración del proxy de API utilizando uno de los siguientes métodos:

• Utilice la interfaz de usuario o API de Apigee.
• Descargue el paquete de configuración de proxy de API, edítelo manualmente y cargue la nueva configuración en Apigee, como se describe en Descargar y cargar un paquete de configuración de proxy de API .

Estructura del directorio de configuración del proxy API

La estructura del directorio de configuración del proxy API se muestra a continuación:

Una configuración de proxy API consta del siguiente contenido:

Configuración base

/apiproxy/weatherapi.xml

La configuración básica de un proxy de API, que define su nombre. Este nombre debe ser único dentro de la organización.

Configuración de muestra:

<APIProxy name="weatherapi">
</APIProxy>

Elementos de configuración base

Punto final del proxy

La siguiente imagen muestra el flujo de solicitud/respuesta:

/apiproxy/proxies/default.xml

La configuración de ProxyEndpoint define la interfaz de entrada (de cara al cliente) para un proxy de API. Al configurar un punto final de proxy, se establece una configuración de red que define cómo las aplicaciones cliente ( apps ) deben invocar la API proxyizada.

La siguiente configuración de muestra de ProxyEndpoint se almacenaría en /apiproxy/proxies :

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Los elementos de configuración necesarios en un punto final de proxy básico son:

Elementos de configuración de ProxyEndpoint

Cómo configurar RouteRules

Un punto final de destino nombrado hace referencia a un archivo de configuración en /apiproxy/targets al cual RouteRule reenvía una solicitud después de ser procesada por el punto final del proxy.

Por ejemplo, la siguiente RouteRule hace referencia a la configuración /apiproxy/targets/myTarget.xml :

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Invocación directa de URL

Un endpoint proxy también puede invocar directamente un servicio backend. La invocación directa de URL omite cualquier configuración de TargetEndpoint con nombre en /apiproxy/targets . Por este motivo, TargetEndpoint es una configuración de proxy de API opcional, aunque, en la práctica, no se recomienda la invocación directa desde el endpoint proxy.

Por ejemplo, la siguiente RouteRule realiza una llamada HTTP a http://api.mycompany.com/v2 .

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Rutas condicionales

Las reglas de ruta se pueden encadenar para permitir el enrutamiento dinámico en tiempo de ejecución. Las solicitudes entrantes se pueden enrutar a configuraciones de TargetEndpoint con nombre, directamente a URL o a una combinación de ambas, según los encabezados HTTP, el contenido del mensaje, los parámetros de consulta o información contextual como la hora del día, la configuración regional, etc.

Las reglas de ruta condicionales funcionan como otras sentencias condicionales en Apigee. Consulte la referencia de condiciones y la referencia de variables de flujo .

Por ejemplo, la siguiente combinación de RouteRule evalúa primero la solicitud entrante para verificar el valor de un encabezado HTTP. Si el encabezado HTTP routeTo tiene el valor TargetEndpoint1 , la solicitud se reenvía al punto final de destino denominado TargetEndpoint1 . De lo contrario, la solicitud entrante se reenvía a http://api.mycompany.com/v2 .

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Rutas nulas

Se puede definir una RouteRule nula para casos en los que no es necesario reenviar el mensaje de solicitud al endpoint de destino. Esto resulta útil cuando el endpoint proxy realiza todo el procesamiento necesario, por ejemplo, al usar JavaScript para llamar a un servicio externo o al recuperar datos de una búsqueda en el almacén de claves/valores de Apigee.

Por ejemplo, lo siguiente define una ruta nula:

<RouteRule name="GoNowhere"/>

Las rutas nulas condicionales pueden ser útiles. En el siguiente ejemplo, se configura una ruta nula para ejecutarse cuando el encabezado HTTP request.header.X-DoNothing tiene un valor distinto de null .

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Recuerde que las reglas de ruta se pueden encadenar, por lo que una ruta nula condicional normalmente sería un componente de un conjunto de reglas de ruta diseñadas para soportar el enrutamiento condicional.

Un uso práctico de una ruta nula condicional sería el soporte del almacenamiento en caché. Al usar el valor de la variable establecida por la política de caché, se puede configurar un proxy de API para que ejecute la ruta nula cuando se sirve una entrada desde la caché.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

Punto final de destino

Un endpoint de destino es el equivalente saliente de un endpoint proxy. Un endpoint de destino funciona como cliente de un servicio backend o API: envía solicitudes y recibe respuestas.

Un proxy de API no necesita tener puntos de conexión de destino. Estos puntos de conexión se pueden configurar para llamar a URL directamente. Un proxy de API sin puntos de conexión de destino suele contener un punto de conexión que llama directamente a un servicio de backend o que está configurado para llamar a un servicio mediante Java o JavaScript.

Configuración de TargetEndpoint

/targets/default.xml

El punto final de destino define la conexión saliente de Apigee a otro servicio o recurso.

A continuación se muestra un ejemplo de configuración de TargetEndpoint:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
    <Authentication/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Elementos de configuración de TargetEndpoint

Un punto final de destino puede llamar a un objetivo de una de las siguientes maneras:

• HTTPTargetConnection para llamadas HTTP o HTTPS
• LocalTargetConnection para encadenamiento de proxy a proxy local

Configure solo uno de estos en un punto final de destino.

<Properties>
  <Property name="response.payload.parse.limit">15M</Property>
</Properties>

Uso del elemento <Authentication>

Referencia de error del elemento <Authentication>

Si está utilizando el elemento <Authentication> , puede encontrar posibles mensajes de error y sugerencias para la solución de problemas de implementación y errores de tiempo de ejecución en la sección Errores de la documentación de la política ServiceCallout.

Ejemplos del elemento <Authentication>

El siguiente ejemplo muestra cómo llamar a un servicio implementado en Cloud Run como destino utilizando el elemento Authentication para generar un token OpenID Connect necesario para autenticar la llamada:

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
      <Properties/>
      <URL>https://cloudrun-hostname.a.run.app/test</URL>
      <Authentication>
          <GoogleIDToken>
             <Audience>https://cloudrun-hostname.a.run.app/test</Audience>
          </GoogleIDToken>
     </Authentication>
  </HTTPTargetConnection>
</TargetEndpoint>

El siguiente ejemplo muestra cómo llamar a un TargetService que apunta a Cloud Run mediante el elemento Authentication para generar un token de OpenID Connect necesario para autenticar la llamada. El elemento HeaderName añade el token de portador generado a un encabezado llamado X-Serverless-Authorization que se envía al sistema de destino. El encabezado Authorization , si está presente, se deja sin modificar y también se envía en la solicitud.

<TargetEndpoint name="TargetEndpoint-1">
   <HTTPTargetConnection>
     <Authentication>
        <HeaderName>X-Serverless-Authorization</HeaderName>
        <GoogleIDToken>
            <Audience ref="flow.variable.audience">https://cloudrun-hostname.a.run.app</Audience>
        </GoogleIDToken>
     </Authentication>
      <LoadBalancer>
         <Server name="cloud-run-target" />
      </LoadBalancer>
   </HTTPTargetConnection>
</TargetEndpoint>

El siguiente ejemplo muestra cómo llamar a un TargetService que apunta al servicio Google Secret Manager . En este ejemplo, el elemento GoogleAccessToken está configurado para generar un token de autenticación de Google para autenticar la solicitud de destino:

<HTTPTargetConnection>
   <Authentication>
      <GoogleAccessToken>
        <Scopes>
          <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
        </Scopes>
      </GoogleAccessToken>
    </Authentication>
    <URL>
      https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id
    </URL>
</HTTPTargetConnection>

El siguiente ejemplo muestra cómo configurar automáticamente la audiencia del GoogleIDToken. Cuando useTargetUrl es true y la variable referenciada no se resuelve en una variable válida, se utiliza como audiencia la URL del destino (sin incluir los parámetros de consulta). Supongamos que la ruta de la solicitud es /foobar y la URL del servidor de destino es https://xyz.com ; la audiencia del GoogleIDToken se configurará automáticamente en https://xyz.com/foobar .

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
    <Authentication>
      <GoogleIDToken>
        <Audience ref='myvariable' useTargetUrl="true"/>
      </GoogleIDToken>
    </Authentication>
    <LoadBalancer>
      <Server name="TS" />
    </LoadBalancer>
  </HTTPTargetConnection>
</TargetEndpoint>

Configuración del punto final de destino TLS/SSL

Los endpoints de destino suelen necesitar gestionar conexiones HTTPS con una infraestructura de backend heterogénea. Por ello, se admiten diversas opciones de configuración TLS/SSL.

Elementos de configuración de TargetEndpoint TLS/SSL

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.2</Protocol>
 <Protocol>TLSv1.3</Protocol>
</Protocols>

Especificación de la aplicación de SSL a nivel de entorno

Si SSLInfo.Enforce se establece como true o false , el valor especificado anula cualquier opción de aplicación granular especificada en los bloques <SSLInfo> en las configuraciones de TargetEndpoint o TargetServer.

Si no se configura SSLInfo.Enforce , la aplicación de SSL se determina mediante los valores especificados mediante el elemento <Enforce> dentro de cada bloque <SSLInfo> . Para más información, consulte Configuración de TLS/SSL TargetEndpoint.

En el siguiente ejemplo, SSLInfo.Enforce se establece en true . En el resultado, se puede ver que SSL se aplica en el entorno especificado.

VALUE=true
curl -Ss -v -X PUT \
    "https://apigee.googleapis.com/v1/organizations/MYORG/environments/MYENV" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer TOKEN" \
    -d '{
        "name": "MYENV",
        "properties": {
            "property": [{
                "name": "features.SSLInfo.Enforce",
                "value": "'"$VALUE"'"
            }]
        }
    }'
  

Producción:

{
  ...
  "properties": {
    "property": [
      {
        "name": "features.SSLInfo.Enforce",
        "value": "true"
      }
    ]
  },
  ...
}

Punto final de destino de muestra con autenticación de cliente saliente habilitada

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <Enforce>true</Enforce>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Para obtener instrucciones detalladas, consulte Opciones para configurar TLS .

Uso de variables de flujo para establecer valores TLS/SSL dinámicamente

También puede configurar dinámicamente los detalles de TLS/SSL para cumplir con los requisitos flexibles de tiempo de ejecución. Por ejemplo, si su proxy se conecta a dos destinos potencialmente diferentes (un destino de prueba y uno de producción), puede configurar su proxy de API para que detecte programáticamente el entorno al que llama y establezca dinámicamente referencias al almacén de claves y al almacén de confianza adecuados. El artículo de la comunidad de Apigee "SSLInfo dinámico para TargetEndpoint mediante referencia de variables" explica este escenario con más detalle y proporciona ejemplos de proxy de API implementables.

En el siguiente ejemplo de cómo se configuraría la etiqueta <SSLInfo> en una configuración de TargetEndpoint, los valores se pueden proporcionar en tiempo de ejecución, por ejemplo, mediante una llamada de Java, una política de JavaScript o una política AssignMessage . Utilice las variables de mensaje que contengan los valores que desee configurar.

Las variables solo se permiten en los siguientes elementos.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Uso de referencias para establecer valores TLS/SSL dinámicamente

Al configurar un punto final de destino que usa HTTPS, debe tener en cuenta el caso en que el certificado TLS/SSL expire o un cambio en la configuración del sistema requiera actualizar el certificado.

Para obtener más información, consulte Manejo de certificados caducados .

Sin embargo, puede configurar opcionalmente el punto final de destino para que utilice una referencia al almacén de claves o al almacén de confianza. La ventaja de usar una referencia es que puede actualizarla para que apunte a un almacén de claves o de confianza diferente y así actualizar el certificado TLS/SSL sin tener que reiniciar los procesadores de mensajes.

Por ejemplo, a continuación se muestra un punto final de destino que utiliza una referencia al almacén de claves:

<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>false</ClientAuthEnabled>
  <KeyStore>ref://keystoreref</KeyStore>
  <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

Utilice la siguiente llamada a la API POST para crear la referencia denominada keystoreref :

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>'

Donde $TOKEN se establece en su token de acceso de OAuth 2.0, como se describe en "Obtención de un token de acceso de OAuth 2.0" . Para obtener información sobre las opciones curl utilizadas en este ejemplo, consulte "Uso de curl" . Para obtener una descripción de las variables de entorno utilizadas, consulte "Configuración de variables de entorno para solicitudes de la API de Apigee" .

La referencia especifica el nombre del almacén de claves y su tipo.

Utilice la siguiente llamada API GET para ver la referencia:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Donde $TOKEN se establece en su token de acceso de OAuth 2.0, como se describe en "Obtención de un token de acceso de OAuth 2.0" . Para obtener información sobre las opciones curl utilizadas en este ejemplo, consulte "Uso de curl" . Para obtener una descripción de las variables de entorno utilizadas, consulte "Configuración de variables de entorno para solicitudes de la API de Apigee" .

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Donde $TOKEN se establece en su token de acceso de OAuth 2.0, como se describe en "Obtención de un token de acceso de OAuth 2.0" . Para obtener información sobre las opciones curl utilizadas en este ejemplo, consulte "Uso de curl" . Para obtener una descripción de las variables de entorno utilizadas, consulte "Configuración de variables de entorno para solicitudes de la API de Apigee" .

Para cambiar posteriormente la referencia para que apunte a un almacén de claves diferente, asegurándose de que el alias tenga el mismo nombre, utilice la siguiente llamada PUT:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -X PUT \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'

Donde $TOKEN se establece en su token de acceso de OAuth 2.0, como se describe en "Obtención de un token de acceso de OAuth 2.0" . Para obtener información sobre las opciones curl utilizadas en este ejemplo, consulte "Uso de curl" . Para obtener una descripción de las variables de entorno utilizadas, consulte "Configuración de variables de entorno para solicitudes de la API de Apigee" .

TargetEndpoint con equilibrio de carga de destino

Los puntos finales de destino admiten el equilibrio de carga entre múltiples servidores de destino nombrados mediante tres algoritmos de equilibrio de carga.

Para obtener instrucciones detalladas, consulte Equilibrio de carga entre servidores back-end .

Punto final de integración

Un IntegrationEndpoint es un endpoint de destino que ejecuta específicamente integraciones de Apigee . Si ha configurado un IntegrationEndpoint, Apigee envía el objeto de solicitud a su plataforma de integración para su ejecución. Para ejecutar la integración, además de configurar el IntegrationEndpoint, también debe agregar la política SetIntegrationRequest en el flujo de proxy.

Puede configurar su integración para que se ejecute de forma síncrona o asíncrona configurando el elemento <AsyncExecution> en la configuración de IntegrationEndpoint. Para obtener más información, consulte Ejecución síncrona vs. asíncrona . Tras ejecutar la integración, Apigee guarda la respuesta en el mensaje de respuesta .

Configuración de IntegrationEndpoint

Para configurar un punto de integración como punto de destino, añada el elemento IntegrationEndpoint a la configuración de ProxyEndpoint. A continuación, se muestra un ejemplo de configuración de ProxyEndpoint:

<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>my-set-integration-request-policy</Name>
            </Step>
        </Request>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow"/>
    <HTTPProxyConnection>
        <BasePath>/integration-endpoint-test</BasePath>
        <Properties/>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <IntegrationEndpoint>my-int-endpoint</IntegrationEndpoint>
    </RouteRule>
</ProxyEndpoint>

En la configuración de ejemplo de ProxyEndpoint, Apigee realiza las siguientes tareas:

1. En PreFlow, ejecuta la política denominada my-set-integration-request-policy , que establece el objeto de solicitud de integración y las variables del flujo de integración.
2. Utiliza my-int-endpoint como punto final de destino, como se especifica en RouteRule .
3. Lee el objeto de solicitud de integración creado por my-set-integration-request-policy .
4. Envía la solicitud a la plataforma de integración de Apigee utilizando el objeto de solicitud y las variables de flujo establecidas por la política SetIntegrationRequest.
5. Guarda la respuesta de la integración en el mensaje de respuesta.

El archivo XML que contiene la declaración <IntegrationEndpoint> estará disponible en el directorio APIGEE_BUNDLE_DIRECTORY /apiproxy/integration-endpoints/ . Si crea su proxy de API mediante la opción Develop > API Proxies > CREATE NEW > Integration target , Apigee almacena la declaración en el archivo /apiproxy/integration-endpoints/default.xml . Si crea el XML del punto final de integración desde la interfaz de usuario, puede asignarle un nombre personalizado.

El siguiente ejemplo muestra la declaración del elemento <IntegrationEndpoint> en el archivo XML:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>false</AsyncExecution>
</IntegrationEndpoint>

Elementos de configuración de IntegrationEndpoint

Ejecución sincrónica vs. asincrónica

Puede configurar la integración para que se ejecute en modo síncrono o asíncrono. Para comprender la diferencia entre los modos de ejecución síncrono y asíncrono, consulte <AsyncExecution> .

Utilice el elemento <AsyncExecution> dentro de </IntegrationEndpoint> para especificar la ejecución síncrona o asíncrona. Si <AsyncExecution> se establece en true , la integración se ejecuta asíncronamente. Si se establece en false , la integración se ejecuta síncronamente.

El siguiente ejemplo establece AsyncExecution en true :

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>true</AsyncExecution>
</IntegrationEndpoint>

Políticas

El directorio /policies de un proxy API contiene todas las políticas disponibles para adjuntarse a los flujos en el proxy API.

Elementos de configuración de políticas

Apego de política

La siguiente imagen muestra la secuencia de ejecución de flujos de proxy API:

Como se muestra arriba:

Las políticas se adjuntan como pasos de procesamiento a los flujos . El nombre de la política se utiliza para hacer referencia a la política que se aplicará como un paso de procesamiento. El formato de un archivo adjunto de políticas es el siguiente:

<Step><Name>MyPolicy</Name></Step>

Las políticas se aplican en el orden en que se unen a un flujo. Por ejemplo:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Elementos de configuración de archivos adjuntos de políticas

Flujos

ProxyEndpoint y TargetEndpoint definen una tubería para el procesamiento de mensajes de solicitud y respuesta. Una tubería de procesamiento consiste en un flujo de solicitud y un flujo de respuesta. Cada flujo de solicitud y flujo de respuesta se subdivide en un flujo previo, uno o más flujos condicionales o nombrados opcionales, y un posterior a la flujo.

• Preflow: siempre se ejecuta. Se ejecuta antes de que fluya cualquier condicional.
• Postflow: siempre se ejecuta. Se ejecuta después de cualquier flujo condicional.

Además, puede agregar un PostClientFlow al punto final proxy, que se ejecuta después de que la respuesta se devuelve a la aplicación del cliente solicitante. Solo la política de mensajería se puede adjuntar a este flujo. PostClientFlow reduce la latencia del proxy API y pone a disposición de la información para el registro que no se calcula hasta que la respuesta se devuelve al cliente, como el client.sent.start.timestamp y client.sent.end.timestamp . El flujo se usa principalmente para medir el intervalo de tiempo entre el inicio y el tiempo final de las campañas para el mensaje de respuesta.

Aquí hay un ejemplo de un flujo postclient con una política de registro de mensajes adjunta.

...
  <PostFlow name="PostFlow">
      <Request/>
      <Response/>
  </PostFlow>
  <PostClientFlow>
      <Request/>
      <Response>
          <Step>
              <Name>Message-Logging-1</Name>
          </Step>
      </Response>
  </PostClientFlow>
  ...

La tubería de procesamiento proxy API ejecuta flujos en la siguiente secuencia:

Solicitud de tubería:

1. Solicitud de proxy Preflow
2. Flujos condicionales de solicitud de solicitud (opcional)
3. Postez de solicitud de solicitud de proxy
4. Solicitud de objetivo Preflow
5. Flujos condicionales de solicitud de objetivo (opcional)
6. Solicitud de objetivo Postflow

Tubería de respuesta:

1. Respuesta del objetivo Preflow
2. Flujos condicionales de respuesta objetivo (opcional)
3. Respuesta de destino Postflow
4. Respuesta proxy Preflow
5. Flujos condicionales de respuesta a proxy (opcional)
6. Respuesta de poder Postflow
7. Respuesta PostClientFlow (opcional)

Solo aquellos flujos con archivos adjuntos de políticas deben configurarse en las configuraciones ProxyendPoint o TargetEndpoint. Preflow y Postflow solo necesitan especificarse en una configuración ProxyendPoint o TargetEndpoint cuando se debe aplicar una política durante el procesamiento previo al flujo o después del flujo.

A diferencia de los flujos condicionales, el orden de los elementos previos al flujo y después del flujo no es importante: el proxy API siempre ejecutará cada uno en el punto apropiado de la tubería, independientemente de dónde aparezcan en la configuración del punto final.

Flujos condicionales

Los puntos finales de proxy y los puntos finales objetivo admiten un número ilimitado de flujos condicionales (también conocidos como flujos nombrados ).

Las pruebas de proxy API para la condición especificada en el flujo condicional y, si se cumple la condición, los pasos de procesamiento en el flujo condicional son ejecutados por el proxy API. Si no se cumple la condición, se omiten los pasos de procesamiento en el flujo condicional. Los flujos condicionales se evalúan en el orden definido en el proxy API y el primero cuya condición se cumple.

Al definir los flujos condicionales, obtiene la capacidad de aplicar pasos de procesamiento en un proxy API basado en:

• URI de solicitud
• Verbo http ( GET / PUT / POST / DELETE )
• Valor de un parámetro de consulta, encabezado y parámetro de formulario
• Muchos otros tipos de condiciones

Por ejemplo, el siguiente flujo condicional especifica que se ejecuta solo cuando la ruta de recursos de solicitud es /accesstoken . Cualquier solicitud entrante con la ruta /accesstoken hace que este flujo se ejecute, junto con cualquier política que esté conectada al flujo. Si la ruta de solicitud no incluye el sufijo /accesstoken , entonces el flujo no se ejecuta (aunque otro flujo condicional podría).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

Elementos de configuración de flujo

Procesamiento de pasos

Apigee hace cumplir el orden secuencial de los flujos condicionales. Los flujos condicionales se ejecutan de arriba a abajo. El primer flujo condicional cuya condición se evalúa a true se ejecuta, y solo se ejecuta un flujo condicional.

Por ejemplo, en la siguiente configuración de flujo, cualquier solicitud entrante que no incluya el sufijo de ruta /first o /second hará que el ThirdFlow ejecute, aplicando la política llamada Return404 .

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Recursos

Los "recursos" (archivos de recursos para su uso en proxies API) son scripts, código y transformaciones XSL que se pueden conectar a flujos utilizando políticas. Estos aparecen en la sección Scripts del Editor de proxy API en la UI de Apigee.

Consulte Gestión de recursos para los tipos de recursos compatibles.

Los recursos se pueden almacenar en un proxy API, un entorno o una organización. En cada caso, se hace referencia a un recurso por nombre en una política. Apigee resuelve el nombre moviéndose del proxy API, al medio ambiente, al nivel de organización.

Un recurso almacenado a nivel de organización puede ser referenciado por políticas en cualquier entorno. Un recurso almacenado a nivel de entorno puede ser referenciado por políticas en ese entorno. Un recurso almacenado en el nivel de proxy API solo puede referenciarse por políticas en ese proxy API.

Esta página se aplica a Apigee y Apigee híbrido .

Ver la documentación de Apigee Edge .

Como desarrollador que trabaja con Apigee, sus actividades principales de desarrollo implican la configuración de proxies de API que funcionan como proxies para API o servicios de backend. Este documento es una referencia de todos los elementos de configuración disponibles para usted al construir proxies API.

Si está aprendiendo a construir proxies API, se recomienda que comience con el tema construyendo un proxy de API simple .

Edite la configuración proxy de su API utilizando uno de los siguientes métodos:

• Use la UI o API Apigee.
• Descargue el paquete de configuración del proxy API, edítelo manualmente y cargue la nueva configuración en Apigee, como se describe en la descarga y la carga de un paquete de configuración de proxy API .

Estructura del directorio de configuración proxy de API

La estructura del directorio de configuración del proxy API se muestra a continuación:

Una configuración proxy de API consiste en los siguientes contenidos:

Configuración base

/apiproxy/weatherapi.xml

La configuración base para un proxy API, que define el nombre del proxy API. El nombre debe ser único dentro de una organización.

Configuración de muestra:

<APIProxy name="weatherapi">
</APIProxy>

Elementos de configuración base

Punto final del proxy

La siguiente imagen muestra el flujo de solicitud/respuesta:

/apiproxy/proxies/default.xml

La configuración de proxyendpoint define la interfaz entrante (orientado al cliente) para un proxy API. Cuando configura un punto final proxy, está configurando una configuración de red que define cómo las aplicaciones del cliente ( APPS ) deben invocar la API proxy.

La siguiente configuración de proxyendpoint de muestra se almacenaría en /apiproxy/proxies :

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Los elementos de configuración requeridos en un punto final de proxy básico son:

Elementos de configuración de proxyendpoint

Cómo configurar los routerules

Un punto final de destino con nombre se refiere a un archivo de configuración en /apiproxy/targets a los que el routerule reenvía una solicitud después del procesamiento por el punto final proxy.

Por ejemplo, el siguiente routerule se refiere a la configuración /apiproxy/targets/myTarget.xml :

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Invocación de URL directo

Un punto final proxy también puede invocar directamente un servicio de backend. La invocación de URL directa omite cualquier configuración de TargetEndpoint nombrada en /apiproxy/targets ). Por esta razón, TargetEndpoint es una configuración de proxy API opcional, aunque, en la práctica, no se recomienda la invocación directa desde el punto final proxy.

Por ejemplo, el siguiente routerule hace una llamada http a http://api.mycompany.com/v2 .

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Rutas condicionales

Los routerules se pueden encadenar para admitir el enrutamiento dinámico en tiempo de ejecución. Las solicitudes entrantes se pueden enrutar a las configuraciones de TargetEndpoint nombradas, directamente a URL, o a una combinación de los dos, basadas en encabezados HTTP, contenido de mensajes, parámetros de consulta o información contextual como hora del día, localidad, etc.

Los routerules condicionales funcionan como otras declaraciones condicionales en Apigee. Ver Condiciones Referencia de referencia y flujo de variables .

Por ejemplo, la siguiente combinación de routerule evalúa primero la solicitud entrante para verificar el valor de un encabezado HTTP. Si la routeTo de encabezado HTTP tiene el valor TargetEndpoint1 , entonces la solicitud se reenvía al punto final de destino llamado TargetEndpoint1 . Si no, entonces la solicitud de entrada se reenvía a http://api.mycompany.com/v2 .

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Rutas nulas

Se puede definir un routerule nulo para admitir escenarios en los que el mensaje de solicitud no necesita reenviarse al punto final de destino. Esto es útil cuando el punto final proxy realiza todo el procesamiento necesario, por ejemplo, mediante el uso de JavaScript para llamar a un servicio externo o recuperar datos de una búsqueda al almacén de clave/valor Apigee.

Por ejemplo, lo siguiente define una ruta nula:

<RouteRule name="GoNowhere"/>

Las rutas nulas condicionales pueden ser útiles. En el siguiente ejemplo, una ruta nula está configurada para ejecutar cuando un encabezado HTTP request.header.X-DoNothing tiene un valor que no sea null .

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Recuerde, se pueden encadenar los routerules, por lo que una ruta nula condicional típicamente sería un componente de un conjunto de routerules diseñados para soportar el enrutamiento condicional.

Un uso práctico de una ruta nula condicional sería apoyo del almacenamiento en caché. Al usar el valor de la variable establecida por la política de caché, puede configurar un proxy API para ejecutar la ruta nula cuando se sirve una entrada desde el caché.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

Punto de destino

Un punto final objetivo es el equivalente de salida de un punto final proxy. Un punto final objetivo funciona como cliente a un servicio o API de backend: envía solicitudes y recibe respuestas.

Un proxy API no necesita tener puntos finales objetivo. Los puntos finales proxy se pueden configurar para llamar a las URL directamente. Un proxy API sin puntos finales de destino generalmente contiene un punto final proxy que llama directamente a un servicio de backend, o que está configurado para llamar a un servicio usando Java o JavaScript.

Configuración de TargetendPoint

/targets/default.xml

El punto final objetivo define la conexión de salida de Apigee a otro servicio o recurso.

Aquí hay una muestra de configuración de TargetEndpoint:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
    <Authentication/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Elementos de configuración de TargetendPoint

Un punto final objetivo puede llamar a un objetivo de una de las siguientes maneras:

• HttpTargetConnection para llamadas http o https
• LocalTargetConnection para encadenamiento local de proxy a proxy

Configure solo uno de estos en un punto final de destino.

<Properties>
  <Property name="response.payload.parse.limit">15M</Property>
</Properties>

<Authentication> uso de elementos

<Authentication> referencia de error de elementos

Si está utilizando el elemento <Authentication> , puede encontrar posibles mensajes de error y consejos de solución de problemas para los errores de implementación y tiempo de ejecución en la sección Errores de la documentación de la política ServiceCallout.

<Authentication> ejemplos de elementos

El siguiente ejemplo muestra cómo llamar a un servicio implementado en la nube ejecutada como el objetivo utilizando el elemento Authentication para generar un token de conexión OpenID necesario para autenticar la llamada:

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
      <Properties/>
      <URL>https://cloudrun-hostname.a.run.app/test</URL>
      <Authentication>
          <GoogleIDToken>
             <Audience>https://cloudrun-hostname.a.run.app/test</Audience>
          </GoogleIDToken>
     </Authentication>
  </HTTPTargetConnection>
</TargetEndpoint>

El siguiente ejemplo muestra cómo llamar a un servicio Target que apunta a la ejecución de la nube utilizando el elemento Authentication para generar un token de Connect OpenID necesario para autenticar la llamada. El elemento HeaderName agrega el token de portador generado a un encabezado llamado X-Serverless-Authorization que se envía al sistema de destino. El encabezado Authorization , si está presente, se deja sin modificar y también se envía en la solicitud.

<TargetEndpoint name="TargetEndpoint-1">
   <HTTPTargetConnection>
     <Authentication>
        <HeaderName>X-Serverless-Authorization</HeaderName>
        <GoogleIDToken>
            <Audience ref="flow.variable.audience">https://cloudrun-hostname.a.run.app</Audience>
        </GoogleIDToken>
     </Authentication>
      <LoadBalancer>
         <Server name="cloud-run-target" />
      </LoadBalancer>
   </HTTPTargetConnection>
</TargetEndpoint>

El siguiente ejemplo muestra cómo llamar a un servicio Target que apunta al Servicio de Google Secret Manager . En este ejemplo, el elemento GoogleAccesStoken está configurado para generar un token de autenticación de Google para autenticar la solicitud de destino:

<HTTPTargetConnection>
   <Authentication>
      <GoogleAccessToken>
        <Scopes>
          <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
        </Scopes>
      </GoogleAccessToken>
    </Authentication>
    <URL>
      https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id
    </URL>
</HTTPTargetConnection>

El siguiente ejemplo muestra cómo establecer automáticamente la audiencia del GoogleIDToken. Cuando useTargetUrl es true y la variable referenciada no se resuelve a una variable válida, la URL del objetivo (excluyendo los parámetros de consulta) se usa como audiencia. Supongamos que la ruta de solicitud es /foobar y la URL del servidor de destino es https://xyz.com , la audiencia del GoogleIDToken se establecerá automáticamente en https://xyz.com/foobar .

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
    <Authentication>
      <GoogleIDToken>
        <Audience ref='myvariable' useTargetUrl="true"/>
      </GoogleIDToken>
    </Authentication>
    <LoadBalancer>
      <Server name="TS" />
    </LoadBalancer>
  </HTTPTargetConnection>
</TargetEndpoint>

Configuración TLS/SSL TargetEndpoint

Los puntos finales objetivo a menudo necesitan administrar conexiones HTTPS con infraestructura de backend heterogénea. Por esta razón, se admiten una serie de configuraciones de configuración TLS/SSL.

Elementos de configuración TLS/SSL TargetEndpoint

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.2</Protocol>
 <Protocol>TLSv1.3</Protocol>
</Protocols>

Especificar la aplicación SSL a nivel de entorno

Si SSLInfo.Enforce se establece en true o false , el valor especificado anula cualquier opción de aplicación granular especificadas en los bloques <SSLInfo> en TargetEndpoint o en configuraciones de TargetServer.

Si SSLInfo.Enforce no es establecido, la aplicación SSL está determinada por cualquier valor especificado usando el elemento <Enforce> dentro de los bloques individuales <SSLInfo> . Para obtener más información, consulte la configuración TLS/SSL TargetEndpoint.

En el siguiente ejemplo, SSLInfo.Enforce se establece en true . En la salida resultante, puede ver que SSL se aplica en el entorno especificado.

VALUE=true
curl -Ss -v -X PUT \
    "https://apigee.googleapis.com/v1/organizations/MYORG/environments/MYENV" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer TOKEN" \
    -d '{
        "name": "MYENV",
        "properties": {
            "property": [{
                "name": "features.SSLInfo.Enforce",
                "value": "'"$VALUE"'"
            }]
        }
    }'
  

Producción:

{
  ...
  "properties": {
    "property": [
      {
        "name": "features.SSLInfo.Enforce",
        "value": "true"
      }
    ]
  },
  ...
}

Ejemplo de punto final de destino con autenticación de cliente saliente habilitado

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <Enforce>true</Enforce>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Para obtener instrucciones detalladas, consulte Opciones para configurar TLS .

Uso de variables de flujo para establecer valores TLS/SSL dinámicamente

También puede establecer dinámicamente los detalles de TLS/SSL para admitir los requisitos de tiempo de ejecución flexibles. Por ejemplo, si su proxy se conecta a dos objetivos potencialmente diferentes (un objetivo de prueba y un objetivo de producción), puede hacer que su proxy API detecte programáticamente qué entorno está llamando y establece dinámicamente las referencias a la tienda de claves y la tienda de confianza apropiada. El SSLINFO dinámico para TargetEndpoint utilizando el artículo de la comunidad de Apigee de referencia variable explica este escenario con más detalle y proporciona ejemplos de proxy API desplegables.

In the following example of how the <SSLInfo> tag would be set in a TargetEndpoint configuration, the values can be supplied at runtime, for example, by a Java Callout, a JavaScript policy, or an AssignMessage policy . Use whichever message variables contain the values you want to set.

Variables are allowed in only the following elements.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Using references to set TLS/SSL values dynamically

When configuring a target endpoint that uses HTTPS, you have to consider the case when the TLS/SSL cert expires, or a change to the system configuration requires you to update the cert.

For more information, see Handling expired certificates .

However, you can optionally configure the target endpoint to use a reference to the keystore or truststore instead. The advantage to using a reference is that you can update the reference to point to a different keystore or truststore to update the TLS/SSL cert without having to restart Message Processors.

For example, shown below is a target endpoint that uses a reference to the keystore:

<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>false</ClientAuthEnabled>
  <KeyStore>ref://keystoreref</KeyStore>
  <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

Use the following POST API call to create the reference named keystoreref :

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>'

Where $TOKEN is set to your OAuth 2.0 access token, as described in Obtaining an OAuth 2.0 access token . For information about the curl options used in this example, see Using curl . For a description of the environment variables used, see Setting environment variables for Apigee API requests .

The reference specifies the name of the keystore and its type.

Use the following GET API call to view the reference:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Where $TOKEN is set to your OAuth 2.0 access token, as described in Obtaining an OAuth 2.0 access token . For information about the curl options used in this example, see Using curl . For a description of the environment variables used, see Setting environment variables for Apigee API requests .

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Where $TOKEN is set to your OAuth 2.0 access token, as described in Obtaining an OAuth 2.0 access token . For information about the curl options used in this example, see Using curl . For a description of the environment variables used, see Setting environment variables for Apigee API requests .

To later change the reference to point to a different keystore, ensuring that the alias has the same name, use the following PUT call:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -X PUT \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'

Where $TOKEN is set to your OAuth 2.0 access token, as described in Obtaining an OAuth 2.0 access token . For information about the curl options used in this example, see Using curl . For a description of the environment variables used, see Setting environment variables for Apigee API requests .

TargetEndpoint with target load balancing

Target endpoints support load balancing across multiple named target servers using three load balancing algorithms.

For detailed instructions, refer to Load balancing across backend servers .

IntegrationEndpoint

An IntegrationEndpoint is a target endpoint that specifically runs Apigee integrations . If you have configured an IntegrationEndpoint, Apigee sends the request object to Apigee's Integration Platform for execution. To run your integration, in addition to configuring the IntegrationEndpoint, you must also add the SetIntegrationRequest policy in your proxy flow.

You can configure your integration to execute either synchronously or asynchronously by setting the <AsyncExecution> element in the IntegrationEndpoint configuration. For more information, see Synchronous vs Asynchronous execution . After running the integration, Apigee saves the response in the response message .

Configuring IntegrationEndpoint

To configure an integration endpoint as your target endpoint, add the IntegrationEndpoint element to your ProxyEndpoint configuration. The following is a sample ProxyEndpoint configuration:

<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>my-set-integration-request-policy</Name>
            </Step>
        </Request>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow"/>
    <HTTPProxyConnection>
        <BasePath>/integration-endpoint-test</BasePath>
        <Properties/>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <IntegrationEndpoint>my-int-endpoint</IntegrationEndpoint>
    </RouteRule>
</ProxyEndpoint>

In the sample ProxyEndpoint configuration, Apigee performs the following tasks:

1. In the PreFlow, executes the policy named my-set-integration-request-policy , which sets the integration request object and integration flow variables.
2. Uses my-int-endpoint as the target endpoint, as specified in the RouteRule .
3. Reads the integration request object created by the my-set-integration-request-policy .
4. Sends the request to Apigee's Integration Platform using the request object and flow variables set by the SetIntegrationRequest policy.
5. Saves the response of the integration in the response message.

The XML file containing the <IntegrationEndpoint> declaration will be available in the APIGEE_BUNDLE_DIRECTORY /apiproxy/integration-endpoints/ directory. If you create your API proxy using the Develop > API Proxies > CREATE NEW > Integration target option, Apigee stores the declaration in the /apiproxy/integration-endpoints/default.xml file. If you create the integration endpoint XML from the UI, you can provide a custom name for the XML file.

The following example shows the declaration of the <IntegrationEndpoint> element in the XML file:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>false</AsyncExecution>
</IntegrationEndpoint>

IntegrationEndpoint configuration elements

Synchronous vs Asynchronous execution

You can configure the integration to run in either synchronous or asynchronous mode. To understand the difference between synchronous and asynchronous execution modes, see <AsyncExecution> .

Use the <AsyncExecution> element within the </IntegrationEndpoint> to specify synchronous or asynchronous execution. If you set <AsyncExecution> to true , the integration runs asynchronously. And if you set it to false , the integration runs synchronously.

The following example sets the AsyncExecution to true :

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>true</AsyncExecution>
</IntegrationEndpoint>

Políticas

The /policies directory in an API proxy contains all policies available to be attached to Flows in the API proxy.

Policy configuration elements

Policy attachment

The following image shows the API proxy flows execution sequence:

Como se muestra arriba:

Policies are attached as processing steps to Flows . The policy's name is used to reference the policy to be enforced as a processing Step. The format of a policy attachment is the following:

<Step><Name>MyPolicy</Name></Step>

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Policy attachment configuration elements

Flujos

ProxyEndpoint and TargetEndpoint define a pipeline for request and response message processing. A processing pipeline consists of a request flow and a response flow. Each request flow and response flow is subdivided into a PreFlow, one or more optional conditional or named flows, and a PostFlow.

• PreFlow: Always executes. Executes before any conditional Flows.
• PostFlow: Always executes. Executes after any conditional Flows.

Additionally, you can add a PostClientFlow to the proxy endpoint, which executes after the response is returned to the requesting client app. Only the MessageLogging policy can be attached to this flow. PostClientFlow reduces API proxy latency and makes information available for logging that is not calculated until after the response is returned to the client, such as the client.sent.start.timestamp and client.sent.end.timestamp .The flow is used primarily for measuring the time interval between the start and end timestamps for the response message.

Here's an example of a PostClientFlow with a message logging policy attached.

...
  <PostFlow name="PostFlow">
      <Request/>
      <Response/>
  </PostFlow>
  <PostClientFlow>
      <Request/>
      <Response>
          <Step>
              <Name>Message-Logging-1</Name>
          </Step>
      </Response>
  </PostClientFlow>
  ...

The API proxy processing pipeline executes Flows in the following sequence:

Request Pipeline:

1. Proxy Request PreFlow
2. Proxy Request Conditional Flows (Optional)
3. Proxy Request PostFlow
4. Target Request PreFlow
5. Target Request Conditional Flows (Optional)
6. Target Request PostFlow

Response Pipeline:

1. Target Response PreFlow
2. Target Response Conditional Flows (Optional)
3. Target Response PostFlow
4. Proxy Response PreFlow
5. Proxy Response Conditional Flows (Optional)
6. Proxy Response PostFlow
7. PostClientFlow Response (Optional)

Only those Flows with policy attachments need to be configured in ProxyEndpoint or TargetEndpoint configurations. PreFlow and PostFlow need only be specified in a ProxyEndpoint or TargetEndpoint configuration when a policy needs to be enforced during PreFlow or PostFlow processing.

In contrast to conditional flows, the ordering of PreFlow and PostFlow elements is not important--the API proxy will always execute each at the appropriate point in the pipeline, regardless of where they appear in the Endpoint configuration.

Flujos condicionales

Proxy endpoints and target endpoints support an unlimited number of conditional flows (also known as named flows ).

The API proxy tests for the condition specified in the conditional flow and, if the condition is met, the processing steps in the conditional flow are executed by the API proxy. If the condition is not met, then the processing steps in the conditional flow are bypassed. Conditional flows are evaluated in the order defined in the API proxy and the first one whose condition is met is executed.

By defining conditional flows, you gain the ability to apply processing steps in an API proxy based on:

• URI de solicitud
• HTTP verb ( GET / PUT / POST / DELETE )
• Value of a query param, header, and form param
• Many other types of conditions

For example, the following conditional flow specifies that it is executed only when the request resource path is /accesstoken . Any inbound request with the path /accesstoken causes this flow to be executed, along with any policies that are attached to the flow. If the request path does not include the suffix /accesstoken , then the flow does not execute (although another conditional flow might).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

Flow configuration elements

Step processing

The sequential ordering of conditional Flows is enforced by Apigee. Conditional Flows execute from top to bottom. The first conditional Flow whose condition evaluates to true is executed, and only one conditional Flow is executed.

For example, in the following Flow configuration, any inbound request that does not include the path suffix /first or /second will cause the ThirdFlow to execute, enforcing the policy called Return404 .

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Recursos

"Resources" (resource files for use in API proxies) are scripts, code, and XSL transformations that can be attached to Flows using policies. These appear in the Scripts section of the API proxy editor in the Apigee UI.

See Managing resources for the supported resource types.

Resources can be stored in an API proxy, an environment, or an organization. In each case, a resource is referenced by name in a Policy. Apigee resolves the name by moving from the API proxy, to environment, to organization level.

A resource stored at the organization level can be referenced by Policies in any environment. A resource stored at the environment level can be referenced by Policies in that environment. A resource stored at the API proxy level can be referenced only by Policies in that API proxy.