Utilice la primitiva de mediación Invocación de servicio para llamar a un servicio desde dentro de un flujo de mediación, como alternativa a utilizar el mecanismo de llamada de salida al final del flujo de mediación.
Cuanto utilice la primitiva de mediación Invocación de servicio dentro de un flujo de mediación, el mensaje de entrada se utiliza para llamar el servicio. Si la llamada es correcta, la respuesta, o una sección de la respuesta identificada por una o más expresiones XPath, se utiliza para crear el mensaje de salida. Si la llamada no es satisfactoria, puede reintentar el mismo servicio o llamar a otro servicio.
Puede tener varias primitivas de mediación Invocación de servicio dentro de un flujo de mediación. Por lo tanto, puede tener una serie de llamadas de servicio. Puede utilizar la primitiva de mediación Invocación de servicio en un flujo de mediación de solicitud o respuesta.
En general, el servicio inicial al que llama la primitiva de mediación Invocación de servicio lo define la operación de referencia, que es una combinación de la propiedad Nombre de referencia y la propiedad Nombre de operación. Para una primitiva de mediación Invocación de servicio en un subflujo, la referencia se define en el subflujo y se resuelve en una referencia en el flujo padre cuando se crea una instancia del subflujo.
La primitiva de mediación Invocación de servicio tiene un terminal de entrada (in) y varios terminales de salida. Hay un terminal de error (fail) para errores sin modelar y un terminal de salida para cada error modelado. Los errores modelados son aquellos que se listan de forma explícita en un archivo WSDL; cualquier otro error es un error sin modelar. Además, existe un terminal de salida (out), que se utiliza para las llamadas de servicio correctas, que se correlaciona con el mensaje de respuesta for y un terminal de tiempo de espera (timeout), que se utiliza para algunos tipos de llamadas asíncronas. Los terminales de salida que se crean con un motivo especial se clasifican como terminales dinámicos. Por ejemplo, un error definido por WSDL hace que se cree un terminal de salida dinámico.
En la modalidad por omisión, el mensaje de entrada, que se recibe en el terminal in, se pasa directamente al servicio, y el mensaje de respuesta de la invocación de servicio se pasa directamente al terminal out. Las secciones del cuerpo y la cabecera del mensaje de respuesta se propagan al mensaje de salida.
En la figura siguente se muestra el flujo de mensajes en la modalidad por omisión para una operación de dos sentidos.

En la tabla siguiente se resume la operación de los terminales de la primitiva de mediación en la modalidad por omisión.
| Tipo de terminal | Nombre de terminal | ¿Terminal dinámico? | Tipo de mensaje | Descripción de terminal |
|---|---|---|---|---|
| Entrada | in | No | Tipo de mensaje WSDL para el mensaje de solicitud de la operación. | Recibe el mensaje de entrada. El mensaje (SMO) recibido en el terminal de entrada se utiliza para llamar al servicio. Las llamadas de servicio las definen operaciones especificadas en WSDL. Por ejemplo, puede tener una operación llamada getCustomerDetails que llame a un servicio de información de cliente. |
| Salida | out | Sí. WebSphere Integration Developer define uno para el mensaje de respuesta en la interfaz. | Tipo de mensaje WSDL para el mensaje de respuesta de la operación. | Propaga el mensaje actualizado. El resultado de la llamada de servicio se utiliza para crear un nuevo mensaje (SMO) que se envía a este terminal. Se utiliza cuando la llamada de servicio es satisfactoria. Este terminal no existe si la operación es unidireccional. |
| Salida | El valor por omisión es el nombre de error modelado. | Sí. WebSphere Integration Developer define uno para cada error modelado en la interfaz. | Tipo de mensaje WSDL para el mensaje de error de la operación. | Propaga el mensaje de respuesta de error. No se pone información en el elemento failInfo. Se utiliza cuando se devuelve el error modelado relevante desde la llamada de servicio. |
| Salida | timeout | No | Tipo de mensaje WSDL para el mensaje de solicitud de la operación. (Igual que el terminal de entrada.) | Propaga el mensaje original junto con la información de excepción de tiempo de espera excedido. La información de excepción de tiempo de espera excedido se almacena en el elemento failInfo. Se utiliza cuando una llamada de servicio asíncrono falla debido a un tiempo de espera excedido. El terminal timeout no se utiliza para llamadas asíncronas con devolución de llamada, sólo se utiliza para llamadas que son asíncronas con una respuesta diferida. Este terminal no existe si la operación es unidireccional. |
| Error | fail | No | Tipo de mensaje WSDL para el mensaje de solicitud de la operación. (Igual que el terminal de entrada.) | Propaga el mensaje original junto con cualquier información de excepción. La información de excepción se almacena en el elemento failInfo. Se utiliza cuando se devuelve un error sin modelar desde la llamada de servicio. |
En la modalidad Message Enrichment, una sección del mensaje de entrada que se recibe en el terminal in de la primitiva de mediacion de Invocación de servicio se utiliza para la invocación de servicio. El mensaje de salida que pasa por el terminal out se forma fusionando la respuesta del servicio con el mensaje de solicitud original que se pasó a la primitiva de mediación.
El tipo de mensaje de los terminales in y out debe coincidir, pero el tipo no se configura inicialmente. Cuando el terminal in está conectado, su tipo de mensaje se define implícitamente mediante el mensaje de entrada, y este tipo de mensaje se propaga a los terminales out.
En la figura siguiente se muestra cómo se enriquece en mensaje a medida que fluye por la primitiva de mediación en una operación de dos sentidos.

En la tabla siguiente se resume la operación de los terminales de la primitiva de mediación en la modalidad Message Enrichment.
| Tipo de terminal | Nombre de terminal | ¿Terminal dinámico? | Tipo de mensaje | Descripción de terminal |
|---|---|---|---|---|
| Entrada | in | No | Sin definir hasta que la propagación de conexión hace que se defina el tipo de mensaje. | Recibe el mensaje de entrada. Se utilizan una o más expresiones XPath para extraer una sección del SMO de entrada para utilizarla como mensaje de solicitud. |
| Salida | out | Sí. WebSphere Integration Developer define uno para el mensaje de respuesta en la interfaz. | Sin definir hasta que la propagación de conexión hace que se defina el tipo de mensaje. | Completa el mensaje de salida fusionando la respuesta del servicio con el mensaje de solicitud original que se pasó a la primitiva de mediación. Este terminal no existe si la operación es unidireccional. |
| Salida | El valor por omisión es el nombre de error modelado. | Sí. WebSphere Integration Developer define uno para cada error modelado en la interfaz. | Sin definir hasta que la propagación de conexión hace que se defina el tipo de mensaje. | Completa el mensaje de error fusionando la respuesta del servicio con el mensaje de solicitud original que se pasó a la primitiva de mediación. No se pone información en el elemento failInfo. Se utiliza cuando se devuelve el error modelado relevante desde la llamada de servicio. |
| Salida | timeout | No | Sin definir hasta que la propagación de conexión hace que se defina el tipo de mensaje. | Propaga el mensaje original junto con la información de excepción de tiempo de espera excedido. La información de excepción de tiempo de espera excedido se almacena en el elemento failInfo. Se utiliza cuando una llamada de servicio asíncrono falla debido a un tiempo de espera excedido. El terminal timeout no se utiliza para llamadas asíncronas con devolución de llamada, sólo se utiliza para llamadas que son asíncronas con una respuesta diferida. Este terminal no existe si la operación es unidireccional. |
| Error | fail | No | Sin definir hasta que la propagación de conexión hace que se defina el tipo de mensaje. | Propaga el mensaje original junto con cualquier información de excepción. La información de excepción se almacena en el elemento failInfo. Se utiliza cuando se devuelve un error sin modelar desde la llamada de servicio. |