✒️SAP BASIS / El concepto de proceso de fondo Por Fernando Escola

El concepto de proceso de fondo

El procesamiento en fondo está diseñado para ejecutar reportes regulares y programas de larga duración, los cuales se planifican como "jobs" (trabajos) en el sistema SAP. El administrador del sistema es el encargado de planificar estos jobs y supervisar su procesamiento para garantizar que se ejecuten correctamente.

• Procesos de diálogo vs. Procesamiento en fondo: Los procesos de trabajo de diálogo (Dialog work processes) se encargan de procesar las solicitudes de los usuarios finales y deben estar disponibles de inmediato, sin tiempos de espera perceptibles. Por lo tanto, los procesos de diálogo solo deben utilizarse para tareas con tiempos de procesamiento cortos, maximizando el rendimiento y la disponibilidad rápida del sistema.

• Limitación de tiempo (parámetro rdisp/max_wprun_time): Para evitar que los procesos de diálogo queden bloqueados por programas de larga duración (lo que interferiría con la operación en línea), existe el parámetro de perfil de sistema rdisp/max_wprun_time (válido hasta SAP_BASIS 754). Este parámetro limita el tiempo máximo de ejecución de un paso de diálogo (dialog step). Si el programa supera este tiempo máximo establecido, se termina automáticamente. Los detalles específicos se encuentran en la Nota SAP 25528.

A partir de la versión SAP_BASIS 740, se introdujo una configuración más precisa que permite establecer el tiempo máximo de ejecución mediante tres parámetros independientes, dependiendo de la prioridad del kernel:

• rdisp/scheduler/prio_high/max_runtime: Para solicitudes ejecutadas con prioridad alta (por ejemplo, solicitudes de GUI).

• rdisp/scheduler/prio_normal/max_runtime: Para solicitudes ejecutadas con prioridad media (por ejemplo, solicitudes RFC).

• rdisp/scheduler/prio_low/max_runtime: Para solicitudes ejecutadas con prioridad baja (por ejemplo, solicitudes de diálogo desencadenadas por solicitudes en fondo).

Regla de compatibilidad y cambios en versiones recientes:

• Si el parámetro antiguo rdisp/max_wprun_time está configurado explícitamente, su valor sobrescribe a las tres configuraciones específicas mencionadas arriba. Debido a esto, en versiones anteriores a SAP_BASIS 755, los valores de los nuevos parámetros a menudo quedaban sobrescritos, perdiéndose el beneficio de la flexibilidad.

• A partir de la versión SAP_BASIS 755, el parámetro antiguo rdisp/max_wprun_time es eliminado por completo del kernel ABAP y se remueve de los perfiles durante la actualización (detalles en la Nota SAP 2918906).

• Ventajas y problemas de compatibilidad: El conjunto de los tres nuevos parámetros proporciona mayor flexibilidad y SAP asume que sus valores predeterminados satisfacen a la mayoría de los clientes. Sin embargo, cambiar un perfil antiguo donde estaba configurado el parámetro original a los nuevos valores basados en prioridad podría causar incompatibilidades si el código ABAP de la aplicación no está bien escrito.

Los procesos de trabajo en fondo (también llamados procesos de trabajo batch o "B", coordinados por el ABAP Dispatcher junto a los de diálogo o "D") se utilizan principalmente para:

• Agendar tareas con tiempos de ejecución altos.

• Liberar recursos de los procesos de diálogo.

• Agendar tareas periódicas o recurrentes, tales como la copia de seguridad diaria de la base de datos o el trabajo de cierre de mes para la contabilidad financiera.

Gestión y responsabilidades de los Jobs:

• Para definir nuevos jobs se utiliza la transacción SM36. Desde allí también se puede invocar el Asistente de Job (Job Wizard) mediante la transacción SM36WIZ.

• Alternativamente, se pueden planificar tareas en fondo desde la transacción SA38, en conjunto con numerosas transacciones de aplicación.

• En la mayoría de los casos, las tareas en fondo son planificadas por expertos en los departamentos de usuario. La responsabilidad del administrador del sistema es asegurarse de que esos jobs planificados puedan ejecutarse realmente (garantizando una configuración de sistema adecuada).

Al definir un job en el sistema, es necesario introducir obligatoriamente la siguiente información:

• Especificaciones generales: Incluye el nombre del job, la clase o prioridad del job (que por defecto es "C") y, opcionalmente, el objetivo de ejecución o servidor (o grupo de servidores) de destino.

• Definición de pasos (job steps): Definición de uno o más pasos individuales que componen el trabajo.

• Definición de una condición de inicio: Puede ser dependiente del tiempo (fecha/hora) o dependiente de un evento del sistema.

Diferencias entre el método Clásico y el Asistente: El Asistente de Job (Job Wizard) ayuda a definir los trabajos guiando al usuario fácilmente a través del proceso de creación. La elección entre el método "clásico" o el Asistente no influye en el resultado final del job. Sin embargo, algunas funciones avanzadas, como especificar un usuario SAP para cada paso o el intercambio de pasos (swapping steps), no están disponibles si se utiliza el Asistente de Job.

Jobs y pasos de Jobs

Cada job en SAP se compone de uno o más pasos (job steps) y es procesado sin interrupción por un único proceso de trabajo en fondo (background work process).

Un paso dentro de un job puede ser de tres tipos diferentes:

• Programa ABAP: Cualquier programa ABAP del sistema se puede planificar como un paso de un job en fondo.

  • Si el programa cuenta con pantallas de selección (selection screens) que requieren datos de entrada, es necesario crear previamente una variante (variant). Los valores almacenados en ella se utilizarán automáticamente durante la ejecución.

  • Si el programa genera una salida de pantalla como resultado, esta se guardará en una lista spool. Al definir el job, se puede especificar un destinatario para que reciba dicha salida por correo electrónico una vez finalizada la ejecución.

  • También se debe especificar una impresora para la creación de las listas spool, aunque el procesamiento en fondo no implica necesariamente una salida directa e inmediata en formato físico (depende del método de acceso de la impresora).

• Comando Externo (External Command): Consiste en una llamada a un script, comando o programa predefinido a nivel de sistema operativo. Mediante los comandos externos se pueden "enmascarar" las llamadas reales al sistema operativo y almacenarlas en SAP bajo un nombre electivo. Este tipo de paso permite utilizar el concepto de autorizaciones de SAP para proteger su ejecución, determinando qué usuarios específicos pueden ejecutarlos y en qué servidores o sistemas operativos de destino.

• Programa Externo (External Program): Es cualquier comando directo del sistema operativo. A diferencia de los comandos externos, el concepto de autorización de SAP para programas externos solo valida de forma general si un usuario puede o no llamar programas externos, pero no proporciona una asignación de autorización detallada a nivel de nombres de programa. Para restricciones precisas, se deben usar obligatoriamente los comandos externos.

Con la definición clásica de jobs a través de la transacción SM36, el administrador o creador puede asignar un usuario específico de ejecución a cada paso individual del job. El ID de este usuario es el que se utiliza para realizar las verificaciones de autorización correspondientes mientras se ejecuta dicho paso.

• Asignación por defecto: El sistema toma automáticamente el nombre del usuario que está conectado en ese momento.

• Modificación: Es posible ingresar un nombre de usuario diferente si el paso del job debe ejecutarse bajo autorizaciones distintas a las del creador.

• Objetos de autorización clave: * S_BTCH_NAM: Objeto de autorización necesario para poder ingresar en el campo de usuario nombres que no sean el propio del creador.

  • S_BTCH_NA1: Una mejora del objeto anterior que controla no solo el campo de usuario del paso, sino también el nombre del programa ABAP asociado.

Para optimizar la seguridad y la gestión de tareas, es de gran utilidad configurar usuarios técnicos de paso (también llamados usuarios de fondo o background users) para las distintas áreas de trabajo. Estos usuarios poseen de forma dedicada las autorizaciones necesarias para las actividades requeridas del negocio.

• Aplicación práctica: Los usuarios finales con autorizaciones estándar pueden utilizar estos usuarios de fondo específicos para planificar tareas dentro de su área correspondiente (por ejemplo, para tareas de administración del sistema).

• Tipo de usuario: Al crear estos usuarios de paso en el sistema, se debe configurar explícitamente el tipo de usuario como System (Sistema).

• Características de seguridad del tipo System:

  • No es posible realizar un inicio de sesión de diálogo (log on) de forma interactiva en el sistema con este tipo de usuario.

  • Están exentos de las configuraciones y políticas habituales de vencimiento periódico de contraseñas.

  • La contraseña de un usuario de sistema solo puede ser modificada directamente por los administradores de usuario mediante la transacción SU01.

• Riesgo de seguridad: Los usuarios finales no deben tener permitido bajo ninguna circunstancia el uso de usuarios técnicos que posean más autorizaciones que su propio usuario de diálogo habitual, ya que esto representaría una brecha de seguridad en el sistema.

A diferencia de la creación clásica, el Asistente de Job (Job Wizard o transacción SM36WIZ) presenta una limitación importante: no ofrece la opción de especificar un usuario dedicado para cada paso. Cuando se utiliza el Asistente para definir un trabajo, el sistema incluye de manera automática el nombre del usuario que está conectado actualmente en la verificación de autorización de cada uno de los pasos.

Además de la hora planeada de inicio, el sistema SAP clasifica los jobs en fondo según su nivel de criticidad o urgencia utilizando tres categorías principales:

• Clase A: Representa la prioridad más alta.

• Clase B: Representa una prioridad media.

• Clase C: Representa la prioridad normal o estándar.

Cuando se combina la clase del job con la asignación o no de un servidor específico, el sistema establece una escala de 6 niveles de prioridad adicionales (ordenados desde la prioridad más alta a la más baja):

1. Clase A, Job con grupo de servidor de destino: Recibe la máxima preferencia de procesamiento en el sistema.

2. Clase A, Job sin grupo de servidor de destino.

3. Clase B, Job con grupo de servidor de destino.

4. Clase B, Job sin grupo de servidor de destino.

5. Clase C, Job con grupo de servidor de destino.

6. Clase C, Job sin grupo de servidor de destino: Representa el nivel más bajo de prioridad en la cola de ejecución.

Mecanismo de preferencia por Servidor Especifico: Si un job está configurado para ejecutarse en un servidor en particular o en un grupo de servidores de job determinado, el sistema lo manejará de manera preferencial en comparación con otros jobs que pertenezcan a su misma clase.

Esta asignación de preferencias es crítica y solo entra en juego cuando múltiples jobs con diversas prioridades solicitan recursos de procesamiento en fondo exactamente al mismo tiempo (por ejemplo, debido a que fueron planificados para iniciar a la misma hora).

Para garantizar el rendimiento óptimo y el equilibrio del sistema SAP, se deben seguir las siguientes directrices de configuración:

• Distribución de la carga: Se debe asegurar que la gran mayoría de todas las tareas en fondo del sistema (aproximadamente el 90% de la totalidad de los jobs) se planifiquen normalmente con la prioridad más baja, es decir, como Clase C y sin especificar un servidor de destino. Esto permite que el sistema distribuya los recursos de manera dinámica según la disponibilidad.

• Tareas automáticas del Sistema: Las tareas en fondo nativas o de "Sistema" también se ejecutan de manera estándar bajo esta misma premisa (Clase C y sin servidor asignado). Un ejemplo claro de esto son las tareas automatizadas relacionadas directamente con el mantenimiento de la base de datos, las cuales se planifican de manera habitual a través de la transacción DBACOCKPIT.

Un job en fondo en el sistema SAP puede ser planificado, agendado o desencadenado principalmente a través de dos grandes criterios o metodologías:

• Basado en Tiempo (Date/Time): El trabajo se configura para ejecutarse bajo condiciones cronológicas específicas.

  • Permite planificar el job en una fecha y una hora exactas determinadas por el administrador o usuario.

  • Incluye la opción de configurar la hora de inicio de forma "inmediatamente", lo que da la orden al sistema de procesarlo lo antes posible.

  • Nota importante sobre recursos: Si en el momento exacto en que se libera el job (ya sea por cumplimiento de la hora o por la orden de ejecución inmediata) no existen procesos de trabajo en fondo libres en el sistema, el job no se perderá; en su lugar, se volverá a planificar de manera automática utilizando la fecha y hora actual disponible como la nueva condición de inicio.

• Basado en Eventos (Event): El trabajo es dirigido y activado por la ocurrencia de un suceso específico dentro del entorno de SAP.

  • Se activa por la aparición de un evento particular previamente definido en el sistema SAP.

  • Este criterio incluye aquellos jobs que deben iniciarse obligatoriamente después de que otros jobs hayan finalizado, o bien aquellos que se disparan de forma automática durante cambios en el modo de operación del sistema (operation mode changes).

  • Nota importante sobre recursos: Del mismo modo que el criterio basado en tiempo, si ocurre el evento desencadenante pero no hay procesos de trabajo en fondo libres y disponibles, el sistema guardará la solicitud y planificará el job con la fecha y hora actual disponible como nueva condición de inicio.

El segundo recorte incluye una recomendación didáctica orientada al uso de herramientas de Inteligencia Artificial para profundizar en la optimización técnica de la plataforma. Propone copiar y pegar un texto específico para consultar cómo resolver problemas críticos de rendimiento y seguridad:

• Optimización de parámetros: Analizar cómo usar los nuevos parámetros de kernel introducidos en la versión SAP_BASIS 755 (prio_high, prio_normal, prio_low) para mitigar y solucionar los bloqueos por Time-outs en los procesos de diálogo provocados por reportes extensos.

• Seguridad en la gestión de usuarios: Estudiar detalladamente los pasos para la creación de un 'Usuario de Sistema' enfocado en la ejecución de jobs técnicos, fundamentando a nivel arquitectónico por qué este enfoque resulta mucho más seguro que delegar dichas tareas a un 'Usuario de Diálogo' convencional.