✒️SAP BASIS / Internet Communication Framework Por José Reyes Alarcón.

Apunte Creado OK - Iniciar Edición

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.

1| CLASIFICACION DEL ICF

Permite establecer la comunicación entre diferentes sistemas sobre internet usando protocolos estándar (http, smtp) . No se requieren librearías de programas SAP adicionales, excepto para el protocolo HTTPS, para el cual la librearía criptográfica de SAP (sapcryptolib) debe existir y ser configurada.

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

2| PROPIEDADES Y MANTENIMIENTO DE LOS SERVICIOS ICF

Hay una clase ABAP detrás de un HTTP request handler, esta clase implementa:

· IF_HTTP_EXTENSION

· y el método HANDLE_REQUEST.

Los clientes pueden también crear sus propias clases con el Class Builder , Tx SE24, integrado dentro del Object Builder y de la TX SE80

La conexión de una URL particular de 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 procesaran la solicitud.

TX SICF à podemos obtener una vista de todos los servicios usando la transacción de mantenimiento central para los servicios.

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

3| 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

4| PROPIEDADES E INHERENCIA

Datos de servicio /procedimiento de Logon:

· cada nodo de servicio se puede configurar individualmente

con la configuración por defecto, standard, las siguientes verificaciones se llevan a cabo en la siguiente secuencia:

1- campos de autentificación mediante capos HTTP (fields authentication)

2- autenticación SSO (Single sign – on)

3- autenticación básica (Basic Authetication)

4- Autenticación de SAP con un usuario y contraseña del sistema SAP (SAP Authentication)

5- Autenticación de certificado mediante un certificado de cliente (Certificate Authetication). Usa un certificado de cliente X.509

6- Autenticación de Servicio con un usuario anónimo almacenado en el mismo servicio (Service Athentication).

Con Alternative Logon Order, podemos seleccionar cualquier procedimiento de Logon, en una nueva solapa de logon order , y cambiar el orden de verificaciones.

Si seleccionamos Logon Data Required , solo los detalles almacenados en el servicio bajo Anonymous Logon Data son usados para la verificación.

Para los procedimientos standard y Alternative Logon Order se puede usar la opción All Logons para definir si el sistema deberá ejecutar las verificaciones en la secuencia relevante hasta que uno del procedimiento de logon es exitoso, o de lo contrario debería retornar un mensaje negativo luego de que el primer procedimiento de logon falla.

Datos de servicio / datos de Logon anónimo

Los detalles almacenados en client, User, Password y Languaje son verificados, si seleccionamos Logon Data Requerid como procedimiento de logon para un servicio. Deberíamos solo almacenar usuarios que fueron creados como usuarios de servicio.

Datos de servicio / opciones de servicio

Podemos usar el campo Server Group para ingresar un grupo de logon (creado en la tx SMLG).

Por defecto, la opción standard esta seleccionada, la cual permite conexiones HTTP Y HTTPS al servicio, si seleccionamos SSL, solo las conexiones HTTPS podrán ser aceptadas.

Datos de servicio / autentificación Básica

Si el logon de 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 tx Su01 , con un máximo de 12 caracteres ) o como un usuario de internet (campo alias en la tx su01, con un máximo de 40 caracteres).

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.

5| MONITOREO

El ICF recorder permite a los desarrolladores y a los administradores identificar y, si es necesario, corregir posibles causas de errores mediante el registro de solicitudes HTTP para aquellos intentos de llamados fallidos.

Podemos usar el CF recorder para almacenar las solicitudes registradas en la base de datos del sistema. Esto facilita la investigación del problema.

Para utilizar el ICF recorder desde la transacción SICF:

Edità Recorder->Activate Recording/deactivate recording/ Display Recording.

Alternativamente la tx 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