✒️SAP BASIS Internet Communication Framework

Internet Communication Framework

El ICF provee un entorno para manejo de solicitudes web dentro del work process ABAP de un sistema SAP. Cuando en la implementación de SAP queremos usar apliaciones web basadas en Web Dynpro, BSPs o el ITS integrado para conectar el sistema SAP a internet será nuestra tarea crear las conexiones entre las llamadas URLs y los servicios y programas del sistema SAP.

1 - Clasificación del ICF

Permite establecer la comunicación entre diferentes sistemas sobre internet utilizando protocolos estándar (como HTTP y SMTP). No se requiren librerías de programas SAP adicionales para esto excepto para HTTPS que se requiere la librería criptográfica de SAP (SAPCRYPTOLIB).

El ICF hace posible generar una respuesta a una solicitude de una aplicación. Una solicitud HTTP es enviada desde un cliente, como un navegador web al servidor. El ICF reenvía la solicitud a una aplicación. Los datos son procesados en la aplicación, la cual devuelve luego (usando nuevamente el ICF) al cliente como respuesta. Los datos de la respuesta son visualziados en el navegador.

Una solicitud HTTP(S) es procesada de la siguiente manera:

1 > Solicitud es enviada desde el navegador Web del usuario al ICM usando el protocolo HTTP. ICM usa la URL recibida para decidir si la aplicación que se está llamand oestá implementada en el stack ABAP o JAVA del servidor de Aplicación Web de SAP.

En este caso, usaremos una aplicación ABAP.

2 > ICM almacena los datos recibidos en un mermoy pipe (memoria compartida) e informa al dispatcher ABAP.

3 > El dispatcher ABAP coloca una solicitud del ICM en la cola del dispatcher (queue), crea un nuevo contexto, y selecciona un work process libre para el procesamiento

4 > Task handler en el work process lee los datos desde el memory pipe y los transfiere al controlador ICF, el cual es implementado usando el módulo de función HTTP_DISPATCH_REQUEST.

5 > El controlador ICF transfiere la solicitud al ICF manager, el cual es implementado usando la clase ABAP CL_HTTP_SERVER. El controlador ICF, crea un bloque de control y lo llena con los datos de la solicitud hTTP.

6 > El cliente es autenticado mediante alguno de los métodos posibles.

7 > HTTP request handler determinado previamente es llamado (procesa los datos solicitados, llama a apps adicionales, accede al objeto de la respuesta, etc). Una vez que finaliza devuelve el control al controlador ICF.

8 > Task handler escribe la respuesta en el memory pipe y avisa al ICM que el procesamiento de la solicitud ha finalizado.

9 > ICM devuelve la respuesta al navegador Web del cliente.

2 - Propiedades y mantenimiento de los servicios ICF

Punto de vista técnico: detrás de un HTTP request handler hay una clase ABAP. Esta clase implementa la interface IF_HTTP_EXTENSION y el método HANDLE_REQUEST. SAP entrega clases de este tipo pero los clientes pueden crear su propia clase (SE24 + SE80).

La conexión de una URL particular con un HTTP request handler es la tarea de los servicios ICF.

Un servicio ICF por lo tanto crea una conexión entre una URL a la cual una solicitud HTTP es enviada y los objetos de desarrollo que procesarán la solicitud.

Vista de todos los servicios a través de la transacción SICF.

3 - Concepto de activación

Los servicios de ICF pueden estar activos o no, lo cual se muestra utilizando diferentes colores en la transacción SICF.

Activo = Negro
Inactivo - Gris = explícitamente desactivado (expresa clara y determinadamente una cosa)
Inactivo - Azul = implícitamente desactivado (sin que esta lo exprese o manifieste de forma directa)

Para los servicios desactivados implícitamente, hay siempre un servicio en algún nivel superior en el árbol de ICF que está explícitamente desactivado. Si activamos el servicio (que está en gris) todos los servicios que estén implícitamente desactivados en el nivel inmediato inferior, también son activados.

Si llamamos a un servicio inactivo, un mensaje aparece informando que el acceso a la página está bloqueado. Los servicios ICF activados representan cierto risgo de seguridad ya que es posible que sean accedidos directamente usando HTTP(S) o SMTP desde la intranet o internet (dependiendo la configuración de red).

Por lo tanto, se DEBE restringir el acceso con medidas apropiadas, tal como solo la activación de servicios requeridos y asignar las auth correspondientes a los usuarios.

4 - Propiedades e Inherencia

Si seleccionamos un servicio desde SICF, las siguientes configuraciones pueden realizarse:

Datos de Servicio/Procedimiento de Logon:

*Varios procedimientos de logon están disponibles para el acceso de una solicitud HTTP al SAP Web AS. Se puede configurar esto para cada nodo de servicio de forma individual.

-Si seleccionamos Alternative Logon Order, podemos seleccionar cualquier procedimiento de logon, en una nueva solapa de Logon Order y cambiar el orden de las verificaciones.

-Si seleccionamos "Logon data required" solo los detalles almacenados en el servicio bajo Anonymus Logon data son usados para la verificación

-Si seleccionamos Client Cert. (SSL) Required, el acceso es posible solo usando un certificado de cliente X.509.

Para los procedimientos Standard y Alternative Order, también podemos usar la opción ALL logons para definir si el sistema deberá ejecutar las verificaciones en la secuencia relevante hasta que uno de los procedimientos de logon es exitoso o de lo contrario deberia retornar un mensaje negativo luego de que el logon falle.

DATOS DE SERVICIO/ DATOS DE LOGON ANÓNIMO:

Los detalles almacenados en Client, user pass y lenguage son verificados si seleccionamos logon data required como procedimiento de logon para un servicio. Utilizar solo usuarios catalogados como de servicio.

DATOS DE SERVICIO/OPCIONES DE SERVICIO

Podemos usar el campo server group para ingresar un grupo de logon (SMLG).

5 - Monitoreo

ICF Recorder permite a los dessarolladores y administradores identificar y si es necesario corregir posibles causas de errores mediante el registro de solicitudes HTTP para aquellos intentos de llamados fallidos.

Podemos usarlo para almacenar solicitudes registradas en la base de datos del sistema. Esto facilita la investigación ya que en la mayoría de los casos, una descripción del problema no es necesaria para reproducir el error.

La solicitud con el problema puede ser reprocesada varias veces mediante el uso de la entrada en la base de datos, para aislar la causa usando el debuggin o un archivo de traza del work process que lo ejecuta.

Para utilizar ICF recorder, desde SICF --> Edit --> Recorder --> Activate recording/deactivate ---> Display recording.

SICFRECORDER para evaluar los registros.