✒️SAP BASIS / Configuración del Internet Communication Manager (ICM) Por Mayra Herrera Naranjo

Las características importantes son:

• Compatibilidad con protocolos web estándar HTTP, HTTPS, WebDAV, SOAP y SMTP
• Visualización de formatos web estándar como HTML, XML, OData y XSLT
• Integración completa en el entorno SAP

El servidor de aplicaciones ABAP puede actuar como servidor web (rol de servidor) como un cliente web (rol de cliente). El rol de servidor puede aceptar y procesoar peticiones HTTP(s) de cualquier cliente web y enviar una respuesta HTTP(s. Dentro de un proceso de trabajo, el internet communication framewrok (ICF) proporciona el entorno para manejar peticiones HTTP(s), el ICF es el puente entre el kernel C del sistema SAP y el programa de aplicación creado en ABAP.

Los procesos de trabajo pueden generar contenido compatible con la web para que sea reenviado a un navegador web con el ICM, como usar para esto Web Dynpro. El ICM es un proceso separado que es iniciado y monitoreado por el dispatcher ABAP, su tarea es asegurar que el sistema SAP pueda comunicarse con el mundo exterior. En el rol de servidor procesa peticiones de internet que llegan con URL que contengan la combinación de servidor/puerto que el ICM esta escuchando, luego el ICM llama al manejador local apropiado, utiliza threads (hilos) para procesar la carga de trabajo creada de manera paralela. Sus componentes son:

• Thread control: Acepta peticiones TCP/IP entrantes y crea o levanta un worker thread desde el pool de threads para procesar la petición
• Worker threads: Maneja peticiones y respuestas para una conexión, contiene un manejador de I/O para la entrada y salida de red, plug-ins para los diferentes protocolos soportados
• Watchdog: Cuando un worker threads espera un respuesta, si ocurre un timeout el watchdog toma la tarea de esperar la respuesta.
• Signal Handler: Procesa señales que son enviadas desde el sistema operativo u otro proceso
• Connection information: Tabla con información para cada conexión de red existente
• Memory Pipes: Objetos de comunicación basados en memoria permiten la transferencia de datos entre el ICM y los procesos de trabajo ABAP

Las peticiones del ICM deben esperar en la cola de diálogo del dispatcher ABAP. El ICM utiliza plug-ins para implementar los diferentes protocolos de comunicación, una vez instalados el servidor de aplicaciones ABAP se pueden usar los protocolos HTTP, HTTPs, SMTP.

El internet server cache (ISC) almacena objetos HTTP(s) antes de que sean enviados al navegador web y la petición se puede hacer directo del ISC siempre que el tiempo de caducidad no haya expirado, esto evita la derivación del proceso de trabajo ABAP.

• Jerarquía de dos niveles: Se utilizan la alta velocidad de memoria principal (cahce de memoria) como de la capacidad de almacenamiento de discos duros (cache de discos)
• Alamacenamiento en cache dinámico: Almacena proxies HTTP y contenido dinámico como JSP o BSP y ofrece caching estático y dinámico
• Almacenamiento en caché activo: Control total para asegurar que los objetos en el caché esten actualizados
• Almacenamiento en caché UFO: Las peticiones inválidas que conducen a situaciones de error en el servidor de aplicación o base de datos son directamente rechazadas
• Almacenamiento en caché dependiente del navegador: El desarrollador BSP define si su aplicación depende de tipo de navegador, si esta activo el ISC usa los datos en el caché para peticiones del mismo tipo de navegador. Se configura utilizando el párametro de perfil icm/HTTP/server_cache

El parámetro rdisp/start_icman controla si un proceso ICM tambipen se inicia cuando se inicia el servidor de aplicaciones. Se configura el ICM como icm/server_port_ que determina el puerto utilizado para cada protocolo, así como otros atributos del protocolo.

Con la transacción SM51 se puede ver que servidores se están ekecutando con un ICM. El monitor ICM se puede usar para ver información más detallada, terminar el ICM con una terminación suave o dura. El dispatcher inicial luego un nuevo proceso ICM, configurar el nivel de trace(0 a 3), evaluar los archivos trace, el archivo de trace del ICM o el registro de seguridad del ICM.

Para consultar los parámetros se puede consultar el ICM Monitor (SMICM), transacción RZ11 o la documentación en línea de SAP. Otras funcionalidades del monitor:

• Visualizar estadísticas: Cuantas peticiones ha procesado el ICM, tiempo de procesamiento
• Monitorear y resetear el cache del servidor ICM: el caché almacena objetos HTTP antes de ser enviados al cliente y si se soclicita de nuevo puede ser enviado desde el cache
• Modo de mantenimiento: El ICM se desconecta del servidor de mensajes ABAP y no esta disponible para peticiones web, el ICM solo procesa peticiones restantes

También se puede acceder a nivel sistema operativo desde icman y puede generar peticiones para simular la carga de trabajo normal del sistema o la interfaz de administración web desde el navegador web, SAP MC o el SAP MMC

El protocolo Secure Sockets Layer( (SSL) asegura las conexiones HTTP hacia y desde el servidor de aplicación ABAPm al usarlo los datos que se transfieren entre ambas partes se cifran. Utiliza tecnología de clave pública para la protección por lo que como requisito previo el servidor debe poseer un par de clave pública y privada y un certificado de clave pública. Debe tener un par de claves y un certificado para identificarse como componente del servidor y otro par de claves y certificado en caso de identificarse como componente cliente.

Estas claves se almacenan en los personal security environments (PSEs) del servidor: el SSL server PSE y el SSL client PSE. Los pasos para configurar el SSL en un servidor de aplicación ABAP

• Establecer los parámetros de perfil para SSL (RZ10)
• Crear y mantener el certificado SSL del servidor en el PSE (STRUST)
• Reiniciar el ICM (SMICM)
• Realizar cambios de configuraciones específicas en aplicaciones y escenarios específicos y realizar pruebas de conexión (aplicación o escenario)