# Fijación de la sesión para las reglas ponderadas
Cuando utilizas reglas ponderadas para las A/B pruebas o los despliegues canarios, quieres que cada sesión reciba una experiencia uniforme en varias solicitudes. Sin la rigidez de la sesión, una sesión podría recibir diferentes paquetes de configuración o dirigirse a diferentes destinos en cada solicitud. El enrutamiento a un destino diferente implica un nuevo tiempo de ejecución del agente sin el contexto de las solicitudes anteriores, lo que perjudica la experiencia del usuario.
Para solucionar este problema, la puerta de enlace permite mantener la duración de las sesiones. Cuando incluye un identificador de sesión en sus solicitudes, la puerta de enlace almacena la decisión de enrutamiento de la primera solicitud y la reutiliza para todas las solicitudes posteriores de la misma sesión.
## Cómo funciona la persistencia de las sesiones
La puerta de enlace identifica una sesión extrayendo un ID de sesión de cada solicitud. El flujo de adherencia funciona de la siguiente manera:
1. En la primera solicitud con un ID de sesión, la puerta de enlace selecciona una variante en función de los pesos configurados y almacena la decisión.
1. Las solicitudes posteriores con el mismo ID de sesión reutilizan la decisión almacenada sin volver a evaluar las ponderaciones.
1. Las solicitudes sin un identificador de sesión se evalúan de forma independiente y sin problemas.
La forma en que la puerta de enlace determina el ID de sesión depende del tipo de destino:
+ **AgentCore Objetivos de tiempo de ejecución**: la puerta de enlace usa el `X-Amzn-Bedrock-AgentCore-Runtime-Session-Id` encabezado. El valor del encabezado debe tener un mínimo de 33 caracteres. No es necesario que envíes este encabezado en la primera solicitud. Si el encabezado está ausente, el tiempo de ejecución del agente genera automáticamente un ID de sesión y la puerta de enlace utiliza ese ID de sesión generado automáticamente para mantener el control en las solicitudes posteriores si lo incluye.
+ **Destinos de transferencia HTTP: de** forma predeterminada, la puerta de enlace usa el encabezado. `X-Amzn-Bedrock-AgentCore-Runtime-Session-Id` También puede configurar un identificador de sesión y un tiempo de espera personalizados en el destino, de modo que los clientes de acceso directo que utilizan su propio encabezado de sesión no tengan que adoptar el encabezado de sesión en tiempo de ejecución. Para obtener más información, consulte [Configurar la rigidez de la sesión para los destinos de acceso directo.](#gateway-rules-session-stickiness-passthrough)
## Configure la rigidez de la sesión para los destinos de transferencia
En el caso de los destinos de transferencia HTTP, puede establecer una opción `stickinessConfiguration` en la configuración de destino para controlar la forma en que la puerta de enlace identifica las sesiones y cuánto dura la afinidad entre las sesiones. Esto resulta útil cuando tus clientes ya envían su propio encabezado de sesión y no quieres pedirles que envíen también el encabezado de sesión estándar en tiempo de ejecución.
El `stickinessConfiguration` objeto contiene:
+ **identificador** (obligatorio): expresión que indica a la puerta de enlace dónde encontrar el identificador de sesión en la solicitud. Actualmente, la puerta de enlace solo puede resolver el ID de sesión desde el encabezado de una solicitud. Puede especificar el encabezado de cualquiera de estas formas:
+ Un nombre de encabezado HTTP simple, como`x-session-id`. La puerta de enlace lee el ID de sesión de ese encabezado de solicitud.
+ Una expresión de ruta de contexto del formulario`$.AMZN_AC_GW_CONTEXT.headers.{header-name}`, como`$.AMZN_AC_GW_CONTEXT.headers.x-session-id`.
En la actualidad, solo se admite la `headers` fuente. Otras fuentes (por ejemplo, una afirmación de JWT) no están disponibles actualmente.
+ **tiempo de espera** (opcional): el tiempo de espera de afinidad de sesión, en segundos, de 1 a 86400 (24 horas). Tras este período de inactividad, la afinidad de sesión caduca. La ventana se restablece en cada solicitud (ventana deslizante).
Cuando un objetivo tiene un`stickinessConfiguration`, la puerta de enlace resuelve el ID de sesión a partir del configurado`identifier`.
En el siguiente ejemplo, se crea un destino de acceso directo con un `stickinessConfiguration` que extrae el ID de sesión de un `x-session-id` encabezado personalizado y caduca la afinidad de sesión después de 8 horas (28800 segundos):
```
aws bedrock-agentcore-control create-gateway-target --cli-input-json '{
"gatewayIdentifier": "GATEWAY_ID",
"name": "my-passthrough-target",
"targetConfiguration": {
"http": {
"passthrough": {
"endpoint": "https://my-service.example.com",
"protocolType": "CUSTOM",
"stickinessConfiguration": {
"identifier": "$.AMZN_AC_GW_CONTEXT.headers.x-session-id",
"timeout": 28800
}
}
}
},
"credentialProviderConfigurations": [
{"credentialProviderType": "GATEWAY_IAM_ROLE"}
]
}'
```
Para obtener más información sobre los destinos de transferencia, consulte los destinos de transferencia [HTTP](gateway-target-http-passthrough.md).
## Comportamientos importantes
**Las decisiones almacenadas tienen prioridad sobre los cambios en las reglas.** Si actualiza una regla, las sesiones existentes continúan con la decisión original. Esto garantiza la coherencia de la sesión. Para aplicar nuevas reglas a una sesión, inicie una nueva sesión con un nuevo ID de sesión.
**Las sesiones caducan tras un período de inactividad.** La ventana de caducidad se restablece en cada solicitud (ventana deslizante). En el AgentCore caso de los objetivos en tiempo de ejecución, las sesiones caducan tras 15 días de inactividad. En el caso de los destinos de transferencia HTTP, el intervalo de caducidad es el `timeout` que tú estableces en el destino `stickinessConfiguration` (de 1 a 86400 segundos); si no estableces un tiempo de espera, se aplicará el valor predeterminado. Cuando caduque una sesión, utilice un nuevo identificador de sesión para las nuevas sesiones a fin de evitar un comportamiento de enrutamiento inesperado. Le recomendamos que no vuelva a utilizar los ID de sesión caducados.
**El estado de la sesión se determina por objetivo.** Los diferentes destinos mantienen un estado de sesión independiente.
**Compatible con destinos AgentCore de transferencia HTTP y Runtime.** Los destinos MCP no admiten la persistencia de la sesión.