🚀PROMO #PLANCARRERA2024 - 🔥Bonificaciones, Precios Congelados y Cuotas

 X 

✒️SAP BASIS Internet Communication Framework

SAP BASIS Internet Communication Framework

SAP BASIS Internet Communication Framework

INTERNET COMMUNACTION FRAMEWORK

El ICF (Internet Communication Framework) provee un entorno para el manejo de solicitudes web dentro del work process ABAP en un sistema SAP.

Como administradores nuestra tarea será administrar y crear la conexiones entee las llamadas URLs y los servicios y programas ABAP.

CLASIFICACION DEL ICF

EL ICF permite establecer la comunicación entre diferentes sistemas sobre internet usando protocolos estándar tal como HTTP y SMTP.

No se requieren librerías de programas SAP adicionales para esto, excepto para el protocolo HTTPS que se necesita la Librería Criptográfica SAP (SAPCRYPTOLIB), esta debe estar configurada.

Para más detalles ver la NOTA DE SAP: 510007

EL IFC hace posible generar una respuesta a una solicitud de una aplicación.

Se envía una solicitud HTTP desde un cliente (desde un navegador web) al servicio. EL ICF reenvía la solicitud a una aplicación. Se procesan los datos, la aplicación devuelve los datos usando el ICF al cliente y estos son visualizados (en el navegador web).

A continuación se detalla más información del sistema SAP como servidor WEB (Servidor HTTP/s)

Para más información sobre el rol de sistema SAP como cliente, consultar la documentación online en http://help.sap.com

HTTP REQUEST HANDLER

Loa lógica de la aplicación que se llama a través de una solicitud HTTP, es implementada por el HTTP Request Handler en cada caso.

Un HTTP Request Handles es una clase ABAP (programa) 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 (codificado dentro de la URL como información de “query string”) para realizar una cantidad de procesos específicos del handler y generar un respuesta a esta solicitud HTTP.

Los clientes pueden crear HTTP resquest handlers, pero SAP también dispone de algunos, el más 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á procesda en un work process el task handler toma el control. Este inicia el controlador ICF.

Una solicitud HTTP(s) se procesa de la siguiente manera:

1. La solicitud es enviad desde el navegador web del usuario al ICM usando el protocolo HTTP

2. El ICM usa la URL recibida para decidir si la aplicación que se llama está en el stack ABAP o JAVA del servidor de aplicación WEB de AP

3. Si es el ABAP, se procesa por un work process de dialogo de ABAP.

4. EL ICM almacena los datos recibidos en una memory pipe (memoria compartida) e informa al dispatcher ABAP.

5. El dispatcher ABAP coloca la solicitud del ICM en la cola de dispatcher (dispatcher queu)

6. Crea un nuevo contexto, si es que no existe aún uno cundo el procesamiento stateful es utilizado en la aplicación

7. Selección un work process libre para el procesamiento

8. El task handler en el work process lee los datos desde el memory pipe y los transfiere al controlado ICF (implementado usando el módulo de función HTTP_DISPATCH_REQUEST

9. El controlado ICF transfiere la solicitud al ICF manager, (implementado usando la clase ABAP CL_HTTP_SERVER)

10. El controlador ICF, crea un bloque de control y lo llena con los datos de la solicitud HTTP

11. El cliente es autenticado mediante alguno de los métodos posibles

12. El HTTP reques handler determinado previamente el llamado, este puede procesar los datos solicitados, llamar a aplicaciones adicionales, acceder al objeto de la respuesta, etc

13. Una vez que el HTTP request handler finaliza, devuelve el control al controlador ICF

14. El task handler escribe la respuesta en el memory pipe

15. Avisa al ICM que el procesamiento de la solicitud ha finalizado

16. EL ICM devuelve la respuesta al navegador Web del cliente.

PROPIEDADES Y MANTENIMIENTO DE LOS SERVICIOS ICF

Desde el punto de vista técnico, hay una clase ABAP detrás de un HTTP request handler.

Esta clase implementa la interface IF_HTTP_EXTENSION y el método HANDLE_REQUEST.

Estas clases ya vienen en SAP, pero se pueden crear propias, mediante el Class Builder, transacción SE24, integrado 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. Por lo tanto el ICF crea una conexión entre una URL a la cual se envían solicitudes HTTP y los objetos que procesarán esta solicitud.

Un sistema SAP (Como WEB AS) contiene ya varios servicios cuando este es instalado.

Podemos obtener una vista de todos los servicios usando la transacción de mantenimiento central para los servicios ICF, transacción SICF

El camino completo para un servicio (por ejemplo /sap/bc/icf/ifo) 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 pueden estar activos o no. Esto se muestra utilizando colores en la transacción SICF

ESTADO >> COLOR EN LA TRANSACCION SICF >>SIFNIFICADO

Activo >> NEGRO >>- EL SERVICIO PUEDE SER LLAMADO

Inactivo >> GRIS >> EL SERVICIO ESTÁ EXPLÍCITAMENTE DESACTIVADO

Inactivo>> AZUL >> EL SERVICIO ESTÁ IMPLÍCITAMENTE DESACTIVADO

Servicios desactivados implícitamente:

Hay algún servicio en algún nivel superior en el árbol del ICF que está explícitamente desactivado. Si activamos este servicio que se muestra de color gris, todos los servicios que estén implícitamente desactivado en el nivel inmediato inferior, los cuales se mostraban previamente en azul, también serán activados.

Cuando activamos un nodo mediante MENU -> SERVICE/VIRTUAL HOST -> ACTIVATE o con el botón derecho del ratón, podemos seleccionar si queremos activar solo el servicios seleccionado (Botón YES) o si queremos también activar explícitamente todos los servicios en los niveles inferiores (botón TES con el icono de árbol).

Si llamamos a un servicio inactivo, aparece un mensaje indicando que el acceso está bloqueado.

Los servicios ICF activos representan un riesgo de seguridad ya que pueden ser accedidos directamente usando los protocolos HTTP(S) o SMTP. Hay que asegurarse que se asignan las correspondientes autorizaciones a los usuarios.

Todos los servicios ICF son entregados con el estado desactivado, ningún servicio ICF puede ser utilizado inicialmente.

PROPIEDADES E INHERENCIA

Un servicio ICF se caracteriza por sus propiedades, estas se pueden mantener mediante la transacción SICF.

Si hacemos doble clic en un servicio, la ventana de creación/modificación de un servicio aparece.

Se puede realizar:

Datos de Servicio/Procedimiento de Logon:

Disponemos de varios procedimientos de logon 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, estándar se utiliza la siguiente secuencia.

1. Campos de autenticación medianto campos HTTP (Fields authentication)

2. Autenticación SSO (Singl Sign-on)

3. Autenticación básica ( Basic Authentication)

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

5. Autenticación de Certificado mediante un certificado de cliente (Certificate Autenticación)

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

Si seleccionamos ALTERNATIVO 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 Anonymous Logon Data son usados para la verificación.

Si seleccionamos Client Certificate (SSL) Required, el acceso es posible sol usando un certificado de cliente X.509.

Para los proceminietos Standard y Alternative 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 procedimientos sea exitoso, o retornar un mensaje negativo después de probar el primer procedimiento de logon.

Datos de Servicio/Datos de Logon Anonimo:

Si seleccionamos Logon Data Required como procedimiento, se verifican estos datos:

1. Client

2. User

3. Password

4. Language

Solo deberíamos poner datos de usuarios creados mediante la transacción SU01. Si utilizamos un usuario de diálogo el sistema no avisa.

Datos de Servicio/Opciones de servicio

Podemos usar el campo Server Group para poner un grupo de logon (creado ante mediante la transacción SMLG)

Es mejor usar la ayuda (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 hemos elegido.

Si ponemos 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 ocurre un error la configuración en Err TYPE determina qué tipo de mensaje utilizará.

Una aplicación stateful se finaliza cuando se cumple el tiempo especificado en el parámetro Session Timeout (si el valor es 0, el parámetro de perfil rdisp/plugin_auto_logout que tiene un valor de 30 aplica).

Si marcamos Compression, si es posible, el sistema SAP comprime la respuesta usando un procedimiento de comprensión gzip, si el que realiza la llamada puede descomprimirla.

Si activamos la opción GUI Link, la pantalla de salida que se genera en la aplicación es mediante el uso de pantallas convencionales convertidas a un formato en el que el navegado del cliente puede 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 está seleccionada, permite conexiones HTTP y HTTPS al servicio. Sí marcamos SSL, solo acepta conexiones HTTPS.

Datos de Servicio/Autenticación Básica

Si se realiza el logon 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 transacción SU01, con un máximo de 12 caracteres) o como un usuario de internet (campo Alias en la transacción SU01, con un máximo de 40 caracteres)

Handler List

En esta solapa, ingresamos los HTTP handlers en la secuencia en que serán ejecutados.

Un HTTP request handles es una clade 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 paginade respuesta será enviada al cliente en las siguientes situaciones:

1. Error de logón (HTTP 401: Logon faileD)

2. Errores de Aplicación (HTTP 500: an error ocurred in the appliacion, such as an ABAP short dump)

3. Página de Logoff

4. No accesible (HTTP 404)

En caso de error, podemos configurar una página explicita de respuesta que se enviará al navegador, o un re direccionamiento a un URL especifica.

Para los errores de logón, también podremos utilizar la opción de permitir un logón directo al sistema si ocurre un error.

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 neceitamos mantener las propiedades de servicio para cada servicio de forma individual, en la transacción SICF, podemos hacerlo en los nodos superiores.

Todos los servicios que se encuentren bajo este nodo heredan las configuraciones del nodo, a menos que explícitamente modifiquemos las propiedades de un servicio particular que está debajo del nodo 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 (Mantain Servicie) de la transacción SCIF cuando creamos un servicio, creamos aquí un alias interno.

En vez de almacenar un HTTP request handler, usaremos el servicio que definiremos en la solapa Alias Tag, con un doble clic y seleccionando desde el árbol de servicios ICF a que servicio apuntará.

Esto nos permite llamar a un servicio que no queremos alterar su configuración mediante un alias interno donde podremos usar una configuración diferente, por ejemplo un logón diferente.

No debemos crear alias internos a los servicios SAP que se encuentran debajo del nodo /sap/

Para permitir el llamado de un servicio con su nombre descriptivo en vez de su nombre técnico podremos usar los alias externos.

Para esto cambiamos a la vista Mantain External Aliases en la transacción SICF.

Un alias externo podría, contener una barra (/) en el nombre, a diferencia de una alias interno. Para que no se utilicen de la misma manera.

MONITOREO

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

Podemos usar el ICF recorder para almacenar las solicitudes registradas en la base de datos del sistema. Facilita la investigación del problema, ya que en la mayoría de caso una descripción del problema no es necesaria para reproducir el error.

La solicitud con el problema puede ser reprocesadas mediante el uso de la entrada en la base de datos. Permitiéndonos usar el debuggin o traza

Para utilizar el ICF recordes desde la transacción SICF, MENU -> EDIT > RECORDER > ACTIVATE RECORDING / DEACTIVATE RECORDIGN / DISPLAY RECORDINF.

La transacción SICFRECORDER la podemos usar para evaluar los registros

Siguiendo estos pasos:

1. Activar el registro, determinamos:

· la URL que será registrada (si hemos seleccionado el servicio desde el árbol previamente, el sistema lo propone)

· La duración del registro en tiempo (Record Time)

· el tiempo de almacenamiento en la base de datos (Lifetime)

· si se registraran las llamadas por un usuario particular o todos los usuarios.

2. Llamar al servicio que queremos monuitorear

3.


 

 

 


Sobre el autor

Publicación académica de Josep Antoni Lopez Moyano, en su ámbito de estudios para la Carrera Consultor Basis NetWeaver.

✒️+Comunidad Académica CVOSOFT

Continúe aprendiendo sobre el tema "Internet Communication Framework" de la mano de nuestros alumnos.

SAP Master

ICF: Conexión de seguridad a internet (Internet communication framework) Internet communication framework (ICF) permite comunicarse con el sistema SAP utilizando protocolos estándar de Internet (HTTP, HTTPS y SMTP). ICF es un componente integrado de Application Server. Comunicación mediante el ICF ofrece los siguientes beneficios: %u25CF Flexibilidad: El uso de la CIF, el usuario puede abrir una conexión a un sistema SAP a través de Internet desde cualquier lugar. %u25CF esfuerzo técnico: El esfuerzo requerido para la instalación y la configuración es relativamente pequeño. %u25CF Seguridad: El protocolo HTTPS garantiza la transferencia segura de datos. El nivel de seguridad...

Acceder a esta publicación

Creado y Compartido por: Edwart Gustavo Rodriguez Garzon

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Expert


Internet Communication Framework (ICF): provee un entorno para el manejo de solicitudes web dentro del work process ABAP. Permite establecer la comunicación entre diferentes sistemas sobre internet usando protocolos estándar. No se requiere librerías de programas SAP adicionales (exceltp SAPCRYPTOLIB). Hay una clase ABAP detrás de un HTTP request handler. Esta clase implementa la interface IF_HTTP_EXTENSION y el método HANDLE_REQUEST. SAP entrega estas clases, pero pueden crerse algunas personalizadas mediante SE24. Los servicios ICF pueden activarse o no mediante SICF. Para que ICF almacene solicitudes registradas en la base de datos del sistema, se usa el ICF recorder que se usa con la transacción...

Acceder a esta publicación

Creado y Compartido por: Daniel Alejandro Monteros Segura

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Senior

Internet Communication Framework (ICF) El Internet Communication Framework (ICF) 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 mas informacion sobre algunos aspectos de la administracion. 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 sera 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 communicaction framework (ICF) permite establecer la comunicacion entre diferentes sistemas sobre internet usando protocolos estandar...

Acceder a esta publicación

Creado y Compartido por: Meyer Macabeo

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Master

El ICF provee un entorno para el manejo de solicitudes WEB dentro del Works Process ABAP dentro de un sistema SAP. Cuando en la implementación de SAP queremos usar aplicaciones WEB basadas en WEB Dympro, BSPs o el ITC integrado para la comunicación con los sistemas SAP a internet, es nuestra tarea como administradores del sistema crear las conexiones entre las llamadas URLs y los servicios y programas de los sistemas SAP. Clasificación de los ICF El ICF permite establecer la comunicación entre diferentes sistemas sobre internet usando protocolos estándar como el HTTP y el SMTP, para el HTTPS debe existir la librería criptográfica de SAP SAPCRYPTOLIB la cual debe estar configurada. Esto lo podemos...

Acceder a esta publicación

Creado y Compartido por: Mauro Ramón Colina Gando

*** CVOSOFT - Nuestros Alumnos - Nuestro Mayor Orgullo como Academia ***

SAP Senior

La conexion de una URL particular con un HTTP request handler es la tarea de los servicios ICF.

Acceder a esta publicación

Creado y Compartido por: Miguelito Marcelo Blas Chimbe

 


 

👌Genial!, estos fueron los últimos artículos sobre más de 79.000 publicaciones académicas abiertas, libres y gratuitas compartidas con la comunidad, para acceder a ellas le dejamos el enlace a CVOPEN ACADEMY.

Buscador de Publicaciones:

 


 

No sea Juan... Solo podrá llegar alto si realiza su formación con los mejores!