Exploración visual de logs SQL, transacciones y sesiones de…

Este artículo desarrolla la arquitectura y el flujo interno de una consola PowerBuilder capaz de descubrir instancias PowerServer activas, localizar su archivo de log efectivo y convertir trazas multilínea en una vista operativa con filtros, métricas, detalle y seguimiento en vivo.

El problema: el log existe, pero no es una consola

PowerServer registra llamadas a controladores, creación y destrucción de sesiones, ciclos de transacción, sentencias SQL, resultados y excepciones. La información es real y valiosa, pero llega como texto cronológico con bloques JSON de varias líneas. Una única operación puede ocupar decenas de líneas y compartir identificadores con operaciones posteriores.

Buscar manualmente en powerserver.log obliga a resolver varias preguntas a la vez: ¿qué proceso corresponde al proyecto?, ¿en qué puerto escucha?, ¿qué archivo configuró realmente log4net?, ¿dónde empieza y termina el evento?, ¿qué sesión y transacción participaron?, ¿es un error real o un resumen duplicado?

Resultado real del demo: 39 eventos procesados, incluidos SQL, transacciones, sesiones y errores. La cuadrícula conserva el mensaje completo en el panel inferior.

Arquitectura del demo

La ventana se mantiene deliberadamente delgada. El descubrimiento, la lectura incremental, el análisis y la administración de la DataWindow viven en objetos no visuales separados.

Descubrimiento de una instancia real

descubrir_logs_powerserver.ps1 no mantiene un catálogo de proyectos de prueba. Consulta procesos activos mediante CIM, identifica el puerto TCP en escucha y deriva el directorio publicado desde la línea de comandos. Después inspecciona dos fuentes de configuración:

• AppConfig/Applications.json, para obtener la aplicación PowerServer publicada.

• Logging/log4net.xml, para resolver la ruta efectiva del RollingFileAppender.

El resultado se serializa como TSV UTF-8. Esta decisión evita una dependencia adicional para intercambiar una lista pequeña entre PowerShell y PowerBuilder, y preserva acentos y caracteres especiales.

1Aplicación | URL local | PID | directorio publicado | archivo de log
2salesdemo_cloud | http://localhost:16561 | 20784 | ...\ServerAPIs | ...\Logging\logs\powerserver.log

La etiqueta visual agrega LOG DISPONIBLE solamente cuando el archivo resuelto existe. Por eso seleccionar un proceso no equivale automáticamente a tener eventos: el diagnóstico muestra la ruta y explica si falta configuración o archivo.

Configuración que hace visibles SQL, sesiones y transacciones

En la instancia examinada, Logging.Development.json habilita EnableFileServer, EnableSqlLog, EnableSessionLog y EnableTransactionLog. Además, el nivel de PowerServer está en Debug. Log4net escribe en UTF-8, añade al archivo existente, utiliza bloqueo mínimo y rota al alcanzar 5 MB, conservando hasta 100 respaldos.

1"PowerServer": "Debug"
2"EnableSqlLog": true
3"EnableSessionLog": true
4"EnableTransactionLog": true

Lectura incremental UTF-8

El lector mantiene il_posicion. En la primera carga puede comenzar desde cero; en seguimientos posteriores obtiene el contenido y devuelve el segmento que empieza en la posición almacenada. Si el archivo disminuye —por truncado o reemplazo— reinicia la posición para no quedar fuera de rango.

1ls_contenido = of_leer_archivo_utf8(is_ruta_archivo)
2If Len(ls_contenido) < il_posicion Then il_posicion = 0
3ls_novedades = Mid(ls_contenido, il_posicion + 1)
4il_posicion = Len(ls_contenido)

La lectura binaria y la conversión EncodingUTF8! evitan depender de la página de códigos de Windows. El análisis acepta saltos CRLF y LF; esto es importante porque un retorno de carro residual puede impedir que una línea aparentemente vacía se reconozca como vacía.

De texto multilínea a eventos estructurados

Una expresión de inicio basada en la marca de tiempo separa eventos consecutivos. Las líneas JSON siguientes permanecen asociadas a la cabecera hasta detectar la siguiente fecha. Así, un resultado como RetrieveWithParm no se fragmenta en filas inconexas.

nvo_analizador_logs_ps crea una estructura str_evento_log_ps con fecha, nivel, categoría, sesión, operación, duración, mensaje y bloque original. El bloque original se conserva porque la cuadrícula resume, pero el panel de detalle debe permitir una investigación completa.

Cabecera

Entrega fecha, nivel y método del controlador. El método real tiene prioridad sobre etiquetas genéricas del cuerpo.

Cuerpo JSON

Aporta SessionId, TransactionId, ErrorCode, duración, SQL y mensaje funcional.

Clasificación

Evalúa primero errores; luego SQL, transacción, sesión, advertencia y finalmente general.

Deduplicación

Descarta resúmenes genéricos de sesión cuando ya existe el evento operacional que contiene el mismo fallo.

Por qué “todo es error” era una interpretación incorrecta

Una traza inicial mostraba repetidamente “La sesión no responde (La sesión no existe)”. El primer analizador trataba cada bloque de error y su resumen como eventos equivalentes, y podía usar el texto del resultado como si fuera la operación principal. La corrección separó tres conceptos:

• Nivel: procede de la cabecera y expresa la severidad emitida.

• Categoría: deriva del contenido; por ejemplo, un fallo dentro de CommitAndCreateTransaction sigue perteneciendo al dominio transaccional.

• Operación: se toma del método real del controlador, no del mensaje genérico posterior.

De este modo una fila puede ser nivel ERROR, categoría TRANSACCIÓN y operación CommitAndCreateTransaction. No se oculta el fallo, pero tampoco se pierde el contexto técnico.

Correlación de una operación real

La validación se realizó contra actividad generada por la aplicación Sales CRM en ejecución. El log registró un RetrieveWithParm sobre d_address_free, con parámetro al_addressid=466, seguido por un SELECT sobre Person.Address. El resultado informó una fila afectada y ErrorCode = 0.

En el mismo flujo aparecieron un CommitAndCreateTransaction exitoso, Disconnect y DestroySession. La sesión 34268BB0-0E21-451B-8788-4A602AC94E73 y la transacción 3CFBC7DD-3AC4-4B41-ACFE-663E35D4C4F0-8 permiten seguir el recorrido sin depender únicamente de la proximidad temporal.

DataWindow, métricas y seguimiento en vivo

nvo_gestor_logs_ps inserta cada evento normalizado en d_eventos_logs_ps. A partir del mismo conjunto calcula total, SQL, transacciones, sesiones, errores y operaciones lentas. Los filtros por texto y categoría operan sobre los datos ya cargados, sin reanalizar el archivo.

El evento Timer de la ventana ejecuta una actualización cada dos segundos cuando el seguimiento está activo. “Pausar seguimiento” detiene la incorporación visual, no altera el log de PowerServer. Al reanudar, el lector procesa el tramo pendiente desde su posición conocida. El detalle inferior muestra el bloque original y la exportación CSV produce una copia interoperable para análisis externo.

Procedimiento de prueba reproducible

• Iniciar un proyecto PowerServer local y confirmar que su Server APIs escucha en un puerto.

• Habilitar las categorías requeridas y el archivo log en su configuración efectiva.

• Abrir el explorador y pulsar Descubrir; seleccionar la instancia marcada como disponible.

• Ejecutar en la aplicación una consulta, una actualización guardada y una navegación que cree o cierre sesión.

• Comprobar el SQL, el método, los identificadores y el código de error en el detalle completo.

• Pausar, generar nueva actividad y reanudar para validar la lectura incremental.

• Rotar o truncar el archivo de manera controlada y verificar el reinicio de posición antes de usar el patrón en producción.

Validación de compilación

La importación final por ORCA reportó OK para los nueve artefactos del demo: las dos estructuras, la DataWindow, los cuatro NVO, la ventana y la aplicación. Esta validación confirma sintaxis y dependencias PowerBuilder; la captura y el recorrido sobre el log activo aportan la prueba de comportamiento, que es distinta de compilar correctamente.

Límites y próximas extensiones

• El descubrimiento actual está orientado a procesos locales; hosts remotos requerirían un agente o una API segura.

• Se procesa el archivo activo. Los respaldos numerados de log4net todavía no forman una línea histórica única.

• La duración depende de que el evento la publique; no se calcula artificialmente entre líneas no relacionadas.

• Los formatos futuros del proveedor pueden exigir adaptar la detección de cabecera o los nombres JSON.

• La consola es una herramienta de diagnóstico, no reemplaza una plataforma centralizada de observabilidad, alertas o retención.

Las extensiones naturales son lectura real por desplazamiento, seguimiento de archivos rotados, agregación por sesión, percentiles de duración, reglas de alerta y conexión remota autenticada. La separación actual entre descubridor, lector, analizador y gestor permite incorporarlas sin convertir la ventana en un script monolítico.

Conclusión

El valor del demo no está en colorear texto, sino en reconstruir el contexto operacional de PowerServer: proceso, aplicación, método, sesión, transacción, SQL, resultado y error. La consola mantiene trazabilidad hasta el bloque original, expone sus límites y trabaja exclusivamente con actividad emitida por proyectos activos. Ese enfoque la convierte en una base práctica para diagnosticar aplicaciones PowerBuilder modernas sin depender de datos simulados.