Tag Archives: RFC SAP

  • 11
    Ene 26
  • 0

Guía DIY: instala y deja listo SAP Cloud Connector (de cero a “conectado” sin dramas)

Category:Programación,SAP,SAP BTP Tags : 

La verdad incómoda (y útil)

SAP Cloud Connector en adelante SCC es mucho mas que “solo instalar un ejecutable”. Es un componente de conectividad y seguridad que permite crear un puente controlado entre tu red on-premise y SAP BTP. Si lo tratas como tan solo un instalador más, lo vas a terminar operando con permisos de más, puertos abiertos de más y visibilidad de menos. Y sí: cuando eso explota, explota en producción… como todo lo “urgente” que se dejó para después.

Dicho eso, SCC es de las piezas más agradecidas del stack SAP cuando se configura bien: reduce superficie de ataque (todo es outbound), trabaja con allowlists, separa entornos con Location IDs y le da a tus proyectos de integración una base sólida para escalar.

El objetivo de esta guía no es solo instalarlo si no dejarlo operando con enfoque “enterprise-ready”, por esto se indican una serie de prerrequisitos, decisiones de arquitectura, instalación en Windows o Linux, conexión a tu subcuenta de BTP, publicación de recursos (HTTP/RFC), pruebas, hardening, operación y troubleshooting.

1) Qué es SAP Cloud Connector y cuándo lo necesitas

SCC es un agente que corre dentro de tu red (datacenter o VPC) y permite establecer un túnel seguro hacia SAP BTP. Su objetivo es habilitar conectividad Cloud-to-On-Premise para servicios y apps en BTP sin exponer sistemas internos a Internet.

Casos típicos:

  • SAP Integration Suite (Cloud Integration/CPI) consumiendo APIs internas (HTTP/S) o RFC hacia ECC/S/4HANA.
  • Apps en SAP BTP (Cloud Foundry / Kyma) accediendo a servicios internos (OData, REST, SOAP, RFC).
  • Conectividad controlada a endpoints no-SAP internos (microservicios, gateways internos, ESB legacy).

Cuándo NO es la mejor opción:

  • Si tu estrategia es “API-first inbound” con API Gateway + WAF + OAuth y tu organización prefiere exponer APIs de forma controlada hacia Internet.
  • Si necesitas tráfico entrante directo a tu red desde Internet (SCC está diseñado para evitarlo).
  • Si tu dolor principal es identidad/IAM: SCC ayuda a conectividad, no resuelve IAM por arte de magia.

2) Arquitectura en 5 minutos: cómo fluye el tráfico

Piensa en SCC como un “proxy inverso controlado por allowlist” con túnel saliente:

  1. BTP (tu app o Integration Suite) solicita un recurso “virtual” (host/puerto virtual).
  2. El servicio de conectividad en BTP enruta esa solicitud por el canal seguro al SCC correcto.
  3. SCC traduce host/puerto virtual → host/puerto interno real solo si está permitido.
  4. La respuesta vuelve por el mismo canal.

Claves que cambian el juego:

  • Todo es outbound desde tu red hacia BTP (típicamente HTTPS 443). Menos peleas con firewall.
  • Allowlist por recurso: no publicas “el sistema”; publicas rutas/servicios específicos.
  • Separación por subcuentas y Location ID: orden y gobernanza para DEV/QA/PRD.
  • Auditabilidad: logs, trazas y cambios administrables.

3) Prerrequisitos: no te saltes esta parte (tu yo del futuro te lo agradecera)

Antes de instalar, valida estos puntos. Esto no es “formalidad”; es gestión de riesgo.

3.1 Infraestructura

  • Servidor dedicado o VM (recomendado).
  • CPU/RAM: para la mayoría de escenarios, 2 vCPU y 4–8 GB RAM funciona bien. Si CPI va a disparar alto volumen, dimensiona con pruebas.
  • Disco: 10–20 GB suele bastar; prioriza IOPS decentes si vas a usar trazas.
  • HA/criticidad: define si SCC será parte de tu plataforma crítica o solo un habilitador puntual.

3.2 Red

  • Salida a Internet desde el host SCC hacia endpoints de SAP BTP (HTTPS/443). En corporativos, puede ser vía proxy.
  • DNS estable: SCC depende de DNS para endpoints BTP y para llegar a sistemas internos.
  • Acceso interno desde SCC a lo que vas a publicar (S/4HANA, APIs, gateways, etc.).
  • Puerto de administración para el UI (HTTPS). Por defecto suele ser 8443, pero puedes definir otro. Restringe su acceso (segmento admin/bastion).

3.3 BTP

  • Subcuenta en SAP BTP.
  • Servicio/plan de conectividad habilitado según tu modelo de consumo.
  • Permisos para administrar destinos (Destinations) y conectividad.

3.4 Seguridad y compliance

  • Define quién administra SCC (roles, rotación, mínimos privilegios).
  • Decide si reemplazarás el certificado del UI por uno corporativo (recomendado en entornos regulados).
  • Define política de logs/retención y si centralizas en SIEM.

4) Diseño rápido antes de tocar “Next”: decisiones que te evitan retrabajo

4.1 Un SCC por ambiente (casi siempre sí)

  • DEV, QA, PRD idealmente en subcuentas separadas y/o con Location IDs distintos.
  • Evita mezclar PRD con DEV en el mismo SCC salvo gobierno explícito.

4.2 Naming estándar (porque el caos no escala)

Define un estándar para:

  • Subaccount mapping: btp-<pais>-<dominio>-<env>
  • Location ID: LOC_<APP>_<ENV> (ej. LOC_LTC_PRD)
  • Virtual Host: vh-<sistema>-<env> (ej. vh-s4-prd)
  • Destinations: S4_PRD_RFC, API_PRD_ODATA, etc.

4.3 Qué vas a exponer (inventario mínimo viable)

  • HTTP(S): OData /sap/opu/odata/, SOAP /sap/bc/srt/, REST internos, etc.
  • RFC: con alcance mínimo y controlado.
  • Si dudas: empieza por un servicio funcional, prueba, luego amplías.

5) Descarga: dónde obtener el instalador y cómo validarlo (sin “descargas misteriosas”)

Flujo recomendado:

  1. Descarga SCC desde el https://tools.hana.ondemand.com/#cloud
  2. Elige el paquete correcto para tu OS (Windows o Linux x86_64).
  3. Verifica integridad si tu proceso lo exige (hash/firmas).
  4. Alinea versión con tu política: no persigas “la última” sin QA, pero tampoco te quedes obsoleto.

Operativamente: guarda instalador + notas de versión en tu repositorio interno. Eso acelera auditorías y rollback.

6) Instalación en Windows (paso a paso)

6.1 Preparación del host

  • Parches de sistema al día.
  • Cuenta de servicio (si tu estándar lo pide).
  • Directorio recomendado, por ejemplo C:\SAP\scc.
  • Firewall:
    • UI: solo desde red admin/bastion.
    • Salida HTTPS/443 hacia BTP (directo o vía proxy).

6.2 Instalar

  1. Ejecuta el instalador como administrador.
  2. Acepta licencia.
  3. Define ruta de instalación.
  4. Define el puerto del UI (8443 es común; lo importante es restringir acceso).
  5. Finaliza.

6.3 Levantar el servicio y abrir la consola

  • Inicia el servicio de SAP Cloud Connector.
  • Abre el UI: https://<host>:<puerto>/
  • Primera vez: crea usuario administrador y contraseña.

Buenas prácticas para el admin:

  • Contraseña larga, rotación.
  • Administración controlada (no “la clave del equipo pegada en un post-it digital”).

7) Instalación en Linux (RPM/DEB) con enfoque operativo

7.1 Preparación del host

  • Hora sincronizada (NTP/chrony). TLS odia relojes “creativos”.
  • Firewall y segmentación listos.
  • Define si usarás proxy corporativo.

7.2 Instalar paquete

RHEL/CentOS (RPM):

sudo rpm -ivh sapcc-*.rpm

Debian/Ubuntu (DEB):

sudo dpkg -i sapcc-*.deb
sudo apt-get -f install

7.3 Control del servicio (systemd)

sudo systemctl status scc_daemon
sudo systemctl start scc_daemon
sudo systemctl enable scc_daemon

7.4 Acceso al UI

Desde un equipo autorizado:

  • https://<host>:<puerto>/

Si el navegador alerta por certificado autogenerado: normal al inicio. En entornos serios, cámbialo por uno corporativo.

8) Primer arranque: configuración inicial sin atajos peligrosos

8.1 Endurece el acceso al UI

  • Restringe a red admin/bastion.
  • No expongas el UI hacia redes generales “porque es más cómodo”.

8.2 Certificado del UI (recomendado)

Objetivo: cifrado y confianza corporativa para administración.

  • Genera certificado TLS con CN/SAN correctos.
  • Instálalo según el mecanismo soportado (keystore).
  • Elimina excepciones “permanentes” en navegadores.

8.3 Configura proxy (si aplica)

Si tu empresa sale a Internet por proxy:

  • Configura proxy en SCC (host/puerto, autenticación si aplica).
  • Valida conexión estable a BTP desde SCC.

8.4 Logs y trazas

  • Nivel estándar en PRD.
  • Trazas elevadas solo con ventana de tiempo y objetivo claro. Dejar debug encendido en producción es como dejar el micrófono abierto en una junta: tarde o temprano alguien se arrepiente.

9) Conexión a SAP BTP: subaccount y Location ID

9.1 Obtén datos en BTP Cockpit

Ubica:

  • Subaccount ID
  • Región/host del endpoint asociado
  • Método de registro/credenciales (según tu configuración y políticas)

9.2 Registra SCC contra la subcuenta

En SCC UI:

  1. Subaccount → Add Subaccount
  2. Ingresa:
    • Región/host endpoint
    • Subaccount ID
    • Credenciales
    • Location ID (altamente recomendado para orden y escalabilidad)
  3. Guarda y valida estado Connected.

Tip de plataforma: Location ID te ayuda a operar múltiples conectores sin confusiones, separar dominios y reducir riesgo de “apunté el destino al conector equivocado”.

10) Publicar recursos: el corazón del asunto (allowlist)

SCC es “publica solo lo necesario”. Esto es Zero Trust aplicado a conectividad.

10.1 Define sistemas backend (On-Premise Systems)

En SCC UI:

  1. Cloud To On-Premise
  2. Agrega un sistema:
    • Tipo: HTTP, RFC (según necesidad)
    • Host/puerto interno real
    • Virtual host/virtual port (lo que verá BTP)
  3. Guarda.

Recomendación: usa virtual hosts que no colisionen con DNS real. Son nombres internos del túnel, no endpoints públicos.

10.2 Exponer rutas HTTP (Resources)

Define rutas específicas:

  • /sap/opu/odata/
  • /sap/bc/srt/
  • /sap/bc/rest/
  • endpoints REST internos concretos

Hard truth: exponer “/” completo es comprar riesgo con descuento… y sin garantía.

10.3 RFC (si aplica): alcance mínimo

Para RFC hacia ABAP:

  • Mantén el alcance controlado por diseño.
  • Evalúa si necesitas usuario técnico con permisos mínimos o avanzar a principal propagation según auditoría.

11) Destinations en BTP: que la conectividad sea usable

SCC solo habilita el puente. Para consumir, normalmente usarás Destinations.

11.1 Destination HTTP (ejemplo conceptual)

En BTP Cockpit → Destinations:

  • Name: S4_PRD_ODATA
  • Type: HTTP
  • URL: https://<virtualHost>:<virtualPort>
  • Proxy Type: OnPremise
  • Authentication: según tu backend (Basic, OAuth2, etc.)
  • Propiedad adicional (si aplica):
    • CloudConnectorLocationId

11.2 Destination RFC (si tu escenario lo usa)

  • Type: RFC
  • Proxy Type: OnPremise
  • Autenticación según tu estrategia.
  • Location ID si aplica.

La lógica es constante: Destination apunta al host/puerto virtual y OnPremise obliga a enrutar por SCC.

12) Pruebas: valida antes de “handover”

No hay nada más caro que descubrir un problema de red cuando ya hay un go-live en el calendario.

12.1 Checklist de prueba rápida

  • SCC conectado (Connected).
  • Backend alcanzable desde el host SCC (DNS + puerto).
  • Recurso permitido (allowlist) correctamente.
  • Destination creado y validado.
  • Prueba funcional desde el consumidor (CPI o app).

12.2 Smoke tests recomendados

  • OData: llama $metadata primero.
  • HTTP: endpoint pequeño y determinístico (status/health si existe).
  • Resiliencia: reinicia SCC y valida reconexión automática.

13) Seguridad y hardening: listo para auditoría

13.1 Acceso al UI

  • Acceso solo desde red admin/bastion.
  • Control de accesos por rol, rotación.
  • Registro de cambios (quién hizo qué y cuándo).

13.2 Certificados y TLS

  • Reemplaza certificado autogenerado del UI.
  • Mantén reloj sincronizado.
  • Revisa cadena y confianza con backend si hay TLS de por medio.

13.3 Allowlist estricta

  • Publica rutas específicas.
  • Versiona tu lista de recursos (documentación/export).
  • Revisión de cambios por proceso (CAB/Change Management) si aplica.

14) Operación: que no se convierta en “ese servidor que nadie toca”

14.1 Backups y recuperación

Plan simple:

  • Export de configuración.
  • Respaldo de keystore/certificados.
  • Procedimiento de restore probado (no solo escrito).

14.2 Actualizaciones

  • Mantén SCC en versión soportada.
  • Pasa por DEV/QA primero.
  • Ventana de mantenimiento para PRD.
  • Plan de rollback (snapshot o reinstalación + restore).

14.3 Monitoreo

  • Servicio arriba/abajo (Windows service / systemd).
  • CPU/RAM.
  • Errores recurrentes (TLS, DNS, proxy).
  • Latencia (si impacta integraciones).

15) Troubleshooting: los 10 problemas más comunes y cómo resolverlos

1) No conecta a la subcuenta

Causas: salida bloqueada, proxy mal configurado, DNS, inspección SSL.
Acción: valida outbound HTTPS, configura proxy, revisa certificados/inspección.

2) Destination falla, SCC conectado

Causas: allowlist insuficiente o Location ID incorrecto.
Acción: revisa rutas permitidas y propiedad de Location ID en Destination.

3) 401/403 desde backend

Causas: auth/roles insuficientes, método de auth incorrecto.
Acción: valida roles en ABAP/gateway interno y método de autenticación del destino.

4) Handshake TLS falla al backend

Causas: CA no confiable, cadena incompleta, TLS incompatible.
Acción: corrige cadena/certificados y confianza (truststore).

5) Funciona “desde SCC”, pero no desde CPI/app

Causas: destino distinto, proxy type incorrecto, consumer mal configurado.
Acción: estandariza nombres, verifica que el consumidor use el destino correcto.

6) UI no abre

Causas: firewall, puerto, red de acceso.
Acción: valida puerto, restringe acceso a admin y verifica servicio arriba.

7) Reconexiones frecuentes

Causas: proxy inestable, inspección SSL, NTP, red intermitente.
Acción: estabiliza salida, revisa logs y sincronización.

8) Rendimiento pobre

Causas: host subdimensionado, trazas activas, backend lento, latencia a región.
Acción: apaga trazas, dimensiona y revisa región/latencia.

9) Cambios no auditados

Causas: administración informal.
Acción: define proceso de solicitud/aprobación/ejecución y evidencia.

10) Dependencia de una sola persona

Causas: knowledge silo.
Acción: runbooks, accesos por rol y rotación. Continuidad operativa no es opcional.

16) Checklist final de salida a producción

  • Host dedicado, parchado y con NTP.
  • UI accesible solo desde red admin/bastion.
  • Certificado del UI alineado a política corporativa.
  • Proxy configurado (si aplica) y canal a BTP estable.
  • Subaccount conectado y Location ID definido (si aplica).
  • Allowlist mínima por ruta/servicio.
  • Destinations con ProxyType=OnPremise y Location ID correcto.
  • Pruebas técnicas y funcionales completadas.
  • Monitoreo y logs definidos.
  • Backup/restore documentado y probado.
  • Proceso de cambios acordado (quién pide, quién aprueba, quién ejecuta).

17) Mini-plan de ejecución (máxima palanca, mínimo teatro)

  1. Hoy: define arquitectura (ambientes, Location IDs, naming, lista de recursos) y valida red/proxy.
  2. Día 1: instala SCC en DEV, conecta subcuenta, publica recursos mínimos, crea destinos y prueba.
  3. Día 2: replica en QA, pruebas integradas con CPI/apps.
  4. Día 3: hardening + runbook + monitoreo + preparación PRD.
  5. Go-live: instalación PRD con ventana, smoke tests y handover formal.

Desafío para hoy: inventario de recursos a exponer (rutas/servicios) con dueños y justificación. Si no puedes defender por qué expones algo, no lo expongas. SCC es un puente, no un colador.

18) Dimensionamiento y alta disponibilidad: cuando el “funciona” no es suficiente

En entornos corporativos, SCC suele volverse un componente de plataforma. Eso significa que debe aguantar picos, cambios y auditorías con un nivel de servicio predecible.

18.1 Cómo dimensionar sin inventar números

El consumo real depende de:

  • Cantidad de llamadas por minuto desde CPI/apps.
  • Tamaño de payloads (OData con expansiones grandes = presión).
  • Latencia entre tu red y la región de BTP.
  • Cantidad de trazas activas.

Enfoque pragmático:

  1. Arranca con 2 vCPU y 8 GB RAM.
  2. Ejecuta pruebas de carga desde el consumidor (CPI/app) con volumen realista.
  3. Observa CPU/RAM y tiempos. Si sostienes >60–70% sostenido, ajusta antes de PRD.

18.2 Patrones de alta disponibilidad (sin vender humo)

SCC no es un balanceador mágico. La alta disponibilidad se diseña:

  • Dos SCC + continuidad en el consumidor: registras dos instancias en la subcuenta (normalmente con Location IDs distintos), duplicas destinos o preparas fallback en CPI/app.
  • HA a nivel infraestructura: failover de host/servicio (según tu plataforma) y runbook claro.

Recomendación práctica: si tu integración es crítica, invierte en redundancia. Lo barato es caro cuando la facturación depende de un túnel.

18.3 DR (Disaster Recovery) en dos pasos

  • Ten un SCC standby (o un host listo con el paquete instalado).
  • Conserva backups de configuración y certificados en un repositorio seguro.

19) Certificados y truststore: el 70% de los “no conecta” viene de aquí

La conectividad segura no es solo “TLS está encendido”. Es confianza de extremo a extremo.

19.1 Tres frentes a cubrir

  1. Certificado del UI de SCC (admin): para confianza y compliance.
  2. Certificado/CA del backend on-prem (S/4HANA, APIs internas): SCC debe confiar en la CA correcta.
  3. Inspección SSL corporativa (si existe): si el proxy re-firma tráfico, puede romper handshakes.

19.2 Regla de oro

Si cambias certificados en backend o proxy, agenda una validación de SCC. Los cambios “transparentes” rara vez lo son.

20) Ejemplo end-to-end: publicar un servicio OData de S/4HANA y consumirlo desde Integration Suite

20.1 En SCC: sistema y recurso

Sistema interno real:

  • Host: s4prd-internal.company.local
  • Puerto: 443

Mapeo virtual:

  • Virtual Host: vh-s4-prd
  • Virtual Port: 443

Allowlist:

  • /sap/opu/odata/sap/ZSALES_ORDER_SRV/

20.2 En BTP: Destination

  • Name: S4_PRD_ZSALES_ODATA
  • Type: HTTP
  • URL: https://vh-s4-prd:443
  • Proxy Type: OnPremise
  • Authentication: Basic en DEV/QA; evoluciona a OAuth2 o principal propagation si aplica
  • CloudConnectorLocationId=LOC_S4_PRD (si lo definiste)

20.3 En CPI: consumo

  1. Receiver HTTP/OData vía Destination.
  2. Smoke test con $metadata.
  3. Implementación funcional y manejo de errores:
    • 401/403: auth/roles
    • 404: ruta no permitida o mapeo incorrecto
    • 5xx: backend o red

21) Principal Propagation: cuándo vale la pena y cómo pensarlo

En muchos proyectos, el primer paso es un usuario técnico para entregar valor rápido. Perfecto. Pero cuando entra auditoría, llega la pregunta: “¿Quién ejecutó esta transacción?”

Ahí aparece principal propagation: transmitir identidad para trazabilidad en backend.

Cuándo lo necesitas:

  • Auditoría exige usuario final.
  • Segregación de funciones estricta.
  • No repudio y trazabilidad fuerte.

Cuándo no hacerlo aún:

  • No hay estrategia IAM clara.
  • Backends no están listos (certificados/trust/mapeos).
  • Prioridad es time-to-value con riesgo bajo.

Enfoque recomendado: baseline seguro (usuario técnico + allowlist mínima) y luego transición a principal propagation como épica planificada (no como “tarea rápida al final”).

22) Gobierno: cómo evitar que SCC sea un “shadow IT” elegante

Si SCC queda sin gobierno, terminará con recursos abiertos de más, destinos sin dueño y un Excel que “nadie sabe de quién es”.

22.1 RACI mínimo

  • Plataforma BTP: estándares y destinos base.
  • Equipo SCC/Infra: instalación, parches, certificados, monitoreo.
  • Integración: solicita exposiciones y valida funcionalmente.
  • Seguridad: políticas, revisión de cambios críticos y auditoría.

22.2 Plantilla de solicitud de exposición (cópiala y úsala)

  • Sistema objetivo (host interno):
  • Puerto:
  • Tipo (HTTP/RFC):
  • Rutas/recursos exactos:
  • Consumidor (CPI/app/otro):
  • Ambiente (DEV/QA/PRD):
  • Justificación de negocio:
  • Dueño funcional:
  • Dueño técnico:
  • Fecha de caducidad (sí, caducidad; así limpias basura):

Entradas recientes

Archivos

Categorías

Contactenos

Medellin, CO

[email protected]

www.globaldynamicssystems.com

Copyright 2014-17 Enigma Theme  Developed By Weblizar