Los procesos de dialogo ABAP.
La capa de Presentación.
Los usuarios, para trabajar, pueden loguearse al sistema utilizando diferentes front end, por ejemplo el clásico SAP GUI, también podrían utilizar un navegador y así trabajar con las aplicaciones de SAP que estén desarrolladas para este tipo de interfaz de usuario.
En ambos casos, por default, los programas que conforman esas aplicaciones están desarrollados para que sean ejecutados en el entorno ABAP de nuestro sistema SAP. No importa si son transacciones clásicas o aplicaciones web, por default serán ejecutadas por el proceso de diálogo de instancia ABAP.
Nota: las aplicaciones web también pueden ser desarrolladas en JAVA por lo que serían procesadas por ese entorno.
Procesando solicitudes de SAP GUI.
El procesamiento de solicitud de un usuario funciona así: por ejemplo al ejecutar una transacción, en el servidor de aplicación ABAP; este procesamiento integra diferentes procesos en las tres capas que son la de presentación, la de aplicación y por último la base de datos. Teniendo en cuenta esto al ejecutar una transacción o cambiar de pantalla dentro de una misma función este proceso es tomado por el programa o capa de presentación SAP GUI, el cual lo convierte en un formato interno y lo envía al AS ABAP; como habíamos visto anteriormente el dispatcher (ABAP) es el proceso central de AS ABAP que se encarga de gestionar los recursos para las aplicaciones escritas en ABAP en coordinación con el sistema operativo en el cual tenemos instalado nuestro sistema SAP; las funciones principales del dispatcher incluye la distribución entre los work processes) e integrarla capa de presentación y organizar las comunicaciones.
La solicitud es enviada por el GUI, queda en la cola de solicitudes en el dispatcher y en cuanto existe un proceso de dialogo libre, la solicitud es enviada por el dispatcher a ese Dialog work process.
Para poder procesar las solicitudes de usuario, frecuentemente el work process necesitara leer o escribir los datos en la BD, esto significa que cada proceso de trabajo esta conectado a la Base de Datos.
Una vez que la solicitud ha sido procesada por el work process, la respuesta es enviada al dispatcher y éste envía al SAP GUI, el SAP GUI interpreta la respuesta y genera una pantalla para el usuario.
Los buffers que son conocidos como shared memory ayudan a agilizar el tiempo de la respuesta por parte del servidor de aplicación a la capa de presentación SAP GUI debido a que estos datos son accedidos frecuentemente, pueden alojarse en alguno de estos buffers, en vez de tener que solicitarlos a través de la consulta a la base datos.
Interface con la base de datos del sistema.
Dentro del lenguaje de programación ABAP, el programador puede utilizar el ABAP Open SQL (SQL = Structured Query Languaje) para acceder a los datos de la aplicación ABAP. Cuando se elige este método, el programador se independiza del RDBMS sobre el cual se instaló el sistema SAP. La interfaz de base de datos, que existe en cada work process del AS ABAP, traduce la sentencia Open SQL al correspondiente lenguaje SQL para la base de datos específica utilizada que sería el SQL Nativo.
Esto es importante porque de esta manera los programas ABAP aseguran que sean independientes de la base de datos. Otra de las ventajas de utilizar Open SQL, es que cuando la interface de base de datos del work process interpreta la sentencia intenta utilizar de manera óptima los buffers de AS ABAP, entre otros, se encuentran los programas ABAP, las pantallas, información del diccionario ABAP y tablas con datos estáticos.
También se puede utilizar SQL nativo para acceder a los objetos de la base de datos, esto quiere decir que la interface de la base de datos y el buffer local no serán utilizados.
Atención: si el programa ABAP tiene en su código sentencias de SQL Nativo, este perderá independencia de la plataforma de base de datos del sistema SAP.