✒️SAP BASIS / Internet Communication Framework Por Rodrigo María García

El Internet Communication Framework (ICF) provee un entorno para el manejo de solicitudes web dentro del work process ABAP de un sistema SAP.

Clasificación del ICF

El ICF permite establecer la comunicación entre diferentes sistemas sobre internet usando protocolos estándar (tales como HTTP y SMTP). Solo se requiere librería criptográfica de SAP para el protocolo HTTPS (SAPCRYPTOLIB).

El ICF hace posible generar una respuesta a una solicitud de una aplicación. Una solicitud HTTP es enviada desde un cliente, tal 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 algo, usando también el ICF. Los datos de la respuesta son visualizados en el navegador.

La lógica de la aplicación que es llamada a través de una solicitud HTTP desde la intranet o internet es implementada por el HTTP request handler en cada caso. Un HTTP request handler es un programa que es identificado usando una URL, y el cual recibe solicitudes HTTP que usan esta URL. La tarea del HTTP request handler es recibir los datos enviados por la solicitud, para realizar una cantidad de procesos específicos del handler y generar una respuesta a esta solicitud HTTP. (El más común es es BPS)

Si una solicitud HTTP es recibida por el ICM que será procesada en un work process, el task handler toma control y luego inicia el cotrolador ICF.

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

• La solicitud es enviada desde un navegador Web del usuario al ICM usando el protocolo HTTP. El ICM usa la URL recibida para decidir si la aplicación que se está llamando está implementada en el stack ABAP o JAVA del Web SAP AS.
• El ICM almacena los datos recibidos en la memoria compartida e informa al dispatcher ABAP.
• El dispatcher ABAP coloca la solicitud del ICM en la cola del dispatcher, crea un nuevo contexto y selecciona un work process libre para el procesamiento.
• El task handler en el work process lee los datos desde la memoria compartida y los transfiere al controlador ICF mediante el módulo de función HTTP_DISPATCH_REQUEST.
• 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.
• El cliente es autenticado mediante alguno de los métodos posibles.
• El HTTP request handler determinado previamente es llamado y cuando finaliza, devuelve el control al controlador IFC.
• El task handler escribe la respuesta en la memoria compartida y avisa al ICM que el procesamiento de la solicitud ha finalizado.
• El ICM devuelve la respuesta al navegador Web del cliente.

Propiedades y Mantenimiento de los Servicios ICF

Desde el punto de vista técnico, hay una clase ABAP detrás de un HTTP request handler. Esta clase implementa la interface "IF_HTTP_EXTENSION" y el método "HANDLE_REQUEST".

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

Un servicio ICF 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.

Un sistema SAP contiene ya varios servicios cuando es instalado.

Podemos obtener una vista de todos los servicios usando la transacción de mantenimiento central para los servicios: transacción SICF.

Concepto de Activación

Los servicios pueden estar activos según los colores:

• Activo -> Negro = El servicio puede ser llamado
• Inactivo -> Gris = El servicio está explícitamente desactivado
• Inactivo -> Azul = El servicio está implícitamente desactivado

Si un servicio está desactivado implícitamente, significa que tiene un servicio en algún nivel superior del árbol que está explícitamente desactivado. Si activamos este servicio (color gris), todos los servicios que están implícitamente desactivados en el nivel inmediato inferior se activarán. La activación de un servicio puede darse individualmente o también a sus servicios de niveles inferiores.

NOTA: Los servicios ICF activados representan cierto riesgo de seguridad ya que es posible que sean accedidos directamente usando los protocolos HTTPS o SMTP desde la intranet o internet. (Todos los servicios ICF son entregados con el estado desactivado).

Propiedades e Inherencia

Un servicio ICF se caracteriza por sus propiedades, las cuales pueden mantenerse mediante la transacción SICF.

Las configuraciones que pueden realizarse en los servicios son:

Procedimiento de Logon:

Existen varios procedimientos de logon para el acceso de una solicitud HTTP al SAP Web AS. Las posibles configuraciones son:

• Estándar (por defecto)
• Alternative Logon Order (Permite seleccionar cualquier procedimiento de logon)
• Logon Data Required (Solo los datos almacenados bajo el servicio Anonymous Logon Data son usados para la verificación)
• Client Cert (SSL) Required (El acceso es posible solo usando un certificado de cliente X.509)

Datos de Logon Anónimo:

Los detalles almacenados en "Cliente, User, Password y Languaje" son verificados si se selecciona "Logon Data Required" como procedimiento de logon para un servicio (el usuario debe ser de tipo Servicio)

Opciones de Servicio

Podemos usar el campo "Server Group" para ingresar un grupo de logon (creado en la transacción SMLG)

Requerimientos de Seguridad:

Por defecto la opción Standar está seleccionada, la cual permite conexiones HTTP y HTTPS al servicio. Si seleccionamos SSL, solo las conexiones mediante HTTPS podrán ser aceptadas.

Autenticación Básica:

Si el logon al SAP Web AS se realiza usando Basic Authentication, podemos seleccionar si las entradas realizadas para el usuario en la ventana HTTP del cliente serán interprestadas como un usuario estándar R/3 o como un usuario de Internet.

Handler List

En esta solapa se ingresa los HTTP handlers en la secuencia en que serán ejecutados. Un HTTP request handler es una clase ABAP que implementa una interface que contiene el método HANDLER-REQUEST, el cual es llamado por el ICF.

Error Pages:

En la solapa Error Pages se puede definir qué página de respuesta será enviada al cliente en las siguientes situaciones:

• Error de Logon (HTTP 401: Logon failed)
• Errores de Aplicación (HTTP 500)
• Página de Logoff
• No accesible (HTTP 404)

Alias:

En el ICF podemos crear links (alias) desde un servicio ICF a otro. Si seleccionamos "Reference to an existing service" en la pantalla de mantenimiento cuando se crea un servicio, crearemos ahí un alias interno.

Monitoreo

El ICF recorder permite a los desarrolladores y a los administradores identificar y corregir posibles causas de errores mediante el registro de solicitudes HTTP para aquellos intentos de llamados fallidos.

Podemos usar el ICF recordar para almacenar las solicitudes registradas, en la base de datos del sistema.

Para usar el IFC recordar vamos a la transacción SICF, luego "Edit -> Recorder -> Activate Recording, o mediante la transacción SICFRECORDER para evaluar los registros.

Los pasos a seguir son:

1. Activar el registro. Para eso determinamos la URL que será registrada.
2. La duración del registro en tiempo y el tiempo de almacenamiento en la BD.
3. Llamar al servicio que queremos monitorear.
4. Desactivar el registro.
5. Visualizar y procesar las solicitudes registradas.