Analizador independiente de proyectos PowerServer

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

Una aplicación de escritorio PowerBuilder capaz de descubrir servidores PowerServer locales, asociarlos con su proyecto generado, comprobar sus endpoints reales y presentar un diagnóstico ejecutivo sin integrarse ni modificar la aplicación analizada.

Demo analizado: Demo_PS_Session_Recovery · Implementación: Luis Avilan · PowerBuilder 2025 R2

Resumen ejecutivo

El laboratorio es una aplicación nativa de escritorio. No es una página de la aplicación PowerServer, no se ejecuta dentro del proyecto inspeccionado y no comparte su sesión. Su propósito es funcionar como una herramienta externa de inspección: observa los procesos y puertos del equipo, identifica soluciones generadas por PowerServer, consulta sus archivos de configuración y verifica por HTTP si la Web API y la aplicación publicada están disponibles.

El diseño no está acoplado a una aplicación específica. Puede analizar cualquier proyecto PowerServer local que conserve la estructura esperada y publique endpoints accesibles. Si existen varias instancias de ServerAPIs, el usuario puede seleccionar cuál analizar. La selección muestra el nombre del proyecto, URL, aplicación publicada, PID y puerto reales.

Qué problema resuelve

Durante el desarrollo de PowerServer es frecuente cerrar PowerBuilder, cerrar la aplicación cliente o perder de vista la consola donde se inició Kestrel. Sin embargo, ServerAPIs.exe puede continuar ejecutándose en segundo plano. También puede ocurrir lo contrario: la ruta del proyecto sigue existiendo y su configuración es válida, pero la API ya no está levantada.

Por esa razón el demo separa tres conceptos que no deben confundirse:

Arquitectura general

Objetos principales del demo

Función de descubrir_powerserver.ps1

descubrir_powerserver.ps1 sí se utiliza y es el componente encargado del descubrimiento automático. PowerBuilder no obtiene por sí solo toda la relación entre sockets TCP, procesos de Windows, líneas de comandos y rutas físicas de ServerAPIs. El script actúa como adaptador entre esa información del sistema operativo y nvo_descubridor_powerserver.

Cómo se ejecuta

nvo_descubridor_powerserver busca el script en el directorio actual, src y bin. Luego crea el nombre del archivo temporal y ejecuta PowerShell de manera oculta, esperando a que termine:

1powershell.exe -NoProfile -ExecutionPolicy Bypass
2  -File "descubrir_powerserver.ps1"
3  -ArchivoSalida "powerserver_detectados.tmp"
Copiar

El parámetro obligatorio ArchivoSalida indica dónde debe escribirse el inventario detectado. La ejecución no modifica el proyecto analizado ni inicia o detiene servidores.

Funciones internas del script

Datos que genera

Por cada aplicación publicada dentro de una instancia activa, el script escribe una línea con siete campos separados por tabuladores:

1Etiqueta | Ruta del proyecto | URL base | Aplicación | PID | Puerto | Código HTTP
Copiar

Las líneas se ordenan, se eliminan duplicados y se guardan en UTF-8 sin BOM. Si una misma instancia publica varias aplicaciones, se genera una opción independiente para cada una. Si /health-ui/ no responde correctamente, la instancia no se presenta como activa.

Entrega del resultado a PowerBuilder

Cuando PowerShell termina, nvo_descubridor_powerserver.of_cargar_resultados lee powerserver_detectados.tmp y distribuye sus siete campos en arreglos. La ventana usa esos arreglos para llenar el selector de instancias y conservar sincronizados el proyecto, la URL, la aplicación, el PID, el puerto y el estado HTTP.

Cómo descubre PowerServer

1. Enumera puertos en escucha

El script utiliza Get-NetTCPConnection -State Listen. Cada conexión entrega el puerto local y el PID propietario.

1$conexiones = Get-NetTCPConnection -State Listen |
2    Sort-Object OwningProcess, LocalPort -Unique
Copiar

2. Correlaciona el PID con el proceso

Para cada socket se consulta Win32_Process. La entrada solamente continúa si el nombre, ruta o línea de comandos contienen ServerAPIs. Esto evita tratar cualquier servidor HTTP local como PowerServer.

3. Resuelve la ruta del proyecto

Una expresión regular extrae la carpeta anterior a \ServerAPIs desde el ejecutable o la línea de comandos. Así se puede asociar el proceso ServerAPIs.exe con la ruta real del proyecto PowerServer que lo inició.

4. Obtiene las aplicaciones publicadas

El descubrimiento busca Applications.json tanto en ServerAPIs\AppConfig como en las carpetas compiladas de ServerAPIs\bin. Las claves bajo Applications se convierten en opciones seleccionables. Si una instancia publica varias aplicaciones, cada una aparece como una entrada independiente.

5. Exige una respuesta HTTP real

La instancia solamente se agrega a la lista de activos cuando /health-ui/ devuelve un código entre 200 y 399. Se prueban HTTP y HTTPS. El resultado tabulado se guarda en UTF-8 sin BOM para que PowerBuilder lo lea sin caracteres extraños.

Cómo PowerBuilder consume el descubrimiento

nvo_descubridor_powerserver ejecuta PowerShell de forma oculta mediante WScript.Shell. Después lee powerserver_detectados.tmp, separa cada línea y conserva arreglos paralelos con los valores reales.

1is_etiquetas[ii_cantidad] = of_obtener_campo(ls_linea, 1)
2is_rutas[ii_cantidad] = of_obtener_campo(ls_linea, 2)
3is_urls[ii_cantidad] = of_obtener_campo(ls_linea, 3)
4is_aplicaciones[ii_cantidad] = of_obtener_campo(ls_linea, 4)
5is_procesos[ii_cantidad] = of_obtener_campo(ls_linea, 5)
6is_puertos[ii_cantidad] = of_obtener_campo(ls_linea, 6)
7is_codigos[ii_cantidad] = of_obtener_campo(ls_linea, 7)
Copiar

La ventana usa esos valores para llenar el selector. Al analizar una opción, carga la ruta, URL y aplicación correspondientes, además de conservar PID y puerto para mostrarlos como evidencia.

Análisis de la configuración PowerServer

nvo_analizador_proyecto_powerserver combina validación física y lectura JSON. Después de localizar Applications.json, usa JSONParser para obtener:

• Nombre de la aplicación PowerServer.

• Timeout de sesión.

• Timeout de solicitud.

• Caché asociada a SQLCA.

• Perfil y caché de conexión.

• Tipo de base de datos.

• Base de datos, servidor y puerto.

• Opciones de seguridad disponibles en el JSON.

Los valores recuperados dependen de cada proyecto. El informe puede mostrar el tipo de base de datos, nombre de la base, servidor, puerto, caché de conexión, perfil y opciones de seguridad configuradas para la aplicación seleccionada.

Comprobaciones HTTP y prevención de estados obsoletos

Antes de cada petición se reinician el código y el estado. Si la llamada falla, el valor permanece en cero y el informe cambia inmediatamente a offline.

1il_codigo_http = 0
2is_estado_webapi = "OFFLINE"
3li_resultado = lnv_http.SendRequest("GET", is_url_webapi + "/health-ui/")
Copiar

La misma regla se aplica a la aplicación publicada. Esto impide que un HTTP 200 anterior permanezca visible después de detener Kestrel.

Aplicación de escritorio frente a aplicación PowerServer

El informe HTML ejecutivo

El reporte original en texto se conserva como evidencia técnica, pero se presenta dentro de un documento HTML generado por nvo_generador_informe_html_powerserver. La ventana lo carga con wb_reporte.NavigateToString(ls_html).

El documento contiene:

• Banda de salud general.

• Tarjetas para estructura, Web API y aplicación publicada.

• Códigos HTTP y endpoints probados.

• Recorrido proyecto → servidor → aplicación.

• PID y puerto del proceso real.

• Configuración completa en un panel desplazable.

• Fecha y hora de generación.

Los valores dinámicos se codifican antes de insertarse en HTML para evitar que rutas, mensajes o contenido de configuración alteren el documento.

Escenario completo con una aplicación PowerServer

Esta captura muestra la diferencia entre el cliente PowerServer y el servidor. La ventana Address consume la aplicación publicada, mientras ServerAPIs continúa como proceso separado. Cerrar solamente el cliente o PowerBuilder no garantiza que la API se detenga.

Paso a paso para probar el demo

Preparación

• Conservar juntos el ejecutable, analizador_powerserver.ini y descubrir_powerserver.ps1 dentro de bin.

• Verificar que PowerShell pueda ejecutar scripts locales.

• Tener disponible al menos un proyecto generado por PowerServer en el equipo.

Prueba 1: sin PowerServer activo

• Detener cualquier ServerAPIs.exe del proyecto que se utilizará.

• Ejecutar bin\demo_ps_session_recovery.exe.

• Comprobar que el selector indique que no se encontraron proyectos activos.

• Verificar que la estructura pueda aparecer como VALIDADO si la carpeta existe.

• Confirmar WEB API OFFLINE, APLICACIÓN NO DISPONIBLE, HTTP 0 y PID no detectado.

Prueba 2: levantar PowerServer

• Iniciar ServerAPIs desde PowerBuilder, Visual Studio, dotnet run o el ejecutable generado.

• Esperar el mensaje Now listening on de Kestrel.

• En el analizador, pulsar Buscar activos.

• Seleccionar la instancia deseada si existe más de una.

• Pulsar Analizar seleccionado.

• Confirmar proyecto, URL, aplicación, PID y puerto.

• Revisar que las tarjetas cambien a VALIDADO, ONLINE y PUBLICADA.

• Desplazarse dentro del WebBrowser para revisar la configuración detectada.

Prueba 3: detener la API durante la ejecución

• Anotar el PID mostrado por el analizador.

• Detener el proceso desde el Administrador de tareas, la consola con Ctrl+C o PowerShell:

1Stop-Process -Id <PID>
Copiar

• Pulsar Buscar activos.

• Pulsar Analizar seleccionado o Verificar servidor.

• Comprobar que el estado cambia a offline y los códigos HTTP vuelven a cero.

Prueba 4: varias instancias

• Levantar dos soluciones PowerServer en puertos diferentes.

• Pulsar Buscar activos.

• Verificar que el selector muestre una entrada por proyecto y aplicación.

• Elegir una opción y pulsar Analizar seleccionado.

• Cambiar de opción y repetir el análisis para comprobar que ruta, URL, PID y resultados cambian juntos.

Resultados esperados

Limitaciones actuales

• El descubrimiento automático está orientado a instancias locales de Windows.

• La correlación requiere que el proceso o su ruta identifiquen ServerAPIs.

• Los servidores remotos pueden analizarse manualmente por URL y ruta accesible, pero no se descubren por procesos locales.

• El health check confirma disponibilidad HTTP; no reemplaza pruebas funcionales de todas las APIs.

• La existencia de Applications.json no garantiza que credenciales, base de datos o permisos sean correctos.

• Las sesiones internas no se consultan sin una API administrativa autorizada.

Consideraciones para producción

• Firmar o controlar el script PowerShell distribuido con la aplicación.

• No desactivar la validación de certificados HTTPS en un ambiente productivo.

• Ocultar secretos y cadenas sensibles antes de presentar o exportar configuraciones.

• Aplicar timeouts breves para evitar bloquear la interfaz.

• Agregar autenticación si se incorporan endpoints administrativos.

• Registrar fecha, equipo, usuario, PID, puerto, URL y códigos HTTP de cada diagnóstico.

• Diferenciar claramente “proyecto válido”, “servidor activo” y “aplicación funcional”.

Conclusión

Este demo demuestra que una aplicación de escritorio PowerBuilder puede servir como consola de diagnóstico para proyectos PowerServer sin formar parte de ellos. La solución combina capacidades nativas de PowerBuilder, WebBrowser/WebView2, JSONParser, HTTPClient, procesos de Windows y PowerShell para construir una vista confiable del estado real de una instalación local.

Su principal valor está en evitar diagnósticos basados en suposiciones. La carpeta del proyecto, el proceso, el puerto, la Web API, la aplicación publicada y la configuración se verifican como evidencias separadas. El resultado es una herramienta reutilizable para desarrollo, soporte, pruebas de disponibilidad y análisis de múltiples soluciones PowerServer.