Administración de sesiones activas en varios proyectos…

Artículo técnico · PowerBuilder y PowerServer 2025 R2

Este demo convierte una aplicación PowerBuilder de escritorio en una consola operativa para consultar, clasificar, auditar y finalizar sesiones mediante las PowerServer Management APIs. El operador puede registrar varios proyectos, seleccionar la instancia que desea observar y mantener cada intervención asociada al servidor correcto.

Demo: Demo_PS_Active_Sesion_Manager · Implementación: Luis Avilan · PowerBuilder 2025 R2

El problema operativo

Una solución PowerServer puede mantener sesiones abiertas aun cuando el usuario dejó de interactuar con la aplicación. En desarrollo, soporte o administración es necesario saber cuántas sesiones existen, cuándo comenzaron, cuánto tiempo llevan sin actividad y cuál debe finalizarse. Cuando hay varios proyectos o ambientes, consultar una única URL fija tampoco es suficiente.

El demo resuelve ese escenario con una consola desacoplada de las aplicaciones administradas. No comparte la sesión del cliente PowerServer ni consulta directamente su base de datos. Toda la comunicación se realiza contra la Management API de la instancia seleccionada.

Vista principal: proyecto seleccionado, API disponible, métricas, sesiones visibles, línea de eventos y controles administrativos.

Qué significa detectar un proyecto PowerServer activo

En esta versión, detectar no significa recorrer automáticamente todos los procesos o carpetas del equipo. La aplicación mantiene un catálogo de proyectos configurados y comprueba el proyecto seleccionado mediante una solicitud real a /api/Session/GetSessionCount. Si el servidor responde con HTTP 2xx, el proyecto se considera administrable y la consola continúa con LoadAll.

Este enfoque permite administrar instancias locales o remotas siempre que su URL sea accesible. La selección evita mezclar sesiones: antes de cambiar de proyecto, la ventana pausa el refresco, limpia DataWindows e indicadores, cambia la URL y la autorización del cliente HTTP, prueba la nueva API y solo entonces carga los datos.

Arquitectura del demo

Catálogo y selección de proyectos

n_cst_ps_server_manager utiliza arreglos paralelos para nombre, ambiente, URL y token. of_agregar_proyecto evita duplicados por URL; of_actualizar_proyecto modifica una entrada; y of_seleccionar_proyecto desconecta el contexto anterior y configura el cliente HTTP con los datos de la nueva instancia.

La descripción visible combina los tres datos que el operador necesita para no equivocarse:

1Nombre del proyecto | Ambiente | URL base

La ventana de configuración acepta un token Bearer opcional. Si se escribe un token sin el prefijo, el administrador agrega automáticamente Bearer antes de crear el header Authorization.

Registro o edición de un proyecto PowerServer. La advertencia explica por qué 403 y 405 suelen indicar que la Management API no está habilitada.

Comunicación con las Management APIs

El cliente construye todas las rutas a partir de la URL base y el prefijo /api/Session. Cada solicitud establece Accept: application/json, contenido UTF-8, timeout y, cuando corresponde, autorización Bearer.

La respuesta se encapsula en str_ps_api_result: operación, endpoint, éxito, HTTP, cuerpo, mensaje de error, detalle técnico y duración. La ventana utiliza la misma estructura tanto para cambiar el estado visual como para registrar auditoría.

Habilitación del servidor

La solución PowerServer que se desea administrar debe incluir el middleware de Management API en UserStartup.cs:

1app.UsePowerServerManagementAPI();

Del JSON al DataWindow

n_cst_ps_session_admin.of_cargar_todas_sesiones obtiene LoadAll y entrega el cuerpo a JSONParser. PowerServer 2025 R2 devuelve nombres como sessionid, application, sessionstate, ipaddress, serveripaddress, createtime y lastvisittime. El parser asigna esos valores a un arreglo de str_ps_active_session.

Después, of_actualizar_sesiones reinicia el DataWindow e inserta una fila por elemento. El identificador completo se conserva para operaciones administrativas, mientras que una versión abreviada mejora la lectura visual.

1istr_sesiones[i].session_id = lnv_json.GetItemString(ll_item, "sessionid")
2istr_sesiones[i].application_name = lnv_json.GetItemString(ll_item, "application")
3istr_sesiones[i].start_datetime = ldt_start
4istr_sesiones[i].last_activity_datetime = ldt_last

Clasificación y métricas

La API entrega estado y tiempos, pero la consola calcula una clasificación operativa propia. Los umbrales proceden de n_cst_ps_session_config y se aplican en este orden:

• NUEVA: duración inferior al umbral inicial.

• PROLONGADA: duración superior al límite de horas.

• CRÍTICA: inactividad superior al umbral crítico.

• INACTIVA: inactividad superior al umbral preventivo.

• ACTIVA: cualquier otra sesión con actividad normal.

La ventana recorre el DataWindow para actualizar sesiones visibles, activas o nuevas, inactivas y las que requieren atención. También crea una fila consolidada en d_ps_session_summary con latencia, última actualización y estado del servidor.

Refresco automático sin solicitudes superpuestas

n_cst_ps_refresh_manager administra el intervalo y dispara un evento de actualización en la ventana. La bandera ib_cargando evita que una actualización manual y otra automática modifiquen simultáneamente el DataWindow. Durante la carga se deshabilitan los botones sensibles; al terminar se actualizan indicadores, estado, auditoría y línea de eventos.

Cuando el usuario cambia de proyecto, el refresco se pausa, los datos del proyecto anterior se limpian y la cuenta regresiva se reanuda únicamente después de completar la nueva conexión. Esto evita mostrar sesiones de una instancia bajo el nombre de otra.

Finalización controlada de una sesión

La operación destructiva no se ejecuta directamente desde la fila. La ventana exige una sesión seleccionada, abre w_ps_kill_confirmation y solicita un motivo. Solo después llama a POST KillById/{sessionId}.

Confirmación previa: el motivo forma parte del registro de auditoría de la finalización.

Si la sesión todavía pertenece a una aplicación cliente en ejecución, el siguiente acceso del cliente falla porque el servidor ya no reconoce ese contexto. La captura siguiente es la evidencia funcional de que la finalización no fue solamente un cambio visual en el administrador.

Consecuencia en el cliente: PowerServer informa que la sesión no existe y solicita reiniciar la aplicación.

Auditoría y trazabilidad

Cada consulta y finalización genera una fila en el DataStore interno de n_cst_ps_session_audit_service. El registro incluye fecha, administrador, operación, Session ID, servidor, ambiente, motivo, HTTP, resultado, error y tiempo de respuesta. La línea de eventos resume el mismo recorrido en orden cronológico.

Esta separación es deliberada: el logger facilita el seguimiento inmediato, mientras el DataStore conserva campos estructurados para una vista administrativa y futuras opciones de exportación o persistencia.

Prueba completa del demo

• En la solución PowerServer, habilitar app.UsePowerServerManagementAPI(), recompilar e iniciar ServerAPIs.

• Iniciar una aplicación cliente PowerServer para crear al menos una sesión.

• Ejecutar Demo_PS_Active_Sesion_Manager.

• Agregar o editar el proyecto con nombre, ambiente, URL y token cuando aplique.

• Seleccionar el proyecto y confirmar API EN LÍNEA.

• Verificar que el conteo de GetSessionCount coincida con las filas de LoadAll.

• Probar actualización manual y automática.

• Revisar resumen técnico y auditoría.

• Seleccionar una sesión, pulsar Finalizar, escribir un motivo y confirmar.

• Comprobar que la sesión desaparezca de la consola y que el cliente reciba el error de sesión inexistente.

Tratamiento de errores

Consideraciones para producción

• Publicar la Management API únicamente en redes administrativas controladas.

• Utilizar HTTPS y tokens de corta duración o un proveedor de identidad.

• Validar permisos por operación; los permisos para consultar sesiones y finalizarlas no deberían requerir necesariamente el mismo rol.

• Persistir la auditoría fuera de memoria si se necesita trazabilidad regulatoria.

• No registrar tokens ni secretos en mensajes, archivos o capturas.

• Convertir correctamente timestamps UTC a la zona horaria del operador.

• Definir umbrales diferentes por ambiente y proyecto.

• Proteger KillById contra errores de selección y finalizaciones masivas accidentales.

Conclusión

El valor del demo no se limita a listar Session IDs. La solución establece un contexto administrativo por proyecto, verifica que la API seleccionada esté realmente disponible, convierte JSON en estructuras y DataWindows, aplica criterios operativos, evita refrescos concurrentes y registra cada intervención.

El patrón puede ampliarse hacia una consola corporativa con descubrimiento automático, persistencia de catálogos, autenticación centralizada, auditoría durable y monitoreo de múltiples servidores. La base ya separa correctamente interfaz, transporte HTTP, administración de proyectos, lógica de sesiones, clasificación y trazabilidad.