Introduccin a SAP

Leccin 1: Qu es SAP?
Qu es SAP?
SAP es una empresa con sede en Alemania creada en el ao 1972. Es junto con Oracle
una de las ms grandes en la venta de software empresarial.
Actualmente la mayora de las grandes corporaciones utilizan para el manejo de sus
negocios alguna implementacin de SAP, lo que asegura un gran futuro de SAP dentro
de las empresas a largo plazo.
Su logro actual es que tambin estn implementando su software en empresas de
pequea 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 estn la
facturacin, las ventas, la logstica, las finanzas, entre otras las cuales se conocen
como mdulos.
La ventaja que tiene este tipo de sistemas es que integran todas estas actividades en
un slo programa, por lo tanto todo se mantiene relacionado, favoreciendo la
interaccin de las diferentes reas.
Una caracterstica importante es que SAP R/3 proporciona la oportunidad de sustituir
un gran nmero de sistemas independientes, que se han desarrollado e instalado en
organizaciones ya establecidas, por un solo sistema modular.
Como referencia, nombramos los mdulos que
contiene SAP R/3:

Figura 1 - Mdulos de R/3

FI: Contabilidad Financiera

CO: Controlling
IM: Inversiones
TR: Tesorera
LO: Gestin de datos de logstica
EC: Enterprise controlling
MM: Gestin de materiales
SD: Gestin de Ventas
PS: Gestin de Proyectos

QM: Gestin de la Calidad

PP: Planeamiento de Produccin
HR: Gestin de Recursos Humanos
PM: Gestin de Mantenimiento

Existen tambin 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 logstica y demanda.
SAP Netweaver: esta es una aplicacin abierta de integracin para todas las
dems aplicaciones de SAP y algunas de terceros tambin.

Figura 2 - SAP Netweaver

Leccin 2: Aplicaciones y Componentes de SAP

Productos SAP a la medida de la compaa
En los ltimos aos SAP ofrece un abanico de productos para empresas u
organizaciones de todos los tamaos. Estos se caracterizan principalmente por su
escalabilidad asegurando de que puedan ajustarse a la talla de cada compaa y
tambin se adapten a los constantes cambios en los procesos de la misma.

Figura 3 Diferentes tamaos, diferentes productos.

SAP Business One: es una aplicacin de ERP con una interfaz similar a la de
Windows, la cual ha sido desarrollada especficamente para pequeas y medianas
compaas. Este software permite gestionar las reas ms importantes del negocio en
una aplicacin simple e integrada.
Esta solucin es ideal para compaas con menos de 100 empleados y hasta 30
usuarios y necesiten un sistema a su alcance econmico 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 solucin desarrollada por SAP para las
pequeas y medianas compaas 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 an
no utilizan software de negocio integrado.
Ofrece protocolos de comunicacin estndar tal como los Web Services que permite la
interaccin entre diferentes aplicaciones (A2A) y sistemas (B2B).
SAP Buiness All-In-One: es la solucin ideal para aquellas empresas de mediana
escala con requerimientos muy especficos 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 implementacin rpida utilizando escenarios ya preconfigurados basados en las mejores prcticas del mercado en las que se encuentran
estas industrias.

Aplicaciones SAP
Si bien la aplicacin ms 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 compaa.
SAP Business Suite provee:
Un completo espectro de soluciones de negocio
Una infraestructura abierta y flexible con aos de madurez y solidez
Componentes adaptables a los requerimientos de negocio
Numerosas funciones especficas 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 ms
pequea, instalable y que puede ser mantenida.

Leccin 3: SAP Netweaver.

Concepto de SAP Netweaver
La plataforma tecnolgica de SAP Netweaver est diseada para poder introducir de
manera paulatina y flexible los procesos ms importantes de una compaa ya que nos
proporciona a un alto nivel las funciones necesarias y los estndares de la industria
para integracin. De esta manera podemos definir a SAP Netweaver como la base
tcnica del SAP Business Suite.

SAP Netweaver nos permite integrar y conectar gente, informacin y procesos de

negocio a travs de diferentes tecnologas permitiendo ajustarse rpidamente a los
cambios que puedan surgir en una compaa. De esta manera la integracin est
unificada en una nica plataforma lo que facilita que no tenga que ser desarrollada
por cada cliente.
Prcticas y Escenarios IT
SAP Netweaver permite implementar procesos de IT dentro de un rango de soluciones
denominados prcticas de IT. Para cada una de estas prcticas 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 compaa puedan alcanzarse en proyectos
individuales y manejables, o sea, en pasos secuenciales de acuerdo a la importancia de
cada uno.
Para cada prctica de IT SAP Netweaver provee los escenarios correspondientes que
sirven como guas de implementacin.

Figura 5 - Escenarios y Prcticas de IT

En conclusin, los escenarios de IT nos brindan una ayuda al momento de la

instalacin, configuracin y operacin de SAP Netweaver.

Las capas de SAP Netweaver

SAP Netweaver est dividido en cuatro capas de integracin que consisten cada una de
funciones centrales:

Integracin de Gente (People Integration): permite que los usuarios de

diferentes aplicaciones tengan acceso a la informacin y funciones que necesitan de
manera rpida y eficiente en una interfaz concentrada. Dentro de esta capa
encontramos principalmente la aplicacin SAP Netweaver Portal que provee funciones
ms importantes en este contexto.

Figura 6 - SAP Netweaver Portal

Integracin de la Informacin (Information Integration): esta capa provee

el acceso a toda la informacin de la compaa ya sea estructurada o no lo que
significa que es informacin que fue generada por un sistema no-SAP. Las principales
reas de integracin de informacin estn formadas por SAP Netweaver Business
Intelligence (BI) y SAP Netweaver Master Data que permite gestionar de manera
central los datos maestros de la compaa.

Figura 7 - SAP Netweaver BI

Integracin de procesos (Process Integration): esta es la capa que se encarga

de comunicar las aplicaciones de nuestra compaa (o fuera de ella tambin) en
ambientes heterogneos. SAP Netweaver Process Integration (PI) juega un rol
fundamental aqu para conectar los sistemas SAP y no-SAP utilizando diferentes
estndares de comunicacin.

Figura 8 - SAP Netweaver PI

Plataforma de Aplicacin (Application Platform): El Servidor de Aplicacin SAP

NetWeaver, denominado comnmente como SAP Netweaver AS, por sus siglas en
ingls provee la infraestructura para la operacin de las aplicaciones de negocio que
estn basadas sobre las tecnologas J2EE o ABAP. Adicionalmente los estndares
abiertos, acceso a aplicaciones web y servicios web completan la plataforma de
aplicacin.
En conclusin el SAP Netweaver AS es el entorno de ejecucin para las aplicaciones de
nuestras aplicaciones SAP. Las herramientas necesarias para el desarrollo de nuestras
propias aplicaciones tambin estn incluidas dentro del mismo.

Figura 9 - SAP Netweaver AS

Plataforma del sistema SAP

Leccin 1: Arquitectura del SAP Netweaver AS
Arquitectura del SAP Netweaver AS
La mayora de los sistemas SAP estn basados sobre un servidor de aplicacin
Netweaver como entorno de ejecucin, junto con la base de datos, el SAP Netweaver
AS es la plataforma de aplicacin de SAP Netweaver.

Figura 10 SAP Netweaver AS

La evolucin de la tecnologa del servidor de aplicacin SAP, antes conocido como SAP
Basis es lo que hoy representa el servidor de aplicacin Netweaver donde las
aplicaciones web tienen una especial relevancia.
Qu caractersticas tiene el SAP Netweaver AS?
Un entorno confiable y comprobado de ejecucin el cual es continuamente
desarrollado y mejorado.
Un framework de ejecucin de procesos complejos de negocio que cumple con los
estndares de seguridad ms altos.
Un ambiente de desarrollo integrado y de fcil utilizacin.
Soporta estndares 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 implementacin de un sistema SAP deberemos decidir la arquitectura de
nuestro sistema SAP y cmo 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 ejecucin: ABAP y JAVA.
Cliente Servidor
En una definicin orientada al hardware cuando nos referimos a una configuracin
cliente-servidor este ltimo provee en una red datos, memoria y otros recursos a las
estaciones de trabajo (workstations).
En una visin 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
Aplicacin Web SAP (SAP Web AS) y es un servidor para ese servicio especfico. Los
componentes de software que usan ese servicio son los clientes.
Al mismo tiempo, un cliente puede comportarse como servidor para otros servicios
especficos.
La siguiente imagen puede clarificar un poco ms los conceptos:

Figura 11 Dos definiciones de Cliente-Servidor

Configuracin Cliente-Servidor de Sistemas SAP

En un sistema de software de negocios generalmente encontraremos los siguientes
procesos:
Procesos de presentacin (por ejemplo para presentar las pantallas)
Procesos de aplicacin (por ejemplo, para ejecutar los programas de aplicacin)
Procesos de base de datos (por ejemplo, para gestionar y organizar los datos de
la base)

En la implementacin de un sistema SAP la configuracin de estos procesos puede

resultar single-tier o multi-tier dependiendo del nmero de capas de hardware
utilizadas. El sistema SAP ECC es un ejemplo de software de aplicacin de negocios.

Figura 12 Configuraciones Cliente-Servidor.

Conformacin 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 ms
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 ms de una instancia de un mismo sistema o de diferentes sistemas

en un mismo servidor. As tambin como ms 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 organizacin dentro de un landscape
SAP cada SID es nico y no debe repetirse.
Qu es una instancia SAP?
Bsicamente una instancia de SAP es una unidad administrativa en la que los
componentes de un sistema SAP que provee uno o ms servicios se encuentran
combinados. Si bien ahora puede no quedar muy claro este concepto vamos a ir
desarrollndolo de ahora en ms.
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 ms de una
instancia podramos 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 trmino instancia tambin es comnmente referenciado como servidor
de aplicacin desde un punto de vista de software ya que es el entorno de
ejecucin para las aplicaciones de negocios de SAP.

Variantes de Servidores de Aplicacin 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 dems instancias del sistema
debern ser del mismo tipo. Las dems 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 tambin 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 dilogo se requieren mnimamente
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 nmero de dos dgitos.
Por lo general en manera secuencial empezando por 00 (doble cero). Cuando
instalamos el sistema tenemos la opcin de elegir el nmero de instancia entre 00 y
97.
Cuando agregamos instancias a nuestro sistema tenemos que elegir un nmero que no
est utilizado si la instancia se instala en el mismo servidor que la o las anteriores.
Podemos concluir entonces que cada nmero 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 dems ya que en esta encontraremos un proceso especial denominado
Message Server (Servidor de Mensajes), este proceso es nico para todo nuestro
sistema SAP. Tambin la instancia central es la nica que ofrece uno o ms work
process de enqueue (encolado).

Instancias JAVA
El dispatcher de JAVA tambin 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

Tambin en este caso cada instancia de JAVA posee un nico dispatcher. Una instancia
de JAVA requiere mnimamente un server process. Si instalamos ms de una instancia
en un servidor, cada una de estas tendr un nmero 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 dems porque incluye un proceso
adicional denominado SDM que son las siglas en ingls 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 clsico 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 podrs 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

Leccin 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 aplicacin puede haber sido diseada en el lenguaje de
programacin ABAP o en JAVA. De esto se deduce que dependiendo del lenguaje con
que se decidi crear la aplicacin 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 ejecucin ABAP:

Figura 17 Procesos del entorno de ejecucin 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 administracin del

dispatcher?
Procesos
Procesos
Procesos
Procesos
Procesos

de
de
de
de
de

dilogo (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 parmetro correspondiente en el perfil de la instancia.
La siguiente tabla describe estos parmetros:

Tabla 1 Parmetros de Work Processes

Veamos ahora otros procesos, que no son work processes, y que proveen servicios de
comunicacin 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 mltiples servidores de
aplicacin (instancias) en paralelo. El message server se configura slo uno para todo
el sistema SAP.
El Gateway (GW) permite la comunicacin entre sistemas SAP, o entre sistemas SAP y
sistemas de aplicacin externos. Existe uno por dispatcher o instancia ABAP.
El Internet Communication Manager (ICM) permite la comunicacin con el sistema SAP
a travs de protocolos web tales como HTTP. El ICM recibe los pedidos del cliente y los
reenva 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 aplicacin.

Leccin 3: Procesos de Dilogo ABAP.

PROCESOS DE DIALOGO ABAP
La capa de presentacin
Los usuarios pueden loguearse al sistema SAP utilizando diferentes front ends, tal
como el clsico SAP GUI el cual usaremos durante el curso pero tambin podran
utilizar un navegador y as trabajar con las aplicaciones de SAP que estn desarrolladas
para este tipo de interfaz de usuario.
En ambos casos, los programas que conforman esas aplicaciones estn desarrollados
para que sean ejecutados en el entorno de ejecucin ABAP de nuestro sistema
SAP. Sin importar si son transacciones clsicas o aplicaciones web sern ejecutadas
por el proceso de dilogo de la instancia de ABAP.
Las aplicaciones web tambin pueden ser desarrolladas en JAVA por lo que seran
procesadas por este entorno. Cuando llega la solicitud al sistema se determina si
es ABAP o JAVA y se reenva al entorno adecuado.

Procesando solicitudes de SAP GUI

Veamos cmo funciona el procesamiento de la solicitud de un usuario, como por
ejemplo el llamado a una transaccin, en el servidor de aplicacin ABAP. Como
muestra la siguiente imagen, el procesamiento involucra diferentes procesos en las tres
capas (presentacin, aplicacin y base de datos):

Figura 18 Procesando solicitudes de usuario ABAP.

Cuando el usuario llama a una transaccin o cambia de pantalla dentro de una misma
funcin, esto es tomado por el programa de presentacin 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 coordinacin con el sistema
operativo respectivo donde corre nuestro sistema SAP.

Las principales tareas del dispatcher incluye la distribucin de solicitudes entre sus
work processes, la integracin de la capa de presentacin y la organizacin 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 dilogo libre, la solicitud es enviada por el dispatcher a
este work process. Esto significa que no hay una relacin fija entre los work process y
los usuarios (ms 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 travs 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 dilogo.

En la figura podemos observar la relacin entre los componentes y en cual sentido se

realiza la comunicacin 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
aplicacin a la capa de presentacin SAP GUI ya que datos que son accedidos
frecuentemente pueden alojarse en alguno de estos buffers en vez de tener que
solicitarlos a travs de una consulta a la base de datos.
Interface con la base de datos del sistema
Dentro del lenguaje de programacin ABAP el programador puede utilizar lo que se
conoce como ABAP Open SQL (SQL = Structured Query Language) para acceder a los
datos de la aplicacin ABAP. Cuando se elige este mtodo 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 especfica utilizada que sera 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 aplicacin SAP para acceder a los datos rpidamente.
Mucha informacin 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,
informacin del diccionario ABAP y tablas con datos estticos.

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 sern
utilizados en estos casos.
Si el programa ABAP tiene en su cdigo sentencias Native SQL, este pierde la
independencia de la plataforma de base de datos del sistema SAP.

Leccin 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
ms de un usuario al mismo tiempo.
Para lograr esto, el sistema SAP tiene su propio concepto de administracin de
bloqueos (lock management)
Transacciones de base de datos
Desde la perspectiva de la base de datos, vimos en la leccin anterior que cada paso
de dilogo forma una unidad fsica y lgica: la transaccin 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
lgica de pasos de trabajo relacionados que son consistentes en trminos de negocio,
los cuales se forman generalmente de varios pasos de dilogo.
El sistema SAP necesita administrar su propio concepto de bloqueo. Esto se logra
utilizando el work process de enqueue (encolado). Esto tambin 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 lgicos de las transacciones de SAP en
la tabla de bloqueo. Esta tabla se sita en la memoria principal de la instancia donde el
proceso corre.

Figura 21 Gestin 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 dilogo 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 dilogo 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 dilogo y el enqueue work process corren en diferentes

instancias se comunicarn a travs del message server. En este caso la solicitud de
bloqueo se reenva desde el work process de dilogo al enqueue work process a travs
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 enva a travs 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 aplicacin informa al usuario que la operacin
solicitada no puede realizarse en este momento.
Los desarrolladores son quienes deciden el modo de bloqueo para la aplicacin:
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 transaccin. Slo
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 dems solicitudes
se rechazan.
Bloqueo Optimstico (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 modificacin en una transaccin
el bloqueo pasa al tipo E. Si otros bloqueos de tipo O existen sobre el objeto estos son
eliminados de la tabla.
La transaccin SM12 muestra los bloqueos que actualmente hay en el sistema.

Figura 22 Transaccin SM12

Leccin 5: Proceso de Update

En el sistema SAP, un proceso de negocio es mapeado utilizando una transaccin que
puede contener varios cambios de pantalla, por ejemplo, la creacin de una orden de
compra.
Los cambios en los datos efectuados en este proceso se suponen que sern ejecutados
completamente o no sern modificados en absoluto en la base de datos (concepto
Atmico del sistema transaccional).
Si la operacin es finalizada durante la ejecucin o un error ocurre, entonces ningn
cambio en la base de datos debe efectuarse. El sistema de Actualizacin de SAP (SAP
Update System), el cual se describe a continuacin, es quien se encarga de esto.

El sistema de actualizacin
El sistema de actualizacin es una tecnologa 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 asincrnica en un proceso especial denominado
update work process (proceso de actualizacin).
Los procesos de dilogo pasan los datos que van a escribirse en la base de datos al
proceso de actualizacin. El proceso de dilogo no espera que la actualizacin se
complete para continuar, por esto es que la actualizacin es asincrnica, no en
simultneo. Los pasos que suceden en un proceso de actualizacin se muestra en la
siguiente figura:

Figura 23 Principio de actualizacin asincrnica.

La tarea del proceso de dilogo se completa con el comando ABAP COMMIT WORK ; la
parte de actualizacin de la transaccin comienza aqu: el message server transfiere la
solicitud de actualizacin a un proceso de actualizacin. Aqu, cada paso de dilogo
corresponde a una transaccin de base de datos, la cual se realiza completamente o
no con un comando COMMIT.

La parte de actualizacin de la transaccin SAP es ejecutada en una nica transaccin

de base de datos. Es en ese momento cuando los datos se copian a las tablas de la
aplicacin. Si un usuario quiere cambiar datos en una transaccin SAP, llama a la
transaccin correspondiente en dilogo, realiza las entradas o modificaciones en las
pantallas y luego inicia el proceso de actualizacin cuando guarda los datos.
Proceso de actualizacin asincrnica
Veamos ahora que pasos suceden cuando se realiza una modificacin de datos en una
transaccin SAP:
El programa bloquea los registros de datos de la aplicacin para otros usuarios. Esto
se logra por supuesto a travs 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 estn 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, enva la
clave de bloqueo (lock key) al usuario. El programa lee el o los registros que sern
modificados desde la base de datos y el usuario realiza las modificaciones en la
pantalla de la transaccin SAP.
En el proceso de dilogo active, el programa llama a un modulo de funcin ABAP
usando la sentencia CALL FUNCTION IN UPDATE TASK y escribe los cambios
realizados por el usuario a las tablas de actualizacin de la base de datos. Estas tablas
se conocen como las tablas VB* porque sus nombres comienzan con las letras VB.
Actan como memoria temporaria y guardan los datos que sern modificados hasta
que puedan ser guardados en las tablas de la aplicacin en la base de datos en una
nica transaccin de base de datos.
En el final de la parte de dilogo de la transaccin, por ejemplo, cuando el usuario
guarda los datos (posiblemente luego de completar otros pasos de dilogo), el
programa inicia la finalizacin de la transaccin con la sentencia ABAP COMMIT WORK.
El proceso de dilogo que hasta ac manejo el paso de dilogo dispara ahora el
proceso de actualizacin.
En base a la informacin que recibe del proceso de dilogo (datos para actualizar,
clave de bloqueo) el proceso de actualizacin lee las tablas VB* para identificar los
datos que pertenecen a esta transaccin SAP ya que pueden haber ms registros en la
tabla VB* al mismo tiempo de otras transacciones SAP.
El proceso de actualizacin transfiere los cambios marcados y obtenidos de las tablas
VB* a la base de datos con una sentencia nica de actualizacin en las tablas de la
aplicacin y evala la respuesta de la base. Si los cambios son realizados, el proceso
de actualizacin 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 actualizacin dispara un rollback en la base de datos y deja
la informacin en las tablas VB* marcndola 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 actualizacin asincrnico

La transaccin SM13 nos permite visualizar si existen actualizaciones pendientes en el

sistema SAP y cul es su estado. Aquellas que estn marcadas como errneas no
deben reprocesarse por el administrador sino por el mismo usuario utilizando la
transaccin para tal fin.

Figura 25 Transaccin SM13 Actualizaciones

Leccin 6: Otros Procesos ABAP

Impresin
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 dilogo, 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. Tambin cada usuario puede tener una impresora
configurada por defecto en su registro de usuario (Transaccin SU01).
Una vez que la impresora est configurada, el sistema SAP tiene toda la informacin
que necesita para poder crear lo que se denomina un spool request.
Spool Request
Un spool request contiene informacin 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 dilogo o por procesos de
background. Los procesos de spool no crean spool requests.

Figura 26 Impresin en un servidor de aplicacin 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 especfica 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 travs
de la red.
De todas maneras, veremos con mayor detalle la administracin de impresin ms
adelante en el curso.
Dos transacciones que son tiles son la transaccin SP02 donde podemos ver nuestros
propios spool requests y output requests. La otra es la transaccin SU3 donde
podemos especificar configuraciones personales de impresin en la seccin Spool
Control.

Figura 27 Transaccin SP02

Figura 28 Transaccin SU3: Configuraciones Personales

Procesamiento en Background
El procesamiento en background del sistema SAP es un mtodo para automatizar
tareas rutinarias y para optimizar el uso de recursos de los sistemas SAP en una
organizacin.
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 utilizacin.
Los programas que se ejecutan utilizando el procesamiento de background no estn
sujetos a las restricciones de los procesos de dilogo que luego de un tiempo definido
son terminados por el sistema.

El background process
La separacin del procesamiento de background en work process especiales nos da
una dimensin adicional para separar el procesamiento de background del de dilogo.
Normalmente el procesamiento de background y el procesamiento interactivo, o de
dilogo se realizan en distintos tiempos. Dilogo durante el da y background durante
la noche.
Tambin es posible utilizar los background work process para separar el procesamiento
de background y el trabajo interactivo en diferentes servidores de aplicacin (o
instancias).

Figura 29 Planificacin de tareas de background (Jobs)

El planeamiento se realiza mediante los work processes de dilogo y luego la ejecucin

la realiza el background work process como se ve en la figura 29.
La transaccin SMX nos muestra los jobs planificados por nuestro usuario.

Figura 285 Transaccin SMX

Comunicacin va el Gateway
Cada instancia de un sistema ABAP (o ABAP+JAVA) contiene un Gateway. Este es
utilizado para la comunicacin entre los work processes de diferentes instancias o
sistemas SAP as tambin 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 peridicamente.

Figura 30 Comunicacin va 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 comunicacin se inicia en el proceso
de dilogo, pasa por el dispatcher y se reenva al Gateway para establecer la
comunicacin con su par de la otra instancia (u otro sistema SAP).
Con la transaccin 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 aplicacin SAP Netweaver) y el mundo exterior va los
protocolos HTTP, HTTPS y SMTP. En su rol como servidor, el ICM puede procesar
solicitudes que llegan desde Internet como URLs con la combinacin de servidorpuerto en la cual el ICM est configurado para escuchar. El ICM luego llama al proceso
local del servidor de aplicacin que se ocupar finalmente de la solicitud URL.
Como consideracin para la implementacin, debemos pensar que necesitaremos del
ICM si queremos que el servidor de aplicacin SAP tenga comunicacin con Internet a
travs de alguno de los protocolos ya mencionados.
El ICM es un componente del servidor de aplicacin 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
travs de parmetros que se configuran en los perfiles de cada instancia.

Figura 31 Internet Communication Manager (ICM)

Tareas Bsicas de Administracin

Leccin 1: Proceso de Logon en un sistema ABAP
Para crear una conexin entre el front-end (interfaz de usuario) y una instancia de un
sistema SAP, el programa sapgui requiere cierta informacin como parmetros de
inicio. Estos parmetros, normalmente son creados utilizando el programa saplogon.
Esta informacin se almacena parcialmente en archivos de configuracin 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 enva a travs del SAP GUI los datos de logon
necesarios: cliente, usuario, contrasea 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 dilogo libre para procesar
el logon, transfiere los datos de logon a este work process, paso 4.
El work process ahora verifica si la combinacin de usuario y contrasea es vlida 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 envo de la
pantalla inicial del sistema al front-end.
Durante la sesin de logon, la asignacin 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 sesin.
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 travs del Message Server. Para esto
debemos especificar explcitamente la instancia a la que vamos a realizar la
conexin.

Leccin 2: Configuracin del SAP Logon

El programa SAP Logn provee a los usuarios una forma sencilla de loguearse a un
sistema SAP a travs 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 Logn fue diseado para
front-ends de plataformas Windows.
El programa SAP Logon evala varios archivos de configuracin que se encuentran en
el front-end del usuario. Estos archivos tambin 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 parmetros. (ver tambin la cadena de conexin SAP GUI)

Figura 34 SAP Logon, Sistemas.

Se pueden realizar varias configuraciones generales a travs de las opciones de SAP

Logon. Se puede por ejemplo, configurar los niveles de trace para conexiones SAP GUI.
Las contraseas pueden tambin quedar registradas en el archivo de trace generado,
por lo que deberemos tener especial cuidado al utilizarlo; el archivo de trace debera
ser eliminado una vez que sea utilizado.
Podemos utilizar el botn Nueva entrada para crear una nueva conexin a un
sistema. Una especie de asistente nos lleva a travs de varias opciones para crear
nuevas conexiones. Hay tres posibles opciones:
1. La seleccin de un sistema que ya fue previamente configurado en el archivo

sapmsg.ini seguido de la seleccin del modo de logn: Grupo de logn o logn a una
instancia especfica.

Figura 35 Opcin 1

2. La definicin de una nueva conexin, eligiendo la opcin Sistema especfico 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 Opcin 2

3. La definicin de una nueva conexin tambin pero como sistema especfico de

usuario con la especificacin explcita de todos los detalles de conexin (Servidor de
aplicacin, nmero de sistema y ID de sistema) sin consultar al Message Server.

Figura 37 Opcin 3

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

Figura 38 - Activacin 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 dilogo que tenga configurada y los usuarios que ya
estn conectados a esta en el momento dentro del grupo de logn elegido.
El archivo de configuracin sapmsg.ini se evala 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
logn y servidores de aplicacin disponibles.
Para que la conexin al message server del sistema especfico en el archivo sapmsg.ini
funcione es necesario del archivo services de Microsoft Windows con el cual se
especifica el puerto de comunicacin 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 conexin es luego creada al servidor y al message server que corre sobre este
utilizando la informacin de los archivos sapmsg.ini yservices.
Resumen de la utilizacin de archivos por SAP Logon
Inicio de SAP Logon: lee saplogon.ini
Botn Acceder al Sistema: accede al sistema seleccionado

Botn Entrada Sistema Variable: Ningn cambio al archivo saplogon.ini, evala los
archivos sapmsg.ini y services.
Botn Nueva Entrada: Edita saplogon.ini, evala sapmsg.ini y el archivo services.
Botn Modificar Entrada: Edita saplogon.ini
Botn Borrar Entrada: Edita saplogon.ini
Con el botn Nueva Entrada, se puede crear una conexin 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 informacin que es relevante para
loguearse al sistema.

Figura 41 - Configuracin especfica de usuario

El nombre del servidor o direccin IP donde se encuentra la instancia a la que

queremos contactar y el nmero de sistema son esenciales, as tambin como el SID
del sistema y una descripcin.
El nmero de instancia especifica los ltimos dos dgitos del puerto de 4 dgitos que
utiliza el dispatcher de cada instancia. Los primeros dos dgitos son fijos, y son 32. Esto
significa que los nmeros de puertos entre 3200 y 3299 son posibles. Los puertos 3298
y 3299 estn asignados a los programas niping y saprouter y no se deberan utilizar
para los puertos de los dispatchers.
La configuracin para una conexin, tal como su nombre en el SAP Logon, puede ser
modificada utilizando el botn 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 conexin. El
Saprouter es un programa que acta como un punto intermedio en la conexin entre el
front-end y el sistema SAP.

Dnde se almacena cada archivo?

La siguiente lista muestra los archivos que mencionamos anteriormente y cules son
sus posibles ubicaciones; en el caso de mltiples lugares posibles, la secuencia que
utiliza SAP Logon tambin 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 opcin es configurar shortcuts (accesos directos) utilizando la solapa Accesos
Directos en el SAP Logon.
Con los shortcuts, necesitamos ingresar el password, despus de la cual el sistema nos
lleva directamente a una transaccin preasignada.
En teora, tambin 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 conexin SAP GUI
El string de conexin SAP GUI describe una serie de parmetros para llamar al
programa SAP GUI.
En su forma ms simple, una llamada a SAP GUI puede verse de la siguiente forma:
Sapgui
Si se va a utilizar un grupo de logn, la estructura de conexin es algo ms 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 logn seleccionado.
sapgui/M/<servidor_de_Message_Server>/S/<Puerto_Message_Server>/
G/<Grupo_de_Logon>
Esta sera la estructura completa de un string de conexin completo
sapgui/M/sapdp01/S/3600/G/SPACE sera un ejemplo concreto del string de conexin.

Utilizacin de Grupos de Logon

Los sistemas SAP muchas veces tienen ms que slo 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
utilizacin 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 dilogo
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 nmero 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 dilogo
Utilizar un grupo de logon para distribuir la carga de dilogo de la mejor manera
SAP recomienda que en los sistemas SAP con instancias mltiples configurar un grupo
de logon para las conexiones de dilogo 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 transaccin SMLG es la que nos permitir crear y administrar los grupos de logon en
el sistema.

Leccin 3: Transacciones de Anlisis

SM51 Ver las instancias activas y los servicios que cada una ofrece, dando clic en el
host name.

Dando clic en el botn Release Notes podemos observar la versin del Kernel

Para pasar a la transaccin sm04 podemos dar clic en el botn 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
botn Sessions.

Podemos cerrar alguna sesin del usuario.

La transaccin al08 es informativa, podemos observar los usuarios que se encuentran

logueados.

La transaccin sm50 muestra una vista de procesos,

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

En la transaccin sm21, podemos visualizar diferentes tipos de eventos registrados por

el sistema,

El nivel de prioridad identifica donde sucedi un problema

La transaccin st22, nos permite ver los errores en tiempo de ejecucin

programas ABAP

de los

La informacin 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 transaccin sm02 es utilizada para crear mensajes para ser visualizados por el
usuario del sistema, son visto por el usuario cuando cambia de transaccin.

Leccin 4: Inicio y parada del sistema SAP.

Leccin 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. Podra ser por ejemplo que existan problemas iniciando la base de
datos, lo que significa que el sistema SAP no podra 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 informacin muy til tal
como mensajes de error o descripcin de problemas.
Estos archivos estn 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 estn listados en el perfil de inicio de la
instancia (start profile).
El contenido de estos archivos de log por lo tanto depende de la configuracin
individual del sistema, y podra, por ejemplo, ser como sigue:
STDERR1: Informacin sobre el proceso de inicio del sistema de base de datos.
STDERR2: Informacin sobre el proceso de inicio del message server.
STDERR3: Informacin sobre el proceso de inicio del dispatcher.
Puedes configurar el nivel de detalle de la informacin registrada en cuatro niveles
diferentes a travs del parmetro de perfil rdisp/TRACE. Los posibles valores para este
parmetro 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 ms alto el nivel de traza, ms grande la cantidad de informacin registrada, y

por lo tanto mayor el tamao de los archivos generados. En conclusin, deberamos
incrementar el valor por defecto slo por perodos cortos para el anlisis de problemas.
El nivel de traza puede ser configurado por separado para cada work process en la
vista de procesos (Transaccin SM50).

Figure 43 - Anlisis 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 ms informacin en la leccin: Apndice: 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 nmero de ID de work
process que vemos en la transaccin SM50).
Si an puedes loguearte al sistema SAP, verfica el log del sistema utilizando la
transaccin SM21.

Leccin 6: Apndice - 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 cronolgico:
Inicio y parada de la base de datos.
Informacin sobre las reas fsicas 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 tamao. Un nuevo archivo de log
es creado despus 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 versin 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 versin ms vieja se almacena como ERRORLOG.6. En cada reinicio del SQL Server,
el archivo ms antiguo (ERRORLOG.6) se sobreescrito y los dems 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 versin.
Los mensajes registrados por el servicio SQLServerAgent tambin se almacenan en la
misma ubicacin con el nombre de archivo SQLAGENT.OUT. Las ltimas seis versiones
de este log tambin 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.
Informacin 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
parmetro 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 informacin:
El lugar en el cual el error ha sido reportado. Los IDs de la aplicaciones permiten la
comparacin entre entradas que pertenecen a una aplicacin particular tal como SAP
en el archivo db2diag.log
Un mensaje de diagnstico con la razn del error. El mensaje usualmente comienza
con DIA.
Toda la informacin disponible tal como la estructura de datos SQLCA y punteros a
otros archivos de dump o trap.
Informacin detallada sobre los errores se registra en los archivos de traza (trace) o
volcado (dump) DB2, los cuales tambin se almacenan en la ruta definida por el

parmetro DIAGPATH. Estos archivos son solamente creados si un problema serio

interno de DB2 ocurre.
Podemos acceder al directorio de volcado mediante la transaccin DB6COCKPIT y
seleccionando Diagnsticos > Directorio de Volcado en el rea de navegacin.
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
Informacin 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
parmetro DUMPDIR. El valor por defecto de este parmetro es /tmp.

Mantener el sistema y la base de datos

Leccin 1: Evaluacin de parmetros SAP
En muchas ocasiones, ya sea porque necesitamos resolver algn problema o porque
nos gustara realizar ajustes en el sistema para mejorar la performance del mismo
tendremos que evaluar y mantener los parmetros del sistema SAP.
Configuracin de los Parmetros del Sistema
La configuracin de las instancias y por lo tanto del sistema SAP se realiza usando los
parmetros del sistema. Los valores por defecto para estos parmetros son definidos
en el cdigo de programa del kernel del sistema.

Figura 49 Asignando los Parmetros del Sistema

La figura muestra los lugares donde estn definidos los parmetros del sistema y la
secuencia de lectura de los mismos. Tambin podemos observar que existe una
prioridad o peso del parmetro dependiendo de dnde lo definamos. Esto significa que
un parmetro 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
tambin 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 parmetros utilizando los archivos de
perfiles, los cuales son ledos cuando las instancias del sistema se levantan. Estos
archivos de perfiles son creados durante la instalacin del sistema y pueden ser
editados luego.
Como los archivos de perfiles son solamente ledos cuando inicia el sistema,
necesitamos reiniciar la instancia o el sistema completo despus de cambiar algn
parmetro.
El dynamic switching (cambio dinmico) de parmetros, el cual se realiza mientras el
sistema se encuentra operando, es posible para un pequeo grupo de parmetros del
sistema.

Figura 50 Archivos de Perfiles a nivel del Sistema Operativo

Los archivos de perfil son automticamente creados durante la instalacin. Despus de

que se completa la instalacin, los archivos de perfiles son almacenados a nivel del
sistema operativo en el directorio:
usr\sap\<SID>\SYS\profile
Este directorio puede ser ledo por todas las instancias de un sistema SAP utilizando las
tcnicas 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)
Visualizacin de los Parmetros
En principio, podemos cambiar estos archivos con herramientas de edicin 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 ms conveniente y seguro realizar los cambios de los parmetros de perfiles
utilizando las herramientas en el sistema SAP.

Figura 51 Archivos de Perfiles (Profile Files)

El perfil especfico por instancia de inicio, cuya nomenclatura es:

START<instancia><nmero 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 ledo 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 nmero de instancia>_<nombre de servidor>

define parmetros que aplican para una instancia, tales como el nmero y tipo de work
processes, o la definicin del tamao de rea de memoria principal asignada al sistema
SAP. El perfil de la instancia es por lo tanto especfico por instancia.

Figura 52 Visualizacin de Parmetros del Sistema

Los valores actuales de los parmetros del sistema pueden visualizarse en el sistema.
Para esto, podemos optar por dos maneras: el reporte RSPFPAR y la transaccin RZ11.
Ambas funciones muestran los parmetros para la instancia en la que el usuario se
encuentra logueado.
El reporte RSPFPAR muestra una lista de todos los parmetros especficos de instancia,
y de los parmetros que aplican para todo el sistema tambin. Esta lista se puede
acotar a un rango especfico de parmetros.
El resultado es una tabla donde se muestra por cada parmetro los valores por defecto
del sistema tal como estn 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 especfico de la instancia, se mostrar este valor tambin. Una breve descripcin
y, si se requiere, documentacin para los parmetros puede ser visualizada tambin.

Figura 53 Reporte RSPFPAR

La transaccin RZ11 muestra informacin y documentacin para los parmetros de

forma individual. Tambin muestra con el indicador Conmutacin Dinmica
(Dynamically Switchable) si el parmetro puede tomar un cambio de inmediato sin
tener que reiniciar el sistema.

Figura 54 Transaccin RZ11

Cuando modificamos un parmetro utilizando la transaccin RZ11, la modificacin se

mantendr mientras la instancia est activa. Una vez que reiniciemos la instancia el
valor del parmetro volver al que estaba definido previamente ya sea del kernel o del
perfil de la instancia.
Modificar parmetros que tienen la propiedad de conmutacin dinmica en la
transaccin 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 parmetros, transaccin RZ10.
En la tabla TPFYPROPTY, todos los parmetros que pueden ser cambiados
dinmicamente estn identificados con el indicador Dinmico (Dynamic). Puedes
utilizar la transaccin SE16, por ejemplo, para visualizar esta tabla.
Fuera del sistema SAP, podemos visualizar los parmetros a nivel del sistema operativo
si estamos trabajando con el usuario <SID>adm con el programa sappfpar. Podemos
obtener el valor actual de un parmetro con el comando sappfpar .
El comando sappfpar all devuelve una lista de todos los parmetros. Podemos verificar
que parmetros estn configurados utilizando sappfpar check. El comando sappfpar
help devuelve una breve ayuda sobre las posibles opciones de ejecucin del programa.
Tambin es posible especificar un perfil de instancia, un nmero 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=nmero de la instancia o name=SID

Para la evaluacin de los parmetros de perfiles utilizando las herramientas

descriptas, algunos parmetros de perfiles son los mismos para todo el sistema
mientras que otros sern diferentes por cada instancia. El reporte RSPFPAR
muestra la configuracin de la instancia en la que se ejecuta el mismo.

Leccin 2: Mantenimiento de parmetros SAP

Leccin 3: Configuracin de Modos de Operacin

Leccin 4: Tareas relacionadas a la base de datos de SAP

Esta primera leccin de tres, describe de una manera simple la arquitectura y
funcionalidad de las bases de datos relacionales. Basndonos luego en este
conocimiento, veremos cmo realizar las actividades primarias de la base de datos
mediante la planificacin en el calendario de base de datos, transaccin DB13.
Fundamentos de Administracin 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 informacin, y log files (archivos de registro) donde los cambios a la
informacin 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 utilizacin 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 pginas 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 pginas completas, se registran en el buffer de log.
Las entradas se escriben desde el log buffer al log file, el cual puede ser slo uno o
ms de uno dependiendo de la base de datos.

Para cada base de datos, existe un mecanismo que realiza un backup (respaldo) de la
informacin 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 informacin 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 podra perderse ante una
falla. Esto significa que habra un riesgo alto de prdida de datos ante una
destruccin del disco duro de los archivos de datos de la base.
Un sistema de base de datos siempre incluye datos estructurados que contiene
informacin esencial de la base de datos, tal como el nmero de data files.

Leccin 5: Backup y Recuperacin de la base de datos

Esta leccin muestra los conceptos sobre el respaldo de la base de datos. Estos
conceptos incluyen un backup regular de datos y de la informacin de log. Estos
backups son realizados mediante el calendario de planificacin de base de datos,
transaccin DB13.
Para proteger el sistema SAP contra la prdida de informacin 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 informacin de log y los datos estructurados de informacin de la base de
datos misma.
El backup de los data files y la informacin 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 informacin de log se respalda de forma separada.

Figura 56 Backup de Data Files e informacin de Log

Se pueden planificar ambos pasos en un sistema SAP (excepto en una plataforma

AS400) como acciones regulares utilizando el calendario de planificacin de base de
datos, transaccin DB13.

Escenarios para la Recuperacin de una Base de Datos

Si es necesario realizar una recuperacin 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 tambin de la
disponibilidad de los backups de informacin de log con la que contemos.
Si un backup de data files se pierde o est corrupto, una recuperacin puede basarse
en el ltimo backup vlido de data files y luego recuperarla a un punto ms reciente en
el tiempo, si los respaldos de informacin de log estn disponibles sin ningn faltante.
Esto significa que tenemos que contar con todos los backups de informacin de log
que se realizaron a partir del backup de data files que utilizamos para la recuperacin
hasta el punto en el tiempo que necesitemos recrear la base de datos.
Recuperar la base de datos (con prdida 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
recuperacin. Si ninguna accin se realiza luego de esto, todos los cambios a la
informacin (creacin, modificacin o borrado) que fueron realizados despus del
punto t1 se perdern.

Figura 57 Recuperacin con prdida de datos

Recuperar la base de datos (sin prdida 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 especficos
de la base de datos como por ejemplo una tabla determinada.
Luego, toda la informacin de log consecutiva respaldada desde el punto t1 (22,23,)
son tomados para la recreacin de la base de datos. En el ltimo paso, el archivo de
informacin de log que tena la base de datos hasta el punto del accidente es
recuperado. Esto significa que toda la informacin ahora est en el mismo estado
hasta el punto en el que ocurri la falla del disco duro.
Solamente si toda la informacin de log desde el ltimo backup de data files est
disponible, sin faltantes, la recuperacin de la base de datos ser sin prdida de datos.

Figura 58 Recuperacin sin Prdida de Datos

Almacenando los backups de data files e informacin de log

La informacin 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 prdida de informacin, es absolutamente
necesario contar con todos los backups de informacin 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 informacin de log ms antiguos del ltimo
backup de data files.
Otras consideraciones: Algunas base de datos tambin requieren de la informacin de
log para poder realizar una recreacin de la base de datos. Por lo tanto deberamos
asegurarnos que se realicen backups tanto de data files y la informacin 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 debera realizarse de la base de datos,
con un subsecuente backup completo de informacin de log.
Los medios de backup utilizados pueden ser sobrescritos nuevamente cada 28 das.
Esto es una recomendacin. Los backups podran ser retenidos por mucho ms tiempo
en una compaa.
SAP recomienda que la duracin de un ciclo de backup sea de 28 das. Esto significa
que los backups de data files e informacin de log son sobrescritos despus de 28 das,
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 opcin de realizar backups
diferenciales o incrementales de data files, lo que no realiza un completo backup de la
base de datos (estos backups sern referidos como backups parciales de ahora en
ms).

Si se utiliza un backup parcial de datos como estrategia diaria de backup, se debera

realizar un backup completo al menos una vez por semana. Debera haber al menos
cuatro backups completos de la base de datos contenidos en un ciclo de backup.
La informacin de log debera respaldarse al menos una vez por da. Tambin es
recomendable duplicar los medios de backup para la informacin de log para asegurar
que contamos con todos los backups de log en caso de que alguno se encuentre
defectuoso.
En muchas compaas generalmente se realizan backups de la informacin de log ms
de una vez por da con frecuencias de hasta 30 minutos. Esto depender muchas veces
de la cantidad de informacin que se modifique en la base de datos durante el da lo
que impacta directamente en un crecimiento de la informacin de log.
Por ltimo es recomendable realizar un backup de data file e informacin de log con
verificacin 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 informacin.

Planificacin y Monitoreo de Backups

En el sistema SAP, puedes planificar y monitorear backups regulares con la transaccin
DB13.

Figura 60 Transaccin DB13

Figura 61 Planificacin de Backup

Si por ejemplo utilizamos un medio externo como un dispositivo de cinta, deberemos

verificar que medio se requiere para el prximo backup cada da e insertar el medio
(cinta) correspondiente antes de iniciar el backup.
Verifica diariamente si los backups se han completado satisfactoriamente. En el
calendario de planificacin, 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 ejecucin del backup, por lo tanto es inutilizable.

Figura 62 Cdigo de colores de estado de tareas.

Informacin adicional se puede ver en la transaccin DB12, la cual nos permite

visualizar los registros de sucesos de las actividades realizadas en la base de datos.

Figura 63 Transaccin DB12

Esta transaccin adems del listado de registros, nos permite visualizar las reas de
datos y log utilizadas por la base de datos.

Figura 64 Transaccin DB12 2/2

A partir de la versin SAP Web Application Server 6.10, es posible controlar y

monitorear los backups para todos los sistemas del landscape con el calendario de
planificacin central, transaccin DB13C. La planificacin se transfiere a los sistemas
remotos utilizando una conexin de tipo RFC.
DB13 fue mejorada para la versin 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 botn de documentacin
sobre las tareas que son
recomendaciones.

posibles

, nos puede dar mayor informacin

realizar desde la transaccin DB13 y

Leccin 6: Monitoreo de base de datos

Dependiendo de la base de datos que se utilice para el sistema SAP, existe una
cantidad de verificaciones peridicas que deben llevarse a cabo adicionalmente a la
realizacin 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

Adems de los chequeos de la ejecucin de los respaldos de la base de datos, existe
una serie de verificaciones que podremos realizar mediante la transaccin DB13
tambin.

Figura 65 Monitoreo de Base de Datos

Estas verificaciones, incluyen entre otras:

Generacin de estadsticas 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 generacin peridica de estadsticas 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 condicin WHERE especifica el nmero de registros que se
obtendrn para la consulta. La base de datos debe encargarse ahora de obtener la
informacin tan rpido 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 travs de un ndice (index scan). Utilizando las
estadsticas, 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 ms econmico) camino de acceso.

Figura 66 Determinando el Mejor Camino de Acceso

Actualizacin de Estadsticas
Las estadsticas contienen informacin sobre el nmero de entradas en la tabla, el
nmero de bloques que son ocupados por la tabla y el ndice de la tabla y la
selectividad de los registros segn los valores de los campos.
La duracin recomendada para la generacin de las estadsticas puede variar
dependiendo de la base de datos que utilicemos o de la versin. En principio, la
actualizacin de estadsticas solo tienen que ser generadas cuando una tabla ha
crecido o reducido notablemente su tamao. Esto es porque la generacin de
estadsticas en el entorno SAP se ejecuta en dos pasos:

En el primer paso, un chequeo es realizado para determinar si es necesaria la

generacin de estadsticas para la tabla. Para hacer esto, el nmero actual de registros
de datos se compara con el nmero de registros de datos que existan la ltima vez
que se ejecutaron las estadsticas.
En el segundo paso, las estadsticas son generadas para todas las tablas para las
cuales su tamao ha cambiado de manera considerable.
Dependiendo de la base de datos que se use, ambos pasos son planificados en la
transaccin DB13 en un nico job o en jobs separados.
La generacin de estadsticas es sumamente importante para el acceso eficiente a los
datos y debera ser verificado regularmente por el administrador.

Monitor CCMS
Otra tarea importante del administrador adems 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 seccin 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
tambin la performance y las actividades planificadas tales como el backup y la
generacin de estadsticas.

Figura 67 Monitor CCMS: Base de Datos.

La transaccin DB02 nos permite realizar un anlisis del estado de la base de datos,
donde podemos verificar entre otras cosas el tamao total de la base de datos y el
espacio ocupado realmente o estadsticas de las tablas e informacin sobre tablas o de
ndices perdidos as tambin como el nivel de llenado histrico.

Figura 68 Anlisis de Base de Datos (DB02)

DBACOCKPIT
La transaccin 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 transaccin DBACOCKPIT y
desde all realizar todas las tareas necesarias para la administracin de la base de
datos.

Figura 69 Transaccin DBACOCKPIT

Usuarios, Roles y Autorizaciones

Leccin 1: Concepto de Administracin 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 Administracin de Usuarios

El concepto de registro maestro de usuario y el concepto de autorizacin sern
explicados con mayor detalle abajo. Ambos conceptos son muy importantes para
comprender mejor los sistemas SAP.

Figura 70- Usuarios en el ambiente SAP

El trmino usuario generalmente se utiliza para hacer referencia a una identificacin 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 contrasea vlidos.
Los sistemas operativos, las bases de datos y el sistema SAP usualmente tienen
diferente conceptos de autorizacin. Si una combinacin de usuario y contrasea 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
contrasea. De todas formas, es posible que una combinacin idntica de usuario y
contrasea 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 aplicacin SAP y del servidor
de la base de datos deben ser protegidos o la operacin y los datos del sistema SAP
pueden ponerse en riesgo.
Autorizaciones

Figura 71 Usuarios y Autorizaciones

La proteccin de autorizaciones se realiza en dos niveles:

1- Puede una transaccin ser accedida?
2- Autorizaciones para realizar acciones y tratamiento de datos durante el
uso propio de la transaccin.
Una persona puede loguearse a un cliente de un sistema SAP si conoce la combinacin
de usuario y contrasea. Si el usuario luego intenta iniciar una transaccin para la cual
no tiene autorizacin, el sistema rechaza al usuario con un mensaje de error
apropiado.
Si el usuario inicia una transaccin para la cual tiene autorizacin, el sistema muestra
la pantalla inicial de la transaccin. Dependiendo de la transaccin que haya ejecutado,
el usuario ingresa datos y realiza acciones en la pantalla. Verificaciones adicionales de
autorizacin 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 prximas 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 propsitos:
Dilogo
Un usuario normal de Dilogo se utiliza para todas las formas posibles de logn por
una persona. Durante un logn de dilogo, el sistema verifica si la contrasea es inicial
o expir entonces el usuario tiene la oportunidad de cambiar su contrasea.
Tambin el sistema verifica si mltiple sesiones son creadas con el mismo usuario y si
permite que el usuario decida qu hacer en los casos que sea posible utilizar mltiples
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 ningn otro mtodo que pueda utilizar una persona,
podemos decir que no es interactivo.
Tambin 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 parmetro
de sistema del perodo de validez de contrasea. Solo los administradores pueden
cambiar la contrasea.
Comunicaciones
Utiliza el usuario de tipo Comunicaciones para el logn de usuarios no-interactivos
entre sistemas. No es posible utilizar estos usuarios para un logn de dilogo. La
configuracin usual del perodo de validez de contrasea aplica para estos usuarios
tambin.
Servicio
Un usuario de tipo Servicio es un usuario de dilogo que est disponible para un gran
nmero de usuarios annimos. En general, estos tipos de usuarios estn muy
restringidos en cuanto a autorizaciones.
Los usuarios de Servicio son usados, por ejemplo, para accesos annimos al sistema
utilizando ITS o servicios ICF. El sistema no verifica por la validez de la contrasea
durante el logn de este tipo de usuarios, por lo que estn exentos.
Solamente el administrador de usuarios puede cambiar la contrasea. Mltiples
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

Transaccin de Administracin de Usuarios SU01.

Para iniciar el mantenimiento de usuarios, transaccin 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 informacin y configuraciones que se
requieren para poder loguearse a un cliente del sistema SAP. Estos datos estn
divididos en las siguientes solapas de la transaccin SU01:
Address: informacin personal y de contacto.
Logon data: perodo de validez de la contrasea y del usuario. Tipo de usuario.
Defaults: valores por defecto para una impresora, lenguaje de logn, etc.
Parameters: Valores especficos de usuario para campos estndar en el sistema SAP.
Roles and Profiles: Roles y perfiles que son asignados al usuario.
Groups: Asignacin de grupos para el usuario, utilizado para el mantenimiento masivo
de usuarios.
El requisito mnimo para la creacin de usuarios es ingresar al menos el apellido (Last
Name) en la solapa Address, y la contrasea inicial en la solapa Logon Data.

Leccin 2: Concepto de Autorizacin.

Las autorizaciones de los usuarios son creadas usando roles y perfiles. Los
administradores crean los roles y el sistema provee el soporte para la creacin de las
autorizaciones asociadas.

Objetos de Autorizacin y Chequeo de Autorizacin

Comprender el concepto de autorizacin de SAP requiere el conocimiento del rol y
perfil de autorizacin en el registro maestro de un usuario. Esta leccin provee el
conocimiento necesario para poder crear los roles y autorizaciones propios.

Figura 74 Objetos de Autorizacin

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

Figura 75 Verificacin de Autorizacin

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 transaccin SU56) del
servidor de aplicacin.
Cuando el usuario llama a la transaccin, el sistema
autorizacin necesaria en el contexto de usuario para
verificaciones de autorizacin 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 transaccin. Las
que existen en el contexto de
podra ser necesario para este
poder utilizar estas nuevas

Si la verificacin de autorizacin para llamar a la transaccin es exitosa, el sistema

luego muestra la pantalla inicial de la transaccin. Dependiendo de la transaccin, el
usuario puede crear datos o seleccionar acciones. Cuando el usuario realiza la accin,
los datos son enviados al dispatcher, el cual los pasa a un work process para que
ejecute el procesamiento.
Verificaciones de autorizacin (AUTHORITY-CHECK) que son realizadas durante la
ejecucin en el work process son programadas dentro del cdigo 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
verificacin (cdigo de retorno = 0), los datos y las acciones son procesadas y la
prxima 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 evaluacin del cdigo de retorno. En este caso, no sera
igual a 0.
Todas las autorizaciones son permisos. No hay autorizaciones para prohibir.
Todo aquello que no est explcitamente permitido est prohibido. Esto es lo
que se conoce como concepto de autorizacin positivo.
Mantenimiento de Roles: Men y Autorizaciones

Figura 76 Mantenimiento de Roles

El Mantenimiento de Roles (transaccin PFCG, previamente tambin llamada Profile

Generator o Activades de Grupo) simplifica la creacin de autorizaciones y sus
respectivas asignaciones a los usuarios.
En el mantenimiento de roles, las transacciones, que desde el punto de vista de la
compaa, pertenecen a un mismo grupo se seleccionan. El mantenimiento de roles
crea las autorizaciones con los valores de campos requeridos para los objetos de
autorizacin que son verificados en la transaccin 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 ms 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 travs de los roles.

Figura 77 Men de usuario

Puedes acceder al mantenimiento de roles con la transaccin 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 botn 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 botn Report, puedes integrar reportes (programas ABAP). En este
caso la transaccin PFCG se encarga de crear los cdigos de transaccin (si es que no
existen para el reporte) con el cual los reportes luego pueden ser accedidos.
Si seleccionamos el botn Other, es posible agregar direcciones de internet o vnculos
a archivos.
Modificacin de Mens: podemos crear, mover, borrar y renombrar directorios y subdirectorios si es necesario. La funcin Drag&Drop se puede utilizar tambin.

Figura 78 Generando Perfiles de Autorizacin

El mantenimiento de roles automticamente crea las autorizaciones que estn

asociadas con las transacciones especificadas en el rbol del men. De todas maneras,
todos los valores de autorizacin 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 estn creando o modificando los roles.
Selecciona la solapa Authorizations y luego el botn Change Authorization Data o
Display Authorization Data, dependiendo en cual modo estemos trabajando en la
transaccin 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
autorizacin.
El significado de los indicadores es el siguiente:
Luz verde: el objeto de autorizacin tiene un valor propuesto para cada uno de los
campos.
Luz amarilla: el objeto de autorizacin necesita mantenimiento manual al menos
para uno de los campos.
Luz roja: Los niveles organizacionales no estn definidos.

Figura 78_b Significado de los indicadores

La falta de un valor propuesto por PFCG para alguno de los campos del objeto de
autorizacin 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 botn
todos los objetos de autorizacin que lo contienen.

entonces los cambios afectarn a

Qu son los Niveles Organizacionales? Son campos determinados por SAP en el

Concepto de Autorizacin que se refieren a la estructura de la compaa. Estos
campos aparecen en la mayora de las autorizaciones. Por lo tanto dentro de un rol
estos campos pueden aparecer muchas veces. El botn Organizational levels en la
transaccin PFCG facilita su mantenimiento.

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

Figura 79 Asignacin de Roles a Usuarios

Los usuarios pueden recibir ms de un rol, esto es til para algunas actividades (como
impresin) que sern permitidas para la mayora de los usuarios.
La asignacin de roles a los usuarios no otorga automticamente las correspondientes
autorizaciones a los usuarios. Para asignar las autorizaciones, es necesario realizar una
comparacin de registros de usuarios mediante la cual los perfiles de los roles son
insertados en el registro maestro de usuario.

Figura 80 Comparacin de Registro Maestro de Usuario

Una comparacin de registros maestros de usuarios determina si los perfiles de

autorizacin deben ser agregados o eliminados del usuario basndose en la asignacin
de roles para este.
Durante una comparacin se agregarn perfiles al maestro de usuario si nuevos roles
son agregados.
Si la asignacin 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 comparacin puede realizarse por cada rol individualmente. Seleccionando el rol en
la funcin de mantenimiento de roles en la solapa User y luego seleccionando User
comparison. En la ventana que aparece, seleccionamos Complete comparison.

Para ms informacin, selecciona el botn de informacin

en la transaccin PFCG y
el
mismo
botn
en
la
comparacin
de
maestros
de
usuarios.
Durante una comparacin completa, los perfiles obsoletos son eliminados.
Si mltiples asignaciones de roles va a ser actualizada, puedes realizar una
comparacin en la transaccin PFCG seleccionando Utilities Mass comparison o
llamando a la transaccin PFUD. Puedes seleccionar los roles que desees o actualizar
todas
las
asignaciones
si
ingresas
el
caracter
asterisco
(*).
Tambin puedes activar una comparacin de registros maestros de usuarios
peridicamente si seleccionas Utilities Mass comparison. Selecciona la opcin
Schedule o Check job for full reconciliation. El sistema luego muestra una ventana de
bsqueda para el job de background PFCG_TIME_DEPENDENCY. Si no encuentra el
job, tenemos la opcin de crear uno. El valor por defecto es que todos los registros
maestros de usuarios sern comparados una vez por da.

Leccin 3: Asignacin de Roles y perfiles

Leccin 4: Parmetros de Login e informacin de usuario.

En esta leccin veremos una serie de parmetros importantes para la administracin
de usuarios, por ejemplo, el comportamiento de logon.
Parmetros del Sistema para Logon de Usuarios

Figura 81 Parmetros del Sistema para Logon de Usuarios 1/2

Podemos especificar la longitud mnima de la contrasea con el parmetro

login/min_password_lng.
El parmetro login/min_password_digits, login/min_password_letters,
login/min_password_lowercase, login/min_password_uppercase, y
login/min_password_specials especifican el nmero de dgitos, letras (maysculas y
minsculas) o caracteres especiales que una contrasea puede contener. El rango de
valores es entre 1 y 40.
El parmetro login/password_expiration_time especifica el nmero de das en los
cuales un usuario debe cambiar su contrasea. Si el parmetro se configura en 0, el
usuario no necesita cambiar su contrasea.
Existen algunas reglas generales sobre las contraseas que no pueden desactivarse.
Una contrasea:
Debe ser al menos de 6 caracteres de largo.
No puede comenzar con ? o !
No puede ser pass
La nueva contrasea debe diferir de la anterior al menos en 1 carcter.
La configuracin que determina que los usuarios deben crear una nueva contrasea
que difiera de las 5 ltimas no es ms mandataria. Se puede utilizar el parmetro
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 ofrecan los parmetros
login/password_max_new_valid y login/password_max_reset_valid. Estos parmetros
especificaban por cuanto tiempo una contrasea inicial para un usuario creado o una
contrasea recreada por el administrador del sistema para un usuario era vlida. Con
SAP Netweaver AS 7.0, estos parmetros han sido reemplazados por
login/password_max_idle_initial.
El parmetro login/password_max_idle_initial indica por cunto tiempo una
contrasea nueva (seleccionada por un administrador) permanece vlida si no es
utilizada. Una vez que el perodo se cumple, la contrasea no puede ser utilizada
para la autenticacin en el sistema.
El administrador de usuarios puede reactivar la contrasea asignando nuevamente una
contrasea inicial.
Otro nuevo parmetro introducido luego de la versin SAP Web AS 6.40 es
login/password_max_idle_productive. Este indica el mximo tiempo que una
contrasea productiva (contrasea seleccionada por el usuario) permanece vlida
cuando esta no es usada.
Una vez que este perodo ha caducado, la contrasea no puede ser utilizada para
autenticacin. El administrador de usuarios puede reactivar la contrasea mediante la
asignacin de una nueva contrasea inicial.
Con el parmetro login/min_password_diff, el administrador puede determinar el
nmero de caracteres diferentes que una contrasea nueva debe poseer en
comparacin con la contrasea anterior. Este parmetro no tiene efecto cuando la
contrasea del usuario es creada o reactivada.

Figura 82 Parmetros del Sistema para Logon de Usuarios 2/2

Figura 83 RZ11: Parmetros de Logon

Puedes configurar el nmero de intentos fallidos de logon despus de los cuales SAP
GUI se cierra usando el parmetro login/fails_to_session_end. Si el usuario quiere
intentar de nuevo, deber reiniciar SAP GUI.
Puedes tambin configurar el nmero de intentos fallidos de logon despus de los
cuales el usuario se bloquea en el sistema SAP usando el parmetro
login/fails_to_user_lock. El contador de intentos fallidos se reinicia despus 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
automticamente por el sistema, valor por defecto desde la versin SAP Netweaver
7.0. Se puede reactivar este desbloqueo automtico con el parmetro
login/failed_user_auto_unlock = 1.
El administrador puede desbloquear, bloquear o asignar una nueva contrasea a los
usuarios en la transaccin SU01, mantenimiento de usuarios.
Si el parmetro login/disable_multi_gui_login se configura con el valor 1, un usuario no
puede ingresar a un cliente ms de una vez, o sea con ms de una sesin. Esto puede
ser til por razones de seguridad del sistema. Si el parmetro est configurado en 1, el
usuario tendr las siguientes opciones cuando abre ms de una sesin:
Continuar con este logon y finalizar cualquier otro logon en el sistema.
Terminar este logon.
Tenemos la opcin de excluir de este parmetro a los usuarios que especifiquemos en
el parmetro login/multi_login_users separados por comas y sin espacios.

Usuarios estndar

Figura 84 Usuarios estndar

Esencialmente, hay dos tipos de usuarios estndar: aquellos creados por la instalacin
del sistema SAP y aquellos creados durante la copia de un cliente.
Durante la instalacin del sistema SAP, el cliente 000 y 066 son creados (el cliente 001
no siempre es creado durante la instalacin. Es creado por ejemplo durante la
instalacin de un sistema ERP 6.0).
Usuarios estndar son predefinidos en los clientes. Como estos nombres de usuarios y
sus contraseas son estndar, 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 estndar 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 contrasea pass y autorizacin de acceso irrestricto
para el sistema.
Cuando instalamos un sistema SAP, un registro maestro de usuario se crea
automticamente para SAP* en el cliente 000 (y 001 si existe). Durante el proceso de
instalacin
se
nos
solicitar
indicar
una
contrasea.
La instalacin solo nos permitir continuar una vez que una contrasea 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 contraseas 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
logstica de software.
Cuando instalamos el sistema, un registro maestro de usuario
automticamente en el cliente 000 (y 001 si aplica) para el usuario DDIC.

se

crea

Con este usuario tambin, se nos requerir cambiar la contrasea estndar durante la
instalacin. Ciertas autorizaciones son predefinidas en el cdigo del sistema para el
usuario DDIC, lo que significa que por ejemplo, solo el usuario DDIC puede realizar un
logon al sistema durante la instalacin de una nueva versin (upgrade).
En versiones anteriores las contraseas que tenan por defecto los usuarios SAP*
y DDIC eran 06071992 y 19920706 respectivamente. Luego era necesario
modificar estas contraseas una vez instalado el sistema.

El usuario EarlyWatch
El usuario EarlyWatch se crea en el cliente 066 y est protegido con la contrasea
support. Los expertos de SAP del servicio EarlyWatch son quienes utilizan este usuario.
Este usuario no debe ser borrado ni la contrasea 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 creacin del mismo en el proceso de instalacin.
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 cdigo del sistema (kernel).
Para proteger el sistema contra accesos no autorizados, debemos crear un registro
de usuario para este usuario estndar. Crea un usuario SAP* con autorizaciones
totales en el sistema (perfil SAP_ALL).

Si borramos el registro de usuario SAP* (tabla USR02), la contrasea inicial pass con
las propiedades vuelven a ser vlidas nuevamente: el usuario tiene autorizaciones
totales ya que no se realizan verificaciones de autorizacin para este usuario.
La contrasea estndar 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 parmetro del sistema login/no_automatic_user_sapstar con el
valor 1. Si el parmetro est activo, o sea con el valor 1, SAP* no es vlido en el
sistema. Si el registro maestro de usuario de SAP* es borrado, el logon con la
contrasea pass no funciona.

Si quisiramos reinstalar el comportamiento anterior de SAP*, debemos cambiar el

parmetro con el valor 0 y reiniciar el sistema.
Es conveniente activar el parmetro en el perfil global del sistema DEFAULT.PFL para
que tenga efecto en todas las instancias del sistema (de todas formas si existiera el
parmetro tambin en un perfil de instancia con el valor 0, este sobrescribe el que est
en el perfil global).
Tambin 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 parmetro es desactivado
(valor 0).

Leccin 5: Concepto Administracin Avanzada de Usuarios

Administracin Central de Usuarios

Figura 85 Administracin Central de Usuarios

Cuando tenemos que operar mltiples sistemas SAP con una determinada cantidad de
clientes y tenemos que crear usuarios idnticos varias veces en diferentes clientes,
podemos reducir significativamente el esfuerzo de administracin usando
Administracin Central de Usuarios, que por las siglas en ingls se conoce como CUA
(Central User Administration). Podremos realizar la administracin 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 administracin 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 tambin especificar que informacin del registro maestro de usuario podr ser
mantenida de forma central y que informacin se podr mantener de forma local

tambin. Algunas veces es til permitir que cierta informacin de usuarios sea
mantenida de forma local por los usuarios o por un administrador en los sistemas hijos.
La informacin del usuario se intercambia mediante ALE. ALE significa Application Link
Enabling y es una tecnologa 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 conexin permanente. El procesamiento asincrnico
de la comunicacin asegura que la operacin sea libre de errores.

Figura 86 - Qu Informacin Puede Ser Distribuida?

La siguiente informacin puede ser distribuida utilizando CUA:

Registro Maestro de Usuarios: Direccin, Datos Logon, Valores Fijos, Parmetros
(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.
Contrasea inicial: Cuando los usuarios son creados una contrasea 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 autorizacin desde el
sistema central. De todas formas, los perfiles de autorizacin se mantienen localmente
ms bien que de forma central ya que diferentes configuraciones de sistema y
versiones pueden requerir una administracin local de los perfiles de autorizacin.

Comunicacin y Logstica de Software

Leccin 1: Fundamentos de Conexiones RFC
Los sistemas SAP pueden comunicarse entre s utilizando Llamadas de Funciones
Remotas, que por sus siglas en ingls 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 aos como la
interfaz tcnica con la que los sistemas SAP y no-SAP usualmente se conectan. No
tiene relevancia si el intercambio de informacin se realiza de manera sincrnica o
asincrnica, peridica o aperidica, o transaccional.

Figura 87 La interfaz RFC

Una RFC es la llamada a un mdulo de funcin que est corriendo en un sistema

diferente al programa que realiza la llamada. Podemos llamar a un mdulo de funcin
en el mismo sistema mediante una RFC tambin. De todas maneras, las RFCs
normalmente son utilizadas cuando los mdulos 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 funcin. 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 Programacin Comn
Para Comunicaciones, por sus siglas en ingls CPI-C (Common Programming Interface
for Communication) y permite comunicacin 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
comunicacin. Para una llamada RFC, la interfaz RFC:
Convierte todos los parmetros al formato requerido en el sistema remoto.
Invoca a las rutinas de comunicacin que se requieren para la comunicacin con el
sistema remoto
Maneja los errores que pueden ocurrir durante la comunicacin.
La interfaz RFC es de fcil utilizacin para los programadores ABAP. Los pasos de
procesamiento para el llamado a los programas externos estn integrados dentro de la
sentencia CALL FUNCTION.

Figura 88 Conexiones RFC

Para poder llamar a una funcin remota (en un sistema remoto), deberemos definir el
sistema remoto como un destino en el sistema desde donde realizamos la
llamada. Tambin se requiere autorizacin de acceso para el sistema remoto.
Se pueden manejar estas conexiones remotas en el sistema que llama. Para hacer
esto, utilizamos la funcin 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 transaccin SM59. Los tipos
de conexin y todos los destinos existentes se muestran en una estructura de rbol en
la pantalla inicial. Para detalles sobre los tipos de conexin disponibles, podemos
observar la documentacin.
Hay una funcin de bsqueda para los destinos que ya estn configurados. Para
realizar una bsqueda, selecciona Search
y luego ingresa el nombre o parte del
nombre. El sistema mostrar una lista de las entradas que concuerden.
Para modificar una conexin RFC existente, seleccionamos el destino RFC en el men
de rbol y seleccionamos Change
Para copiar una conexin RFC existente, primero tenemos que ingresar a la
conexin RFC que queremos copiar. Luego seleccionar Connection Copy.

Variantes de Utilizacin de RFC

RFC sincrnica (sRFC)
Para comunicacin entre diferentes sistemas y entre SAP Netweaver AS y SAP GUI. En
estas comunicaciones el llamado a la funcin remota se basa en una comunicacin
sincrnica por lo que el sistema remoto debe estar disponible en el momento de la
llamada.
RFC asincrnica (aRFC)
Para comunicacin entre sistemas y para procesamiento paralelo de tareas. Con este
tipo de comunicacin, aunque no es realmente asincrnica ya que el sistema remoto
debe estar disponible al momento de la comunicacin, el sistema origen (desde donde
se realiza la llamada a la funcin remota) no necesita esperar una respuesta del
sistema remoto para continuar su procesamiento y en este sentido es por el cual se
denomina asincrnica.
RFC transaccional (tRFC)
Este mtodo si utiliza una forma de comunicacin realmente asincrnica. 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 extensin 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 trmino general para diferentes variantes de implementacin. sRFC es la
llamada de mdulo de funciones sincrnica. Esto significa que el cliente espera hasta
que el servidor ha completado el procesamiento de la funcin remota.
Dentro un sistema SAP, una RFC puede tambin ser ejecutada de forma asincrnica
mediante el uso de otro work process. La variante se conoce como aRFC.
Tambin est tRFC que es la Llamada de Funcin Remota Transaccional, la cual es
asincrnica ya que asegura que la informacin puede ser enviada ms de una vez al
sistema destino si problemas de comunicacin en la red suceden y son reconocidos del
lado del servidor. Para esto un identificador de Transaccin (TID) se asigna al llamado.
Esto es til para prevenir que la informacin se procese ms de una vez en el sistema
lo que podra ocasionar informacin errnea en la aplicacin debido al procesamiento
asincrnico.
qRFC con cola de envo es una extensin de tRFC. Crea una capa entre la aplicacin y
tRFC y permite enviar los parmetros de la funcin remota si no existen ejecuciones
anteriores pendientes en la cola. Luego de que una unidad lgica de trabajo (LUW) es

ejecutada, el coordinador de qRFC automticamente procesa el siguiente llamado en

concordancia con la secuencia de la cola.

Leccin 2: Configuracin de Conexiones RFC

Transaccin SM59

Leccin 3: Estructura de Sistemas SAP

En esta leccin veremos la estructura de datos de un sistema SAP. Tminos como
cliente, customizing (adaptacin) dependiente de cliente y customizing inter-cliente
(cross-client), datos maestros y de transacciones, datos de usuario y repositorio de
objetos sern descriptos. Por ltimo las opciones para modificar y crear objetos de
repositorio sern parte de la leccin tambin.
El software de SAP necesita ser adaptado a los requerimientos especficos de las
compaas. Cmo podemos transferir esas adaptaciones desde el sistema de
desarrollo al sistema de produccin? El esfuerzo de trabajo extra debemos procurar
que sea mnimo cuando importamos Support Packages o durante un posible Upgrade
del sistema. Veremos cmo 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 especfica. Adicionalmente a las
configuraciones de negocio (customizing) que son relevante nicamente para ciertos
clientes del sistema SAP, tambin 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
semnticamente. Diferentes objetos de desarrollo (programas, tablas, pantallas,
mdulos de funcin, clases, etc) pueden estar contenidos dentro de un paquete.
Los paquetes estn caracterizados por ciertas propiedades:
Anidado (nesting)
Interfaces (interfaces)
Visibilidad (visibility)
Accesibilidad (accesibility)
Los paquetes son creados y mantenidos con Package Builder, la transaccin SPAK.
El grabado y transporte de modificaciones de objetos est controlado por el Sistema de
Transportes y Cambios, que por sus siglas en ingls se denomina CTS (Change and
Transport System) utilizando la asignacin de objetos de repositorios a paquetes.

Customizing
El trmino Customizing, que se podra traducir como adaptaciones, describe las
configuraciones de negocio de un sistema SAP. Las funciones provistas tantos
generales de una compaa como aquellas que pueden ser especficas para una
industria son adaptadas a los requerimientos especficos de la empresa en el proceso
de Customizing.
El Customizing comprende cosas simples y bsicas como la definicin de plantas y
almacenes hasta cosas ms complejas como funciones de compras basadas en
planificacin de produccin o liquidacin de nmina.
Una gran cantidad de Customizing estndar tal como definiciones de pas, lenguaje,
uso horario estn 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 impresin o el acceso a la ayuda.
Clientes
Los sistemas SAP estn divididos entre unidades de negocio o clientes, que tambin
se conocen como mandantes.
Un cliente es una unidad comercial, organizacional y tcnica 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 especficos
de cliente.
Los tipos de datos que son dependientes de un cliente estn relacionados entre s. Por
lo tanto, cuando ingresamos informacin en una aplicacin, el sistema verifica si la
informacin ingresada concuerda con la configuracin especfica de ese cliente
(Customizing). Si hay inconsistencias, la informacin ingresada en la aplicacin es
rechazada. Esto nos dice que la informacin de una aplicacin es significativa en
trminos del negocio solamente en el cliente con el Customizing correspondiente.
Ejemplos de Customizing dependiente de cliente son los cdigos de compaa, plantas
y almacenes.
Datos Maestros y de Transacciones son dependientes del cliente tambin. Son
nicamente vlidos en el cliente. Esto incluye por ejemplo registros maestros de
materiales, rdenes y facturas. Los datos de usuario tambin 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

propsitos de pruebas y en un sistema de produccin, un cliente para trabajo

productivo. Los roles se asignan a los clientes desde la transaccin 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 tambin. Se pueden
realizar cambios o mejoras en el repositorio de objetos. Los cambios o mejoras al
repositorio pueden realizarse en diferentes formas:
Extensin del repositorio a travs 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, tambin requerir un nombre
de espacio propio a SAP que empiece y termine con el caracter /. Este tendr un
mximo de ocho caracteres inlcuyendo /, tal como /Firma/.
Todos los objetos que se creen bajo el nombre del espacio tendrn 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 estndar de SAP puede ser
suplementado con cdigo propio del cliente en puntos predefinidos en el cdigo
conocidos como customer exits (salidas de cliente). Las estructuras de tablas pueden
ser ampliadas con campos propios utilizando appends (agregados)
Modificaciones al estndar del sistema SAP: cambios a objetos estndar 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 mltiples basado en la conformacin 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 tambin como
productivo. En circunstancias normales, un landscape de tres sistemas es suficiente
para la operacin.

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 tambin 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 operacin de produccin. Una prueba de aceptacin usualmente no es
posible realizarse en el sistema de desarrollo, ya que los datos reales no estn
disponibles
en
este
sistema
para
una
prueba
real.
La razn 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 nmero 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 produccin. Diferentes
clientes pueden ser creados para propsitos especficos. Si realizamos un Customizing
dependiente de cliente en el sistema de desarrollo y queremos verificarlo antes de
transportarlo a los dems sistemas, puede utilizarse un cliente de prueba en el mismo
sistema de desarrollo para tal propsito.
Clientes con roles especficos 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 produccin.
Generalmente, los clientes principales de cada sistema tienen el mismo nmero ya que
por defecto cuando transportamos el cliente origen es igual al cliente destino. Esto
ltimo de todas formas no es obligatorio.

Leccin 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 produccin. 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), transaccin SE09 o SE10. Como
parte de una orden de transporte, el lder 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.
Despus que cada tarea individualmente es liberada, la orden de transporte puede ser
liberada tambin. Liberar la orden de transporte genera que esta sea exportada.
Despus de que se realiza la exportacin, 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 configuracin del sistema, necesitaremos asignar a una tarea, la cual est
incluida en una orden de transporte, cada modificacin o nuevo objeto que creemos o
configuracin de Customizing que realicemos.
Cuando un proyecto de desarrollo comienza, el lder del proyecto idealmente deber
crear una o ms 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 lder 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, transaccin 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 dgitos que
combinados forman una secuencia alfanumrica. Por ejemplo DEVK901234.
Una orden de transporte debera contener objetos que estn lgicamente relacionados
y sern transportados juntos. Esto es, una orden de transporte nos permite transportar
y administrar desarrollos completos, lgicos y auto-contenidos. Una nueva orden de

transportes no es requerida para cada objeto, ya que esto resultara en una gran
cantidad de rdenes de transportes y la administracin se volvera compleja y confusa
lo que tambin llevara 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 convencin de nombres para las tareas es la misma que para las rdenes de
transporte. Una orden de transporte se diferencia entre varios trminos.
El trmino orden de transporte es el trmino general o neutral. Una orden de
modificacin o cambio es una orden de transporte utilizada para transportar cambios.
Los objetos que contiene, pueden por supuesto, ser transportados sin que ningn
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 consolidacin es una orden de transporte que ser
transportada al sistema de consolidacin (sistema de calidad).
Transportes
El transporte de objetos est dividido en las fases de Exportacin e Importacin: 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 produccin.

Figura 94 Transportes en un Landscape de Tres Sistemas

La liberacin de una orden de transporte dispara la exportacin 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 informacin respecto del xito de la liberacin y la exportacin queda
guardada en el log (registro) de transporte de la orden de transporte.

La importacin en el sistema destino es usualmente no automtica, pero es iniciada

por el administrador de transportes en el Sistema de Gestin de Transportes, que por
sus siglas en ingls se conoce como TMS (Transport Management System) y podemos
acceder mediante la transaccin STMS.
Los registros de importacin tambin son guardados en el log de transporte.

Figura 95 Log de Transporte

En trminos tcnicos, una copia de los datos desde la base de datos del sistema de
desarrollo se escribe al directorio de transportes central durante la exportacin de la
orden de transporte. Durante la importacin, 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 fsicamente 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 ubicacin del directorio de transportes que utilizar, ya sea
para escribir o leer las rdenes de transporte, por medio del parmetro de perfil
DIR_TRANS. La ubicacin por defecto del directorio de transportes es:
/usr/sap/trans
De todas maneras, esto puede ser adaptado segn 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 ms
complejo, pero podra ser til en algunos casos por razones de seguridad de la red.

Importacin
El administrador de transportes usualmente inicia la importacin en los sistemas
subsiguientes manualmente usando el TMS (Transport Management System) en el
sistema SAP correspondiente, con la transaccin STMS.
En los sistemas posteriores a desarrollo, podemos ver que ordenes de transportes
estn encoladas para ser importadas dentro del sistema en la transaccin STMS. Desde
un punto de vista tcnico en un landscape de tres sistemas, la orden de transporte es
marcada para importacin 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 importacin en el siguiente
sistema en el TMS, transaccin STMS por medio de la opcin de men Overview
Imports.

Figura 96 STMS Colas de Importacin

Esto muestra la cola de importacin para el sistema. Para ver los detalles sobre la cola
de importacin, selecciona Import Queue Display

Figura 97 Visualizacin de Cola de Importacin

Existe un nmero de mtodos disponibles en la cola de importacin de TMS para

importar las rdenes de transporte en el sistema destino. Los mtodos ms
importantes son Import All Transport Requests (Importacin Masiva de Ordenes de
Transporte) e Import Individual Transport Requests (Importacin Individual de
Ordenes de Transporte). Es posible ejecutar estos mtodos en dilogo o en
background.

Figura 98 Mtodos de Importacin

Cuando importamos ordenes individuales, tenemos que seleccionar la orden de la cola

de importacin y luego importarla con la opcin indicada. Cuando importamos ordenes
de transporte de manera masiva, todas las ordenes en la cola de importacin 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 importacin. Una
tabla por lo tanto es ms importante que un programa porque el programa puede ser
dependiente de la tabla.
El orden de las rdenes de transporte en la cola de importacin del sistema de calidad
asegura que sea el mismo orden en el que se exportaron desde el sistema de
desarrollo. Por comparacin, el orden en la cola de importacin del sistema de
produccin se define por el orden con el que se import en el sistema de calidad.
La cola de importacin del sistema de produccin 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 importacin al sistema de calidad y por lo tanto la aceptacin tcnica en el
sistema de calidad.
En el sistema SAP, el administrador de transportes inicia la importacin utilizando la
transaccin STMS, eligiendo la cola de importacin con la opcin de men Overview
Imports, seleccionando el sistema en el cual la importacin se llevar a cabo y
eligiendo Import Queue Display. La importacin inicia ya sea con el botn Import All
Requests

o Import Request

Tcnicamente, el programa tp del sistema operativo es utilizado para la exportacin y

la importacin. La importacin siempre usa los archivos de datos que fueron generados
y almacenados en el directorio central de transportes durante la exportacin.

Leccin 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 lder de projecto puede liberar la
orden de Customizing y por lo tanto realizar la exportacin.

Figura 99 Ejecucin, Liberacin 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 lder 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 modificacin 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 nmero 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 estarn 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

Leccin 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 lder del proyecto de
desarrollo puede liberar la orden de transporte y, en consecuencia, se genera la
exportacin 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, Liberacin 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 tambin tengan tareas en la orden de transporte.
El desarrollo o mantenimiento de los objetos est bloqueado para todos los otros
desarrolladores que no estn involucrados en la misma orden de transporte hasta que
la misma es liberada. Estos desarrolladores solo podrn 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 - Visualizacin 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, tambin son registrados por el Organizador de Transportes,
pero las tablas solo estn bloqueadas durante el proceso de modificacin por el
enqueue work process. No hay bloqueo de objetos para Customizing.

El Organizador de Transportes tambin lleva el versionado de los objetos de

repositorio, permitiendo comparaciones y tambin 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
versin es generada cuando la orden de transporte es liberada.

Mantenimiento del software SAP

Leccin 1: Notas y Support Packages
Luego de que finalizamos la instalacin de un sistema SAP, es muy probable que
necesitemos importar ajustes que se realizaron debido a cambios en requerimientos
legales, y corregir errores que podra haber en el software del sistema SAP.
SAP provee las notas de SAP y los Support Packages para este propsito.
Notas SAP y Support Packages
Un sistema SAP se conforma de varios componentes de software. Estos componentes
se actualizan regularmente a travs 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 debera siempre tener el nivel de actualizacin ms 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 estndar por otro.

Figura 105 Notas SAP y Support Packages

Las Notas de SAP pueden contener informacin general, recomendaciones o

indicaciones de SAP. Tambin pueden describir un problema y su resolucin al error en
funciones estndar del software SAP. Este ltimo tipo de Notas SAP contiene una
solucin a un problema individual, el cual es generalmente una correccin a un error
de programacin, que obtenemos en la forma de lneas de cdigo fuente con las
modificaciones necesarias para solucionar el error.
Las notas de SAP son muy utilizadas por los administradores de sistema para
resolver problemas especficos como errores en tiempo de ejecucin de
programas estndar o fallas en los componentes del kernel por ejemplo. La base
de notas de SAP puede accederse a travs del enlace rpido
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 versin 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 Resolucin de Conflictos, que por sus siglas en ingls se conoce como
CRT (Conflict Resolution Transport)
Los add-ons se implementan para soluciones de industria especfica y modifican un
componente de software estndar (tal como por ejemplo SAP_APPL).
Tcnicamente hablando, los Support Packages son un tipo de orden transporte que
no puede ser importada por los mtodos normales que vimos en la unidad anterior. Un
Support Package contiene todas las Notas de SAP relevante a ese componente de
software y versin 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, transaccin SPAM. Las Notas de SAP son implementadas con el Asistente de
Notas, transaccin SNOTE.

Transaccin SNOTE
El Asistente de Notas se accede a travs de la transaccin SNOTE. Desde el SNOTE
podemos implementar varios tipos de notas: cambios a programas SAP, creacin de
nuevos programas SAP, cambios a mdulos de funcin SAP y varias otras cosas. De
todas formas, el Asistente de Notas no puede modificar objetos de Diccionario por
ejemplo. Adems, el Asistente de Notas puede slo modificar objetos de repositorio y
no Customizing.

Figura 106 Asistente de Notas: proceso de implementacin

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 nmero 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
versin del componente de software donde se va aplicar y el nivel de actualizacin de
Support Package del mismo son correctos para los prerrequisitos de la nota. Tambin
verifica si la nota requiere de otras notas previamente implementadas y si puede ser
implementada cuando existen otras modificaciones sobre los objetos que estn
afectados por la misma.
4. La Nota de SAP es implementada mediante la funcin de importacin. Esto crea
una orden de transporte.
5. El resultado de la implementacin de la Nota de SAP se prueba en forma general
en el sistema de desarrollo. Si la Nota no corrige el problema puede desimplementarse
tambin mediante la transaccin 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
aceptacin tcnica se realiza en este sistema.
7. Si tambin resulta correcta la aceptacin, entonces la orden de transporte es
importada en el sistema de produccin.

Support Packages Stacks

En principio, la importacin 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
importacin de Support Packages para un componente en particular tenga algunos
requisitos con otros Support Packages en otro componente. Esto significa que por
ejemplo la importacin de un Support Package de HR puede requerir la importacin
previa de un Support Package determinado del componente BASIS, o un Support
Package de APPL.
Tambin 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 combinacin 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 estn disponibles para varias de las aplicaciones de SAP y
para componentes de SAP Netweaver tambin.
Adicionalmente a los Support Packages Stacks, tambin 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 informacin sobre los Support
Packages de los diferentes componentes de software de SAP as tambin como de
los Stacks, como estn conformados y tambin 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 tambin como la duda de cmo utilizar los Support Package Stacks para una
actualizacin ordenada y documentada.
Cul es el nivel de actualizacin actual de mi landscape SAP?
Dnde puedo encontrar la informacin necesaria sobre Support Packages y Stacks?
El Optimizador de Mantenimiento (Maintenance Optimizer) provee la solucin 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 implementacin, podemos hacerlo desde
cualquier pantalla de SAP, desde la opcin de men System Status

Figura 107 - Estado de Sistema

Figura 108 Informacin 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 versin. Luego del upgrade, el sistema funciona con
todas las funciones de la nueva versin. Antes de que pueda ser utilizado en la
operacin de produccin es necesario realizar muchos ajustes. Estos incluyen ajustes a
modificaciones del estndar, cambios a customizing, cambios a desarrollos propios del
cliente y mejoras.
Las pruebas de aceptacin necesarias tambin consumen gran parte del tiempo.
Normalmente se necesita un perodo 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 Activacin (Switch Framework) el cual est disponible a partir de AS ABAP
7.0 es usado para este propsito. Utilizando el Panel de Activacin, 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 Activacin, el sistema seguir
funcionando como antes de la importacin.
Desde un punto de vista tcnico, esto significa que un programa puede existir en el
repositorio en diferentes estados al mismo tiempo. Por lo tanto cuando activamos la
funcin desde el Panel de Activacin, lo que estamos haciendo es activar una
determinada versin para los objetos de repositorio que dependen de esa funcin.
La importacin 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
implementacin 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
Adaptacin simple a requerimientos legales
Tecnologa estable
Planificacin y mantenimiento sencillo
Disminucin 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 versin directamente.
La importacin de Enhancement Packages se realiza mediante la transaccin SAINT, la
cual es para la implementacin y actualizacin 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 propsito.
Los Support Packages al estar vinculados con la versin del componente de software
existen en diferentes niveles para cada versin de componente de software. Esto
significa que luego de la implementacin de Enhancement Package 2 para SAP ECC
6.0, los Support Packages que necesitaremos posteriormente debern ser para SAP
ECC 6.0 EhP 2

Leccin 2: Configuracin de Impresoras

El administrador configura las impresoras en el sistema SAP y monitorea la salida de
los spool requests.
Impresin 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 impresin 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 informacin de
impresin independiente del dispositivo de salida e incluye informacin administrativa
tal como autor, fecha, nmero de copias y la informacin 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 informacin 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.
Impresin 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 impresin 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 informacin de
impresin independiente del dispositivo de salida e incluye informacin administrativa
tal como autor, fecha, nmero de copias y la informacin 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 informacin 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 impresin

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 tambin
la impresin puede ser al mismo tiempo de la creacin del spool request mediante la
seleccin de la opcin impresin 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 parmetro 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 transaccin SPAD (desde el men Edit Data
Storage).
La nota de SAP
rspo/store_location.

20176

contiene

valores

adicionales

para

el

parmetro

La creacin de un output request solicita al sistema de spool de SAP enviar informacin

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 ms importantes, conocidas como mtodos de
acceso (access methods) se explican a continuacin en esta leccin.
Impresin Local

Figura 111 Impresin Local

Una caracterstica de la impresin 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 travs de la red.
El spool work process pasa la informacin de forma local, en el mismo servidor.
En servidores UNIX, la impresin local se define con el mtodo de acceso L.
En Microsoft Windows, se utiliza el mtodo de acceso C.
La impresin local es la conexin ms rpida y confiable desde el sistema SAP al
sistema operativo. Tan pronto como el spool work process ha transferido la

informacin, puede tomar nuevos output requests, an si el spool del sistema

operativo se encuentra ocupado todava.
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 podran ser impresos en un orden distinto del que fueron creados. Si
necesitamos que la salida de impresin respete la secuencia, podemos especificarlo
para impresoras de forma individual. Sin embargo, una configuracin de este tipo
reduce la posibilidad de impresin en paralelo. Para ms informacin sobre esto,
podemos consultar la nota de SAP 108799.
Impresin Remota
En la impresin remota, el spool work process y el spool del sistema operativo estn
corriendo en diferentes hosts. De la misma manera que en la impresin local, es
irrelevante desde el punto de vista del sistema SAP si la impresora se conecta
directamente al host remoto o es a travs de una conexin de red.

Figura 112 Impresin Remota

Escenarios tpicos para la impresin 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 mtodo U con el nombre de la
impresora.
El mtodo de acceso U tambin es utilizado si el host remoto es un sistema UNIX. La
nota 39405 describe como el mtodo 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 ejecucin 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 impresin de otros output requests en otras

impresoras.
El mtodo de acceso S es usualmente utilizado en este caso (protocolo SAP), pero el
mtodo de acceso U tambin es soportado.
Por razones de performance, solo deberamos utilizar impresin remota en un entorno
LAN y deberamos asegurarnos que los spools de los sistemas operativos estn
disponibles.
Los usuarios SAP pueden imprimir documentos en sus impresoras locales usando
impresin 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 Impresin en Front-end con Tecnologa de Control (Mtodo de Acceso G)

Desde la versin SAP Web AS 6.20, un nuevo procedimiento de impresin en front-end

se encuentra disponible: impresin en front-end mediante tecnologa de control con el
mtodo de acceso G. Esto ya no requiere del programa SAPlpd. La ventana de
impresin 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
mtodo de impresin recibe los datos de impresin y lo transfiere al sistema de
impresin del sistema operativo. Una ventaja de este mtodo frente al mtodo F es
que ofrece la ventaja de que puede ser utilizado tambin con SAP GUI para JAVA lo
que hace que sea independiente de la plataforma del front-end. Tambin puede ser
utilizado con Windows Terminal Server. Informacin sobre impresin de front-end con
tecnologa de control est disponible en la nota de SAP 821519.
Podemos definir el mximo nmero de spool work processes que pueden ser utilizados
en el sistema SAP para impresin en front-end para cada instancia de SAP mediante el
parmetro rdisp/wp_no_Fro_max (el valor por defecto es 1).

Este mtodo de impresin no es recomendado para impresin masiva, sino ms bien

para impresin en impresoras locales de los usuarios.
Cuando usamos el mtodo de acceso F (para versiones hasta 4.6C), los datos de
impresin se transfieren al host en donde el programa SAP GUI del usuario est
corriendo. Este mtodo 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 impresin de Windows. Si es necesario, saplpd se
inicia automticamente.
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 definicin del dispositivo.
Para ms informacin, puedes ver la Nota 128105.
Si utilizamos SAP GUI para HTML y vamos a imprimir en los front-end, debemos utilizar
el mtodo de acceso F. Usando este mtodo, los datos de impresin son enviados al
navegador y visualizados. Luego puede imprimirse el documento en el front-end.

Creacin de Dispositivos de Salida

La configuracin del sistema de spool es una tarea del admnistrador del sistema. La
herramienta central para esto es la transaccin SPAD (men Tools CCMS Print
Spool Administration)

Figura 114 Creacin de Dispositivos de Salida

Con impresin de front-end con tecnologa de control (mtodo de acceso G), la

impresora tiene un nombre genrico en SAP, y es asignada al dispositivo fsico
_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 impresin en front-end se realizar utilzando SAP GUI para HTML con el mtodo
de acceso F, el dispositivo de tipo PDF1 debe seleccionarse. Los datos de impresin
son luego transferidos al navegador en el front-end como un documento PostScript y
puede ser impreso localmente.

Tabla 2 - Dispositivos de Salida para Impresin en Front-end

Para crear un dispositivo de salida, llamamos a la transaccin SPAD y elegimos Output

Device en la solapa Devices/Servers. Si hay un gran nmero 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, mximo 30 caracteres.
Nombre corto (Short Name): Para propsitos internos del sistema (puede generarse
automticamente)
Tipo de Dispositivo (Device Type): Modelo de la impresora o familia compatible.
Servidor de Spool (Spool Server): Servidor de aplicacin SAP con spool work
processes o un servidor lgico (veremos este concepto en la prxima leccin)
Lugar (Location): Por ejemplo, edificio u nmero de oficina. Sirve para que los
usuarios sepan donde se har la impresin)
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 impresin inmediata.
Mtodo 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 minsculas y maysculas. En Windows, no
debe haber espacios en el nombre de impresora.
Nombre de Host (Host Name): solo para impresin local, se calcula automticamente
del servidor de spool.
Host Destino (Destination Host): solo para impresin 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 informacin de impresin
a un dispositivo especfico.
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 Gestin 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 impresin de datos
debera 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 trminos de la figura.

Formato de Pgina (Page Format): Un formato de pgina describe el formato de
una pgina imprimible en el sistema SAP. Un gran nmero de formatos de pginas
estndar 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
debera aparecer en el papel. Principalmente contiene el formato para la pgina.
Formato (Format): Un formato es una implementacin de un tipo de formato
especfico para un dispositivo. Esto es, el sistema SAP puede usar la descripcin en un
formato para controlar un dispositivo correctamente. Por ejemplo, realizar una salida

en una pgina con el formato de Carta. Un tipo de formato es por lo tanto

independiente del dispostivo; el formato, por otro lado es una implementacin
especfica 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 Impresin (Print Control): Permite el control de la visualizacin de
opciones de los dispositivos de salida, tal como el cambio de tamao de fuente, o la
misma fuente. El control de impresin utiliza un control de secuencia de caracteres
especfico del dispositivo. Esto significa que para crear nuevos dispositivos, las
opciones de visualizacin ofrecidas por el sistema SAP deben ser almacenadas con el
control de secuencia de caracteres que el modelo de impresora elegido soporta.

Leccin 3: Administracin de Spool Servers

Concepto de Spool Server Lgico

El concepto de impresin mostr hasta ac un idea de una asignacin fija de un

dispositivo de salida a un servidor de spool. Un servidor de spool, por otro lado, pude
ser asignado a mltiples dispositivos de salida lo cual incrementa el riesgo de
sobrecarga en este servidor o tambin de no disponer de muchas impresoras si una
instancia no se encuentra operativa.
Por estos motivos sera convenientes tener un mecanismo para balancear la carga
entre varios servidores de aplicacin SAP. La inclusin de servidores lgicos en el
planeamiento de impresin para el landscape de SAP desde un primer momento puede
ahorrar mucho esfuerzo en el mantenimiento de la operacin.
Cuando el sistema SAP se escala en el tiempo con instancias adicionales y spool work
processes se ponen a disposicin, los servidores de spool lgico facilitan la adaptacin
del landscape de impresin.

Figura 116 Servidores de Spool

Un servidor de spool es un servidor de aplicacin 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 lgica entre el dispositivo de salida y el servidor de spool. Podemos utilizar
servidores de spool lgicos para este propsito.
Podemos clasificar dispositivos de salida y servidores de spool, por ejemplo, para
impresin de test o impresin de produccin.
El sistema SAP verifica la clasificacin y muestra mensajes de advertencia si encuentra
una desviacin. Por ejemplo, el sistema advierte si intentamos imprimir un gran
volumen en un servidor de impresin productivo.
Podemos mantener los servidores de spool en la transaccin SPAD mediante la
seleccin de Spool Servers en la solapa Devices/Servers. Informacin importante de un
servidor de spool:
Nombre de Servidor (Server Name): Nombre del servidor de spool, mximo de 20
caracteres y depende si es maysculas o minsculas. El siguiente campo es para una
descripcin breve.
Clase de Servidor (Server Class): Clasificacin del spool server, por ejemplo:
impresin masiva.
Servidor Lgico (Logical Server): seleccionamos esta opcin cuando creamos un
servidor lgico.
Mapeo (Mapping): Nombre de un servidor lgico real al cual este servidor lgico
refiere.

Figura 117 Creacin de Servidor Lgico de Spool

Se puede definir un servidor de spool (lgico o real) especificamente para impresin en

front-ends. Si especificamos el parmetro de perfil rspo/local_print/server con el

nombre del servidor de spool.
Si vamos a tener una carga siginificante de impresin en front-end, podemos
configurar al menos un spool work process adicional por cada servidor de spool de
impresin 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
transaccin SPAD, bajo Output Devices y seleccionar el men Edit Classification.
Ventajas de los Servidores de Spool Lgicos
Cuando creamos un servidor de spool, ya sea un servidor lgico 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 podran 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 ms de dos servidores de spool para un servidor lgico. Pero como
si puede referenciar a otro servidor lgico, es posible configurar jerarquas extensivas
de servidores se spool. O sea configuraciones en cascada de servidores lgicos
haciendo referencia a un servidor de spool y como alternativa a otro servidor lgico.
Balanceo de Carga
Podemos permitir balanceo de carga para cada servidor de spool con un servidor
alternativo (para esto debemos elegir la opcin Allow Load Balancing). La carga de un
servidor de spool es calculada con el nmero de spool work processes, output requests
y pginas a imprimir.

Figura 119 Balanceo de Carga

Para un output request para un servidor de spool con balanceo de carga (la
configuracin puede ser para servidores lgicos y para servidores de spool), el sistema
determina el servidor con la menor carga. El algoritmo es recursivo: el mismo criterio
de seleccin es utilizado en el servidor mapeado y en el servidor alternativo (ambos
podran ser servidores lgicos tambin).
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 Impresin

El concepto de servidores lgicos soporta una definicin de un landscape de impresin
consistente y transportable. A diferencia de servidores de spool reales, los servidore
lgicos pueden tener el mismo nombre en varios sistemas SAP. De esta forma,
podemos definir una arquitectura de impresin en SAP en el sistema de desarrollo y
luego transportarla a los dems sistemas. Luego de transportar, todo lo que
necesitaremos hacer es ajustar el mapeo de los servidores lgicos a los servidores de
spool del nuevo sistema.

Figura 120 Transportando el Landscape de Impresin

Existen funciones para el transporte manual de dispositivos de salida y de servidores

de spool en la transaccin SPAD.

Leccin 4: Jobs de Background

Qu es el procesamiento en background o de fondo?
El procesamiento en background debera esencialmente separar tareas peridicas y
que insumen mucho tiempo de aquellas de interaccin de usuarios. Tareas que
requieran mucho tiempo y ocuparan un work process en dilogo pueden ser
secuencialmente procesadas en background sin afectar la performance de dilogo.
Un requisito importante para conseguir este objetivo es un dimensionamiento
apropiado del sistema, ya que, demasiados procesos de background podran terminar
compitiendo por recursos compartidos con procesos de dilogo (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 ejecucin de los mismos.

Fundamentos
Las siguientes preguntas responderemos en esta leccin:
Por qu necesitamos procesamiento en background?
Qu es un Job de background?
Qu podemos realizar en background?
Qu condiciones de inicio existen?
Cmo 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 dilogo deberan estar disponibles para responder a las solicitudes
de los usuarios rpidamente. Los recursos de dilogo deberan por lo tanto no ser

utilizados para ejecuciones prolongadas ya que pueden provocar cuellos de botella en

el tiempo de respuesta de dilogo. El parmetro rdisp/max_wprun_time existe por este
motivo justamente. Limita el mximo tiempo de ejecucin de un paso de dilogo en un
work process de dilogo.
Esto debera asegurar que los procesos de dilogo no sean bloqueados por programas
que requieren demasiado tiempo de ejecucin, interfiriendo la operacin online. Luego
de que el mximo tiempo se ha superado, el programa es terminado.
La manera en que el parmetro 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. Tambin se conocen estos como procesos de batch.
Normalmente, los procesos de background no se utilizan solamente para ejecuciones
largas, sino que tambin 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 ms pasos (steps). Un paso puede ser:

Un programa ABAP
Un comando externo
Un programa externo
Cada job se procesa sin interrupcin 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 mltiples 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.
Deberamos asegurarnos que la mayor parte de los jobs de background sean
planificados con prioridad normal, clase C, sin especificacin de servidor de
ejecucin. Esto debera aplicar para el 90% o ms 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 ms pantallas de seleccin, 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 ejecucin del
programa. Si un programa ABAP tiene una pantalla de salida como resultado, esto es
dirigido a una lista de spool. Podramos tambin especificar un recipiente de email para
esta lista de spool durante la definicin del job. Debemos especificar una impresora
para la creacin 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 podra 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 tambin el concepto de autorizacin de SAP para proteger la ejecucin
de un comando externo. Esto permite que podamos determinar que usuarios estn
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

autorizacin de SAP solamente especifica si un usuario puede llamar un programa
externo o no. Una asignacin ms detallada de autorizaciones, por ejemplo a nivel de
los nombres de programa, no es provista con la ejecucin 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 planificacin 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 segn la planificacin)
Mediante la ocurrencia de un evento particular definido en el sistema SAP. Esto
incluye jobs que se iniciarn luego de la finalizacin de otros jobs o en los cambios de
modo de operacin o jobs con inicio inmediato si existen background work processes
libres al momento.

Planificacin y Monitoreo
Podemos utilizar la transaccin SM36 para definir nuevos Jobs. Puedes tambin llamar
el Asistente de Job, transaccin SM36WIZ o desde la transaccin SM36 tambin.

Figura 125 Planificacin de Jobs

Las especificaciones que requiere la definicin de un job son:

Especificaciones generales tales como nombre de job, prioridad del job (por defecto:
C) y opcionalmente un servidor de ejecucin o grupo.
Definicin de uno o ms pasos
Definicin de una condicin de inicio (de tiempo o controlada por evento)
El Asistente de Job nos ayuda en la creacin del job guindonos de manera fcil a
travs del proceso de creacin.
El mtodo de creacin de un job de background (clsico o mediante el Asistente de
Job) no tiene incidencia en el resultado. Algunas funciones (especificar el usuario SAP
en la definicin del paso de job, modificacin del orden de ejecucin de los pasos) no
estn disponibles para el Asistente de Job.
La transaccin SM37 nos permite monitorear los jobs. Podemos seleccionar los
jobs utilizando diversos criterios en la pantalla inicial de esta transaccin. Algunas
opciones seran 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 mostrarn y el orden, entre otras cosas. Podemos
tambin configurar si ser el diseo (layout) estndar para el usuario actual o todos los
usuarios.
Para el anlisis de jobs, una columna que no se visualiza por defecto y es importante,
es la columna de servidor de ejecucin. Muchas veces algn problema en la ejecucin
de un job puede estar relacionado al servidor de aplicacin donde se ejecuta.
Podemos tambin navegar a otras vistas especficas del job desde la visualizacin 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, informacin sobre la definicin del job,
duracin 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 informacin sobre un programa que
finaliz con error o para realizar una investigacin detallada sobre la ejecucin 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 creacin del job han sido
definidos ya, de todas formas la condicin de inicio an necesita ser definida.
Liberado (Released): El job ha sido completamente definido, incluyendo la
condicin de inicio. Un job no puede ser liberado sin una condicin 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
autorizacin no puedan ejecutar jobs sin aprobacin.
Listo (Ready): La condicin 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 ms del
tiempo normal, podemos analizar el job en modo de depuracin. Luego podemos
finalizar el job definitivamente o liberarlo nuevamente. Para esto, en la transaccin
SM37, seleccionamos Job Capture: active job.
Para capturar un job de background, debemos iniciar sesin 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 transaccin SM37 mediante la

seleccin 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
ejecucin 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.

Leccin 5: Administracin de Jobs

Planificacin 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 da laboral determinado.
Puedes seleccionar que el job sea recurrente. Esto significa que el job ser ejecutado
nuevamente despus de un perodo de tiempo definido. Tambin es posible especificar
excepciones, tal como posponer al siguiente da 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 tambin un perodo de tiempo en el cual el job debe iniciarse. Para
esto, especificamos un tiempo luego del cual el job no debe ejecutarse. Con esta
funcin, podemos prevenir la ejecucin de jobs peridicos en un momento no
conveniente, entre otras cosas. Por ejemplo, un job de reorganizacin que debera
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 da, cuando los usuarios de dilogo estn activos y
hay menos recursos disponibles.
Balanceo de Carga
El parmetro de perfil rdisp/bctime especifica el perodo de tiempo en el cual el
planificador de jobs dependientes de tiempo est activo (observar la Figura 129). La
ejecucin de jobs con una condicin de inicio inmediata usualmente evita el
planificador. En este caso, el work process de dilogo 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 debera 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 parmetro de perfil rdisp/wp_no_btc.
El nmero de work processes requeridos en el sistema SAP depende del nmero de
tareas que se realizarn en batch. Si el sistema de transporte es utilizado, debe haber
al menos dos work processes de background en el sistema. La combinacin 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 automticamente en un work process de dilogo.
A partir de SAP Netweaver 7.0 el planificador de job tambin 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 versin a partir de Basis de 4.6C.
El planificador de job basado en tiempo verifica la tabla de planificacin de jobs en la
base de datos y busca jobs que estn 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 ejecucin.
Los jobs que no son asignados a ningn servidor en particular para la ejecucin
pueden ser ejecutados con cualquier work process de background libre. Esto significa
que la carga de trabajo es automticamente distribuida entre las instancias SAP.
Si un job es explcitamente asignado a ser ejecutado ya sea en una instancia
seleccionada o un grupo de instancias algunas caractersticas 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 distribucin de carga automtica del sistema.

Jobs Estndar
Los jobs estndar son jobs de background que deberan ejecutarse regularmente en un
sistema de produccin SAP. Estos jobs principalmente realizan ciertas tareas de
limpieza en el sistema, tal como el borrado de spool requests obsoletos o el
procesamiento de informacin estadstica y de monitoreo.

Figura 130 Planificacin de Jobs Estndar

En la transaccin de definicin de jobs (SM36), puedes acceder a una seleccin de jobs

estndar importantes que puedes planificar, monitorear y editar seleccionando
Standard Jobs.
Si queremos planificar todos los jobs estndar, seleccionamos Default Scheduling.
Todos los jobs estndar que estn definidos en la tabla REORGJOBS son planificados
con una variante y perodo especfico.
Para planificar jobs individuales, selecciona el job y especifica el perodo de ejecucin.
Para definir un job estndar adicional que no est disponible en la seleccin (tabla
REORGJOBS), podemos seleccionar Predefine new job.
Para informacin sobre jobs estndar, podemos consultar las notas 16083
Standard Jobs, reorganization jobs y 1034532 Changes for standard jobs.

Planificacin Basada en Eventos

Un evento es una seal 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 estn
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 despus de que un evento definido en el sistema
SAP es recibido.
Modo de Operacin: Con esta opcin, puedes vincular un job a la activacin de un
modo de operacin cuando planificamos el job.

Luego de un Job: De esta manera, podemos crear cadenas simples de jobs donde la
ejecucin 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, transaccin
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 deberamos
modificar o disparar.

Figura 132 Definicin y Disparo de Eventos

Los eventos pueden ser disparados de diferentes formas:

Manualmente en CCMS para propsitos de prueba (transaccin SM64).
Con un programa ABAP, mediante el uso del mdulo de funcin BP_EVENT_RAISE o
el mtodo RAISE de la clase CL_BATCH_EVENT.
Fuera del sistema SAP a nivel del sistema operativo usando el programa sapevt.
Un parmetro puede tambin ser transferido cuando un evento se dispara. De esta
manera, podremos definir jobs que esperan por la ocurrencia del evento junto con el
parmetro especfico. Tambin podemos acceder al Historial de Eventos en la
transaccin 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 parmetros 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 ejecucin del programa
event=NUEVO_ARCHIVO_INTERFAZ
name=DEV

sapevt podra 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

Leccin 6: Otros Temas de Procesamiento en Background

Reserva para Jobs de Clase A
En la operacin 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 reservacin de work processes para jobs de clase A no reserva ningn work process
en particular. Ms 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 nmero definido de work processes para posibles jobs de
clase A se mantiene libre.

Figura 133 Reserva de Jobs de Clase A

Para configurar el nmero de work processes de background de clase A tendremos que

configurar los modos de operacin en la transaccin RZ04. Cuando hacemos esto,
tendremos la opcin de reservar work processes de background.
Si la carga de jobs de clase A es pequea, 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 reservacin simplemente
significar que un work process es muy poco utilizado (solo por jobs de clase A).

SAP recomienda que no reservemos ms 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 planificacin de jobs de background.
Objetivos de Ejecucin
Solamente instancias con work processes de background o un grupo de servidores de
job puede ser utilizado para planificar la ejecucin de jobs con instancias o grupos
especficos.
Un grupo de servidores de job contiene una o ms 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 dilogo. Tambin es posible procesar tareas de
background en instancias seleccionadas.

Figura 134- Ejecucin en instancias o grupos de servidores de job

Podemos configurar un grupo de servidores de job en la transaccin SM61 (men

Tools CCMS Background Processing Background Objects). Aqu podremos definir
grupos de servidores con work processes de background asignando las instancias que
formarn el grupo.
Usuarios de Background
Con la clsica definicin de jobs utilizando la transaccin SM36, podemos asignar cada
paso de un job a un usuario (observar la Figura 135). El usuario especificado es
utilizado para las verificaciones de autorizacin durante la ejecucin 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 debera ejecutarse usando las autorizaciones de ese usuario, podemos
ingresar un usuario diferente. Para poder hacer este cambio, deberemos contar con la
autorizacin pertinente S_BTCH_NAM para poder ingresar otros usuarios diferentes al
nuestro en el campo User en la definicin 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 administracin de sistema. Los usuarios de
background tienen registros maestros de usuario que cuentan especficamente 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 dilogo no es posible con este tipo de usuarios. De
la misma manera, los usuarios de este tipo estn exentos de la configuracin de
validez de las contraseas. El administrador de sistema solo puede cambiar la
contrasea mediante la transaccin SU01.
Si en cambio usamos el Asistente de Jobs para la creacin de los mismos, no tenemos
la posibilidad de definir un usuario diferente para cada paso del job.

Utilizacin 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
propsito de esta diferenciacin es darle a los administradores del sistema la
posibilidad de ejecutar cualquier programa externo que requieran, mientras que los
usuarios normales estn restringidos al uso de comandos externos para los cuales hay
verificaciones de autorizacin. 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 estn 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 verificacin de
autorizacin SAP se lleva a cabo antes de la ejecucin del comando. Los programas
externos proveen al administrador la flexibilidad para ejecutar cualquier comando en el
sistema operativo en el sistema SAP sin preparacin previa.
Un administrador de sistema debe contar con autorizaciones para el objeto
S_RZL_ADM: Administrador de Procesamiento en Background.

Figura 137 Definicin y Uso de Comandos Externos

La creacin de comandos externos requiere de los siguientes pasos:

1. Llamar a la transaccin SM69.
2. Seleccionar Create.
3. Realizar las entradas en el nuevo comando.
Los comando externos son identificados unvocamente con un nombre, comenzando
con Z o Y, y un tipo de sistema operativo. El campo Type se completa
automticamente.
Especificar un comando ejecutable del sistema operativo (si es necesario con la ruta
completa) y especificar cualquier parmetro requerido u opcional.
Seleccionar el cuadro de verificacin (checkbox) Additional Parameters Allowed si los
usuarios podrn especificar parmetros adicionales cuando ejecutan el comando
externo. Los parmetros adicionales son agregados en una cadena de parmetros
especificados bajo el campo Parameters for Operating System Command.
El campo Trace debera dejarse en blanco usualmente. Para seguir la ejecucin de un
comando externo, utiliza el parmetro de traza para el mdulo de funcin
SXPG_COMMAND_EXECUTE.
Si se ha definido una verificacin adicional de autorizacin, ingrese el nombre del
mdulo de funcin que realiza la verificacin en el campo Check Module. Este es
usualmente una copia del mdulo de funcin SXPG_DUMMY_COMMAND_CHECK. El
sistema llama al mdulo de funcin automticamente 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 ejecucin 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. Tambin es posible registrar informacin 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 finalizacin del programa externo.
En el caso de que despus 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 deberamos utilizar el indicador de control Job waiting for ext.
Termination cuando planficamos el paso del job.

Leccin 7: Monitoreo de Sistema

La infraestructura de Monitoreo de Alertas - Permite realizar un monitoreo eficiente de
los sistemas SAP

Recoleccin 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 informacin obtenida en la memoria principal
de la Instancia.
Almacenamiento de Datos --> el rea de la memoria q almacena toda la informacin
se conoce como segmento de monitoreo, esta area es continuamente sobrescrita, los
datos se copian a la BD para poder ser analizados posteriormente
Administracin de Datos --> Los datos obtenidos en el monitoreo de segmento son
analizados y evaluados tx - RZ20 Herramienta de visualizacin
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 categoras para facilitar la bsqueda y visualizacin 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 mtodo de
anlisis

Las alertas se propagan si es severa por los niveles superiores del rbol, rojo es ms
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 funcin de

mantenimiento

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

Luego de finalizar se desactiva la funcin de mantenimiento

Se pueden revisar que alarmas estn abiertas

En el rbol se puede visualizar las alarmas q estn pendientes por anlisis

Haciendo doble clic sobre el atributo se vern las alarmas pendientes

Luego de q esta determinada la causa y efectuar la correccin se marca como alarma

completa para que vuelva el indicar al estado normal.

Administracin Avanzada de Clientes

Leccin 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 contrasea
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 ejecucin 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 verificacin antes de iniciar la copia donde se vern los datos
del cliente destino, el perfil utilizado y el cliente origen, as tambin como un detalle de
los datos que sern copiados segn 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 tambin 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 ejecucin 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 accin actual que se
est realizando y las estadsticas para la ejecucin

Con el monitor se puede observar de forma grfica el progreso de la cantidad de tablas

copiadas as tambin 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 ejecucin

En la copia de cliente remota previamente a iniciar la copia, el sistema realizara una

verificacin 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
podra afectar el resto de los mandantes que puedan existir en el sistema destino

Se debe seleccionar tambin una conexin 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 ejecucin, esto puede ayudar a reducir los tiempos de la copia

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

Se puede observar la accin de cada uno de los procesos escogidos

Otra opcin para la copia es la exportacin e importacin, 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 exportacin, 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 exportacin

Tambin la informacin del sistema destino y el mandante destino, esta informacin

ser utilizada por el sistema de transportes luego para la importacin
La ventaja de este mtodo 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 podra actualizarse una vez por
semana por ejemplo

En la copia remota como en la exportacin podremos verificar de ante mano la

consistencia con el sistema destino

Debemos contar con una conexin RFC al sistema destino

El resultado del chequeo de consistencias, podra 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 exportacin, 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 informacin indicara que hasta 3 archivos se podrn generar

dependiendo del perfil seleccionado, bsicamente 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

Leccin 2: Comparacin de Clientes

Usando la Herramienta de Comparacin de Clientes
Cuando varios sistemas SAP y clientes estn siendo implementados, podra ser
necesario comparar y ajustar el customizing entre diferentes sistemas y clientes. La
funcin de comparacin permite comparar y ajustar el contenido de una tabla o vista
en dos clientes diferentes, mediante conexiones RFC.

Figura 138 Comparacin de Clientes

Para usar la funcin de comparacin de clientes, desde la pantalla inicial de SAP,

ingresa a la transaccin SCU0.
Podemos usar esta funcin 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 despus de un Upgrade o Importacin
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 organizacin superior.

Figura 139 Comparacin de Clientes: Opciones de Seleccin

Para seleccionar los objetos a ser comparados en una comparacin de clientes,

podemos usar un mtodo orientado a proyecto utilizando el IMG para definir los
objetos. Tambin podemos seleccionar desde los componentes de aplicacin, listas de
objetos y rdenes de transporte. Tambin podemos elegir objetos manualmente.
Para iniciar la comparacin, utiliza la transaccin SCU0 y el procesamiento en
background. La transaccin primero muestra un resumen de las tablas que pertenecen
a vistas para el IMG, componente de aplicacin u orden de transporte seleccionado.
Luego de la comparacin, 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
comparacin detallada.

La comparacin de cliente es generalmente con otro sistema, por lo que en estos casos
necesitaremos acceder mediante una RFC.
Para ms informacin sobre comparacin de clientes, puedes consultar la Nota de
SAP 91096
Los resultados de cada comparacin es un resumen de las diferencias que existen
entre el cliente donde nos encontramos y el cliente seleccionado para la comparacin.
Este resumen sirve como un punto de inicio para continuar con el anlisis de las
diferencias. El resultado de la comparacin 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 descripcin en la salida de la
comparacin. La informacin ms 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 todava no. Este tipo de procesamiento se conoce tambin
como ajuste del objeto. El estado de procesamiento se indica por un pequeo
semforo, donde rojo indica que no ha sido ajustado, amarillo significa que se est
realizando el ajuste y verde que se ha completado.
Una breve explicacin sobre el estado de comparacin 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 travs de la transaccin
SM30. Todos los dems 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 comparacin, el cual inidica si cada entrada de
registro existe en el cliente comparado y en el cliente donde nos encontramos.

Figura 141 Configuracin de Cliente

La opcin 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
comparacin y ajuste de cliente. Tambin puede asegurar que los datos sensibles no
puedan ser visualizados desde otro cliente durante una comparacin.
Para seleccionar esta opcin desde la transaccin SCC4, seleccionamos uno de los
niveles de proteccin:
Nivel 1: No overwriting
Este nivel de proteccin asegura que el cliente no puede ser sobrescrito por el
programa de copia de cliente. Esta opcin debera utilizarse si en el cliente se realiza
customizing o el cliente contiene configuraciones crticas o datos que no deberan
sobrescribirse.
Nivel 2: No overwirting and no external availability
Este nivel de proteccin tambin protege contra la sobrescritura del cliente y contra el

acceso a lectura desde otro cliente durante una copia de cliente o una comparacin de
customizing. Esta configuracin debera utilizarse si el cliente contiene datos sensibles.
Todos los clientes productivos deberan tener esta opcin.

Importacin 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 produccin no son requeridos en esta
etapa. Tambin 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 podran ser creados automticamente durante la instalacin
del sistema SAP (ver la gua de instalacin para el sistema SAP para ms detalles).
Los transportes nos permiten sincronizar el Customizing y los desarrollos en mltiples
sistemas SAP a travs de la transferencia de los cambios realizados desde el sistema
de desarrollo a los sistemas subsiguientes. Los transportes a travs de las rutas de
transportes deben ocurrir solo en una direccin.

Conceptos y Terminologa de TMS

Los conceptos detrs de TMS (Transport Management System):
Configuracin centralizada del Sistema de Cambios y Transportes (CTS) para todos los
sistemas SAP.
Gestin centralizada de rdenes de transportes y del proceso de importacin.
Estrategia de transportes basada en rutas de transportes predefinidas.
TMS
El propsito de TMS, el cual se accede mediante la transaccin STMS, es controlar de
forma central la propagacin de los cambios a travs de los sistemas del landscape
basado en caminos predefinidos. Esto est diseado 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
estndar.
Configurar los parmetros del programa de transportes tp
Visualizar las colas de importacin de todos los sistemas en el dominio de transportes.
Definir los procedimientos de aseguramiento de calidad y aceptacin de cambios en el
sistema de QA.
Planificar la importacin de rdenes de transportes en una cola de importacin.
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 configuracin es distribuida a todos los
sistemas en el landscape. Esto asegura que todas las configuraciones de TMS son
consistentes a travs de todo el dominio. El controlador de dominio almacena la
configuracin y todos los otros sistemas reciben una copia de esta configuracin.
Un dominio de transportes contiene al menos un grupo de transportes. Ms simple, un
grupo de transporte consiste de uno o ms sistemas que comparten un directorio de
transportes comn. Las siguientes figuras muestran la relacin 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 comunicacin 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
automticamente configurados por la herramienta TMS. La configuracin de dominio
se distribuye a travs del dominio usando la comunicacin RFC.

Los cambios en la configuracin 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
sern incluidos en el dominio. El domino de transportes debera contener todos los
sistemas de todos los landscapes de sistemas que sern administrados centralmente
mediante TMS.
La configuracin de TMS puede desglosarse en tres pasos individuales.

1. La configuracin del dominio de transportes que define los sistemas que sern
incluidos en el dominio.
2. La configuracin de las rutas de transportes que define los roles de los sistemas
(y clientes) dentro del o los landscapes.
3. La configuracin del procedimiento de QA que define quien ser responsable
para la aprobacin y aceptacin de cambios y la promocin de los mismos a los
sistemas de delivery subsiguientes.

Inicializando el Controlador de Dominio de Transportes

El primer sistema que configuramos es automticamente seleccionado como el
controlador de dominio pero ms 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 produccin podra ser ideal para ser el controlador de
dominio. Como los sistemas de desarrollo usualmente son instalados antes del sistema
de calidad o produccin, en la prctica es comn configurar el sistema de desarrollo
como el controlador de dominio y luego mover la asignacin al sistema de produccin.

Cuando usamos TMS por primera vez luego de la instalacin del sistema,
automticamente nos solicitar configurar TMS.
Cuando inicializamos TMS, las siguientes acciones se llevarn a cabo automticamente
por el sistema SAP:
Un grupo de transportes es creado con el nombre GROUP_<SID>.
En el cliente 000, el usuario de comunicacin TMSADM es creado.
Los destinos RFC necesarios para TMS son generados.
El archivo de configuracin DOMAIN.CFG es almacenado en el subdirectorio bin del
directorio de transportes. Este archivo contiene el nombre del dominio de transportes y
la descripcin as tambin como el nombre del host de controlador de dominio, nmero
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 parmetros en este perfil se mantienen usando la transaccin STMS.
El nombre del domino de transportes no debe contener espacios en blanco y no puede
ser modificado despus 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
informacin sobre cmo establecer la conexin 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 configuracin del dominio de transportes. No
debemos modificar el perfil de transportes usando un editor de textos en el sistema
operativo.

Para visualizar los parmetros de tp en un sistema SAP, llamamos a la transaccin

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.

Configuracin 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 an realizar transportes hasta que las
rutas de transportes hayan sido configuradas y distribuidas.
Despus de establecer el dominio de transportes, necesitaremos:
1. Modelar las rutas de transportes desde el controlador de dominio, usando:
a. Configuraciones estndar (uno, dos o tres sistemas)
b. Editor grfico para configuraciones no estndar
2. Distribuir y activar la nueva configuracin para todos los sistemas SAP dentro del
dominio de transportes.
Para reducir el trabajo para especificar las rutas de transportes, podemos usar las
configuraciones estndar. Las rutas de transportes se generan automticamente
cuando seleccionamos los sistemas y la configuracin 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
consolidacin o de entrega o reparto (delivery).

Una ruta de consolidacin es una ruta de exportacin/importacin. Tpicamente, la ruta

de consolidacin 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 estndar de tres sistemas.
Una ruta de reparto es otra ruta de importacin. En el landscape de tres sistemas, la
ruta de reparto se especifica entre el sistema de calidad y el sistema de produccin
porque no hay una exportacin desde el sistema de calidad pero si una importacin al
sistema de produccin.
El customizing y los objetos de respositorio son asignados a una ruta de consolidacin
especfica mediante una capa de transportes. En el directorio de objetos SAP, el cual es

el catlogo de todos los objetos, estn agrupados dentro de unidades lgicas llamadas
paquetes, formalmente conocidos como clases de desarrollo.
La definicin de cada paquete contiene una asignacin a una capa de transportes. Los
objetos, a travs de la asignacin del paquete, indirectamente son asignados a la capa
de transportes.
Todos los objetos entregados por SAP estn 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 Integracin: 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 estndar de SAP.
Sistema de Consolidacin: el sistema destino de una ruta de consolidacin.
Sistema de Entrega o Reparto: es el o los sistemas destino de una ruta de entrega o
reparto.

Necesitaremos configurar ms capas de transporte si nuestro landscape es ms

complejo y tambin si necesitamos redirigir la ruta de ciertos objetos si no usarn la
ruta de transportes estndar.
Por ejemplo, si un sistema de entrenamiento separado existe y hay ciertos programas
que sern ejecutados all pero no queremos que esos programas lleguen al sistema de
calidad o produccin.

Configuracin Bsica de TMS

Ingresar a la tx STMS

Para realizar la configuracin 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 informacin del sistema donde estamos realizando la
configuracin y el dominio de transporte que estamos creando para nuestro sistema
de transportes ya que para el ejemplo prctico este sera el primer sistema instalado,
se tomara los valores propuestos

Una vez que se guarde la configuracin, 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 configuracin, se creara sistemas virtuales dentro del dominio

Con el sistema virtual podr configurarse todos los sistemas de transporte sin la
necesidad de tener los dems 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 visualizacin 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 aadirlos en el
entorno grafico

Una vez colocado los tres sistemas, empezaremos con la creacin 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 consolidacin, este tipo de

ruta se otorga a los sistemas desde donde se liberan las rdenes de transporte y el
prximo sistema donde se importaran

En la ruta de consolidacin tambin debemos elegir la capa de transporte, por lo

general son dos; una capa llamada SAP para los objetos estndar 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 consolidacin 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 Produccin, 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 opcin 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
produccin

Luego el sistema generara automticamente la ruta ente los tres sistemas

Guardar

Leccin 1: El Proceso de Transportes

Como administradores del sistema SAP, deberemos asegurarnos el correcto
movimiento de cambios a travs 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 introduccin del Sistema de Gestin 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 mltiples rutas
de consolidacin o de entrega. El procedimiento de importacin 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
transaccin STMS son ejecutadas por comandos del programa tp en el sistema
operativo, que con cierto nivel de conocimiento tcnico podramos llegar a realizar
manualmente en algn caso necesario.
Las rdenes de transporte que estn pendientes de importacin se visualizan en la cola
de importacin del sistema destino desde cualquiera de los sistemas SAP que
conforman el dominio de transportes.
Usando TMS podemos importar completamente la cola de importacin, esto es, todas
las rdenes de transporte que fueron exportadas desde el sistema de desarrollo. Esto
asegura que ningn error de importacin ocurra debido a objetos faltantes y que las
ltimas versiones de un objeto no sean sobrescritas por versiones anteriores.

Liberacin y Exportacin

Figura 143 Proceso de Transporte: Liberacin y Exportacin

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 comn 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 exportacin, las entradas necesarias para la importacin siguiente son
creadas en el buffer de importacin del sistema destino, y una importacin de prueba
puede realizarse.
En el directorio buffer, en el sistema operativo, hay una buffer de importacin 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 informacin 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 importacin en el sistema operativo. La informacin de control en los
archivos de buffer de importacin es leda y representada como las colas de
importacin accedidas desde el sistema SAP. Una cola de importacin muestra todos
las rdenes de transportes que estn contenidas en el buffer correspondiente.

Figura 144 Proceso de Transporte: Importacin 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 importacin del sistema de calidad
(QAS). TMS realiza la importacin iniciando el programa de control de transportes tp
en el sistema operativo.
Despus que las rdenes de transportes se han importado correctamente en el sistema
de QAS, las rdenes se agregan en el buffer de importacin (con estado inactivas si es
que el procedimiento de QA est implementado) y la cola de importacin del sistema
de produccin (PRD) y cualquier otro sistema de entrega segn la ruta de transporte.

Figura 145 Proceso de Transporte: Aseguramiento de Calidad

Despus 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 importacin en QAS, la orden o las rdenes de
transportes adicionales son agregadas al buffer de importacin del sistema de
produccin.

Figura 146 Proceso de Transporte: Importacin en PRD

Despus 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 estn 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
importacin en la secuencia que se presentan.
Para asegurarnos que no haya ningn efecto negativo en las actividades de
produccin, debemos asegurarnos que los errores y las correcciones se importen en el
orden correcto, o sea, respetando el orden de importacin de la cola.

Leccin 2: Importacin usando TMS

El administrador de transportes debe seguir las normas establecidas para la estrategia
y planificacin 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 importacin de TMS, reflejan los buffer especficos de cada sistema que se
encuentran a nivel del sistema operativo. Las colas de importacin muestran el orden
correcto en que deben importarse las rdenes. Las colas de importacin de todos los
sistemas se pueden visualizar desde cualquier sistema del dominio de transportes, as
tambin como realizar las importaciones.
Para acceder lo hacemos mediante la transaccin STMS y luego desde el men
Overview Imports. All veremos el estado actual de la cola de importacin, a veces
es necesario refrescarla para una vista actualizada. El timestamp muestra que tan
reciente es la informacin.

Figura 146 Informacin de la Cola de Importacin

Para que la informacin de la cola de importacin se refresque automticamente

podemos configurar un job de background peridico. Para esto elegimos STMS
Overview Imports Extras Update All Import Queues. Luego seleccionamos con
qu perodo se ejecutar el job. Cada una hora es un tiempo razonable. El programa
es RSTMSCOL.

Figura 147 Colas de Importacin y Buffer de Importacin

Marca de Stop
Los trminos buffer de importacin y colas de importacin estn relacionados. La cola
de importacin en el sistema SAP representa el buffer de importacin que se encuentra
en el directorio de transportes. La cola de importacin resalta las rdenes que sern
importadas durante la prxima importacin (mtodo importar todo). Debido a la marca
de stop (stopmark), podra haber ms rdenes de transportes en el buffer de
importacin que aquellas resaltadas en la cola de importacin.
El stopmark indica que solo las rdenes anteriores a la marca sern importadas. El
stopmark se crea tanto en la cola de importacin como en el buffer de importacin. En
la cola de importacin se muestra con la leyenda End of Import Queue. En el buffer,
el trmino stopmark se muestra. Puede solo haber un stopmark en cada buffer de
importacin.
Para crear un stopmark para cerrar la cola de importacin, desde la misma cola de
importacin en STMS elegimos Queue Close. Esto es anlogo 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.
Tambin podemos mover luego la marca de stop a otra posicin en la cola de
importacin. 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 Importacin

La cola de importacin es til para:

Visualizar el estado de las rdenes.
Acceder a listas de objetos en las rdenes, documentacin, 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 lmites
para coordinar la liberacin de rdenes de transportes de los desarrolladores. Para
prevenir que las rdenes liberadas posteriormente a la fecha lmite sean importadas, la
cola de importacin puede cerrarse. Las rdenes liberadas posterior al cierre de la cola
se posicionan luego de la marca de stop en la cola para la prxima importacin. 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 importacin. 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 importacin seleccionamos la orden y luego
Request Forward System.
Tambin podemos borrar o agregar rdenes de transporte a una cola de importacin.
Las dependencias de objetos pueden causar inconsistencias en el sistema destino
luego en la importacin. 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 fallarn. Para evitar estas inconsistencias, es muy importante no
borrar rdenes de transporte.

Figura 149 Importacin de Todas las rdenes de Transporte

Para importar todas las rdenes en la cola, lo que se conoce como un Importar Todo,
seleccionamos el botn 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 importacin.
En la solapa Execution podemos seleccionar si TMS iniciar tp de forma sincrnica o
asincrnica. De forma asincrnica significa que tp trabajar en background y no
bloquear la sesin durante la importacin.
En la solapa Options podemos seleccionar opciones expertas conocidas como modos
incondicionales. Las opciones y las que son por defecto varan segn la estrategia de
transportes configurada.
La pantalla Import Overview muestra si la importacin est corriendo. Despus de la
importacin, la marca de stop es removida y la cola se abre nuevamente
automticamente. Despus que las rdenes de transporte han sido importadas
exitosamente, son automticamente agregadas a la cola de importacin del siguiente
sistema.
Si usamos el procedimiento de Aprobacin de QA, todas las rdenes en la cola de
importacin 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
importacin.
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 aprobacin (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 an si hay todava otras rdenes sin procesar por el procedimiento
de aprobacin o rechazadas en la cola de importacin.
Si realizamos una importacin a travs de la opcin 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 despus de la
importacin estarn activos con los ltimos cambios. Como resultado, los objetos
incorrectos no afectan el ambiente productivo.
Podemos desactivar la opcin de realizar una importacin completa, importar todo,
para cada sistema usando el parmetro de TMS NO_IMPORT_ALL

Figura 150 Importar un Proyecto Completo

Antes de iniciar la importacin, SAP recomienda configurar la marca de stop para

cerrar la cola de importacin. Esto evita la importacin de otras rdenes que podran
aparecer en la cola.
Podemos usar tambin filtros en la cola de importacin para limitar las rdenes que se
muestran con propiedades especficas de forma que podamos ver solo las rdenes que
pertenecen a un proyecto particular o con cierta relacin 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 importacin y seleccionar el botn Filters.

Figura 151 Importar una nica Orden de Transporte (Importacin Preliminar)

En contraste a las importaciones estndar, las importaciones preliminares son

importaciones de una nica orden (o un conjunto seleccionado). SAP recomienda

utilizar la importacin estndar 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 an. Hasta que la tabla no es importada, la ejecucin del reporte generar
short dumps. Por esto debemos usar la importacin preliminar en casos excepcionales.
Para minimizar los riesgos asociados con importaciones preliminares, la orden queda
en la cola de importacin luego de que ha sido importada y es re-importada la prxima
vez que toda la cola es importada. Esto garantiza que la secuencia de exportacin e
importacin es siempre la misma. Esto se define con la opcin Leave Transport
Request in queue for later import, la cual es marcada dependiendo de la estrategia de
transportes.

Leccin 3: Opciones y Estrategias de Transportes

Opciones Adicionales en la Importacin
En circunstancias particulares, podra ser necesario especificar opciones adicionales
cuando realizamos una importacin 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 opcin para que la importacin no
falle.
Sobrescribir objetos en reparaciones sin confirmar: un objeto que fue modificado en
un sistema donde no es original, por ejemplo un objeto estndar 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 opcin.
Ignorar tipo de transporte invlido
Los objetos de las rdenes de transportes seleccionadas para importacin sern
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 ms de una orden de transporte, solo la
versin en la ltima orden de transporte es importada (de acuerdo a la secuencia en la
cola de importacin)
Esto es independiente del mtodo de importacin elegido (Importar Todo, Importar
Proyecto, Importacin Individual)

En un landscape de tres sistemas, la cola de importacin de QAS refleja el orden

de exportacin de DEV. La cola de importacin de PRD refleja el orden de
importacin que se realiz en QAS. Esto no siempre es idntico en todos los
casos. Pero es la secuencia correcta.

Planificacin de Importacin

Figura 152 Fecha y Hora de Importacin

Dependiendo si seleccionamos la importacin por proyecto, importacin individual,

importar todo, o un workflow especial de transporte y particularmente de la versin de
SAP y nivel de Support Package, las opciones pueden variar. Cuando iniciamos una
importacin, podemos elegir las siguientes opciones en la solapa Date:
Immediate
Seleccionando esta opcin inmediatamente inicia la importacin en un work process de
dilogo.

At Start Time
Si elegimos esta opcin la importacin inicia en una fecha y hora especfica. Se
planifica un job de background en el sistema destino. Si ingresamos un fecha y hora en
el campo No Start After, la importacin 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 importacin no se relaliza. Si queremos que la
importacin se realice regularmente debemos ingresar la frecuencia en el campo
Period.
After Event
Seleccionando esta opcin la importacin se inicia solamente despus que un evento
especfico se dispare. Si seleccionamos Execute Import Periodically, la importacin se
inicia cada vez que el evento seleccionado ocurre. De otra manera, la importacin
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 importacin de cada sistema SAP, podemos monitorear y mantener
todas las importaciones planificadas seleccionando Goto Job Monitor.

Figura 153 Frecuencia de Transportes

Despus de la exportacin, una orden de transporte no es importada

automticamente, sino que debe hacerse manualmente. Cuando planificamos las
importaciones, deberamos incluir un tiempo suficiente entre cada importacin para
poder realizar las tareas de pos-importacin tal como las pruebas de QA.
SAP recomienda que la planificacin 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 importacin frecuente no es recomendada.
Las siguientes acciones tienen que considerarse:
Liberacin de rdenes de transportas.
Copia en un cliente en el mismo sistema (de desarrollo) mediante la transaccin
SCC1 (test unitario).
Importacin 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 sincronizacin, esto es, cuando son requeridos los cambios en los
diferentes sistemas.
Requerimientos de Congelamiento de Cdigo (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 solucin si tenemos que adminsitrar un gran
nmero de transportes y queremos automatizar el proceso lo ms que podamos. El uso
continuo de importacin masiva es la forma ms segura de mantener los sistemas
sincronizados y consistentes. Antes de importar con este mtodo en el sistema de
produccin, deberemos verificar que todas las rdenes en el sistema de calidad y la
confirmacin (o aprobacin) de estas en los dems sistemas (por ejemplo el de
produccin).
Para esto usamos el procedimiento de QA en TMS. Tambin deberemos definir la
importacin masiva como el mtodo elegido para los sistemas relevantes. Para esto,
seleccionamos la estrategia de transportes Queue-controlled mass imports.
El administrador puede planificar las importaciones peridicamente en TMS, o iniciar
cada importacin manualmente. Solamente deberamos importar rdenes individuales
antes que otras segn el orden de la cola de importacin en casos especiales.
Las rdenes de transportes que son importadas previamente son importadas
nuevamente en la importacin normal, o sea la importacin masiva. Esto es as por la
opcin Leave transport request in queue for later import la cual se selecciona
automticamente cuando realizamos un transporte que no sea masivo (Importar
Todo). Tambin podemos usar workflow para importar rdenes de transportes
individuales.
Importacin Individual: usamos esta estrategia si tenemos pocos cambios para
transportar y la organizacin no nos permite realizar una planificacin fija de
transportes. Este mtodo usualmente demanda un esfuerzo extra para los
administradores en comparacin a los transportes peridicos. Los desarrolladores
debern poner atencin a la consistencia de sus rdenes de transportes.
Si un nmero pequeo de desarrolladores estn trabajando en un proyecto, y tambin
en un mismo equipo con el administrador, usualmente crean sus propias rdenes de
transporte e incluso la importacin 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 mtodo automticamente dispara un workflow cuando se libera la
orden de transporte.
El workflow asegura la comunicacin entre el desarrollador y el administrador. Como
requisito tendremos que haber configurado el worfklow de transportes en el sistema.

Leccin 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 instalacin y configuracin de TMS. Si queremos trabajar con transportes
individuales controlados por cola o transportes controlados por workflow, podremos
seguir los pasos de configuracin descriptos a continuacin:

Figura 154 Transaccin STMS: Overview Transport Routes

Inicia la transaccin 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 edicin seleccionando Configuration ->Display Change.

3. Posiciona el cursor sobre el sistema SAP para el cual queremos cambiar la

configuracin 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 opcin Leave transport request in queue for later import est activada,
cuando se realiza una importacin individual.
La opcin de importacin Leave transport request in queue for later import
hace que las rdenes importadas como transportes individuales se mantengan
en la cola de importacin para que sean importadas en el orden correcto en la
prxima importacin de todas las rdenes.
Esta opcin es til si tenemos que hacer una importacin preliminar para rdenes
individuales. Esto previene que objetos ms antiguos sean importados en la prxima
importacin normal de todas las rdenes.
Queue-controlled single transports (Transportes individuales controlado por
cola)
Por defecto, la opcin de importacin Leave transport request in queue for later import
est desactivado.
La barra de botones en la cola de importacin cambia de acuerdo a los requisitos de la
estrategia de importacin de transportes individuales. Por ejemplo, contiene una
funcin de seleccin.
En la funcin Importar Todo (el camin con carga completa) est solamente disponible
si elegimos uno o ms proyectos usando la funcin 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 automticamente cuando las rdenes son
exportadas.
Las opciones de importacin 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 importacin si intentamos realizar transportes
sin usar el workflow de transportes.
Los siguientes parmetros para el programa de control de transportes y el Sistema de
Cambios y Transportes (CTS) son configurados acorde a la estrategia de transportes
elegida:
Parmetros de tp para las estrategias de transportes:

El parmetro de tp STOPONERROR define a partir de que cdigo de error la

importacin se detiene. REPEATONERROR define desde que cdigo de error la
importacin no es clasificada como exitosa y tiene que repetirse. Por ejemplo, con
Transportes Individuales, el cdigo de error 8 es tomado como una importacin fallida
y tiene que ser repetida. Con Transportes Masivos, el mismo cdigo de error 8 ser
una importacin exitosa.
No cambies manualmente los parmetros que son relevantes a la estrategia de
transportes. TMS genera estos parmetros cada vez que la configuracin de
rutas de transportes es modificada.
Transportes de Copias y Reubicacin

Figura 155 Transporte de Copias y Reubicacin

Utiliza la funcin Transport of copies para transportar objetos a otro sistema SAP que
seleccionemos. Esta funcin es especialmente til si el sistema destino no es un
sistema de consolidacin desde el sistema donde vamos a generar la orden. Los
objetos son transportados con la versin que tienen en el sistema donde nos
encontramos. La ubicacin original del objeto (sistema origen) no es modificada. La
orden de transporte no ser agregada tampoco a la cola de importacin de un sistema
subsiguiente en la ruta de transportes.

La funcin 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 podran 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 funcin 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 ubicacin original de los objetos al sistema
destino y tambin 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 importacin.
Usamos Relocations of Complete Package cuando el sistema de desarrollo de un
paquete completo ser cambiado de manera permanente.

Leccin 5: Configuracin y Caractersticas del Procedimiento de QA

Las rdenes de transportes sern importadas en el sistema de produccin solamente
despus que sean aprobadas en el sistema de calidad. Por lo tanto necesitaremos
contar con un procedimiento de aprobacin de calidad.
Aseguramiento de Calidad en TMS
El procedimiento de aseguramiento de calidad (QA) incrementa la calidad y la
disponibilidad del sistema de produccin permitindonos verificar las rdenes de
transporte en el sistema de calidad antes de que sean entregadas en los sistemas
subsiguientes.
Cuando activamos el procedimiento de aprobacin de calidad QA, las rdenes de
transporte estarn 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 debern
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 Configuracin del Procedimiento de Aprobacin de QA

Antes que podamos procesar rdenes de transportes deberemos configurar el

procedimiento de aprobacin 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 consolidacin.
Debe tener una ruta de entrega hacia otro sistema al menos.
Despus de la configuracin, la lista de trabajo de QA es automticamente creada.
Todas las rdenes importadas en el sistema de QA son incluidas en la lista de trabajo
de QA.
Pasos en el Procedimiento de Aprobacin de QA
Para visualizar la lista de trabajo de QA, usamos las transaccin 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 an estn pendientes
de procesamiento.
La lista muestra las rdenes de transporte que se corresponden con el paso de
aprobacin seleccionado. Por defecto, las rdenes correspondientes a todos los pasos
se visualizan en primer lugar. Para seleccionar el paso de aprobacin 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
ms detalles sobre el mismo.

Figura 157 Aprobacin QA

Antes de importar las rdenes en un sistema de entrega deberamos testear las

rdenes en el sistema de QA. El estado de QA rechazada (rejected) siginifica que uno o
ms pasos de aprobacin no fueron aprobados por la persona responsable. Una orden
es aprobada solamente si todos los pasos de aprobacin tienen el estado aprobado
(approved).
En la lista de trabajo de QA podemos ver:
El estado de QA (St)
El estado general (GS)
El nmero de paso (Nr)
Una vez que todos los pasos de aprobacin 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 an tengan rdenes pendientes de
procesar o rechazadas en la lista de trabajo de QA.
Las rdenes con el estado rechazada en QA as tambin como las rdenes an sin
procesar en la lista de trabajo no son importadas en los sistemas de entrega.
A partir de la versin 6.10 la aprobacin o rechazo de un paso individual puede ser
modificado, mientras que el procedimiento completo de aprobacin no est realizado.
Una vez que todos los pasos de aprobacin estn completo, no es posible cambiar la
decisin.
SAP recomienda no rechazar las rdenes que contengan errores, sino ms 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 perodo especfico 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 perodo por defecto para la lista
de QA es de 30 das 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
produccin por ejemplo, el historial se perder. Podemos consultar por notas en
el Marketplace de SAP para mayor informacin.

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 debera tener las siguientes
caractersticas 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 transaccin STMS y luego desde el men Overview Systems Goto
Transport Domain.
Seleccionamos la solapa Worfklow Engine.
Cambiamos al modo de edicin con el botn 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
configuracin. A continuacin ingresamos al sistema que funcionar como el Workflow
Engine. El sistema automticamente:
Crea el usuario TMSADM_WF.
Genera los destinos RFC necesarios para el Workflow Engine.
Enva 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, transaccin 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 descripcin y el sistema destino, y
tambin podremos agregar otras rdenes de transporte. La condicin es que todas las
rdenes que ingresemos en la propuesta de transporte estn liberadas.
Si una propuesta de transporte es creada, el sistema SAP le asigna un nmero 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.
Despus que el administrador de transportes ha aprobado la propuesta, la importacin
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 transaccin 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
importacin y opciones para la propuesta de transportes son correctas. Tambin
podemos visualizar las rdenes de transporte seleccionando Display y el cono de los
logs de transportes.
Cambiamos al modo de modificacin si queremos hacer modificaciones a las rdenes
de transportes, destinos, fecha de importacin u opciones de importacin.
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 importacin en el o los sistemas
destinos es iniciada automticamente.