✒️SAP BASIS Internet Communication Framework

1) Clasificación del ICF.

Permite establecer la comunicación entre diferentes sistemas sobre internet usando protocolos estándar (tal como HTTP y SMTP).

No se requieren librerias de programas SAP adicionales para esto, excepto por el protocolo HTTPS, para el cual la Libreria Criptográfica de SAP (SAPCRYPTOLIB) debe existir y ser configurada. Una solicitud HTTP es enviada desde un cliente, tal como un navegador web, al servidor. Los datos son procesados en la aplicación, la cual devuelve luego, usando también el ICF, al cliente como respuesta.

Lo que sigue a continuación provee más información sobre la utilización del sistema SAP como un servidor Web (servidor HTTP(S). La logica 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 (más precisamente una clase ABAP) 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 (por ejemplo, codificado dentro de la URL como información de "query string), para realizar una cantidad de procesos especificos del handler, y generar una respuesta a esta solicitud HTTP. Los clientes pueden crear HTTP request handlers, pero SAP también entrega algunos.

2) 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. SAP entrega clases de este tipo, pero los clientes pueden también crear sus propias clases con el Class Builder, transacción SE24, integrado dentro del Object Builder y la transacción 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. El camino completo para un servicio (tal como /sap/bc/icf/info) determina, junto con el protocolo, nombre del servidor y puerto, la URL bajo la cual el servicio puede ser llamado.

3) Concepto de Activación.

Para los servicios desactivados (color gris), hay un servicio en algún nivel superior en el árbol de ICF que está desactivado. Si activamos este servicio, todos los servicios que estén desactivados en el nivel inmediato inferior, se mostraban en azul son activados.

Activación del nodo:

En el menú Service/Virtual Host Activate o usando el menú >el botón derecho del mouse; seleccionar si queremos activar solo el servicio seleccionado (Yes), o si queremos activar todos los servicios en los niveles inferiores (Yes con el icono de árbol).

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 riesgo de seguridad ya que es posible que sean accedidos directamente usando los protocolos HTTP(S) o SMTP desde la intranet o internet (dependiendo de la configuración de red).

4) Propiedades e Inherencia.

-Datos de servicio/procedimiento logon.

Se llevan a cabo en la siguiente secuencia:

Campos de autenticación mediante campos HTTP (Fields authentication)

Autenticación SSO (Single Sign-On)

Autenticación básica (Basic Authentication)

Autenticación de SAP con un usuario y contraseña del sistema SAP (SAP Authentication)

Autenticación de Certificado mediante un certificado de cliente (Certificate Authentication) Autenticación de Servicio con un usuario anónimo almacenado en el mismo servicio (Service Authentication)

Si seleccionamos…

Alternative Logon Order: Podemos seleccionar cualquier procedimiento de logon, en una solapa nueva de Logon Order, y cambiar el orden de las verificaciones.

Logon Data Required: Solo los detalles en el servicio bajo Anonymous Logon Data son usados para la verificación.

-Datos de Servicio/Logon Anónimo

Los detalles almacenados en Client, User, Password, y Language son verificados, si seleccionamos Loprocedimiento de logon para un servicio. Deberíamos solo almacenar usuarios aquí que fueron creados como usuarios de Servicio en lalmacenamos un usuario de diálogo, el sistema muestra una advertencia.

-Datos/Opciones de servicio

SAP Web Dispatcher >las solicitudes enviadas a este servicio son reenviadas a las instancias ABAP del grupo de logon que elegimos. Esta función (y la ventana que aparece si seleccionamos Settings) es requerida para el ITS integrado dentro del SAP Web AS desde la versión 6.40.

-Datos de Servicio/Requerimientos de Seguridad

La opción Standard está seleccionada, la cual permite conexiones HTTP y HTTPS al servicio. > SSL >las conexiones mediante HTTPS podrán ser aceptadas.

-Datos de servicio/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 interpretadas como un usuario estándar R/3 (Campo USER en la transacción SU01, con un máximo de 12 caracteres) o como un usuario de Internet (campo Alias en la transacción SU01, con un máximo de 40 caracteres).

Handler List

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

Error Pages

Definimos que pagina de respuesta será enviada al cliente en las siguientes situaciones:

Error de Logon (HTTP 401: Logon failed)

â–¸ Errores de Aplicación (HTTP 500: an error occurred in the application, such as an ABAP short dump)

Página de Logoff

No accessible (HTTP 404)

Caso de error: podemos configurar una página explicita de respuesta que se enviarà al navegador, o un redireccionamiento a una URL específica.

Errores de logon: también podremos utilizar la opción de permitir un logon directo al sistema si ocurre un error.

Un principio inherente aplica para las propiedades que se listaron: no necesitamos mantener las propiedades de servicio para cada servicio de forma individual en la transacción SICF, ya que podemos hacerlo en los nodos superiores, tal como /sap/bc/bsp

Alias

Esto nos permite, por ejemplo, llamar a un servicio que no queremos alterar su configuración mediante un alias intero donde podremos usar una configuración diferente, tal como los datos y el procedimiento de logon. Para permitir el llamado de un servicio con un nombre descriptivo en vez de su nombre técnico, podremos usar los alias externos. Para esto, cambiamos a la vista Maintain External Aliases en la transacción SICF. Un alias externo podría, a diferencia de un alias intero, contener una barra (/) en el nombre, de otra forma, ambos procedimientos podrían ser utilizados de la misma manera.

5) Monitoreo

El ICF recorder permite a los desarrolladores y los administradores identificar y si es necesario, corregir posibles causas de errores mediante el registro de solicitudes HTTP para aquellos intentos de llamados falidos. 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 debugging o un archivo de traza del work process que lo ejecuta Deactivate Recording/ Display Recording; alternativamente la transacción SICFRECORDER para evaluar los registros.

Pasos a seguir:

1. Activar el registro, cuando hacemos esto, determinamos: La URL que serà registrada (si hemos seleccionado el servicio desde el árbol previamente, este será propuesto).

2. La duración del registro en tiempo (Record Time) y el tiempo de almacenamiento en la base de datos (Lifetime) y si se registrarán las llamadas por un usuario particular o todos los usuarios.

3. Llamar al servicio que queremos monitorear

4. Desactivar el registro.

5. Visualizar y procesar las solicitues registradas.