En SAP S/4HANA, el usuario final utiliza la interfaz (SAP GUI) para conectar el despachador del servidor de aplicaciones.

El despachador selecciona un proceso de trabajo de diálogo libre (DIA) para procesar la solicitud de inicio de sesión. Si se configura el equilibrio de carga, la conexión se realizará al servidor de mensajes, después de lo cual el usuario será redirigido al despachador del servidor de aplicaciones con la mayor cantidad de recursos disponibles. Durante el proceso de inicio de sesión, se fija la asignación del usuario al servidor de aplicaciones. El usuario permanece en el servidor de aplicaciones asignado hasta que cierra la sesión.

Un proceso de trabajo DIA no está reservado a un único usuario. Una vez que se procesa la solicitud de un usuario, el proceso de trabajo vuelve a estar disponible para otra solicitud del mismo usuario o de uno diferente. De esta manera, el procesamiento de transacciones que constan de múltiples pantallas se puede ejecutar utilizando múltiples procesos de trabajo de diálogo. Este proceso de distribución se llama multiplexación. La multiplexación de procesos de trabajo significa que una función con contenido que está conectado lógicamente pero que consta de múltiples subpasos puede procesarse mediante diferentes procesos de trabajo de diálogo.

Los procesos de trabajo de diálogo utilizan diferentes áreas de memoria. Algunas áreas de memoria se utilizan exclusivamente para el proceso de trabajo del diálogo (memoria dinámica), mientras que otras son compartidas por todos los procesos de trabajo (memoria entre procesos). Como los procesos de trabajo no se asignan exclusivamente a las sesiones de los usuarios, los datos y el contexto deben estar disponibles al comienzo de un paso de diálogo (desplegado) y guardados al final del paso de diálogo (desplegado), para que la siguiente solicitud del usuario ( pantalla en la misma transacción) puede ser tratado por otro proceso de trabajo que comience donde terminó el primero.

El número y los tipos de procesos de trabajo se configuran en el perfil de la instancia y se determinan al iniciar el servidor de aplicaciones. Puede haber situaciones en las que todos los procesos de trabajo estén ocupados. Para resolver estos puntos muertos, se pueden activar procesos de trabajo dinámicos y en espera:

• Procesos de trabajo de diálogo en espera: se inician junto con los demás procesos de trabajo al inicio de la instancia. Se mantienen libres durante el funcionamiento normal y sólo se utilizan cuando el servidor de aplicaciones identifica un cuello de botella y necesita procesos de trabajo adicionales para resolver el problema. El número de procesos de trabajo en espera se define mediante el parámetro de perfil rdisp/wp_no_restricted. En la descripción general del proceso Transaction SM50, los procesos de trabajo de diálogo en espera se indican mediante el estado en espera (ver figura a continuación).
• Procesos de trabajo dinámicos: Puede ser de tipo diálogo o actualización. Cuando todos los procesos de trabajo tienen el estado de retención, el servidor de aplicaciones inicia los procesos de trabajo dinámicos. Cuando se resuelve el cuello de botella, se vuelven a detener. Cuando se inicia el servidor de aplicaciones, el valor del parámetro de perfil rdisp/wp_max_no se establece automáticamente en la suma de los procesos de trabajo configurados más cinco procesos de trabajo dinámicos.

Las tareas de larga duración en transacciones en línea se cancelan después de exceder un límite de tiempo configurable. Esto garantiza que los procesos de trabajo de diálogo no sean bloqueados por programas de larga ejecución y obligue a los usuarios a iniciar esas tareas en segundo plano. El tiempo de ejecución máximo se puede priorizar aún más estableciendo diferentes límites de tiempo en solicitudes altas, medias y bajas. El parámetro rdisp/scheduler/prio_high/max_runtime establece el tiempo de ejecución para solicitudes de alta prioridad, como las solicitudes provenientes de usuarios finales. El parámetro rdisp/scheduler/prio_ normal/max_runtime hace lo mismo para solicitudes con una prioridad media, como las solicitudes RFC. El tiempo de ejecución máximo para solicitudes de baja prioridad, como tareas de diálogo activadas por solicitudes en segundo plano, se puede configurar mediante el parámetro rdisp/scheduler/prio_low/max_runtime. Tenga en cuenta que el parámetro rdisp/max_wprun_time reemplaza a los demás. Si se ha configurado, sobrescribe las configuraciones más detalladas. Recomendamos reemplazar el parámetro rdisp/max_wprun_time con los parámetros anteriores, ya que brindan mucha más flexibilidad.

El parámetro rdisp/max_wprun_time está en desuso: El mecanismo más antiguo y ampliamente utilizado para controlar los tiempos de espera de las sesiones es establecer el parámetro de perfil rdisp/max_wprun_time. A partir de SAP S/4HANA 2020, este parámetro se elimina del ABAP Se deben utilizar el kernel y los tiempos de espera basados ​​en prioridades (consulte la nota SAP 2918906).

Los grandes sistemas productivos tienen múltiples servidores de aplicaciones. Estos tienen en la mayoría de los casos el mismo número y tipo de procesos de trabajo para mejorar el equilibrio de carga y garantizar la continuidad, en caso de que falle uno de los servidores de aplicaciones. Aunque es una buena práctica configurar los servidores de aplicaciones de la misma manera, no es obligatorio. Los servidores de aplicaciones pueden tener una cantidad diferente de procesamiento de trabajo dependiendo de sus recursos de hardware, como su cantidad de memoria y CPU.

El rendimiento se puede mejorar utilizando grupos de inicio de sesión para separar la carga de diálogo de otras cargas generadas, por ejemplo, por el procesamiento en segundo plano. Los grupos de inicio de sesión también se pueden utilizar para separar el procesamiento de llamadas a funciones remotas (RFC). Los grupos de inicio de sesión se pueden crear y mantener con Transaction SMLG (Mantener grupos de inicio de sesión).

Comando del sistema operativo para monitorear el servidor de mensajes: El comando lgtst del sistema operativo se puede utilizar para probar la conexión al servidor de mensajes y enumerar los grupos de inicio de sesión disponibles. El comando enumera las instancias de SAP disponibles y los grupos de inicio de sesión con sus favoritos. Para obtener más información, consulte la nota SAP 64015.

Nota del editor: esta publicación ha sido adaptada de una sección del libro. Administración SAP S/4HANA por Mark Mergaerts y Bert Vanstechelman.