![](/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/24.jpg)
Internet Communication Framework
Provee un entorno para el manejo de solicitudes web dentro del work process ABAP de un sistema SAP. Esta leccion introduce el ICF y provee más informacion sobre alguno aspectos de la administración. Cuando en la implementacion 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 administracion crear las conexiones entre las llamadas URLs y los servicios y programas del sistema SAP.
1. Clasificacion del ICF
El internet communication framework (ICF) permite establecer la comunicacion entre diferentes sistemas sobre internet usando protocolos estandard (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 criptografica de SAP (SAPCRYPTOLIB) debe existir y ser configurada. Para ver mas detalles ver la nota SAP 510007.
El ICF hace posible generar una respuesta a una solicitud de una aplicacion. Una solicitud HTTP, es enviada desde un cliente, tal como un navegador web, al servidor. El ICF, reenvia la solicitud a una aplicacion. Los datos son procesados en la aplicacion, la cual devuelve luego, usando tambien el ICF, al cliente como respuesta. ÑLos datos de la respuesta son visualizados en el navegador.
Lo que sigue a continuacion provee mas informacion sobre la utilizacion del sistema SAP como un servidor WEB (servidor HTTP(S)). Para mayor informacion sobre el rol del sistema SAP como cliente, puedes consultar la documentación online en http://help.sap.com
La logica de la aplicacion que es llamada a traves 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 usnado 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 informacion 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 tambien entrega algunos. El más comun 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 dentro 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 aplicacion que se esta llamando está implementada en el stack ABAP o JAVA del servidor de aplicacion Web de SAP. En este caso, estamos considerando una aplicacion ABAP, que debe de ser procesada por un work process 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 aplicacion, y selecciona un work process 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 funcion 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 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 control al 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 tecnico, hay una clase ABAP detras de un HTTP request handler. Esta clase implementa la interface IF_HTTP_EXTENSION y el metodo HANDLE_REQUEST. SAP entrega clases de este tipo, pero los clientes pueden tambien crear sus propias clases con el Class Builder, transaccion SE24, integrado dentro del Object Builder y la transaccion SE80.
La conexion de una URL particular con un HTTP request handler es la tarea de los servicios ICF. Un servicio ICF por lo tanto crea una conexion entre una url a la cual una solicitud HTTP es enviada y los objetos de desarrollo que procesaran la solicitud.
Un sistema SAP (con SAP Web AS como base tecnica) contiene ya varios servicios cuando este es instalado. Cuantos de estos servicios depende del tipo de sistema (SAP ECC, SAP CRM, etc) y la version.
Podemos obtener una vista de todos los servicios usando la transaccion de mantenimeinto central para los servicios ICF, transaccion 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 en mayor detalle a continuacion.
3.Concepto de activacion
Los servicios ICF pueden estar activos o no, lo cual se muestra utilizando diferentes colores en la transaccion SICF.
Estado Color en la transaccion SICF Significado
Activo Negro El servicio puede ser llamado
Inactivo Gris El servicio esta explicitamente desactivado
Inactivo Azul El servicoo esta implicitamente desactivado
Para los servicios desactivados implicitamente, hay siempre un servicio en algun nivel superior en el arbol de ICF que esta explicitamente desactivado. Si activamos este servico, que se muestra de color gris, todos los servicios que esten implicitamente desactivados en el nivel inmediato inferior, lo cuales se mostraban previamente en azul, tambien son activados.
Cuando activamos un nodo mediante el menu Service/Virtual Host+Activate o usando el menu de contexto con el boton derecho del mouse, podremos seleccionar si queremos activar solo el servicio seleccionado (boton yes), o si quremos tambien activar explicitamente todos los servicios en los niveles inferiores (boton Yes en el icono de arbol).
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 configuracion de red).
Por lo tanto deberemos restringir el acceso con medidas apropiadas, tal como solo la activacion de los servicios ICF requeridos y asignando las correspondientes autorizaciones a los usuarios.
Todos los servicios ICF son entregados con el estado desactivado, de tal forma que ningun servicio ICF pueda ser utilizado inicialmente.
4. Propiedades e inherencia
Un servicio ICF se caracteriza por sus propiedades, las cuales pueden mantenerse en la transaccion SICF. Si hacemos doble click un servicio, la ventana de creacion/modificacion de un servicio aparece. Las siguientes configuraciones pueden realizarse.
Datos de servicio/Procedimiento de logon:
Varios procedimientos de logon estan disponibles para el acceso de una solicitud HTTP al SAP Web AS. Podemos configurar esto para cada nodo de servicio de forma individual. Con las configuracion por defecto, standard, las siguientes verificaciones se llevan a cabo en la siguiente secuencia:
1. Campos de autenticacion mediante campos HTTP (Fields uthentication).
2. Autenticacion SSO (Single Sign-ON).
3. Autenticacion básica (Basic Authentication).
4. Autenticacion de SAP con un usuario y contraseña del sistema SAP (SAP Authentication).
5. Autenticacion de certificado mediante un certificado de cliente (Certificate Authentication).
6. Autenticacion de servicio con un usuario anonimo almacenado en el mismo servicio (service authentication).
Si seleccionamos Alternative Logon Order, podemos seleccionar cualquier procedimiento de logon, en una solapa de logon order, y cambiar el orden de las verificaciones. Si seleccionamos Logon Data Required, solo los detalles almacenados en el servicio bajo Anonymous Logon Data son usados para la verificacion.
Si seleccionamos Client Cert (SSL) Required, el acceso es posible solo usando un certificado de cleinte X.509. Para los procedimientos Standard y Alternative Logon Order, tambien podemos usar la opcion 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 1er procedimiento de logon falle.
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 aqui que fueron creados como usuarios de Servicio en la transaccion SU01. Si almacenamos un usuario de dialogo, el sistema muestra una advertencia.
Datos de servicio/Opciones de servicio
Podemos usar el campo Server Group para ingresar ungrupo de logon (creado en la transaccion 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 ejecucion si el usuario tiene esta autorización (para el objeto de autorizacion S_ICF, campo ICF_VALUE).
Si un error de autorizacion ocurre, la configuración en Err Type determina que tipo de mensaje se utilizará.
Una aplicacion stateful es finalizada luego de que se cumple el tiempo especificado en Session Timeout (si el valor es 0, el parametro de perfil rdisp/plugin_auto_logout, el cual tiene un valor por defecto de 30 min, aplica).
Si usamos el tilde de Compression, si es posible, el sistema SAP comprime la respuesta usando un procedimiento de compresion gzip, en la medida que quien realiza la llamada pueda descomprimir la respuesta.
Si activamos la opcion GUI Link, la pantalla de salidad que es generada en la aplicacion es mediante el uso de pantallas convencionales convertidas a un formato en el que el navegador del cliente puede mostrar.
Esta funcion ( y la ventana que aparece si seleccionamos Settings) es requerida para el ITS integrado dentro del SAP Web AS desde la version 6.40.
Datos de servicio/Requerimientos de seguridad
Por defecto, la opcion Standard está seleccionada, la cual permite conexiones HTTP y HTTPS al servicio. Si seleccionamos SSL, solo las conexiones mediante HTTPS podran ser aceptadas.
Datos de servicio/Autenticacion 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, seran interpretadas como un usuario estandar R/3 (Campo USER en la transaccion SU01, con un maximo de 12 caracteres) o como un usuario de internet (campo Alias en la transaccion SU01, con un maximo de 40 caracteres).
Handler List
En esta solapa, ingresamos los HTTP handlers en la secuencia en que seran ejecutados. Un HTTP request handler es una clase ABAP que implementa la interface IF_HTTP_EXTENSION. Esta interface contiene el metodo 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 Aplicacion (HTTP 500: an error occurred 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 enviará al navegador, o un redireccionamiento a una url especifica. Para los errores de logon, tambien podremos utilizar la opcion de permitir un logon directo al sistema si ocurre un error.
Los servicios que son requeridos para servicios internos del sistema estan 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 transaccion SICF, ya que podemos hacerlo en los nodos superiores, tal como /sap/bc/bsp.
Todos los servicios que se encuentren bajo ese nodo heredan las configuraciones del nodo, a menos que explicitamente modifiquemos las propiedades de un servicio particular que esta debajo del nodo superior tambien configurado.
Alias
En el ICF, podemos crear links, conocidos comoalias, desde un servicio ICF a otro. Si seleccionamos: Reference to an existing service en la pantalla de mantenimiento de servicio (Maintain Service) de la transaccion SICF cuando creamos un servicio, creamos aqui un alias interno.
En vez de almacenar un HTTP request handler, usaremos el servicio que definiremos en la solap Alias Trg, con un doble click y seleccionando desde el arbol de servicios ICF a que servicio apuntará. Esto nos permite, por ejemplo, llamar a un servicio que no queremos alterar su configuracion mediante un alias interno donde podremos usar una configuracion diferente, tal como los datos y el procedimiento de logon.
No deberiamos crear alias internos a los servicios SAP, los cuales se encuentran debajo del nodo /sap/.
Para permitir el llamado de un servicio conun nombre descriptivo en vez de su nombre tecnico, podremosusar los alias externos. Para esto, cambiamos a la vista Maintain External Aliases en la transaccion SICF.
Un alias externo podria, a diferencia de un alias interno contener una barra / en el nombre; de otra forma, ambos procedimientos podrian ser utilizados de la misma manera.
5. Monitoreo
El ICF recorder permitea los desarrolladores y los administradores identificar y si es necesario, corregir posibles causas de errores mediante el registro de solicitudes HTTP para aquellos ontentos de llamados fallidos. Podemos usar el ICF recorder para almacenar las solicitudes registradas, en la bd del sistema. Esto facilita la investigacion del problema, ya que en la mayoria de los casos, una descripcion 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 bd, para aislar la causa usando el debugging o un archivo de traza del work process que lo ejecuta.
 
 
 
Sobre el autor
Publicación académica de Sharly Jose Aponte Escobar, en su ámbito de estudios para la Carrera Consultor Basis NetWeaver.
Sharly Jose Aponte Escobar
Profesión: Ingeniero en Informática - Mexico - Legajo: MP19S
✒️Autor de: 45 Publicaciones Académicas
🎓Egresado del módulo:
Disponibilidad Laboral: PartTime