✒️SAP BASIS / La configuración del entorno de proceso de fondo Por Fernando Escola

La configuración del entorno de proceso de fondo

Reserva de procesos para Jobs de clase A

En una operación estándar, los procesos de trabajo de fondo procesan jobs sin importar su prioridad. Sin embargo, el sistema permite reservar procesos de fondo específicamente para jobs de alta prioridad, conocidos como clase A.

Es importante destacar que esta función no reserva un proceso de trabajo específico de forma permanente, sino que garantiza que un número determinado de procesos se mantengan libres para ser utilizados por jobs de clase A siempre que sea necesario. Bajo esta configuración, los jobs de menor prioridad (clase B y C) solo podrán iniciarse si se respeta el cupo de procesos libres definido para la clase A.

Estrategias de Priorización

El administrador puede elegir entre dos enfoques principales para gestionar la carga de trabajo:

• Pista Crítica (Clase A) y Prioridad de Dos Niveles (Clases B y C): Se utiliza cuando existen tareas de misión crítica cuya ejecución inmediata debe estar garantizada. En este escenario, se reserva un proceso para la clase A y se asigna esta categoría únicamente a los jobs críticos, minimizando la posibilidad de que jobs de clase B o C bloqueen el sistema.

• Prioridad de Tres Niveles: Es un esquema de prioridad lineal donde no se reservan procesos para la clase A. Se recomienda cuando la carga de jobs de clase A es pequeña o cuando los cuellos de botella son poco frecuentes, ya que mantener una reserva en estos casos resultaría en un uso ineficiente de los recursos (procesos ociosos).

Configuración y Recomendaciones Técnicas

Para implementar la reserva de procesos, se debe acceder a la transacción RZ04 (CCMS: Editar Modos de Operación e Instancias). Allí se define el modo de operación y la distribución de los procesos de trabajo de fondo.

Las recomendaciones generales para una configuración óptima son:

• Normalmente es suficiente con reservar un solo proceso de trabajo de fondo para jobs de clase A por sistema.

• No se recomienda reservar más de un proceso de fondo para clase A por cada servidor de aplicación ABAP.

El Servidor de Destino y los Grupos de Servidores de Jobs

Para realizar la planificación dirigida de una tarea en fondo, únicamente se pueden utilizar aquellas instancias que dispongan de procesos de trabajo de fondo o que formen parte de un grupo de servidores de jobs.

Un grupo de servidores de jobs está constituido por una o más instancias que tienen procesos de trabajo de fondo disponibles. Su funcionamiento es análogo al de los grupos de logon empleados para los usuarios de diálogo. Estos grupos permiten procesar tareas de fondo correspondientes a distintas aplicaciones en instancias previamente seleccionadas.

Una de sus utilidades principales es aislar la carga de trabajo: permiten separar los jobs de los servidores de aplicación que están siendo utilizados por los usuarios de diálogo. En esta estrategia, el grupo de servidores de jobs contiene servidores de aplicación totalmente distintos a los asignados en los grupos de logon para usuarios (los cuales se gestionan mediante la transacción SMLG).

Lógica de Selección del Servidor de Ejecución

El flujo de asignación para la ejecución de un job depende directamente de si se especifica o no un servidor de destino:

• Si NO se especifica el servidor de destino: El sistema utiliza un balanceador automático de carga para determinar dónde se ejecutará la tarea.

• Si SÍ se especifica el servidor de destino: El administrador puede optar por dirigir la tarea hacia un Servidor Fijo específico o hacia un Grupo de servidores de jobs determinado.

Configuración, Notas SAP y Herramientas de Control

La gestión y el diagnóstico de estos grupos se realizan a través de transacciones específicas y cuentan con soporte en notas oficiales:

• Configuración (Transacción SM61): Para configurar un grupo de servidores de jobs, se debe iniciar la transacción SM61 (Visualizar lista de objetos de control) y seleccionar la opción "Grupos de Servidor de Jobs" (Job Server Groups) para definir el grupo y asignarle las instancias correspondientes.

• Notas SAP de Referencia: Para obtener información detallada sobre la administración de estos grupos, se puede consultar la SAP Note 612838. Adicionalmente, existe un grupo de servidor de jobs por defecto que se puede crear y utilizar siguiendo las indicaciones de la SAP Note 786412 (Determinación del servidor de ejecución de jobs sin servidor de destino).

• Verificaciones de Salud y Trazas: Dentro de la misma transacción SM61, se incluyen herramientas avanzadas de diagnóstico que permiten realizar verificaciones de salud (health checks) para los servidores de aplicación (lo que redirige a la transacción SM65) y modificar el nivel de traza (trace level) para los objetos de control de fondo mediante la barra de herramientas de la aplicación.

El procesamiento paralelo de los Jobs

El Problema de las "Noches Cortas"

En mandantes que manejan grandes volúmenes de datos, ciertos reportes que se ejecutan habitualmente en el sistema de procesamiento en fondo (como la planificación de materiales) sufren de tiempos de ejecución de muchas horas. Este escenario provoca que las ventanas de tiempo nocturno resulten insuficientes, una situación que se agrava significativamente cuando los usuarios de diálogo se encuentran distribuidos en múltiples zonas horarias.

Solución: Procesamiento Paralelo de Jobs

Para solucionar las limitaciones de tiempo, SAP permite implementar el procesamiento paralelo en reportes de larga ejecución. Esta técnica consiste en:

• División de la carga: El trabajo total a realizar se fragmenta en paquetes más pequeños.

• Distribución: Estos paquetes de trabajo se reparten entre los procesos de trabajo que se encuentren disponibles.

• Consolidación: Al finalizar, los resultados de cada paquete individual se recolectan y se sincronizan nuevamente.

Mecanismo de Ejecución y Procesos Involucrados

La lógica operativa del paralelismo se gestiona a nivel de código y mediante la asignación de diferentes tipos de procesos:

• Inicio del paso de job: Un paso de job se inicia de la manera habitual dentro de un proceso de trabajo de procesamiento en fondo.

• Lógica ABAP: Utilizando el comando específico CALL FUNCTION {Function Module} STARTING NEW TASK {Task} DESTINATION IN GROUP {Group}, el programa que corre en segundo plano se parametriza para que las porciones de datos fragmentadas se ejecuten concurrentemente en otros procesos de trabajo.

• Asincronía: El programa principal que realiza la llamada continúa su marcha inmediatamente después de que la función remota inicia en el sistema de destino, sin necesidad de detenerse a esperar que esta termine de procesar.

• Roles de los procesos: Mientras el job principal se mantiene en ejecución dentro de un proceso de fondo, todas las tareas paralelas derivadas se ejecutan en procesos de trabajo de diálogo, los cuales pueden pertenecer a cualquier servidor SAP del entorno.

Control de Servidores Mediante Grupos RFC

El direccionamiento de los recursos de hardware para estas tareas paralelas se puede administrar mediante la transacción RZ12:

• Asignación por defecto: De manera predeterminada, un job con procesamiento paralelo emplea de forma automática todos los servidores calificados en el sistema SAP según sus reglas automáticas. Esto equivale a invocar la función con el argumento DESTINATION IN GROUP DEFAULT.

• Uso de Grupos RFC: Para un control más estricto, el administrador puede definir Grupos RFC específicos. Un Grupo RFC delimita con exactitud el conjunto de servidores permitidos para la ejecución de un job de procesamiento paralelo en particular, regulando el balanceo de carga y controlando los límites de los recursos.

Definición de grupos RFC para Jobs de procesamiento paralelo

Un Grupo RFC cumple la función específica de determinar y delimitar el conjunto de servidores que están permitidos para ejecutar un job de procesamiento paralelo en particular.

Configuración y Documentación del Sistema

Para llevar a cabo la creación, gestión y parametrización de estos grupos, el sistema dispone de herramientas específicas:

• Transacción RZ12: Es la transacción dedicada y utilizada para definir de manera formal un grupo de servidor RFC. En su interfaz de mantenimiento (CCMS: RFC Server Group Maintenance) se pueden visualizar elementos como el grupo de logon (Logon Group), la instancia asociada y su estado actual.

• Ayuda F1: Las descripciones detalladas de cada uno de los parámetros individuales encargados de la asignación de recursos dentro del grupo de servidor RFC se pueden consultar directamente a través de la ayuda F1 incorporada en el sistema.

Notas SAP de Referencia y Limitaciones

El comportamiento técnico y las restricciones asociadas a estos parámetros están documentados en las siguientes notas oficiales:

• SAP Note 88284 (Excepción RFC: RESOURCE_FAILURE): En esta nota se explican en detalle las limitaciones relativas a los parámetros del sistema SAP que pueden desencadenar este fallo de recursos.

• SAP Note 2001278 (Configuración modificada a partir de 7.40 SP2): Debe consultarse para conocer los cambios estructurales introducidos a partir del servidor de aplicación ABAP 7.40.

Concurrencia y Buenas Prácticas de Asignación

Al configurar la arquitectura de los grupos de servidores, es fundamental tener en cuenta los aspectos de rendimiento y desarrollo:

• Competencia por recursos: Cuando un servidor físico o instancia pertenece de forma simultánea a más de un grupo, los jobs que utilicen dichos grupos competirán entre sí por los procesos de trabajo que se encuentren libres en el o los servidores compartidos.

• Vinculación en el código: El administrador o desarrollador debe asegurarse rigurosamente de que el grupo RFC creado esté debidamente especificado dentro del programa ABAP que lo va a utilizar.

• Recomendación sobre valores estándar: Se aconseja firmemente no desviarse de los valores estándar predefinidos por SAP para los parámetros de asignación de recursos. Modificar estos valores solo debe hacerse en situaciones muy excepcionales y cualquier cambio requiere ser probado minuciosamente bajo la carga relevante en el sistema.

Los Jobs estándar (en versiones anteriores a S/4 Hana)

Concepto de Jobs Estándar y Mantenimiento

• Definición de jobs estándar: Son tareas en segundo plano que requieren ser ejecutadas de forma regular en ambientes de producción de SAP.

• Propósito principal: Se encargan fundamentalmente de realizar labores de limpieza (clean-up) y mantenimiento operativo (housekeeping) dentro del sistema. Un ejemplo común de estas funciones es la eliminación de solicitudes de impresión obsoletas o antiguas.

• La problemática de las tablas de jobs: Por defecto, el entorno operativo batch de SAP mantiene en la base de datos el registro de los jobs ejecutados anteriormente y no los reorganiza de manera automática.

• Estrategia de reorganización: Debido a lo anterior, el administrador debe programar de forma regular jobs de mantenimiento (como por ejemplo, el job SAP_REORG_JOBS). De no implementarse una estrategia óptima, las tablas del sistema destinadas a almacenar la información de los jobs (tales como TBTCO, TBTCP, entre otras) crecerán de manera desmedida comprometiendo el estado del sistema.

Gestión y Planificación mediante la Transacción SM36

• Acceso en sistemas no S/4HANA: En aquellos servidores basados en aplicaciones ABAP tradicionales que son previos a SAP S/4HANA Server, la gestión, monitoreo y edición de este grupo de tareas se realiza ingresando a la transacción SM36.

• Visualización de la tabla REORGJOBS: Una vez dentro de la función de "Jobs Estándar" (Standard Jobs), el sistema desplegará la tabla denominada REORGJOBS. En caso de que no existan tareas planificadas previamente, esta pantalla se mostrará vacía.

• Planificación por Defecto (Default Scheduling): Al optar por esta alternativa, el administrador puede planificar de manera simultánea la totalidad de los jobs estándar. Para esto, se debe proporcionar un usuario de sistema bajo cuyas credenciales correrán las actividades. Todos ellos se programarán usando la variante y el período preestablecidos por el fabricante. Cabe destacar que si ya existen otros jobs activos ejecutando exactamente los mismos programas, el sistema emitirá un mensaje de carácter informativo.

• Planificación de Jobs Individuales: Si se prefiere un esquema selectivo, se puede elegir un job específico sirviéndose de las ayudas de entrada del sistema y determinando manualmente el período en el cual deberá ejecutarse.

• Definición de nuevos elementos: Si se requiere incorporar un job estándar adicional que no se encuentre cargado dentro de la lista inicial de la tabla REORGJOBS, se cuenta con la opción de "Predefinir nuevo job" (Predefine new job).

Recomendaciones de Mandante y Notas SAP de Referencia

• Entorno recomendado: SAP aconseja realizar la planificación general de estas tareas de limpieza de manera centralizada en el mandante 000.

• Excepciones de mandante: No obstante la recomendación anterior, existen jobs específicos que trabajan directamente con objetos propios y dependientes de un mandante en particular (como ocurre con la gestión de las tareas individuales).

• Planificación manual por cambios en el tiempo: A raíz de las modificaciones estructurales que han experimentado los jobs estándar a lo largo de las sucesivas versiones, se vuelve indispensable realizar la planificación de manera manual guiándose por la documentación oficial. Las notas principales que proveen información y actualizaciones técnicas son:

  • Nota SAP 18083: Relativa a los jobs estándar y los procesos de reorganización.

  • Nota SAP 1034632: Detalla los cambios implementados para las tareas estándar.

  • Nota SAP 1411877: Introduce especificaciones sobre nuevos jobs estándar.

  • Nota SAP 1440438: Corresponde a la segunda parte de la documentación sobre nuevos jobs estándar.

El Repositorio de Jobs Técnicos (S/4HANA)

En los entornos SAP S/4HANA Server, se introduce el Repositorio de Jobs Técnicos (Technical Job Repository), el cual tiene como propósito planificar de forma automática los jobs en fondo técnicos indispensables para mantener el sistema en un estado "saludable". Esta automatización opera tanto en el mandante de administración (ADMIN) como en el mandante de negocio (BUSINESS).

Este nuevo repositorio reemplaza por completo a las funciones antiguas de "Job Estándar" que se gestionaban en la transacción SM36. Para su funcionamiento, consta de dos secciones estructuradas: un componente de tiempo de diseño y un componente de tiempo de ejecución.

Componentes del Repositorio

• Componente de Tiempo de Diseño: Facilita a SAP la creación de "Definiciones de Jobs Técnicos" (o Definiciones de Jobs), las cuales actúan esencialmente como plantillas preestablecidas para los jobs en fondo que tienen carácter recurrente.

• Componente de Tiempo de Ejecución (Runtime):

  • Se encuentra activo de manera automática en cada uno de los servidores SAP S/4HANA Server. Se puede constatar su operatividad con el programa R_JR_UTIL_1 empleando los parámetros por defecto.

  • Es el encargado directo de ejecutar la planificación (o desplanificación) real de los jobs en segundo plano, basándose en el conjunto de Definiciones de Jobs Técnicos provistas.

  • Su activación se produce mediante una acción horaria automática del sistema.

Parámetros, Activación y Gestión de Usuarios

• Parámetro de perfil: El responsable de regular esta función es rdisp/job_repo_activate_time, cuyo valor predeterminado es de 60M (60 minutos).

• Monitoreo en tablas: La acción horaria guarda el registro de su última ejecución en la tabla BTCCTL. Es posible visualizar la última hora de generación de estos jobs mediante la transacción SE16, buscando en dicha tabla la entrada con el valor clave CTLID = 'JOBREPID'.

• Asignación de usuarios por defecto: Casi la totalidad de las definiciones de jobs traen grabado el valor *(DEFAULT)* en el campo de Nombre de Usuario (User Name). Esto funciona como un marcador de posición (placeholder) que el componente de tiempo de ejecución sustituirá al planificar el job.

• Estrategia de usuarios sustitutos: Por defecto, el repositorio intentará usar el usuario SAP_SYSTEM como encargado del paso de job batch, siempre que se encuentre disponible en el mandante actual. Si no existe, se empleará el usuario DDIC como una solución alternativa (fallback solution).

• Transacción SJOBREPO_STEPUSER: Esta transacción específica permite crear un usuario técnico adecuado para el repositorio en el mandante actual, o bien asignar un usuario técnico ya existente. Adicionalmente, sirve para visualizar de forma centralizada qué usuarios técnicos están asignados al repositorio en todos los mandantes del sistema.

Estados de la Definición de Job y Sus Razones

Es fundamental diferenciar el estado de la definición de un job frente al estado del job en fondo real. Una definición de job puede figurar como consistente (coherente), pero el job en sí puede no estar planificado en el sistema.

Para aclarar estas discrepancias, el campo "Razón del estado de la definición de job" (Job definition status reason) detalla el motivo exacto por el cual no hay un job planificado. Los escenarios típicos incluyen:

• BTC User Error: Se presenta si el usuario asociado a la definición del job no existe en el mandante actual.

• Not Relevant: Se muestra cuando el job en cuestión no requiere ser ejecutado en el mandante en el que se está consultando.

• Not In Scope: Ocurre con los jobs que dependen del alcance (scope dependent, reflejado en la columna correspondiente). Si las condiciones o requisitos de alcance de la aplicación no se cumplen en ese momento, el job no se agendará.

Visualización Multimandante

A partir de la versión SAP_BASIS 7.56, el sistema incorpora una mejora de visualización. Al seleccionar una definición de job de la lista en la pantalla principal (transacción SJOBREPO), el administrador puede presionar el botón "Todos los mandantes" (All clients) en la barra de herramientas. Esto proporciona de inmediato una visión general y detallada del comportamiento y estado de esa definición de job a lo largo de todos los mandantes existentes en el entorno.

El análisis de la configuración del procesamiento en segundo plano

Para que el procesamiento en fondo funcione correctamente dentro del sistema, se requiere el cumplimiento de ciertos requisitos previos, entre los que se incluye el establecimiento de autorizaciones y parámetros de perfil específicos. Con el objetivo de verificar la consistencia de todo este entorno, SAP dispone de una función simple llamada herramienta de análisis para el procesamiento en fondo, la cual se opera mediante la transacción SM65.

Tipos de Pruebas en la Transacción SM65

La herramienta de análisis se estructura fundamentalmente en dos categorías de pruebas según el nivel de profundidad requerido:

• Pruebas Básicas (Basic Tests): Se ejecutan desde la pantalla inicial de la transacción. Permiten verificar si los parámetros de perfil están configurados de forma correcta y comprobar la existencia del ID de usuario SAPWPDIC, el cual es estrictamente necesario para iniciar programas externos. Esta verificación se puede realizar tanto para un servidor de fondo en particular como para la totalidad de los servidores del sistema.

• Pruebas Expertas (Expert Tests): Para acceder a ellas, el administrador debe dirigirse a la barra de menú desde la pantalla inicial y seleccionar la ruta Ir a $rightarrow$ Pruebas Adicionales. Esta modalidad avanzada permite comprobar los siguientes elementos adicionales:

  • La autorización de usuario específica para el procesamiento en fondo.

  • El nombre de todos los servidores de jobs activos.

  • La función y el estado del subsistema TemSe, un elemento indispensable para que el sistema pueda escribir los logs de los jobs.

  • La consistencia de las tablas de la base de datos.

Importancia de la Consistencia en la Base de Datos

Debido a que el procesamiento en fondo almacena la información técnica de los jobs en múltiples tablas de la base de datos, la verificación de consistencia que ofrece la herramienta resulta crucial. Esta comprobación adquiere una importancia especial cuando se presentan fallos o problemas en la base de datos y se hace necesario determinar con precisión si todos los datos históricos y operativos de los jobs todavía se encuentran disponibles en el sistema.

Opciones Avanzadas mediante el Reporte BTC_OPTIONS_SET

Adicionalmente a las transacciones de análisis estándar, el sistema ofrece opciones versátiles para optimizar el procesamiento en fondo a través del programa o reporte BTC_OPTIONS_SET.

• Para facilitar la administración, cada una de las opciones disponibles dentro de este reporte identifica de manera directa la nota SAP correspondiente que suministra información técnica complementaria sobre la función en cuestión.

• A modo de ejemplo de sus capacidades, este reporte permite habilitar la especificación de un servidor de destino o un grupo de servidores de destino para la ejecución en fondo, una acción que se puede realizar tanto de manera interna desde una aplicación como utilizando la transacción SA38.