Geometría ArcGIS y taxonomía SAP: cómo se sincronizan vía GEF

Mientras una edición del mapa vive en una versión con nombre, sin conciliar ni publicar todavía en la versión predeterminada, ¿qué debería leer el sistema de mantenimiento? Esa pregunta, casi nunca formulada en los talleres de diseño, decide si una integración entre ArcGIS y SAP sostiene una sola verdad sobre el activo o fabrica dos. Esta pieza desarma la sincronización en cuatro decisiones técnicas. Empieza por la que se suele subestimar, el versionado, y sigue con la llave, el canal y el almacenamiento.

Versión con nombre o versión predeterminada: qué debe leer SAP

---
config:
  theme: base
  fontFamily: 'Inter Variable, system-ui, sans-serif'
  themeVariables:
    darkMode: true
    fontFamily: 'Inter Variable, system-ui, sans-serif'
    fontSize: '15px'
    background: '#111113'
    primaryColor: '#1A1A1D'
    primaryTextColor: '#F4F5F8'
    primaryBorderColor: '#8B5CF6'
    secondaryColor: '#242428'
    tertiaryColor: '#1A1A1D'
    mainBkg: '#1A1A1D'
    secondBkg: '#242428'
    tertiaryBkg: '#2E2E33'
    lineColor: '#8B5CF6'
    textColor: '#F4F5F8'
    titleColor: '#F4F5F8'
    nodeBorder: '#8B5CF6'
    clusterBkg: '#1A1A1D'
    clusterBorder: '#2E2E33'
    edgeLabelBackground: '#242428'
    pie1: '#8B5CF6'
    pie2: '#f59e0b'
    pie3: '#22c55e'
    pie4: '#b495f9'
    pie5: '#f97316'
    pie6: '#ef4444'
    pieTitleTextColor: '#F4F5F8'
    pieSectionTextColor: '#F4F5F8'
    pieLegendTextColor: '#F4F5F8'
    pieStrokeColor: '#111113'
    pieOuterStrokeColor: '#111113'
---
flowchart TD
  A([Edición en versión con nombre]) --> B[El editor termina sus cambios]
  B --> C[Conciliar y publicar en la predeterminada]
  C --> D{¿Regla de lectura explícita?}
  D -->|Sí| E([SAP consume la red conciliada y publicada])
  D -->|No| F([Red a medio dibujar puede convivir con órdenes sobre la red anterior])
  class A inicio
  class D decision
  class B,C proceso
  class E bueno
  class F malo
classDef inicio fill:#30274d,stroke:#8B5CF6,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
classDef malo fill:#462226,stroke:#ef4444,color:#ffffff

En el modelo de versionado en rama, cada editor trabaja en su propia versión con nombre y, al terminar, concilia y publica sus cambios en la versión predeterminada (Esri ArcGIS Pro — Versioning types, 2026). La misma documentación fija dos reglas que pesan en una integración. La primera: una versión con nombre admite un solo editor, que obtiene un bloqueo exclusivo. La segunda: la jerarquía es plana, con un único nivel de versiones creadas a partir de la predeterminada (Esri ArcGIS Pro — Versioning types, 2026).

Para la geodatabase en SAP HANA no hay atajo. Los flujos de edición versionada exigen versionado en rama y publicar los datos como capa de entidades web con gestión de versiones habilitada (Esri ArcGIS Pro, 2026). El versionado tradicional tiene otra condición que conviene conocer antes de improvisar lecturas directas a las tablas: las aplicaciones que no son de ArcGIS deben adaptarse con vistas versionadas antes de poder leer los datos (Esri ArcGIS Pro — Versioning types, 2026).

De ahí sale la regla de diseño que recomendamos dejar por escrito. El sistema de mantenimiento consume la red conciliada y publicada en la versión predeterminada, nunca un trabajo en curso. Es una decisión de diseño que conviene fijar explícitamente. Si queda implícita, una ampliación de red a medio dibujar puede convivir con órdenes de trabajo emitidas sobre la red anterior, y la integración disimula la diferencia en vez de exponerla.

El par de llaves: la unidad mínima de la sincronización

La segunda decisión es de identidad. Esri describe que los patrones de integración entre SAP y ArcGIS dependen, en general, de establecer y mantener la vinculación o sincronización de relaciones de pares de llaves foráneas (Esri ArcGIS Architecture Center, s. f.). En términos operativos, cada entidad del mapa necesita un par explícito con su objeto técnico en SAP, sea una ubicación técnica o un equipo.

Todo lo demás viaja sobre ese par. Consultoría Venezuela aborda este punto desde la operación: si la llave existe pero nadie la custodia, la integración copia la discrepancia con total fidelidad, y ambos registros quedan unidos por un dato equivocado. Antes de tocar cualquier interfaz conviene cerrar una decisión de negocio: qué sistema es dueño de la identidad del activo y cuál es dueño de su forma y su posición.

Por dónde viaja el dato: REST, OData y vistas CDS

Con la versión de lectura y la llave resueltas, queda el transporte. Según Esri, el GEF usa APIs REST para conectar servicios de ArcGIS con sistemas SAP, lo que permite almacenar y manipular datos geoespaciales transaccionales en una geodatabase de ArcGIS en SAP HANA. En el sentido inverso, admite servicios OData para exponer datos geoespaciales de SAP hacia ArcGIS (Esri ArcGIS Architecture Center, s. f.). Entre ambos sentidos, las vistas CDS de SAP pueden actuar como capa semántica consumible por los dos sistemas, ya sea como vistas de cálculo de HANA o como capas de consulta de ArcGIS (Esri ArcGIS Architecture Center, s. f.).

Dónde se guarda la geometría: la geodatabase en SAP HANA

La cuarta decisión es física. La documentación vigente de ArcGIS Pro indica que una base de datos SAP HANA puede habilitarse para alojar una geodatabase. Esa geodatabase admite, entre otras capacidades, redes de servicios públicos (utility networks), seguimiento de editores y versionado en rama para edición de transacciones largas a través de servicios de entidades (Esri ArcGIS Pro, 2026). Que el modelo de red y el rastro de quién editó qué compartan motor con SAP puede evitar la copia intermedia, que es donde suele perderse la trazabilidad.

Esto es coherente con la premisa que SAP planteó al anunciar el framework: que la geometría de los objetos de negocio resida en SAP HANA (DBTA, 2016). Además, Esri anunció la certificación y el soporte de SAP HANA Cloud, componente de SAP Business Technology Platform (Geospatial World, 2021), lo que extiende esta arquitectura a organizaciones que están migrando su núcleo SAP.

Cuando el GEF no es la ruta: Integration Suite

No todos los escenarios pasan por el GEF. Esri documenta que las herramientas de SAP Integration Suite, dentro de SAP BTP, pueden conectarse con servicios de ArcGIS mediante REST para traer entidades de ArcGIS a SAP. En sentido inverso, pueden empujar entidades de SAP hacia servicios de entidades de ArcGIS o invocar herramientas de geoprocesamiento (Esri ArcGIS Architecture Center, s. f.). Este patrón encaja cuando la organización ya opera su integración en BTP o cuando la geometría no necesita residir en HANA.

Una precisión útil al buscar documentación: Esri se refiere al marco como “Geospatial Enablement Framework”, mientras que SAP lo anunció como Geographical Enablement Framework. Se trata del mismo componente.

Cualquiera de las dos rutas se apoya en plataformas licenciadas de ambos fabricantes, así que conviene confirmar con SAP y con Esri qué cubre cada contrato antes de fijar alcance.

Tres reglas de operación que el conector no trae

Especializados en IS-U y gestión de activos, vemos que cuando una sincronización GIS↔SAP falla, el origen rara vez está en el conector. Está en tres reglas que nadie asignó:

• Custodio de la llave. Alguien debe responder por cada par entre la entidad del mapa y el objeto técnico de SAP. Sin ese responsable, la integración queda como una iniciativa que nadie mantiene.
• Pares huérfanos antes de activar. Antes de encender la sincronización, cada objeto técnico geolocalizable debería tener su entidad pareada, y viceversa. Ese recuento debe ser un quality gate obligatorio, no una limpieza posterior.
• Bitácora de discrepancias. Cada diferencia detectada en campo dice algo sobre la regla de sincronización o sobre la versión que se está leyendo. Si no se registra, se repite.

En las distribuidoras eléctricas y de agua de América Latina, donde los equipos de GIS y de mantenimiento suelen ser reducidos, estas reglas aportan más estabilidad que cualquier funcionalidad adicional.

Esta es la tercera entrega de la serie. La anterior presentó el framework y sus componentes. En la próxima pasaremos del mecanismo al uso: cómo crear una orden de mantenimiento directamente desde el mapa y ver el trabajo antes de llegar al sitio.

Fuentes

• Esri ArcGIS Pro — Versioning types (2026). https://doc.esri.com/en/arcgis-pro/latest/help/data/geodatabases/overview/versioning-types.html
• Esri ArcGIS Architecture Center (s. f.). SAP and ArcGIS integrations. https://architecture.arcgis.com/en/framework/architecture-pillars/integration/providers/sap.html
• Esri ArcGIS Pro (2026). Introduction to enterprise geodatabases in SAP HANA. https://doc.esri.com/en/arcgis-pro/latest/help/data/geodatabases/manage-saphana/overview-geodatabases-saphana.html
• DBTA (2016). New Geospatial Framework Offered by SAP. https://www.dbta.com/Editorial/News-Flashes/New-Geospatial-Framework-Offered-by-SAP-112522.aspx
• Geospatial World (2021). Esri and SAP advance integration of business technology and GIS platforms. https://geospatialworld.net/news/esri-and-sap-advance-integration-of-business-technology-and-gis-platforms/

Artículo de Edward Camacho Guerra, elaborado con apoyo de herramientas de inteligencia artificial y revisado y aprobado por el autor.