✒️SAP BASIS Internet Communication Framework

Internet Communication Framework

El ICF (Lo que permite comunicarnos con el sistema sap) 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 aplicaciones 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.

El Internet Communication Framework (ICF). Cuando en la implementación de SAP queremos usar aplicaciones web basadas en Web Dynpro, BSP o el ITS para conectar el sistema SAP a internet.

Clasificación del ICF

Permite establecer la comunicación entre diferentes sistemas sobre internet utilizando protocolos estándar (como HTTP y SMTP). No se requieren 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.

ara mas detalles en la nota 510007.

Para más información sobre el rol del sistema SAP como cliente podemos consultar documentación en http://help-sap.com

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 (mas precisamente una clase ABAP) que es identificado usando una url, el cual recibe solicitudes HTTP que usan esta URL

Los clientes pueden crear HTTP request handlers, pero SAP también entrega algunos. El más común de HTTP request handler de SAP es el que maneja los Business Server Pages (BSP), con el es posible desarrollar aplicaciones Web simples.

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.

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 interfase 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.

Concepto de activación

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

Estado – color negro- el servicio puede ser llamado

Estado- color gris – el servicio esta explícitamente desactivado. Si se activa este servicio se activan los servicios que están en azul.

Estado- color azul – el servicio esta implícitamente desactivado

Todos los servicios ICF son entregados con el estado desactivado, de tal forma que ningún servicio ICF pueda ser utilizado inicialmente

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.

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).

Handler list

Ingresamos los HTTP handlers en la secuencia en que eran ejecutados.

Un HTTP request handler es una clase ABAP que implementa:

· La interface IF_HTTP_EXTENSION y contiene

· El método HANDLER-REQUEST

· Que es llamado por ICF

Error Pages

En la solapa Error Pages , podemos definir que pagina de respuesta será enviada al cliente en las siguientes situaciones:

· Error de logon (HTTP 401 : logon failed)

· Error de aplicación (HTTP 500: an error ocurred in the application, such as an ABAP short dump)

· Pagina de logoff

· No accesible (HTTP 404)

Los servicios que son requeridos para servicios internos del sistema están definidos bajo el nodo

/sap/public.

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 tx SICF, ya que podemos hacerlo en los nodos superiores, tal como /sap/bc/bsp

Todos los servicios que se encuentran bajo este nodo heredan las configuraciones del nodo, a menos que explícitamente modifiquemos las propiedades de un servicio particular que esta debajo del nodo superior también configurado.

ALIAS

En el ICF podemos crear links, conocidos como alias, desde un ICF a otro. Si seleccionamos Reference to an existing service.

en vez de almacenar un HTTP request handler, usaremos el servicio que definiremos en la solapa alias TRG

no deberíamos crear alias internos a los servicios SAP, los cuales se encuentran debajo del nodo /sap/

un alias externo podría, a diferencia de un alias interno, contener una barra (/) en el nombre; de otra forma, ambos procedimientos podrían ser utilizados de la misma manera.

Monitoreo

ICF Recorder permite a los desarolladores 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.

Pasos que debemos seguir:

· Activar el registro

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

· Llamar al servicio que queremos monitorear

· Desactivar el registro

Podemos prevenir el uso del ICF recorder en todo el sistema en las configuraciones de administrador mediante la opción de menú en la tx SICF:

Goto->Setting

Podemos controlar el acceso a los datos registrados con el objeto de autorización S_SICGREC

Agradecimiento:

Ha agradecido este aporte: David Solaliga