SAP IDoc
Requiere el SAP NW RFC SDK instalado en el servidor — ver SDK de SAP.
El camino asíncrono, y el único en que es SAP quien llama al CMS. El microservicio
cms-idoc-connector registra un RFC Server (node-rfc, clase Server) en el gateway SAP y
recibe los IDocs enviados. Ver SAP para la visión general.
Cómo funciona
El connector es un proceso separado de cms-sap-connector porque un RFC Server es un listener de
larga duración registrado en el gateway, no una llamada request/response — una falla o reinicio del
listener no puede afectar al client RFC ni a la API.
Como cualquier recepción pasiva, es orientado a evento: no hay programación, no hay cron. El IDoc llega cuando SAP lo envía.
Listeners
cms-apienvía la lista completa de listeners deseados (POST /idoc/listeners/sync) — una entrada por Conexión Externa de tipo SAP IDoc que tenga alguna Recolección activa usándola.- El connector reconcilia (inicia, detiene, reinicia registros) y devuelve el estado de cada uno.
GET /idoc/listeners/statusconsulta el estado actual sin esperar el próximo sync.
Un único Program ID se mantiene por Conexión Externa. Varias Recolecciones — tipos de IDoc
distintos — comparten el mismo listener; es cms-api quien decide a cuáles reenviar cada IDoc
recibido.
Configurar la conexión
En la Conexión Externa SAP, el bloque de IDoc pide dos cosas de naturalezas distintas:
| Bloque | Campos | Para qué |
|---|---|---|
| Registro en el gateway | Gateway host, gateway service, Program ID, SAProuter, trace | Es lo que SAP va a buscar |
| Logon de client | Mandante, usuario, contraseña, idioma, host/instancia o message server | Resolver los metadatos del function module |
El logon de client parece redundante — el registro en sí no pide usuario ni contraseña. Pero el
Server de node-rfc no registra nada en el gateway sin antes abrir esa conexión, que usa para
resolver la interfaz de IDOC_INBOUND_ASYNCHRONOUS. Sin ella, el listener no levanta.
Los dos botones de prueba
| Botón | Qué hace | Costo |
|---|---|---|
| Probar Login | Abre y cierra la conexión de logon. No registra nada en el gateway | Barato, y nunca deja conexión atascada en el SMGW |
| Probar Registro en el Gateway | Registro de vida corta: levanta y baja de inmediato | Exige SM59/WE21/ACL ya configurados del lado de SAP |
Use el primero para validar credencial y alcance de red; el segundo solo después de que Basis haya hecho su parte.
Qué necesita existir del lado de SAP
Esta es la parte que suele trabar una implantación, y no se hace en el CMS. Lleve esta lista a Basis:
- Destino RFC de tipo T (Registrado) en SM59, con el Program ID elegido.
- Puerto WE21 (Transactional RFC) apuntando a ese destino.
- Perfil de socio WE20 (inbound) para el tipo de mensaje, con código de proceso ligado a
IDOC_INBOUND_ASYNCHRONOUS. - Liberación de registro en el gateway:
gw/reg_no_conn_infoy las ACLssecinfo/reginfopara el Program ID y el host de este servicio. - Confirmación de la estructura de la interfaz (
EDI_DC40/EDI_DD40), que varía entre ECC y S/4HANA.
El ítem 4 es el más olvidado. Sin la ACL del gateway, el registro falla con un error de seguridad que no menciona ninguna ACL — y el tiempo se pierde buscando en el lugar equivocado.
Recolección — SAP_IDOC
En la Recolección se define para cuáles IDocs de esta conexión sirve esta interfaz. Los filtros se aplican sobre el registro de control (EDIDC):
| Filtro | Coincide contra | Vacío significa |
|---|---|---|
| Tipo de IDoc | IDOCTYP (ej.: ORDERS05) | Cualquier tipo |
| Tipo de mensaje | MESTYP (ej.: ORDERS) | Cualquier mensaje |
| Socio | El socio emisor | Cualquier socio |
Varias Recolecciones pueden compartir la misma conexión, cada una con su recorte. Un IDoc que coincide con más de un filtro se reenvía a todas las Recolecciones que lo aceptan — lo que permite, por ejemplo, una Recolección específica de un socio y otra genérica de auditoría.
El formato del mensaje
Cada IDoc llega agrupado por DOCNUM, con el registro de control (EDIDC) y los segmentos de datos (EDIDD). El Transformador de la Recolección recibe ese conjunto entero y decide qué se vuelve mensaje — típicamente aplanando los segmentos que interesan.
Modo de desarrollo
Sin SAP_IDOC_CLIENT=real, el connector arranca con un servidor fake: nunca registra nada en el
gateway y acepta POST /idoc/simulate para inyectar un IDoc de prueba por el mismo camino que
seguiría un IDoc real. Así se prueba la configuración de Recolección, el Transformador y el reenvío
sin acceso a un SAP.
La instalación del SDK es la misma del RFC client, con
SAP_IDOC_CLIENT=real en lugar de SAP_RFC_CLIENT.
Monitorear
Configure la alerta Conexión Perdida para las Recolecciones de IDoc. Como la recepción es pasiva, un listener caído es silencioso: no genera error, simplemente dejan de llegar IDocs. Sin la alerta, la parada solo aparece cuando alguien echa de menos el dato. Ver Alertas.
El estado del listener también aparece en el Panel de Aplicaciones, cuando la Aplicación usa keep-alive de tipo SAP IDoc.