Esta página se aplica a Apigee y Apigee Hybrid.
Información general
La política IntegrationCallout te permite ejecutar una integración de aplicaciones que tenga un activador de API. Sin embargo, antes de ejecutar una integración, debes ejecutar la política SetIntegrationRequest. La política SetIntegrationRequest crea un objeto de solicitud y lo pone a disposición de la política IntegrationCallout como variable de flujo. El objeto de solicitud tiene los detalles de la integración, como el nombre del activador de la API, el ID del proyecto de integración, el nombre de la integración y otros detalles configurados en la política SetIntegrationRequest. La política IntegrationCallout usa la variable de flujo del objeto de solicitud para ejecutar la integración. Puedes configurar la política IntegrationCallout para guardar la respuesta de la ejecución de la integración en una variable de flujo.
La política IntegrationCallout es útil si quieres ejecutar una integración en medio del flujo de tu proxy. También puedes ejecutar una integración especificando un endpoint de integración como endpoint de destino en lugar de configurar la política IntegrationCallout. Para obtener más información, consulta IntegrationEndpoint.
Esta política es una política extensible y su uso puede tener implicaciones en cuanto a costes o utilización, en función de tu licencia de Apigee. Para obtener información sobre los tipos de políticas y las implicaciones de uso, consulta Tipos de políticas.
<IntegrationCallout>
Especifica la política IntegrationCallout.
Valor predeterminado | N/A |
¿Es obligatorio? | Obligatorio |
Tipo | Tipo complejo |
Elemento principal | N/A |
Elementos secundarios |
<DisplayName> <AsyncExecution> <Request> <Response> |
En la siguiente tabla se ofrece una descripción general de los elementos secundarios de <IntegrationCallout>
:
Elemento secundario | ¿Es obligatorio? | Descripción |
---|---|---|
<DisplayName> |
Opcional | Un nombre personalizado para la política. |
<AsyncExecution> |
Opcional | Especifica si la integración debe ejecutarse en modo síncrono o asíncrono. |
<Request> |
Obligatorio | Variable de flujo que tiene el objeto de solicitud creado por la política SetIntegrationRequest. |
<Response> |
Opcional | La variable de flujo en la que se guardará la respuesta de la integración. |
El elemento <IntegrationCallout>
utiliza la siguiente sintaxis:
Sintaxis
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <IntegrationCallout continueOnError="[true|false]" enabled="[true|false]" name=POLICY_NAME> <DisplayName>POLICY_DISPLAY_NAME</DisplayName> <AsyncExecution>BOOLEAN_ASYNC_EXECUTION</AsyncExecution> <Request clearPayload="[true|false]">REQUEST_FLOW_VARIABLE_NAME</Request> <Response>RESPONSE_FLOW_VARIABLE_NAME</Response> </IntegrationCallout>
Ejemplo
En el siguiente ejemplo se muestra la definición de la política IntegrationCallout:
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <IntegrationCallout continueOnError="false" enabled="true" name="Integration-Callout"> <DisplayName>Integration-Callout-1</DisplayName> <AsyncExecution>true</AsyncExecution> <Request clearPayload="true">my_request_flow_var</Request> <Response>my_response_flow_var</Response> </IntegrationCallout>
Este elemento tiene los siguientes atributos, que son comunes a todas las políticas:
Atributo | Predeterminado | ¿Es obligatorio? | Descripción |
---|---|---|---|
name |
N/A | Obligatorio |
El nombre interno de la política. El valor del atributo Opcionalmente, usa el elemento |
continueOnError |
falso | Opcional | Asigna el valor false para devolver un error cuando falle una política. Este es el comportamiento esperado de la mayoría de las políticas. Asigna el valor true para que la ejecución del flujo continúe incluso después de que falle una política. Consulta también:
|
enabled |
true | Opcional | Asigna el valor true para aplicar la política. Selecciona false para desactivar la política. La política no se aplicará aunque siga adjunta a un flujo. |
async |
falso | Obsoleto | Este atributo está obsoleto. |
Referencia de elemento secundario
En esta sección se describen los elementos secundarios de<IntegrationCallout>
.
<DisplayName>
Se usa junto con el atributo name
para etiquetar la política en el editor de proxy de la interfaz de usuario de gestión con un nombre diferente que suene más natural.
El elemento <DisplayName>
es común a todas las políticas.
Valor predeterminado | N/A |
¿Es obligatorio? | Opcional. Si omite <DisplayName> , se usará el valor del atributo name de la política. |
Tipo | Cadena |
Elemento principal | <PolicyElement> |
Elementos secundarios | Ninguno |
El elemento <DisplayName>
utiliza la siguiente sintaxis:
Sintaxis
<PolicyElement> <DisplayName>POLICY_DISPLAY_NAME</DisplayName> ... </PolicyElement>
Ejemplo
<PolicyElement> <DisplayName>My Validation Policy</DisplayName> </PolicyElement>
El elemento <DisplayName>
no tiene atributos ni elementos secundarios.
<AsyncExecution>
Especifica el modo en el que se ejecutará la integración. Puedes ejecutar la integración de forma síncrona o asíncrona.
Si se define como true
, la integración se ejecuta de forma asíncrona. Si se define como false
, la integración se ejecuta de forma síncrona.
- Modo asíncrono: cuando la solicitud para ejecutar la integración llega al endpoint, este devuelve inmediatamente los IDs de ejecución de la integración, pero inicia la ejecución de la integración en el momento especificado por el elemento
<ScheduleTime>
. Si no has definido el elemento<ScheduleTime>
, la integración se programará para que se ejecute inmediatamente. Aunque la integración esté programada para ejecutarse inmediatamente, puede que tarde unos segundos en iniciarse. Cuando la integración empieza a ejecutarse, ocurren dos cosas:- La integración devuelve el código de estado HTTP
200 OK
para que la persona que llama pueda seguir procesando. - Se completa la política IntegrationCallout.
- La integración devuelve el código de estado HTTP
- Modo síncrono: cuando la solicitud para ejecutar la integración llega al endpoint, este inicia inmediatamente la ejecución de la integración y espera la respuesta. El límite de tiempo máximo para completar la ejecución es de 2 minutos. Una vez finalizada la ejecución, el endpoint devuelve una respuesta con los IDs de ejecución y otros datos de respuesta.
Valor predeterminado | falso |
¿Es obligatorio? | Opcional |
Tipo | Booleano |
Elemento principal |
<IntegrationCallout> |
Elementos secundarios | Ninguno |
El elemento <AsyncExecution>
utiliza la siguiente sintaxis:
Sintaxis
<AsyncExecution>BOOLEAN</AsyncExecution>
Ejemplo
En el siguiente ejemplo se asigna el valor true
a la ejecución asíncrona:
<AsyncExecution>true</AsyncExecution>
<Request>
Especifica la variable de flujo que tiene el objeto de solicitud creado por la política SetIntegrationRequest. La política IntegrationCallout envía este objeto de solicitud a Application Integration para ejecutar la integración.
Valor predeterminado | N/A |
¿Es obligatorio? | Obligatorio |
Tipo | Cadena |
Elemento principal |
<IntegrationCallout> |
Elementos secundarios | Ninguno |
El elemento <Request>
utiliza la siguiente sintaxis:
Sintaxis
<Request clearPayload="true">FLOW_VARIABLE_NAME</Request>
Ejemplo
En el siguiente ejemplo se especifica que el objeto de solicitud está disponible en la variable de flujo my_request_flow_var
:
<Request clearPayload="true">my_request_flow_var</Request>
En la siguiente tabla se describen los atributos de <Request>
:
Atributo | ¿Es obligatorio? | Tipo | Descripción |
---|---|---|---|
clearPayload |
Opcional | booleano | Especifica si el objeto de solicitud se debe borrar de la memoria después de enviar la solicitud para ejecutar la integración.
Si no especifica este atributo, el valor predeterminado es |
<Response>
Especifica la variable de flujo para guardar la respuesta de la integración.
Si no especificas este elemento, la política guardará la respuesta en la variable de flujo integration.response
.
Valor predeterminado | integration.response |
¿Es obligatorio? | Opcional |
Tipo | Cadena |
Elemento principal |
<IntegrationCallout> |
Elementos secundarios | Ninguno |
Se puede acceder al resultado de la integración mediante integration.response.content
o flow_variable.content
. El elemento <Response>
utiliza la siguiente sintaxis:
Sintaxis
<Response>FLOW_VARIABLE_NAME</Response>
Ejemplo
En el siguiente ejemplo se guarda la respuesta de la ejecución de la integración en la variable de flujo my_response_flow_var
:
<Response>my_response_flow_var</Response>
Códigos de error
En esta sección se describen los códigos de fallo, los mensajes de error y las variables de fallo que define Apigee cuando esta política activa un error. Esta información es esencial si vas a desarrollar reglas de errores para gestionarlos. Para obtener más información, consulta Qué debes saber sobre los errores de políticas y Cómo gestionar los fallos.
Errores de tiempo de ejecución
Estos errores pueden producirse cuando se ejecuta la política.
Código de fallo | Estado de HTTP | Causa |
---|---|---|
entities.UnresolvedVariable |
500 |
Este error se produce si Apigee no puede resolver las variables integration.project.id
o integration.name . |
steps.integrationcallout.ExecutionFailed |
500 |
Este error puede producirse si el servicio de destino del backend devuelve un estado de error HTTP, como
|
steps.integrationcallout.NullRequestVariable |
500 |
Este error se produce si la variable de flujo especificada en <Request> es nula. |
steps.integrationcallout.RequestVariableNotMessageType |
500 |
Este error se produce cuando la variable de flujo especificada por el elemento Request no es de tipo message. |
steps.integrationcallout.RequestVariableNotRequestMessageType |
500 |
Este error se produce cuando la variable de flujo especificada por el elemento Request no es del tipo Mensaje de solicitud. |
messaging.adaptors.http.filter.GoogleTokenGenerationFailure |
500 |
Este error puede deberse a una configuración incorrecta de la cuenta de servicio. Estas son algunas de las posibles causas:
|
Variables de error
Cuando se producen errores de ejecución en una política, Apigee genera mensajes de error. Puedes ver estos mensajes de error en la respuesta de error. En muchas ocasiones, los mensajes de error generados por el sistema pueden no ser relevantes en el contexto de su producto. Puede que quieras personalizar los mensajes de error en función del tipo de error para que sean más significativos.
Para personalizar los mensajes de error, puedes usar reglas de error o la política RaiseFault. Para obtener información sobre las diferencias entre las reglas de errores y la política RaiseFault, consulta Reglas de errores frente a la política RaiseFault.
Debes comprobar las condiciones mediante el elemento Condition
tanto en las reglas de errores como en la política RaiseFault.
Apigee proporciona variables de error únicas para cada política. Los valores de las variables de error se definen cuando una política activa errores de tiempo de ejecución.
Al usar estas variables, puede comprobar si se dan condiciones de error específicas y tomar las medidas oportunas. Para obtener más información sobre cómo comprobar las condiciones de error, consulta Crear condiciones.
En la siguiente tabla se describen las variables de error específicas de esta política.
Variables | Dónde | Ejemplo |
---|---|---|
fault.name |
El fault.name puede coincidir con cualquiera de los errores que se indican en la tabla Errores de tiempo de ejecución.
El nombre del error es la última parte del código de error. |
fault.name Matches "UnresolvedVariable" |
IntegrationCallout.POLICY_NAME.failed |
POLICY_NAME es el nombre de la política especificado por el usuario que ha provocado el error. | IntegrationCallout.integration-callout-1.failed = true |
Temas relacionados
Si quieres obtener más información sobre la función Integración de aplicaciones, consulta el artículo sobre la integración de aplicaciones.