Montar ARC-1 en BTP con Principal Propagation
Sacar el servidor MCP del portátil y llevarlo a BTP, para que el agente actúe con tu usuario SAP real, con permisos acotados y auditoría de verdad. La arquitectura, las tres puertas de permisos y los pasos.
Cuando montas un servidor MCP en tu portátil funciona, sí. Pero las credenciales están en tu máquina, SAP ve un único usuario para todo y nadie puede auditar después qué hizo el agente. Esta guía va de mover esa pieza a donde debe estar: una instancia central en BTP, con identidad real y permisos que alguien pueda revisar sin ponerse pálido.
La idea en una frase
No es «otra forma de instalar lo mismo». Es cambiar el sitio donde vive el acceso: de muchos servidores locales sin control a un endpoint MCP gestionado por sistema SAP, con un único lugar donde se define la política.
Los dos saltos de autenticación
Casi todas las discusiones sobre MCP mezclan dos preguntas distintas: quién puede hablar con el servidor, y como qué usuario habla el servidor con SAP. ARC-1 las separa, y por eso la arquitectura se entiende:
Cliente de IA
Claude, Cursor, Copilot para Eclipse, MCP Inspector…
Salto 1 · XSUAA
OAuth. Decide quién puede llamar al endpoint /mcp
ARC-1 en Cloud Foundry
Una instancia por sistema SAP, con su configuración
Salto 2 · Destination + Cloud Connector
Decide como qué usuario se entra en SAP
Tu sistema ABAP
Con Principal Propagation, ve tu usuario real
Por qué Principal Propagation lo cambia todo
Sin ella, SAP ve un usuario técnico compartido y el log dice «lo hizo ARC1_TECH». Con ella, ARC-1 recibe tu token, lo pasa al Destination Service y BTP más Cloud Connector propagan tu identidad al backend: SAP ve tu usuario, aplica TUS autorizaciones y el registro dice tu nombre. Eso es la diferencia entre «confía en esta cuenta de servicio» y «puedo decirte quién hizo qué».
Las tres puertas
Esto es lo más importante de toda la guía. Una petición no pasa por un interruptor, pasa por tres, y tienen que abrirse los tres. El permiso efectivo es una Y lógica, no una O.
| Puerta | Quién la define | Qué controla |
|---|---|---|
| 1. Techo del servidor | Variables de entorno de la instancia | Lo máximo que esta instancia de ARC-1 puede llegar a hacer, pase quien pase |
| 2. Permiso del usuario | Role collections de XSUAA | Qué puede hacer ESE usuario dentro de ARC-1: leer, escribir, datos, SQL, transportes, git, admin |
| 3. Autorización SAP | El propio sistema | S_DEVELOP, autorizaciones de paquete y de transporte, restricciones de ABAP Cloud |
Lo que esto significa en la práctica
Si la instancia tiene SAP_ALLOW_WRITES=false, un usuario con el rol ARC-1 Developer sigue sin poder escribir. Si SAP_ALLOW_FREE_SQL=false, alguien con permiso de SQL tampoco puede lanzar consultas libres. Y aunque las dos capas de ARC-1 digan que sí, SAP puede seguir diciendo que no. Las banderas del servidor y los roles de BTP no son lo mismo, y conviene explicarlo bien la primera vez que alguien pregunte.
Lo que necesitas tener antes
Aquí ya no basta con tu portátil: hace falta gente de BTP y de Basis en la conversación.
Una subcuenta de BTP con Cloud Foundry habilitado
Y permisos para desplegar aplicaciones y crear instancias de servicio.
Los servicios de BTP: XSUAA, Destination y Connectivity
El despliegue MTA de ARC-1 los declara, pero tienen que estar disponibles en tu entitlement.
Cloud Connector configurado
Solo si vas contra on-premise o private cloud. Para BTP ABAP Environment no hace falta: se usa service key.
Principal Propagation preparada en Cloud Connector
Es la parte que suele llevar más tiempo, porque implica confianza de certificados y mapeo de usuarios. Involucra a Basis pronto.
El CLI de Cloud Foundry y Node instalados
Vas a usar cf set-env, cf restage y los scripts npm del proyecto.
Un sistema de desarrollo como primer destino
La recomendación es una instancia por sistema SAP: DEV con escrituras acotadas, PROD en solo lectura.
El despliegue, paso a paso
El camino recomendado es el despliegue MTA, porque describe en un único sitio la aplicación y sus enlaces a servicios. Es el más reproducible cuando dentro de seis meses alguien tenga que repetirlo.
Despliega ARC-1 como aplicación MTA
El proyecto incluye un mta.yaml con la aplicación de Cloud Foundry y los servicios necesarios: XSUAA, Destination y Connectivity. Con dos comandos lo tienes arriba.
terminalnpm run btp:build npm run btp:deploy # o los dos de una vez npm run btp:build-deployOjo: Hay otras dos vías —imagen Docker en Cloud Foundry o buildpack de Node con cf push— pero solo merecen la pena si tienes un motivo concreto, como desplegar una imagen fijada desde un registro interno.
Configura las dos destinations
Aquí está el truco que a mucha gente se le escapa: hacen falta dos destinos, no uno. Al arrancar no existe todavía ningún token de usuario, así que ARC-1 usa un destino con BasicAuth para el sondeo de capacidades y el calentamiento de caché. Las peticiones autenticadas de cada usuario van por el destino de Principal Propagation.
- Destino compartido
- SAP_BTP_DESTINATION = SAP_ECC_DEV
- Destino por usuario
- SAP_BTP_PP_DESTINATION = SAP_ECC_DEV_PP
- Tipo del primero
- BasicAuth
- Tipo del segundo
- PrincipalPropagation
Activa la autenticación y la propagación
Este bloque convierte a ARC-1 en un servidor MCP remoto con autenticación XSUAA y propagación de identidad activa.
variables de entornoSAP_TRANSPORT=http-streamable SAP_XSUAA_AUTH=true SAP_PP_ENABLED=true SAP_PP_STRICT=trueOjo: SAP_PP_STRICT=true es la que yo no me saltaría en productivo: hace que un fallo de Principal Propagation cante en vez de caer en silencio al usuario compartido. Un fallo silencioso aquí es exactamente el escenario que no quieres explicar luego en una auditoría.
Pon el techo del servidor lo más bajo posible
Arranca en modo conservador. Siempre es más fácil abrir después que cerrar tras un susto.
variables de entornoSAP_ALLOW_WRITES=false SAP_ALLOW_DATA_PREVIEW=false SAP_ALLOW_FREE_SQL=false SAP_ALLOW_TRANSPORT_WRITES=false SAP_ALLOW_GIT_WRITES=false SAP_ALLOWED_PACKAGES='$TMP'Verifica lo aburrido antes de tocar nada más
Dos llamadas y una lectura de logs. Los logs deben mostrar qué modos de autenticación están activos: XSUAA por el lado del cliente MCP y Principal Propagation por el lado de SAP.
terminalcurl https://arc1-ecc-dev.cfapps.eu10.hana.ondemand.com/health curl https://arc1-ecc-dev.cfapps.eu10.hana.ondemand.com/.well-known/oauth-authorization-serverOjo: Después, una llamada MCP de solo lectura. Si eso funciona y los logs dicen lo que esperabas, ya tienes la base. Si no, no sigas abriendo permisos: el problema está aquí.
Conecta a los clientes
Con ARC-1 central, la configuración del desarrollador se reduce a una URL. Nadie guarda credenciales de SAP en su cliente: eso es media batalla ganada.
configuración del cliente MCP{ "mcpServers": { "arc1-ecc-dev": { "url": "https://arc1-ecc-dev.cfapps.eu10.hana.ondemand.com/mcp" } } }Ojo: ARC-1 expone metadatos OAuth y hace de intermediario con XSUAA, así que los clientes con MCP remoto y descubrimiento OAuth pueden seguir el flujo: Claude, Cursor, clientes tipo VS Code o MCP Inspector.
Abre permisos por escalones, nunca de golpe
Solo cuando lo anterior esté verificado. En un sistema de desarrollo puedes abrir escrituras selectivas; en productivo, lo razonable es dejarlo en solo lectura.
terminalcf set-env arc1-ecc-dev SAP_ALLOW_WRITES true cf set-env arc1-ecc-dev SAP_ALLOW_TRANSPORT_WRITES true cf set-env arc1-ecc-dev SAP_ALLOWED_PACKAGES 'Z*,$TMP' cf restage arc1-ecc-dev
El orden de apertura que yo seguiría
Menos espectacular que una demo donde la IA lo escribe todo desde el minuto uno, pero mucho más parecido a cómo se introduce esto en una empresa de verdad:
Solo lectura
Leer código, buscar objetos, where-used, ATC
Escrituras en $TMP
Objetos locales, sin transporte
Paquetes concretos
SAP_ALLOWED_PACKAGES con tu convención
Transportes
Solo cuando el resto lleve tiempo funcionando
Los roles de XSUAA
ARC-1 trae ámbitos que se agrupan en colecciones de roles. Asígnalos como asignarías cualquier otro rol: por necesidad, no por comodidad.
| Colección de roles | Para quién |
|---|---|
| ARC-1 Viewer | Leer código y analizar. El punto de partida para todo el mundo |
| ARC-1 Developer | Quien va a dejar que el agente escriba y active |
| ARC-1 Developer + Data | Añade vista previa de datos. Piénsalo dos veces si hay datos personales |
| ARC-1 Developer + SQL | Añade consultas libres. El más delicado de todos |
| ARC-1 Admin | Administración de la propia instancia |
¿Y si no necesito identidad por usuario?
No todos los escenarios la necesitan. Para automatismos, chequeos programados o agentes de proceso muy acotados, un usuario técnico está bien. Lo único que hay que tener claro es el intercambio: ARC-1 sabrá qué token le llamó, pero SAP verá al usuario técnico. Con Principal Propagation, SAP ve a la persona. Para desarrollo humano, esa segunda opción es la que aguanta una auditoría.
Un límite honesto de esta guía
Esto explica la arquitectura y las decisiones, no sustituye a la documentación de despliegue. Los detalles concretos dependen mucho de tu paisaje: versión de Cloud Connector, confianza de certificados, mapeo de usuarios, región de la subcuenta. Para los comandos exactos, la referencia es la documentación de ARC-1; para el mapeo de identidades, tu equipo de Basis.