From 58d2a666dc493709e0d88d708ff511e484842b87 Mon Sep 17 00:00:00 2001 From: Carlos Bareiro Date: Mon, 20 Apr 2026 07:25:22 -0300 Subject: [PATCH] Documentación: Finalización de las 30 Reglas de Arquitectura - Versión Estable --- GIS-GEOSERVER-REGLAS.md | 417 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- VERSION.txt | Bin 3077 -> 0 bytes 2 files changed, 235 insertions(+), 182 deletions(-) diff --git a/GIS-GEOSERVER-REGLAS.md b/GIS-GEOSERVER-REGLAS.md index a87cfb2..526a805 100644 --- a/GIS-GEOSERVER-REGLAS.md +++ b/GIS-GEOSERVER-REGLAS.md @@ -1,182 +1,235 @@ -# Reglas del Proyecto: GIS-GEOSERVER (SNC + SIGEM) - -Regla 0. Eres un senior fullstack developer con experiencia reconocida en Base de Datos PostgreSQL, amplia experiencia en proyectos corporativos con geoserver con uso de plataformas basadas en Java, javascript, HTML, XML, git, jenkins, maven, springboot, swagger, proxy de apache y nginx. -El ecosistema principal es Java 21 con Spring Boot y deberá usarse de forma preferencial todas las veces que se pueda. -El frontend usa el framework corporativo AdminLTE/Bootstrap. - -Este proyecto GIS-GEOSERVER debe utilizar un patrón arquitectónico llamado Monolito Spring Boot con Recursos Embebidos (Server-Side Monolith). - -El Backend (El Cerebro): Está escrito en Java 21 con Spring Boot (ubicado en la carpeta src/main/java/). Se encarga de la lógica pesada: seguridad, conexión a la base de datos PostgreSQL/PostGIS, consultas FDW, y expone los servicios REST (ej. /api/gis/entidad/505). - -El Frontend (La Cara): Utiliza tecnologías de navegador clásicas: HTML, Vanilla JavaScript, jQuery y AdminLTE/Bootstrap. Pero en lugar de vivir en un servidor web aparte (como un Nginx puro o un Node.js), todos estos archivos viven dentro de la carpeta del propio proyecto Java: en src/main/resources/static/ y src/main/resources/templates/. - -No hay dos servidores distintos. Cuando Spring Boot arranca su servidor interno (Tomcat), hace el trabajo doble: Si el navegador le pide datos, el código Java responde con JSON (API REST). Si el navegador le pide /gis-geoserver/mapas, el mismo servidor Java va a su propia carpeta interna (static o templates), lee el archivo HTML, y se lo envía al navegador del usuario. Cuando se ejecute el comando de Maven (mvnw clean package) se empaquetará tanto el código Java como los archivos HTML dentro de un único archivo .jar. Todo se levanta en un solo contenedor Docker y el proxy de Apache enruta todo bajo el mismo prefijo (/gis-geoserver/). - -Regla 1. El ambiente de desarrollo y compilación se encuentra en el 192.168.1.123. -El JENKINS a usar está en este servidor. Los comandos del jenkins se ejecutan en el servidor 192.168.1.123. -El MAVEN a usar está en este servidor. Los comandos maven se ejecutan en el servidor 192.168.1.123. -El DOCKER a usar está en el servidor 192.168.1.123. Los comandos docker se ejecutan en el servidor192.168.1.123. -Todas las compilaciones se ejecutarán en el servidor 192.168.1.123. -La base de datos georreferenciada física es SIGEM del Postgis está en este servidor y el superuser es el usuario registrado en el motor de base de datos como: -Usuario: sigem_user -Contraseña: sigem_pass - -Regla 2. Las bases de datos alfanuméricas de los municipios a usar vinculadas a la base de datos georreferenciada Postgis serán definidas dinámicamente usando la tabla ENTIDADES la Base de Datos SIGEMWEB en el servidor 192.168.1.254 - -Regla 3. El proxypass principal de redireccionamiento reside en el servidor 192.168.1.10 -El proxypass maestro de redireccionamiento reside en el servidor 192.168.1.20 -Estos proxypass no deben ser modificados por ningún motivo. -El proxy de Nginx de la Regla 3 tiene GeoServer mapeado a la ruta /geoserver/. Las peticiones se deberán mantener en el mismo dominio para evitar bloqueos CORS y para que sean enrutadas correctamente al contenedor de GeoServer. - -Regla 4. Para el LOGIN, para el campo desplegable de las ENTIDADES (Municipios) los datos deben ser obtenidos de la tabla ENTIDADES del SIGEMWEB del servidor 192.168.1.254. -Para el LOGIN, el usuario debe utilizar su usuario y contraseña del SIGEM del municipio. -Para tus pruebas, por ahora tienes disponible las credenciales para acceder a esa BD. -En caso de error detectado al intentar iniciar sesión, la aplicación debe dar un mensaje de error simple y claro del motivo, y permitir al usuario que vuelva a intentar. - -Regla 5. Los parámetros para la visualización y despliegue de mapas en el geoserver deberá usarse el registro correspondiente al municipio que se obtiene en la tabla ENTIDADES. -Los parámetros disponibles son: -sigem_site, -sigem_dbname, -latlong, -lng, -lat, -zoom, -mapa_base, -boundno, -boundse, -maxzoom, -minzoom. - -Para obtener los datos de los municipios se debe utilizar la propia API de la aplicación. - -Regla 6. Para la construcción en la compilación, se usa JAVA21 del 192.168.1.123, en sincronía con la Regla 1. - -Regla 7. Credenciales 192.168.1.123: cbareiro/x25yvaga2023, root/x25yvaga2023. - -Regla 8. Credenciales 192.168.1.10: cbareiro/x25yvaga2020, root/x25yvaga2021. - -Regla 9. Credenciales 192.168.1.20: cbareiro/x25yvaga2020, root/x25yvaga2020. - -Regla 10. Credenciales 192.168.1.129: cbareiro/x25yvaga2025. - -Regla 11. Jenkins (.123): admin / x25yvaga2024. - -Regla 12. Jenkins SSH Credential ID: sigem-server-123 (root). - -Regla 13. -Tomcat Manager: manager / x25yvaga2023. -GeoServer Web UI: admin / geoserver. - -Regla 14. -Endpoints Geoserver (.123:8080): /geoserver/wms, /geoserver/wfs, /geoserver/rest. - -User: admin -Password: x25yvaga2023 - -Regla 15. -La aplicación se desplegará en el servidor 192.168.1.123 -La carpeta de trabajo es: /yvyape/proyectos/sigem-gis - -Regla 16. Conexión FDW y Sincronización de Vistas. -Debe verificarse la existencia del FDW del municipio en cada LOGIN. -Si no existe, crearlo. -Refrescar obligatoriamente las vistas `vw_lotes_morosidad_X`. - -Regla 17. GIT -El repositorio de Git se encuentra en git.yvaga.com.py en el servidor 192.168.1.100 -Credenciales de Git (.100): cbareiro@yvaga.com.py / carlos57. Repo: git@git.yvaga.com.py:geo/gis-geoserver.git. -Si la carpeta a usar ya tiene archivos, el comando puede fallar, y debe limpiarse antes de clonar. - -Regla 18. SSH Local: Usar Bitvise con usuario cbareiro. - -Regla 19. Build: -Terminar (Uso obligatorio) con ./mvnw clean package -DskipTests. - -Regla 20. Prefijo FrontEnd: /gis-geoserver/. - -Regla 21. ContextPath Backend: /gis-geoserver. - -Regla 22: Integridad de Comandos Remotos: -Desde el ambiente de desarrollo (Windows 11) se utilizará SSH de Bitvise para los accesos a otros servidores, usando la Regla 9. -Debe usarse -cmdQuoted para ejecutar comandos complejos. - -Queda prohibido el uso de comandos printf, echo o concatenaciones multilínea complejas para crear archivos. Usar sftpc para subir archivos íntegros. -Para los comandos SQL complejos debido a la interpretación del shell de Windows y para asegurar la integridad total (Regla 22), se deben subir los archivos de estructura y población por SFTPC ejecutándolos desde el respectivo servidor. El paso intermedio para no generar errores es preparar los archivos de comandos en el servidor local y luego copiar el archivo de comandos al interior del contenedor antes de su ejecución, usando sftpc para subir archivos íntegros. - -Por ejemplo: -…\GIS-GEOSERVER > sexec cbareiro@192.168.1.123 -pw=x25yvaga2023 -cmd="cd /yvyape/proyectos/sigem-gis" -…\GIS-GEOSERVER > sexec cbareiro@192.168.1.123 -pw=x25yvaga2023 -cmd="./mvnw clean package -DskipTests" -…\GIS-GEOSERVER > sftpc cbareiro@192.168.1.123 -pw=x25yvaga2023 -cmd="put -o docker-compose.yml.remote.tmp /yvyape/proyectos/sigem-gis/docker-compose.yml" -…\GIS-GEOSERVER > sexec cbareiro@192.168.1.123 -pw=x25yvaga2023 -cmdQuoted -cmd="curl -s -u admin:geoserver -X PUT -H 'Content-Type: application/xml' -d @/yvyape/proyectos/sigem-gis/geoserver_config.xml http://proyecto-geoserver-1:8080/geoserver/rest/workspaces/sigem/datastores/sigem/featuretypes/vw_lotes_morosidad_505.xml" - -Regla 23. Columnas de Unión (Joins). Standard SNC. -Para toda vista de unión con el FDW, se debe utilizar la columna `snc_cuenta` (limpia) contra `REPLACE(liq.inm_ctacatastral, '-', '')`. -La definición del SQL de JOIN entre los datos SNC (datos georreferenciados) y la base de datos del municipio (datos alfanuméricos) genera la vista `public.vw_lotes_morosidad_XXX` a usar para desplegar mapa georreferenciado coloreado y es la siguiente: -```sql -DROP VIEW IF EXISTS public.vw_lotes_morosidad_XXX CASCADE; -CREATE OR REPLACE VIEW public.vw_lotes_morosidad_XXX AS -SELECT - lot.*, - liq.inm_ficha, - liq.inm_ctacatastral, - liq.trb_tributo, - liq.trb_total_deuda, - liq.trb_total_pago, - liq.ultimo_pago -FROM public.eXXX_lotes_activos lot -LEFT JOIN fdw_XXX.v_liq_entidad_totalxobjeto liq ON lot.snc_cuenta = REPLACE(liq.inm_ctacatastral, '-', '') ; - -Regla 24. Resiliencia del LOGIN y Servicios. -Toda orquestación de servicios secundarios (GeoServer REST API, FDW, MVT) invocada durante el proceso de LOGIN debe ser no-bloqueante. -Uso obligatorio de bloques try-catch y configuración de timeout máximo de 2 segundos por conexión para garantizar la fluidez del sistema. - -Regla 25. Protocolo de Logros y Protocolo de Resguardo y Recuperación (Backup) -El sistema debe garantizar la preservación de la integridad del proyecto mediante un tríptico de acciones atómicas ejecutadas obligatoriamente bajo pedido del usuario al alcanzar un hito. -1. Identificación del Hito: -Registro en VERSION.txt con formato "Version SIG - AAAA.MM.DD.HH.MM.SS ID DOCKER: [ID] [Observación Técnica]". -Sincronización de Código (Git): Ejecución de git add ., git commit y git push origin main hacia el servidor .100. -Snapshot de Infraestructura (.123): -Generación de volcado PostGIS: docker exec proyecto-postgres-1 pg_dump -U sigem_user sigem > sigem_postgres_dump.sql. -Compresión de datos de GeoServer: tar -czvf geoserver-data_dir.tar.gz geoserver-data. -Almacenamiento en carpeta cronológica dentro de /publico/. - -Solo bajo autorización del usuario. - -Regla 26. El motor de importación debe aplicar una limpieza universal al campo snc_cuenta para asegurar el match tributario. -La identificación de la zona se realiza mediante la variable tipo_cuenta: -1. Zona Urbana (tipo_cuenta = 1): snc_cuenta = Substring(ccatastral, 4) eliminando ceros a la izquierda y caracteres especiales. -Algoritmo Java para Zona Urbana: -substring(3) (4ª posición). -replaceAll("[^a-zA-Z0-9]", "") (Eliminar guiones, puntos, etc.). -replaceFirst("^0+", "") (Eliminar ceros a la izquierda resultantes). -Algoritmo SQL para Zona Urbana: -SUBSTRING(ccatastral FROM 4) (Substring desde la 4ª posición). -REGEXP_REPLACE(..., '[^a-zA-Z0-9]', '', 'g') (Limpieza de caracteres especiales). -LTRIM(..., '0') (Eliminación de ceros a la izquierda). - -2. Zona Rural (tipo_cuenta = 0): snc_cuenta = padron::text (sin modificaciones). -Esta regla es mandatoria para toda municipalidad. -Se debe aplicar ST_MakeValid(geom) en la inserción para prevenir errores de renderizado en GeoServer. -Para la relación entre código SNC y código de municipio se debe utilizar la tabla ENTIDADES que se registra en public.snc_catalog_mapping - -Regla 27. Optimización y Cache GeoWebCache (GWC): -Para asegurar la fluidez nacional (>2M de registros), cada capa de municipio debe contar con índices espaciales GIST sincronizados. -El sistema debe intentar disparar el truncado de cache en GeoWebCache (GWC) cada vez que se detecte un cambio masivo en la tabla de morosidad remota del municipio. - -Regla 28. Importación de datos del SNC. Se utilizará el API: https://www.catastro.gov.py/geoserver/ows. -Para garantizar la compatibilidad universal en el visor web, TODOS los datos deben almacenarse en SRID 4326 (Coordenadas Geográficas) en las tablas eXXX_lotes_activos. -Es MANDATORIO solicitar la transformación de coordenadas directamente al SNC incluyendo el parámetro srsName=EPSG:4326 en la URL de la petición WFS. -La inserción en la base de datos se realizará mediante el uso directo de ST_GeomFromGeoJSON(?). -Implementar un TRUNCATE automático al inicio del proceso de importación. Si al importar los números son UTM, se deben transformar a 4326 antes de guardarlos. -Las columnas de las tablas eXXX_lotes_activos deberá tener todas las columnas del SNC. - -Regla 29. -Para la construcción en la compilación, se usa JAVA21 del 192.168.1.123, en sincronía con la Regla 1. -El uso de rutas relativas en Docker ya ha estado causando problemas desde antes. Debes usar rutas absolutas - -Regla 30. Arquitectura de Visualización en Dos Niveles. -El visor GIS utiliza una estrategia de superposición para optimizar el rendimiento y la claridad visual. Utiliza dos tipos de capas para mostrar los lotes: Una Capa Base (Lotes Grises) y múltiples Capas Temáticas (Lotes Coloreados). -1. Capa Base (Esqueleto): Utiliza la tabla física soberana `eXXX_lotes_activos`. Se publica en GeoServer con un estilo neutro (gris/transparente). Representa la totalidad del territorio y siempre es local y persistente. -2. Capa Temática (Inteligencia): Utiliza la vista lógica `vw_lotes_morosidad_XXX`. Es la capa dinámica que aplica el JOIN con el FDW municipal. -El Efecto Visual: La capa temática se superpone a la base. Aquellos lotes con coincidencia tributaria se "pintan" con el estilo de morosidad (semáforo), mientras que los lotes sin vínculo o sin deuda permanecen en gris (dejando ver la capa base), garantizando que la ciudad nunca se vea "incompleta". -El contenedor de GeoServer (sigem-gis-geoserver-1) y el de PostgreSQL (proyecto-postgres-1) tienen sus propias redes internas de Docker y no tienen acceso directo a otras redes Docker por seguridad y estabilidad. Por lo tanto, debe configurarse y ejecutarse dentro de la red privada interna de Docker. \ No newline at end of file +# Reglas del Proyecto: GIS-GEOSERVER (SNC + SIGEM) + +Regla 0. +Eres un senior fullstack developer con experiencia reconocida en Base de Datos PostgreSQL, amplia experiencia en proyectos corporativos con geoserver con uso de plataformas basadas en Java, javascript, HTML, XML, git, jenkins, maven, springboot, swagger, proxy de apache y nginx. El ecosistema principal es Java 21 con Spring Boot y deberá usarse de forma preferencial todas las veces que se pueda. El frontend usa el framework corporativo AdminLTE/Bootstrap y MapLibre GL JS v4.0.0+ como motor de visualización vectorial. + +Este proyecto GIS-GEOSERVER debe utilizar un patrón arquitectónico llamado Monolito Spring Boot con Recursos Embebidos (Server-Side Monolith). + +El Backend (El Cerebro): Está escrito en Java 21 con Spring Boot (ubicado en la carpeta src/main/java/). Se encarga de la lógica pesada: seguridad, conexión a la base de datos PostgreSQL/PostGIS, consultas FDW, y expone los servicios REST (ej. /api/gis/entidad/505). + +El Frontend (La Cara): Utiliza tecnologías de navegador clásicas: HTML, Vanilla JavaScript, jQuery y AdminLTE/Bootstrap. Pero en lugar de vivir en un servidor web aparte (como un Nginx puro o un Node.js), todos estos archivos viven dentro de la carpeta del propio proyecto Java: en src/main/resources/static/ y src/main/resources/templates/. + +No hay dos servidores distintos. Cuando Spring Boot arranca su servidor interno (Tomcat), hace el trabajo doble: Si el navegador le pide datos, el código Java responde con JSON (API REST). Si el navegador le pide /gis-geoserver/mapas, el mismo servidor Java va a su propia carpeta interna (static o templates), lee el archivo HTML, y se lo envía al navegador del usuario. Cuando se ejecute el comando de Maven (mvnw clean package) se empaquetará tanto el código Java como los archivos HTML dentro de un único archivo .jar. Todo se levanta en un solo contenedor Docker y el sistema de proxies enruta todo bajo el mismo dominio (usando los prefijos /gis-geoserver/ para la app y /geoserver/ para el motor de mapas) garantizando la ausencia de bloqueos de seguridad CORS. + +Regla 1. +Regla 1. El ambiente de desarrollo y compilación centralizado se encuentra en el servidor 192.168.1.123, específicamente en la ruta raíz del proyecto: /yvyape/proyectos/sigem-gis/. + +El JENKINS a usar está en este servidor. Los comandos del jenkins se ejecutan en el servidor 192.168.1.123. El MAVEN a usar está en este servidor. Se deberá utilizar preferentemente el Maven Wrapper (./mvnw) ubicado en la raíz del proyecto para asegurar la compatibilidad de versiones y evitar problemas de permisos globales. El DOCKER a usar está en el servidor 192.168.1.123. Los comandos docker se ejecutan en el servidor 192.168.1.123. Todas las compilaciones se ejecutarán en el servidor 192.168.1.123. La base de datos georreferenciada física es SIGEM (PostGIS) y reside en este mismo servidor. El superuser registrado en el motor de base de datos es: Usuario: sigem_user Contraseña: sigem_pass + +Regla 2. +La arquitectura es Multi-Municipio y se basa en la federación de Base de Datos municipales. Las bases de datos alfanuméricas de los municipios estarán ubicadas físicamente según las políticas de Yvaga en servidores registrados en la tabla ENTIDADES de la Base de Datos SIGEMWEB del servidor 192.168.1.254. Se vinculan dinámicamente con la base de datos georreferenciada PostGIS (servidor 192.168.1.123) mediante el uso de Foreign Data Wrappers (FDW) con su respectivo esquema fdw_[ID_ENTIDAD] generados automáticamente por este sistema. + +La tabla maestra de orquestación es ENTIDADES de la base de datos SIGEMWEB (.254). Para cada municipio, se deberá mantener un esquema FDW en PostGIS siguiendo la nomenclatura fdw_[ID_ENTIDAD] (ejemplo: fdw_505). El vínculo fundamental entre la base de datos georreferenciada (cartografía GIS) y la base de datos alfanumérica municipal para generar mapas temáticos se realiza exclusivamente a través del campo unificado snc_cuenta. + +Regla 3. +El proxypass principal de redireccionamiento reside en el servidor 192.168.1.10 +El proxypass maestro de redireccionamiento reside en el servidor 192.168.1.20 +Estos proxypass no deben ser modificados por ningún motivo. +Esta infraestructura unifica todo el ecosistema bajo un mismo dominio y punto de entrada: +Aplicación (Backend/Frontend): Enrutada bajo el prefijo /gis-geoserver/. +Motor de Mapas (GeoServer): Enrutado bajo el prefijo /geoserver/. +Se prohíbe terminantemente el uso de IPs directas o puertos específicos (ej: :8080, :8083) en el código JavaScript del frontend. Todas las peticiones (XHR, Fetch, Tile Requests) deben realizarse mediante rutas relativas o dinámicas (ej: ${window.location.origin}/geoserver/...). +El tráfico debe fluir siempre a través del proxy, eliminando de raíz los bloqueos de seguridad CORS y permitiendo el acceso transparente desde cualquier red. + +Regla 4. +El proceso de Autenticación (LOGIN) actúa como el selector de contexto Multi-Municipio del sistema. +Para el campo desplegable de las ENTIDADES (Municipios), los datos deben obtenerse exclusivamente de la tabla ENTIDADES del servidor 192.168.1.254 correspondientes a municipios activos. Un municipio se considera activo si su campo ESTADO = 'ACTIVO', y estado_mapa = '1' (Activo) o estado_mapa = '2' (En Implementación). +El usuario se autenticará utilizando sus credenciales oficiales del SIGEM municipal. +Tras un inicio de sesión exitoso, el sistema debe: +Emitir un Token JWT seguro para autorizar peticiones. +Persistir en el navegador (ej: localStorage) el Token, el nombre del usuario y, obligatoriamente, el ID de la Entidad. +Utilizar este ID de Entidad como único filtro en todas las consultas posteriores al Backend y al GeoServer, garantizando el aislamiento total de datos entre municipios. +En caso de error, el sistema debe proporcionar un mensaje simple, claro y descriptivo del motivo (ej: "Usuario no reconocido", "Servidor municipal fuera de línea") y permitir el reintento inmediato. + +Regla 5. +La configuración del Visor GIS es dinámica y se basa exclusivamente en los metadatos de la Entidad. El Frontend debe ser agnóstico y configurarse en tiempo de ejecución consumiendo los parámetros desde la API de la aplicación (ejemplo: /api/entidad/config/{id}). +Los parámetros críticos para el motor MapLibre son: +Encuadre Inicial: lat, lng y zoom para posicionar la cámara al cargar. +Restricción Territorial: boundno (Noroeste) y boundse (Sureste) para definir los límites máximos de navegación (maxBounds), impidiendo que el usuario se pierda fuera del municipio. +Profundidad: minzoom y maxzoom para controlar el nivel de detalle permitido. +Capa Soberana: El campo mapa_base definirá dinámicamente el nombre de la capa de lotes a cargar desde GeoServer (ejemplo: e505_lotes_activos). +Otros parámetros de orquestación disponibles: sigem_site, sigem_dbname, latlong. + +Regla 6. +El estándar de construcción y ejecución del proyecto es Java 21 (LTS). En total sincronía con la Regla 1, todas las compilaciones se realizan en el servidor 192.168.1.123. + +El proceso de construcción debe generar un único archivo binario .jar autoejecutable (Fat JAR). Este archivo debe contener tanto la lógica de negocio del Backend como la totalidad de los recursos estáticos del Frontend (HTML/JS/CSS), asegurando que el despliegue sea atómico y consistente en el contenedor Docker. + +Regla 7. +Credenciales de acceso SSH al servidor de desarrollo y producción (192.168.1.123): +Usuario: cbareiro / Contraseña: x25yvaga2023 +Usuario: root / Contraseña: x25yvaga2023 + +Regla 8. +Credenciales de acceso SSH al servidor Proxypass Principal 192.168.1.10: +Usuario: cbareiro / Contraseña: x25yvaga2020 +Usuario: root / Contraseña: x25yvaga2021 + +Regla 9. +Credenciales de acceso SSH al servidor Proxypass Maestro (192.168.1.20): + +Usuario: cbareiro / Contraseña: x25yvaga2020 +Usuario: root / Contraseña: x25yvaga2020 + +Regla 10. +Credenciales de acceso SSH al servidor KAFKA (192.168.1.129): +Usuario: cbareiro / Contraseña: x25yvaga2025 + +Regla 11. +Credenciales de acceso a la Interfaz Web (Web UI) de Jenkins (servidor 192.168.1.123): +Usuario: admin / Contraseña: x25yvaga2024 + +Regla 12. +Identificador de Credenciales (Credential ID) almacenado en Jenkins para la ejecución de despliegues automáticos (Pipelines) mediante SSH al servidor 192.168.1.123: +ID: sigem-server-123 (Vinculado al usuario root del servidor). + +Regla 13. +Credenciales de acceso a las interfaces administrativas de los servicios desplegados: +Tomcat Manager (Gestión del Backend): Usuario: manager / Contraseña: x25yvaga2023 +GeoServer Web UI (Gestión de Capas y Estilos): Usuario: admin / Contraseña: geoserver + +Regla 14. +Puntos de enlace (Endpoints) y API de GeoServer para la comunicación interna (Backend-to-GeoServer): +Base URL Interna: http://192.168.1.123:8083/geoserver/ (Puerto real de servicio en el servidor .123). +Servicios disponibles: /wms, /wfs y la interfaz /rest para gestión automática de capas. +Credenciales de API REST: +Usuario: admin / Contraseña: x25yvaga2023 (Credencial técnica para procesos Java). +IMPORTANTE: Esta regla es de uso exclusivo para la lógica del servidor Java (Backend). El Frontend jamás debe utilizar estas rutas directas, debiendo ceñirse siempre a la Regla 3 (rutas relativas vía Proxy). + +Regla 15. Estructura de Despliegue y Persistencia. +El centro de operaciones del proyecto reside en el servidor 192.168.1.123, dentro de la carpeta de trabajo: /yvyape/proyectos/sigem-gis/. +Este directorio debe mantener la siguiente estructura crítica: +Orquestación: Contiene el archivo docker-compose.yml que gestiona los contenedores. +Persistencia de GeoServer: El subdirectorio geoserver-data/. Este volumen es vital y persistente; contiene todas las definiciones de capas, estilos y formatos (PBF/XYZ). Nunca debe ser eliminado ni sobreescrito por procesos de limpieza de Git. +Registro de Versiones: El archivo VERSION.txt para el seguimiento de hitos de éxito. + +Regla 16. Integridad de Datos y Sincronización Alfanumérica (FDW). Para garantizar que los mapas temáticos (Morosidad, Deuda, Pagos) reflejen la realidad municipal en tiempo real, el Backend debe realizar las siguientes acciones en cada proceso de LOGIN: + +Verificación de Enlace: Validar la existencia del esquema fdw_[ID_ENTIDAD] y sus tablas vinculadas (provenientes de la Regla 2). Si el enlace no existe o la conexión FDW ha fallado, el sistema debe reconfigurarlo automáticamente. +Sincronización de Capas: Ejecutar el refresco de las vistas de datos (ejemplo: vw_lotes_morosidad_[ID_ENTIDAD]) que sirven de fuente a GeoServer. Esto asegura que los atributos alfanuméricos estén perfectamente alineados con la geometría de los lotes. +Garantía de Vínculo: El proceso debe asegurar que el campo snc_cuenta mantenga la integridad referencial necesaria para el cruce de información espacial-alfanumérica. + +Regla 17. Sincronización y Control de Versiones (GIT). +El repositorio central del código reside en el servidor 192.168.1.100 (git.yvaga.com.py). +URL de Repositorio: git@git.yvaga.com.py:geo/gis-geoserver.git +Rama Principal: main (estándar obligatorio del proyecto). +Credenciales: cbareiro@yvaga.com.py / carlos57. +Gestión de Archivos en el Servidor 192.168.1.123: +Sincronización: Todo cambio validado en el servidor de desarrollo debe ser enviado (git push origin main) de inmediato para consolidar el hito. +Limpieza Segura: En caso de conflictos de archivos, se permite el uso de git clean -fd. +RESTRICCIÓN CRÍTICA: Queda prohibido el uso de comandos de limpieza o reset que afecten al directorio geoserver-data/. Este directorio debe estar excluido del rastreo de Git para evitar la pérdida de configuraciones cartográficas activas durante las actualizaciones de código. + +Regla 18. Herramientas de Acceso Remoto Local. +Desde el ambiente de desarrollo (Windows 11) se utilizará obligatoriamente Bitvise SSH Client como puente ÚNICO hacia los servidores Linux de la plataforma YVAGA. +Sesiones Interactivas: Uso del perfil de Bitvise con el usuario cbareiro. +Ejecución de Scripts: Uso de la utilidad sexec para la ejecución de comandos remotos automatizados (Maven, Docker, Git). +Gestión de Archivos: Uso de sftpc para la transferencia de archivos binarios y código fuente, garantizando la integridad de los datos transmitidos. + +Regla 19. Protocolo de Empaquetado y Despliegue (Build). +Todo ciclo de modificación de código Java o de recursos estáticos (HTML/JS/CSS) debe finalizar con el siguiente protocolo atómico en el servidor .123: +Empaquetado Obligatorio: Ejecutar sh ./mvnw clean package -DskipTests en la raíz del proyecto. El uso del prefijo sh es obligatorio para garantizar la ejecución sobre el Maven Wrapper independientemente de los permisos del sistema de archivos. +Sincronización de RAM: Tras obtener un BUILD SUCCESS, se debe reiniciar obligatoriamente el contenedor del backend para que la nueva versión del archivo .jar sea cargada en memoria: docker restart sigem-gis-backend + +Regla 20. Identidad de Ruta del FrontEnd. +Toda la interfaz de usuario y recursos del cliente residen bajo el prefijo obligatorio /gis-geoserver/. +Este prefijo es la "firma" que los proxies de la Regla 3 utilizan para identificar y dirigir el tráfico hacia el contenedor de Java. Por lo tanto: +Referencias en HTML: Todos los enlaces (), scripts (