✒️SAP BASIS / Internet Communication Framework Por Camilo Cubides Mojica

Leccion 8

Internet comminication Framework

El internet communication framework (ICF) prove 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 utilizando protocolos estándar (tal como http y smtp). No se requieren librerías de programas SAP adicionales para esto excepto por el protocolo HTTPS para el cual la librería Criptografica de sap (SAPCRYPTOLIB) debe existir y ser configurada.

Un https 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

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 estamos en el mundo Abap y dentro del ICFl

Una solicitud HTTPS 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 JAVAdel servidor de aplicación WEB de sap.

2. El ICM almacena los datos recibidos en un memory pipe (en la memoria compartida) e informa al dispacher ABAP

3. El dispacher abap coloca la solicitud del ICM en la cola del dispacher (dispacher 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 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 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. El http request handler determinado previamente es llamado (este puede procesar los datos solicitados llamara aplicaciones adicionales acceder al objeto de la respuesta )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 a finalizado.

9. El ICM devuelve la respuesta al navegador.

Propiedades y mantenimiento de los servicios ICF

SE24 creacion clases con el class builder integrando 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.

Podemos tener una vista de todos los servicios usando la transacción de mantenimiento central paralos servicios ICF transacción SICF el camino completo para un servicio (tal como /sap/bc/icf/info)determina junto con el protocolo nombre del servidor y puertola url bajo la cual el servicio puede ser llamado.

Concepto de Activacion:

Los servicios ICF pueden estar activos o no lo cual se muestra utilizando diferentes colores en la transacción SICF

Activo Negro--- El servicio puede ser llamado

Inactivo Gris --- el servicio esta explícitamente desactivado

Azul es servicio esta implícitamente desactivado

Para los servicios desactivados implícitamente, hay siempre un servicio en algún nivel superior en el árbol 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 previamente en azul, también son activados.

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

Propiedades e Inherencia:

Un servicio ICF se caracteriza por sus propiedades, las cuales pueden mantenerse en la transacción SICF. Si hacemos doble click un servicio, la ventana de creación/modificación de un servicio aparece las siguientes configuraciones pueden realizarse:

Datos de servicio /procedimiento de logon:

Variaos procedimientos de logon están disponibles para el acceso de una HTTP al sap web as.

Podemos configurar esto para cada nodo de servicio de forma individual. Con las configuraciones 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 Basica

4.Autenticacion de sap con un usuario y contraseña del sistema sap

5.Autenticacion de certificado mediante un certificado de cliente

6.Autenticacion de servicio con un usuario anónimo almacenado en el mismo servicio.

Datos de servicio/datos de logon anónimo

Los detalles almacenados en Client,user, password y lenguaje son verificados si seleccionamos LOgon Data requerid como procedimiento de logon para un servicio.

Deberiamos solo almacenar usuarios aquí que fueron creados como usuarios de servicio en la transacción su01 si almacenamos un usuario de dialogo el sistema muestra una advertencia.

Datos de servicio/opciones de servicio

Pödemos usar el campó Server Group para ingresar un grupo de logon (creado en la transacción SMLG)

Datos de servicio/Requerimientos de seguridad

Por defecto la opción Standardesta seleccionada, la cual permite conexiones HTTP Y HTPPS al servicio.Si seleccionamos SSL solo 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 USERn la transacción SU01 con un máximo de 12 caracteres ) o como un usuario de internet

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 accessible (HTTP 404)

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

Alias:

En el ICF podemos crear links conocidos como alias desde un servicio ICF a otro si señleccionamos reference to an existing service en la pantalla de mantenieminto de servicio de la transacción sifc cuando creamos un servicio creamos aquí un alias interno.

NO deberíamos crear alias internos a los servicios SAP los cuales se encuentran debejo del nodo de /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

Transaccion SICFRECORDER PARA EVALUAR REGISTROS

PASOS A SEGUIR

1.ACTIVAR el registro cuando hacemos esto determinamos La URL que se ra registrada

2. la duración del registro en tiempo

3. llamar al servicio que queremos monitorear

4.desactivar el registro

5. Visualizar y procesar las solicitudes registradas.

Agradecimiento:

Ha agradecido este aporte: Mauricio Torres Hidalgo