✒️SAP BASIS / Internet Communication Framework Por Xavier Elias Rodriguez

El Internet communication Framework proporciona un entorno para el manejo de solicitudes web dentro del WP ABAP de un sistema SAP.

CLASIFICACION DEL ICF
El ICF permite establecer la comunicacion entre dos sistemas en intenrt usando protocolos HTTP y SMTP. SOlo necesita librerias extra para el protocolo HTPPS para el que debe existir SAPCRYPTOLIB y ser configurada.

Hace posible generar una respuesta a una solicitud de una app.Una solicitud HTTP se envia desde un navegador web al server.El ICF reenvia la solicitud a una app. Los datos se procesan en la app y devuelve al cliente la respues a tra ves del ICF. Los datos se ven en el navegador

La tarea del HTTP request handler es recibir los datos enviados por la solicitud para realizar unos procesos del handler y generar una respuesta a la solicitud http

Los clientes pueden crear http request handlers pero sap entrega algunos. El mas comun es el que maneja los BSP para el desarrollo de app simples

Si una solicitud HTTP se recibe por el ICM que seraprocesada por el wp, el task handler toma el control. Inicia el controlador ICF

Proceso de la solicitud http o http's:
-La solicitud se envia desde el navegador web al icm usando protocolo http.
El icm usa la url recibida para decidir si la app que llama esta implementada en abap o java del server de app web de SAP

-El icm guarda los datos recibidos en un memory pipe e informa al dispatcher ABAP

-El dispatcher ABAP pone la solicitud del icm en la cola del dispatcher y crea un nuevo contexto y selecciona un WP libre

-El task handler en el WP lee los datos desde el memory pipe y los transfiere al controlador ICF que es implementado usando el midulo de funcion HTTP_DISPATCH_REQUEST

-El controlador icf envia la solicitud al icf manager que es implementado por la clase ABAP CL_HTTP_SERVER. El controlador icf crea un bloque de control y lo llena con los datos de solicitud http

-El cliente es autenticado

-El http request handler determiando previamente es llamado

-El task handler escribe la respuesta en el memory pipe y avisa al icm que el proceso de la solicitud ha terminado

-El icm devuelve la respuesta al navegador web del cliente

PROPIEDADES Y MANTENIMIENTO DE LOS SERVICIOS ICF
Detras de un http request hay una clase abap.
Esta clase implementa la interface IF_HTTP_EXTENSION y el metodo HANDLE_REQUEST.
SAp entrega clases de este tipo pero los clientes pueden grear sus propias clases con el class builder, tx SE24 y la tx SE80

La conexion de una url con un http request handler es tarea de los sericios ICF

Un sistema sap contiene varios servicios cuando se instala, el numero depende del tipo de sistema sap y la version

Con la tx SICF podemos obtener una vista de todos los servicios
El camino completo para un serivcio determina junto con el protocolo, nombre del servidor y puerto la url bajo la cual el servicio puede ser llamado

CONCEPTO DE ACTIVACION
LOs servicios icf se peuden o no activar

estado color en la tx SICF significado
activo negro el servicio puede ser llamado
inactivo gris servicio explicitamente desactivado
azul servicio implicitamente desactivado

Para los servicioa implicifamenet desactivdo hay siempre un servicio en algun nivel superior del arbol ICF que esta explicitamente desactivado. Si activamos este servicio de color gris todos los serivios implicitamente desactivados en el nivel inferior seran activados

Cuando activamos un nodo desde el menu service/virtual host - activate podemos selccionar si queremos activar el servicio seleccionado (boton yes) o si queremos activar explicitamente todos los servicios en los niveles inferiores boton yes con el icono de arbol

Si llamamos a un servicio inactivo aparece un mensaje informando que el acceso a la pagina esta bloqueado.

PROPIEDADES E INHERENCIA
El servicio icf se caracteriza por sus propiedades que pueden mantenerse en la tx SICF
Al hacer un doble click en el servicio, aparece la ventana de creacion /modificacion y pueden hacerse las siguintes configuaciones:

-datos de servicio/procedimiento de logon
Hay varios procedimineto de logon para el acceso de una solicitud HTTP al sap web as. Se puede configurar para cada node de serivio de forma indiviudal.
Con la conf standard se siguen las siguientes verificaciones:

-campos de autentificacion mediante campos http
-autentificacion sso
-autentificacion baseica
-autentificacoin de sap con user y pass del sistema sap
-autentificacion de certificado mediante un certficado de cliente
-autentificacion de servicio con usuario anonimo guardado en el mismo servicio

Con el alternative logon order podemos selccionas cualquier proc de logon en una nueva solapa de logon order y cambiar el orden de las verificaciones
Con el logon data required solos los detalles guardados en el servicio anonymous logon data son usados para la verificacion

Con el Client cert ssl required el acceso es posible udando un certificado de cliente x509

Para standard y alternative logon orderpodemos usar la opcion all logons para definir si el esistema ha de ejecutar las verifiacoines en la secuencia relevante has que uno de los procedimineto de logon sea exitoso

-datos de servicio/datos de logon anonimo
Si seleccionamos logon data required como proc de logon para un servicio se verifican los detalles guardados en client, user, pass, lang

Aqui solo debemos guardar los usuarios que fueron creados como usuarios de servicios en la ux su01, el sistema muestra un warning si guardamos un usuario de dialogo

-datos de servicio/opciones de servicio
El campo Server group se usa para poner un grupo de logon que se ha creado en la tx SMLG

Si usamos un sap web dispathcer las solicitudes enviadas a este servicio se reenvian a las instancias del grupo de logon que elegimos.

Si ponemos un valor en el campo SAP authriz el sistema en tiempo de ejecucion revisa si el usuario tiene autorizacion

Si ocurre un error , la configuracion que hay en ERR type determina el mensaje a enviar.

Una app stateful se cierra cuando cumple el tiempo que hay en el session timeout si el valor es o el param rdips/plugin_auto_logout aplica su valor por defecto es 20 min

Si usamos compression el sistema sap comprime la respuesta en gzip

Si usamos la opcion link la pantalla de salida se genera meidante el uso de pantallas que se pueden mostrar en el navegador.

Esta funcion es requerida para el its en el sap web as

-datos de servicio/requerimientos de seguridad
Por defecto las opcion estandard esta seleccionada y permite conexiones http y https al servicio.
Si seleccionamos la opcion SSL solo permite cnexiones https

-datos de servicio/autentificacion basica
Si el logon se hace cin basic authorization podemos selccionar si las entradas para el usaurio en la ventana http del cliente se interpretan como usuario r/3 o como usurio de internet

-handler list
Ponemos los http handlers en la secuencia en la que sran ejecutados.
El request handler es una clase abap que implementa la interface if_http_extension que tiene como emtodo handler requet llamado por el icf

-error page
definimos que pagina de respuesta sera enviada al cliente en las situaciones:
-error de logon http logon faield
-errores de app http 500 error ocurred in the app as abap dump
-pagina de logoff
-no accesible http 404

Los servicios requeridos para servicios internos del sistema se definen en /sap/public

Sobre esas propiedades anteriores podemos mantener sus propiedades en los nodos superiores como /sap/bc/bsp. Los servicios que se encuantran bajo este nodo heredan la conf del nodo a menos que lo especifiquemos en las propiedades de un servicio en concreto

ALIAS
son los lonks que podemos crear en el ICF hacia otro ICF.
PAra crear un alias interno: dede la pantalla de mantenimiento selccionamos reference to an existing aervice con la tx sicf

Usaremos el servicio definido en la solapa alias trg y desde el arbol de servicios de icf a que servicio apuntara

No se debe crear alias internos a los servicios sap que se encuentren debajo del nodo /sap

Loas alias externos se usan para permitir la llamada a un servicio con el nombre descriptivo. PAra ello cambiamos a la vista maintain external aliases en la tx sicf

MONITORING
El icf identifica y corrige las causas de erroes en el registro de solicitudes http
Se puede usar para guardar las solicitudes registradas en la base de datos
Se usa: desde la tx sicf - edit-recorder- activate recording/deactivate recording /display recording y la tx sicfrecorder para evaluar los registros
Pasos a seguir:
-activar el registro: se determina que url sera registrada

-duracion del registro en teimpo y el tiempo de almacenamiento en la db y si se registran las llamadas por un usuario o todos

-llamar al servicio que quermos monitorizar

-desactivar el registro

-visualizar y procesar las solicitudes registradas

Con la tx sicf goto-settings podemos prevenir el uso del icf recorder en todo el sistema.
Comnel objeto de autorizacion S_sICFERC podemos controlar el acceso a los datos registrados