✒️SAP BASIS / Programación de jobs Por Fernando Escola

Programación de Jobs

La planificación de los jobs basado en el tiempo

Un job (un trabajo o tarea en segundo plano) puede iniciarse mediante dos modalidades principales: basado en tiempo o basado en evento. Cuando se opta por la planificación basada en tiempo, el sistema ofrece tres opciones específicas para determinar el inicio:

• Inmediatamente: El job arranca de forma instantánea. Puede configurarse para que ocurra una sola vez o de manera periódica, y permite definir excepciones durante el período programado.

• A una hora o fecha específica: El job se programa para un momento exacto del calendario. Al igual que la opción anterior, admite ejecuciones únicas o periódicas, así como la configuración de excepciones.

• Un día relativo al inicio o fin de un mes (día laborable determinado): Permite programar la tarea en función de la lógica del calendario comercial. Un ejemplo de esto es configurar el job para que se ejecute el cuarto día hábil de cada mes.

Condiciones de Recurrencia y Excepciones

Cualquiera de estas condiciones de inicio puede configurarse como recurrente (periódica), lo que significa que el job se volverá a ejecutar automáticamente una vez transcurrido un intervalo de tiempo definido.

Además, el sistema permite establecer excepciones. Por ejemplo, se puede configurar el aplazamiento automático del job al siguiente día laborable en caso de que la fecha programada coincida con un día festivo según el calendario de fábrica.

Cabe destacar que la ejecución efectiva del job en la fecha y hora especificadas dependerá siempre de la prioridad del job y de la disponibilidad de los procesos de trabajo en fondo (background) del sistema.

Ventanas de Tiempo y Restricciones de Inicio La Función "No Iniciar Después de" (No Start After)

El sistema permite acotar el período de tiempo en el que un job tiene permitido comenzar mediante la especificación de una hora límite. Si el job se retrasa y supera esa hora, el sistema ya no lo iniciará.

Esta función sirve principalmente para evitar que los jobs periódicos se ejecuten en momentos no deseados. Por ejemplo, si un job de reorganización masiva está diseñado para correr exclusivamente por la noche (aprovechando que hay más recursos disponibles y los usuarios de diálogo están inactivos), establecer una ventana de tiempo evita que, ante un retraso imprevisto, la tarea comience a ejecutarse en pleno horario laboral, lo que afectaría el rendimiento del sistema para los usuarios.

Limitaciones en la Planificación Periódica

Existe una restricción clave al utilizar la planificación periódica de jobs: no es posible definir una fecha de finalización para la serie de ejecuciones. El sistema no admite condiciones de corte del estilo "ejecutar todos los días hasta el final de este año".

Balanceo de carga

El planificador de jobs basado en tiempo (time-driven job scheduler) es el encargado de gestionar las tareas en fondo. El parámetro de perfil rdisp/btctime es el que determina el período de tiempo exacto en el cual este planificador se mantiene activo.

Planificación con Condición de Inicio Inmediato

Para evitar depender exclusivamente del planificador basado en tiempo, un usuario puede optar por ejecutar un job con la condición de inicio Inmediato:

• En este escenario, el propio proceso de trabajo de diálogo del usuario que realiza la solicitud se encarga de planificar y lanzar el job.

• No obstante, si en ese preciso instante el sistema no encuentra recursos libres (procesos en fondo disponibles), el job se ve obligado a planificarse de forma basada en tiempo. En este caso, la hora de inicio planificada registrada será la fecha y hora exacta en la que el job debería haber comenzado originalmente.

Funcionamiento del Planificador de Jobs (SAPMSSY2)

El planificador de jobs basado en tiempo se ejecuta en cada servidor de aplicación de SAP que tenga configurados procesos de trabajo en fondo (background work processes). El número de estos procesos necesarios en el sistema varía según el volumen de tareas a realizar, teniendo como requisito mínimo contar con al menos dos procesos en fondo si se utiliza el Sistema de Gestión de Transportes (TMS) para la importación de órdenes.

Características Técnicas del Planificador

• Naturaleza del programa: El planificador es un programa auto-ABAP llamado SAPMSSY2, el cual se ejecuta de manera automática utilizando un proceso de trabajo de diálogo.

• Frecuencia de ejecución: Se ejecuta de forma periódica cada determinada cantidad de segundos, intervalo que viene definido por el parámetro de perfil rdisp/btctime (cuyo valor por defecto es de 60 segundos).

• Desfase en la ejecución: A pesar de que la regla general indica que se ejecuta cada 60 segundos, las ejecuciones no ocurren exactamente al unísono ni clavadas al inicio de cada minuto en todos los servidores. Por ejemplo, un servidor de aplicaciones podría ejecutarlo en el segundo 42 de un minuto y otro servidor diferente en el segundo 9. El administrador del sistema no puede influir en esta hora exacta de inicio, ya que la misma se establece cuando se reinicia el servidor de aplicación y depende del momento en que se realizan las primeras actividades del sistema tras el reinicio.

Optimización del Rendimiento

Para incrementar significativamente el rendimiento (throughput) del procesamiento en segundo plano, el planificador de jobs no se limita únicamente al tiempo del parámetro. También se inicia de manera automática cada vez que un job finaliza. Esto acelera la revisión de la tabla de planificación de jobs en la base de datos sin tener que esperar a que se cumpla el ciclo completo de los 60 segundos, lo cual resulta especialmente útil cuando hay un gran volumen de tareas esperando.

Distribución y Asignación de Carga de Trabajo

A nivel organizativo dentro de SAP, un job se define de forma única en el sistema mediante la combinación de dos elementos: su ID de job y su nombre de job.

Cuando el planificador examina la tabla de planificación de jobs en la base de datos para buscar tareas pendientes de procesamiento, estas se transfieren a los procesos de trabajo en fondo libres siguiendo dos criterios de distribución:

Distribución de Carga Automática

Los jobs a los que no se les asigna explícitamente un destino de ejecución específico pueden correr en cualquier proceso de trabajo en fondo que se encuentre libre. El sistema SAP distribuye automáticamente la carga de trabajo general entre las diferentes instancias disponibles, optimizando los recursos globales.

Asignación Explícita de Servidor

Un administrador puede asignar explícitamente un objetivo de ejecución a un job en particular (seleccionando una instancia específica o un grupo de instancias).

• Esto permite cumplir con requerimientos técnicos muy puntuales. Por ejemplo, asegurar que un job se ejecute en un sistema operativo específico, o forzar a que el job corra en el mismo host (servidor físico) donde se encuentra alojada la base de datos para mejorar la velocidad de transferencia de datos.

• Desventaja: Al forzar la ejecución en un servidor determinado, se pierden por completo las ventajas del equilibrio de carga automático que realiza el sistema.

Planificación de Jobs Basada en Eventos

En el entorno de SAP, un evento funciona como una señal enviada al sistema de procesamiento en fondo para indicar que se ha alcanzado un estado o condición particular. Una vez que el sistema de procesamiento en fondo recibe esta señal, procede a iniciar de forma automática todos los jobs que se encuentren vinculados o encadenados a dicho evento.

A diferencia de la planificación por tiempo, la planificación basada en eventos ofrece tres condiciones de inicio específicas:

• Después del Evento (After event): El job arranca inmediatamente después de que el sistema SAP recibe la señal del evento definido. Esta ejecución puede configurarse para que ocurra una sola vez o de manera periódica, y tiene la flexibilidad de admitir o no el uso de parámetros adicionales.

• Después del Job / Predecesor (After job): Esta opción se utiliza para crear cadenas de jobs simples. Permite vincular el inicio de un job (sucesor) directamente a la finalización de otro job anterior (predecesor). La ejecución del job sucesor es opcional en términos de flujo, ya que se puede configurar para que dependa estrictamente del estado final en el que termine el job predecesor (por ejemplo, si finalizó con éxito o con errores).

• En Modo de Operación / Después de un cambio de Modo de Operación (At operation mode): Permite vincular la ejecución del job a la activación de un modo de operación específico dentro del sistema SAP. El job se disparará en el momento en que el sistema cambie a ese modo configurado.

Comportamiento del Sistema y Parámetros de Perfil Desactivación del Parámetro de Perfil rdisp/btctime

Un aspecto técnico crítico cuando se trabaja puramente con la planificación basada en eventos es el comportamiento de los disparadores del sistema:

• En este tipo de planificación, el parámetro de perfil rdisp/btctime (que define la frecuencia en segundos con la que el planificador basado en tiempo revisa las tareas pendientes) ya no se evalúa y, por lo tanto, deja de ser relevante.

• Esto se debe a que el inicio de las tareas ya no depende de un ciclo de reloj o de un escaneo periódico de la base de datos, sino de la recepción directa e inmediata de la señal del evento por parte del sistema de procesamiento en fondo.

Los eventos

Tipos de Eventos y su Administración

Los eventos en SAP actúan como disparadores para los trabajos en segundo plano y se pueden gestionar y revisar integralmente desde la consola del sistema:

• Eventos de Sistema: Son eventos predefinidos directamente por SAP. No pueden ser modificados por el usuario y, por regla general, no deben ser activados de forma manual.

• Eventos de Usuario: Son creados y definidos a medida por los administradores o desarrolladores para responder a necesidades específicas del negocio.

• Administración e Historial: Para dar de alta y administrar estos eventos se utiliza la transacción SM64 (Eventos de Fondo: Resumen y Administración). Por otro lado, para realizar un seguimiento o auditoría de los eventos que ya han ocurrido, se puede visualizar el registro histórico mediante la transacción SM62 (Historial de Eventos).

Métodos para Disparar Eventos

Un evento se puede activar desde diferentes ámbitos (dentro o fuera de SAP). Las principales vías disponibles son:

• Manualmente: Directamente dentro de SAP utilizando la transacción SM64.

• Mediante Programación ABAP: Ejecutando el programa estándar BTC_EVENT_RAISE o realizando una llamada al módulo de función BP_EVENT_RAISE. También es posible emplear programación orientada a objetos mediante el método RAISE de la clase CL_BATCH_EVENT.

• A través del Sistema Operativo (Externo): Utilizando la herramienta de línea de comandos ejecutable sapevt.

• Mediante Protocolo HTTP o HTTPS: Realizando una llamada externa al servicio web del Internet Communication Framework (ICF).

Disparo Externo mediante el Programa sapevt

El programa sapevt es un ejecutable ubicado en el directorio kernel que permite activar eventos desde fuera de SAP (por ejemplo, mediante un script de consola en Bash). Para que funcione de manera efectiva, el sistema SAP de destino debe estar activo, de lo contrario, el evento enviado por el programa externo se perderá.

Consideraciones Técnicas y Sintaxis de sapevt

• Uso de Parámetros: Al disparar un evento se le puede adjuntar un parámetro específico. Esto permite afinar la ejecución, logrando que solo inicien los jobs que estén esperando ese evento en combinación exacta con ese parámetro. El nombre del evento no distingue entre mayúsculas y minúsculas, pero el parámetro sí.

• Manejo de Espacios: Si el nombre del evento contiene espacios en blanco, se debe obligatoriamente escribir entre comillas al invocar el comando (por ejemplo: sapevt "my event" name=S4D...).

• Uso del Parámetro de Perfil (pf=...): Al llamar a sapevt desde el servidor de aplicación con el usuario administrador {sid}adm, se le debe indicar la ruta del perfil de la instancia utilizando el parámetro pf=. Los sistemas SAP modernos basados en Windows exigen de forma obligatoria esta entrada. En entornos Linux, si se omite, el comando puede fallar con un error indicando que no puede determinar el "mshost", aunque el evento a veces logre activarse con éxito. Ante cualquier duda, la recomendación técnica es incluir siempre el parámetro del perfil de la instancia.

• Archivos de Logs: Cada vez que se ejecuta una llamada de ayuda o comando, sapevt escribe su salida y trazabilidad en un archivo de rastreo llamado dev_evt, ubicado en el directorio desde donde se invocó el programa.

• Limitaciones por Versión del Kernel: A partir del Kernel 7.40, cambios internos en el servidor de mensajes provocaron interrupciones en la compatibilidad de llamadas cruzadas (cross-release) entre diferentes versiones. Además, debido a que sapevt se comunica sin autenticación con el servidor de mensajes, el programa podría dejar de funcionar si el sistema tiene implementada o activa la comunicación segura con dicho servidor.

Disparo Externo mediante el Servicio ICF (event_raise)

Una alternativa moderna para disparar eventos desde el exterior sin usar el comando de sistema operativo es realizar una llamada HTTP(S) al servicio del Internet Communication Framework (ICF) a través de la ruta URL: /default_host/sap/bc/batch/event_raise.

Para interactuar con este servicio, existen tres metodologías de autenticación de credenciales:

• Credenciales Almacenadas en el Servicio ICF: Si los datos de conexión (usuario y contraseña) ya están preconfigurados en la sección "Datos de Conexión" (Logon Data) del servicio en la transacción SICF, el cliente externo solo debe enviar una URL simple indicando el host, puerto, mandante y el ID del evento. Esta variante no requiere autenticación explícita en la cadena de llamada, funcionando de manera equivalente al antiguo programa sapevt.

• Credenciales Especificadas en la Cadena de Parámetros: Es posible incluir directamente las credenciales de un usuario específico de SAP dentro de la propia URL mediante variables de parámetros (añadiendo los campos sap-user={nombre_de_usuario} y sap-password={contraseña}). Esta opción suele limitarse a entornos de prueba.

• Certificados X.509: Se puede configurar el inicio de sesión de la llamada web de forma segura utilizando certificados digitales X.509.

Existe también la posibilidad de realizar esta activación remota utilizando el cliente RFC sapevt_rf a nivel de sistema operativo, el cual ejecuta por detrás el módulo de función BP_REMOTE_EVENT_RAISE.

Los comandos externos y los programas externos

El sistema de procesamiento en fondo de SAP establece una distinción clara entre dos conceptos para ejecutar tareas a nivel del sistema operativo subyacente: comandos externos y programas externos.

Esta diferenciación tiene como objetivo principal otorgar a los administradores la flexibilidad de ejecutar cualquier software necesario, mientras que restringe a los usuarios finales ("normales") a un catálogo cerrado y controlado de comandos predefinidos.

Independientemente de si se trata de un comando o de un programa, el sistema SAP invoca internamente a un programa conector a nivel de sistema operativo llamado sapxpg, el cual se encarga de iniciar y controlar la ejecución real de la tarea externa.

Comandos Externos (External Commands)

Los comandos externos están diseñados para ser utilizados tanto por administradores como por usuarios finales bajo estrictos criterios de seguridad.

Características y Restricciones

• Definición previa: Son comandos o programas del sistema operativo host que deben estar predefinidos en el sistema SAP por un administrador.

• Protección por autorizaciones: Los usuarios comunes solo pueden planificar o ejecutar los comandos externos para los cuales un administrador les haya otorgado permisos explícitos.

• Control de seguridad: La ejecución de estos comandos requiere validación mediante el objeto de autorización S_LOG_COM. Este objeto consta de tres campos de control específicos: COMMAND (el nombre del comando), OPSYSTEM (el sistema operativo) y HOST (el servidor de ejecución).

Configuración y Creación (Transacción SM69)

La creación y modificación de los comandos externos se realiza mediante la transacción SM69 (Herramientas -> CCMS -> Configuración -> Visualizar/Modificar Comandos Externos). Al dar de alta un comando, se deben seguir las siguientes reglas técnicas:

• Identificación: Se identifican de forma única mediante una combinación de su nombre de comando (que por convención estándar debe comenzar con las letras Y o Z) y el tipo de sistema operativo. El campo de tipo de sistema operativo se completa automáticamente.

• Definición del ejecutable: Se especifica el comando real del sistema operativo (añadiendo la ruta completa si es necesario) y los parámetros adicionales fijos que requiera.

• Parámetros adicionales permitidos: Cuenta con una casilla de verificación llamada Additional Parameters Allowed. Si se marca, se le permite al usuario final especificar argumentos o parámetros dinámicos adicionales al momento de ejecutar el comando o planificarlo en un job. Estos argumentos nuevos se concatenarán a los parámetros fijos predefinidos.

• Trazabilidad (Traza): El campo Trace generalmente se deja en blanco. Para realizar un seguimiento exhaustivo, el sistema utiliza el parámetro de traza asociado al módulo de función SXPG_COMMAND_EXECUTE.

• Módulo de Verificación (Check module): Permite añadir una capa de seguridad extra introduciendo el nombre de un módulo de función personalizado (el cual suele ser una copia adaptada del módulo estándar SXPG_DUMMY_COMMAND_CHECK). El sistema llama automáticamente a este módulo cuando un usuario intenta planificar o ejecutar el comando para verificar si la acción cumple con las reglas de seguridad definidas.

Programas Externos (External Programs)

Los programas externos son herramientas de uso exclusivo para perfiles con privilegios de administración global y no pasan por el filtro de la transacción SM69.

Características y Restricciones

• Sin restricciones de catálogo: Consisten en cualquier archivo ejecutable o programa a nivel de sistema operativo. No necesitan estar predefinidos en el sistema SAP ni limitarse a una lista específica.

• Privilegios requeridos: Únicamente un usuario que posea autorizaciones de administración completas puede introducir un programa externo de manera directa como un paso (step) dentro de la configuración de un job.

• Validación de seguridad laxa: A diferencia de los comandos externos, el sistema de procesamiento en fondo de SAP no realiza ninguna verificación de autorización adicional antes de lanzar el comando. La seguridad recae por completo en que el usuario tenga asignado el objeto de autorización de administración de fondo S_RZL_ADM (Procesamiento en Fondo: Administrador de Fondo). Este objeto le brinda al administrador total libertad y flexibilidad para ejecutar cualquier comando en el sistema host sin necesidad de configuraciones previas en SAP.

Las banderas de control (Control Flags)

El documento explica el uso de los indicadores o banderas de control (control flags) en el sistema SAP, los cuales sirven para definir especificaciones detalladas sobre una tarea y otras opciones durante el tiempo de ejecución. Por lo general, no es necesario modificar los valores que vienen configurados de forma predeterminada.

Estas opciones se gestionan a través de la transacción SM36 (en la pantalla "Create Step 1" y su respectiva ventana emergente para establecer indicadores de control para programas externos).

Opciones de configuración principales

A través de estas banderas de control, se pueden especificar los siguientes comportamientos para los programas y comandos externos que se ejecutan en un job de fondo:

• Registro en el historial (Logging): Permite determinar si el proceso debe ser registrado (logged). Cuando se activa, los datos de salida se escriben directamente en el log del job tal como los emite el programa externo. Se destaca que el idioma de estos registros puede ser diferente al idioma con el que se conectó el usuario, y también se puede invocar información adicional sobre los datos del programa externo dentro del mismo historial.

• Espera de finalización (Job waiting for external termination): Permite indicar si el programa de control de SAP debe esperar a que el programa externo finalice en la computadora de destino. Esta opción es fundamental, por ejemplo, si se necesita recibir el valor de retorno (return code) que genera el programa externo al terminar.

• Activación de traza (Trace): Da la opción de activar el nivel de detalle más alto para el seguimiento o la traza (trace) del proceso, lo que resulta útil para tareas de diagnóstico o depuración.

Ayuda Adicional

El documento concluye con una recomendación práctica: para visualizar información detallada y específica sobre el significado de cada uno de los indicadores de control, se puede utilizar la ayuda del sistema presionando la tecla F1 directamente en la pantalla "Establecer Indicadores de Control para Programas Externos" (Set Control Flags for External Programs).

Las opciones para extender el comportamiento estándar en el procesamiento en segundo plano

Cuando las opciones de planificación de tareas habituales no cubren todos los requisitos, existen alternativas para realizar escenarios más complejos en SAP. Además de usar SAP Business Process Automation (SAP BPA) de Redwood, se dispone de las siguientes herramientas:

1. Módulos de Función Internos

El sistema SAP cuenta con varios módulos de función internos diseñados para ayudar a definir procesos de tareas propios. Estos módulos se agrupan específicamente dentro de los grupos de funciones BTCH y BTC2. Con su utilización, es posible definir prácticamente cualquier escenario complejo que se requiera dentro del sistema.

2. Interfaces de Gestión Externa

SAP ofrece un conjunto de interfaces que permiten conectar entornos de gestión de sistemas externos directamente al Sistema de Gestión del Centro de Cómputo SAP (CCMS). Estas interfaces principales son:

• XMI-API (External Monitoring Interface API): Esta interfaz se encarga de registrar detalladamente las actividades de los usuarios y de los programas externos.

• XBP-API (External interface for Background Processing): Esta interfaz habilita y permite el uso de programas de planificación de tareas de origen externo.

Comparativa de capacidades de ampliación

La flexibilidad que ofrecen estas herramientas permite diferenciar dos grandes enfoques para ir más allá del estándar:

• Usando la API de tareas de ABAP: Está orientada a la complejidad interna del sistema. Permite, por ejemplo, ejecutar periódicamente pares de tareas, vincular una tarea para que dependa de dos tareas predecesoras simultáneamente, o diseñar cualquier escenario complejo que ocurra de manera nativa dentro de un único sistema SAP.

• Usando la API XBP: Está orientada a la integración con el exterior. Permite conectar y coordinar múltiples sistemas SAP a la vez, así como interactuar con sistemas que no son de SAP. A través de un sistema externo de gestión de tareas que se comunica mediante XBP, se pueden disparar y controlar procesos en diferentes entornos de manera centralizada.

Adicionalmente, se menciona que para gestionar el procesamiento en segundo plano a nivel de todo el paisaje de sistemas (Landscape-wide background processing), se puede emplear un planificador de tareas (job scheduler) que supera las limitaciones de las transacciones convencionales y locales como SM36 y SM37.

Opciones de Planificación Centralizada

Para centralizar el control y la automatización de los procesos, el ecosistema de SAP provee tres plataformas principales:

• SAP Business Process Automation by Redwood (SAP BPA): Es una solución avanzada de automatización que anteriormente se conocía bajo el nombre de SAP Central Process Scheduling by Redwood (SAP CPS).

• SAP Solution Manager: Esta plataforma proporciona funciones centrales destinadas a la planificación y administración de tareas a través de un espacio de trabajo específico denominado "Centro de Trabajo Gestión de Tareas" (Job Management work center).

SAP Cloud ALM: Orientado a entornos en la nube, ofrece capacidades de gestión centralizada dentro del mosaico "Monitoreo de Jobs y Automatización" (Job & Automation Monitoring), el cual forma parte del módulo SAP Cloud ALM for Operations.