✒️SAP Web Dispatcher

LECCION 10: SAP WEB DISPATCHER

1.- Implementacion del SAP Web Dispatcher

Deberemos considerar el uso del SAP Web Dispatcher si las aplicaciones Web que estamos operando en el sistema SAP son implementadas como aplicaciones en ABAP (por ejemplo, BSPs) y/o en JAVA.

Algunos requisitos que motivaron el desarrollo del SAP Web Dispatcher:

· Las aplicaciones Web serán utilizadas desde internet. La red de la compañía esta protegida mediante una zona DMZ (Demilitarized Zone) y los procesos críticos de negocio corren sobre servidores que no son reconocidos en Internet. ¿Cómo podemos evitar tener que incorporar los servidores de aplicación SAP dentro de la DMZ?

· El sistema SAP en cuestión consiste de multiples servidores de aplicación (instancias) que están distribuidas entre diferentes hosts. De todas formas, las aplicaciones Web provistas deberían correr bajo una dirección descriptiva; los detalles técnicos tal como el nombre del servidor y numero de puerto permanecerían ocultos a los usuarios.

· ¿De que manera podría una distribución sensible implementarse? Todos los servidores de aplicación podrían no proveer todos los servicios (ICF o un Stack JAVA).

Los requerimientos de este tipo, pueden ser implementadas utilizando productos de terceros conocidos como Proxies Iinversos o Conmutadores Web (Web switches). Aunque hay algunas ventajas, tales como el alto throughput e implementación de bajo nivel con el hardware, las desventajas que tienen es el costo adicional que representan y una integración limitada a SAP.

Nota: El SAP Web Dispatcher es relevante solo en un entorno Web. Cuando un SAP GUI se utiliza para el acceso, el ABAP Message Server se encarga de la distribución de carga.

En principio, el Message Server puede también distribuir la carga de solicitudes HTTP(s), pero sus funciones están limitadas en contraste al SAP Web Dispatcher, por lo cual SAP recomienda que se utilice este ultimo.

2.- Funciones del SAP Web Dispatcher

El SAP Web Dispatcher reenvia las solicitudes HTTP(S) a un servidor de aplicación especifico. Esta sección describe el criterio por el cual se realiza esto.

Una solicitud HTTP es asignada a un servidor en dos etapas:

Primero, el SAP Web Dispatcher determina si la solicitud HTTP será reenviada a un servidor ABAP o JAVA. Luego encuentra un grupo de servidores en el sistema que pueda ejecutar la solicitud.

La distribución de carga se lleva a cabo dentro de esta grupo. Despues que el SAP Web Dispatcher ha identificado el servidor, reenvia la solicitud al ICM del servidor de aplicación elegido.

NOTA: Un SAP Web Dispatcher puede distribuir solicitudes para solo un sistema SAP.

Si multiples sistemas SAP son requeridos, será necesario configurar diferentes procesos de SAP Web Dispatcher para cada uno de los sistemas (aunque podrían correr el simultaneo en una computadora).

El SAP Web Dispatcher es compatible de forma retroactiva, esto es, la versión del SAP Web Dispatcher puede ser mas alta o igual a la versión del sistema back-end de SAP. El nivel de parche también puede diferir del nivel de parche del sistema back-end.

Para los sistemas basados en SAP Web AS 6.40 o SAP Netweaver AS 7.0, recomendamos utilizar el SAP Web Dispatcher 7.00 provisto que sea compatible con el sistema operativo utilizado.

Selección de Server

El SAP Web Dispatcher primero verifica si la solicitud debe ser procesada por el stack ABAP o JAVA del sistema SAP. Esta distinción esta basada en el prefijo de la URL. Para la URL http://adm102.sap.com/A/B/C/Default.html, el prefijo que es analizado es la cadena /A/B/C.

Si este prefijo es conocido en el ICF, esto es una solicitud ABAP. Si la solicitud contiene solo un carácter / (slash), luego del nombre de host, requiere un tratamiento especial: el valor del perfil de parámetro is/HTTP/default_root_hdl determina el destino.

En el caso de una solicitud ABAP, el SAP Web Dispatcher primero usa una cookie para identificar si la solicitud es una aplicación stateful. Si esto existe, la decision es simple.

La solicitud es enviada al servidor de aplicación que esta procesando ya esta sesión. Para una aplicación stateless, el grupo interno !DIAG es seleccionado, el cual consiste de todos los servidores de aplicación ABAP. Esto es usado solamente si un grupo de logon (creado mediante la trx SMLG) es especificado explícitamente en el servicio ICF.

El AS JAVA también reconoce el concepto de grupos logon. Si un grupo de logon especifico no ha sido configurado para el prefijo de la solicitud JAVA, el SAP Web Dispatcher usa el grupo interno !J2EE. En el caso de una aplicación statful, esto es indicado a través de la información de sesión en la URL o una cookie. Por razones de compatibilidad, la cookie de sesión jsessionid puede también ser utilizada aquí.

El SAP Web Dispatcher obtiene información sobre los grupos de logon y el mapeo de URLs del servidor de aplicación ABAP via HTTP(s). Para que esto suceda, el servicio /sap/public/icman y /sap/public/icf_info/* deben ser activados en el ICF.

Balance de Carga

El SAP Web Dispatcher obtiene información sobre los servidores de aplicación del sistema SAP del message server via HTTP(S). Es posible usar el SAP Web en sistemas ABAP puros asi también como en sistemas combinados ABAP JAVA y sistemas JAVA puro. De este modo, la opción de instalación determina el message server con el cual el SAP Web Dispatcher se comunica.

Partes involucradas en la comunicación del SAP Web Dispatcher para la información de Servidores.

NOTA: El SAP Web Dispatcher usa los parámetros rdisp/mshost y ms/http_port para especificar el message server asignado del sistema SAP.

Por las razones de compatibilidad, el parámetro obsoleto ms/http_port aun funciona en el sistema SAP para el menssage server ABAP pero no debería continuar utilizándose.

L a interface HTTP del message server permite mostrar información sobre el servidor de aplicación con un navegador Web. Para esto, llamamos a la URL: http:77<server>:<port>/msgserver/commands

El SAP Web Dispatcher distribuye las solicitudes en turnos del grupo de servidores seleccionando por defecto acorde a la capacidad de carga de cada uno de los servidores de aplicación. Para ABAP, la capacidad se calcula a partir del numero de procesos de dialogo(dialog Work processes) y para JAVA, del numero de server processes.

Podemos usar el perfil de parámetro wdisp/load_balancing_strategy para configurar el SAP Web Dispatcher con diferentes procedimientos de balanceo de carga.

3.- Operaciones del SAP Web Dispatcher

La estructura interna del SAP Web Dispatcher esta basado en el procese ICM. Un archivo de perfil también es utilizado en este caso para determinar la configuración con la cual SAP Web Dispatcher es iniciado. Es muy fácil copiar y usar el archivo ejecutable (sapwebdisp.exe) junto con el perfil en un servidor por separado del sistema SAP.

Parámetros de Perfil:

Para plantillas el perfil y descripción de parámetros, puedes consultar documentación online. El SAP Web Dispatcher esencialmente solo necesita conocer el puerto en el cual recibirá las solicitudes HTTP (parámetro icm/server_port_) y en que host (rdisp/mshost) y con que puerto HTTP (ms/http_port) puede acceder al message server.

Nota: Si se va a intercambiar metadata via HTTPS, algunos pasos adicionales son requeridos (consultar documentación online).

Desde SAP Web AS 6.40 es posible también iniciar el SAP Web Dispatcher sin un archivo de perfil. Para esta opción de bootstrap (iniciada con el comando sapwebdisp-bootstrap), los siguientes pasos se llevan a cabo:

Si el archivo de perfil sapwebdisp.plf no existe aun, es creado basado en las entradas de manera interactiva.

Si la autorización del archivo ecmauth.txt no existe, es creado y un usuario es ingresado para la administración Web

El SAP Web Dispatcher es iniciado con el archivo de perfil creado.

4.- Go Live (Sin opción Bootstrap)

Iniciamos el SAP Web Dispatcher con el comando del sistema operativo sapwebdisp pf= , donde podemos configurar opciones adicionales tal como un archivo y nivel de traza.

Nota: En Microsoft Windows, podemos configurar el SAP Web Dispatcher como un servicio con el comando ntscmgr install sawebdisp – b sapwebdisp.exe –p “servicio pf=”.

Para detener el SAP Web Dispatcher usamos el comando kill del sistema operativo. Para esto necesitamos conocer el ID de proceso (PID), el cual se puede identificar con la salida del comando cuando es iniciado o desde el archivo de traza (por defecto dev_sapwebdisp). En Unix, el comando kill -2; en Microsoft Windows, es sapntkill –INT

5.- MONITOREO

Podemos monitorear el SAP Web Dispatcher con el comando icmon el cual vimos en una lección previa. Cuando hacemos esto, no debemos modificar el archivo de perfil para el SAP Web Dispatcher.

Desde el SAP Web AS 6.40, existe una interface Web para administrar y monitorear el SAP Web Dispatcher. Para usarla, los siguientes prerrequisitos deben cumplirse:

· Hemos descomprimido el paquete de instalación SAP Web Dispatcher en un directorio.

· El archivo icmauth.txt existe para los administradores autorizados.

· En el archivo de perfil del SAP Web Dispatcher, el parámetro icm/HTTP/admin_existe.

Luego podemos llamar a la interface Web de Administracion usando la URL:http//<servidor>:<puerto>/<prefijo>.

Nota: Por razones de seguridad, utiliza HTTPS para administración. Si usamos HTTP, las contraseñas de administrador se transfieren sin encriptación y podrían ser capturadas.

Los dato de logon se verifican contra el archivo icmauth.txt. Sin iniciamos el SAP Web Dispatcher con la opción bootstrap, este es generado automáticamente. Podemos editar las entradas del archivo de autenticación icmauth.txt usando el programa icmon mediante el comando icmon-a.