✒️SAP BASIS / Utilización del Internet Communication Framework (ICF) Por Fernando Escola

Utilización del Internet Communication Framework (ICF)

El Internet Communication Framework (ICF)

El ICF es el componente de SAP que permite la comunicación entre sistemas a través de protocolos estándar como HTTP, HTTPS y SMTP. Funciona como un puente: recibe peticiones de clientes (como navegadores web), las transfiere a la aplicación ABAP correspondiente, recoge la respuesta y la envía de vuelta al usuario. A partir de la versión ABAP 7.40, esta capacidad es nativa del servidor, aunque el uso de HTTPS requiere una configuración adicional de SSL.

El Manejador de Peticiones HTTP

Detrás de cada servicio web en SAP existe un Manejador de Peticiones HTTP. Técnicamente, se trata de una clase ABAP que debe implementar la interfaz IF_HTTP_EXTENSION y el método HANDLE_REQUEST. Este programa es el encargado de procesar los datos recibidos (como los "query strings" de una URL) y generar la respuesta técnica que verá el cliente. SAP proporciona manejadores estándar, pero los desarrolladores pueden crear los propios mediante las transacciones SE24 o SE80.

Proceso de Interacción en el Servidor

Cuando llega una petición desde internet, el proceso sigue un orden estricto:

1. El ICM (Internet Communication Manager) recibe la petición y la guarda en una memoria compartida.

2. El Dispatcher asigna la tarea a un proceso de trabajo de diálogo disponible.

3. El Manejador de Tareas transfiere los datos al Controlador ICF.

4. El Gestor ICF (clase CL_HTTP_SERVER) crea un bloque de control para manejar la sesión.

5. Se realiza la Autenticación del usuario.

6. Se ejecuta el Manejador de Peticiones HTTP específico para procesar la lógica de negocio.

7. Finalmente, los resultados se envían de vuelta al ICM, que entrega la respuesta al navegador.

Mantenimiento y Propiedades de los Servicios

Un servicio ICF es, en esencia, el vínculo entre una URL y un manejador de peticiones. Estos servicios se organizan de forma jerárquica (en forma de árbol) y se gestionan íntegramente desde la transacción SICF.

Estados de Activación y Colores

En la transacción SICF, los servicios pueden estar en tres estados distintos, identificados por colores:

• Activo (Color Negro): El servicio funciona normalmente y puede recibir llamadas.

• Inactivo Explícito (Color Gris): El administrador ha desactivado el servicio manualmente.

• Inactivo Implícito (Color Azul): El servicio no funciona porque alguno de sus "nodos padre" en el árbol está desactivado (en gris). Si se activa el nodo superior, los servicios en azul recuperan su operatividad automáticamente.

Seguridad y Administración Masiva

Por motivos de seguridad, todos los servicios ICF están inactivos por defecto tras la instalación del sistema. Esto obliga al administrador a activar únicamente aquellos que sean necesarios, reduciendo la superficie de ataque. Además de la activación, es fundamental controlar el acceso mediante autorizaciones de usuario.

Para facilitar la gestión en sistemas grandes, existen reportes especializados:

• El reporte RS_ICF_SERV_ADMIN_TASKS permite generar listados de servicios (activos o inactivos) en formato CSV.

• El reporte RS_ICF_SERV_MASS_PROCESSING permite activar o desactivar servicios de forma masiva utilizando archivos de datos.

Las Propiedades y herencia de los servicios ICF

1. Propiedades y Herencia de los Servicios

Los servicios ICF se gestionan en la transacción SICF. Una de sus características principales es el Principio de Herencia: no es necesario configurar cada servicio individualmente; los nodos de nivel superior pueden transmitir sus parámetros a los niveles inferiores.

• Herencia: Los servicios subordinados adoptan las propiedades de sus padres a menos que se defina lo contrario. Es posible interrumpir esta lógica activando el indicador "No tener en cuenta parametrización heredada".

• Distribución de carga (Load Balancing): Se pueden asignar grupos de logon para que, al usar el SAP Web Dispatcher, las peticiones se redirijan solo a instancias específicas.

• Seguridad y Tiempo: Permite configurar autorizaciones específicas (objeto S_ICF), tiempos de espera de sesión (Session Timeout) y compresión de datos mediante gzip.

• Interfaz GUI: Ofrece la opción de convertir pantallas dynpro convencionales a un formato visualizable en navegadores web y habilitar modos de accesibilidad.

2. Configuración de Acceso (Datos Logon)

Existen diversos procedimientos para que una petición HTTP inicie sesión en el servidor ABAP. Por defecto, el sistema sigue una secuencia de verificación que incluye:

1. Campos HTTP y certificados SSL.

2. SAP Logon/Assertion Tickets.

3. Autenticación estándar (usuario y contraseña de SAP).

4. SAML, tokens OIDC y autenticación SPNEGO.

5. Datos de servicio (acceso anónimo).

El administrador puede elegir entre un procedimiento estándar, una secuencia de acceso alternativa o forzar el uso de datos de entrada específicos (mandante, usuario, contraseña e idioma). En este último caso, el usuario debe estar configurado como "usuario de servicio" en la transacción SU01.

3. Listas de Control, Errores y Gestión

La configuración detallada se divide en varias pestañas estratégicas:

• Listas de control: Aquí se definen los manejadores HTTP (clases ABAP) y el orden exacto en que deben ejecutarse.

• Páginas de Error: Permite personalizar las respuestas que recibe el usuario ante fallos de entrada (Error 401), errores de aplicación (Error 500), cierre de sesión o páginas no encontradas (Error 404).

• Servicios Públicos: El nodo /sap/public contiene servicios internos esenciales que funcionan sin credenciales bajo el usuario del sistema SAPSYS. Los clientes tienen prohibido crear servicios propios en esta ruta.

• Gestión y Seguridad: La pestaña de gestión registra quién creó o modificó el servicio. Para servicios sensibles, se recomienda el uso de virtual hosts y puertos dedicados para restringir el acceso.

4. Consideraciones sobre el Transporte de Servicios

Al mover servicios ICF entre sistemas (por ejemplo, de Desarrollo a Producción), hay reglas críticas de seguridad:

• Pérdida de Datos de Logon: Los datos de inicio de sesión (usuarios/contraseñas guardados) se eliminan automáticamente durante el transporte para evitar riesgos de seguridad y asegurar que el usuario exista en el sistema destino.

• Estado Inactivo: Los servicios transportados llegan inicialmente en estado inactivo. El administrador debe activarlos explícitamente en el sistema de destino tras verificar la configuración.

Los Alias del ICF

1. Concepto de Alias en el ICF

Un alias es básicamente un vínculo que conecta un servicio nuevo con otro ya existente. Esto permite llamar a un mismo servicio técnico a través de diferentes nombres o configuraciones. Existen dos tipos principales:

• Alias Internos: Se crean dentro de la transacción SICF al elegir la opción "Alias en un servicio existente". En lugar de programar un nuevo manejador de peticiones, se utiliza la pestaña Target para apuntar al servicio de destino. Esto es útil para ofrecer un mismo servicio con configuraciones alternativas (por ejemplo, distintos procedimientos de logon) sin tocar el original.

• Alias Externos: Se gestionan cambiando a la vista específica de "Alias Externos" en la SICF. Su propósito principal es permitir el uso de nombres significativos y no técnicos para los usuarios finales. A diferencia de los internos, los alias externos pueden incluir barras inclinadas ("/") en su nombre.

2. Restricciones y Buenas Prácticas

La documentación destaca algunas reglas importantes para el administrador del sistema:

• Namespace de SAP: Los clientes tienen prohibido crear alias internos dirigidos a servicios propios de SAP (aquellos que se encuentran bajo el nodo /sap/).

• Procedimientos Uniformes: A excepción de la nomenclatura y la vista desde donde se crean, tanto los alias internos como los externos se manejan de la misma forma en cuanto a su configuración técnica y transporte entre sistemas.

3. Utilidad para el Administrador

El uso de alias facilita la gestión de URLs más amigables y permite separar las configuraciones de seguridad. Por ejemplo, se puede tener un servicio base y crear un alias externo con un nombre sencillo para el usuario, aplicando en ese alias una restricción de acceso distinta a la del servicio original.

La grabadora del ICF

1. Propósito de la Grabadora del ICF

La grabadora permite identificar y corregir errores en las llamadas a servicios que fallaron mediante el registro de las peticiones HTTP. Su principal ventaja es que permite guardar estas peticiones en la base de datos (omitiendo las contraseñas por seguridad) para reproducir el problema tantas veces como sea necesario.

Esto facilita la búsqueda de la "causa raíz" a través de depuración (debugging) o el análisis de los traces de los procesos de trabajo, sin que el usuario final tenga que describir o repetir manualmente el error.

2. Proceso de Uso

Para utilizar la grabadora, se deben seguir estos pasos fundamentales dentro de la transacción SICF (o SICFRECORDER):

1. Activar la grabación: Se debe especificar la URL del servicio, la duración de la grabación y el tiempo que se guardarán los datos en la base de datos (Lifetime). Es recomendable activar la opción de "usuario dependiente" para grabar solo las peticiones de una persona específica.

2. Ejecutar el servicio: Se accede al servicio que se desea monitorear para que la herramienta capture el tráfico.

3. Desactivar la grabación: Es un paso crítico para evitar pérdidas de rendimiento innecesarias en el sistema una vez obtenido el registro.

4. Visualización y Procesamiento: Se analizan las peticiones grabadas para verificar correcciones o identificar fallos técnicos.

3. Acceso y Restricciones

Existen diferentes formas de acceder y controlar esta herramienta:

• Rutas de acceso: Se puede llegar a través del menú Mandante -> Recorder dentro de la actualización de servicios o directamente mediante la transacción SICFRECORDER.

• Seguridad y Control: El administrador puede deshabilitar el uso de la grabadora en todo el sistema desde el menú Pasar a -> Opciones.

• Autorizaciones: El acceso a los datos grabados está protegido por el objeto de autorización S_ICFREC, asegurando que solo personal autorizado pueda ver el contenido de las peticiones HTTP.

SAP GUI para HTML

1. Concepto y Funcionamiento

El SAP GUI para HTML (también conocido como WebGUI) es un servicio del ICF que mapea dinámicamente las pantallas de SAP a páginas HTML. Técnicamente, se identifica por la ruta del servicio /sap/bc/gui/sap/its/webgui.

• Acceso: Se puede iniciar ingresando la URL específica en el navegador o mediante la transacción WEBGUI desde el SAP GUI para Windows.

• Soporte Móvil: Es compatible con dispositivos táctiles como iPads y tabletas Android.

• Prerrequisitos: Para que funcione, deben estar activos el servicio ICF de WebGUI, el servicio de soporte /sap/bc/apc/sap/webgui_services y el SAP ITS (Internet Transaction Server). Además, la propiedad "GUI Interface" del servicio debe estar configurada en "Sí".

2. Limitaciones Técnicas

Aunque ofrece gran flexibilidad, el WebGUI tiene restricciones comparado con las versiones instalables (Windows/Java):

• No permite el control de servidores de automatización OLE.

• La integración con Microsoft Office es únicamente de visualización.

• Controles avanzados (como el Editor ABAP) pueden no estar disponibles.

• La navegación con el teclado es más limitada.

• Para verificar si una transacción es compatible, se debe revisar la "Capacidad GUI" en la transacción SE93.

3. Configuración y Rendimiento

El sistema permite un alto grado de personalización a nivel de usuario:

• Opciones de Usuario: Se accede mediante el menú "Parametrizaciones" y permite ajustar el diseño visual, notificaciones y opciones de teclado. Estos ajustes se guardan en la base de datos del sistema por cada usuario.

• Tecnología APC: Utiliza ABAP Push Channels (APC) para la comunicación en tiempo real entre el navegador y el servidor.

• Diagnóstico FESR: Para solucionar problemas de rendimiento, ofrece el Log de Frontend Sub-Records (FESR), que registra datos detallados sobre la duración de la comunicación entre el cliente y el servidor. Se habilita en la ruta Herramientas -> Rendimiento.

4. Compatibilidad de Navegadores

El SAP GUI para HTML es compatible con los principales navegadores modernos bajo diversos sistemas operativos:

• Microsoft Edge (basado en Chromium).

• Google Chrome (Windows, macOS, Android).

• Mozilla Firefox (Windows, Linux, macOS).

• Safari (macOS, iOS, iPadOS).

El SAP Internet Transaction Server (SAP ITS)

1. Arquitectura y Conceptos Generales

El SAP ITS está completamente integrado en la infraestructura del servidor de aplicación ABAP (AS ABAP). Su función principal es permitir la visualización de aplicaciones SAP a través de un navegador web.

• Acceso: Se realiza mediante el proceso ICM (Internet Communication Manager).

• Implementación: Se basa en servicios dentro del ICF (Internet Communication Framework).

• Componentes Clave: Navegador Web → ICM → ICF → Funciones del SAP ITS (Plantillas HTML/CSS) → Pantalla ABAP.

• Modelos Soportados: Soporta tanto el SAP GUI para HTML como los IAC (Internet Application Components).

2. Requisitos y Configuración

El SAP ITS viene instalado por defecto con el Kernel de SAP (versión 6.40 y superiores). Para su funcionamiento se deben cumplir:

• ICM activo: Configurado para protocolos HTTP/HTTPS.

• Parámetro de Perfil: itsp/enable debe estar configurado en 1.

• Servicios SICF: Los servicios correspondientes deben estar activos en la transacción SICF, asegurando que la propiedad "Conexión GUI" esté en "Sí" para el servicio principal y en "No especificado" para los recursos MIME (/sap/public/bc/its/mimes).

3. Parámetros de Perfil Relevantes

• itsp/enable: Permite activar o desactivar el ITS. Es útil para restringir el acceso web en instancias específicas (por ejemplo, en servidores de procesos de fondo/batch) para ahorrar recursos de CPU.

• em/global_area_MB: Define la memoria utilizada por el kernel para gestionar sesiones y plantillas HTML. El consumo depende del número de sesiones, el uso de diferentes idiomas y los tipos de navegadores utilizados.

4. Desarrollo y Administración

• Creación de Servicios: Se utiliza el Web Application Builder dentro de la transacción SE80 (Internet Service).

• Publicación: Por defecto se publican en el sitio integrado. Tras una actualización (upgrade), es vital verificar si los objetos requieren ser publicados nuevamente (Notas SAP 790727 y 2208029).

• Transacciones de Gestión:

  • RZ10/RZ11: Para configurar y consultar parámetros de perfil.

  • SICF: Para mantener y configurar los servicios individuales.

5. Monitoreo del Sistema

El administrador dispone de herramientas integradas para supervisar el rendimiento y estado del ITS:

• SITSPMON: Es la herramienta principal. Proporciona un resumen de:

  • Estatus del sistema y opciones de parámetros.

  • Consumo de memoria y estadísticas.

  • Análisis de caché de plantillas HTML y objetos MIME.

  • Bloqueos (Mutex Locks).

• Otras herramientas: Transacciones SM21 (Logs), ST22 (Dumps), SMICM (Estado del ICM) y archivos de traza dev_w*. También se puede activar el tracing específico para ICF/WebGUI en la SM50.