![](/cvo_files/imgs_sap_abap/logos/logo_cvo_academy_it.png)
✒️SAP BASIS Internet Communication Framework
SAP BASIS Internet Communication Framework
![SAP BASIS Internet Communication Framework SAP BASIS Internet Communication Framework](https://www.cvosoft.com/cvo_files/imgs_sap_abap/og-images/326.jpg)
LECCION 8: INTERNET CONNUNICATION FRAMEWORK
El Internet Communication Framework (ICF) provee un entorno para el manejo de solicitudes web dentro del work process ABAP de un sistema SAP. Esta lección introduce el ICF y provee mas información sobre algunos aspectos de la administración.
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 como miembros del equipo de administración crear las conexiones entre las llamadas URLs y los servicios y programas del sistema SAP.
1.- Clasificacion del ICF
El internet communication famework (ICF) permite establecer la comunicación entre diferentes sistemas sobre internet usando portocolos estándar (tal como HTTP y SMTP). No se requiere de librerías de programas SAP adicionales para esto, excepto por el protocolo HTTPS, para el cual la librerías de programas SAP adicionales para esto, excepto por el protocolo HTTPS, para el cual la Librería Criptrografica de SAP (SAPCRYPTOLIB) debe existir y ser configurada.
Nota: para mas detalles ver la nota SAP 510007
El ICF hace posible generar una respuesta a una solicitue de una aplicación. Un a solicitud HTTP es enviada desde un cliente, tal como un navegador web, al servidor. El ICF reenvia la solicitud a una aplicación. Los datos son procesados en la aplicación, la cual devuelve luego, usando tambienel ICF, al cliente como respuesta. Los datos de la respuesta son visualizados en el navegador.
Lo que sigue a continuación provee mas información sobre la utilización del sistema SAP como un servidor Web (servidor HTTP(S)). Para mayor información sobre el rol del sistema SAP como cliente puedes consultar la documentación online en http://help.sap.com
La lógica de la aplicación 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, 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 específicos del handler, y generar una respuesta a esta solicitud HTTP.
Los clientes pueden crear HTTP request handler, pero SAP también entrega algunos. El mas común de HTTP request handler de SAP es el que maneja los Business Server Pages (BSP), con el cual es posible desarrollar aplicaciones web simples.
Si una solicitud HTTP es recibida por el ICM que será procesada en un work process el task handler toma control. Este luego inicia el controlador ICF. Desde ahora en adelante, estamos en el mundo ABAP y dento del ICF.
Una solicitud HTTP(S) es procesada de la siguiente manera:
1. La solicitud es enviada desde el navegador Web del usuario al ICM usando el protocolo HTTP. El ICM usa la URL recibida para decidir si la aplicación que se esta llamando esta implementada en el stack ABAP o JAVA del Servidor de Aplicación Web de SAP.
En este caso, estamos considerando una aplicación ABAP que debe ser procesada por un work porcess de dialogo ABAP.
2. El ICM almacena los datos recibidos en un memory pipe (en la memoria compartida) e informa al dispatcher ABAP.
3. El dispatcher ABAP coloca la solicitud del ICM en la cola del dispatcher (dispatcher queue), crea un nuevo contexto, si es que no existe aun uno cuando el procesamiento stateful es utilizado en la aplicación, y selecciona un work porcess libre para el procesamiento.
4. El 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 modulo de función HTTP_DIPATCH_REQUEST.
5. El controlador ICF transfiere la solicitud del 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 metodos posibles.
7. El HTTP request handler determinado previamente es llamado (este puede procesar los datos solicitados, llamar a aplicaciones adicionales, acceder al objeto de la respuesta, etc. ) Una vez que el HTTP request handler finaliza, devuelve el controlador ICF.
8. El task handler escribe la respuesta en el memory pipe y avisa al ICM que el procesamiento de la solicitud ha finalizado.
9. El ICM devuelve la respuesta al navegador Web del cliente.
2.- Propiedades y Mantenimiento de los Servicios ICF
Desde el punto de vista técnico, hay una clase de ABAP detrás de un HTTP request handler. 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 sus propias clase con el Class Builder, transacción SE24, integrado dentro del Object Builder y la trx 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 solcitud HTTP es enviada y los objetos de desarrollo que procesaran la solicitud.
Un sistema SAP (con SAP Web AS como base técnica) contiene ya varios servicios cuando este es instalado. Cuantos de estos servicios depende del tipo de sistema (SAP ECC, SAP CRM, et.) y la versión.
Podemos obtener una vista de todos los servicios usando la trx de mantenimiento central para los servicios ICF, TRX SICF. 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. Algunos aspectos que son importantes para los administradores son descritos con mayor detalle a continuación.
3.- Concepto de Activacion
Los servicios ICF pueden estar activos o no, lo cual se muestra utilizando diferentes colores en la trx SICF:
Estado
Color en trx SICF
Significado
Activo
Negro
El servicio puede ser llamado
Inactivo
Gris
El servicio esta expliciamente desactivado
Azul
El servicio esta implícitamente desactivado.
Para los servicios desactivados implícitamente, hay siempre un servicio en algún nivel superior en el árbol de ICF que esta explícitamente desactivado. Si activamos este servicio, que se muestra de color gris, todos los servicios que estén implícitamente desactivados en el nivel inmediato inferior, los cuales se mostraban perviamente en azul, también son activados.
Cuando activamos un nodo mediante el menú Service/Virtual HOSTàActivate o usando el menú de contexto con el botón derecho del mouse, podremos seleccionar si queremos activar solo el servicio seleccionado (botón yes), o si queremos también activar explícitamente todos los servicios en los niveles inferiores (botón yes con el icono de árbol).
Si llamamos a un servicio inactivo, un mensaje aparece informando que el acceso a la pagina esta 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 la red).
Por lo tanto deberemos restringir el acceso con medidas apropiadas, tal como solo la activación de los servicios ICF requeridos y asignando las correspondientes autorizaciones de los usuarios.
Nota: Todos los servicios ICF son entregados con es estado de desactivados, de tal forma que ningún servicio de ICF pueda se utilizado inicialmente.
4.- Propiedades e Inherencia
Un servicio ICF se caracteriza por sus propiedades, las cuales pueden mantenerse en la trx SICF. Si hacemos doble clic un servicio, la ventana de creación/modificación de un servicio aparece. 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. Podemos configurar esto para cada nodo de servicio de forma individual. Con la configuración por defecto, Standard, las siguientes verificaciones se llevan a cabo en la siguiente secuencia:
1. Campos de autenticación mediante campos HTTP
2. Autenticacion SSO
3. Autenticacion básica
4. Autenticacion de SAP con un usuario y contraseña del sistema SAP
5. Autenticacion de Servicio con un usuario anónimo almacenado en el mismo servicio
Si seleccionamos Altenative 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 Anonimous Logon Data son usados para la verificación.
Si seleccionamos Client Cert. (SSL) Required, el acceso es posible solo usando un certificado de cliente X509.
Para los procedimientos Standard y Altenative Logon 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 procedimiento de logon es exitoso, o de lo contrario debería retomar un mensaje negativo luego de que el primer procedimiento de logon falla.
Datos de Servicio / Datos de logon Anonimo :
Los detalles almacenados en Client, User, Password y Language son verificados, si seleccionamos Logon Data Required como procedimiento de logon para un servicio.
Deberiamos solo almacenar usuarios aquí que fueron creados como usuarios de Servicio en la trx SU01. Si almacenamos un usuario de dialog, el sistema muestra una advertencia.
Datos de Servicio/Opciones de Servicio
Podemos usar el campo Server Group para ingresar un grupo de logon (creado en la trx SMLG).
Es mejor usar la ayuda con F4 para esto. Si estamos usando un SAP Web Dispatcher, las solicitudes enviadas a este servicio son solamente reenviadas a las instancias ABAP del grupo de logon que elegimos.
Si ingresamos un valor en el campo SAP Authoriz, el sistema verifica en tiempo de ejecución si el usuario tiene esta autorización (para el objeto de autorización S_ICF, campo ICF_VALUE).
Si un error de autorización ocurre, la configuración en Err TYPE determina que tipo de mensaje se utilizará.
Un aplicación stateful es finalizada luego de que se cumple el tiempo especificado en Session Timeout (si el valor es 0, el parámetro de perfil rdisp/plugin_auto_logout, el cual tiene un valor por defecto de 30 minutos aplica).
Si usamos el tilde de Compression, si es posible, el sistema SAP comprime la respuesta usando un procedimiento de compresión gzip, en la medida que quien realiza la llamada pueda descomprimir la respuesta.
Si activamos la opción GUI Link, la pantalla de salida que es generada en la aplicación es mediante el uso de pantallas convencionales convertidas a un formato en el que el navegador del cliente pueda mostrar.
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
Por defecto, la opción Standard esta seleccionada, la cual permite conexiones HTTP y HTTPS al servicio. Si seleccionamos SSL, solo las conexiones mediante HTTPS podrán ser aceptadas.
Datos de servicio / Autenticacion Basica
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 TRX SU01, con un máximo de 12 caracteres) o como un usuario de internet ( campo Alias en la trx SU01, con un máximo de 40 c aracteres).
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
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)
· Errores de Aplicación (HTTP 500 : an error ocurred in the application, such as an ABAP short Dump)
· Pagina de Logoff
· No accesible (HTTP 404).
En cada caso de error, podemos configurar una pagina explicita de respuesta que se enviara al navegador, o un redireccionamiento a la URL especifica. Para los errores de logon, también podremos utilizar la opción de permitir un logon directo al sistema si ocurre un error.
Nota : 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 transacción SICF, ya que podemos hacerlo en los nodos superiores, tal como /sap/bc/bsp.
Todos los servicios que se encuentren bajo este nodo heredan las configuraciones del nodo, a menos que explicitamente 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 servicio ICF a otro. Si seleccionamos Reference to an existing service en la pantalla de mantenimiento de servicio (Maintain Service) de la trx SICF cuando creamos un servicio, creamos aquí un alian inteno.
Una vez de almacenar un HTTP request handler, usaremos el servicio que definiremos en la solapa Alias Trg, con un dobre clic y seleccionando desde el árbol de servicios ICF a que servicio apuntará. Esto nos permite, por ejemplo, llamar a un servicio que no queremos alterar su configuración mediante un alias interno donde podremos usar una configuración diferente, tal como los datos y el procedimiento logon.
Nota: No deberíamos crear alias internos a los servidores SAP, los cuales se encuentran debajo del nodo /sap/.
Para permitir el llamado de un servicio con un nombre descriptivo en vez de su nombre técnico, podremos usar los alia externos. Para esto, cambiamos a la vista Maintain External Aliases en la trx SICF.
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.
5.- Monitoreo
El ICF recorder permite a los desarrolladores y los administradores indentificar y m si es necesario, corregir posibles causas de errores mediante el registro de solicitudes HTTP para aquellos intentos de llamados fallidos.
Podemos usar el ICF recorder para almacenar las solicitudes registradas, en la base de datos del sistema. Esto facilita la investigación del problema, 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 debugging o un archivo de traza del work process que lo ejecuta.
Para utilizar el ICF recorder, desde la trx SICF seleccionamos EDITàRecorder àActivate Recording/Desactivate Recording/Display Recording; alternativamente la trx SICFRECORDER para evaluar los registros.
Los pasos que debemos seguir son:
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 registraran 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 solicitudes registradas
Tambien podemos prevenir el uso de ICF recorder en todo el sistea en las configuraciones de administrador, mediante la opción de menú en la trx SICF GOTOàSETTING. Por ultimo, podemos controlar el acceso a los datos registrados con el objeto de autorización S_SICFREC.
 
 
 
Sobre el autor
Publicación académica de Arnold Sevilla, en su ámbito de estudios para la Carrera Consultor Basis NetWeaver.
Arnold Sevilla
Profesión: Pasante de la Carrera Ing.informati - Honduras - Legajo: ML28W
✒️Autor de: 93 Publicaciones Académicas
🎓Egresado de los módulos:
Presentación:
Hola, buenos días, mi nombre es arnold sevilla, estudio la carrera de ing.informatica.
Certificación Académica de Arnold Sevilla