Tutorial SAP

Introducción a SAP
Lección 1: Qué es SAP?
¿Qué es SAP?
SAP es una empresa con sede en Alemania creada en el año 1972. Es junto con Oracle
una de las más grandes en la venta de software empresarial.
Actualmente la mayoría de las grandes corporaciones utilizan para el manejo de sus
negocios alguna implementación de SAP, lo que asegura un gran futuro de SAP dentro
de las empresas a largo plazo.
Su logro actual es que también están implementando su software en empresas de
pequeña y mediana envergadura (PyMEs) de la mano de productos como SAP Business
One.
SAP Software
Su nombre corresponde a las iniciales de las siglas Sistemas, Aplicaciones y Productos.
SAP actualmente tiene una amplia gama de productos, entre los que se destacan los
siguientes:
SAP R/3 (ahora llamado SAP ECC - Enterprise Central Components) es lo que se llama
un sistema ERP (Enterprise Resource Planning) que resumiendo es un sistema que
abarca todas las unidades centrales del negocio de una empresa. Entre estas están la
facturación, las ventas, la logística, las finanzas, entre otras las cuales se conocen
como módulos.
La ventaja que tiene este tipo de sistemas es que integran todas estas actividades en
un sólo programa, por lo tanto todo se mantiene relacionado, favoreciendo la
interacción de las diferentes áreas.
Una característica importante es que SAP R/3 proporciona la oportunidad de sustituir
un gran número de sistemas independientes, que se han desarrollado e instalado en
organizaciones ya establecidas, por un solo sistema modular.
Como referencia, nombramos los módulos que
contiene SAP R/3:

Figura 1 - Módulos de R/3

FI: Contabilidad Financiera
CO: Controlling
IM: Inversiones
TR: Tesorería
LO: Gestión de datos de logística
EC: Enterprise controlling
MM: Gestión de materiales
SD: Gestión de Ventas
PS: Gestión de Proyectos

QM: Gestión de la Calidad
PP: Planeamiento de Producción
HR: Gestión de Recursos Humanos
PM: Gestión de Mantenimiento

Existen también otras herramientas de SAP entre las que se destacan:
SAP CRM: Manejo de las relaciones con los clientes.
SAP SRM: Manejo de las relaciones con los proveedores.
SAP PLM: Manejo integral de productos.
SAP SCM: Manejo de logística y demanda.
SAP Netweaver: esta es una aplicación abierta de integración para todas las
demás aplicaciones de SAP y algunas de terceros también.

Figura 2 - SAP Netweaver

Lección 2: Aplicaciones y Componentes de SAP
Productos SAP a la medida de la compañía
En los últimos años SAP ofrece un abanico de productos para empresas u
organizaciones de todos los tamaños. Estos se caracterizan principalmente por su
escalabilidad asegurando de que puedan ajustarse a la talla de cada compañía y
también se adapten a los constantes cambios en los procesos de la misma.

Figura 3 – Diferentes tamaños, diferentes productos.

SAP Business One: es una aplicación de ERP con una interfaz similar a la de
Windows, la cual ha sido desarrollada específicamente para pequeñas y medianas
compañías. Este software permite gestionar las áreas más importantes del negocio en
una aplicación simple e integrada.
Esta solución es ideal para compañías con menos de 100 empleados y hasta 30
usuarios y necesiten un sistema a su alcance económico y que pueda cubrir los
procesos centrales (core) tales como financieros, ventas, servicios al cliente y
operaciones.
SAP Business by Design: esta es la última solución desarrollada por SAP para las
pequeñas y medianas compañías de 100 a 500 empleados que quieran administrar y
mejorar sus procesos centrales financieros, de recursos humanos, proyectos,
abastecimiento, etc. Está enfocado principalmente a las empresas medianas que aún
no utilizan software de negocio integrado.
Ofrece protocolos de comunicación estándar tal como los Web Services que permite la
interacción entre diferentes aplicaciones (A2A) y sistemas (B2B).
SAP Buiness All-In-One: es la solución ideal para aquellas empresas de mediana
escala con requerimientos muy específicos de la industria a la que pertenecen y con
varias divisiones y una infraestructura de IT madura. Este software está basado en un
SAP ERP. Está pensado para una implementación rápida utilizando escenarios ya preconfigurados basados en las mejores prácticas del mercado en las que se encuentran
estas industrias.

Aplicaciones SAP
Si bien la aplicación más conocida, o bien con la cual SAP pudo expandirse
mundialmente es SAP R/3, hoy existe un conjunto de aplicaciones las cuales pueden
licenciarse de manera conjunta o por separado.
SAP Business Suite: esta es la familia de aplicaciones de negocio que se compone
de diferentes productos los cuales dan soporte a todos los procesos de una compañía.
SAP Business Suite provee:
Un completo espectro de soluciones de negocio
Una infraestructura abierta y flexible con años de madurez y solidez
Componentes adaptables a los requerimientos de negocio
Numerosas funciones específicas de la industria

Figura 4 – SAP Business Suite

Las nuevas funciones para la suite de SAP se obtienen hoy con los enhancement
packages.
Componentes de Software
Numerosas aplicaciones son provistas dentro del conjunto del SAP Business Suite.
Estas aplicaciones, en muchos casos, requieren de las mismas funciones en algunas de
sus sub áreas. Por lo tanto diferentes aplicaciones contienen componentes de software
similares. Por esto podemos decir que un componente de software es la unidad más
pequeña, instalable y que puede ser mantenida.

Lección 3: SAP Netweaver.
Concepto de SAP Netweaver
La plataforma tecnológica de SAP Netweaver está diseñada para poder introducir de
manera paulatina y flexible los procesos más importantes de una compañía ya que nos
proporciona a un alto nivel las funciones necesarias y los estándares de la industria
para integración. De esta manera podemos definir a SAP Netweaver como la base
técnica del SAP Business Suite.

SAP Netweaver nos permite integrar y conectar gente, información y procesos de
negocio a través de diferentes tecnologías permitiendo ajustarse rápidamente a los
cambios que puedan surgir en una compañía. De esta manera la integración está
unificada en una única plataforma lo que facilita que no tenga que ser desarrollada
por cada cliente.
Prácticas y Escenarios IT
SAP Netweaver permite implementar procesos de IT dentro de un rango de soluciones
denominados prácticas de IT. Para cada una de estas prácticas SAP Netweaver soporta
un rango de actividades claves las cuales se pueden realizar con los componentes
integrados en la plataforma de SAP Netweaver.
Esto nos permite que los objetivos de cada compañía puedan alcanzarse en proyectos
individuales y manejables, o sea, en pasos secuenciales de acuerdo a la importancia de
cada uno.
Para cada práctica de IT SAP Netweaver provee los escenarios correspondientes que
sirven como guías de implementación.

Figura 5 - Escenarios y Prácticas de IT

En conclusión, los escenarios de IT nos brindan una ayuda al momento de la
instalación, configuración y operación de SAP Netweaver.

Las capas de SAP Netweaver
SAP Netweaver está dividido en cuatro capas de integración que consisten cada una de
funciones centrales:

Integración de Gente (People Integration): permite que los usuarios de
diferentes aplicaciones tengan acceso a la información y funciones que necesitan de
manera rápida y eficiente en una interfaz concentrada. Dentro de esta capa
encontramos principalmente la aplicación SAP Netweaver Portal que provee funciones
más importantes en este contexto.

Figura 6 - SAP Netweaver Portal

Integración de la Información (Information Integration): esta capa provee
el acceso a toda la información de la compañía ya sea estructurada o no lo que
significa que es información que fue generada por un sistema no-SAP. Las principales
áreas de integración de información están formadas por SAP Netweaver Business
Intelligence (BI) y SAP Netweaver Master Data que permite gestionar de manera
central los datos maestros de la compañía.

Figura 7 - SAP Netweaver BI

Integración de procesos (Process Integration): esta es la capa que se encarga
de comunicar las aplicaciones de nuestra compañía (o fuera de ella también) en
ambientes heterogéneos. SAP Netweaver Process Integration (PI) juega un rol
fundamental aquí para conectar los sistemas SAP y no-SAP utilizando diferentes
estándares de comunicación.

Figura 8 - SAP Netweaver PI

Plataforma de Aplicación (Application Platform): El Servidor de Aplicación SAP
NetWeaver, denominado comúnmente como SAP Netweaver AS, por sus siglas en
inglés provee la infraestructura para la operación de las aplicaciones de negocio que
están basadas sobre las tecnologías J2EE o ABAP. Adicionalmente los estándares
abiertos, acceso a aplicaciones web y servicios web completan la plataforma de
aplicación.
En conclusión el SAP Netweaver AS es el entorno de ejecución para las aplicaciones de
nuestras aplicaciones SAP. Las herramientas necesarias para el desarrollo de nuestras
propias aplicaciones también están incluidas dentro del mismo.

Figura 9 - SAP Netweaver AS

Plataforma del sistema SAP
Lección 1: Arquitectura del SAP Netweaver AS
Arquitectura del SAP Netweaver AS
La mayoría de los sistemas SAP están basados sobre un servidor de aplicación
Netweaver como entorno de ejecución, junto con la base de datos, el SAP Netweaver
AS es la plataforma de aplicación de SAP Netweaver.

Figura 10 – SAP Netweaver AS

La evolución de la tecnología del servidor de aplicación SAP, antes conocido como SAP
Basis es lo que hoy representa el servidor de aplicación Netweaver donde las
aplicaciones web tienen una especial relevancia.
¿Qué características tiene el SAP Netweaver AS?
Un entorno confiable y comprobado de ejecución el cual es continuamente
desarrollado y mejorado.
Un framework de ejecución de procesos complejos de negocio que cumple con los
estándares de seguridad más altos.
Un ambiente de desarrollo integrado y de fácil utilización.
Soporta estándares abiertos incluyendo HTTPS, HTTP, SMTP, WebDAV, SOAP, SSL,
SSO, X.509, Unicode, HTML, XML y WML.
Alta escalabilidad
Soporta diferentes bases de datos y sistemas operativos (multiplataforma).

Arquitectura principal del SAP Netweaver AS
Durante la implementación de un sistema SAP deberemos decidir la arquitectura de
nuestro sistema SAP y cómo distribuir los procesos en el hardware que tengamos
disponible.
Las aplicaciones que ejecutaremos deben ser implementadas de manera independiente
del hardware, sistema operativo y base de datos que utilicemos. Para esto el SAP
Netweaver AS provee dos ambientes de ejecución: ABAP y JAVA.
Cliente – Servidor
En una definición orientada al hardware cuando nos referimos a una configuración
cliente-servidor este último provee en una red datos, memoria y otros recursos a las
estaciones de trabajo (workstations).
En una visión orientada a software, el cliente y el servidor son ambos definidos a nivel
de procesos (servicios).
En este contexto un servicio es provisto por un componente de software que puede
consistir en un proceso o un grupo de procesos, tal como lo es un Servidor de
Aplicación Web SAP (SAP Web AS) y es un servidor para ese servicio específico. Los
componentes de software que usan ese servicio son los clientes.
Al mismo tiempo, un cliente puede comportarse como servidor para otros servicios
específicos.
La siguiente imagen puede clarificar un poco más los conceptos:

Figura 11 – Dos definiciones de Cliente-Servidor

Configuración Cliente-Servidor de Sistemas SAP
En un sistema de software de negocios generalmente encontraremos los siguientes
procesos:
Procesos de presentación (por ejemplo para presentar las pantallas)
Procesos de aplicación (por ejemplo, para ejecutar los programas de aplicación)
Procesos de base de datos (por ejemplo, para gestionar y organizar los datos de
la base)

En la implementación de un sistema SAP la configuración de estos procesos puede
resultar single-tier o multi-tier dependiendo del número de capas de hardware
utilizadas. El sistema SAP ECC es un ejemplo de software de aplicación de negocios.

Figura 12 – Configuraciones Cliente-Servidor.

Conformación de un sistema SAP
En muchas ocasiones debemos referirnos a los componentes de la infraestructura de
SAP y vamos a ver ahora como está conformado un sistema SAP.
Los elementos que conforman un sistema SAP son los que se muestran en la siguiente
imagen: Figura 13– Componentes de un sistema SAP, una base de datos y una o más
instancias.
La instancia que junto con la base de datos constituyen un sistema funcional se
denomina instancia central. En cada sistema SAP encontraremos una instancia central.
Si el sistema está configurado solo con la instancia central y esta corre en el mismo
servidor donde se encuentra la base de datos entonces nos encontramos frente a un
sistema central.

Figura 13 – Componentes de un sistema SAP

Es posible instalar más de una instancia de un mismo sistema o de diferentes sistemas
en un mismo servidor. Así también como más de un sistema (base datos e instancia
central) en un mismo servidor si contamos con suficiente hardware para esto.

Un sistema SAP se identifica con tres caracteres (System ID: SID). El conjunto de
sistemas SAP de un mismo producto (Ej: ECC) se referencia como landscape, aunque
esto no es exclusivo de SAP. En una empresa u organización dentro de un landscape
SAP cada SID es único y no debe repetirse.
¿Qué es una instancia SAP?
Básicamente una instancia de SAP es una unidad administrativa en la que los
componentes de un sistema SAP que provee uno o más servicios se encuentran
combinados. Si bien ahora puede no quedar muy claro este concepto vamos a ir
desarrollándolo de ahora en más.
Los servicios que ofrece una instancia de SAP pueden ser iniciados o detenidos
en conjunto. Por lo tanto podemos pensar que en un sistema SAP con más de una
instancia podríamos tener una de estas detenida y otra u otras funcionando al mismo
tiempo. La instancia central siempre debe estar funcionando al menos para que un
sistema SAP esté operativo.
En SAP el término instancia también es comúnmente referenciado como servidor
de aplicación desde un punto de vista de software ya que es el entorno de
ejecución para las aplicaciones de negocios de SAP.

Variantes de Servidores de Aplicación Netweaver SAP
Las instancias de los sistemas SAP pueden ser de los siguientes tipos:
Instancia basada en ABAP
Instancia basada en JAVA
Instancia mixta ABAP+JAVA
Estas tres variantes no pueden ser instaladas en un mismo sistema SAP. Si
una instancia es JAVA pura, entonces todas las demás instancias del sistema
deberán ser del mismo tipo. Las demás combinaciones son posibles. El
siguiente cuadro resume estas combinaciones:

Cuadro 1 – Combinaciones posibles de instancias en un sistema SAP

Instancias ABAP
Primero nos enfocaremos en instancias puramente ABAP.
El dispatcher (despachante) de ABAP es el proceso principal de una instancia ABAP.
Este proceso se encarga de iniciar otros procesos configurados en la instancia
denominados work processes (procesos de trabajo), el Gateway (no se muestra en la
figura 14 – Sistema SAP ABAP) y el Internet Communication Manager (ICM).
Cada instancia ABAP se configura con un perfil de instancia y cada instancia posee su
propia área de memoria en el servidor donde corre así también como su propia
estructura de directorio.

Figura 14– Sistema SAP ABAP

Una instancia tiene un único dispatcher y cuando levantamos una instancia el
dispatcher es lo primero que inicia. Dos procesos de diálogo se requieren mínimamente
por instancia, luego veremos con mayor detalle cada tipo de proceso que podemos
tener en una instancia.
Cada instancia se identifica dentro de un sistema SAP por un número de dos dígitos.
Por lo general en manera secuencial empezando por 00 (doble cero). Cuando
instalamos el sistema tenemos la opción de elegir el número de instancia entre 00 y
97.
Cuando agregamos instancias a nuestro sistema tenemos que elegir un número que no
esté utilizado si la instancia se instala en el mismo servidor que la o las anteriores.
Podemos concluir entonces que cada número de instancia es único por servidor.
Si varias instancias son instaladas en un mismo servidor, cada una de ellas tendrá su
propia área de memoria y su propia estructura de directorio en el sistema de archivos
del servidor.
En los sistemas SAP basados en ABAP o ABAP+JAVA podemos distinguir la instancia
central de las demás ya que en esta encontraremos un proceso especial denominado
Message Server (Servidor de Mensajes), este proceso es único para todo nuestro
sistema SAP. También la instancia central es la única que ofrece uno o más work
process de enqueue (encolado).

Instancias JAVA
El dispatcher de JAVA también es el proceso central de una instancia JAVA. Este
proceso, de manera similar que el dispatcher de ABAP, distribuye las solicitudes que
llegan a la instancia entre los server processes (servidores de proceso) disponibles.

Figura 15 – Sistema JAVA

También en este caso cada instancia de JAVA posee un único dispatcher. Una instancia
de JAVA requiere mínimamente un server process. Si instalamos más de una instancia
en un servidor, cada una de estas tendrá un número de instancia diferente.
Un sistema SAP JAVA pude tener varias instancias pero solo una instancia central. En
este caso, la instancia central se diferencia de las demás porque incluye un proceso
adicional denominado SDM que son las siglas en inglés de Software Deployment
Manager el cual se configura solo uno para todo el sistema.
A diferencia del sistema SAP ABAP, acá encontraremos como se puede observar en la
figura 15 – Sistema JAVA, una instancia de Servicios Centrales (JAVA Central Services).
La instancia JAVA CS proporciona el JAVA Message Server (Servidor de Mensajes) y
JAVA Enqueue Server (Servidor de Encolado).
En un escenario clásico la instancia central y el JAVA CS se alojan en el mismo
servidor. Instancias adicionales pueden ser instaladas en el mismo servidor donde se
encuentra la instancia central o los servicios centrales.
Instancias ABAP+JAVA
Como ya podrás deducir en este tipo de instancias vamos a encontrar procesos ABAP y
JAVA. Una instancia central ABAP+JAVA estará conformada por los procesos de una
instancia central ABAP y los procesos de una instancia central JAVA.
Recordemos que la instancia de servicios centrales es una instancia independiente, por
lo tanto no es parte de la instancia central ABAP+JAVA.

Figura 16 – Sistema ABAP+JAVA

Lección 2: Procesos del SAP Netweaver AS.
Procesos del SAP Netweaver AS
Cuando un usuario trabaja con SAP utiliza alguna de las aplicaciones que provee el
producto, tal como el ECC. Esta aplicación puede haber sido diseñada en el lenguaje de
programación ABAP o en JAVA. De esto se deduce que dependiendo del lenguaje con
que se decidió crear la aplicación va a ser procesada por la parte de ABAP o de JAVA
de nuestro servidor Netweaver SAP.
En cada una de las instancias ABAP y JAVA corren una serie de procesos en paralelo
los cuales trabajan en conjunto y se comunican en algunos casos.
Veamos en la siguiente figura los procesos del entorno de ejecución ABAP:

Figura 17 – Procesos del entorno de ejecución ABAP

El dispatcher de ABAP es quien se encarga de distribuir los pedidos entre los work
processes. Como ya vimos antes, este proceso se encuentra en cada instancia ABAP de
nuestro sistema SAP.

¿Qué tipos de work processes son los que dependen de la administración del
dispatcher?
Procesos
Procesos
Procesos
Procesos
Procesos

de
de
de
de
de

diálogo (tipo D)
Background (tipo B)
Lock Managment (tipo E)
Update 1 y 2 (tipo V)
Spool (tipo S)

La cantidad de procesos de cada tipo que una instancia tendrá se determinan
configurando el parámetro correspondiente en el perfil de la instancia.
La siguiente tabla describe estos parámetros:

Tabla 1 – Parámetros de Work Processes

Veamos ahora otros procesos, que no son work processes, y que proveen servicios de
comunicación interna y externa.
El Message Server (MS) maneja las comunicaciones entre los dispatchers distribuidos
en todo el sistema. De esta manera se logra la escalabilidad de múltiples servidores de
aplicación (instancias) en paralelo. El message server se configura sólo uno para todo
el sistema SAP.
El Gateway (GW) permite la comunicación entre sistemas SAP, o entre sistemas SAP y
sistemas de aplicación externos. Existe uno por dispatcher o instancia ABAP.
El Internet Communication Manager (ICM) permite la comunicación con el sistema SAP
a través de protocolos web tales como HTTP. El ICM recibe los pedidos del cliente y los
reenvía al sistema SAP para su posterior procesamiento.
En los sistemas mixtos ABAP+JAVA, el ICM puede reconocer si el pedido es una
llamada para el AS ABAP o para el AS JAVA ya que ambos manejan aplicaciones web.
Es posible configurar o no un ICM por cada servidor de aplicación.

Lección 3: Procesos de Diálogo ABAP.
PROCESOS DE DIALOGO ABAP
La capa de presentación
Los usuarios pueden loguearse al sistema SAP utilizando diferentes front ends, tal
como el clásico SAP GUI el cual usaremos durante el curso pero 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, los programas que conforman esas aplicaciones están desarrollados
para que sean ejecutados en el entorno de ejecución ABAP de nuestro sistema
SAP. Sin importar si son transacciones clásicas o aplicaciones web serán ejecutadas
por el proceso de diálogo de la instancia de ABAP.
Las aplicaciones web también pueden ser desarrolladas en JAVA por lo que serían
procesadas por este entorno. Cuando llega la solicitud al sistema se determina si
es ABAP o JAVA y se reenvía al entorno adecuado.

Procesando solicitudes de SAP GUI
Veamos cómo funciona el procesamiento de la solicitud de un usuario, como por
ejemplo el llamado a una transacción, en el servidor de aplicación ABAP. Como
muestra la siguiente imagen, el procesamiento involucra diferentes procesos en las tres
capas (presentación, aplicación y base de datos):

Figura 18 – Procesando solicitudes de usuario ABAP.

Cuando el usuario llama a una transacción o cambia de pantalla dentro de una misma
función, esto es tomado por el programa de presentación SAP GUI, el cual lo
convierte en un formato interno y enviado al AS ABAP.
El dispatcher (ABAP) es el proceso central del AS ABAP. Se encarga de gestionar los
recursos para las aplicaciones escritas en ABAP en coordinación con el sistema
operativo respectivo donde corre nuestro sistema SAP.

Las principales tareas del dispatcher incluye la distribución de solicitudes entre sus
work processes, la integración de la capa de presentación y la organización de las
comunicaciones.
La solicitud enviada por el SAP GUI entra en una cola de solicitudes en el dispatcher.
En cuanto existe un proceso de diálogo libre, la solicitud es enviada por el dispatcher a
este work process. Esto significa que no hay una relación fija entre los work process y
los usuarios (más adelante volveremos sobre esto).
Para poder procesar las solicitudes de usuario, frecuentemente el work process
necesitará leer datos desde o escribirlos en la base de datos del sistema. Es por esto
que cada work process está conectado directamente a la base de datos.
Finalmente, una vez que la solicitud ha sido completamente procesada por el work
process la respuesta es enviada nuevamente a través del dispatcher al SAP GUI. El SAP
GUI interpreta la respuesta y genera una pantalla para el usuario.

Figura 19 – Flujo de procesamiento de solicitudes de diálogo.

En la figura podemos observar la relación entre los componentes y en cual sentido se
realiza la comunicación en cada caso.
Los buffers que se muestran dentro del área indicada como Shared Memory (Memoria
Compartida) ayudan a agilizar el tiempo de la respuesta por parte del servidor de
aplicación a la capa de presentación SAP GUI ya que datos que son accedidos
frecuentemente pueden alojarse en alguno de estos buffers en vez de tener que
solicitarlos a través de una consulta a la base de datos.
Interface con la base de datos del sistema
Dentro del lenguaje de programación ABAP el programador puede utilizar lo que se
conoce como ABAP Open SQL (SQL = Structured Query Language) 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
Native SQL (SQL Nativo).
Esto es importante porque de esta manera los programas ABAP aseguran que sean
independientes de la base de datos.
Otra ventaja importante 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 del servidor de aplicación SAP para acceder a los datos rápidamente.
Mucha información que no suele cambiar frecuentemente es la que se aloja en estos
buffers del AS ABAP, entre otros, se encuentran los programas ABAP, las pantallas,
información del diccionario ABAP y tablas con datos estáticos.

Figura 20 – Flujo de sentencias SQL.

Sin embargo es posible utilizar Native SQL para acceder a los objetos de la base de
datos, esto significa que la interface de base de datos y el buffer local no serán
utilizados en estos casos.
Si el programa ABAP tiene en su código sentencias Native SQL, este pierde la
independencia de la plataforma de base de datos del sistema SAP.

Lección 4: Proceso de Bloqueo
Para asegurar la consistencia de datos dentro de nuestro sistema SAP, debemos
asegurarnos de que los registros de datos no puedan ser accesados y cambiados por
más de un usuario al mismo tiempo.
Para lograr esto, el sistema SAP tiene su propio concepto de administración de
bloqueos (lock management)
Transacciones de base de datos
Desde la perspectiva de la base de datos, vimos en la lección anterior que cada paso
de diálogo forma una unidad física y lógica: la transacción de base de datos. El sistema
de base de datos sobre el que corre nuestro sistema SAP puede coordinar este tipo de
transacciones de base de datos.

Transacciones SAP
Desde el punto de vista de SAP, de todas formas, esto no es suficiente para asegurar
la consistencia porque las transacciones SAP, las cuales se forman por una secuencia
lógica de pasos de trabajo relacionados que son consistentes en términos de negocio,
los cuales se forman generalmente de varios pasos de diálogo.
El sistema SAP necesita administrar su propio concepto de bloqueo. Esto se logra
utilizando el work process de enqueue (encolado). Esto también asegura la
independencia de plataforma utilizada para el sistema.
Sistema de bloqueo en SAP
El concepto de bloqueo de SAP funciona sobre el principio de que los programas SAP
realizan entradas de registros en la tabla de bloqueo (lock table). Solo pueden
generarse nuevas entradas en esta tabla si no existen otras ya para el objeto que
intenta bloquearse.
Enqueue Work Process
El enqueue work process maneja los bloqueos lógicos de las transacciones de SAP en
la tabla de bloqueo. Esta tabla se sitúa en la memoria principal de la instancia donde el
proceso corre.

Figura 21 – Gestión de bloqueos en SAP

En la figura 21 se muestra un escenario con dos instancias, podemos deducir que la
instancia central es aquella donde el enqueue work process se encuentra corriendo.
Un work process de diálogo que corre en la misma instancia que el enqueue work
process puede acceder directamente a la tabla de bloqueo en la memoria principal
para chequear si un nuevo bloqueo puede generarse, esto es, si no ocurrirá un
conflicto con un bloqueo ya establecido.
Si el bloqueo puede crearse, entonces el work process de diálogo crea la entrada en la
tabla y se le entrega una key (llave) al usuario la cual se mantiene en la memoria de
contexto de usuario.

Si el work process de diálogo y el enqueue work process corren en diferentes
instancias se comunicarán a través del message server. En este caso la solicitud de
bloqueo se reenvía desde el work process de diálogo al enqueue work process a través
de los respectivos dispatchers y el message server. Ahora el enqueue work process es
quien se encarga de chequear si puede crearse un bloqueo en la tabla. Si esto es
posible, el bloqueo se realiza y la key generada se envía a través del dispatcher y el
message server.
Modos de bloqueos
Cuando se solicita el bloqueo, el sistema verifica si el bloqueo generará un conflicto
con alguna de las entradas que ya pudiesen existir en la tabla. Si esto ocurre, la
solicitud de bloqueo es rechazada. La aplicación informa al usuario que la operación
solicitada no puede realizarse en este momento.
Los desarrolladores son quienes deciden el modo de bloqueo para la aplicación:
Bloqueo de Escritura Exclusivo (Exclusive write lock), denominado con la letra E en la
tabla de bloqueos. Los datos bloqueados solo pueden ser editados por un usuario. El
modo Exclusivo (E) rechaza cualquier otro tipo de bloqueo por otra transacción. Sólo
puede acumular otros bloqueos E por el mismo usuario.
Bloqueo de Lectura Compartido (Shared Lock Mode), estos bloqueos se identifican
con la letra S en la tabla de bloqueo. Se aceptan solicitudes adicionales de lectura. Una
solicitud de escritura es rechazada.
Bloqueo de Escritura Mejorado (Exclusive Noncumulative Write Lock), identificados
con la letra X en la tabla, solo puede ser solicitado una vez, todas las demás solicitudes
se rechazan.
Bloqueo Optimístico (Optimistic Lock), denominados con la letra O en la tabla de
bloqueo. Al comienzo se establecen como bloqueos de lectura y luego pueden
transformarse en bloqueos de escritura. Permite bloqueos adicionales del mismo tipo
sobre un objeto. Cuando un usuario pasa al modo de modificación en una transacción
el bloqueo pasa al tipo E. Si otros bloqueos de tipo O existen sobre el objeto estos son
eliminados de la tabla.
La transacción SM12 muestra los bloqueos que actualmente hay en el sistema.

Figura 22 – Transacción SM12

Lección 5: Proceso de Update
En el sistema SAP, un proceso de negocio es mapeado utilizando una transacción que
puede contener varios cambios de pantalla, por ejemplo, la creación de una orden de
compra.
Los cambios en los datos efectuados en este proceso se suponen que serán ejecutados
completamente o no serán modificados en absoluto en la base de datos (concepto
Atómico del sistema transaccional).
Si la operación es finalizada durante la ejecución o un error ocurre, entonces ningún
cambio en la base de datos debe efectuarse. El sistema de Actualización de SAP (SAP
Update System), el cual se describe a continuación, es quien se encarga de esto.

El sistema de actualización
El sistema de actualización es una tecnología que permite a las transacciones de SAP
quitar carga de trabajo intensa en los cambios a nivel de la base de datos. Estos
cambios se realizan luego de manera asincrónica en un proceso especial denominado
update work process (proceso de actualización).
Los procesos de diálogo pasan los datos que van a escribirse en la base de datos al
proceso de actualización. El proceso de diálogo no espera que la actualización se
complete para continuar, por esto es que la actualización es asincrónica, no en
simultáneo. Los pasos que suceden en un proceso de actualización se muestra en la
siguiente figura:

Figura 23 – Principio de actualización asincrónica.

La tarea del proceso de diálogo se completa con el comando ABAP COMMIT WORK ; la
parte de actualización de la transacción comienza aquí: el message server transfiere la
solicitud de actualización a un proceso de actualización. Aquí, cada paso de diálogo
corresponde a una transacción de base de datos, la cual se realiza completamente o
no con un comando COMMIT.

La parte de actualización de la transacción SAP es ejecutada en una única transacción
de base de datos. Es en ese momento cuando los datos se copian a las tablas de la
aplicación. Si un usuario quiere cambiar datos en una transacción SAP, llama a la
transacción correspondiente en diálogo, realiza las entradas o modificaciones en las
pantallas y luego inicia el proceso de actualización cuando guarda los datos.
Proceso de actualización asincrónica
Veamos ahora que pasos suceden cuando se realiza una modificación de datos en una
transacción SAP:
El programa bloquea los registros de datos de la aplicación para otros usuarios. Esto
se logra por supuesto a través del enqueue work process (utilizando el message server
si fuese apropiado). El enqueue work process realizará las entradas correspondientes
en la tabla de bloqueo si es que ya no están bloqueados los datos por otro usuario, en
este caso informará al usuario que los datos no pueden modificarse en este momento.
Si el enqueue work process puede realizar el bloqueo en la tabla de bloqueo, envía la
clave de bloqueo (lock key) al usuario. El programa lee el o los registros que serán
modificados desde la base de datos y el usuario realiza las modificaciones en la
pantalla de la transacción SAP.
En el proceso de diálogo active, el programa llama a un modulo de función ABAP
usando la sentencia CALL FUNCTION … IN UPDATE TASK y escribe los cambios
realizados por el usuario a las tablas de actualización de la base de datos. Estas tablas
se conocen como las tablas VB* porque sus nombres comienzan con las letras “VB”.
Actúan como memoria temporaria y guardan los datos que serán modificados hasta
que puedan ser guardados en las tablas de la aplicación en la base de datos en una
única transacción de base de datos.
En el final de la parte de diálogo de la transacción, por ejemplo, cuando el usuario
guarda los datos (posiblemente luego de completar otros pasos de diálogo), el
programa inicia la finalización de la transacción con la sentencia ABAP COMMIT WORK.
El proceso de diálogo que hasta acá manejo el paso de diálogo dispara ahora el
proceso de actualización.
En base a la información que recibe del proceso de diálogo (datos para actualizar,
clave de bloqueo) el proceso de actualización lee las tablas VB* para identificar los
datos que pertenecen a esta transacción SAP ya que pueden haber más registros en la
tabla VB* al mismo tiempo de otras transacciones SAP.
El proceso de actualización transfiere los cambios marcados y obtenidos de las tablas
VB* a la base de datos con una sentencia única de actualización en las tablas de la
aplicación y evalúa la respuesta de la base. Si los cambios son realizados, el proceso
de actualización confirma los cambios con el comando de base de datos commit luego
del último cambio en la base de datos y borra las entradas de las tablas VB*. Si un
error ocurre, el proceso de actualización dispara un rollback en la base de datos y deja
la información en las tablas VB* marcándola como defectuosa.
Por último, las entradas en la tabla de bloqueo son eliminadas.

Los pasos explicados previamente son los que se ilustran en la siguiente imagen:

Figura 24 – Proceso de actualización asincrónico

La transacción SM13 nos permite visualizar si existen actualizaciones pendientes en el
sistema SAP y cuál es su estado. Aquellas que están marcadas como erróneas no
deben reprocesarse por el administrador sino por el mismo usuario utilizando la
transacción para tal fin.

Figura 25 – Transacción SM13 – Actualizaciones

Lección 6: Otros Procesos ABAP
Impresión
El sistema SAP provee una amplia variedad de opciones para representar los datos de
negocio u otros. Estos datos, creados y formateados en un paso de diálogo, pueden
luego ser enviados a impresoras y otros dispositivos de salidas como faxes, e-mails,
etc. Particularmente una impresora debe ser configurada en el sistema antes de que
pueda ser utilizada.

Los usuarios pueden seleccionar al momento de imprimir entre las impresoras
configuradas en el sistema. También cada usuario puede tener una impresora
configurada por defecto en su registro de usuario (Transacción SU01).
Una vez que la impresora está configurada, el sistema SAP tiene toda la información
que necesita para poder crear lo que se denomina un spool request.
Spool Request
Un spool request contiene información sobre los datos de salida (output), su formato y
el modelo de impresora utilizado. El spool request generado se almacena en un área
temporal de almacenamiento llamada TemSe (temporary sequential file)
Los spool requests pueden ser creados por procesos de diálogo o por procesos de
background. Los procesos de spool no crean spool requests.

Figura 26 – Impresión en un servidor de aplicación ABAP

Spool work process
Como puede verse en la figura 26, un spool work process formatea los datos
especificados en el spool request y crea un output request. El output request contiene
todos los datos en un formato apropiado para la impresora específica que el usuario
seleccionó. Estos datos pueden ser enviados por el spool work process al sistema
operativo que puede ser local si es en la misma computadora o remoto si es a través
de la red.
De todas maneras, veremos con mayor detalle la administración de impresión más
adelante en el curso.
Dos transacciones que son útiles son la transacción SP02 donde podemos ver nuestros
propios spool requests y output requests. La otra es la transacción SU3 donde
podemos especificar configuraciones personales de impresión en la sección Spool
Control.

Figura 27 – Transacción SP02

Figura 28 –Transacción SU3: Configuraciones Personales

Procesamiento en Background
El procesamiento en background del sistema SAP es un método para automatizar
tareas rutinarias y para optimizar el uso de recursos de los sistemas SAP en una
organización.
Podemos utilizar el procesamiento en background para ejecutar programas que
insumen mucho tiempo o hacen un uso intensivo de recursos, por ejemplo la base de
datos, y programarlos para que corran fuera de horarios de picos altos de utilización.
Los programas que se ejecutan utilizando el procesamiento de background no están
sujetos a las restricciones de los procesos de diálogo que luego de un tiempo definido
son terminados por el sistema.

El background process
La separación del procesamiento de background en work process especiales nos da
una dimensión adicional para separar el procesamiento de background del de diálogo.
Normalmente el procesamiento de background y el procesamiento interactivo, o de
diálogo se realizan en distintos tiempos. Diálogo durante el día y background durante
la noche.
También es posible utilizar los background work process para separar el procesamiento
de background y el trabajo interactivo en diferentes servidores de aplicación (o
instancias).

Figura 29 – Planificación de tareas de background (Jobs)

El planeamiento se realiza mediante los work processes de diálogo y luego la ejecución
la realiza el background work process como se ve en la figura 29.
La transacción SMX nos muestra los jobs planificados por nuestro usuario.

Figura 285 – Transacción SMX

Comunicación vía el Gateway
Cada instancia de un sistema ABAP (o ABAP+JAVA) contiene un Gateway. Este es
utilizado para la comunicación entre los work processes de diferentes instancias o
sistemas SAP así también como con programas externos. El Gateway reader,
usualmente llamado solamente Gateway, es el proceso principal del sistema de
Gateway. El dispatcher se encarga de iniciarlo y verificarlo periódicamente.

Figura 30 – Comunicación vía Gateway

En las comunicaciones entre instancias o sistemas SAP realizadas utilizando funciones
remotas (Remote Function Call) RFC o CPIC siempre está involucrado el Gateway de
cada instancia. Como se muestra en la imagen, la comunicación se inicia en el proceso
de diálogo, pasa por el dispatcher y se reenvía al Gateway para establecer la
comunicación con su par de la otra instancia (u otro sistema SAP).
Con la transacción SMGW se pueden monitorear las conexiones del Gateway.

Internet Communication Manager (ICM)
El Internet Communication Manager (Administrador de Comunicaciones de Internet) es
quien se encarga de que funcionen adecuadamente las comunicaciones entre un
sistema SAP (Servidor de aplicación SAP Netweaver) y el mundo exterior vía los
protocolos HTTP, HTTPS y SMTP. En su rol como servidor, el ICM puede procesar
solicitudes que llegan desde Internet como URLs con la combinación de servidorpuerto en la cual el ICM está configurado para escuchar. El ICM luego llama al proceso
local del servidor de aplicación que se ocupará finalmente de la solicitud URL.
Como consideración para la implementación, debemos pensar que necesitaremos del
ICM si queremos que el servidor de aplicación SAP tenga comunicación con Internet a
través de alguno de los protocolos ya mencionados.
El ICM es un componente del servidor de aplicación SAP, por lo que podremos
administrar uno por cada instancia del sistema SAP. Es un proceso que se implementa
por separado el cual es iniciado y monitoreado por el dispatcher. Se puede configurar a
través de parámetros que se configuran en los perfiles de cada instancia.

Figura 31 – Internet Communication Manager (ICM)

Tareas Básicas de Administración
Lección 1: Proceso de Logon en un sistema ABAP
Para crear una conexión entre el front-end (interfaz de usuario) y una instancia de un
sistema SAP, el programa sapgui requiere cierta información como parámetros de
inicio. Estos parámetros, normalmente son creados utilizando el programa saplogon.
Esta información se almacena parcialmente en archivos de configuración del SAP
Logon y parcialmente se obtiene directamente de una consulta al proceso Message

Server del sistema SAP. El SAP Logon luego puede iniciar el programa SAP GUI con
estas especificaciones obtenidas.
Veamos en la siguiente figura como sucede el proceso de logon al sistema SAP.

Figura 32 – Proceso de Logon al sistema SAP ABAP

Luego de que la pantalla de logon se transfiere desde el dispatcher al front-end (no
mostrado en la figura), el usuario envía a través del SAP GUI los datos de logon
necesarios: cliente, usuario, contraseña y opcionalmente el idioma de logon. Esto se
muestra en el paso 3 de la figura.
Luego de que el dispatcher dispone de un work process de diálogo libre para procesar
el logon, transfiere los datos de logon a este work process, paso 4.
El work process ahora verifica si la combinación de usuario y contraseña es válida para
el sistema enviando una consulta a la base de datos (pasos 5 al 8).
Una respuesta positiva de la base de datos al work process resulta en el envío de la
pantalla inicial del sistema al front-end.
Durante la sesión de logon, la asignación del usuario a la instancia es única. Esto
significa que una vez que el usuario ingresa al sistema estará asignado a trabajar en
una instancia determinada por el message server durante todo el tiempo que el
usuario este logueado con la sesión.
Solamente durante un nuevo logon el usuario posiblemente sea asignado a una
instancia diferente por el message server.
Es posible loguearse al sistema sin pasar a través del Message Server. Para esto
debemos especificar explícitamente la instancia a la que vamos a realizar la
conexión.

Lección 2: Configuración del SAP Logon
El programa SAP Logón provee a los usuarios una forma sencilla de loguearse a un
sistema SAP a través del programa para Windows SAP GUI.
Existen versiones de programas SAP GUI basados en JAVA que pueden ser
utilizados en entornos como Linux, MacOS, etc. SAP Logón fue diseñado para
front-ends de plataformas Windows.
El programa SAP Logon evalúa varios archivos de configuración que se encuentran en
el front-end del usuario. Estos archivos también pueden ser editados utilizando SAP
Logon.

Figura 33 – Programa SAP logon

En principio, SAP Logon simplemente inicia el programa SAP GUI para un sistema SAP
seleccionado con ciertos parámetros. (ver también la cadena de conexión SAP GUI)

Figura 34 – SAP Logon, Sistemas.

Se pueden realizar varias configuraciones generales a través de las opciones de SAP
Logon. Se puede por ejemplo, configurar los niveles de trace para conexiones SAP GUI.
Las contraseñas pueden también quedar registradas en el archivo de trace generado,
por lo que deberemos tener especial cuidado al utilizarlo; el archivo de trace debería
ser eliminado una vez que sea utilizado.
Podemos utilizar el botón Nueva entrada… para crear una nueva conexión a un
sistema. Una especie de asistente nos lleva a través de varias opciones para crear
nuevas conexiones. Hay tres posibles opciones:
1. La selección de un sistema que ya fue previamente configurado en el archivo

sapmsg.ini seguido de la selección del modo de logón: Grupo de logón o logón a una
instancia específica.

Figura 35 – Opción 1

2. La definición de una nueva conexión, eligiendo la opción Sistema específico de
usuario, en donde se realiza una consulta al Message Server para conocer que
servidores o grupos de servidores existen en el sistema.

Figura 36 – Opción 2

3. La definición de una nueva conexión también pero como sistema específico de
usuario con la especificación explícita de todos los detalles de conexión (Servidor de
aplicación, número de sistema y ID de sistema) sin consultar al Message Server.

Figura 37 – Opción 3

En los casos 1 y 2 se necesita del ABAP Message Server del sistema al que
queremos crear la conexión. En el caso 3, definimos una conexión directa al
dispatcher seleccionado, o sea a una instancia específica del sistema. No hay
necesidad de una consulta al Message Server aquí.
Si ves los botones Grupos… y Servidor… en vez del botón Nueva Entrada… el
asistente está desactivado. Para activarlo, selecciona Opciones desde el menú en
la esquina superior izquierda del SAP Logon. Selecciona la opción Con Asistente y
confirma con OK y luego con Sí.

Figura 38 - Activación de Asistente

Cuando nos logueamos utilizando un grupo de logon, el message server de ABAP es
consultado primero para poder identificar la instancia con mayor disponibilidad en base

a la cantidad de work process de diálogo que tenga configurada y los usuarios que ya
estén conectados a esta en el momento dentro del grupo de logón elegido.
El archivo de configuración sapmsg.ini se evalúa para mostrar los sistemas ya
configurados en el SAP Logon. La siguiente imagen muestra un ejemplo del contenido
del archivo sapmsg.ini:

Figura 39 - Archivo sampsg.ini

El message server del sistema seleccionado es consultado para mostrar los grupos de
logón y servidores de aplicación disponibles.
Para que la conexión al message server del sistema específico en el archivo sapmsg.ini
funcione es necesario del archivo services de Microsoft Windows con el cual se
especifica el puerto de comunicación del message server del ID (Identification) del
sistema seleccionado, denominado SID (System ID). Continuando el ejemplo se
muestra las entradas en el archivo servicespara los puertos del Message Server de
cada sistema:

Figura 40 - Archivo services

Una conexión es luego creada al servidor y al message server que corre sobre este
utilizando la información de los archivos sapmsg.ini yservices.
Resumen de la utilización de archivos por SAP Logon
Inicio de SAP Logon: lee saplogon.ini
Botón Acceder al Sistema: accede al sistema seleccionado

Botón Entrada Sistema Variable…: Ningún cambio al archivo saplogon.ini, evalúa los
archivos sapmsg.ini y services.
Botón Nueva Entrada…: Edita saplogon.ini, evalúa sapmsg.ini y el archivo services.
Botón Modificar Entrada…: Edita saplogon.ini
Botón Borrar Entrada…: Edita saplogon.ini
Con el botón Nueva Entrada…, se puede crear una conexión a un sistema SAP que no
necesariamente se encuentra en el archivo sapmsg.ini y el archivo services.
En este caso tendremos que ingresar toda la información que es relevante para
loguearse al sistema.

Figura 41 - Configuración específica de usuario

El nombre del servidor o dirección IP donde se encuentra la instancia a la que
queremos contactar y el número de sistema son esenciales, así también como el SID
del sistema y una descripción.
El número de instancia especifica los últimos dos dígitos del puerto de 4 dígitos que
utiliza el dispatcher de cada instancia. Los primeros dos dígitos son fijos, y son 32. Esto
significa que los números de puertos entre 3200 y 3299 son posibles. Los puertos 3298
y 3299 están asignados a los programas niping y saprouter y no se deberían utilizar
para los puertos de los dispatchers.
La configuración para una conexión, tal como su nombre en el SAP Logon, puede ser
modificada utilizando el botón Modificar Entrada…
Se puede especificar un string (secuencia) de SAProuter para las conexiones de SAP
GUI. Un SAProuter es asignado a la transferencia de datos para esta conexión. El
Saprouter es un programa que actúa como un punto intermedio en la conexión entre el
front-end y el sistema SAP.

¿Dónde se almacena cada archivo?
La siguiente lista muestra los archivos que mencionamos anteriormente y cuáles son
sus posibles ubicaciones; en el caso de múltiples lugares posibles, la secuencia que
utiliza SAP Logon también se muestra:

saplogon.ini, sapmsg.ini, saprouter.ini:
1.Directorio de SAP GUI
2.Directorio de Windows
services (Windows)
Windows/system32/drivers/etc/services
Otra opción es configurar shortcuts (accesos directos) utilizando la solapa Accesos
Directos en el SAP Logon.
Con los shortcuts, necesitamos ingresar el password, después de la cual el sistema nos
lleva directamente a una transacción preasignada.
En teoría, también es posible guardar el password en el shortcut. De todas formas, no
es recomendable por cuestiones de seguridad. Los shortcuts se guardan en un archivo
llamado sapshortcut.ini en el directorio de Windows en la computadora del usuario,
front-end.
String de conexión SAP GUI
El string de conexión SAP GUI describe una serie de parámetros para llamar al
programa SAP GUI.
En su forma más simple, una llamada a SAP GUI puede verse de la siguiente forma:
Sapgui
Si se va a utilizar un grupo de logón, la estructura de conexión es algo más compleja:
/M/
Para especificar el servidor del Message Server, luego
/S/
Para especificar el Puerto del Message Server, y
/G/
Es utilizado para especificar el nombre del grupo de logón seleccionado.
sapgui/M/<servidor_de_Message_Server>/S/<Puerto_Message_Server>/
G/<Grupo_de_Logon>
Esta sería la estructura completa de un string de conexión completo
sapgui/M/sapdp01/S/3600/G/SPACE sería un ejemplo concreto del string de conexión.

Utilización de Grupos de Logon
Los sistemas SAP muchas veces tienen más que sólo una o dos instancias. Cada una
de estas instancias ofrece una cantidad de work processes de varios tipos y pueden
acceder a los recursos de hardware.
Algunas situaciones en las que las tareas a realizar en una instancia demandan una
utilización intensiva del hardware, por lo tanto, degradando todo el trabajo que pueda
ser realizado en esta instancia. Largos tiempos de respuesta de los procesos de diálogo
son particularmente molestos para los usuarios que se ven afectados por esto lo que
lleva a costos altos debido a una pobre disponibilidad del sistema. Ejemplos de estas
situaciones pueden ser:
Carga debido a un gran número de solicitudes RFC externas.
Carga debido a un complejo esquema de work processes de background
Carga debido a numerosas tareas de update
Alternativas podemos utilizar para separar las cargas de trabajo mediante los grupos
de logon:
Configurar un grupo de logon especial para recibir solicitudes RFC
Configurar un grupo de logon especial para las actividades de background
Configurar un grupo de logon especial para las tareas de diálogo
Utilizar un grupo de logon para distribuir la carga de diálogo de la mejor manera
SAP recomienda que en los sistemas SAP con instancias múltiples configurar un grupo
de logon para las conexiones de diálogo con el objetivo de que los usuarios
experimenten tiempos de respuesta similares.
Este grupo de logon es llamado por ejemplo PUBLIC. Si consideramos que es útil,
podemos elegir no incluir la instancia central de nuestro sistema SAP en este grupo de
logon.
Por defecto, cada instancia de un sistema SAP (incluyendo la instancia central) es
asignada al grupo de logon SPACE.
La transacción SMLG es la que nos permitirá crear y administrar los grupos de logon en
el sistema.

Lección 3: Transacciones de Análisis
SM51 – Ver las instancias activas y los servicios que cada una ofrece, dando clic en el
host name.

Dando clic en el botón Release Notes podemos observar la versión del Kernel

Para pasar a la transacción sm04 podemos dar clic en el botón de usuarios para ver
que usuarios se encuentran logueados en la misma instancia

Podemos observar las sesiones del usuario, seleccionamos el usuario y damos clic en el
botón Sessions.

Podemos cerrar alguna sesión del usuario.

La transacción al08 es informativa, podemos observar los usuarios que se encuentran
logueados.

La transacción sm50 muestra una vista de procesos,

Podemos modificar el nivel de trace para un work processes determinado.

En la transacción sm21, podemos visualizar diferentes tipos de eventos registrados por
el sistema,

El nivel de prioridad identifica donde sucedió un problema

La transacción st22, nos permite ver los errores en tiempo de ejecución
programas ABAP

de los

La información recopilada por el sistema luego de que ocurre el error, se divide en
diferentes áreas de vista para ser visualizada por el usuario, el programador o por el
administrador del sistema.

La transacción sm02 es utilizada para crear mensajes para ser visualizados por el
usuario del sistema, son visto por el usuario cuando cambia de transacción.

Lección 4: Inicio y parada del sistema SAP.

Lección 5: Logs de Inicio del sistema
Problemas ocurridos durante el inicio del sistema SAP deben ser analizados por el
administrador del sistema. Los archivos de log y trace generados son de gran ayuda
para identificar la causa.
Registrando el Proceso de Inicio
El proceso de inicio es una fase especialmente importante, el cual es registrado por el
sistema operativo, el sistema SAP y la base de datos.

Si el sistema SAP no inicia, podemos encontrar mensajes de error pertinentes en los
archivos de log. Podría ser por ejemplo que existan problemas iniciando la base de
datos, lo que significa que el sistema SAP no podría ser iniciado.

Figura 42 – Registrando el Proceso de Inicio del Sistema SAP

Los logs sobre el proceso de inicio del sistema SAP se almacenan en el file system. Si
hay problemas durante el inicio, estos logs pueden proveer información muy útil tal
como mensajes de error o descripción de problemas.
Estos archivos están en el directorio local (DIR_HOME) de la instancia respectiva.
Durante el proceso de inicio, los archivos de log STDERR son creados por el Servicio de
SAP.
Los procesos de inicio escriben cada uno de estos archivos, dependiendo de la
secuencia en la que estos componentes están listados en el perfil de inicio de la
instancia (start profile).
El contenido de estos archivos de log por lo tanto depende de la configuración
individual del sistema, y podría, por ejemplo, ser como sigue:
STDERR1: Información sobre el proceso de inicio del sistema de base de datos.
STDERR2: Información sobre el proceso de inicio del message server.
STDERR3: Información sobre el proceso de inicio del dispatcher.
Puedes configurar el nivel de detalle de la información registrada en cuatro niveles
diferentes a través del parámetro de perfil rdisp/TRACE. Los posibles valores para este
parámetro son:
0:
1:
2:
3:

Solamente errores
Errores y advertencias (por defecto)
Mensajes de error y resumen de traza (trace)
Mensajes de error y traza completa

Cuanto más alto el nivel de traza, más grande la cantidad de información registrada, y
por lo tanto mayor el tamaño de los archivos generados. En conclusión, deberíamos
incrementar el valor por defecto sólo por períodos cortos para el análisis de problemas.
El nivel de traza puede ser configurado por separado para cada work process en la
vista de procesos (Transacción SM50).

Figure 43 - Análisis de Problemas

Si el sistema SAP no inicia correctamente, esto puede ser debido a una variedad de
razones.
Para analizar el problema, podemos proceder de la siguiente manera:
Verifica los mensajes de error y advertencia en el sistema operativo con las
herramientas correspondientes del mismo.
Verifica el status de la base de datos respectiva utilizando los archivos de log de
errores.
(Puedes encontrar más información en la lección: Apéndice: Logs de Base de Datos)
Verifica el log de inicio en la consola de SAP (SAP MC). Selecciona la instancia que
está con problemas, y desde el menú de contexto, selecciona List Developer Traces
(Listar Trazas de Desarrollador)
Verifica los archivos de error stderr que fueron creados por el Servicio de SAP.
Verifica los trace files (archivos de traza) individuales de los work processes:
dev_ms: developer trace (traza de desarrollador) del Message Server.
dev_rd: developer trace del Gateway.
dev_disp: developer trace para el dispatcher
dev_wm: developer trace para los work processes (m es el número de ID de work
process que vemos en la transacción SM50).
Si aún puedes loguearte al sistema SAP, verfica el log del sistema utilizando la
transacción SM21.

Lección 6: Apéndice - Logs de Base de Datos.
En algunas ocasiones, frente a un error con nuestro sistema SAP, deberemos acceder a
los logs de la base de datos sobre la que está instalado el sistema.
1| Max DB

Figura 44 – Logs de Max DB

Los mensajes de sistema y errores son registrados por Max DB en el siguiente
directorio:
<Unidad>:\sapdb\data\wrk\<SID>
Donde <SID> es el nombre de nuestra base de datos, la cual coincide con el del
sistema SAP.
Los mensajes de sistema son registrados en el log del Kernel (knldiag). Este contiene
los siguientes tipos de mensaje en un orden cronológico:
Inicio y parada de la base de datos.
Información sobre las áreas físicas de almacenamiento.
Procesos de usuarios.
Mensajes de error de sistema
El log se escribe con una modalidad conocida como anillo o circular, lo que significa
que es sobreescrita cada vez que alcanza un cierto tamaño. Un nuevo archivo de log
es creado después de cada inicio del sistema de base de datos.
Una copia del log anterior (knldiag.old) se crea antes de reiniciar el sistema de base de
datos.
Todos los mensajes de error y advertencia relativos al sistema de base de datos son
registrados en el log de errores (knldiag.err), incluyendo los mensajes para el inicio y
parada de sistema.

2| MS SQL Server

Figura 45 – Logs de MS SQL Server

MS SQL Server registra todos los eventos significativos tales como los de inicio y
parada de la base de datos y mensajes de error en el archivo:
<Unidad>:…\MSSQL\LOG\ERRORLOG
Una nueva versión del archivo de log de errores es creado con cada inicio del MS SQL
SERVER. Las versiones de estos archivos de logs se almacenan en el órden
ERRORLOG.1, ERRORLOG.2 y así sucesivamente.
La versión más vieja se almacena como ERRORLOG.6. En cada reinicio del SQL Server,
el archivo más antiguo (ERRORLOG.6) se sobreescrito y los demás se renombran para
mantener el órden mencionado.
Estos archivos de logs pueden ser visualizados utilizando la herramienta del sistema
MS SQL SERVER: Enterprise Manager o Management Studio dependiendo la versión.
Los mensajes registrados por el servicio SQLServerAgent también se almacenan en la
misma ubicación con el nombre de archivo SQLAGENT.OUT. Las últimas seis versiones
de este log también son guardadas.
3| ORACLE

Figura 46 – Logs de Oracle

La base de datos Oracle registra todos los eventos significativos tales como el inicio y
parada de la base de datos y mensajes de error en el archivo:
<Unidad>:\oracle\<SID>\saptrace\background\ALRT.LOG.
Información detallada sobre errors se registra en el archivo de traza de Oracle (Oracle
trace file):
<Unidad>:\oracle\<SID>\saptrace\usertrace\Ora<no>.trc.
Si el administrador del sistema administra la base de datos con el usuario sapdba, este
escribe sus propios archivos de log en los siguientes directorios:
<Unidad>:\oracle\<SID>\sapreorg
<Unidad>:\oracle\<SID>\sapcheck
<Unidad>:\oracle\<SID>\sapbackup
4| DB2 (UDB)

Figura 47 – Logs de DB2

La base de datos DB2 registra todos los eventos significativos en el archivo
db2diag.log. La ruta bajo la cual este archivo estará almacenado se define con el
parámetro Diagnostic Directory Data Path (DIAGPATH).
Esta ruta se configura en el Database Manager Configuration. El valor por defecto es :
$DB2INSPROF/DB2INSTANCE.
El archivo db2diag.log contiene la siguiente información:
El lugar en el cual el error ha sido reportado. Los IDs de la aplicaciones permiten la
comparación entre entradas que pertenecen a una aplicación particular tal como SAP
en el archivo db2diag.log
Un mensaje de diagnóstico con la razón del error. El mensaje usualmente comienza
con “DIA”.
Toda la información disponible tal como la estructura de datos SQLCA y punteros a
otros archivos de dump o trap.
Información detallada sobre los errores se registra en los archivos de traza (trace) o
volcado (dump) DB2, los cuales también se almacenan en la ruta definida por el

parámetro DIAGPATH. Estos archivos son solamente creados si un problema serio
interno de DB2 ocurre.
Podemos acceder al directorio de volcado mediante la transacción DB6COCKPIT y
seleccionando Diagnósticos –> Directorio de Volcado en el área de navegación.
Si lo que queremos es mostrar el contenido de un log de error o un archivo de traza,
solo necesitamos hacer doble click sobre el archivo.
5| Informix

Figura 48 - Logs de Informix

Todos los eventos significativos, tales como inicio y parada de la base de datos y
mensajes de error son registrados por INFORMIX en el archivo:
$INFORMIXDIR/online.<hostname>.<SID>.log
Información detallada de los errores se registra en el archivo de traza (trace file)
af.<unique no>
En ciertas ocasiones, el contenido de la memoria compartida es copiada a los archivos
shmem.<unique no>
El directorio en donde estos archivos son almacenados se define utilizando el
parámetro DUMPDIR. El valor por defecto de este parámetro es /tmp.

Mantener el sistema y la base de datos
Lección 1: Evaluación de parámetros SAP
En muchas ocasiones, ya sea porque necesitamos resolver algún problema o porque
nos gustaría realizar ajustes en el sistema para mejorar la performance del mismo
tendremos que evaluar y mantener los parámetros del sistema SAP.
Configuración de los Parámetros del Sistema
La configuración de las instancias y por lo tanto del sistema SAP se realiza usando los
parámetros del sistema. Los valores por defecto para estos parámetros son definidos
en el código de programa del kernel del sistema.

Figura 49 – Asignando los Parámetros del Sistema

La figura muestra los lugares donde están definidos los parámetros del sistema y la
secuencia de lectura de los mismos. También podemos observar que existe una
prioridad o peso del parámetro dependiendo de dónde lo definamos. Esto significa que
un parámetro que tiene un valor definido por defecto en el kernel del sistema, cuando
está definido en el perfil DEFAULT.PFL tomará el valor de este último, y si está definido
también en el perfil de la instancia, entonces será ese valor con el que finalmente
funcionará el sistema.
Podemos cambiar los valores por defecto de los parámetros utilizando los archivos de
perfiles, los cuales son leídos cuando las instancias del sistema se levantan. Estos
archivos de perfiles son creados durante la instalación del sistema y pueden ser
editados luego.
Como los archivos de perfiles son solamente leídos cuando inicia el sistema,
necesitamos reiniciar la instancia o el sistema completo después de cambiar algún
parámetro.
El dynamic switching (cambio dinámico) de parámetros, el cual se realiza mientras el
sistema se encuentra operando, es posible para un pequeño grupo de parámetros del
sistema.

Figura 50 – Archivos de Perfiles a nivel del Sistema Operativo

Los archivos de perfil son automáticamente creados durante la instalación. Después de
que se completa la instalación, los archivos de perfiles son almacenados a nivel del
sistema operativo en el directorio:
usr\sap\<SID>\SYS\profile
Este directorio puede ser leído por todas las instancias de un sistema SAP utilizando las
técnicas de montaje o de directorio compartido dependiendo el sistema operativo por
supuesto donde esté instalado el sistema.
El sistema SAP tiene tres perfiles de sistema. Estos son:
Start Profile (Perfil de Inicio)
Default Profile (Perfil por Defecto)
Instance Profile (Perfil de Instancia)
Visualización de los Parámetros
En principio, podemos cambiar estos archivos con herramientas de edición del sistema
operativo. Quienes editen estos archivos, deben asegurarse que los cambios realizados
sean correctos ya que si son configurados de manera incorrecta pueden llevar a que el
sistema no inicie.
Es mucho más conveniente y seguro realizar los cambios de los parámetros de perfiles
utilizando las herramientas en el sistema SAP.

Figura 51 – Archivos de Perfiles (Profile Files)

El perfil específico por instancia de inicio, cuya nomenclatura es:
START<instancia><número de instancia><nombre de servidor>
especifica que
procesos van a iniciar por cada instancia estos procesos son por ejemplo el MS y
dispatcher.
Existe solo un único pefil por defecto, cuyo nombre es DEFAULT.PFL, por cada sistema
SAP y el cual es leído por todas las instancias SAP. Contiene configuraciones que
afectan a todo el sistema, tal como el nombre del sistema, el nombre del servidor de
base de datos o el cliente de logon por defecto para el sistema.

El perfil de instancia, <SID>_<instancia número de instancia>_<nombre de servidor>
define parámetros que aplican para una instancia, tales como el número y tipo de work
processes, o la definición del tamaño de área de memoria principal asignada al sistema
SAP. El perfil de la instancia es por lo tanto específico por instancia.

Figura 52 – Visualización de Parámetros del Sistema

Los valores actuales de los parámetros del sistema pueden visualizarse en el sistema.
Para esto, podemos optar por dos maneras: el reporte RSPFPAR y la transacción RZ11.
Ambas funciones muestran los parámetros para la instancia en la que el usuario se
encuentra logueado.
El reporte RSPFPAR muestra una lista de todos los parámetros específicos de instancia,
y de los parámetros que aplican para todo el sistema también. Esta lista se puede
acotar a un rango específico de parámetros.
El resultado es una tabla donde se muestra por cada parámetro los valores por defecto
del sistema tal como están definidos en el programa del kernel y si el valor por defecto
ha sido anulado por un valor definido por el usuario ya sea en el perfil por defecto o
en el específico de la instancia, se mostrará este valor también. Una breve descripción
y, si se requiere, documentación para los parámetros puede ser visualizada también.

Figura 53 – Reporte RSPFPAR

La transacción RZ11 muestra información y documentación para los parámetros de
forma individual. También muestra con el indicador Conmutación Dinámica
(Dynamically Switchable) si el parámetro puede tomar un cambio de inmediato sin
tener que reiniciar el sistema.

Figura 54 – Transacción RZ11

Cuando modificamos un parámetro utilizando la transacción RZ11, la modificación se
mantendrá mientras la instancia esté activa. Una vez que reiniciemos la instancia el
valor del parámetro volverá al que estaba definido previamente ya sea del kernel o del
perfil de la instancia.
Modificar parámetros que tienen la propiedad de conmutación dinámica en la
transacción RZ11 es útil para realizar pruebas sin tener que reiniciar la instancia o el
sistema enteramente. Luego, si decidimos que el cambio debe ser permanente lo
haremos utilizando la herramienta de mantenimiento de parámetros, transacción RZ10.
En la tabla TPFYPROPTY, todos los parámetros que pueden ser cambiados
dinámicamente están identificados con el indicador Dinámico (Dynamic). Puedes
utilizar la transacción SE16, por ejemplo, para visualizar esta tabla.
Fuera del sistema SAP, podemos visualizar los parámetros a nivel del sistema operativo
si estamos trabajando con el usuario <SID>adm con el programa sappfpar. Podemos
obtener el valor actual de un parámetro con el comando sappfpar .
El comando sappfpar all devuelve una lista de todos los parámetros. Podemos verificar
que parámetros están configurados utilizando sappfpar check. El comando sappfpar
help devuelve una breve ayuda sobre las posibles opciones de ejecución del programa.
También es posible especificar un perfil de instancia, un número de instancia o el
nombre del sistema SAP con este comando si utilizamos las opciones pf=ruta y nombre
del perfil de la instancia, nr=número de la instancia o name=SID

Para la evaluación de los parámetros de perfiles utilizando las herramientas
descriptas, algunos parámetros de perfiles son los mismos para todo el sistema
mientras que otros serán diferentes por cada instancia. El reporte RSPFPAR
muestra la configuración de la instancia en la que se ejecuta el mismo.

Lección 2: Mantenimiento de parámetros SAP

Lección 3: Configuración de Modos de Operación

Lección 4: Tareas relacionadas a la base de datos de SAP
Esta primera lección de tres, describe de una manera simple la arquitectura y
funcionalidad de las bases de datos relacionales. Basándonos luego en este
conocimiento, veremos cómo realizar las actividades primarias de la base de datos
mediante la planificación en el calendario de base de datos, transacción DB13.
Fundamentos de Administración de Base de Datos
Un sistema de base de datos (Database Management System: DBMS) incluye procesos
de base de datos, un buffer en la memoria principal, data files (archivos de datos) que
contienen la información, y log files (archivos de registro) donde los cambios a la
información son registrados.
Cuando el sistema SAP inicia, todos los work processes se conectan a un proceso de la
base de datos. Las consultas a la base de datos pasan de los work processes de SAP a
los procesos de base de datos asignados, los cuales ejecutan la solicitud en la base de
datos.º
Los datos se almacenan en los data files, el acceso a los datos siempre se realiza
mediante la utilización del buffer en la memoria principal.
Procesos especiales de la base de datos se encargan del intercambio de datos entre el
buffer y los data files. Durante este intercambio, los datos se leen y se escriben
siempre en páginas completas, las cuales normalmente contienen cientos de registros
de datos.

Figura 55 - Conceptos de Base de Datos

Si se realizan cambios a los datos, estos son registrados en el log file, por lo tanto el
archivo contiene el estado de los cambios realizados a la base de datos. Solo los
cambios, pero no las páginas completas, se registran en el buffer de log.
Las entradas se escriben desde el log buffer al log file, el cual puede ser sólo uno o
más de uno dependiendo de la base de datos.

Para cada base de datos, existe un mecanismo que realiza un backup (respaldo) de la
información desde el log file a otros archivos o a un medio de backup. Esto asegura
que el archivo de log no se vuelva demasiado grande porque con cada respaldo del log
file, el espacio ocupado por la información respaldada es liberado por el sistema de
base de datos para ser reutilizado y registrar nuevos cambios a la base de datos en el
log file.
SAP recomienda que realicemos un espejado del archivo de log. Algunas bases de
datos proveen un software especial que realiza el espejado de los archivos.
El espejado de log file mediante este software especial se realiza mediante una
escritura de dos log files en paralelo (primario y secundario). El sistema de base de
datos puede solamente sobrescribir los archivos de log primario y secundario una vez
que el primario ha sido respaldado (backup).
Cuando hay problemas para acceder a un log file primario, el archivo es marcado como
defectuoso, y la base de datos debe llevarse a un estado operacional OFFLINE. Para
restaurar el log file defectuoso, es necesario reemplazarlo completamente con el
contenido del log file secundario.
El mecanismo de log no debe ser desactivado nunca en un sistema productivo; de
otra manera el estado de las modificaciones a los datos podría perderse ante una
falla. Esto significa que habría un riesgo alto de pérdida de datos ante una
destrucción del disco duro de los archivos de datos de la base.
Un sistema de base de datos siempre incluye datos estructurados que contiene
información esencial de la base de datos, tal como el número de data files.

Lección 5: Backup y Recuperación de la base de datos
Esta lección muestra los conceptos sobre el respaldo de la base de datos. Estos
conceptos incluyen un backup regular de datos y de la información de log. Estos
backups son realizados mediante el calendario de planificación de base de datos,
transacción DB13.
Para proteger el sistema SAP contra la pérdida de información si un error ocurre, el
administrador regularmente realiza los backups.
Concepto de Backup
El concepto de backup para la base de datos siempre incluye un backup regular de los
data files, la información de log y los datos estructurados de información de la base de
datos misma.
El backup de los data files y la información de log se realiza en pasos diferentes. Todos
los data files y los datos estructurados son respaldados en un solo paso. En otro paso,
la información de log se respalda de forma separada.

Figura 56 – Backup de Data Files e información de Log

Se pueden planificar ambos pasos en un sistema SAP (excepto en una plataforma
AS400) como acciones regulares utilizando el calendario de planificación de base de
datos, transacción DB13.

Escenarios para la Recuperación de una Base de Datos
Si es necesario realizar una recuperación de la base de datos, el momento al cual
podremos recrearla de manera consistente dependerá no solamente de la
disponibilidad del backup de data files con el que contemos, sino también de la
disponibilidad de los backups de información de log con la que contemos.
Si un backup de data files se pierde o está corrupto, una recuperación puede basarse
en el último backup válido de data files y luego recuperarla a un punto más reciente en
el tiempo, si los respaldos de información de log están disponibles sin ningún faltante.
Esto significa que tenemos que contar con todos los backups de información de log
que se realizaron a partir del backup de data files que utilizamos para la recuperación
hasta el punto en el tiempo que necesitemos recrear la base de datos.
Recuperar la base de datos (con pérdida de datos)
Observando la figura 462, si un accidente del disco duro ocurre en un punto entre t1 y
t2, todos los datos respaldados en el backup de data files t1 son recreados con la
recuperación. Si ninguna acción se realiza luego de esto, todos los cambios a la
información (creación, modificación o borrado) que fueron realizados después del
punto t1 se perderán.

Figura 57 – Recuperación con pérdida de datos

Recuperar la base de datos (sin pérdida de datos)
Todos los datos del backup de data files t1 son recuperados. Algunas bases de datos
permiten recuperar solamente los data files que faltan o inclusive objetos específicos
de la base de datos como por ejemplo una tabla determinada.
Luego, toda la información de log consecutiva respaldada desde el punto t1 (22,23,…)
son tomados para la recreación de la base de datos. En el último paso, el archivo de
información de log que tenía la base de datos hasta el punto del accidente es
recuperado. Esto significa que toda la información ahora está en el mismo estado
hasta el punto en el que ocurrió la falla del disco duro.
Solamente si toda la información de log desde el último backup de data files está
disponible, sin faltantes, la recuperación de la base de datos será sin pérdida de datos.

Figura 58 – Recuperación sin Pérdida de Datos

Almacenando los backups de data files e información de log
La información de log respaldada en los backups es borrada a nivel del sistema
operativo para evitar problemas de espacio en disco. Si un accidente de disco ocurre
en el punto t5 de la figura 463, y un medio de backup del backup de data files t3 se
encuentra defectuoso, un backup anterior en el tiempo (en este caso, t1) debe ser
utilizado.
Para recuperar la base de datos sin pérdida de información, es absolutamente
necesario contar con todos los backups de información de log (en este caso t2 y t4)
que se generaron luego del backup de data files en el punto t1. Por esto es necesario
mantener siempre backups de data files e información de log más antiguos del último
backup de data files.
Otras consideraciones: Algunas base de datos también requieren de la información de
log para poder realizar una recreación de la base de datos. Por lo tanto deberíamos
asegurarnos que se realicen backups tanto de data files y la información de log
regularmente.
Ciclo de Backup
Hay diferentes variantes para un completo backup de data files diario, dependiendo de
la base de datos. Al menos un backup online debería realizarse de la base de datos,
con un subsecuente backup completo de información de log.
Los medios de backup utilizados pueden ser sobrescritos nuevamente cada 28 días.
Esto es una recomendación. Los backups podrían ser retenidos por mucho más tiempo
en una compañía.
SAP recomienda que la duración de un ciclo de backup sea de 28 días. Esto significa
que los backups de data files e información de log son sobrescritos después de 28 días,
al menos.

Figura 59 – Ciclo de Backup Recomendado

En un sistema productivo SAP recomienda realizar un completo backup de datos
diariamente. Algunas bases de datos ofrecen la opción de realizar backups
diferenciales o incrementales de data files, lo que no realiza un completo backup de la
base de datos (estos backups serán referidos como backups parciales de ahora en
más).

Si se utiliza un backup parcial de datos como estrategia diaria de backup, se debería
realizar un backup completo al menos una vez por semana. Debería haber al menos
cuatro backups completos de la base de datos contenidos en un ciclo de backup.
La información de log debería respaldarse al menos una vez por día. También es
recomendable duplicar los medios de backup para la información de log para asegurar
que contamos con todos los backups de log en caso de que alguno se encuentre
defectuoso.
En muchas compañías generalmente se realizan backups de la información de log más
de una vez por día con frecuencias de hasta 30 minutos. Esto dependerá muchas veces
de la cantidad de información que se modifique en la base de datos durante el día lo
que impacta directamente en un crecimiento de la información de log.
Por último es recomendable realizar un backup de data file e información de log con
verificación al menos una vez en el ciclo. Esto asegura que el backup es legible en el
dispositivo de backup, pero incrementa el tiempo total del respaldo de la información.

Planificación y Monitoreo de Backups
En el sistema SAP, puedes planificar y monitorear backups regulares con la transacción
DB13.

Figura 60 – Transacción DB13

Figura 61 – Planificación de Backup

Si por ejemplo utilizamos un medio externo como un dispositivo de cinta, deberemos
verificar que medio se requiere para el próximo backup cada día e insertar el medio
(cinta) correspondiente antes de iniciar el backup.
Verifica diariamente si los backups se han completado satisfactoriamente. En el
calendario de planificación, un backup exitoso se muestra en verde o amarillo (cuando
hay alguna advertencia). Si el indicador es de color rojo, entonces un error sucedió
durante la ejecución del backup, por lo tanto es inutilizable.

Figura 62 – Código de colores de estado de tareas.

Información adicional se puede ver en la transacción DB12, la cual nos permite
visualizar los registros de sucesos de las actividades realizadas en la base de datos.

Figura 63 – Transacción DB12 ½

Esta transacción además del listado de registros, nos permite visualizar las áreas de
datos y log utilizadas por la base de datos.

Figura 64– Transacción DB12 2/2

A partir de la versión SAP Web Application Server 6.10, es posible controlar y
monitorear los backups para todos los sistemas del landscape con el calendario de
planificación central, transacción DB13C. La planificación se transfiere a los sistemas
remotos utilizando una conexión de tipo RFC.
DB13 fue mejorada para la versión SAP Netweaver 7.00, lo que permite utilizar la
misma para planificar acciones en otras bases de datos. Para poder realizar esto,
primero es necesario crear las conexiones a estos sistemas en DB13.
El botón de documentación
sobre las tareas que son
recomendaciones.

posibles

, nos puede dar mayor información
realizar desde la transacción DB13 y

Lección 6: Monitoreo de base de datos
Dependiendo de la base de datos que se utilice para el sistema SAP, existe una
cantidad de verificaciones periódicas que deben llevarse a cabo adicionalmente a la
realización de los backups.
Para asegurarnos una óptima performance de la base de datos y por lo tanto, una
buena performance del sistema SAP, el administrador debe realizar verificaciones
adicionales a la base de datos, las cuales pueden ser planificadas regularmente.

Monitoreo Regular de la Base de Datos
Además de los chequeos de la ejecución de los respaldos de la base de datos, existe
una serie de verificaciones que podremos realizar mediante la transacción DB13
también.

Figura 65– Monitoreo de Base de Datos

Estas verificaciones, incluyen entre otras:
Generación de estadísticas para asegurar una buena performance cuando se accede
a los registros.
Crecimiento de la base de datos y espacio disponible
Chequeo de errores o problemas generales de la base de datos
La generación periódica de estadísticas es un importante prerrequisito para un acceso
eficiente a los registros. Cuando una sentencia SQL es ejecutada, la base de datos
tiene que optar por una de las posibles alternativas para acceder a los datos
requeridos.
En la sentencia SQL, la condición WHERE especifica el número de registros que se
obtendrán para la consulta. La base de datos debe encargarse ahora de obtener la
información tan rápido como pueda, en otras palabras, en la menor cantidad de
accesos posibles.
La base puede leer el contenido completo de una tabla, lo que se denomina Full Table
Scan o acceder a una tabla a través de un índice (index scan). Utilizando las
estadísticas, el Optimizador Basado en Costo (Cost Based Optimizer) de la base de
datos calcula el acceso de lectura respectivo para todas las posibles alternativas y elige
el mejor (el más económico) camino de acceso.

Figura 66 – Determinando el Mejor Camino de Acceso

Actualización de Estadísticas
Las estadísticas contienen información sobre el número de entradas en la tabla, el
número de bloques que son ocupados por la tabla y el índice de la tabla y la
selectividad de los registros según los valores de los campos.
La duración recomendada para la generación de las estadísticas puede variar
dependiendo de la base de datos que utilicemos o de la versión. En principio, la
actualización de estadísticas solo tienen que ser generadas cuando una tabla ha
crecido o reducido notablemente su tamaño. Esto es porque la generación de
estadísticas en el entorno SAP se ejecuta en dos pasos:

En el primer paso, un chequeo es realizado para determinar si es necesaria la
generación de estadísticas para la tabla. Para hacer esto, el número actual de registros
de datos se compara con el número de registros de datos que existían la última vez
que se ejecutaron las estadísticas.
En el segundo paso, las estadísticas son generadas para todas las tablas para las
cuales su tamaño ha cambiado de manera considerable.
Dependiendo de la base de datos que se use, ambos pasos son planificados en la
transacción DB13 en un único job o en jobs separados.
La generación de estadísticas es sumamente importante para el acceso eficiente a los
datos y debería ser verificado regularmente por el administrador.

Monitor CCMS
Otra tarea importante del administrador además de asegurar el acceso eficiente a la
base de datos es verificar el crecimiento de la base de datos, en particular el espacio
libre disponible para la base. Esto se puede realizar utilizando las herramientas propias
de la base de datos o desde el mismo sistema SAP.
La Figura 67, muestra una sección del monitor de base de datos que puede ser
utilizado para monitorear que tan llena está la base de datos. Como muestra la Figura
67, se puede monitorear no solamente el fill level (nivel de llenado) de la base, sino
también la performance y las actividades planificadas tales como el backup y la
generación de estadísticas.

Figura 67 – Monitor CCMS: Base de Datos.

La transacción DB02 nos permite realizar un análisis del estado de la base de datos,
donde podemos verificar entre otras cosas el tamaño total de la base de datos y el
espacio ocupado realmente o estadísticas de las tablas e información sobre tablas o de
índices perdidos así también como el nivel de llenado histórico.

Figura 68– Análisis de Base de Datos (DB02)

DBACOCKPIT
La transacción DBACOCKPIT concentra todas las operaciones y funciones de monitoreo
para la base de datos. En vez de tener que llamar a cada una de las transacciones que
vimos anteriormente podemos acceder directamente a la transacción DBACOCKPIT y
desde allí realizar todas las tareas necesarias para la administración de la base de
datos.

Figura 69 – Transacción DBACOCKPIT

Usuarios, Roles y Autorizaciones
Lección 1: Concepto de Administración de usuarios ABAP
Los usuarios de los sistemas SAP requieren contar con las autorizaciones apropiadas
para ingresar al sistema. El administrador crea y configura un ID de Usuario en el
sistema para cada usuario.

Bases de Administración de Usuarios
El concepto de registro maestro de usuario y el concepto de autorización serán
explicados con mayor detalle abajo. Ambos conceptos son muy importantes para
comprender mejor los sistemas SAP.

Figura 70- Usuarios en el ambiente SAP

El término usuario generalmente se utiliza para hacer referencia a una identificación de
usuario (ID de usuario). La gente se loguea a un sistema operativo, una base de datos
o a un sistema SAP utilizando un usuario y contraseña válidos.
Los sistemas operativos, las bases de datos y el sistema SAP usualmente tienen
diferente conceptos de autorización. Si una combinación de usuario y contraseña es
creada en un sistema SAP para una persona, esto no significa que es posible para esa
persona loguearse en el sistema operativo del servidor con el mismo usuario y
contraseña. De todas formas, es posible que una combinación idéntica de usuario y
contraseña se creen para loguearse al sistema operativo y al sistema SAP.
Las solicitudes de los usuarios son procesadas por los work processes de SAP.
Estos work processes utilizan un mismo usuario para acceder a la base de datos.
Los datos de usuarios y autorizaciones son dependientes del cliente.
El acceso a nivel del sistema operativo de un servidor de aplicación SAP y del servidor
de la base de datos deben ser protegidos o la operación y los datos del sistema SAP
pueden ponerse en riesgo.
Autorizaciones

Figura 71– Usuarios y Autorizaciones

La protección de autorizaciones se realiza en dos niveles:
1- ¿Puede una transacción ser accedida?
2- Autorizaciones para realizar acciones y tratamiento de datos durante el
uso propio de la transacción.
Una persona puede loguearse a un cliente de un sistema SAP si conoce la combinación
de usuario y contraseña. Si el usuario luego intenta iniciar una transacción para la cual
no tiene autorización, el sistema rechaza al usuario con un mensaje de error
apropiado.
Si el usuario inicia una transacción para la cual tiene autorización, el sistema muestra
la pantalla inicial de la transacción. Dependiendo de la transacción que haya ejecutado,
el usuario ingresa datos y realiza acciones en la pantalla. Verificaciones adicionales de
autorización se llevan a cabo para los datos y acciones que se realizan para proteger
los mismos.
A los usuarios se les asignan autorizaciones mediante roles. Las autorizaciones son
combinadas en roles y los roles luego se ingresan en el registro maestro de usuario.
Esto se explica con mayor detalle en las próximas lecciones.

Figura 72 – Registro Maestro de Usuario.

Tipos de Usuarios
El tipo de usuario es una propiedad importante de un usuario. Diferentes tipos de
usuario existen para diferentes propósitos:
Diálogo
Un usuario normal de Diálogo se utiliza para todas las formas posibles de logón por
una persona. Durante un logón de diálogo, el sistema verifica si la contraseña es inicial
o expiró entonces el usuario tiene la oportunidad de cambiar su contraseña.
También el sistema verifica si múltiple sesiones son creadas con el mismo usuario y si
permite que el usuario decida qué hacer en los casos que sea posible utilizar múltiples
sesiones.

Sistema
El tipo de usuario Sistema se utiliza en comunicaciones dentro de un sistema o para
procesamiento de fondo. Este tipo de usuario no puede utilizarse para acceder
mediante el programa SAP GUI o ningún otro método que pueda utilizar una persona,
podemos decir que no es interactivo.
También se puden usar los usuarios de tipo Sistema para aplicaciones que requieren
de comunicaciones RFC tales como ALE, Workflow, Transport Management System,
Central User Administration. Los usuarios de este tipo quedan exentos del parámetro
de sistema del período de validez de contraseña. Solo los administradores pueden
cambiar la contraseña.
Comunicaciones
Utiliza el usuario de tipo Comunicaciones para el logón de usuarios no-interactivos
entre sistemas. No es posible utilizar estos usuarios para un logón de diálogo. La
configuración usual del período de validez de contraseña aplica para estos usuarios
también.
Servicio
Un usuario de tipo Servicio es un usuario de diálogo que está disponible para un gran
número de usuarios anónimos. En general, estos tipos de usuarios están muy
restringidos en cuanto a autorizaciones.
Los usuarios de Servicio son usados, por ejemplo, para accesos anónimos al sistema
utilizando ITS o servicios ICF. El sistema no verifica por la validez de la contraseña
durante el logón de este tipo de usuarios, por lo que están exentos.
Solamente el administrador de usuarios puede cambiar la contraseña. Múltiples
sesiones se permiten para estos usuarios.
Referencia
Como el tipo de usuario de Servicio, un usuario de Referencia no está vinculado a una
persona. No es posible utilizar este tipo de usuario para loguearse al sistema. Un
usuario de Referencia es utilizado solamente para asignar autorizaciones adicionales en
la solapa de Roles del registro de usuario.

Figura 73 – Tipos de Usuarios

Transacción de Administración de Usuarios SU01.
Para iniciar el mantenimiento de usuarios, transacción SU01, selecciona desde el menú
Tools → Administration → User Maintenance → Users.
Es posible crear un nuevo registro maestro de usuario copiando un registro de usuario
existente o creando completamente uno nuevo.
El registro maestro de usuario contiene toda la información y configuraciones que se
requieren para poder loguearse a un cliente del sistema SAP. Estos datos están
divididos en las siguientes solapas de la transacción SU01:
Address: información personal y de contacto.
Logon data: período de validez de la contraseña y del usuario. Tipo de usuario.
Defaults: valores por defecto para una impresora, lenguaje de logón, etc.
Parameters: Valores específicos de usuario para campos estándar en el sistema SAP.
Roles and Profiles: Roles y perfiles que son asignados al usuario.
Groups: Asignación de grupos para el usuario, utilizado para el mantenimiento masivo
de usuarios.
El requisito mínimo para la creación de usuarios es ingresar al menos el apellido (Last
Name) en la solapa Address, y la contraseña inicial en la solapa Logon Data.

Lección 2: Concepto de Autorización.
Las autorizaciones de los usuarios son creadas usando roles y perfiles. Los
administradores crean los roles y el sistema provee el soporte para la creación de las
autorizaciones asociadas.

Objetos de Autorización y Chequeo de Autorización
Comprender el concepto de autorización de SAP requiere el conocimiento del rol y
perfil de autorización en el registro maestro de un usuario. Esta lección provee el
conocimiento necesario para poder crear los roles y autorizaciones propios.

Figura 74 – Objetos de Autorización

Las acciones y los accesos a los datos están protegidos a través de los objetos de
autorización en el sistema SAP. Los objetos de autorización se encuentran en el
sistema SAP.
Para facilitar un poco la organización, los objetos de autorización están divididos en
diferentes clases.
Los objetos de autorización permiten verificaciones complejas que involucran múltiples
condiciones que permiten a un usuario realizar una acción. Las condiciones son
especificadas en los campos de autorización para el objeto de autorización y son
evaluados estos campos mediante la condición lógica AND para la verificación. O sea,
se deben cumplir todas las condiciones para que la verificación de autorización sea
exitosa.
Los objetos de autorización y los campos que contienen tienen nombres técnicos y
descriptivos.
En el ejemplo de la figura 74, el objeto de autorización User Master Maintenance: User
Groups (nombre técnico: S_USER_GRP) contiene dos campos de autorización:
Actividad (nombre técnico: ACTVT) y User Group in User Master Record (nombre
técnico: CLASS).
El objeto de autorización S_USER_GRP protege el registro maestro de usuario
justamente. Un objeto de autorización puede incluir hasta diez campos de autorización.
Una autorización siempre se asocia con solo un objeto de autorización y está formada
por el valor para los campos del objeto de autorización. Una autorización es un
permiso para realizar cierta acción en el sistema SAP. La acción es definida sobre la
base de los valores para cada uno de los campos de un objeto de autorización.
Por ejemplo, la autorización B en la figura para el objeto de autorización S_USER_GRP
permite mostrar todos los registros de usuarios que NO están asignados al grupo
SUPER. La autorización A, en cambio, permite mostrar registros de usuarios
pertenecientes a ese grupo.
Es posible que existan múltiples autorizaciones para un objeto de autorización. Algunas
autorizaciones ya están incluidas en el sistema por SAP, pero la mayor parte son
creadas específicamente por requerimientos de los clientes.

Figura 75 – Verificación de Autorización

Cuando un usuario se loguea a un cliente de un sistema SAP, sus autorizaciones son
cargadas en el contexto de usuario. El contexto de usuario se encuentra en el buffer
(en la memoria principal, puedes consultarla mediante la transacción SU56) del
servidor de aplicación.
Cuando el usuario llama a la transacción, el sistema
autorización necesaria en el contexto de usuario para
verificaciones de autorización utilizan las autorizaciones
usuario. Si se asignan nuevas autorizaciones al usuario,
usuario volverse a loguear al sistema SAP para
autorizaciones.

verifica si el usuario tiene la
acceder a la transacción. Las
que existen en el contexto de
podría ser necesario para este
poder utilizar estas nuevas

Si la verificación de autorización para llamar a la transacción es exitosa, el sistema
luego muestra la pantalla inicial de la transacción. Dependiendo de la transacción, el
usuario puede crear datos o seleccionar acciones. Cuando el usuario realiza la acción,
los datos son enviados al dispatcher, el cual los pasa a un work process para que
ejecute el procesamiento.
Verificaciones de autorización (AUTHORITY-CHECK) que son realizadas durante la
ejecución en el work process son programadas dentro del código por los
desarrolladores ABAP para proteger los datos y las acciones que van a realizarse.
Si el contexto de usuario contiene todas las autorizaciones requeridas para la
verificación (código de retorno = 0), los datos y las acciones son procesadas y la
próxima pantalla es devuelta al usuario. Si falta alguna de las autorizaciones
requeridas, el procesamiento no se realiza y el usuario recibe un mensaje que indica
que las autorizaciones son insuficientes.
Esto se controla mediante la evaluación del código de retorno. En este caso, no sería
igual a 0.
Todas las autorizaciones son permisos. No hay autorizaciones para prohibir.
Todo aquello que no está explícitamente permitido está prohibido. Esto es lo
que se conoce como concepto de autorización positivo.
Mantenimiento de Roles: Menú y Autorizaciones

Figura 76 – Mantenimiento de Roles

El Mantenimiento de Roles (transacción PFCG, previamente también llamada Profile
Generator o Activades de Grupo) simplifica la creación de autorizaciones y sus
respectivas asignaciones a los usuarios.
En el mantenimiento de roles, las transacciones, que desde el punto de vista de la
compañía, pertenecen a un mismo grupo se seleccionan. El mantenimiento de roles
crea las autorizaciones con los valores de campos requeridos para los objetos de
autorización que son verificados en la transacción elegida.
Un rol puede ser asignado a varios usuarios. Los cambios a un rol por lo tanto tienen
efecto sobre todos estos usuarios. Los usuarios pueden ser asignados a más de un rol.
El menú de usuario se compone del menú de rol y contiene las entradas
(transacciones, URLs, reportes, etc) que son asignadas al usuario a través de los roles.

Figura 77 – Menú de usuario

Puedes acceder al mantenimiento de roles con la transacción PFCG o mediante el
menú de la pantalla inicial del sistema en Tools → Administration → User Maintenance
→ Role Administration → Roles. Ingresa el nombre del rol y presiona el botón Create o
Change. Selecciona la solapa Menu.
Selecciona y modifica las funciones: En el árbol de menú se pueden realizar ajustes
para los roles individuales. Se pueden insertar o borrar transacciones en el árbol de
transacciones.
Si se selecciona el botón Report, puedes integrar reportes (programas ABAP). En este
caso la transacción PFCG se encarga de crear los códigos de transacción (si es que no
existen para el reporte) con el cual los reportes luego pueden ser accedidos.
Si seleccionamos el botón Other, es posible agregar direcciones de internet o vínculos
a archivos.
Modificación de Menús: podemos crear, mover, borrar y renombrar directorios y subdirectorios si es necesario. La función Drag&Drop se puede utilizar también.

Figura 78 – Generando Perfiles de Autorización

El mantenimiento de roles automáticamente crea las autorizaciones que están
asociadas con las transacciones especificadas en el árbol del menú. De todas maneras,
todos los valores de autorización deben ser verificados manualmente y ajustados si
fuese necesario para que concuerden con los requerimientos y permisos que se deben
otorgar con el rol.
El administrador del sistema es responsable para esta tarea, junto con el área
apropiada para quien se están creando o modificando los roles.
Selecciona la solapa Authorizations y luego el botón Change Authorization Data o
Display Authorization Data, dependiendo en cual modo estemos trabajando en la
transacción PFCG.
En la pantalla que ingresamos podremos ver y modificar el contenido de las
autorizaciones, o sea los valores propuestos para los campos de los objetos de
autorización.
El significado de los indicadores es el siguiente:
Luz verde: el objeto de autorización tiene un valor propuesto para cada uno de los
campos.
Luz amarilla: el objeto de autorización necesita mantenimiento manual al menos
para uno de los campos.
Luz roja: Los niveles organizacionales no están definidos.

Figura 78_b – Significado de los indicadores

La falta de un valor propuesto por PFCG para alguno de los campos del objeto de
autorización puede ser por ejemplo en los casos de accesos a archivos externos
donde no se puede determinar si el acceso será de lectura o de lectura/escritura.
Algunos campos aparecen en muchas autorizaciones por lo que estos campos se
denominan Niveles Organizacionales. Si editamos una entrada en el nivel
organizacional utilizando el botón
todos los objetos de autorización que lo contienen.

entonces los cambios afectarán a

¿Qué son los Niveles Organizacionales? Son campos determinados por SAP en el
Concepto de Autorización que se refieren a la estructura de la compañía. Estos
campos aparecen en la mayoría de las autorizaciones. Por lo tanto dentro de un rol
estos campos pueden aparecer muchas veces. El botón Organizational levels… en la
transacción PFCG facilita su mantenimiento.

Una vez que todas las autorizaciones han sido mantenidas como se requiere, el perfil
de autorización puede ser generado mediante el botón Generate
. Las
autorizaciones se combinan en un perfil. Los perfiles deben ingresarse en los registros
maestros de usuarios, esto se denomina Comparación de Registros Maestros de
Usuarios (User Master Record Comparission)
Usuarios y Roles
La asignación de usuarios a roles se realiza mediante la transacción PFCG
(mantenimiento de roles) o en la transacción de mantenimiento de usuario SU01.
Selecciona la solapa User y los ID de usuarios a los que se les asignará el rol.

Figura 79 – Asignación de Roles a Usuarios

Los usuarios pueden recibir más de un rol, esto es útil para algunas actividades (como
impresión) que serán permitidas para la mayoría de los usuarios.
La asignación de roles a los usuarios no otorga automáticamente las correspondientes
autorizaciones a los usuarios. Para asignar las autorizaciones, es necesario realizar una
comparación de registros de usuarios mediante la cual los perfiles de los roles son
insertados en el registro maestro de usuario.

Figura 80 – Comparación de Registro Maestro de Usuario

Una comparación de registros maestros de usuarios determina si los perfiles de
autorización deben ser agregados o eliminados del usuario basándose en la asignación
de roles para este.
Durante una comparación se agregarán perfiles al maestro de usuario si nuevos roles
son agregados.
Si la asignación de roles es removida manualmente o porque se cumple la fecha de
vencimiento del rol para el usuario los perfiles correspondientes son eliminados del
registro maestro de usuario.
La comparación puede realizarse por cada rol individualmente. Seleccionando el rol en
la función de mantenimiento de roles en la solapa User y luego seleccionando User
comparison. En la ventana que aparece, seleccionamos Complete comparison.

Para más información, selecciona el botón de información
en la transacción PFCG y
el
mismo
botón
en
la
comparación
de
maestros
de
usuarios.
Durante una comparación completa, los perfiles obsoletos son eliminados.
Si múltiples asignaciones de roles va a ser actualizada, puedes realizar una
comparación en la transacción PFCG seleccionando Utilities → Mass comparison o
llamando a la transacción PFUD. Puedes seleccionar los roles que desees o actualizar
todas
las
asignaciones
si
ingresas
el
caracter
asterisco
(*).
También puedes activar una comparación de registros maestros de usuarios
periódicamente si seleccionas Utilities → Mass comparison. Selecciona la opción
Schedule o Check job for full reconciliation. El sistema luego muestra una ventana de
búsqueda para el job de background PFCG_TIME_DEPENDENCY. Si no encuentra el
job, tenemos la opción de crear uno. El valor por defecto es que todos los registros
maestros de usuarios serán comparados una vez por día.

Lección 3: Asignación de Roles y perfiles

Lección 4: Parámetros de Login e información de usuario.
En esta lección veremos una serie de parámetros importantes para la administración
de usuarios, por ejemplo, el comportamiento de logon.
Parámetros del Sistema para Logon de Usuarios

Figura 81 – Parámetros del Sistema para Logon de Usuarios 1/2

Podemos especificar la longitud mínima de la contraseña con el parámetro
login/min_password_lng.
El parámetro login/min_password_digits, login/min_password_letters,
login/min_password_lowercase, login/min_password_uppercase, y
login/min_password_specials especifican el número de dígitos, letras (mayúsculas y
minúsculas) o caracteres especiales que una contraseña puede contener. El rango de
valores es entre 1 y 40.
El parámetro login/password_expiration_time especifica el número de días en los
cuales un usuario debe cambiar su contraseña. Si el parámetro se configura en 0, el
usuario no necesita cambiar su contraseña.
Existen algunas reglas generales sobre las contraseñas que no pueden desactivarse.
Una contraseña:
Debe ser al menos de 6 caracteres de largo.
No puede comenzar con ? o !
No puede ser pass
La nueva contraseña debe diferir de la anterior al menos en 1 carácter.
La configuración que determina que los usuarios deben crear una nueva contraseña
que difiera de las 5 últimas no es más mandataria. Se puede utilizar el parámetro
login/password_history_size para configurar el historial entre 1 y 100. El valor
propuesto por defecto se mantiene en 5.

Se pueden definir restricciones adicionales en la tabla USR40.
SAP Web Application Server 6.20 y 6.40 ofrecían los parámetros
login/password_max_new_valid y login/password_max_reset_valid. Estos parámetros
especificaban por cuanto tiempo una contraseña inicial para un usuario creado o una
contraseña recreada por el administrador del sistema para un usuario era válida. Con
SAP Netweaver AS 7.0, estos parámetros han sido reemplazados por
login/password_max_idle_initial.
El parámetro login/password_max_idle_initial indica por cuánto tiempo una
contraseña nueva (seleccionada por un administrador) permanece válida si no es
utilizada. Una vez que el período se cumple, la contraseña no puede ser utilizada
para la autenticación en el sistema.
El administrador de usuarios puede reactivar la contraseña asignando nuevamente una
contraseña inicial.
Otro nuevo parámetro introducido luego de la versión SAP Web AS 6.40 es
login/password_max_idle_productive. Este indica el máximo tiempo que una
contraseña productiva (contraseña seleccionada por el usuario) permanece válida
cuando esta no es usada.
Una vez que este período ha caducado, la contraseña no puede ser utilizada para
autenticación. El administrador de usuarios puede reactivar la contraseña mediante la
asignación de una nueva contraseña inicial.
Con el parámetro login/min_password_diff, el administrador puede determinar el
número de caracteres diferentes que una contraseña nueva debe poseer en
comparación con la contraseña anterior. Este parámetro no tiene efecto cuando la
contraseña del usuario es creada o reactivada.

Figura 82 – Parámetros del Sistema para Logon de Usuarios 2/2

Figura 83 – RZ11: Parámetros de Logon

Puedes configurar el número de intentos fallidos de logon después de los cuales SAP
GUI se cierra usando el parámetro login/fails_to_session_end. Si el usuario quiere
intentar de nuevo, deberá reiniciar SAP GUI.
Puedes también configurar el número de intentos fallidos de logon después de los
cuales el usuario se bloquea en el sistema SAP usando el parámetro
login/fails_to_user_lock. El contador de intentos fallidos se reinicia después de un
intento exitoso de logon.
A la medianoche de la hora del servidor, los usuarios que se bloquearon como
resultado de intentos incorrectos de logon no son desbloqueados
automáticamente por el sistema, valor por defecto desde la versión SAP Netweaver
7.0. Se puede reactivar este desbloqueo automático con el parámetro
login/failed_user_auto_unlock = 1.
El administrador puede desbloquear, bloquear o asignar una nueva contraseña a los
usuarios en la transacción SU01, mantenimiento de usuarios.
Si el parámetro login/disable_multi_gui_login se configura con el valor 1, un usuario no
puede ingresar a un cliente más de una vez, o sea con más de una sesión. Esto puede
ser útil por razones de seguridad del sistema. Si el parámetro está configurado en 1, el
usuario tendrá las siguientes opciones cuando abre más de una sesión:
Continuar con este logon y finalizar cualquier otro logon en el sistema.
Terminar este logon.
Tenemos la opción de excluir de este parámetro a los usuarios que especifiquemos en
el parámetro login/multi_login_users separados por comas y sin espacios.

Usuarios estándar

Figura 84 – Usuarios estándar

Esencialmente, hay dos tipos de usuarios estándar: aquellos creados por la instalación
del sistema SAP y aquellos creados durante la copia de un cliente.
Durante la instalación del sistema SAP, el cliente 000 y 066 son creados (el cliente 001
no siempre es creado durante la instalación. Es creado por ejemplo durante la
instalación de un sistema ERP 6.0).
Usuarios estándar son predefinidos en los clientes. Como estos nombres de usuarios y
sus contraseñas son estándar, pueden ser conocidos por otras personas por lo tanto es
aconsejable que como administradores del sistema protejamos estos usuarios de
accesos no autorizados.
El usuario estándar del sistema SAP*
SAP* es el único usuario para el cual no se requiere un registro maestro de usuario (no
existe una entrada en las tablas de usuarios) ya que está definido en el kernel del
sistema. SAP* tiene por defecto la contraseña pass y autorización de acceso irrestricto
para el sistema.
Cuando instalamos un sistema SAP, un registro maestro de usuario se crea
automáticamente para SAP* en el cliente 000 (y 001 si existe). Durante el proceso de
instalación
se
nos
solicitará
indicar
una
contraseña.
La instalación solo nos permitirá continuar una vez que una contraseña se ha
ingresado para el usuario SAP*.
El registro maestro de usuario creado para el usuario SAP* desactiva las propiedades
especiales de SAP*, por lo que solo las autorizaciones y contraseñas definidas en el
registro maestro del usuario aplican ahora.

El usuario DDIC
Este usuario es responsable de mantener el Diccionario ABAP (ABAP Dictionary) y la
logística de software.
Cuando instalamos el sistema, un registro maestro de usuario
automáticamente en el cliente 000 (y 001 si aplica) para el usuario DDIC.

se

crea

Con este usuario también, se nos requerirá cambiar la contraseña estándar durante la
instalación. Ciertas autorizaciones son predefinidas en el código del sistema para el
usuario DDIC, lo que significa que por ejemplo, solo el usuario DDIC puede realizar un
logon al sistema durante la instalación de una nueva versión (upgrade).
En versiones anteriores las contraseñas que tenían por defecto los usuarios SAP*
y DDIC eran 06071992 y 19920706 respectivamente. Luego era necesario
modificar estas contraseñas una vez instalado el sistema.

El usuario EarlyWatch
El usuario EarlyWatch se crea en el cliente 066 y está protegido con la contraseña
support. Los expertos de SAP del servicio EarlyWatch son quienes utilizan este usuario.
Este usuario no debe ser borrado ni la contraseña debe ser cambiada.
Este usuario solo debe ser utilizado para las funciones de EarlyWatch: monitoreo y
peformance. Las autorizaciones necesarias para este usuario ya son provistas durante
la creación del mismo en el proceso de instalación.
Caracteristicas especiales de SAP*
Si copias un cliente, el usuario SAP* siempre está disponible. Este usuario no tiene
un registro maestro de usuario y está programado en código del sistema (kernel).
Para proteger el sistema contra accesos no autorizados, debemos crear un registro
de usuario para este usuario estándar. Crea un usuario SAP* con autorizaciones
totales en el sistema (perfil SAP_ALL).

Si borramos el registro de usuario SAP* (tabla USR02), la contraseña inicial pass con
las propiedades vuelven a ser válidas nuevamente: el usuario tiene autorizaciones
totales ya que no se realizan verificaciones de autorización para este usuario.
La contraseña estándar no puede ser cambiada.
¿De qué manera podemos proteger el sistema contra este potencial riesgo
de acceso no autorizado?
Se puede desactivar el usuario SAP* que viene incluido en el sistema. Para esto,
debemos configurar el parámetro del sistema login/no_automatic_user_sapstar con el
valor 1. Si el parámetro está activo, o sea con el valor 1, SAP* no es válido en el
sistema. Si el registro maestro de usuario de SAP* es borrado, el logon con la
contraseña pass no funciona.

Si quisiéramos reinstalar el comportamiento anterior de SAP*, debemos cambiar el
parámetro con el valor 0 y reiniciar el sistema.
Es conveniente activar el parámetro en el perfil global del sistema DEFAULT.PFL para
que tenga efecto en todas las instancias del sistema (de todas formas si existiera el
parámetro también en un perfil de instancia con el valor 0, este sobrescribe el que está
en el perfil global).
También crear el registro maestro de usuario SAP* en todas las instancias y así
asegurar que no se podrá ingresar con el usuario pass si el parámetro es desactivado
(valor 0).

Lección 5: Concepto Administración Avanzada de Usuarios
Administración Central de Usuarios

Figura 85 – Administración Central de Usuarios

Cuando tenemos que operar múltiples sistemas SAP con una determinada cantidad de
clientes y tenemos que crear usuarios idénticos varias veces en diferentes clientes,
podemos reducir significativamente el esfuerzo de administración usando
Administración Central de Usuarios, que por las siglas en inglés se conoce como CUA
(Central User Administration). Podremos realizar la administración de forma central
desde un cliente si utilizamos CUA. Este cliente se denomina Sistema Central (Central
System). Los clientes para los cuales se realiza la administración desde el sistema
central se denominan Sistemas Hijos (Child Systems).
Puedes especificar para cada usuario en que clientes podrá ingresar. Utilizando CUA no
significa que todos los usuarios pueden ser usados en todos los clientes del landscape.
Puedes también especificar que información del registro maestro de usuario podrá ser
mantenida de forma central y que información se podrá mantener de forma local

también. Algunas veces es útil permitir que cierta información de usuarios sea
mantenida de forma local por los usuarios o por un administrador en los sistemas hijos.
La información del usuario se intercambia mediante ALE. ALE significa Application Link
Enabling y es una tecnología para configurar y operar aplicaciones SAP distribuidas.
ALE permite un proceso de intercambio controlado de mensajes de negocio entre
sistemas SAP que no tienen una conexión permanente. El procesamiento asincrónico
de la comunicación asegura que la operación sea libre de errores.

Figura 86 - ¿Qué Información Puede Ser Distribuida?

La siguiente información puede ser distribuida utilizando CUA:
Registro Maestro de Usuarios: Dirección, Datos Logon, Valores Fijos, Parámetros
(addresses,
logon
data,
user
defaults
y
user
parameters)
Los usuarios son asignados a los roles simples o compuestos y los perfiles para todos
los sistemas hijos. Utilizar CUA tiene la ventaja que como administradores no
necesitamos ingresar a cada cliente para gestionar estas asignaciones localmente.
Contraseña inicial: Cuando los usuarios son creados una contraseña inicial es
transferida a los sistemas hijos donde el usuario existirá. Esta luego será modificada de
la forma tradicional.
Bloqueo: adicionalmente a las formas normales de bloqueo (intentos fallidos de logon
o bloqueos por el administrador) hay un nuevo bloqueo general. Este tiene efecto en
todos los sistemas hijos en los que un usuario existe y puede quitarse el bloqueo de
forma local en cada cliente o de forma central desde el sistema central.
Es posible asignar un rol simple o compuesto y perfiles de autorización desde el
sistema central. De todas formas, los perfiles de autorización se mantienen localmente
más bien que de forma central ya que diferentes configuraciones de sistema y
versiones pueden requerir una administración local de los perfiles de autorización.

Comunicación y Logística de Software
Lección 1: Fundamentos de Conexiones RFC
Los sistemas SAP pueden comunicarse entre sí utilizando Llamadas de Funciones
Remotas, que por sus siglas en inglés se conocen como RFCs (Remote Function Calls).
Un prerrequisito para esto es que el administrador haya configurado el sistema de
interfaces.
Fundamentos de RFC
Las Llamadas de Funciones Remotas han sido utilizadas por muchos años como la
interfaz técnica con la que los sistemas SAP y no-SAP usualmente se conectan. No
tiene relevancia si el intercambio de información se realiza de manera sincrónica o
asincrónica, periódica o aperiódica, o transaccional.

Figura 87– La interfaz RFC

Una RFC es la llamada a un módulo de función que está corriendo en un sistema
diferente al programa que realiza la llamada. Podemos llamar a un módulo de función
en el mismo sistema mediante una RFC también. De todas maneras, las RFCs
normalmente son utilizadas cuando los módulos de funciones, el que llama y el que
recibe el llamado, se encuentran en sistemas diferentes.
En el sistema SAP, el sistema de interfaz RFC provee esta función. El sistema de
interfaz RFC permite llamadas a funciones entre dos sistemas SAP o entre un sistema
SAP y un sistema no-SAP externo.
RFC es un protocolo de interfaz de SAP basado en la intefaz de Programación Común
Para Comunicaciones, por sus siglas en inglés CPI-C (Common Programming Interface
for Communication) y permite comunicación entre programas de diferentes
hosts. Esto permite que las aplicaciones externas puedan llamar funciones ABAP y los
sistemas SAP contactar aplicaciones externas que sean compatibles mediante RFC.

RFC significa que los programadores ABAP no tienen que escribir sus propias rutinas de
comunicación. Para una llamada RFC, la interfaz RFC:
Convierte todos los parámetros al formato requerido en el sistema remoto.
Invoca a las rutinas de comunicación que se requieren para la comunicación con el
sistema remoto
Maneja los errores que pueden ocurrir durante la comunicación.
La interfaz RFC es de fácil utilización para los programadores ABAP. Los pasos de
procesamiento para el llamado a los programas externos están integrados dentro de la
sentencia CALL FUNCTION.

Figura 88 – Conexiones RFC

Para poder llamar a una función remota (en un sistema remoto), deberemos definir el
sistema remoto como un destino en el sistema desde donde realizamos la
llamada. También se requiere autorización de acceso para el sistema remoto.
Se pueden manejar estas conexiones remotas en el sistema que llama. Para hacer
esto, utilizamos la función Display and Maintain RFC Destinations, ya sea seleccionando
desde el árbol del menú del sistema la ruta Administration → Administration →
Network → RFC Destinations o directamente llamando a la transacción SM59. Los tipos
de conexión y todos los destinos existentes se muestran en una estructura de árbol en
la pantalla inicial. Para detalles sobre los tipos de conexión disponibles, podemos
observar la documentación.
Hay una función de búsqueda para los destinos que ya están configurados. Para
realizar una búsqueda, selecciona Search
y luego ingresa el nombre o parte del
nombre. El sistema mostrará una lista de las entradas que concuerden.
Para modificar una conexión RFC existente, seleccionamos el destino RFC en el menú
de árbol y seleccionamos Change
Para copiar una conexión RFC existente, primero tenemos que ingresar a la
conexión RFC que queremos copiar. Luego seleccionar Connection → Copy.

Variantes de Utilización de RFC
RFC sincrónica (sRFC)
Para comunicación entre diferentes sistemas y entre SAP Netweaver AS y SAP GUI. En
estas comunicaciones el llamado a la función remota se basa en una comunicación
sincrónica por lo que el sistema remoto debe estar disponible en el momento de la
llamada.
RFC asincrónica (aRFC)
Para comunicación entre sistemas y para procesamiento paralelo de tareas. Con este
tipo de comunicación, aunque no es realmente asincrónica ya que el sistema remoto
debe estar disponible al momento de la comunicación, el sistema origen (desde donde
se realiza la llamada a la función remota) no necesita esperar una respuesta del
sistema remoto para continuar su procesamiento y en este sentido es por el cual se
denomina asincrónica.
RFC transaccional (tRFC)
Este método si utiliza una forma de comunicación realmente asincrónica. El sistema
remoto no necesariamente debe estar disponible al momento de la llamada por el
programa en el sistema origen. Si una llamada es ejecutada y el sistema destino no
está disponible, la llamada se mantiene en una cola local del sistema origen. El
programa que ejecutó la llamada puede proceder sin esperar si el resultado de la
llamada fue exitoso o no.
RFC encolada (qRFC)
Para garantizar que se procesen en el mismo orden en el que se realizaron las
llamadas en el sistema origen, qRFC garantiza esto. Es una extensión de tRFC. Se
utiliza cuando necesitamos que el procesamiento se realice con un orden predefinido
(establecido por el orden de los llamados desde el programa en el sistema origen).
RFC es un término general para diferentes variantes de implementación. sRFC es la
llamada de módulo de funciones sincrónica. Esto significa que el cliente espera hasta
que el servidor ha completado el procesamiento de la función remota.
Dentro un sistema SAP, una RFC puede también ser ejecutada de forma asincrónica
mediante el uso de otro work process. La variante se conoce como aRFC.
También está tRFC que es la Llamada de Función Remota Transaccional, la cual es
asincrónica ya que asegura que la información puede ser enviada más de una vez al
sistema destino si problemas de comunicación en la red suceden y son reconocidos del
lado del servidor. Para esto un identificador de Transacción (TID) se asigna al llamado.
Esto es útil para prevenir que la información se procese más de una vez en el sistema
lo que podría ocasionar información errónea en la aplicación debido al procesamiento
asincrónico.
qRFC con cola de envío es una extensión de tRFC. Crea una capa entre la aplicación y
tRFC y permite enviar los parámetros de la función remota si no existen ejecuciones
anteriores pendientes en la cola. Luego de que una unidad lógica de trabajo (LUW) es

ejecutada, el coordinador de qRFC automáticamente procesa el siguiente llamado en
concordancia con la secuencia de la cola.

Lección 2: Configuración de Conexiones RFC
Transacción SM59

Lección 3: Estructura de Sistemas SAP
En esta lección veremos la estructura de datos de un sistema SAP. Téminos como
cliente, customizing (adaptación) dependiente de cliente y customizing inter-cliente
(cross-client), datos maestros y de transacciones, datos de usuario y repositorio de
objetos serán descriptos. Por último las opciones para modificar y crear objetos de
repositorio serán parte de la lección también.
El software de SAP necesita ser adaptado a los requerimientos específicos de las
compañías. ¿Cómo podemos transferir esas adaptaciones desde el sistema de
desarrollo al sistema de producción? El esfuerzo de trabajo extra debemos procurar
que sea mínimo cuando importamos Support Packages o durante un posible Upgrade
del sistema. Veremos cómo se relacionan estos en SAP.

Estructura de Datos en un Sistema SAP
Conocer la estructura de datos de un sistema SAP es igualmente importante tanto para
los usuarios, desarrolladores y administradores para entender de qué manera un
sistema SAP funciona.

Figura 89 – Estructura de Datos de un Sistema SAP

Los sistemas SAP tienen una estructura de datos específica. Adicionalmente a las
configuraciones de negocio (customizing) que son relevante únicamente para ciertos
clientes del sistema SAP, también contiene configuraciones y el repositorio de objetos
que son inter-clientes (cross-client).
El repositorio es el lugar de almacenamiento central para todos los objetos de
desarrollo de Workbench ABAP y es inter-cliente. Los objetos de repositorio se
almacenan en paquetes (packages).
Los paquetes son contenedores para objetos de desarrollo relacionados
semánticamente. Diferentes objetos de desarrollo (programas, tablas, pantallas,
módulos de función, clases, etc) pueden estar contenidos dentro de un paquete.
Los paquetes están caracterizados por ciertas propiedades:
Anidado (nesting)
Interfaces (interfaces)
Visibilidad (visibility)
Accesibilidad (accesibility)
Los paquetes son creados y mantenidos con Package Builder, la transacción SPAK.
El grabado y transporte de modificaciones de objetos está controlado por el Sistema de
Transportes y Cambios, que por sus siglas en inglés se denomina CTS (Change and
Transport System) utilizando la asignación de objetos de repositorios a paquetes.

Customizing
El término Customizing, que se podría traducir como adaptaciones, describe las
configuraciones de negocio de un sistema SAP. Las funciones provistas tantos
generales de una compañía como aquellas que pueden ser específicas para una
industria son adaptadas a los requerimientos específicos de la empresa en el proceso
de Customizing.
El Customizing comprende cosas simples y básicas como la definición de plantas y
almacenes hasta cosas más complejas como funciones de compras basadas en
planificación de producción o liquidación de nómina.
Una gran cantidad de Customizing estándar tal como definiciones de país, lenguaje,
uso horario están incluidas por SAP como parte de las instalaciones.
El sistema SAP diferencia entre Customizing dependiente de cliente y Customizing
inter-clientes.
Customizing inter-clientes contiene configuraciones que son independientes de una
unidad de negocio particular y tienen una validez general. Entre otros incluye el
calendario, configuraciones de impresión o el acceso a la ayuda.
Clientes
Los sistemas SAP están divididos entre unidades de negocio o clientes, que también
se conocen como mandantes.
Un cliente es una unidad comercial, organizacional y técnica contenida en un sistema
SAP y consiste de configuraciones de negocio (customizing dependiente de cliente),
sus propios datos maestros y transaccionales y sus propios datos de usuarios.
Los datos de un cliente se conocen como datos dependientes de cliente o específicos
de cliente.
Los tipos de datos que son dependientes de un cliente están relacionados entre sí. Por
lo tanto, cuando ingresamos información en una aplicación, el sistema verifica si la
información ingresada concuerda con la configuración específica de ese cliente
(Customizing). Si hay inconsistencias, la información ingresada en la aplicación es
rechazada. Esto nos dice que la información de una aplicación es significativa en
términos del negocio solamente en el cliente con el Customizing correspondiente.
Ejemplos de Customizing dependiente de cliente son los códigos de compañía, plantas
y almacenes.
Datos Maestros y de Transacciones son dependientes del cliente también. Son
únicamente válidos en el cliente. Esto incluye por ejemplo registros maestros de
materiales, órdenes y facturas. Los datos de usuario también son dependientes de
cliente.
Varios roles de clientes son utilizados en un sistema SAP. Un cliente de Customizing
puede ser configurado para las configuraciones que sean dependientes de cliente en el
sistema de desarrollo. En un sistema de calidad, un cliente puede crearse para

propósitos de pruebas y en un sistema de producción, un cliente para trabajo
productivo. Los roles se asignan a los clientes desde la transacción SCC4.
Repositorio de Objetos

Figura 90 – Ajustes a las Estructuras de Datos

Así como el Customizing dependiente de cliente e inter-cliente, es posible realizar
ajustes adicionales a la estructura de datos de un sistema SAP también. Se pueden
realizar cambios o mejoras en el repositorio de objetos. Los cambios o mejoras al
repositorio pueden realizarse en diferentes formas:
Extensión del repositorio a través de desarrollos del cliente (customer
developments): en el sistema SAP, es posible crear objetos de repositorio propios tales
como tablas, programas, transacciones, etc. Todos los desarrollos del cliente son
usualmente realizados en el espacio de nombres del cliente y deben comenzar con la
letra Y o Z, entre otras cosas. Es posible, de todas formas, también requerir un nombre
de espacio propio a SAP que empiece y termine con el caracter /. Este tendrá un
máximo de ocho caracteres inlcuyendo /, tal como /Firma/.
Todos los objetos que se creen bajo el nombre del espacio tendrán un nombre que
empezará con /Firma/, tal como /Firma/Evaluacion1.
Mejoras de cliente (customer enhancement): el repositorio es suplementado por
sub-objetos del cliente aquí. Por ejemplo, un programa estándar de SAP puede ser
suplementado con código propio del cliente en puntos predefinidos en el código
conocidos como customer exits (salidas de cliente). Las estructuras de tablas pueden
ser ampliadas con campos propios utilizando appends (agregados)
Modificaciones al estándar del sistema SAP: cambios a objetos estándar de SAP
(programas, tablas, estructuras) se conocen como modificaciones. El repositorio de
objetos que vienen junto con el sistema SAP en este caso no es extendido sino
directamente modificado.

Varios tipos de modificaciones son posibles, dependiendo del tipo de objeto:
Modificaciones manuales
Modificaciones con el asistente de modificaciones
Modificaciones con el asistente de notas
Landscape de Tres Sistemas
SAP recomienda un landscape de sistemas múltiples basado en la conformación de la
estructura de datos de un sistema SAP, en la que existe solo un repositorio de objetos
por sistema. Nunca se debe desarrollar en un sistema SAP que se utiliza también como
productivo. En circunstancias normales, un landscape de tres sistemas es suficiente
para la operación.

Figura 91 – Landscape de tres sistemas

Como el repositorio de objetos es inter-cliente, SAP recomienda que no se desarrolle
en un sistema que al mismo tiempo se utiliza para trabajar en forma productiva, ya
que esto conlleva un riesgo de una posible inconsistencia de datos. Si se van a realizar
cambios al repositorio, SAP recomienda que se utilice al menos dos, pero idealmente
tres sistemas separados. Un sistema para desarrollos, un segundo sistema para
pruebas y aseguramiento de la calidad y un tercer sistema productivo.
Un landscape de tres sistemas facilita el siguiente proceso recomendado:
Se realizan desarrollos propios de cliente en el repositorio de objetos y las
configuraciones (Customizing) requeridas en el sistema de desarrollo. Las
configuraciones de Customizing realizadas, así también como todos los cambios
(desarrollos, mejoras y modificaciones) al repositorio se registran en el sistema de
desarrollo.
Estos cambios son luego transportados al sistema de calidad y se verifican allí, sin
influenciar la operación de producción. Una prueba de aceptación usualmente no es
posible realizarse en el sistema de desarrollo, ya que los datos reales no están
disponibles
en
este
sistema
para
una
prueba
real.
La razón principal, de todas formas, es que el sistema de desarrollo no ofrece un

ambiente estable para una prueba comprensiva e integral: muchos desarrolladores
trabajan en un número de diferentes proyectos al mismo tiempo.
Luego de que se han probado satisfactoriamente, todos los objetos y configuraciones
en el sistema de calidad pueden ser transportados al sistema de producción. Diferentes
clientes pueden ser creados para propósitos específicos. Si realizamos un Customizing
dependiente de cliente en el sistema de desarrollo y queremos verificarlo antes de
transportarlo a los demás sistemas, puede utilizarse un cliente de prueba en el mismo
sistema de desarrollo para tal propósito.
Clientes con roles específicos son usualmente creados en cada sistema: un cliente de
desarrollo en el sistema de desarrollo, un cliente para pruebas en el sistema de calidad
y un cliente productivo en el sistema de producción.
Generalmente, los clientes principales de cada sistema tienen el mismo número ya que
por defecto cuando transportamos el cliente origen es igual al cliente destino. Esto
último de todas formas no es obligatorio.

Lección 4: Transportes en SAP
Los cambios que los desarrolladores realizan en el sistema de desarrollo deben ser
transportados al sistema de calidad para realizar las pruebas necesarias y luego al
sistema de producción. El transporte de cambios es una de las tareas del administrador
del sistema o de un administrador de transportes.
Órdenes de Transportes y Tareas
Los transportes de Workbench y Customizing pueden ambos ser creados con el
Organizador de Transportes (Transport Organizer), transacción SE09 o SE10. Como
parte de una orden de transporte, el líder de proyecto es quien se encarga de definir
tareas para el tipo de orden (Workbench o Customizing) y asigna cada una a un
usuario correspondiente.
Después que cada tarea individualmente es liberada, la orden de transporte puede ser
liberada también. Liberar la orden de transporte genera que esta sea exportada.
Después de que se realiza la exportación, la orden de transporte está en condiciones
de ser importada en el sistema destino.
En un sistema de desarrollo, las configuraciones de Customizing son realizadas y
modificadas, los objetos de repositorio son creados y los que existen son modificados.
Para transportar estos objetos en los sistemas siguientes del landscape, necesitamos
una orden de transporte. Sin una orden de transporte no podemos transportar
configuraciones de Customizing u objetos de repositorio. Esto es porque, dependiendo
de la configuración del sistema, necesitaremos asignar a una tarea, la cual está
incluida en una orden de transporte, cada modificación o nuevo objeto que creemos o
configuración de Customizing que realicemos.
Cuando un proyecto de desarrollo comienza, el líder del proyecto idealmente deberá
crear una o más órdenes de transporte. Durante el proceso las personas involucradas
en el proyecto son asignadas a tareas dentro de esas órdenes de transporte.

Una orden de transporte por lo tanto pertenece al líder del proyecto y generalmente
comprende varias tareas, cada una de ellas asignada a una persona para el proyecto.

Figura 92 – Estructura de Órdenes de Transporte

El Organizador de Transportes
Uno de los lugares donde podemos crear una orden de transporte es en el Organizador
de Transportes, transacción SE09.

Figura 93 - El Organizador de Transportes

El Organizador de Transportes genera un nombre para la orden de transporte creada.
Este nombre se compone del SID del sistema de desarrollo, o mejor dicho, del sistema
donde estamos creando la orden. Luego, los caracteres K9 y cinco dígitos que
combinados forman una secuencia alfanumérica. Por ejemplo DEVK901234.
Una orden de transporte debería contener objetos que están lógicamente relacionados
y serán transportados juntos. Esto es, una orden de transporte nos permite transportar
y administrar desarrollos completos, lógicos y auto-contenidos. Una nueva orden de

transportes no es requerida para cada objeto, ya que esto resultaría en una gran
cantidad de órdenes de transportes y la administración se volvería compleja y confusa
lo que también llevaría a errores con los transportes potencialmente.
El Organizador de Transportes crea una tarea para cada persona involucrada en la
orden de transporte. Si una persona asigna un objeto a la orden de transporte, el
objeto se registra en la tarea de esa persona. De esta manera, todos los objetos que
una persona edita o crea durante el proyecto de desarrollo son registrados en la tarea.
La convención de nombres para las tareas es la misma que para las órdenes de
transporte. Una orden de transporte se diferencia entre varios términos.
El término orden de transporte es el término general o neutral. Una orden de
modificación o cambio es una orden de transporte utilizada para transportar cambios.
Los objetos que contiene, pueden por supuesto, ser transportados sin que ningún
cambio se haya realizado sobre ellos, tal es el caso de objetos nuevos creados en el
repositorio.
Una orden de Workbench es una orden de transportes en la que objetos de repositorio
o Customizing inter-cliente son transportados. Una orden de Customizing es una orden
de transporte en la que objetos dependientes de cliente son transportados, en otras
palabras, Customizing dependiente de cliente, datos maestros, transaccionales o datos
de usuario. De los tres, normalmente solamente Customizing dependiente de cliente es
transportado. Una orden de consolidación es una orden de transporte que será
transportada al sistema de consolidación (sistema de calidad).
Transportes
El transporte de objetos está dividido en las fases de Exportación e Importación: los
objetos son exportados desde el sistema de desarrollo e importados en los sistemas
destino tales como el sistema de calidad y el sistema de producción.

Figura 94 – Transportes en un Landscape de Tres Sistemas

La liberación de una orden de transporte dispara la exportación de los objetos que se
encuentran registrados por nombre en la orden de transporte. Estos objetos se
almacenan ahora en archivos de datos (data files) en el directorio de transportes
central. La información respecto del éxito de la liberación y la exportación queda
guardada en el log (registro) de transporte de la orden de transporte.

La importación en el sistema destino es usualmente no automática, pero es iniciada
por el administrador de transportes en el Sistema de Gestión de Transportes, que por
sus siglas en inglés se conoce como TMS (Transport Management System) y podemos
acceder mediante la transacción STMS.
Los registros de importación también son guardados en el log de transporte.

Figura 95 – Log de Transporte

En términos técnicos, una copia de los datos desde la base de datos del sistema de
desarrollo se escribe al directorio de transportes central durante la exportación de la
orden de transporte. Durante la importación, la orden de transporte almacenada en el
directorio central de transporte se copia a la base de datos del sistema destino.
El directorio central de transporte está físicamente ubicado en un sistema de archivos
(file system) al cual todos los sistemas que pertenecen al landscape de SAP tienen
acceso de lectura y escritura.
Cada sistema encuentra la ubicación del directorio de transportes que utilizará, ya sea
para escribir o leer las órdenes de transporte, por medio del parámetro de perfil
DIR_TRANS. La ubicación por defecto del directorio de transportes es:
/usr/sap/trans
De todas maneras, esto puede ser adaptado según los requerimientos. Solo en casos
excepcionales puede ser necesario utilizar varios directorios de transporte locales en
vez de un directorio central. Esto hace que el proceso de transportes sea un poco más
complejo, pero podría ser útil en algunos casos por razones de seguridad de la red.

Importación
El administrador de transportes usualmente inicia la importación en los sistemas
subsiguientes manualmente usando el TMS (Transport Management System) en el
sistema SAP correspondiente, con la transacción STMS.
En los sistemas posteriores a desarrollo, podemos ver que ordenes de transportes
están encoladas para ser importadas dentro del sistema en la transacción STMS. Desde
un punto de vista técnico en un landscape de tres sistemas, la orden de transporte es
marcada para importación en el sistema siguiente (sistema de calidad) cuando es
exportada desde el sistema de desarrollo.
Es posible ver esta marca de la orden de transporte para importación en el siguiente
sistema en el TMS, transacción STMS por medio de la opción de menú Overview →
Imports.

Figura 96 – STMS – Colas de Importación

Esto muestra la cola de importación para el sistema. Para ver los detalles sobre la cola
de importación, selecciona Import Queue → Display

Figura 97 – Visualización de Cola de Importación

Existe un número de métodos disponibles en la cola de importación de TMS para
importar las órdenes de transporte en el sistema destino. Los métodos más
importantes son Import All Transport Requests (Importación Masiva de Ordenes de
Transporte) e Import Individual Transport Requests (Importación Individual de
Ordenes de Transporte). Es posible ejecutar estos métodos en diálogo o en
background.

Figura 98 – Métodos de Importación

Cuando importamos ordenes individuales, tenemos que seleccionar la orden de la cola
de importación y luego importarla con la opción indicada. Cuando importamos ordenes
de transporte de manera masiva, todas las ordenes en la cola de importación son
importadas.
En ambos casos, los objetos son importados primero en orden de importancia y
segundo en el orden que tiene la orden de transporte en la cola de importación. Una
tabla por lo tanto es más importante que un programa porque el programa puede ser
dependiente de la tabla.
El orden de las órdenes de transporte en la cola de importación del sistema de calidad
asegura que sea el mismo orden en el que se exportaron desde el sistema de
desarrollo. Por comparación, el orden en la cola de importación del sistema de
producción se define por el orden con el que se importó en el sistema de calidad.
La cola de importación del sistema de producción puede ser por lo tanto organizada de
manera diferente a la del sistema de calidad. Esto es correcto, ya que esto refleja el
orden de la importación al sistema de calidad y por lo tanto la aceptación técnica en el
sistema de calidad.
En el sistema SAP, el administrador de transportes inicia la importación utilizando la
transacción STMS, eligiendo la cola de importación con la opción de menú Overview →
Imports, seleccionando el sistema en el cual la importación se llevará a cabo y
eligiendo Import Queue → Display. La importación inicia ya sea con el botón Import All
Requests

o Import Request

Técnicamente, el programa tp del sistema operativo es utilizado para la exportación y
la importación. La importación siempre usa los archivos de datos que fueron generados
y almacenados en el directorio central de transportes durante la exportación.

Lección 5: Órdenes de Customizing
Órdenes de Customizing
Una orden de Customizing puede contener objetos de Customizing dependientes de
cliente, datos maestros, datos transaccionales y de usuarios. Normalmente, solamente
Customizing dependiente de cliente es transportado en una orden de Customizing. En
el caso que sea necesario transportar Customizing inter-cliente deberá ser incluido en
una orden de tipo Workbench.
El Organizador de Transporte crea una tarea para cada persona en la orden de
transporte. Si una persona asigna un objeto de Customizing a la orden de Customizing,
el objetos es registrado por nombre en la tarea de esa persona. De esta manera, todos
los objetos de Customizing editados por esa persona se registran en la tarea.
Cuando las personas han completado el Customizing, liberan sus respectivas tareas.
Esto transfiere los objetos registrados en las tareas a la orden de Customizing. Una vez
que todas las personas han liberado sus tareas, el líder de projecto puede liberar la
orden de Customizing y por lo tanto realizar la exportación.

Figura 99– Ejecución, Liberación y Transporte de Customizing

La estructura de los proyectos de Customizing es similar a la estructura de proyectos
de desarrollo. Las personas involucradas en este caso son el líder de proyecto de
Customizing, quien crea y libera las ordenes de Customizing, y los miembros del
proyecto, quienes realizan el Customizing y asignan las configuraciones realizadas a la
orden de Customizing mediante las tareas.
Los cambios a los datos de Customizing se registran en el Organizador de Transportes
y en consecuencia en las tareas de las ordenes de Customizing, aunque en el caso de
Customizing, las entradas de tabla que son modificadas son solamente bloqueadas

durante el tiempo que se está trabajando en la modificación y es realizado por el
enqueue work process.
Para resumir, podemos decir que las configuraciones que son dependientes de cliente,
son modificaciones que se realizan en tablas del sistema, las cuales tienen un campo
clave que determina el número de cliente donde estamos trabajando.

Figura 100 – Estructura de una tabla de Customizing

Solamente durante el tiempo que estamos realizando los cambios los registros de
dichas tablas estarán bloqueadas con el sistema de bloqueo del sistema SAP. Una vez
que guardamos los cambios y quedan registrados en la tarea de Customizing, el
bloqueo se libera.

Figura 101 – Vista de una Orden de Customizing en el Organizador de Transporte

Lección 6: Órdenes de Workbench
Órdenes de Workbench
Las órdenes de Workbench son órdenes de transporte de Customizing inter-cliente y
objetos de repositorio. El proceso ilustrado aquí es utilizando objetos de repositorio
como ejemplo. El proceso para el Customizing inter-cliente es el mismo que para las
órdenes de Customizing.
El Organizador de Transportes crea una tarea para cada persona en la orden de
transporte. Si una persona asigna un objeto de repositorio a la orden de transportes, el
objeto de repositorio es registrado por el nombre en la tarea de esa persona.
Cuando el proyecto de desarrollo está completo desde el punto de vista del miembro
del proyecto, él o ella libera su tarea. Esto transfiere el objeto en la tarea a la orden de
transporte.
Una vez que todas las personas han liberado sus tareas, el líder del proyecto de
desarrollo puede liberar la orden de transporte y, en consecuencia, se genera la
exportación de la orden de transporte. Una orden de Workbench, por lo tanto, agrupa
objetos de repositorio con los que se han trabajado durante un proyecto de desarrollo.

Figura 102 – Desarrollo, Liberación y Transporte de Objetos de Respositorio

Si un objeto de repositorio es editado e incluido en una orden de transporte por un
desarrollador, este objeto se encuentra reservado exclusivamente para ser procesado
en esta orden de transporte. Cambios a este objeto pueden ser realizados por los
desarrolladores que también tengan tareas en la orden de transporte.
El desarrollo o mantenimiento de los objetos está bloqueado para todos los otros
desarrolladores que no están involucrados en la misma orden de transporte hasta que
la misma es liberada. Estos desarrolladores solo podrán visualizar los objetos.

Figura 103 – Ejemplo de Objeto de Repositorio en el Editor ABAP

Cada persona que está involucrada en la orden de transporte y edita el objeto recibe
una entrada correspondiente en la lista de objetos de su tarea. De esta manera, es
posible determinar quien o quienes editaron un objeto.

Figura 104 - Visualización de una orden de Workbench en el Organizador de
Transportes

Los objetos son desbloqueados cuando la orden de transporte es liberada. Otros
desarrolladores pueden luego trabajar sobre el objeto nuevamente. En los cambios a
los datos de Customizing, también son registrados por el Organizador de Transportes,
pero las tablas solo están bloqueadas durante el proceso de modificación por el
enqueue work process. No hay bloqueo de objetos para Customizing.

El Organizador de Transportes también lleva el versionado de los objetos de
repositorio, permitiendo comparaciones y también el acceso a versiones anteriores. De
esta manera, es posible documentar y recrear si es necesario, los diferentes estados,
posteriores y anteriores, a una orden de transporte o un proyecto de desarrollo. Una
versión es generada cuando la orden de transporte es liberada.

Mantenimiento del software SAP
Lección 1: Notas y Support Packages
Luego de que finalizamos la instalación de un sistema SAP, es muy probable que
necesitemos importar ajustes que se realizaron debido a cambios en requerimientos
legales, y corregir errores que podría haber en el software del sistema SAP.
SAP provee las notas de SAP y los Support Packages para este propósito.
Notas SAP y Support Packages
Un sistema SAP se conforma de varios componentes de software. Estos componentes
se actualizan regularmente a través de Notas de SAP y Support Packages . Ambos son
utilizados para importar al sistema cambios en requerimientos legales, corregir errores
y en algunos casos mejorar ciertas funciones existentes o incorporar nuevas funciones.
El sistema SAP debería siempre tener el nivel de actualización más reciente, por un
lado para cumplir con los requerimientos legales que puedan existir en el lugar donde
opera y para eliminar los errores que existen en el estándar por otro.

Figura 105 – Notas SAP y Support Packages

Las Notas de SAP pueden contener información general, recomendaciones o
indicaciones de SAP. También pueden describir un problema y su resolución al error en
funciones estándar del software SAP. Este último tipo de Notas SAP contiene una
solución a un problema individual, el cual es generalmente una corrección a un error
de programación, que obtenemos en la forma de líneas de código fuente con las
modificaciones necesarias para solucionar el error.
Las notas de SAP son muy utilizadas por los administradores de sistema para
resolver problemas específicos como errores en tiempo de ejecución de
programas estándar o fallas en los componentes del kernel por ejemplo. La base
de notas de SAP puede accederse a través del enlace rápido
http://service.sap.com/notes. La base de Notas de SAP se encuentra dentro del
Marketplace de SAP (http://service.sap.com) pero necesitamos de un usuario
especial para poder ingresar llamado usuario S.
Cada cliente de SAP es provisto por un super usuario S el cual luego puede crear
usuarios S adicionales con diferentes permisos dentro de Marketplace.
Los Support Packages son un conjunto de objetos de repositorio. En principio, cada
componente de software para cada nivel de versión tiene sus propios Support
Packages. En el caso de componentes de software que intersectan (con add-ons
modificados, por ejemplo), existe un tipo de Support Package adicional llamado
Transporte de Resolución de Conflictos, que por sus siglas en inglés se conoce como
CRT (Conflict Resolution Transport)
Los add-ons se implementan para soluciones de industria específica y modifican un
componente de software estándar (tal como por ejemplo SAP_APPL).
Técnicamente hablando, los Support Packages son un tipo de orden transporte que
no puede ser importada por los métodos normales que vimos en la unidad anterior. Un
Support Package contiene todas las Notas de SAP relevante a ese componente de
software y versión que se crearon desde el Support Package anterior al mismo. Los
Support Packages son por lo tanto no acumulativos y requieren siempre del anterior
para poder ser implementado.
Los Support Packages son implementados en el sistema con el Support Package
Manager, transacción SPAM. Las Notas de SAP son implementadas con el Asistente de
Notas, transacción SNOTE.

Transacción SNOTE
El Asistente de Notas se accede a través de la transacción SNOTE. Desde el SNOTE
podemos implementar varios tipos de notas: cambios a programas SAP, creación de
nuevos programas SAP, cambios a módulos de función SAP y varias otras cosas. De
todas formas, el Asistente de Notas no puede modificar objetos de Diccionario por
ejemplo. Además, el Asistente de Notas puede sólo modificar objetos de repositorio y
no Customizing.

Figura 106 – Asistente de Notas: proceso de implementación

Siguiendo la Figura 106, Las Notas de SAP se implementan con el Asistente de Notas
en los siguientes pasos:
1. Primero debemos localizar la Nota de SAP requerida en el SAP Marketplace, por
ejemplo, buscando por palabras claves o utilizando el número de nota si es que ya
conocemos cual es la que necesitamos.
2. Luego podemos cargar la Nota de SAP al sistema de desarrollo mediante el
Asistente de Notas (SNOTE)
3. La Nota de SAP es verificada por el Asistente de Notas. Verifica si el nivel de
versión del componente de software donde se va aplicar y el nivel de actualización de
Support Package del mismo son correctos para los prerrequisitos de la nota. También
verifica si la nota requiere de otras notas previamente implementadas y si puede ser
implementada cuando existen otras modificaciones sobre los objetos que están
afectados por la misma.
4. La Nota de SAP es implementada mediante la función de importación. Esto crea
una orden de transporte.
5. El resultado de la implementación de la Nota de SAP se prueba en forma general
en el sistema de desarrollo. Si la Nota no corrige el problema puede desimplementarse
también mediante la transacción SNOTE.
6. Si el resultado de la prueba es exitoso, por ejemplo si el error ya no se produce
luego de implementar la nota en el programa que corrigió, la orden de transporte se
libera y se importa en el sistema de calidad mediante el sistema de transportes. La
aceptación técnica se realiza en este sistema.
7. Si también resulta correcta la aceptación, entonces la orden de transporte es
importada en el sistema de producción.

Support Packages Stacks
En principio, la importación de Support Packages para un componente de software en
particular es independiente de los Support Packages de otros componentes de
software.
Los componentes individualmente son en general independientes de otro u otros
componentes de software. De todas maneras, pueden existir casos donde la
importación de Support Packages para un componente en particular tenga algunos
requisitos con otros Support Packages en otro componente. Esto significa que por
ejemplo la importación de un Support Package de HR puede requerir la importación
previa de un Support Package determinado del componente BASIS, o un Support
Package de APPL.
También puede suceder que aunque no sea un requisito cierto nivel de Support
Package en otro componente de software, resultan efectos adversos. Estos efectos
adversos (side-effects) son documentados en una Nota de SAP en cuanto son
detectados.
Para que podamos implementar las correcciones de manera consistente en los
diferentes componentes de software, SAP recomienda importar los Support Packages
usando Support Package Stacks.
Support Packages Stacks son una combinación de Support Packages de diferentes
componentes de software que incluyen un nivel determinado a cada componente y
evita los inconvenientes de dependencias y efectos adversos descriptos anteriormente.
Los Support Packages Stacks están disponibles para varias de las aplicaciones de SAP y
para componentes de SAP Netweaver también.
Adicionalmente a los Support Packages Stacks, también contienen actualizaciones para
otros componentes, tales como actualizaciones del kernel del sistema. Esto es
importante porque incluso puede ser necesario que actualicemos el kernel del sistema
SAP para asegurarnos que no sucedan errores con un nuevo nivel determinado de
Support Packages.
En el Marketplace de SAP podemos consultar información sobre los Support
Packages de los diferentes componentes de software de SAP así también como de
los Stacks, como están conformados y también determinar los Support Packages
que necesitaremos descargar para pasar del Stack actual al que necesitemos
actualizar.
El problema que surge frecuentemente es como actualizar un landscape complejo de
SAP, así también como la duda de cómo utilizar los Support Package Stacks para una
actualización ordenada y documentada.
¿Cuál es el nivel de actualización actual de mi landscape SAP?
¿Dónde puedo encontrar la información necesaria sobre Support Packages y Stacks?
El Optimizador de Mantenimiento (Maintenance Optimizer) provee la solución a estas
preguntas. Con el Optimizador de Mantenimiento pueden requerirse los Support

Package Stacks necesarios para el landascape definido en el Solution Manager en una
forma controlada y gestionable.
El Optimizador de Mantenimiento es mandatorio para algunos Support Packages y
Stacks, tales como los Support Packages para SAP ECC 6.0 que fueron liberados a
partir
de
Abril
de
2007.
Si queremos visualizar el estado actual de nivel de Support Packages para los
componentes de software de nuestra implementación, podemos hacerlo desde
cualquier pantalla de SAP, desde la opción de menú System → Status

Figura 107 - Estado de Sistema

Figura 108 – Información de Componentes de Software

Enhancement Packages
Un upgrade de sistema, por ejemplo de SAP R/3 4.6C a SAP ECC 6.0, es un upgrade
completo de sistema a una nueva versión. Luego del upgrade, el sistema funciona con
todas las funciones de la nueva versión. Antes de que pueda ser utilizado en la
operación de producción es necesario realizar muchos ajustes. Estos incluyen ajustes a
modificaciones del estándar, cambios a customizing, cambios a desarrollos propios del
cliente y mejoras.
Las pruebas de aceptación necesarias también consumen gran parte del tiempo.
Normalmente se necesita un período de varios meses para un proyecto de upgrade
para un landscape de sistemas SAP. Esto lo hace que sea de un esfuerzo considerable
de recursos y tiempo, por lo tanto costoso.
Para reducir el costo y esfuerzo que involucra, SAP está cambiando paulatinamente a
liberar los Enhancement Packages (EhP) para todas las aplicaciones. Esto comenzó con
SAP ERP 6.0 en 2007 con el EhP 2.
Enhancement Packages son nuevas versiones completas para un componente de
software particular en el sistema SAP, en otras palabras, son upgrades parciales del
sistema.
El Panel de Activación (Switch Framework) el cual está disponible a partir de AS ABAP
7.0 es usado para este propósito. Utilizando el Panel de Activación, se pueden realizar
cambios a los objetos de repositorio y no utilizarlos ya que necesitaremos activarlos en
primer lugar. Esto significa que podemos importar un Enhancement Package para un
componente de software en particular y mientras no activemos la o las funciones que
incorpora este Enhancement Package desde el Panel de Activación, el sistema seguirá
funcionando como antes de la importación.
Desde un punto de vista técnico, esto significa que un programa puede existir en el
repositorio en diferentes estados al mismo tiempo. Por lo tanto cuando activamos la
función desde el Panel de Activación, lo que estamos haciendo es activar una
determinada versión para los objetos de repositorio que dependen de esa función.
La importación de Enhancemente Packages solamente no genera un esfuerzo
considerable. Ahora es posible solo activar las funciones que van a ser requeridas
desde el punto de vista funcional. Eso mantiene el esfuerzo requerido para la
implementación y prueba de forma razonable.

Figura 109 – Enhancement Packages y Componentes de Software

Los Enhancement Packages son por lo tanto upgrades a componentes de software
individuales, con la ventaja adicional de que podemos activar las nuevas funciones de
una forma controlada y solamente cuando son necesarias.
Las ventajas de los Enhancement Packages son:
Procesos centrales estables
Adaptación simple a requerimientos legales
Tecnología estable
Planificación y mantenimiento sencillo
Disminución de upgrades de sistemas
Nuevas funciones pueden ser implementadas selectivamente cuando son requeridas
A diferencia de los Support Packages, los Enhancement Packages son acumulativos, lo
que significa que no necesariamente debemos importarlos en secuencia. Por ejemplo,
el Enhancement Package 4 para SAP ERP 6.0 contiene a Enhancement Package 2 y 3
por lo que podremos implementar directamente la última versión directamente.
La importación de Enhancement Packages se realiza mediante la transacción SAINT, la
cual es para la implementación y actualización de componentes de software. De todas
formas, a partir de EhP 4 para SAP ERP 6.0 existe una herramienta externa llamada
Ehpi (Enhancement Package Installer) para este propósito.
Los Support Packages al estar vinculados con la versión del componente de software
existen en diferentes niveles para cada versión de componente de software. Esto
significa que luego de la implementación de Enhancement Package 2 para SAP ECC
6.0, los Support Packages que necesitaremos posteriormente deberán ser para SAP
ECC 6.0 EhP 2

Lección 2: Configuración de Impresoras
El administrador configura las impresoras en el sistema SAP y monitorea la salida de
los spool requests.
Impresión en el Sistema SAP
Existen varias clases de documentos en el sistema SAP, tales como listas de reportes,
SAPscript o SAP Smart Forms. Aunque la manera en que se crean estos documentos es
completamente diferente, la salida de impresión en papel de estos documentos
siempre se realiza utilizando el mismo mecanismo de dos etapas:
Primero un spool request es creado. El spool request contiene información de
impresión independiente del dispositivo de salida e incluye información administrativa
tal como autor, fecha, número de copias y la información que se va a imprimir.
Solamente cuando el spool request va a ser direccionado a un dispositivo en
particular un output request es creado. La información independiente de dispositivo del
spool request es convertida al lenguaje particular de la impresora que comprende el
dispositivo de salida seleccionado.

El administrador configura las impresoras en el sistema SAP y monitorea la salida de
los spool requests.
Impresión en el Sistema SAP
Existen varias clases de documentos en el sistema SAP, tales como listas de reportes,
SAPscript o SAP Smart Forms. Aunque la manera en que se crean estos documentos es
completamente diferente, la salida de impresión en papel de estos documentos
siempre se realiza utilizando el mismo mecanismo de dos etapas:
Primero un spool request es creado. El spool request contiene información de
impresión independiente del dispositivo de salida e incluye información administrativa
tal como autor, fecha, número de copias y la información que se va a imprimir.
Solamente cuando el spool request va a ser direccionado a un dispositivo en
particular un output request es creado. La información independiente de dispositivo del
spool request es convertida al lenguaje particular de la impresora que comprende el
dispositivo de salida seleccionado.

Figura 110 – Flujo de datos durante la impresión

Este proceso permite al usuario visualizar el spool request antes de la salida. Puede
haber muchos output requests para un spool request. Esto puede evitar que el usuario
tenga que recrear un spool request, si por ejemplo, el toner de la impresora está
agotado o el papel incorrecto se encontraba en la bandeja. Por supuesto que también
la impresión puede ser al mismo tiempo de la creación del spool request mediante la
selección de la opción impresión inmediata (Print out immediately).
El contenido real de un documento de un spool request se almacena en el TemSe
(para objetos secuenciales temporales), el cual se define el lugar donde se almacenará
mediante el parámetro rspo/store_location.
Valor db (valor por defecto): El spool request se almacena en la tabla de base de
datos TST03 (ventaja: se respalda junto con el backup de la base de datos)

Valor G: se almacena en el sistema operativo en el directorio global. (ventaja:
mayor performance)
Se puede especificar el lugar de almacenamiento individualmente para cada
dispositivo de salida en la transacción SPAD (desde el menú Edit → Data
Storage).
La nota de SAP
rspo/store_location.

20176

contiene

valores

adicionales

para

el

parámetro

La creación de un output request solicita al sistema de spool de SAP enviar información
con un formato dependiente de la impresora seleccionada al sistema de spool del
sistema operativo. Esto significa que el modelo de impresora elegida debe ser conocido
por el sistema SAP. Definiciones de este tipo se conocen como tipos de dispositivos
(device types).
Si una impresora no puede ser controlada a nivel del sistema operativo, no puede ser
usada en el sistema SAP tampoco.
Hay varias maneras en la que un spool work process puede alcanzar a un spool del
sistema operativo. Las conexiones más importantes, conocidas como métodos de
acceso (access methods) se explican a continuación en esta lección.
Impresión Local

Figura 111 – Impresión Local

Una característica de la impresión local es que el spool work process y el sistema de
spool del sistema operativo corren en el mismo servidor. No es relevante si la
impresora está conectada directamente a este servidor o se alcanza a través de la red.
El spool work process pasa la información de forma local, en el mismo servidor.
En servidores UNIX, la impresión local se define con el método de acceso L.
En Microsoft Windows, se utiliza el método de acceso C.
La impresión local es la conexión más rápida y confiable desde el sistema SAP al
sistema operativo. Tan pronto como el spool work process ha transferido la

información, puede tomar nuevos output requests, aún si el spool del sistema
operativo se encuentra ocupado todavía.
Se pueden configurar multiple spool work processes para una instancia SAP. Esto tiene
consecuencias en la secuencia de salida. Spool Requests diferentes para la misma
impresora podrían ser impresos en un orden distinto del que fueron creados. Si
necesitamos que la salida de impresión respete la secuencia, podemos especificarlo
para impresoras de forma individual. Sin embargo, una configuración de este tipo
reduce la posibilidad de impresión en paralelo. Para más información sobre esto,
podemos consultar la nota de SAP 108799.
Impresión Remota
En la impresión remota, el spool work process y el spool del sistema operativo están
corriendo en diferentes hosts. De la misma manera que en la impresión local, es
irrelevante desde el punto de vista del sistema SAP si la impresora se conecta
directamente al host remoto o es a través de una conexión de red.

Figura 112 – Impresión Remota

Escenarios típicos para la impresión remota son:
Impresoras de red que proveen su propio sistema de spool y son conectadas
directamente a la red.
Desde el sistema SAP se acceden mediante el método U con el nombre de la
impresora.
El método de acceso U también es utilizado si el host remoto es un sistema UNIX. La
nota 39405 describe como el método de acceso U puede ser usado por las diferentes
versiones de UNIX.
SAP provee el programa SAPSprint para todos los hosts con sistemas operativos
Windows. SAPSprint es un servicio de Windows. Cada output request se procesa en un
hilo de ejecución separado. Los output requests de SAP que recibe SAPSprint del
sistema SAP pueden ser transferidos a una impresora particular. Si la impresora no

está funcionando, esto no interrumpe la impresión de otros output requests en otras
impresoras.
El método de acceso S es usualmente utilizado en este caso (protocolo SAP), pero el
método de acceso U también es soportado.
Por razones de performance, solo deberíamos utilizar impresión remota en un entorno
LAN y deberíamos asegurarnos que los spools de los sistemas operativos estén
disponibles.
Los usuarios SAP pueden imprimir documentos en sus impresoras locales usando
impresión en front-end.
Estas impresoras locales no necesitan ser definidas en el sistema SAP. Si es necesario
que el administrador del sistema configure un dispositivo representativo para cada
plataforma de sistema operativo de front-end.

Figura 113 Impresión en Front-end con Tecnología de Control (Método de Acceso G)

Desde la versión SAP Web AS 6.20, un nuevo procedimiento de impresión en front-end
se encuentra disponible: impresión en front-end mediante tecnología de control con el
método de acceso G. Esto ya no requiere del programa SAPlpd. La ventana de
impresión de Windows se llama directamente desde el control.
El programa SAPlpd se instala junto con el programa SAP Logon.
Los controles son DLLs que corren en el contexto de proceso de SAP GUI. El nuevo
método de impresión recibe los datos de impresión y lo transfiere al sistema de
impresión del sistema operativo. Una ventaja de este método frente al método F es
que ofrece la ventaja de que puede ser utilizado también con SAP GUI para JAVA lo
que hace que sea independiente de la plataforma del front-end. También puede ser
utilizado con Windows Terminal Server. Información sobre impresión de front-end con
tecnología de control está disponible en la nota de SAP 821519.
Podemos definir el máximo número de spool work processes que pueden ser utilizados
en el sistema SAP para impresión en front-end para cada instancia de SAP mediante el
parámetro rdisp/wp_no_Fro_max (el valor por defecto es 1).

Este método de impresión no es recomendado para impresión masiva, sino más bien
para impresión en impresoras locales de los usuarios.
Cuando usamos el método de acceso F (para versiones hasta 4.6C), los datos de
impresión se transfieren al host en donde el programa SAP GUI del usuario está
corriendo. Este método puede ser usado en PCs con diferentes sistemas operativos:
En el caso de sistemas operativos de Microsoft Windows, el programa saplpd transfiere
los datos recibidos al control de impresión de Windows. Si es necesario, saplpd se
inicia automáticamente.
Con otros sistemas operativos (Linux, Apple Macintosh, etc) los datos se transfieren
directamente al sistema de spool del sistema operativo. En este caso, el nombre de la
impresora debe especificarse en la definición del dispositivo.
Para más información, puedes ver la Nota 128105.
Si utilizamos SAP GUI para HTML y vamos a imprimir en los front-end, debemos utilizar
el método de acceso F. Usando este método, los datos de impresión son enviados al
navegador y visualizados. Luego puede imprimirse el documento en el front-end.

Creación de Dispositivos de Salida
La configuración del sistema de spool es una tarea del admnistrador del sistema. La
herramienta central para esto es la transacción SPAD (menú Tools → CCMS → Print →
Spool Administration)

Figura 114 – Creación de Dispositivos de Salida

Con impresión de front-end con tecnología de control (método de acceso G), la
impresora tiene un nombre genérico en SAP, y es asignada al dispositivo físico
_DEFAULT. Como los modelos utilizados en las impresoras de front-end pueden ser
muy variados, el dispositivo SWIN se asigna para las impresoras de los front-ends que
utilizan Windows. Cuando se imprime con SAP GUI para JAVA en otros sistemas
operativos, deberemos utilizar un dispositivo correspondiente, tal como PostScript.
Si la impresión en front-end se realizará utilzando SAP GUI para HTML con el método
de acceso F, el dispositivo de tipo PDF1 debe seleccionarse. Los datos de impresión
son luego transferidos al navegador en el front-end como un documento PostScript y
puede ser impreso localmente.

Tabla 2 - Dispositivos de Salida para Impresión en Front-end

Para crear un dispositivo de salida, llamamos a la transacción SPAD y elegimos Output
Device en la solapa Devices/Servers. Si hay un gran número de dispositivos en el
sistema, podemos restringir la lista de devuelta con el campo de texto por ejemplo
ingresando PR* (devolverá todas los dispositivos que comiencen con las letras PR)
Dispositivo de Salida (Output Device): Nombre, máximo 30 caracteres.
Nombre corto (Short Name): Para propósitos internos del sistema (puede generarse
automáticamente)
Tipo de Dispositivo (Device Type): Modelo de la impresora o familia compatible.
Servidor de Spool (Spool Server): Servidor de aplicación SAP con spool work
processes o un servidor lógico (veremos este concepto en la próxima lección)
Lugar (Location): Por ejemplo, edificio u número de oficina. Sirve para que los
usuarios sepan donde se hará la impresión)
Mensaje (Message): Utilizado temporalmente para sobrescribir al campo Lugar. Sirve
para informar por ejemplo cuando está en mantenimiento el dispositivo)
Impresora Bloqueada en el Sistema SAP (Lock Printer in SAP System): Los output
requests para este dispositivo son creados pero no transferidos a la impresora. El
usuario recibe un mensaje: sin impresión inmediata.
Método de Acceso (Host Spool Access Method): como un spool work process
contacta al sistema de spool del sistema operativo.
Host de Impresora (Host Printer): Nombre de la impresora a nivel del sistema
operativo. Este nombre es dependiente de minúsculas y mayúsculas. En Windows, no
debe haber espacios en el nombre de impresora.
Nombre de Host (Host Name): solo para impresión local, se calcula automáticamente
del servidor de spool.
Host Destino (Destination Host): solo para impresión remota. Nombre del host en el
cual el spool del sistema operativo está corriendo.

Tipos de Dispositivos
El sistema SAP utiliza un tipo de dispositivo para formatear la información de impresión
a un dispositivo específico.
Cuando se hace referencia a un dispositivo de salida en el ambiente de SAP,
no necesariamente significa una impresora. Un dispositivo de salida puede ser,
por ejemplo, un Sistema de Gestión de Salida o un Sistema de Archivado.
Cuando el spool work process genera un output request, utiliza las especificaciones del
tipo de dispositivo. Esto es, el tipo de dispositivo describe como la impresión de datos
debería ser formateada para un dispositivo en particular.
La siguiente figura ilustra como un dispositivo de salida es creado:

Figura 115 – Dispositivo de Salida

La siguiente lista explica los términos de la figura.
Formato de Página (Page Format): Un formato de página describe el formato de
una página imprimible en el sistema SAP. Un gran número de formatos de páginas
estándar son predefinidos en el sistema. Si un dispositivo va a soportar formatos
adicionales, podemos definir nuevos formatos. Hay que considerar que cuando
hacemos esto, el dispositivo de salida que vamos a utilizar debe soportar el formato
definido.
Tipo de Formato (Format Type): Un tipo de formato describe como la salida
debería aparecer en el papel. Principalmente contiene el formato para la página.
Formato (Format): Un formato es una implementación de un tipo de formato
específico para un dispositivo. Esto es, el sistema SAP puede usar la descripción en un
formato para controlar un dispositivo correctamente. Por ejemplo, realizar una salida

en una página con el formato de Carta. Un tipo de formato es por lo tanto
independiente del dispostivo; el formato, por otro lado es una implementación
específica de dispositivo para un tipo de formato.
Set de Caracteres (Character Set): Un set de caracteres contine los caracteres
que pueden ser utilizados por un dispositivo de salida particular. Significa, que para
poder usar un set de caraceteres particular para un modelo de impresora en el sistema
SAP, el tipo de dispositivo asignado al modelo de impresora debe contener este set de
caracteres.
Control de Impresión (Print Control): Permite el control de la visualización de
opciones de los dispositivos de salida, tal como el cambio de tamaño de fuente, o la
misma fuente. El control de impresión utiliza un control de secuencia de caracteres
específico del dispositivo. Esto significa que para crear nuevos dispositivos, las
opciones de visualización ofrecidas por el sistema SAP deben ser almacenadas con el
control de secuencia de caracteres que el modelo de impresora elegido soporta.

Lección 3: Administración de Spool Servers
Concepto de Spool Server Lógico

El concepto de impresión mostró hasta acá un idea de una asignación fija de un
dispositivo de salida a un servidor de spool. Un servidor de spool, por otro lado, pude
ser asignado a múltiples dispositivos de salida lo cual incrementa el riesgo de
sobrecarga en este servidor o también de no disponer de muchas impresoras si una
instancia no se encuentra operativa.
Por estos motivos sería convenientes tener un mecanismo para balancear la carga
entre varios servidores de aplicación SAP. La inclusión de servidores lógicos en el
planeamiento de impresión para el landscape de SAP desde un primer momento puede
ahorrar mucho esfuerzo en el mantenimiento de la operación.
Cuando el sistema SAP se escala en el tiempo con instancias adicionales y spool work
processes se ponen a disposición, los servidores de spool lógico facilitan la adaptación
del landscape de impresión.

Figura 116 – Servidores de Spool

Un servidor de spool es un servidor de aplicación SAP con al menos un spool work
process. Cada output request es procesado en un servidor de spool real de este tipo.
Un dispositivo de salida es creado en el sistema SAP y se asigna a un servidor de spool
directamente. Sin embargo, existen varias ventajas asociadas con una capa
adicional lógica entre el dispositivo de salida y el servidor de spool. Podemos utilizar
servidores de spool lógicos para este propósito.
Podemos clasificar dispositivos de salida y servidores de spool, por ejemplo, para
impresión de test o impresión de producción.
El sistema SAP verifica la clasificación y muestra mensajes de advertencia si encuentra
una desviación. Por ejemplo, el sistema advierte si intentamos imprimir un gran
volumen en un servidor de impresión productivo.
Podemos mantener los servidores de spool en la transacción SPAD mediante la
selección de Spool Servers en la solapa Devices/Servers. Información importante de un
servidor de spool:
Nombre de Servidor (Server Name): Nombre del servidor de spool, máximo de 20
caracteres y depende si es mayúsculas o minúsculas. El siguiente campo es para una
descripción breve.
Clase de Servidor (Server Class): Clasificación del spool server, por ejemplo:
impresión masiva.
Servidor Lógico (Logical Server): seleccionamos esta opción cuando creamos un
servidor lógico.
Mapeo (Mapping): Nombre de un servidor lógico real al cual este servidor lógico
refiere.

Figura 117 – Creación de Servidor Lógico de Spool

Se puede definir un servidor de spool (lógico o real) especificamente para impresión en

front-ends. Si especificamos el parámetro de perfil rspo/local_print/server con el
nombre del servidor de spool.
Si vamos a tener una carga siginificante de impresión en front-end, podemos
configurar al menos un spool work process adicional por cada servidor de spool de
impresión de front-end para otras tareas.
Como se mencionó antes, es posible clasificar dispositivos de salida y servidores de
spool. Para clasificar un dispositivo de salida, tendremos que seleccionarlo en la
transacción SPAD, bajo Output Devices y seleccionar el menú Edit → Classification.
Ventajas de los Servidores de Spool Lógicos
Cuando creamos un servidor de spool, ya sea un servidor lógico o un servidor real,
podemos especificar un servidor alternativo. Si el servidor normal no está disponible, el
sistema SAP intenta usar el alternativo.

Figura 118 – Alternativas de Servidores de Spool

Debemos asegurarnos que todas las impresoras que podrían ser usadas por un
servidor de spool diferentes puedan ser controladas de la misma manera por cada
servidor de spool. Por ejemplo, si el dispositivo de salida Test 1 en el ejemplo de la
figura apunta a una impresora del sistema operativo P42 que es controlada localmente,
una impresora a nivel del sistema operativo P42 debe existir en los servidores
twdf5000 y twdf5001.
No podemos definir más de dos servidores de spool para un servidor lógico. Pero como
si puede referenciar a otro servidor lógico, es posible configurar jerarquías extensivas
de servidores se spool. O sea configuraciones en cascada de servidores lógicos
haciendo referencia a un servidor de spool y como alternativa a otro servidor lógico.
Balanceo de Carga
Podemos permitir balanceo de carga para cada servidor de spool con un servidor
alternativo (para esto debemos elegir la opción Allow Load Balancing). La carga de un
servidor de spool es calculada con el número de spool work processes, output requests
y páginas a imprimir.

Figura 119 – Balanceo de Carga

Para un output request para un servidor de spool con balanceo de carga (la
configuración puede ser para servidores lógicos y para servidores de spool), el sistema
determina el servidor con la menor carga. El algoritmo es recursivo: el mismo criterio
de selección es utilizado en el servidor mapeado y en el servidor alternativo (ambos
podrían ser servidores lógicos también).
Procesamiento de solicitudes secuenciales (propiedad de un dispositivo de salida) tiene
prioridad sobre el balanceo de carga mostrado aquí (propiedad de un servidor de
spool). Esto significa que el output request para un dispositivo de salida con
procesamiento de solicitudes secuenciales no será distribuido en concordancia con la
carga de trabajo, aunque sea asignado a un servidor de spool con balanceo de carga.

Transportando el Landscape de Impresión
El concepto de servidores lógicos soporta una definición de un landscape de impresión
consistente y transportable. A diferencia de servidores de spool reales, los servidore
lógicos pueden tener el mismo nombre en varios sistemas SAP. De esta forma,
podemos definir una arquitectura de impresión en SAP en el sistema de desarrollo y
luego transportarla a los demás sistemas. Luego de transportar, todo lo que
necesitaremos hacer es ajustar el mapeo de los servidores lógicos a los servidores de
spool del nuevo sistema.

Figura 120 – Transportando el Landscape de Impresión

Existen funciones para el transporte manual de dispositivos de salida y de servidores
de spool en la transacción SPAD.

Lección 4: Jobs de Background
¿Qué es el procesamiento en background o de fondo?
El procesamiento en background debería esencialmente separar tareas periódicas y
que insumen mucho tiempo de aquellas de interacción de usuarios. Tareas que
requieran mucho tiempo y ocuparían un work process en diálogo pueden ser
secuencialmente procesadas en background sin afectar la performance de diálogo.
Un requisito importante para conseguir este objetivo es un dimensionamiento
apropiado del sistema, ya que, demasiados procesos de background podrían terminar
compitiendo por recursos compartidos con procesos de diálogo (memoria principal,
CPU).
Los programas que deban ejecutarse regularmente y consuman mucho tiempo son
planificados como Jobs de background en el sistema SAP. El administrador planifica los
Jobs de background y monitorea la correcta ejecución de los mismos.

Fundamentos
Las siguientes preguntas responderemos en esta lección:
¿Por qué necesitamos procesamiento en background?
¿Qué es un Job de background?
¿Qué podemos realizar en background?
¿Qué condiciones de inicio existen?
¿Cómo son planificados y monitoreados los Jobs?
¿Qué estados puede tener un Job?

Figura 121 – ¿Por qué es necesario el Procesamiento en Background?

Work processes de diálogo deberían estar disponibles para responder a las solicitudes
de los usuarios rápidamente. Los recursos de diálogo deberían por lo tanto no ser

utilizados para ejecuciones prolongadas ya que pueden provocar cuellos de botella en
el tiempo de respuesta de diálogo. El parámetro rdisp/max_wprun_time existe por este
motivo justamente. Limita el máximo tiempo de ejecución de un paso de diálogo en un
work process de diálogo.
Esto debería asegurar que los procesos de diálogo no sean bloqueados por programas
que requieren demasiado tiempo de ejecución, interfiriendo la operación online. Luego
de que el máximo tiempo se ha superado, el programa es terminado.
La manera en que el parámetro rdisp/max_wprun_time funciona está descrito en
la nota de SAP 25528.
Podemos utilizar los procesos de background para tareas que consuman mucho
tiempo. También se conocen estos como procesos de batch.
Normalmente, los procesos de background no se utilizan solamente para ejecuciones
largas, sino que también para tareas repetitivas. Ejemplos de estas son los backups
diarios de base de datos o los cierres de mes financieros y contables.

Figura 122 – ¿Qué es un Job de Background?

Un job de background consiste de uno o más pasos (steps). Un paso puede ser:
Un programa ABAP
Un comando externo
Un programa externo
Cada job se procesa sin interrupción por un único background work process. Los jobs
de background pueden ser planificados con diferentes prioridades:
Clase A (Prioridad alta)
Clase B (Prioridad media)

Clase C (Prioridad normal)
Si un job es planificado para ser ejecutado en un servidor particular o un grupo de
servidores, este tendrá preferencia con respecto a otros jobs de la misma clase. Esta
preferencia solamente aplica si múltiples jobs con la misma prioridad solicitan el
procesamiento en background al mismo tiempo, por ejemplo, porque se planificaron
para que se ejecuten a la misma hora.
Deberíamos asegurarnos que la mayor parte de los jobs de background sean
planificados con prioridad normal, clase C, sin especificación de servidor de
ejecución. Esto debería aplicar para el 90% o más de todas las tareas de
background.

Figura 123 – ¿Qué Podemos Ejecutar en Background?

Un paso dentro de un job puede ejecutar una de estas tres acciones:
Un programa ABAP pude planificarse como un paso de un job. Si el programa
ABAP tiene una o más pantallas de selección, tendremos que crear las entradas
previamente en una variante. Una variante hace posible ejecutar un programa ABAP en
background aunque el programa requiera valores de entrada.
Los valores almacenados en la variante son luego utilizados durante la ejecución del
programa. Si un programa ABAP tiene una pantalla de salida como resultado, esto es
dirigido a una lista de spool. Podríamos también especificar un recipiente de email para
esta lista de spool durante la definición del job. Debemos especificar una impresora
para la creación de la lista de spool, aunque no necesariamente tenga que ser impreso
en un dispositivo de salida como resultado del procesamiento en background. Esto por
ejemplo podría hacerse posteriormente.
Un comando externo es un llamado a un script predefinido, un comando, o un
programa a nivel del sistema operativo. Con comandos externos, podemos enmascarar
llamadas al sistema operativo y guardarlos en el sistema SAP bajo un nombre.
Podemos usar también el concepto de autorización de SAP para proteger la ejecución
de un comando externo. Esto permite que podamos determinar que usuarios están
permitidos a ejecutar que comandos externos (sobre que servidores y/o sistemas
operativos)

Un programa externo es un comando del sistema operativo. El concepto de
autorización de SAP solamente especifica si un usuario puede llamar un programa
externo o no. Una asignación más detallada de autorizaciones, por ejemplo a nivel de
los nombres de programa, no es provista con la ejecución de programas externos.
Utilicemos comandos externos para esto.

Figura 124– Criterios de Inicio de un Job de Background

Un job puede ser iniciado:
Mediante la planificación en una fecha y hora particular (esto incluye el inicio
inmediato, si no hay background work processes libres disponibles al momento en que
debe iniciar el job según la planificación)
Mediante la ocurrencia de un evento particular definido en el sistema SAP. Esto
incluye jobs que se iniciarán luego de la finalización de otros jobs o en los cambios de
modo de operación o jobs con inicio inmediato si existen background work processes
libres al momento.

Planificación y Monitoreo
Podemos utilizar la transacción SM36 para definir nuevos Jobs. Puedes también llamar
el Asistente de Job, transacción SM36WIZ o desde la transacción SM36 también.

Figura 125 – Planificación de Jobs

Las especificaciones que requiere la definición de un job son:
Especificaciones generales tales como nombre de job, prioridad del job (por defecto:
C) y opcionalmente un servidor de ejecución o grupo.
Definición de uno o más pasos
Definición de una condición de inicio (de tiempo o controlada por evento)
El Asistente de Job nos ayuda en la creación del job guiándonos de manera fácil a
través del proceso de creación.
El método de creación de un job de background (clásico o mediante el Asistente de
Job) no tiene incidencia en el resultado. Algunas funciones (especificar el usuario SAP
en la definición del paso de job, modificación del orden de ejecución de los pasos) no
están disponibles para el Asistente de Job.
La transacción SM37 nos permite monitorear los jobs. Podemos seleccionar los
jobs utilizando diversos criterios en la pantalla inicial de esta transacción. Algunas
opciones serían visualizar los jobs que contienen un paso determinado, que tienen un
estado particular o que reaccionan a un evento definido.

Figura 126 – Monitoreo de Jobs

Luego de que seleccionamos Execute, una vista de job aparece que es creada por el
Visor de Listas SAP (SAP List Viewer: ALV). Seleccionando del menú Settings podemos
determinar las columnas que se mostrarán y el orden, entre otras cosas. Podemos
también configurar si será el diseño (layout) estándar para el usuario actual o todos los
usuarios.
Para el análisis de jobs, una columna que no se visualiza por defecto y es importante,
es la columna de servidor de ejecución. Muchas veces algún problema en la ejecución
de un job puede estar relacionado al servidor de aplicación donde se ejecuta.
Podemos también navegar a otras vistas específicas del job desde la visualización de
job mostrada en la figura:
Lista de Spool contiene las listas de salida de los programas de ABAP (si es que
existen)
Detalle del Job contiene, entre otras cosas, información sobre la definición del job,
duración del procesamiento del job y la fecha y hora de inicio del job.
Todos los mensajes de salida por un programa de background son almacenados en el
log del job. Podemos visualizar el log para obtener información sobre un programa que
finalizó con error o para realizar una investigación detallada sobre la ejecución de un
job de background.

Figura 127 - Estados de un Job

Un job puede tener los siguientes estados:
Planificado (Scheduled): Los pasos que requieren la creación del job han sido
definidos ya, de todas formas la condición de inicio aún necesita ser definida.
Liberado (Released): El job ha sido completamente definido, incluyendo la
condición de inicio. Un job no puede ser liberado sin una condición de inicio.
Solamente un administrador o un usuario con las autorizaciones necesarias para el
procesamiento de background puede liberar un job. Esto asegura que usuarios sin
autorización no puedan ejecutar jobs sin aprobación.
Listo (Ready): La condición de inicio de un job liberado se ha cumplido. Sin
embargo el job se encuentra en la cola de espera por un work process de background
libre.
Activo (Active): El job está siendo ejecutado y no puede ser borrado ni modificado.
Si un job activo no se ejecuta normalmente, por ejemplo, demora mucho más del
tiempo normal, podemos analizar el job en modo de depuración. Luego podemos
finalizar el job definitivamente o liberarlo nuevamente. Para esto, en la transacción
SM37, seleccionamos Job → Capture: active job.
Para capturar un job de background, debemos iniciar sesión en el
servidor SAP donde el job está corriendo.
Finalizado (Finished): todos los pasos del job fueron ejecutados sin problemas.
Cancelado (Canceled): El job finaliza anormalmente, esto puede suceder de dos
maneras:

1. El administrador deliberadamente termina el job en la transacción SM37 mediante la
selección de Job → Cancel active job.
2. Un paso del job terminó con error.
Podemos modificar un job mientras este tenga los estados Planificado o Liberado. Si la
ejecución de un job ya ha comenzado, podemos monitorear el procesamiento en el log
del job. Si el job tiene programas ABAP que crean listas de salida, estas se almacenan
en las listas de spool.
Podemos crear un nuevo job copiando otro existente. Desde el menú selecciona Job →
Copy.

Lección 5: Administración de Jobs
Planificación Basada en Tiempo

Figura 128 – Inicio Dependiente de Tiempo de un Job

Un job puede ser iniciado de forma dependiente de tiempo o de un evento. En el caso
de inicio basado en tiempo, podemos seleccionar entre las siguientes opciones:
El job debe ejecutarse inmediatamente.
El job debe ser ejecutado en una fecha y hora particular.
El job debe ejecutarse en un día laboral determinado.
Puedes seleccionar que el job sea recurrente. Esto significa que el job será ejecutado
nuevamente después de un período de tiempo definido. También es posible especificar
excepciones, tal como posponer al siguiente día laboral en el caso de un feriado en el
calendario.

El job es iniciado en la fecha y hora indicado, en concordancia con la prioridad del job
y disponibilidad de work processes de background.
Puedes especificar también un período de tiempo en el cual el job debe iniciarse. Para
esto, especificamos un tiempo luego del cual el job no debe ejecutarse. Con esta
función, podemos prevenir la ejecución de jobs periódicos en un momento no
conveniente, entre otras cosas. Por ejemplo, un job de reorganización que debería
solamente ejecutarse durante la noche demora su inicio por falta de disponibilidad de
work process de background. Con una ventana de tiempo de inicio, podremos evitar
que este job se ejecute durante el día, cuando los usuarios de diálogo están activos y
hay menos recursos disponibles.
Balanceo de Carga
El parámetro de perfil rdisp/bctime especifica el período de tiempo en el cual el
planificador de jobs dependientes de tiempo está activo (observar la Figura 129). La
ejecución de jobs con una condición de inicio inmediata usualmente evita el
planificador. En este caso, el work process de diálogo del usuario que solicita el inicio
inmediato es quien planifica el job. Solo si no hay recursos libres, el job es planificado
de forma basada en tiempo. La fecha y hora planificada de inicio corresponde al
momento en el tiempo en el que debería haber iniciado.

Figura 129 – Planificando Jobs y Balanceo de Carga

Los work processes de background pueden ser configurados en cada instancia del
sistema SAP utilizando el parámetro de perfil rdisp/wp_no_btc.
El número de work processes requeridos en el sistema SAP depende del número de
tareas que se realizarán en batch. Si el sistema de transporte es utilizado, debe haber
al menos dos work processes de background en el sistema. La combinación de job ID y
el nombre de job definen el job de manera univoca en el sistema.
En cada instancia SAP en la que existen work processes de background definidos, el
planificador de job basado en tiempo corre cada la cantidad de segundos definido en

ridsp/btctime (el valor por defecto es 60). Este es un programa ABAP (SAPMSSY2) que
corre automáticamente en un work process de diálogo.
A partir de SAP Netweaver 7.0 el planificador de job también se inicia luego de que
un job ha finalizado. Esto incrementa la tasa de salida para el procesamiento de
background considerablemente dependiendo de cuantos jobs hay planificados y
recursos disponibles. La nota de SAP 923228 describe como podemos activar esto
para sistemas SAP con una versión a partir de Basis de 4.6C.
El planificador de job basado en tiempo verifica la tabla de planificación de jobs en la
base de datos y busca jobs que estén esperando a ser ejecutados. Estos jobs son
transferidos a work processes de background que se encuentren libres en la instancia
de SAP, de acuerdo a la prioridad y servidor de ejecución.
Los jobs que no son asignados a ningún servidor en particular para la ejecución
pueden ser ejecutados con cualquier work process de background libre. Esto significa
que la carga de trabajo es automáticamente distribuida entre las instancias SAP.
Si un job es explícitamente asignado a ser ejecutado ya sea en una instancia
seleccionada o un grupo de instancias algunas características particulares se derivan
de esto, tal como asegurarnos que el job se ejecuta en un sistema operativo particular
o en el mismo servidor donde corre la base de datos. Esto significa, de todas maneras,
que no contamos con la ventaja de la distribución de carga automática del sistema.

Jobs Estándar
Los jobs estándar son jobs de background que deberían ejecutarse regularmente en un
sistema de producción SAP. Estos jobs principalmente realizan ciertas tareas de
limpieza en el sistema, tal como el borrado de spool requests obsoletos o el
procesamiento de información estadística y de monitoreo.

Figura 130 – Planificación de Jobs Estándar

En la transacción de definición de jobs (SM36), puedes acceder a una selección de jobs
estándar importantes que puedes planificar, monitorear y editar seleccionando
Standard Jobs.
Si queremos planificar todos los jobs estándar, seleccionamos Default Scheduling.
Todos los jobs estándar que están definidos en la tabla REORGJOBS son planificados
con una variante y período específico.
Para planificar jobs individuales, selecciona el job y especifica el período de ejecución.
Para definir un job estándar adicional que no está disponible en la selección (tabla
REORGJOBS), podemos seleccionar Predefine new job.
Para información sobre jobs estándar, podemos consultar las notas 16083 –
Standard Jobs, reorganization jobs y 1034532 – Changes for standard jobs.

Planificación Basada en Eventos
Un evento es una señal para el sistema de procesamiento en background que indica
que un estado particular se ha alcanzado en el sistema SAP. El sistema de
procesamiento en background recibe eventos y luego inicia todos los jobs que están
vinculados a este evento.

Figura 131 – Inicio de Jobs Dependiente de Eventos

Un job dependiente de evento puede ser planificado con una de las siguientes
condiciones de inicio:
Luego de un Evento: El job inicia después de que un evento definido en el sistema
SAP es recibido.
Modo de Operación: Con esta opción, puedes vincular un job a la activación de un
modo de operación cuando planificamos el job.

Luego de un Job: De esta manera, podemos crear cadenas simples de jobs donde la
ejecución del job sucesor pude ser dependiente del estado con el que finalizó el job
predecesor.
Eventos
Nuevos eventos son definidos por el administrador de sistema en CCMS, transacción
SM62. Cuando se hace esto, el administrador diferencia entre eventos de sistema y
eventos de usuario. Los eventos de sistema son predefinidos por SAP y no deberíamos
modificar o disparar.

Figura 132 – Definición y Disparo de Eventos

Los eventos pueden ser disparados de diferentes formas:
Manualmente en CCMS para propósitos de prueba (transacción SM64).
Con un programa ABAP, mediante el uso del módulo de función BP_EVENT_RAISE o
el método RAISE de la clase CL_BATCH_EVENT.
Fuera del sistema SAP a nivel del sistema operativo usando el programa sapevt.
Un parámetro puede también ser transferido cuando un evento se dispara. De esta
manera, podremos definir jobs que esperan por la ocurrencia del evento junto con el
parámetro específico. También podemos acceder al Historial de Eventos en la
transacción SM62.
La sintaxis del programa sapevt es:
sapevt <parameters>
<Parameters> are multiple individual switches based on:
{<EventID> | event=<EventID>} [{-p <EventParam>} | param=<EventParam<´>]
[-t[0|1|2][a]]
[-v]
{[name=<SystemName>] [msserv=<MsServ>]
[mshost=<MsHost>] [pf=<Profile>]}
{[timeout=<TimeOut>]}
[-? | /? | -help | /help]

La nota de SAP 802172 explica los parámetros en detalle.
La salida de sapevt se escribe a un archivo de traza dev_evt. Para que pueda
reaccionar a eventos externos, el sistema SAP debe estar activo. De otra manera, un
evento que se haya disparado por un programa externo se pierde.
Un ejemplo de ejecución del programa
event=NUEVO_ARCHIVO_INTERFAZ
name=DEV

sapevt podría ser: sapevt
mshost=twdf5000.wdf.sap.corp.

Si el nombre del evento contiene espacios, deberemos utilizar comillas (“”) cuando
llamamos
al
programa
sapevt.
Por
ejemplo:
sapevt
"MY EVENT" name=QAS mshost=twdf9999.wdf.sap.corp

Lección 6: Otros Temas de Procesamiento en Background
Reserva para Jobs de Clase A
En la operación normal, cada work process de background procesa jobs de todas las
prioridades. De todas formas, podemos reservar tantos work processes de background
configurados como deseemos para jobs de prioridad alta, o sea, jobs de clase A.
La reservación de work processes para jobs de clase A no reserva ningún work process
en particular. Más bien, el sistema asegura que una cantidad determinada de work
processes de background se mantengan libres. Los jobs de clase B y C pueden
solamente ser iniciados si el número definido de work processes para posibles jobs de
clase A se mantiene libre.

Figura 133 – Reserva de Jobs de Clase A

Para configurar el número de work processes de background de clase A tendremos que
configurar los modos de operación en la transacción RZ04. Cuando hacemos esto,
tendremos la opción de reservar work processes de background.
Si la carga de jobs de clase A es pequeña, o cuellos de botella raramente ocurre en el
procesamiento de background, en otras palabara, al menos un work process de
background casi siempre se encuentra libre, la reserva de work processes para jobs de
clase A probablemente no ofrezca ventajas. En este caso, la reservación simplemente
significará que un work process es muy poco utilizado (solo por jobs de clase A).

SAP recomienda que no reservemos más de un work process de background para el
procesamiento de jobs de clase A por cada instancia del sistema. Con esto usualmente
es suficiente para un escenario de planificación de jobs de background.
Objetivos de Ejecución
Solamente instancias con work processes de background o un grupo de servidores de
job puede ser utilizado para planificar la ejecución de jobs con instancias o grupos
específicos.
Un grupo de servidores de job contiene una o más instancias con work processes de
background. Los grupos de este tipo pueden ser utilizados de la misma forma que los
grupo de logon para usuarios de diálogo. También es posible procesar tareas de
background en instancias seleccionadas.

Figura 134- Ejecución en instancias o grupos de servidores de job

Podemos configurar un grupo de servidores de job en la transacción SM61 (menú
Tools CCMS → Background Processing → Background Objects). Aquí podremos definir
grupos de servidores con work processes de background asignando las instancias que
formarán el grupo.
Usuarios de Background
Con la clásica definición de jobs utilizando la transacción SM36, podemos asignar cada
paso de un job a un usuario (observar la Figura 135). El usuario especificado es
utilizado para las verificaciones de autorización durante la ejecución del paso. Por
defecto, el nombre del usuario que está definiendo el job aparece, y el job luego será
ejecutado usando las autorizaciones que ese usuario tenga.
Si el job no debería ejecutarse usando las autorizaciones de ese usuario, podemos
ingresar un usuario diferente. Para poder hacer este cambio, deberemos contar con la
autorización pertinente S_BTCH_NAM para poder ingresar otros usuarios diferentes al
nuestro en el campo User en la definición del paso.

Figura 135 – Usuarios de Background

Es útil configurar usuarios de background para varias áreas de trabajo que cuenten con
las autorizaciones necesarias para las actividades que se requieran, y que puedan ser
usadas por usuarios con las mismas autorizaciones para planificar jobs de background
en esta área de trabajo, tal como la administración de sistema. Los usuarios de
background tienen registros maestros de usuario que cuentan específicamente con
autorizaciones para el procesamiento de background.
El tipo de usuario de Sistema (System) debe ser elegido cuando creamos usuarios de
background. Un logon al sistema de diálogo no es posible con este tipo de usuarios. De
la misma manera, los usuarios de este tipo están exentos de la configuración de
validez de las contraseñas. El administrador de sistema solo puede cambiar la
contraseña mediante la transacción SU01.
Si en cambio usamos el Asistente de Jobs para la creación de los mismos, no tenemos
la posibilidad de definir un usuario diferente para cada paso del job.

Utilización de Programas Externos
El sistema de procesamiento en background diferencia entre comandos externos para
usuarios normales y programas externos para los administradores de sistema. El
propósito de esta diferenciación es darle a los administradores del sistema la
posibilidad de ejecutar cualquier programa externo que requieran, mientras que los
usuarios normales están restringidos al uso de comandos externos para los cuales hay
verificaciones de autorización. En ambos casos, el programa sapxpg es invocado a
nivel del sistema operativo e inicia el programa relevante en el sistema operativo.

Figura 136 – Utilizando Programas Externos

Los Comandos Externos son commandos o programas del host predefinidos en el
sistema SAP por el administrador. Estos están protegidos por autorizaciones por lo que
los usuarios normales pueden solamente planificar los comandos para los cuales el
administrador les ha asignado las autorizaciones necesarias. De esta manera, podemos
proveer de funciones fuera del sistema SAP, a nivel del sistema operativo, a los
usuarios del sistema SAP.
Los Programas Externos son comandos sin restricciones que no son predefinidos o
restringidos por autorizaciones. Un usuario que tenga autorizaciones de administrador
puede ingresar un programa externo en un paso de un job. Ninguna verificación de
autorización SAP se lleva a cabo antes de la ejecución del comando. Los programas
externos proveen al administrador la flexibilidad para ejecutar cualquier comando en el
sistema operativo en el sistema SAP sin preparación previa.
Un administrador de sistema debe contar con autorizaciones para el objeto
S_RZL_ADM: Administrador de Procesamiento en Background.

Figura 137 – Definición y Uso de Comandos Externos

La creación de comandos externos requiere de los siguientes pasos:
1. Llamar a la transacción SM69.
2. Seleccionar Create.
3. Realizar las entradas en el nuevo comando.
Los comando externos son identificados unívocamente con un nombre, comenzando
con Z o Y, y un tipo de sistema operativo. El campo Type se completa
automáticamente.
Especificar un comando ejecutable del sistema operativo (si es necesario con la ruta
completa) y especificar cualquier parámetro requerido u opcional.
Seleccionar el cuadro de verificación (checkbox) Additional Parameters Allowed si los
usuarios podrán especificar parámetros adicionales cuando ejecutan el comando
externo. Los parámetros adicionales son agregados en una cadena de parámetros
especificados bajo el campo Parameters for Operating System Command.
El campo Trace debería dejarse en blanco usualmente. Para seguir la ejecución de un
comando externo, utiliza el parámetro de traza para el módulo de función
SXPG_COMMAND_EXECUTE.
Si se ha definido una verificación adicional de autorización, ingrese el nombre del
módulo de función que realiza la verificación en el campo Check Module. Este es
usualmente una copia del módulo de función SXPG_DUMMY_COMMAND_CHECK. El
sistema llama al módulo de función automáticamente si un usuario intenta ejecutar el
comando externo o lo planifica en un paso de job de background.
4. Guarda el comando. Para regresar a la vista de comandos, selecciona Back.

Indicadores de Control (Control Flags)
Es posible realizar especificaciones sobre la tarea y otras opciones de ejecución usando
indicadores de control. Usualmente no es necesario cambiar los valores por defecto.
Por ejemplo, podemos especificar:
Si el proceso va a ser registrado.
Si Los datos de salida se escriben al log del job tal como son devueltos por el
programa externo. También es posible registrar información adicional sobre el
programa externo en el log del job.

Figura 138 – Indicadores de Control para Programas o Comandos Externos

Otro indicador es si el paso del job espera por la finalización del programa externo.
En el caso de que después de que hemos iniciado un servicio con el sistema de
procesamiento en background, tal como un demonio en UNIX o un servicio en
Windows, el programa se mantiene activo luego del inicio. Estos programas iniciados
como servicio o demonios no devuelven el control al sistema de procesamiento en
background de SAP, como en el caso de otros programas. Si iniciamos un programa
mediante un servicio, no deberíamos utilizar el indicador de control Job waiting for ext.
Termination cuando planficamos el paso del job.

Lección 7: Monitoreo de Sistema
La infraestructura de Monitoreo de Alertas - Permite realizar un monitoreo eficiente de
los sistemas SAP

Recolección de Datos --> Cada subarea y componente de un sistema sap es
monitoreado por un programa llamado recolector de datos, el cual chequea ciertos
intervalos su componente y almacena la información obtenida en la memoria principal
de la Instancia.
Almacenamiento de Datos --> el área de la memoria q almacena toda la información
se conoce como segmento de monitoreo, esta area es continuamente sobrescrita, los
datos se copian a la BD para poder ser analizados posteriormente
Administración de Datos --> Los datos obtenidos en el monitoreo de segmento son
analizados y evaluados tx - RZ20 Herramienta de visualización
TX RZ20

Sap provee un set de monitores los cuales ya viene incluidos, dentro de un set de
monitores se encuentran los monitores q este contienen, estos ofrecen diferentes
vistas de los objetos de monitoreo de un sistema

Una vez q se ingresa al monitor se accede a las vistas de elementos del árbol de
Monitor (MTE)

Cada nodo del árbol es un MTE lo cuales nos permiten organizar a los objetos de
monitoreo dentro de categorías para facilitar la búsqueda y visualización de los objetos

Luego en las hojas del árbol se encuentran los atributos del objeto de monitoreo

Estos atributos son propios de cada objeto y almacenan los valores y almacenan los
valores recolectados por los programas recolectores de datos

Haciendo doble clic al atributo que indica alguna alarma se ingresa al método de
análisis

Las alertas se propagan si es severa por los niveles superiores del árbol, rojo es más
severo q amarillo.

Cada atributo tiene una serie de propiedades para ajustar la generacion de alarmas a
los requerimientos

En los atributos de performance es donde se definen los valores que generaran las
alarmas de advertencia

Para poder configurar propios set de monitores se debe activar la función de
mantenimiento

Luego de asignar los objetos, se da guardar para asignar un nombre

Luego de finalizar se desactiva la función de mantenimiento

Se pueden revisar que alarmas están abiertas

En el árbol se puede visualizar las alarmas q están pendientes por análisis

Haciendo doble clic sobre el atributo se verán las alarmas pendientes

Luego de q esta determinada la causa y efectuar la corrección se marca como alarma
completa para que vuelva el indicar al estado normal.

Administración Avanzada de Clientes
Lección 1: Concepto Copia y Transporte de Clientes

Las copias de clientes pueden reemplazar datos en un cliente nuevo o en uno ya
existente.
Ingresar a la TX – SCC4
Para crear un nuevo cliente

Una vez creado el cliente, se ingresa a este mismo con el usuario SAP* y la contraseña
pass

Siempre que se crea un nuevo cliente, debe realizarse una copia desde un cliente de
referencia, puede ser local o remoto:
Copia Local entre clientes – en la copia local los datos se leen y se escriben en la
misma BD, para todos los tipos de copias siempre la ejecución debe realizarse en el
cliente destino, se debe seleccionar desde que cliente se quiere realizar la copia, para
el caso de un nuevo mandante es recomendable realizar la copia desde el cliente 000
del sistema.
Ingresar a la TX – SCCL

Luego debe elegirse el perfil para la copia, es decir que datos se copiaran desde el
cliente origen hacia el nuevo cliente

Por último se observa la verificación antes de iniciar la copia donde se verán los datos
del cliente destino, el perfil utilizado y el cliente origen, así también como un detalle de
los datos que serán copiados según el perfil utilizado

Se podrá observar el progreso y los logs de la copia de mandante en la TX – SCC3

En la TX- Scc3 se puede ver no solo los logs del cliente en el que estamos logueados,
si no también todos los clientes del sistema

Desde acá se podrá ingresar al detalle de los logs de las copias de los otros
mandantes, es importante que mientras una copia este en ejecución no se trabaje ni
en el cliente destino ni tampoco en el cliente origen

En el detalle, se podrá ver el estado del progreso de la copia, la acción actual que se
está realizando y las estadísticas para la ejecución

Con el monitor se puede observar de forma gráfica el progreso de la cantidad de tablas
copiadas así también como el tiempo

Con el detalle se puede analizar exactamente cada objeto que ha sido copiado desde el
cliente origen.

En la TX SM37, se puede observar el progreso del job en ejecución

En la copia de cliente remota previamente a iniciar la copia, el sistema realizara una
verificación de consistencia mediante las conexiones RFC

En el mandante destino desde la TX – SCC9, se realizara la copia remota de clientes,
se selecciona un perfil, se debe tener en cuenta que si copiamos datos cross-client se
podría afectar el resto de los mandantes que puedan existir en el sistema destino

Se debe seleccionar también una conexión RFC que tenga un usuario con las
suficientes autorizaciones para realizar la copia desde el sistema origen

Tanto en la copia local como remoto, podemos seleccionar la cantidad de procesos en
paralelo para la ejecución, esto puede ayudar a reducir los tiempos de la copia

En la TX- SCC3, ver los logs de la copia

Se puede observar la acción de cada uno de los procesos escogidos

Otra opción para la copia es la exportación e importación, mediante la TX- SCC8 se
exportara el cliente desde un sistema origen y luego con el sistema de transporte se
importara en el sistema destino

Se debe seleccionar un perfil para la exportación, dependiendo del perfil seleccionado
podremos generar hasta 3 archivos en el directorio de transportes del sistema origen,
tenemos que tener en cuenta contar con el suficiente espacio para la exportación

También la información del sistema destino y el mandante destino, esta información
será utilizada por el sistema de transportes luego para la importación
La ventaja de este método es reproducible, una vez que exportamos el cliente se
podrá importarlo en el mandante las veces que sea necesario, lo que es muy útil para
un mandante que se usa de entrenamiento el cual podría actualizarse una vez por
semana por ejemplo

En la copia remota como en la exportación podremos verificar de ante mano la
consistencia con el sistema destino

Debemos contar con una conexión RFC al sistema destino

El resultado del chequeo de consistencias, podría advertir por ejemplo que exista una
tabla con diferentes estructuras en el sistema origen y en el sistema destino

Antes de iniciar el proceso de exportación, se podrá verificar los datos que se han
seleccionado, tener en cuenta que para este caso se utilizaran las herramientas del
sistema transporte tal como el programa de transporte tp

Una ventana de información indicara que hasta 3 archivos se podrán generar
dependiendo del perfil seleccionado, básicamente si se selecciona exportar datos crossclient desde el sistema origen, un tercer archivo se generara en el directorio de
transportes

Al importar el mandante en el sistema destino, se utilizara la herramienta STMS, luego
se debe realizar un post-procesamiento con la TX SCC7 en el mandante destino

Lección 2: Comparación de Clientes
Usando la Herramienta de Comparación de Clientes
Cuando varios sistemas SAP y clientes están siendo implementados, podría ser
necesario comparar y ajustar el customizing entre diferentes sistemas y clientes. La
función de comparación permite comparar y ajustar el contenido de una tabla o vista
en dos clientes diferentes, mediante conexiones RFC.

Figura 138 – Comparación de Clientes

Para usar la función de comparación de clientes, desde la pantalla inicial de SAP,
ingresa a la transacción SCU0.
Podemos usar esta función para comparar:
Un cliente con un cliente de referencia, tal como un cliente creado por nosotros o el
cliente de SAP 000. Esto es especialmente útil después de un Upgrade o Importación
de Lenguaje, ya que solamente el cliente 000 es provisto con datos de las tablas
perteneciente a la clase de entrega CC.
Comparar clientes durante un escenario de rollout. Por ejemplo, si las subsidiarias
quisieran ajustar sus customizing con respecto al customizing de referencia de un
Cliente Maestro.
Comparar el customizing cross-client de distintos sistemas antes de combinar
diferentes clientes en un mismo sistema en un escenario de roll-in. Por ejemplo, si las
subsidiarias quisieran recibir los cambios de customizing desde un cliente de
referencia, cliente maestro de la organización superior.

Figura 139 – Comparación de Clientes: Opciones de Selección

Para seleccionar los objetos a ser comparados en una comparación de clientes,
podemos usar un método orientado a proyecto utilizando el IMG para definir los
objetos. También podemos seleccionar desde los componentes de aplicación, listas de
objetos y órdenes de transporte. También podemos elegir objetos manualmente.
Para iniciar la comparación, utiliza la transacción SCU0 y el procesamiento en
background. La transacción primero muestra un resumen de las tablas que pertenecen
a vistas para el IMG, componente de aplicación u orden de transporte seleccionado.
Luego de la comparación, el sistema crea una lista de las diferencias e indica si estas
diferencias se encuentran en la estructura de las tablas o en el contenido. Para
visualizar la diferencia de las entradas, selecciona un objeto. Esto permite realizar una
comparación detallada.

La comparación de cliente es generalmente con otro sistema, por lo que en estos casos
necesitaremos acceder mediante una RFC.
Para más información sobre comparación de clientes, puedes consultar la Nota de
SAP 91096
Los resultados de cada comparación es un resumen de las diferencias que existen
entre el cliente donde nos encontramos y el cliente seleccionado para la comparación.
Este resumen sirve como un punto de inicio para continuar con el análisis de las
diferencias. El resultado de la comparación es almacenado en una lista de trabajo o de
diferencias.
Usando la Herramienta de Mantenimiento de Clientes
Por cada objeto que es comparado, se lista con una descripción en la salida de la
comparación. La información más importante es el indicador de estado. El indicador de
estado informa la existencia y naturaleza de cualquier diferencia.
El estado de procesamiento nos permite distinguir entre los objetos que han sido ya
procesados o tratados, o sea, que han sido ajustados para igualarse entre ambos
clientes y aquellos que todavía no. Este tipo de procesamiento se conoce también
como ajuste del objeto. El estado de procesamiento se indica por un pequeño
semáforo, donde rojo indica que no ha sido ajustado, amarillo significa que se está
realizando el ajuste y verde que se ha completado.
Una breve explicación sobre el estado de comparación y el estado de procesamiento se
puede obtener mediante el ícono Legend.

Figura 140 – Ajustando Objetos de Customizing

Podemos ajustar un objeto por vez. Estos objetos que pueden ser ajustados son
algunas de las tablas o vistas que pueden mantenerse a través de la transacción
SM30. Todos los demás objetos solo pueden ser comparados.
Para realizar un ajuste, desde la pantalla Comparison, selecciona Edit Interact Copy.
La pantalla Overview Adjustment se visualiza, mostrando el detalle de las diferencias
entre los dos clientes, registro por registro. A la izquierda de cada registro en esta lista
de trabajo se encuentra el estado de comparación, el cual inidica si cada entrada de
registro existe en el cliente comparado y en el cliente donde nos encontramos.

Figura 141 – Configuración de Cliente

La opción de cliente Protection: Client Copier and Client Comparsion Tool puede ser
utilizada para prevenir que un cliente sea sobrescrito por una copia de cliente o una
comparación y ajuste de cliente. También puede asegurar que los datos sensibles no
puedan ser visualizados desde otro cliente durante una comparación.
Para seleccionar esta opción desde la transacción SCC4, seleccionamos uno de los
niveles de protección:
Nivel 1: No overwriting
Este nivel de protección asegura que el cliente no puede ser sobrescrito por el
programa de copia de cliente. Esta opción debería utilizarse si en el cliente se realiza
customizing o el cliente contiene configuraciones críticas o datos que no deberían
sobrescribirse.
Nivel 2: No overwirting and no external availability
Este nivel de protección también protege contra la sobrescritura del cliente y contra el

acceso a lectura desde otro cliente durante una copia de cliente o una comparación de
customizing. Esta configuración debería utilizarse si el cliente contiene datos sensibles.
Todos los clientes productivos deberían tener esta opción.

Importación de Ordenes de Transporte
Para configurar el landscape de sistemas, es suficiente contar con un sistema SAP, tal
como el de desarrollo; el sistema de calidad y producción no son requeridos en esta
etapa. También deberemos crear un directorio de transportes a nivel del sistema
operativo, si es que estará ubicado en un servidor distinto del primer sistema que
instalemos. Este directorio es requerido por TMS.

Dependiendo del sistema operativo, el directorio de transportes global y todos los
subdirectorios necesarios podrían ser creados automáticamente durante la instalación
del sistema SAP (ver la guía de instalación para el sistema SAP para más detalles).
Los transportes nos permiten sincronizar el Customizing y los desarrollos en múltiples
sistemas SAP a través de la transferencia de los cambios realizados desde el sistema
de desarrollo a los sistemas subsiguientes. Los transportes a través de las rutas de
transportes deben ocurrir solo en una dirección.

Conceptos y Terminología de TMS
Los conceptos detrás de TMS (Transport Management System):
Configuración centralizada del Sistema de Cambios y Transportes (CTS) para todos los
sistemas SAP.
Gestión centralizada de órdenes de transportes y del proceso de importación.
Estrategia de transportes basada en rutas de transportes predefinidas.
TMS
El propósito de TMS, el cual se accede mediante la transacción STMS, es controlar de
forma central la propagación de los cambios a través de los sistemas del landscape
basado en caminos predefinidos. Esto está diseñado para asegurar la consistencia del
repositorio de SAP y el contenido de las tablas de Customizing en todos los sistemas
del landscape.
Con TMS podemos:
Definir el rol de un sistema SAP dentro de un landscape de sistemas o un dominio de
transportes.
Configurar las rutas de transportes mediante un editor o usando configuraciones
estándar.
Configurar los parámetros del programa de transportes tp
Visualizar las colas de importación de todos los sistemas en el dominio de transportes.
Definir los procedimientos de aseguramiento de calidad y aceptación de cambios en el
sistema de QA.
Planificar la importación de órdenes de transportes en una cola de importación.
Dominio de transporte
Un dominio de transportes consiste de todos los sistemas que planeamos manejar
usando el mismo TMS. Dentro de un dominio de transportes, todos los sistemas deben
tener un ID de sistema (SID) único y solo uno de estos sistemas es identificado, o
mejor dicho tiene el rol, de controlador de dominio (de transportes).
El controlador de dominio de transportes es el sistema donde todas las configuraciones
de TMS se mantienen. Cualquier cambio en la configuración es distribuida a todos los
sistemas en el landscape. Esto asegura que todas las configuraciones de TMS son
consistentes a través de todo el dominio. El controlador de dominio almacena la
configuración y todos los otros sistemas reciben una copia de esta configuración.
Un dominio de transportes contiene al menos un grupo de transportes. Más simple, un
grupo de transporte consiste de uno o más sistemas que comparten un directorio de
transportes común. Las siguientes figuras muestran la relación entre un dominio de
transporte y un grupo de transportes.

Los sistemas dentro de un dominio de transportes se comunican cada uno con otro
usando funciones de llamadas remotas (RFC). La comunicación RFC necesita un ID de
usuario para acceder a los sistemas destinos. Cuando los sistemas se agregan a un
dominio de transportes, los destinos RFC necesarios y los ID de usuarios son
automáticamente configurados por la herramienta TMS. La configuración de dominio
se distribuye a través del dominio usando la comunicación RFC.

Los cambios en la configuración del dominio de transportes se realizan en el
controlador de dominio. Cada vez que hacemos un cambio, una ventana se muestra
consultando si los cambios deben ser distribuidos inmediatamente a los sistemas del
dominio. Podemos distribuir varios cambios en una sola vez.
Estableciendo un Dominio de Transportes
Para configurar un dominio de transportes, primero determinaremos cuales sistemas
serán incluidos en el dominio. El domino de transportes debería contener todos los
sistemas de todos los landscapes de sistemas que serán administrados centralmente
mediante TMS.
La configuración de TMS puede desglosarse en tres pasos individuales.

1. La configuración del dominio de transportes que define los sistemas que serán
incluidos en el dominio.
2. La configuración de las rutas de transportes que define los roles de los sistemas
(y clientes) dentro del o los landscapes.
3. La configuración del procedimiento de QA que define quien será responsable
para la aprobación y aceptación de cambios y la promoción de los mismos a los
sistemas de delivery subsiguientes.

Inicializando el Controlador de Dominio de Transportes
El primer sistema que configuramos es automáticamente seleccionado como el
controlador de dominio pero más tarde podemos cambiar el rol del controlador de
dominio a un sistema diferente.

SAP recomienda que el sistema que seleccionemos para el rol de controlador de
dominio tenga los siguientes atributos:
Alta disponibilidad
Alta seguridad
Alto nivel de mantenimiento
Por lo tanto, un sistema de producción podría ser ideal para ser el controlador de
dominio. Como los sistemas de desarrollo usualmente son instalados antes del sistema
de calidad o producción, en la práctica es común configurar el sistema de desarrollo
como el controlador de dominio y luego mover la asignación al sistema de producción.

Cuando usamos TMS por primera vez luego de la instalación del sistema,
automáticamente nos solicitará configurar TMS.
Cuando inicializamos TMS, las siguientes acciones se llevarán a cabo automáticamente
por el sistema SAP:
Un grupo de transportes es creado con el nombre GROUP_<SID>.
En el cliente 000, el usuario de comunicación TMSADM es creado.
Los destinos RFC necesarios para TMS son generados.
El archivo de configuración DOMAIN.CFG es almacenado en el subdirectorio bin del
directorio de transportes. Este archivo contiene el nombre del dominio de transportes y
la descripción así también como el nombre del host de controlador de dominio, número
de instancia, SID y grupo de transportes.
El perfil de transporte para el programa de control de transportes tp se genera y se
almacena en el subdirectorio bin bajo el nombre TP_<DOMAIN>.PFL.
Los parámetros en este perfil se mantienen usando la transacción STMS.
El nombre del domino de transportes no debe contener espacios en blanco y no puede
ser modificado después sin reconfigurar el controlador de dominio. Por defecto el
dominio de transportes tendrá el nombre DOMAIN_<SID>, donde <SID> es el ID de
sistema del controlador de dominio.
El programa de control de transportes tp require un perfil de transporte que contenga
información sobre cómo establecer la conexión a la base de datos de todos los
sistemas SAP en el dominio de transportes. TMS genera y gestiona este perfil de
transportes como una parte de la configuración del dominio de transportes. No
debemos modificar el perfil de transportes usando un editor de textos en el sistema
operativo.

Para visualizar los parámetros de tp en un sistema SAP, llamamos a la transacción
STMS. Selecciona Overview
Systems. Marca uno de los sistemas y selecciona SAP
System Display. Selecciona la solapa Transport tool. Desde el menu, selecciona Goto
Display.

Configuración de las Rutas de Transporte y Verificaciones
Las rutas de transportes indican el rol de cada sistema y el flujo de las órdenes de
transportes. Las rutas de transportes son lo que definen el landscape de sistemas.
Aunque TMS ha sido inicializado, no es posible aún realizar transportes hasta que las
rutas de transportes hayan sido configuradas y distribuidas.
Después de establecer el dominio de transportes, necesitaremos:
1. Modelar las rutas de transportes desde el controlador de dominio, usando:
a. Configuraciones estándar (uno, dos o tres sistemas)
b. Editor gráfico para configuraciones no estándar
2. Distribuir y activar la nueva configuración para todos los sistemas SAP dentro del
dominio de transportes.
Para reducir el trabajo para especificar las rutas de transportes, podemos usar las
configuraciones estándar. Las rutas de transportes se generan automáticamente
cuando seleccionamos los sistemas y la configuración para uno, dos o tres sistemas.
Capas y Rutas de Transportes
Como mencionamos anteriormente las rutas de transportes definen el flujo de las
órdenes de transportes desde un sistema a otro. Estas rutas se denominan de
consolidación o de entrega o reparto (delivery).

Una ruta de consolidación es una ruta de exportación/importación. Típicamente, la ruta
de consolidación procede desde el sistema de desarrollo (desde donde las órdenes de
transportes son exportadas) al sistema de calidad (donde las órdenes de transporte
son importadas) en un landscape estándar de tres sistemas.
Una ruta de reparto es otra ruta de importación. En el landscape de tres sistemas, la
ruta de reparto se especifica entre el sistema de calidad y el sistema de producción
porque no hay una exportación desde el sistema de calidad pero si una importación al
sistema de producción.
El customizing y los objetos de respositorio son asignados a una ruta de consolidación
específica mediante una capa de transportes. En el directorio de objetos SAP, el cual es

el catálogo de todos los objetos, están agrupados dentro de unidades lógicas llamadas
paquetes, formalmente conocidos como clases de desarrollo.
La definición de cada paquete contiene una asignación a una capa de transportes. Los
objetos, a través de la asignación del paquete, indirectamente son asignados a la capa
de transportes.
Todos los objetos entregados por SAP están asignados a la capa de transportes SAP.
Todos los objetos de customizing y los objetos de desarrollo que vayan a ser
transportados por la ruta de transportes son asignados a otras capas de transportes,
estas capas de transportes son normalmente denominadas Z<SID>, donde <SID>
corresponde al ID del sistema de desarrollo.
En el contexto de las rutas de transporte, un sistema SAP puede tomar los siguientes
roles:
Sistema de Integración: el sistema donde se originan los cambios y son asignados a las
órdenes de transportes. Es el punto donde las modificaciones de “cliente” se integran
con el estándar de SAP.
Sistema de Consolidación: el sistema destino de una ruta de consolidación.
Sistema de Entrega o Reparto: es el o los sistemas destino de una ruta de entrega o
reparto.

Necesitaremos configurar más capas de transporte si nuestro landscape es más
complejo y también si necesitamos redirigir la ruta de ciertos objetos si no usarán la
ruta de transportes estándar.
Por ejemplo, si un sistema de entrenamiento separado existe y hay ciertos programas
que serán ejecutados allí pero no queremos que esos programas lleguen al sistema de
calidad o producción.

Configuración Básica de TMS
Ingresar a la tx STMS

Para realizar la configuración del TMS se debe ingresar al cliente 000 en el controlador
de dominio y la TX STMS, al no estar configurado el sistema de transporte, se obtendrá
una ventana donde solicitara información del sistema donde estamos realizando la
configuración y el dominio de transporte que estamos creando para nuestro sistema
de transportes ya que para el ejemplo práctico este sería el primer sistema instalado,
se tomara los valores propuestos

Una vez que se guarde la configuración, se empezara a trabajar con la tx STMS

Desde esta vista podrá observarse todos los sistemas que integran nuestro dominio de
transporte

Para proseguir con la configuración, se creara sistemas virtuales dentro del dominio

Con el sistema virtual podrá configurarse todos los sistemas de transporte sin la
necesidad de tener los demás sistemas realmente instalados
Se crea el sistema de QAS y PRD

Ya se tiene todo el landsacpe con los sistemas necesarios

Ahora veremos las rutas de transportes

Pasamos a la visualización del editor grafico

Desde acá se configuraran las rutas de transportes entre los tres sistemas

Arrastramos DEV y luego damos doble clic sobre QAS y PRD para añadirlos en el
entorno grafico

Una vez colocado los tres sistemas, empezaremos con la creación de las rutas

Primero se dibuja la ruta que va desde DEV a QAS

La ruta desde un sistema de desarrollo y calidad es de tipo consolidación, este tipo de
ruta se otorga a los sistemas desde donde se liberan las órdenes de transporte y el
próximo sistema donde se importaran

En la ruta de consolidación también debemos elegir la capa de transporte, por lo
general son dos; una capa llamada SAP para los objetos estándar de sap y otra capa
llamada ZDEV dependiendo del nombre que tenga el sistema de desarrollo para los
objetos propios

Agregamos la ruta de transporte de consolidación con la capa de transporte Z<SID> O
ZDEV para todos los objetos que sean creados para en el sistema de desarrollo

Ahora creamos la ruta entre QAS y el sistema de Producción, en este caso es de
entrega o Delivery esta ruta se utilizan entre los sistemas en los cuales ambos realicen
importaciones de ordenes de transporte

Luego de configurar el sistema de transporte, se guardan los cambios

Otra opción de configurar el sistema de transportes

Sap provee las configuraciones predeterminadas para landscapes de 1,2 o 3 sistemas

En este caso solo se debe indicar cuales son los sistemas de desarrollo, calidad y
producción

Luego el sistema generara automáticamente la ruta ente los tres sistemas

Guardar

Lección 1: El Proceso de Transportes
Como administradores del sistema SAP, deberemos asegurarnos el correcto
movimiento de cambios a través del landscape de sistemas mediante el curso del
proceso de transportes.
Pasos en el Proceso de Transportes

Figura 142 – Resumen: Estrategia de Transportes

En las versiones anteriores a 3.1H, los transportes se realizaban a nivel del sistema
operativo. Con la introducción del Sistema de Gestión de Transportes (TMS), los
transportes se realizan desde el mismo sistema SAP.
En el TMS, las órdenes de transportes son transportadas a lo largo de rutas de
transportes predefinidas. Ya vimos anteriormente que podemos definir múltiples rutas
de consolidación o de entrega. El procedimiento de importación puede ser realizado
por cualquier usuario que tenga las autorizaciones desde el sistema SAP sin que se
necesite acceso al sistema operativo. Sin embargo, casi todas las funciones en la
transacción STMS son ejecutadas por comandos del programa tp en el sistema
operativo, que con cierto nivel de conocimiento técnico podríamos llegar a realizar
manualmente en algún caso necesario.
Las órdenes de transporte que están pendientes de importación se visualizan en la cola
de importación del sistema destino desde cualquiera de los sistemas SAP que
conforman el dominio de transportes.
Usando TMS podemos importar completamente la cola de importación, esto es, todas
las órdenes de transporte que fueron exportadas desde el sistema de desarrollo. Esto
asegura que ningún error de importación ocurra debido a objetos faltantes y que las
últimas versiones de un objeto no sean sobrescritas por versiones anteriores.

Liberación y Exportación

Figura 143 – Proceso de Transporte: Liberación y Exportación

El primer paso en el proceso de transportes es liberar una orden de transporte y por
consiguiente exportar todos los objetos asociados desde la base de datos del sistema
de desarrollo (DEV) a archivos en el directorio de transportes común a nivel del
sistema operativo.
Para cada orden de transporte, los datos son exportados a un archivo de datos en el
subdirectorio data y un archivo de control es creado en el subdirectorio cofiles.
Durante la exportación, las entradas necesarias para la importación siguiente son
creadas en el buffer de importación del sistema destino, y una importación de prueba
puede realizarse.
En el directorio buffer, en el sistema operativo, hay una buffer de importación para
cada sistema SAP en el dominio de transportes. El archivo tiene el nombre del sistema
SAP al que pertenece (DEV, QAS, PRD, etc.) y contiene información de control respecto
a que órdenes de transporte deben ser importadas y en qué orden.
Varios comandos de control de transporte pueden utilizarse para manejar los archivos
de buffer de importación en el sistema operativo. La información de control en los
archivos de buffer de importación es leída y representada como las colas de
importación accedidas desde el sistema SAP. Una cola de importación muestra todos
las órdenes de transportes que están contenidas en el buffer correspondiente.

Figura 144 – Proceso de Transporte: Importación en QAS

Usando TMS desde el sistema SAP, el segundo paso en el proceso de transportes es:
importar todas las órdenes listadas en la cola de importación del sistema de calidad
(QAS). TMS realiza la importación iniciando el programa de control de transportes tp
en el sistema operativo.
Después que las órdenes de transportes se han importado correctamente en el sistema
de QAS, las órdenes se agregan en el buffer de importación (con estado inactivas si es
que el procedimiento de QA está implementado) y la cola de importación del sistema
de producción (PRD) y cualquier otro sistema de entrega según la ruta de transporte.

Figura 145 – Proceso de Transporte: Aseguramiento de Calidad

Después de importar en el sistema de QAS, los objetos necesitan ser testeados por
posibles errores. Los errores deben ser corregidos en el sistema de desarrollo, y los
cambios importados nuevamente (con una orden de transporte nueva por supuesto)
en el sistema de QAS. Durante la importación en QAS, la orden o las órdenes de
transportes adicionales son agregadas al buffer de importación del sistema de
producción.

Figura 146 – Proceso de Transporte: Importación en PRD

Después que todas las órdenes de transporte que fueron importadas en QAS han sido
testeadas y verificadas, las órdenes deben ser aprobadas (si el procedimiento de QA
está activo). El estado de la entradas cambian de inactivas a activas y las órdenes de
transporte están listas para importar en el sistema PRD.

Usando TMS, podemos importar todas las órdenes de transporte, o simplemente un
primer conjunto de las órdenes que fueron verificadas que se encuentran en la cola de
importación en la secuencia que se presentan.
Para asegurarnos que no haya ningún efecto negativo en las actividades de
producción, debemos asegurarnos que los errores y las correcciones se importen en el
orden correcto, o sea, respetando el orden de importación de la cola.

Lección 2: Importación usando TMS
El administrador de transportes debe seguir las normas establecidas para la estrategia
y planificación de transportes. De esta forma, nos aseguraremos que los cambios sean
distribuidos de forma consistente en el landscape.
Visualizando Órdenes de Transportes usando TMS
Las colas de importación de TMS, reflejan los buffer específicos de cada sistema que se
encuentran a nivel del sistema operativo. Las colas de importación muestran el orden
correcto en que deben importarse las órdenes. Las colas de importación de todos los
sistemas se pueden visualizar desde cualquier sistema del dominio de transportes, así
también como realizar las importaciones.
Para acceder lo hacemos mediante la transacción STMS y luego desde el menú
Overview Imports. Allí veremos el estado actual de la cola de importación, a veces
es necesario refrescarla para una vista actualizada. El timestamp muestra que tan
reciente es la información.

Figura 146 – Información de la Cola de Importación

Para que la información de la cola de importación se refresque automáticamente
podemos configurar un job de background periódico. Para esto elegimos STMS
Overview Imports Extras Update All Import Queues. Luego seleccionamos con
qué período se ejecutará el job. Cada una hora es un tiempo razonable. El programa
es RSTMSCOL.

Figura 147 – Colas de Importación y Buffer de Importación

Marca de Stop
Los términos buffer de importación y colas de importación están relacionados. La cola
de importación en el sistema SAP representa el buffer de importación que se encuentra
en el directorio de transportes. La cola de importación resalta las órdenes que serán
importadas durante la próxima importación (método importar todo). Debido a la marca
de stop (stopmark), podría haber más órdenes de transportes en el buffer de
importación que aquellas resaltadas en la cola de importación.
El stopmark indica que solo las órdenes anteriores a la marca serán importadas. El
stopmark se crea tanto en la cola de importación como en el buffer de importación. En
la cola de importación se muestra con la leyenda “End of Import Queue”. En el buffer,
el término stopmark se muestra. Puede solo haber un stopmark en cada buffer de
importación.
Para crear un stopmark para cerrar la cola de importación, desde la misma cola de
importación en STMS elegimos Queue Close. Esto es análogo en el sistema operativo
con el comando tp setstopmark.
Para quitar la marca de stop, aunque normalmente no se realiza esto, desde la misma
pantalla selecciona Queue Open. En el sistema operativo tp delstopmark.
También podemos mover luego la marca de stop a otra posición en la cola de
importación. Seleccionamos la orden delante de la cual queremos situar la marca y
elegimos Queue Move End Mark. En el sistema operativo tp mvstopmark.

Figura 148– Cola de Importación

La cola de importación es útil para:
Visualizar el estado de las órdenes.
Acceder a listas de objetos en las órdenes, documentación, y logs de transportes.
Cerrar y abrir la cola y mover la marca de stop.
Importar todas las órdenes, proyectos completos, órdenes preliminares, y órdenes
seleccionadas de acuerdo a ciertos filtros.
Agregar, borrar y redireccionar órdenes.
Para mantener los sistemas SAP consistentes, es necesario establecer fechas límites
para coordinar la liberación de órdenes de transportes de los desarrolladores. Para
prevenir que las órdenes liberadas posteriormente a la fecha límite sean importadas, la
cola de importación puede cerrarse. Las órdenes liberadas posterior al cierre de la cola
se posicionan luego de la marca de stop en la cola para la próxima importación. Solo
las órdenes previas a la marca de stop son importadas.
En casos excepcionales, podemos redireccionar una orden de transporte a otro sistema
SAP antes de que sea importada en el sistema destino de la cola de importación. Por
ejemplo, antes de importarse en el entorno de calidad, una orden necesita ser enviada
al sistema de entrenamiento. Para importar una orden en un sistema fuera de la ruta
predefinida, en la pantalla de la cola de importación seleccionamos la orden y luego
Request Forward System.
También podemos borrar o agregar órdenes de transporte a una cola de importación.
Las dependencias de objetos pueden causar inconsistencias en el sistema destino
luego en la importación. Por ejemplo, si borramos una orden que contiene un nuevo
elemento de datos, todas las ordenes que contengan tablas que dependen de ese
elemento de dato fallarán. Para evitar estas inconsistencias, es muy importante no
borrar órdenes de transporte.

Figura 149 – Importación de Todas las Órdenes de Transporte

Para importar todas las órdenes en la cola, lo que se conoce como un “Importar Todo”,
seleccionamos el botón Import All Requests. La ventana Start Import aparece.
Si tenemos configurado el Control de Transporte Extendido, el cliente destino está
fijado. De otra forma, deberemos seleccionar el cliente destino.
Tenemos varias opciones para iniciar el transporte:
En la solapa Date podemos planificar la importación.
En la solapa Execution podemos seleccionar si TMS iniciará tp de forma sincrónica o
asincrónica. De forma asincrónica significa que tp trabajará en background y no
bloqueará la sesión durante la importación.
En la solapa Options podemos seleccionar opciones expertas conocidas como modos
incondicionales. Las opciones y las que son por defecto varían según la estrategia de
transportes configurada.
La pantalla Import Overview muestra si la importación está corriendo. Después de la
importación, la marca de stop es removida y la cola se abre nuevamente
automáticamente. Después que las órdenes de transporte han sido importadas
exitosamente, son automáticamente agregadas a la cola de importación del siguiente
sistema.
Si usamos el procedimiento de Aprobación de QA, todas las órdenes en la cola de
importación en el o los siguientes sistemas son marcadas como inactivas. Si tratamos
de importar órdenes donde al menos una se encuentra inactiva, TMS no realizará la
importación.
Solamente podremos importar todas las órdenes en un sistema de entrega si
todas las órdenes listas para importar han sido verificadas en todos los pasos del
procedimiento de aprobación (ya sea que se aprueben o se rechacen).
Si todas las órdenes para un proyecto han sido aprobadas, puedes importarlas en el
sistema de entrega aún si hay todavía otras órdenes sin procesar por el procedimiento
de aprobación o rechazadas en la cola de importación.
Si realizamos una importación a través de la opción importar todo, los objetos son
importados en la secuencia correcta como se listan en el buffer. Esto significa que si
las órdenes de transportes cerca del comienzo de la lista y aquellas cerca del final

afectan a los mismos objetos, las versiones finales de estos objetos después de la
importación estarán activos con los últimos cambios. Como resultado, los objetos
incorrectos no afectan el ambiente productivo.
Podemos desactivar la opción de realizar una importación completa, importar todo,
para cada sistema usando el parámetro de TMS NO_IMPORT_ALL

Figura 150 – Importar un Proyecto Completo

Antes de iniciar la importación, SAP recomienda configurar la marca de stop para
cerrar la cola de importación. Esto evita la importación de otras órdenes que podrían
aparecer en la cola.
Podemos usar también filtros en la cola de importación para limitar las órdenes que se
muestran con propiedades específicas de forma que podamos ver solo las órdenes que
pertenecen a un proyecto particular o con cierta relación entre sí por ejemplo porque
fueron creadas por el mismo usuario. Para configurar un filtro, debemos posicionar el
cursor en una columna de la cola de importación y seleccionar el botón Filters.

Figura 151– Importar una Única Orden de Transporte (Importación Preliminar)

En contraste a las importaciones estándar, las importaciones preliminares son
importaciones de una única orden (o un conjunto seleccionado). SAP recomienda

utilizar la importación estándar por la dependencia entre objetos y el riesgo de
inconsistencias cuando se importan órdenes individuales.
Por ejemplo, un reporte ABAP en una orden puede ser importado correctamente, pero
la tabla a la que refiere puede estar en otra orden de transporte que no ha sido
importada aún. Hasta que la tabla no es importada, la ejecución del reporte generará
short dumps. Por esto debemos usar la importación preliminar en casos excepcionales.
Para minimizar los riesgos asociados con importaciones preliminares, la orden queda
en la cola de importación luego de que ha sido importada y es re-importada la próxima
vez que toda la cola es importada. Esto garantiza que la secuencia de exportación e
importación es siempre la misma. Esto se define con la opción Leave Transport
Request in queue for later import, la cual es marcada dependiendo de la estrategia de
transportes.

Lección 3: Opciones y Estrategias de Transportes
Opciones Adicionales en la Importación
En circunstancias particulares, podría ser necesario especificar opciones adicionales
cuando realizamos una importación preliminar.
Ignorar que la orden de transporte ya ha sido importada.
Sobrescribir originales: si un objeto fue creado en el sistema destino y la orden
contiene el mismo objeto tendremos que usar esta opción para que la importación no
falle.
Sobrescribir objetos en reparaciones sin confirmar: un objeto que fue modificado en
un sistema donde no es original, por ejemplo un objeto estándar de SAP, es un objeto
marcado como reparado en el sistema. Si la orden contiene un objeto que en el
sistema destino está marcado como reparado, deberemos utilizar esta opción.
Ignorar tipo de transporte inválido
Los objetos de las órdenes de transportes seleccionadas para importación serán
importadas de la siguiente manera:
Todos los objetos de todas las órdenes de transportes son tratados de manera
conjunta, esto es, independiente de la orden a la que pertenecen.
Primero todos los objetos son ordenados de acuerdo al nivel que pertenecen (ej. las
definiciones de tablas antes que los programas).
En caso de un objeto que se encuentra en más de una orden de transporte, solo la
versión en la última orden de transporte es importada (de acuerdo a la secuencia en la
cola de importación)
Esto es independiente del método de importación elegido (Importar Todo, Importar
Proyecto, Importación Individual)

En un landscape de tres sistemas, la cola de importación de QAS refleja el orden
de exportación de DEV. La cola de importación de PRD refleja el orden de
importación que se realizó en QAS. Esto no siempre es idéntico en todos los
casos. Pero es la secuencia correcta.

Planificación de Importación

Figura 152 – Fecha y Hora de Importación

Dependiendo si seleccionamos la importación por proyecto, importación individual,
importar todo, o un workflow especial de transporte y particularmente de la versión de
SAP y nivel de Support Package, las opciones pueden variar. Cuando iniciamos una
importación, podemos elegir las siguientes opciones en la solapa Date:
Immediate
Seleccionando esta opción inmediatamente inicia la importación en un work process de
diálogo.

At Start Time
Si elegimos esta opción la importación inicia en una fecha y hora específica. Se
planifica un job de background en el sistema destino. Si ingresamos un fecha y hora en
el campo No Start After, la importación puede iniciar en la ventana de tiempo entre
Planned Start y No Start After. Si no hay work processes de background disponibles
durante la ventana de tiempo, la importación no se relaliza. Si queremos que la
importación se realice regularmente debemos ingresar la frecuencia en el campo
Period.
After Event
Seleccionando esta opción la importación se inicia solamente después que un evento
específico se dispare. Si seleccionamos Execute Import Periodically, la importación se
inicia cada vez que el evento seleccionado ocurre. De otra manera, la importación
ocurre solo la primera vez que sucede el evento.

En los transportes individuales o en un workflow de transporte el campo Period
no existe.
Desde la cola de importación de cada sistema SAP, podemos monitorear y mantener
todas las importaciones planificadas seleccionando Goto Job Monitor.

Figura 153 – Frecuencia de Transportes

Después de la exportación, una orden de transporte no es importada
automáticamente, sino que debe hacerse manualmente. Cuando planificamos las
importaciones, deberíamos incluir un tiempo suficiente entre cada importación para
poder realizar las tareas de pos-importación tal como las pruebas de QA.
SAP recomienda que la planificación de las importaciones sea intervalos de tiempo
regulares tal como mensual, semanal o diaria y usando la estrategia Importar Todo en
el sistema destino. La importación frecuente no es recomendada.
Las siguientes acciones tienen que considerarse:
Liberación de órdenes de transportas.
Copia en un cliente en el mismo sistema (de desarrollo) mediante la transacción
SCC1 (test unitario).
Importación en clientes en sistemas subsiguientes.
La frecuencia de transportes está basada en los siguientes factores:
Clientes y los roles de estos en el landscape de sistemas.
Requerimientos de sincronización, esto es, cuando son requeridos los cambios en los
diferentes sistemas.
Requerimientos de Congelamiento de Código (Code Freezing).
Estrategias de Transportes
Hay tres estrategias de transportes diferentes disponibles:
Transporte masivo controlado por la cola.
Transporte individual controlado por la cola.
Transporte controlado por workflow.

La estrategia de transporte es por defecto el Transporte masivo (Importar
Todo).
Transportes Masivos: son una buena solución si tenemos que adminsitrar un gran
número de transportes y queremos automatizar el proceso lo más que podamos. El uso
continuo de importación masiva es la forma más segura de mantener los sistemas
sincronizados y consistentes. Antes de importar con este método en el sistema de
producción, deberemos verificar que todas las órdenes en el sistema de calidad y la
confirmación (o aprobación) de estas en los demás sistemas (por ejemplo el de
producción).
Para esto usamos el procedimiento de QA en TMS. También deberemos definir la
importación masiva como el método elegido para los sistemas relevantes. Para esto,
seleccionamos la estrategia de transportes Queue-controlled mass imports.
El administrador puede planificar las importaciones periódicamente en TMS, o iniciar
cada importación manualmente. Solamente deberíamos importar órdenes individuales
antes que otras según el orden de la cola de importación en casos especiales.
Las órdenes de transportes que son importadas previamente son importadas
nuevamente en la importación normal, o sea la importación masiva. Esto es así por la
opción Leave transport request in queue for later import la cual se selecciona
automáticamente cuando realizamos un transporte que no sea masivo (Importar
Todo). También podemos usar workflow para importar órdenes de transportes
individuales.
Importación Individual: usamos esta estrategia si tenemos pocos cambios para
transportar y la organización no nos permite realizar una planificación fija de
transportes. Este método usualmente demanda un esfuerzo extra para los
administradores en comparación a los transportes periódicos. Los desarrolladores
deberán poner atención a la consistencia de sus órdenes de transportes.
Si un número pequeño de desarrolladores están trabajando en un proyecto, y también
en un mismo equipo con el administrador, usualmente crean sus propias órdenes de
transporte e incluso la importación de las mismas en el sistema de calidad.
En el caso en que los transportes individuales que realicemos en el sistema tengan que
realizarse por el administrador de sistema, recomendamos que se utilice el workflow de
transportes. Este método automáticamente dispara un workflow cuando se libera la
orden de transporte.
El workflow asegura la comunicación entre el desarrollador y el administrador. Como
requisito tendremos que haber configurado el worfklow de transportes en el sistema.

Lección 4: Establecer y Modificar Estrategias de Transportes
Mantener las Estrategias de Transporte
La estrategia de transporte masivo está configurada por defecto en el sistema luego de
la instalación y configuración de TMS. Si queremos trabajar con transportes
individuales controlados por cola o transportes controlados por workflow, podremos
seguir los pasos de configuración descriptos a continuación:

Figura 154 – Transacción STMS: Overview → Transport Routes

Inicia la transacción STMS y luego Overview ->Transport Routes. La pantalla
Display ->Transport Routes aparece mostrando las rutas de transportes existentes en
1.

el dominios de transportes.
2.

Cambia al modo de edición seleccionando Configuration ->Display ↔ Change.

3. Posiciona el cursor sobre el sistema SAP para el cual queremos cambiar la
configuración de la estrategia de transportes.
4. Seleccionamos Edit ->System ->Change. El cuadro Change System Attributes
aparece.
5. Seleccionamos la solapa System Attributes y luego elegimos la estrategia de
transportes.
Dentro de un grupo de transportes debemos configurar a todos los sistemas con
la misma estrategia, ya sea Queue-controlled transports o Workflow-controlled
transports.
6. Seleccionamos Copy.
7. Luego Configuration

Distribute and activate.

Configuraciones en TMS dependiendo de la Estrategia de Transporte
Queue-controlled mass transports (Transportes masivos controlado por
cola)
Por defecto la opción Leave transport request in queue for later import está activada,
cuando se realiza una importación individual.
La opción de importación Leave transport request in queue for later import
hace que las órdenes importadas como transportes individuales se mantengan
en la cola de importación para que sean importadas en el orden correcto en la
próxima importación de todas las órdenes.
Esta opción es útil si tenemos que hacer una importación preliminar para órdenes
individuales. Esto previene que objetos más antiguos sean importados en la próxima
importación normal de todas las órdenes.
Queue-controlled single transports (Transportes individuales controlado por
cola)
Por defecto, la opción de importación Leave transport request in queue for later import
está desactivado.
La barra de botones en la cola de importación cambia de acuerdo a los requisitos de la
estrategia de importación de transportes individuales. Por ejemplo, contiene una
función de selección.
En la función Importar Todo (el camión con carga completa) está solamente disponible
si elegimos uno o más proyectos usando la función de filtro. Esto previene que se
importe accidentalmente todas las órdenes en la cola.
Workflow-controlled transports (Transportes controlados por workflow)
Las propuestas de transportes son creadas automáticamente cuando las órdenes son
exportadas.
Las opciones de importación se corresponden con las de los transportes individuales.
Las importaciones se agregan a la lista de procesamiento de las propuestas de
transportes en la lista de trabajo de TMS.
Una advertencia aparece en la cola de importación si intentamos realizar transportes
sin usar el workflow de transportes.
Los siguientes parámetros para el programa de control de transportes y el Sistema de
Cambios y Transportes (CTS) son configurados acorde a la estrategia de transportes
elegida:
Parámetros de tp para las estrategias de transportes:

El parámetro de tp STOPONERROR define a partir de que código de error la
importación se detiene. REPEATONERROR define desde que código de error la
importación no es clasificada como exitosa y tiene que repetirse. Por ejemplo, con
Transportes Individuales, el código de error 8 es tomado como una importación fallida
y tiene que ser repetida. Con Transportes Masivos, el mismo código de error 8 será
una importación exitosa.
No cambies manualmente los parámetros que son relevantes a la estrategia de
transportes. TMS genera estos parámetros cada vez que la configuración de
rutas de transportes es modificada.
Transportes de Copias y Reubicación

Figura 155 – Transporte de Copias y Reubicación

Utiliza la función Transport of copies para transportar objetos a otro sistema SAP que
seleccionemos. Esta función es especialmente útil si el sistema destino no es un
sistema de consolidación desde el sistema donde vamos a generar la orden. Los
objetos son transportados con la versión que tienen en el sistema donde nos
encontramos. La ubicación original del objeto (sistema origen) no es modificada. La
orden de transporte no será agregada tampoco a la cola de importación de un sistema
subsiguiente en la ruta de transportes.

La función Relocation of objects w/o package change nos sirve si el trabajo de
desarrollo sobre los objetos se realizará temporalmente en otro sistema SAP. Algunos
desarrollos especiales podrían ser realizados en un sistema SAP separado, por ejemplo,
para no interferir con el proceso normal de desarrollo. Estos tipos de órdenes nos
permite mover ubicaciones originales de los objetos a un sistema destino, o sea
cambiar el sistema al que pertenece donde es original el objeto.
Usamos la función Relocations of objects with package change cuando el sistema de
desarrollo de los objetos que transportaremos será cambiado de manera permanente.
Este tipo de órdenes nos permite cambiar la ubicación original de los objetos al sistema
destino y también cambiar el paquete de los objetos al mismo tiempo. Debido a esto
último, los objetos tienen los atributos del paquete al que son asignados en el sistema
destino inmediatamente luego de la importación.
Usamos Relocations of Complete Package cuando el sistema de desarrollo de un
paquete completo será cambiado de manera permanente.

Lección 5: Configuración y Características del Procedimiento de QA
Las órdenes de transportes serán importadas en el sistema de producción solamente
después que sean aprobadas en el sistema de calidad. Por lo tanto necesitaremos
contar con un procedimiento de aprobación de calidad.
Aseguramiento de Calidad en TMS
El procedimiento de aseguramiento de calidad (QA) incrementa la calidad y la
disponibilidad del sistema de producción permitiéndonos verificar las órdenes de
transporte en el sistema de calidad antes de que sean entregadas en los sistemas
subsiguientes.
Cuando activamos el procedimiento de aprobación de calidad QA, las órdenes de
transporte estarán disponibles para ser importadas en el o los sistemas de entrega si
todos los pasos del proceso de calidad han sido aprobados.
Cuando configuramos el sistema de QA determinamos cuantos pasos de QA deberán
aprobarse para cada orden de transporte. Si uno de los pasos no es aprobado,
entonces la orden no puede ser aprobada. Solo podremos importar órdenes que hayan
sido completamente aprobadas.
Las órdenes rechazadas no son importadas en el sistema de entrega.

Figura 156 – Configuración del Procedimiento de Aprobación de QA

Antes que podamos procesar órdenes de transportes deberemos configurar el
procedimiento de aprobación de QA. Al menos deberemos contar con un landscape
tradicional de tres sistemas (DEV, QAS y PRD). El sistema que que configuremos como
el sistema QA deberá contar con los siguientes atributos:
Debe ser el destino de al menos una ruta de consolidación.
Debe tener una ruta de entrega hacia otro sistema al menos.
Después de la configuración, la lista de trabajo de QA es automáticamente creada.
Todas las órdenes importadas en el sistema de QA son incluidas en la lista de trabajo
de QA.
Pasos en el Procedimiento de Aprobación de QA
Para visualizar la lista de trabajo de QA, usamos las transacción STMS y seleccionamos
Overview
Imports
Goto
QA worklist. La fecha y hora en la parte superior
derecha de la pantalla indica cuando la lista de trabajo de QA ha sido actualizada por
última vez; la parte susperior izquierda indica cuantas órdenes aún están pendientes
de procesamiento.
La lista muestra las órdenes de transporte que se corresponden con el paso de
aprobación seleccionado. Por defecto, las órdenes correspondientes a todos los pasos
se visualizan en primer lugar. Para seleccionar el paso de aprobación y ver todas las
órdenes que concuerdan con el mismo seleccionamos Worklist
Select Approval
Step. Con un doble clic sobre uno de los ítems en la lista de trabajo podemos obtener
más detalles sobre el mismo.

Figura 157 – Aprobación QA

Antes de importar las órdenes en un sistema de entrega deberíamos testear las
órdenes en el sistema de QA. El estado de QA rechazada (rejected) siginifica que uno o
más pasos de aprobación no fueron aprobados por la persona responsable. Una orden
es aprobada solamente si todos los pasos de aprobación tienen el estado aprobado
(approved).
En la lista de trabajo de QA podemos ver:
El estado de QA (St)
El estado general (GS)
El número de paso (Nr)
Una vez que todos los pasos de aprobación fueron procesados satisfactoriamente
entonces la orden de transporte podrá ser importada en el sistema de entrega. Si
todas las órdenes para un proyecto han sido aprobadas, pueden ser importadas en el
sistema de entrega a pesar que otros proyectos aún tengan órdenes pendientes de
procesar o rechazadas en la lista de trabajo de QA.
Las órdenes con el estado rechazada en QA así también como las órdenes aún sin
procesar en la lista de trabajo no son importadas en los sistemas de entrega.
A partir de la versión 6.10 la aprobación o rechazo de un paso individual puede ser
modificado, mientras que el procedimiento completo de aprobación no esté realizado.
Una vez que todos los pasos de aprobación están completo, no es posible cambiar la
decisión.
SAP recomienda no rechazar las órdenes que contengan errores, sino más bien
corregir los errores en una nueva orden de transporte y luego aprobar todas las
órdenes de transportes vinculadas en conjunto.

Figura 158 – Historial de QA

Desde la pantalla de la lista de trabajo de QA, podemos acceder al historial de QA
mediante Goto QA History.
El historial de QA muestra todas las órdenes para un período específico que ya no se
muestra en la lista de trabajo. Las órdenes no se visualizan tampoco en la lista de
trabajo una vez que han sido aprobadas o borradas. El período por defecto para la lista
de QA es de 30 días pero puede ser cambiado.
Para determinar quien fue responsable de aprobar una orden de transporte,
seleccionamos Request Display QA Status
El historial de QA se almacena en la base de datos del sistema de calidad, por lo
que si realizamos una copia de base de datos o de sistema desde el sistema de
producción por ejemplo, el historial se perderá. Podemos consultar por notas en
el Marketplace de SAP para mayor información.

Workflow de Transportes Especiales

Figura 159 – Workflow de Transportes Especiales

Utilizaremos el workflow de transportes si se requieren de manera urgente un
transporte de correcciones o si se necesitan transportes que no siguen la ruta de
transportes definida.
Antes de utilizar el workflow de transportes, será necesario configurar uno de los
sistemas como el Workflow Engine. Este sistema debería tener las siguientes
características listadas en orden de importancia:
Alta disponibilidad
Carga de trabajo baja a media
Estos requisitos son por ejemplo los que posee el sistema de calidad QAS. Todas las
tareas realizadas por el workflow de transportes son centralizadas en el Workflow
Engine y luego los resultados se comunican a los sistemas SAP involucrados.

Figura 160 – Configurando el Workflow de Transportes Especiales

Para configurar el workflow de transportes especiales, realizaremos lo siguiente:
Ingresamos al sistema que funciona como controlador de dominio de transportes.
Iniciamos la transacción STMS y luego desde el menú Overview Systems Goto
Transport Domain.
Seleccionamos la solapa Worfklow Engine.
Cambiamos al modo de edición con el botón de Display ↔ Change. Ingresamos el
sistema SAP, el cliente y el host destino para el Workflow Engine. Luego de guardar las
modificaciones tendremos que aceptar afirmativamente el cuadro para distribuir la
configuración. A continuación ingresamos al sistema que funcionará como el Workflow
Engine. El sistema automáticamente:
Crea el usuario TMSADM_WF.
Genera los destinos RFC necesarios para el Workflow Engine.
Envía los datos propios de Workflow Engine a todos los sistemas en el dominio de
transportes.
Realiza el customizing para el worfklow en el sistema.

Figura 161 – Creando las Propuestas de Transportes

Para utilizar el workflow de transportes, tendremos que crear una propuesta de
transportes. Para esto, desde el Organizador de Transportes, transacción SE09 y
seleccionamos las órdenes liberadas (released requests). Seleccionamos la orden de
transporte que vamos a transportar y luego seleccionamos Utilities Create Transport
Proposal.
Una ventana aparece donde ingresamos una descripción y el sistema destino, y
también podremos agregar otras órdenes de transporte. La condición es que todas las
órdenes que ingresemos en la propuesta de transporte estén liberadas.
Si una propuesta de transporte es creada, el sistema SAP le asigna un número de
propuesta y luego es agregada a la lista de trabajo de TMS para el administrador de
transportes.
Si el administrador de transportes rechaza la propuesta de transporte aparecerá
nuevamente en la bandeja de entrada de propuestas de transportes del solicitante.
Podremos cancelar la propuesta o revisarla y reenviarla nuevamente al administrador
de transportes.
Después que el administrador de transportes ha aprobado la propuesta, la importación
se inicia y la propuesta de transportes reaparece en la bandeja de entrada del
solicitante. Luego de que verificamos que la orden de transporte se importó
correctamente en el sistema destino, confirmamos la propuesta de transporte.

Figura 162 – Lista de Trabajo de Propuestas de Transportes

Para aprobar o rechazar una propuesta de transportes, iniciamos la transacción STMS.
Para visualizar la lista de trabajo de TMS, seleccionamos Overview
Worklist. Con
doble clic seleccionamos la propuesta de transporte que queremos procesar.
Podremos verificar allí si las órdenes, la lista de sistemas destinos, las fechas de
importación y opciones para la propuesta de transportes son correctas. También
podemos visualizar las órdenes de transporte seleccionando Display y el ícono de los
logs de transportes.
Cambiamos al modo de modificación si queremos hacer modificaciones a las órdenes
de transportes, destinos, fecha de importación u opciones de importación.
Se pueden agregar mensajes para un desarrollador por ejemplo con el ícono Manage
Attachments.
Para procesar la propuesta de transporte, seleccionamos el ícono para aprobar o
rechazar la propuesta.
Una vez aprobada una propuesta de transporte, la importación en el o los sistemas
destinos es iniciada automáticamente.