Configuración de timeout en una entrada binding de un WS

Para calcular el timeout de una transacción de Engage en base a los timeouts del binding de un web service, lo que hay que hacer es sumar todos los timeouts del binding (open, send, receive y close). El valor resultante es el máximo tiempo posible de espera.

Ahora, si bien es lógico hacer esto, no es recomendable cuando el timeout calculado supera ciertos valores razonables para el proceso Engage. Por ejemplo, si sumo todos los valores y me da 15 minutos de timeout, esto es impracticable en un proceso Engage, porque antes que de timeout la transacción, va a dar timeout la comunicación vía WCF entre el Agente Web y el servicio de Kernel, y ni hablar que quedarán recursos retenidos por ese lapso, incluyendo la conexión al IIS.

Es decir, el timeout de una transacción también se tiene que condecir con la suma de los timeouts del binding del servicio de Kernel (tanto en el web.config del Agente Web como en el archivo .config del servicio de Kernel).

Los timeouts se deben calcular, de mayor a menor, en el siguiente orden:

Timeout de sesión IIS->Timeout de binding EKS (.config de Kernel y .config del Agente Web) ->Timeout transacción Engage->Timeout binding con web service en EIS

Según lo anterior, los timeouts de más a la derecha no deberían ser mayores que los de la izquierda.

Muchas veces es preferible pensar las cosas desde el punto de vista del usuario y del proceso de negocio. Por ejemplo, cual es el máximo tiempo que puedo dejarlo esperando al usuario? Independientemente de lo que tarde el web service. Acá es donde hay que empezar a considerar la necesidad de hacer que la transacción sea “pseudo-asincrónica”, y armar una pantalla de refresh para que el usuario sepa cuando terminó el web service, en lugar de tenerlo esperando (con todos los recursos retenidos).