Adm SAP

DE SISTEMAS DE
GESTION
INFORMACION
Universidad de Deusto - Facultad de Ingeniera

Antonio Toledo Carnicero
Pablo Perez Perez
c Octubre de 2004

c

copyleft
Copyright (c) 2004 Pablo Perez Perez y Antonio Toledo Carnicero.
This
work
is
licensed
under
the
Creative
Commons
AttributionNonCommercial-ShareAlike License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc-sa/2.0/ or send a letter to Creative
Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Copyright (c) 2004 Pablo Perez Perez y Antonio Toledo Carnicero.

Esta obra esta licenciada bajos los terminos de la licencia Atribucion-No ComercialComparte Igual de Creative Commons. Para ver una copia de esta licencia visite
http://creativecommons.org/licenses/by-nc-sa/2.0/es/deed.es o escriba una carta a
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Prefacio
En los u
ltimos 10 a
nos la implantacion de sistemas de informacion tipo
ERP en las grandes empresas ha sido masiva. SAP R/3 es el maximo
exponente de ello al ser el lder mundial en n
umero de instalaciones. La
gran amplitud y complejidad de un sistema R/3 exige la especializacion del
personal de la empresa en cada uno de sus aspectos como pueden ser, la
funcionalidad, la parametrizacion, la programacion o la administracion del
sistema. Es en este u
ltimo aspecto, la administracion del sistema, en el que
se centra la presente obra.
Audencia
Este libro esta especficamente escrito para los alumnos de la asignatura
Gestion de Sistemas de Informaci
on dentro del quinto curso del programa de
estudios de Ingeniera en Informatica de ESIDE en la Universidad de Deusto.
Son a ellos, principalmente, a quien va dirigido el libro.
No obstante, a lo largo de nuestra experiencia laboral hemos tenido
la oportunidad de mostrar varios captulos del libro a diversas personas
que trabajan con SAP R/3. A algunos programadores y tecnicos de
atencion a usuarios les ha resultado u
til para comprender determinados
aspectos globales de SAP que no tratan habitualmente en su trabajo diario
como la arquitectura del sistema, el sistema de transporte o la seguridad.
Tambien puede servir como introduccion a los que quieran iniciarse en la
administracion de sistemas R/3.
Sobre los autores

Pablo P
erez completo sus estudios de licenciatura en informatica en
la Universidad de Deusto en el a
no 1995. Comenzo su experiencia con
SAP R/3 en 1997, en la empresa de automocion Grupo Antoln, como
programador de ABAP/4 y administrador de sistemas. Posteriormente ha
3
4
trabajado como analista y consultor tecnico de SAP para varias empresas y
formo parte durante 5 a
nos del equipo de desarrollo de Finanzas y Control
de Gestion en la electrica Iberdrola. En la actualidad es el responsable de los
sistemas informaticos de la empresa reprografica Cianoplan y ocasionalmente
trabaja como analista freelance de ABAP/4. Su experiencia docente incluye
varias ediciones del Master de Consultora e Implantaci
on de Sistemas de
Informacion y la Diplomatura de Especializaci
on en Gesti
on de Sistemas y
Redes, ambos ttulos de postgrado impartidos por la Universidad de Deusto.
Antonio Toledo es licenciando en Ciencias Fsicas por la Universidad
del Pas Vasco desde el a
no 1995. Trabajo tambien como programador de
ABAP/4 y administrador de sistemas en la empresa Grupo Antoln. Despues
presto servicios de administracion y consultora de sistemas formando parte
de la empresa Ceinsa. En la actualidad trabaja en la consultora IT Deusto
formando parte del equipo de administracion de sistemas SAP R/3 de
Iberdrola. Ha colaborado en varias ocasiones como profesor en el Master de
Consultora e Implantacion de Sistemas de Informaci
on y la Diplomatura de
Especializacion en Gesti
on de Sistemas y Redes de la Universidad de Deusto.
Indice general
Copyleft
1. Introducci
on a SAP R/3
1.1. Software estandar vs. software a medida
1.2. Vision general de SAP R/3 . . . . . . .
1.2.1. Caractersticas principales . . . .
1.2.2. Modulos . . . . . . . . . . . . . .
1.2.3. Entorno de desarrollo . . . . . . .
2. Introducci
on al sapgui
2.1. Pantalla de logon a SAP R/3 . . .
2.2. Concepto de mandante . . . . . . .
2.3. La barra de ttulo . . . . . . . . . .
2.4. El men
u desplegable . . . . . . . .
2.5. La barra estandar de herramientas
2.6. La barra de aplicaciones . . . . . .
2.7. La pantalla principal . . . . . . . .
2.8. La barra de estado . . . . . . . . .
2.9. Ventana de dialogo . . . . . . . . .
2.10. Ayudas de b
usqueda . . . . . . . .
2.11. Modos . . . . . . . . . . . . . . . .
2.12. Concepto de transaccion . . . . . .
2.13. Opciones tecnicas . . . . . . . . . .
2.14. La pantalla status . . . . . . . . . .
3. Arquitectura de un sistema R/3
3.1. Introduccion . . . . . . . . . . .
3.2. Servicios de base de datos . . .
3.3. Servicios de aplicacion . . . . .
3.4. Servicios de presentacion . . . .
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
14
14
16
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
21
24
24
25
27
27
28
29
29
30
32
33
34
.
.
.
.
37
37
39
40
43
INDICE GENERAL
4. Escenarios de configuraci
on
4.1. Consideraciones generales sobre los sistemas R/3 . . . . . . . .
4.2. Descripcion y funciones de cada sistema . . . . . . . . . . . .
4.2.1. Sistema de desarrollo . . . . . . . . . . . . . . . . . . .
4.2.2. Sistema de integracion . . . . . . . . . . . . . . . . . .
4.2.3. Sistema de produccion . . . . . . . . . . . . . . . . . .
4.3. Mandantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1. Mandantes estandar . . . . . . . . . . . . . . . . . . .
4.3.2. Mandantes propios . . . . . . . . . . . . . . . . . . . .
4.4. Comparacion de escenarios . . . . . . . . . . . . . . . . . . . .
4.4.1. Configuracion con un solo sistema (Produccion) . . . .
4.4.2. Configuracion con dos sistemas (Desarrollo y Produccion)
4.4.3. Configuracion con tres sistemas (Desarrollo, Integracion y Produccion) . . . . . . . . . . . . . . . . . .
45
45
46
46
46
47
47
47
48
50
50
51
52
5. Monitorizaci
on de procesos y usuarios
55
5.1. Monitorizacion de procesos activos . . . . . . . . . . . . . . . 55
5.2. Monitorizacion usuarios conectados . . . . . . . . . . . . . . . 60
6. Procesamiento en fondo
6.1. Conceptos de procesamiento en fondo
6.2. Definicion de jobs . . . . . . . . . . .
6.2.1. Informacion general . . . . . .
6.2.2. Hora de inicio o evento . . . .
6.2.3. Pasos . . . . . . . . . . . . . .
6.3. Analisis de jobs . . . . . . . . . . . .
6.3.1. Estados de un job . . . . . . .
6.3.2. Operaciones sobre jobs . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7. Servicios de actualizaci
on
7.1. Actualizacion sncrona y asncrona . . . . .
7.2. Procesos de actualizacion V1 y V2 . . . . .
7.3. Monitorizacion del estado de la actualizacion
7.4. Actualizaciones interrumpidas . . . . . . . .
7.5. Entradas de bloqueo . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
del
. .
. .
8. Log del sistema y an

alisis de dumps
8.1. Conceptos del log del sistema . . . . . . . . . .
8.1.1. Accediendo al log local del sistema . . .
8.1.2. Accediendo al log local en modo normal
8.1.3. Accediendo al log local en modo experto
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
sistema
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
65
66
66
67
68
68
69
70
.
.
.
.
.
73
73
75
75
77
80
.
.
.
.
85
85
86
86
88
INDICE GENERAL
8.1.4. Leyendo el log del sistema . . . . . . . .

8.1.5. Opciones de relectura del log del sistema
8.1.6. Accediendo a logs remotos del sistema .
8.2. Concepto de dump . . . . . . . . . . . . . . . .
8.2.1. Accediendo a los dumps del sistema . . .
8.2.2. Interpretando los dumps . . . . . . . . .
9. Gesti
on de spool
9.1. Concepto de spool . . . . . . . . .
9.2. Instalacion de una impresora . . . .
9.3. Como imprimir . . . . . . . . . . .
9.4. Operaciones sobre ordenes de spool
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
89
91
92
92
94
.
.
.
.
103
. 103
. 103
. 106
. 108
10.Gesti
on de usuarios y autorizaciones
111
10.1. Modelo de seguridad en R/3 . . . . . . . . . . . . . . . . . . . 111
10.2. Mantenimiento de usuarios . . . . . . . . . . . . . . . . . . . . 113
10.3. Generador de perfiles . . . . . . . . . . . . . . . . . . . . . . . 116
11.Sistema de transporte
11.1. Ordenes
de transporte . . . . . .
11.2. Clases de desarrollo . . . . . . . .
11.3. Tipos de ordenes de transporte . .
11.4. Estados de una orden de transporte
11.5. Customizing organizer y workbench
11.6. Transporte manual de ordenes . .
11.7. Log del transporte . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
y sus tareas
organizer .
. . . . . . .
. . . . . . .
12.Gesti
on de mandantes
12.1. Creacion de un nuevo mandante . .
12.2. Copia local de mandante . . . . . .
12.3. Copia remota de mandante . . . . .
12.4. Transporte de mandante . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
121
. 121
. 124
. 124
. 126
. 127
. 131
. 136
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
153
. 153
. 153
. 157
. 158
. 159
. 159
. 161
13.Mantenimiento de instancias
13.1. Perfiles del sistema . . . . . . . . . . . . . . . . .
13.1.1. Mantenimiento de perfiles del sistema . . .
13.1.2. Importacion de perfiles del sistema . . . .
13.1.3. Visualizacion todos los parametros activos
13.1.4. Parametros mas importantes de un sistema
13.2. Modos de Operacion . . . . . . . . . . . . . . . .
13.2.1. Gestion de modos de operacion . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
R/3
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
139
140
145
148
149
INDICE GENERAL
13.3. Grupos de logon . . . . . . . . . . . . . . . . . . . . . . . . . 164

13.3.1. Gestion de grupos de logon . . . . . . . . . . . . . . . 165
13.3.2. Saplogon . . . . . . . . . . . . . . . . . . . . . . . . . 166
A. Transacciones m
as comunes
171
B. Recursos Web
177
C. Casos reales
179
C.1. Autodesk, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
C.2. Schweppes, S.A. . . . . . . . . . . . . . . . . . . . . . . . . . . 180
C.3. IBM Espa
na . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
D. Glosario
185
Indice de figuras
2.1. Pantalla de entrada a SAP R/3 . . . . . . .
2.2. Barra de ttulo . . . . . . . . . . . . . . . .
2.3. Barra de aplicaciones . . . . . . . . . . . . .
2.4. Pantalla principal . . . . . . . . . . . . . . .
2.5. Barra de estado . . . . . . . . . . . . . . . .
2.6. Ventana de dialogo . . . . . . . . . . . . . .
2.7. Ayuda de b
usqueda . . . . . . . . . . . . . .
2.8. Listado de valores posibles . . . . . . . . . .
2.9. Icono de acceso a las opciones tecnicas . . .
2.10. Menu del icono de acceso a opciones tecnicas
2.11. Status del sistema . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
24
27
27
28
29
30
31
33
33
35
3.1. Capas de la estructura cliente/servidor de R/3 . . . . . . . . . 37

3.2. Arquitectura abierta de R/3 . . . . . . . . . . . . . . . . . . . 39
3.3. Esquema del funcionamiento del dispatcher . . . . . . . . . . . 42
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
Monitor de procesos de una instancia . . . . .

Monitor de instancias activas . . . . . . . . .
Monitor de sistema operativo . . . . . . . . .
Monitor de conexion de usuarios por instancia
Lista de modos activos por usuario . . . . . .
Informacion detalllada de usuario . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
59
60
61
62
62
6.1. Pantalla inicial de definicion de job . . . . . . . . . . . . . . . 66

6.2. Pantalla inicial de seleccion de jobs . . . . . . . . . . . . . . . 69
6.3. Resumen de jobs seleccionados . . . . . . . . . . . . . . . . . . 70
7.1.
7.2.
7.3.
7.4.
7.5.
Esquema funcionamiento actualizacion asncrona .

Esquema funcionamiento actualizacion sncrona .
Pantalla principal monitor actualizacion . . . . .
Actualizaciones pendientes . . . . . . . . . . . . .
Modulos de actualizacion . . . . . . . . . . . . . .
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
74
76
78
79
INDICE DE FIGURAS
10
7.6. Pantalla principal entradas de bloqueo . . . . . . . . . . . . . 81

7.7. Listado de bloqueos activos en el sistema . . . . . . . . . . . . 81
7.8. Informacion detallada de un bloqueo . . . . . . . . . . . . . . 82
8.1.
8.2.
8.3.
8.4.
8.5.
8.6.
8.7.
Pantalla principal log local del sistema . . . . . . . . .

Parametros de seleccion adicionales en modo experto .
Contenido del log del sistema . . . . . . . . . . . . . .
Opciones de la barra de aplicaciones del log del sistema
Pantalla principal log remoto del sistema . . . . . . . .
Pantalla principal de analisis de dumps . . . . . . . . .
B
usqueda de dumps antiguos . . . . . . . . . . . . . .
9.1.
9.2.
9.3.
9.4.
9.5.
9.6.
9.7.
Transaccion SPAD. Mantenimiento de dispositivos

Datos generales para una impresora local . . . . .
Tipo de impresora para una impresora local . . .
Ventana de dialogo para imprimir un listado . . .
Transaccion SP01. Seleccion de ordenes de spool .
Transaccion SP01. Listado de ordenes de spool . .
Atributos de una orden de spool . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
88
90
90
91
93
93
de salida
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
104
105
106
107
109
109
110
10.1. Componentes de la seguridad en R/3 . . . . . . . .

10.2. Pantalla inicial de la actualizacion de usuarios . . .
10.3. Datos de direccion del maestro de usuarios . . . . .
10.4. Transaccion PFCG. Mantenimiento de papeles . . .
10.5. Descripcion del papel . . . . . . . . . . . . . . . . .
10.6. Transacciones asignadas a un papel . . . . . . . . .
10.7. Asignacion de valores a los objetos de autorizacion .
10.8. Asignacion de un papel a usuarios . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
112
114
115
116
117
118
119
119
11.1. Esquema de una orden de transporte . . . . .

11.2. Esquema de ordenes de transporte . . . . . . .
11.3. Clase de desarrollo . . . . . . . . . . . . . . .
11.4. Esquema pasos del transporte . . . . . . . . .
11.5. Pantalla principal Workbench Organizer . . .
11.6. Ordenes
de transporte . . . . . . . . . . . . .
11.7. Creacion de una orden de transporte . . . . .
11.8. Listado de ordenes transportadas y liberadas .
11.9. Transporte de una orden a un sistema destino
11.10.Esquema ejemplo del transporte de una orden
11.11.Visualizacion individual de ordenes . . . . . .
11.12.Log del transporte de una orden . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
123
123
125
127
128
129
131
133
134
135
137
137
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INDICE DE FIGURAS
11
12.1. Pantalla principal de la gestion de mandantes

12.2. Detalle de opciones de un mandante . . . . . .
12.3. Copia local de un mandante . . . . . . . . . .
12.4. Detalle de un perfil de copia . . . . . . . . . .
12.5. Copia remota de un mandante . . . . . . . . .
12.6. Export de mandante . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
141
142
145
147
148
150
13.1. Pantalla pricipal perfiles del sistema . . .

13.2. Datos de gestion de un perfil . . . . . . .
13.3. Actualizacion basica de un perfil . . . . .
13.4. Actualizacion ampliada de un perfil . . .
13.5. Modos de operacion . . . . . . . . . . . .
13.6. Distribucion de procesos de trabajo . . .
13.7. Pantalla principal asignacion horaria . .
13.8. Asignacion horaria a modos de operacion
13.9. Pantalla principal grupos de logon . . . .
13.10.Pantalla detalles creacion grupo logon . .
13.11.Pantalla de saplogon . . . . . . . . . . .
13.12.Opcion de seleccion servidor en saplogon
13.13.Opcion propiedades en saplogon . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
155
155
156
157
161
162
163
164
166
167
168
169
169
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Captulo 1
Introducci
on a SAP R/3
1.1.
Software est
andar vs. software a medida
Tras la continua y masiva introduccion de la informatica en los sistemas

de gestion empresariales durante mas de treinta a
nos, nos encontramos
a principio de los noventa con un panorama variopinto. Los diversos
departamentos de gestion de la mayora de las empresas utilizan varios
software diferentes hechos a medida por el propio departamento de TI1 o
por alguna consultora externa. La compatibilidad es casi nula y la creacion
de interfases para integrar los datos de un departamento con otro esta a la
orden del da. Veamos un ejemplo clarificador de esta situacion. El director
del departamento de TI de una empresa dedicada a la fabricacion de grandes
piezas industriales, refleja su caotica situacion:
Nuestra planta de 1.500 trabajadores esta operando sobre
una amalgama formada por sistemas anticuados y modernos
servidores. Estamos operando TCP/IP, IPX y Decnet en nuestra
Ethernet y tenemos concentradores de todo tipo. Algunos
departamentos tienen clientes ligeros y estan formulando grandes
demandas en la red ya que operan procesos en el servidor y estan
reenviando datos de un sitio para otro.
Los sistemas de contabilidad e inventario que tiene la planta
operan en mainframes de arquitectura 370. Un desfasado sistema
de planificacion de recursos de fabricacion (MRP) opera en
un VAX de gama alta. Y parte del software de gestion de la
fabricacion y de transporte opera en un AS/400. Practicamente
1
Tecnologas de la informaci
on
13
A SAP R/3
CAPITULO 1. INTRODUCCION
14
todo el codigo de cosecha propia que tiene la planta esta escrito

en COBOL.
Aproximadamente la mitad de los operarios de la planta
trabaja con una diversidad de sistemas Windows. La otra mitad
permanece conectada al mainframe IBM con terminales no
inteligentes tipo 3270. Existe una red de area local que engloba
a toda la planta y que opera Novell 3.11, asi como una peque
na
cantidad de servidores NT no tan grandes pero en crecimiento.
Un situacion como esta obliga al departamento de TI a incurrir en grandes
costes para poder mantener en pie unos sistemas que ya no son tan efectivos
como antes. Hablamos de programas que se dise
naron para las necesidades
especificas de la empresa hace unos a
nos y que con la evolucion que ha venido
sufriendo la industria y la tecnologa, se han quedado obsoletos. Ademas de
las deficiencias que cada empresa detecta en sus sistemas de informacion
tenemos que tener en cuenta otros factores generales que afectan a todas
ellas. Problemas como el efecto 2000 o la introduccion del Euro como moneda
u
nica en los pases de la CEE no pueden ser obviados por el departamento
de TI.
La pregunta que se plantea cualquier empresa en esta situacion es la
siguiente Vamos rehaciendo y adaptando nuestro software o adquirimos
una solucion estandar?. Veremos que casi todas la grandes empresas han
optado por una solucion estandar. En la mayora de los casos se trata de
SAP R/3 , por ello es el lder mundial, pero existen otras opciones como
Baan, PeopleSoft, Oracle Financials o en menor medida Ross, BCPS o JD
Edwards.
1.2.
1.2.1.
Visi
on general de SAP R/3
Caractersticas principales
Las m
ultiples ventajas del software R/3 hace que se haya convertido
en uno de los estandares de hecho dentro de las grandes corporaciones. A
continuacion detallaremos algunas de estas ventajas.
Exhaustivo El sistema R/3 engloba la practica totalidad de los procesos de
gestion de la empresa. En el siguiente apartado veremos detallados la
cantidad de modulos que incluye.
Integrado Tal cantidad de modulos no aportaran demasiado valor a
nadido
a la empresa si no fuera por la integracion. Las interrelaciones estrechas
GENERAL DE SAP R/3

1.2. VISION
15
entre modulos de SAP permiten tener disponible en tiempo real y

con exactitud los principales indicadores de gestion. Como ejemplo
ilustrativo diremos que una entrada de mercancas en R/3 puede
producir una actualizacion del inventario de almacen, un apunte
contable en la contabilidad financiera, un actualizacion del sistema de
informacion del control de costes y un aviso a produccion de que hay
nueva materia prima en almacen.
Abierto Tecnologicamente hablando, SAP es un sistema abierto. Podemos
implantarlo en una variedad enorme de servidores diferentes y
ejecutarlo sobre sistemas operativos y sistemas de gestion de bases
de datos de diversos fabricantes. Esto nos permite escalar nuestro
sistema adecuandolo a nuestro tama
no de empresa y elegir a nuestros
proveedores de hardware y software de sistemas sin estar atados a
ninguno. La arquitectura sigue varios de los estandares de sistemas
abiertos como POSIX o X/OPEN.
Flexible Podemos utilizar junto con SAP R/3 otros productos de software
de otros fabricantes, existen interfases con productos de Microsoft,
Lotus o Oracle entre otros. SAP posee tambien un amplio menu de
parametrizacion que nos permite adecuar 1 el sistema a nuestras
necesidades, asi como un completo sistema de desarrollo para crear
nuestros nuevos programas y que mantengan la integracion con el
estandar.
Global El sistema R/3 soporta su utilizacion en varios idiomas, la
contabilizacion de documentos en cualquier moneda y tiene recogidas
las particularidades fiscales y de gestion de recursos humanos de un
gran n
umero de pases. Esta globalidad es el argumento de mayor peso
en la decision de una multinacional a la hora de adquirir SAP.
Actualizado Dos de los grandes problemas de los departamentos de TI a
finales de los 90 han sido el efecto 2000 y la entrada en vigor del euro. El
software SAP R/3 tiene contemplados y solucionados estos problemas.
Ademas, la constante investigacion llevada a cabo por SAP hace que su
software este al da incluyendo la u
ltima tecnologas disponibles como
EDI, Data Warehouse, clientes Java, comercio electronico. . . .
1
Para referirse a la adecuaci

on del sistema a la necesidades del cliente se escuchara frecuentemente el termino anglosajon customizing que en castellano se traduce
por parametrizaci
on. La palabra inglesa proviene de customer cliente por lo que el significado completo de customizing viene a ser modificacion de los parametros del sistema
para adecuarlo a las necesidades del cliente
A SAP R/3
16
1.2.2.
M
odulos
Como apuntabamos anteriormente el software de SAP es un compendio

realmente exhaustivo de aplicaciones de gestion. A cada uno de los
componentes que sirven para gestionar cada una de la areas de la empresa se
les denomina modulos y se les nombra con dos letras correspondientes a las
iniciales del nombre en ingles. Los modulos principales (finanzas, logstica
y recursos humanos) se componen a su vez de submodulos. Estos son los
principales modulos y sus caractersticas.
1. Gesti
on Financiera FI Financial Accounting. Re
une todos los
datos de la empresa relevantes para la contabilidad financiera. Recibe
todas la imputaciones contables del resto de modulos y las centraliza en
un base de datos actualizada en tiempo real. Esto nos permite conocer
el estado contable de nuestra compa
nia (balance y cuenta de perdidas
y ganancias) en todo momento. Los submodulos que la componen son
los siguientes.
Control de Gesti
on CO Controlling. La contabilidad financiera no
siempre puede proporcionar informacion desde todos los puntos
de vista que una gestion eficaz de costes requiere y es, en este
punto, donde act
ua el modulo CO. Partiendo de los datos de
FI, la contabilidad analtica nos muestra los ingresos, gastos e
inversiones desde vistas diferentes. Si juntamos esto con el sistema
de planificacion y prevision de costes obtendremos un sistema
de informacion completo con las comparativas del plan contra el
real que nos permiten saber si nos ajustamos al presupuesto y el
porque.
Tesoreria TR Treasury. Representa la solucion completa para
una gestion economico financiera eficaz. Nos permite asegurar la
liquidez de la empresa en todo momento y estructurar los activos
financieros de la manera mas lucrativa posible.
Activos Fijos AM Asset Management. Nos permite controlar el
ciclo de vida completo del nuestro inmovilizado, desde la inversion
inicial en activos fijos en curso, pasando por la contabilizacion
de la manera mas conveniente las amortizaciones, la puesta en
explotacion de dicho inmovilizado y la enajenacion del mismo.
Existe otro peque
no submodulo denominado gestion de inversiones
(IM Investment Management) que esta muy relacionado con AM.
2. Logstica LO Logistics. Bajo este epgrafe se engloba la gestion
de todo el ciclo de vida de los productos de una empresa, desde la
GENERAL DE SAP R/3

1.2. VISION
17
compra y almacenaje de materia prima, pasando por la fabricacion del

producto hasta su venta y distribucion. Es el modulo mas grande de
todos ellos y el que mas componentes tiene. Describimos a continuacion
los mas usados aunque existen otros menos conocidos como la gestion
del servicio al cliente, la gestion de proyectos y la gestion de la calidad
de productos.
Gestion de Materiales MM Materials Management. Optimiza
todos los procesos de compra a traves de varias funciones
disponibles. Por un lado permite automatizar las evaluaciones de
proveedores mediante la entrada de ofertas y el mantenimiento de
registros info. Tambien podemos reducir los costes de aprovisionamiento y almacenamiento, gracias a la precision de la gestion de
stocks y de almacenes. Este es uno de los puntos donde mas claramente poder apreciar el retorno de la inversion porque los costes
de almacenaje es una de las principales preocupaciones de las empresas en la actualidad. Un completo sistema de verificacion de
facturas nos proporciona la integracion necesaria con los modulos
contables FI, CO y TR para tener la informacion actualizada en
tiempo real.
Planificacion de la Producci
on PP Production Planning. Proporciona procesos completos para todos los tipos de fabricacion: fabricacion repetitiva, fabricacion contra pedido, fabricacion contra
catalogo, fabricacion por procesos, fabricacion por lotes y en serie, hasta la gestion integrada de cadenas de suministro con funciones MRP y Kanban. La integracion con MM puede provocar la
solicitud de necesidades automatica al lanzar la planificacion de
requerimientos de material.
Mantenimiento de Planta PM Plant Manteinance. Para una empresa industrial es fundamental el poder garantizar la disponibilidad de la planta y sus herramientas de produccion y de esto se
encarga el modulo de PM. Aplicaciones como la planificacion de
las revisiones, la programacion de ordenes de mantenimiento, las
gestion notificaciones de aprobacion nos aseguran una rendimiento
optimo de nuestra fabrica. Integrando todo esto con PP (podemos
modificar las ordenes de produccion en funcion de la disponibilidad de la cadena de produccion), con HR (calendarios laborales,
turnos. . . ) y con MM (creando solicitudes de necesidad de repuestos, por ejemplo) tenemos controlada una pieza vital de la
empresa.
18
A SAP R/3
Ventas y Distribuci
on SD Sales and Distribution. La cambiante
realidad de los mercados actuales es un reto para cualquier
programa de gestion de ventas. SD es lo suficientemente flexible
como para poder adecuarnos a precios, condiciones de entrega,
descuentos, comisiones y ofertas que a veces cambian a diario.
Informar adeduadamente a los modulos financieros del estado de
nuestras ventas es una labor imprescindible para poder conocer el
estado economico y financiero actualizado de la empresa.
3. Recursos Humanos HR Human Resources. Tradicionalmente, la

gestion de recursos humanos se ha considerado una area aislada del
resto de sistemas de gestion de la empresa. SAP, sin embargo, ha llevado
su maxima de integracion hasta el punto de incluir la gestion de turnos
y plantillas, los horarios de fabricas, y el absentismo laboral en los
procesos de negocio de la fabricacion y el mantemiento de planta entre
otros. Los dos submodulos principales son PA y PD aunque tambien
existen soluciones menos usadas como la gestion de candidatos, el
calendario de fabrica y la gestion de viajes y gastos.
Nomina PA Payroll Accounting. Mantiene todos los datos de los

empleados en unas estructuras denominadas infotipos que nos
permiten calcular el pago de la nomina y contabilizarla tanto en
FI como CO de manera automatica. Existen infotipos para todas
las caractersticas de un empleado, como datos personales, salario
bruto, datos familiares, turnos, retenes, retenciones fiscales. . . Este
submodulo es posiblemente el mas especfico de cada pas debido
a que las leyes que rigen las relaciones laborales difieren mucho
de unos pases a otros. Es por ello que SAP porporciona unos
programas diferentes para cada pas y un servicio de actualizacion
para poder estar al da con los cambios que se producen en
materia de legislacion laboral (aparicion de nuevas modalidades
de contratacion, cambios en la normativa fiscal, etc. . . )
Estructura Organizativa PD Personnel Development. Este submodulo se encarga de gestionar la estructura de la empresa organizando la misma en departamentos, areas, grupos de trabajo,
etc. . . Permite la definicicion de tareas de puestos de trabajo y la
reorganizacion de los mismos.
GENERAL DE SAP R/3

1.2. VISION
1.2.3.
19
Entorno de desarrollo
Aunque la cantidad de aplicaciones desarrolladas por SAP es enorme,

siempre existe la posibilidad de que el cliente que compre R/3 tenga
alguna necesidad tan especfica de su negocio que no este contemplada
en el estandar. Tambien puede darse el caso de que la funcionalidad que
ofrece el estandar no se ajuste completamente a las necesidades del cliente.
Para resolver estas situaciones existe un entorno completo de desarrollo de
nuevas aplicaciones integradas en R/3. Este entorno, que SAP denomina
ABAP/4 Development Workbench, se compone de una serie de herramientas
integradas que permiten crear desarrollos nuevos en poco tiempo.
ABAP/4 El lenguaje de programacion ABAP/4 se caracteriza por su total
integracion en el sistema R/3. No en vano todo el software de aplicacion
(se calcula que mas de treinta millones de lneas de codigo) que el cliente
recibe cuando compra R/3 esta escrito en ABAP. Es un mezcla entre
el COBOL y el SQL, hay que tener en cuenta que se creo en los a
nos
70 cuando el COBOL era el lenguaje preferido para los desarrollos de
aplicaciones de gestion. Es un lenguaje de muy alto nivel, facil de leer
y se aprende rapidamente.
Data Dictionary Es el punto de referencia para los programadores ya que
permite aislarles del sistema de gestion de base de datos que se utilize
por debajo. Desde un misma pantalla se puede crear, modificar y
borrar los objetos de bases de datos, entre los que se incluyen tablas,
estructuras, vistas, elementos de datos y dominios. Las definiciones de
las tablas, por ejemplo, pueden ser referenciadas directamente en los
programas permitiendonos modificar posteriormente las tablas sin tener
que cambiar los programas. Tenemos la posibilidad de gestionar otros
objetos del data dictionary como las ayudas de b
usqueda, los objetos
de bloqueo o los objetos de autorizacion.
Editor de programas El editor ABAP/4, aparte de proveer de las funciones basicas para la edicion de texto, tiene m
ultiples caractersticas
que facilitan la programacion enormemente. Nos permite efectuar una
verificacion de sintaxis y aceptar las sugerencias del dispositivo de correcion automatica que tiene incluido. Tambien nos permite resaltar las
palabras clave y tener una vista en forma de estructura jerarquica que
ofrece la posibilidad de ocultar o desglosar bloques sintacticos. De esta forma, el programador obtiene una buena vision de conjunto de la
estructura general del programa.
A SAP R/3
20
Screen Painter Con esta herramienta crearemos rapidamente interfases

graficas de usuario incluyendo una amplia gama de elementos de
control, como botones de pulsacion, botones de radio, checkboxes,
etiquetas, campos de entrada, listas de base de datos. . . Las pantallas
que se crean se denominan dynpro 2 y en ellas se incluye la definicion
de la pantalla y sus campos y la logica de proceso de la misma.
Esta logica de proceso esta dirigida por eventos, como los lenguajes
visuales modernos, aunque la variedad de eventos posibles esta bastante
limitada.
Entorno de depuraci
on El modo debugging de ABAP/4 es posiblemente
la herramienta mas alabada por los programadores habituales de
este lenguaje. Tiene todas las ventajas de este tipo de ayudas a la
programacion (creacion de breakpoints, watchpoints, ejecucion paso a
paso, ejecucion por bloques. . . ) pero ademas nos permite hacer todo
esto viendo el codigo fuente del programa, por lo que la localizacion del
lugar del error es exacta.
Otras herramientas. Existe una gran variedad de herramientas adicionales
cuyo uso no es tan frecuente como el Menu Painter, el analisis del
tiempo de ejecucion, el Object Browser, el sistema de test asistido por
ordenador (CATT), etc. . .
Abreviatura de dynamic programs
Captulo 2
Introducci
on al sapgui
Como cualquier software que este basado en arquitectura cliente/servidor,
SAP R/3 dispone de un programa cliente que se debe instalar en cada uno
de los servidores de presentacion (PCs) para poder realizar la conexion al
sistema R/3. Este programa cliente se llama SAPGUI o SAP Frontend y es la
herramienta que nos permite navegar por las distintas aplicaciones integradas
que conforman el sistema R/3 de SAP.
2.1.
Pantalla de logon a SAP R/3
Una vez que tengamos instalado el SAPGUI y pulsemos el icono

correspondiente, nos aparecera la pantalla de conexion al sistema R/3
indicada en la figura 2.1.
En esta pantalla deberemos introducir el usuario que nos hayan asignado
as como su clave de acceso.Tambien podremos elegir el idioma de conexion.
SAP R/3 es un software multiling
ue que permite presentar al usuario todos
los textos que aparezcan en pantalla en el idioma que el elija, siempre que
ese idioma haya sido previamente instalado en el sistema. Si el usuario no
introduce idioma alguno, se conectara en el idioma que tenga asignado por
defecto en su registro maestro de usuario.
En esta pantalla aparece un nuevo concepto: Mandante. Este es quiza el
termino mas importante dentro SAP R/3. El usuario, ademas de los datos
arriba especificados, debera indicar a que mandante se quiere conectar.
2.2.
Concepto de mandante
El concepto se puede definir desde 2 puntos de vista distintos pero

complementarios: La Vision Logica y la Visi
on Fsica.
21
22
AL SAPGUI
Figura 2.1: Pantalla de entrada a SAP R/3

La Visi
on L
ogica. El mandante no es mas que una unidad organizativa
divisoria de la empresa y permite que distintos usuarios esten trabajando en
el mismo sistema sin ning
un tipo de interferencia mutua ya que cada usuario
solo dispondra de acceso para visualizar y actualizar los datos de aplicacion
de la empresa que esten asociados al mandante al que estan conectados. Esto
es as porque en el sistema SAP R/3 existen dos tipos de datos diferentes:
Datos dependientes de mandante. Se engloban aqu los datos de
aplicacion de la empresa (datos de clientes, proveedores, pedidos,
facturas, cuentas contables, etc. . . ) as como la mayora de los datos de
parametrizacion de la empresa. Se llaman dependientes de mandante
porque solo son accesibles desde el mandante en el que se crearon. Estos
tipo de datos son los mas habituales en un sistema SAP R/3.
Datos independientes de mandante. Se engloban aqu ciertos datos de
la parametrizacion de la empresa que son accesibles desde cualquier
mandante creado. Este tipo de datos son los menos numerosos. Cada
vez que se va a proceder a la modificacion de este tipo de datos, el
sistema avisa con un mensaje informativo informandonos de que la
modificacion afectara a todos los mandantes. Se ha de ser especialmente
cuidadoso al modificar la parametrizacion independiente de mandante.
La Visi
on Fsica. La base de datos de SAP R/3 esta formada por
tablas relacionales. Cuando el usuario navega por las pantallas de SAP es
2.2. CONCEPTO DE MANDANTE
23
el sistema R/3 el que accede a dichas tablas para irle mostrando al usuario
la informacion pedida. El mandante es el primer campo clave de la mayora
de la tablas que conforman la base de datos de SAP R/3. Las tablas que
contienen al campo mandante como primer campo dentro de su clave son las
llamadas dependientes de mandante. Las tablas que no contienen al campo
mandante dentro de su clave se llaman independientes de mandante.
Cuando un usuario se conecta a un mandante, el sistema le esta asignando
en ese momento el valor del mandante elegido, con lo que el usuario solo
podra acceder a visualizar o modificar los datos de cada tabla que tengan
como mandante el que ha elegido en tiempo de conexion. Sin embargo, si
una tabla es independiente de mandante, esta puede ser accedida desde
cualquier mandante al que se conecte el usuario. Esto se consigue de manera
transparente para el usuario e incluso para el desarrollador ya que es el
propio sistema el que traduce los accesos a las tabla incluyendo en la clausula
WHERE de la instruccion SQL el campo mandante y el valor actual que
tenga.
Ejemplo:
Situaci
on 1: Los usuarios user1 y user2 estan ambos conectados al
mandante 015 de un mismo sistema. Mientras el usuario user1 esta modificando la factura 1000, el usuario user2 solo podra acceder en modo visualizacion
ya que la factura esta siendo bloqueada por el usuario user1; sin embargo,
cuando el usuario user1 termine de modificarla, user2 podra ver la modificacion realizada por user1, e incluso podra realizar cualquier modificacion
posterior.
Situaci
on 2: El usuario user1 esta conectado al mandante 015 y el
usuario user2 esta conectado al mandante 016 del mismo sistema. Ahora los
2 usuarios no pueden acceder a la misma informacion ya que sus conexiones al
sistema estan logicamente separadas; el usuario user1 accede a la factura
1000 de su mandante y el usuario user2 puede acceder al mismo tiempo
a la factura 1000 ( si esta existe ) de su mandante, si bien los datos son
completamente distintos ya que la factura 1000 del mandante 015 no es la
misma que la factura 1000 del mandante 016.
Lo que realmente ocurre es que para poder los usuarios acceder a la
factura 1000, el sistema esta accediendo a la tabla de facturas, pero en cada
caso accede al registro compuesto por el mandante de conexion del usuario
y el n
umero de factura:
AL SAPGUI
24
Mandante
015
015
016
016
Num. factura
1000
1010
1000
1050
Descripcion
Factura X
Factura Y
Factura Z
Factura V
As pues, cuando el usuario user1, conectado al mandante 015, solicita

la factura 1000, el sistema le muestra la factura con descripcion Factura X,
mientras que si el usuario user2 se conecta al mandante 016 para solicitar la
factura 1000, el sistema le mostrara la factura con descripcion Factura Z.
2.3.
La barra de ttulo
Figura 2.2: Barra de ttulo

Con la visualizacion antigua del sapgui se encuentra en la parte superior
de la pantalla y su funcion principal es mostrarnos la descripcion de la
transaccion o men
u de ambito en curso. En la nueva visualizacion del
sapgui se encuentra entre la barra estandar de herramientas y la barra de
aplicaciones.
Ejemplos: Crear usuario, Visualizar material.
2.4.
El men
u desplegable
El men
u desplegable es la herramienta basica para la navegacion por
las distintas aplicaciones del sistema SAP R/3. En el podremos encontrar
todas las funciones necesarias para un llevar a cabo un control total sobre
las transacciones y programas. El men
u desplegable se caracteriza por tener
fijas las u
ltimas dos opciones de la derecha. Estas dos opciones son:
Sistema. Opcion para crear y borrar modos, desconexion del sistema,
ver el status de nuestra sesion entre otras.
Ayuda. Acceso a la ayuda online de SAP.

2.5. LA BARRA ESTANDAR
DE HERRAMIENTAS
2.5.
25
La barra est
andar de herramientas
La barra de herramientas estandar es de particular interes, ya que contiene

muchos de los botones necesarios para realizar las acciones mas comunes tales
como grabar, enter, imprimir, etc. . . Las funciones asignadas a la barra de
herramientas estandar son las siguientes.
Bot
on Enter
Se debera pulsar este boton para chequear los datos introducidos en una
pantalla. El boton enter realiza la misma funcion que pulsar la tecla enter
del teclado.
Campo de Comandos
Es un prompt de linea de comandos, y en el se pueden introducir

comandos tales como codigos de transacciones o men
us de ambito.
Bot
on Grabar
Se debera pulsar este boton cuando deseemos confirmar la grabacion de

los datos introducidos.
Bot
on Back
Se debera pulsar este boton si queremos regresar a la pantalla anterior

sin grabar los datos introducidos.
Bot
on Exit
AL SAPGUI
26
Se debera pulsar este boton si queremos salir de la actual aplicacion. El

sistema nos devuelve a la anterior aplicacion.
Bot
on Cancel
Se debera pulsar este boton si deseamos salir de la tarea actual sin grabar.
Bot
on Imprimir
Se debera pulsar este boton si deseamos imprimir los datos que

actualmente aparecen en pantalla. El boton de impresion estara activado
u
nicamente en pantallas donde se los datos aparezcan en formato de listado
y formato de tabla.
Bot
on Buscar
Se debera pulsar este boton si deseamos realizar una b

usqueda de una
cadena de caracteres en la pantalla actual. El boton de buscar estara activado
u
nicamente en pantallas donde los datos aparezcan en formato de listado y
formato de tabla.
Bot
on Buscar Siguiente
Se debera pulsar este boton si deseamos seguir buscando la cadena de

caracteres indicada en una b
usqueda anterior con el boton buscar. El boton
de buscar siguiente estara activado u
nicamente en pantallas donde los datos
aparezcan en formato de listado y formato de tabla.
Botones de Paginaci
on
2.6. LA BARRA DE APLICACIONES
27
Los botones de paginacion nos permiten colocarnos en las paginas

deseadas dentro de los listados que podamos obtener en pantalla. Los botones
de paginacion estaran activado u
nicamente en pantallas donde los datos
aparezcan en formato de listado y formato de tabla.
Disponemos de las opciones primera pagina, pagina arriba, pagina abajo
yu
ltima pagina:
2.6.
La barra de aplicaciones
Figura 2.3: Barra de aplicaciones

Con la visualizacion antigua del sapgui se encuentra entre la barra
estandar de herramientas y la parte principal de la pantalla. En ella
disponemos de las opciones basicas para el control de la aplicacion actual
(ejemplos de aplicaciones: visualizar pedido de compras, creacion de cliente,
.. ). En la nueva visualizacion del sapgui se encuentra entre la barra de ttulos
y la parte principal de la pantalla.
2.7.
La pantalla principal
Figura 2.4: Pantalla principal
AL SAPGUI
28
Es la parte principal de la aplicacion y dependiendo de esta podra estar

compuesta de campos de entrada y/ o salida, subpantallas, tabla, etc. . .
2.8.
La barra de estado
Figura 2.5: Barra de estado

Se encuentra en la parte inferior de la pantalla y su funcion principal es
la de mostrarnos los mensajes de Informaci

on, Advertencia, Error o Exito
que la aplicacion en curso nos muestre al navegar por ella. Como funciones
adicionales, la barra de estado nos muestra tambien:
El nombre de la base de datos SAP (de 3 caracteres) a la que estamos
conectados. Cuando se instala en el servidor el software del sistema SAP
R/3, este se comunica con el RDBMS - que debe haber sido previamente
instalado - para crear la base de datos que contendra todas las tablas
relacionales de las que se componen las distintas aplicaciones modulares
de SAP. El nombre de la base de datos se elige en tiempo de instalacion
y debe ser obligatoriamente de 3 caracteres de longitud
El n
umero de modo al que corresponde la pantalla actual.
El mandante al que estamos conectados.
El nombre del servidor a nivel de sistema operativo al que estamos
conectados.
El modo de escritura en el que estamos. Los valores posibles pueden
ser INS (modo insert) y OVR (modo overwrite). Cambiaremos de uno
a otro sin mas que pulsar la tecla Insert de nuestro teclado.
En la visualizacion antigua del sapgui aparece la hora que tiene
configurada el servidor de presentacion a nivel de sistema operativo.
Sin embargo, en la nueva visualizacion no aparece la hora del PC.
Esta hora no es la hora que tiene configurada el Sistema R/3 en el
servidor, sino que es dependiente de la configuracion de cada servidor
de presentacion.

2.9. VENTANA DE DIALOGO
2.9.
29
Ventana de di
alogo
Un elemento final de la ventana R/3 es la ventana de dialogo en la que el

sistema nos presenta una ventana flotante donde normalmente nos pedira la
introduccion de alg
un dato o la confirmacion o anulacion de alg
un mensaje
sin posibilidad de retornar o avanzar en la navegacion hasta que el usuario
introduzca la informacion pedida. Ver figura 2.6.
Figura 2.6: Ventana de dialogo
2.10.
Ayudas de b
usqueda
El sistema SAP R/3 dispone de una herramienta especfica para la

determinacion de valores posibles en un campo de entrada. Esta herramienta
se conoce con el nombre de Ayudas de B
usqueda a partir de la version 4.0B de
SAP R/3 (hasta esta version la herramienta era conocida como matchcodes).
Junto con este cambio de nombre se produce a su vez una mejora sustancial
de la herramienta.
Las ayudas de b
usqueda son muy u
tiles ya que en la mayora de los
casos en que deberemos introducir un dato en un campo no conoceremos los
valores posibles. Se encuentran activas en casi todos los campos de entrada
de cualquier pantalla de SAP R/3 y se identifican por aparecer a la derecha
del campo de entrada un peque
no recuadro con una flecha vertical apuntando
hacia abajo como podemos ver en la figura 2.7.
Esta flecha podra estar activa permanentemente o solo cuando posicionemos el cursor sobre dicho campo. Veamos esto con un ejemplo:
AL SAPGUI
30
Figura 2.7: Ayuda de b

usqueda
En una pantalla cualquiera del modulo de Gesti
on de Materiales(MM)
debemos introducir un valor en el concepto Material ; sin embargo no
conocemos que valores posibles puede tomar ese campo.
Para saber que posibles valores puede llegar a tomar el campo Material
haremos uso de la ayuda de b
usqueda asociada. Para ello pulsaremos su boton
de ayuda de b
usqueda o la tecla de funcion F4 estando posicionados en el
campo.
A continuacion nos aparecera un listado con los posibles valores como el de
la figura 2.8 que el concepto Material puede tomar. Cualquier valor distinto
de los presentados en el listado sera un valor no valido y el sistema mostrara el
consiguiente mensaje de error si un valor incorrecto es introducido.
2.11.
Modos
Los modos externos en un sistema R/3 son conexiones virtuales que un

usuario puede realizar a partir de una conexion real al sistema. A efectos de
servidor de presentacion esto se traduce en la creacion de una nueva pantalla
del SAPGUI con la que el usuario puede interactuar con el sistema R/3
independientemente de los anteriores modos externos. En lo que sigue nos
referiremos a los modos externos simplemente como modos.
Ejemplo: En un modo accedemos al M
odulo de Ventas para la visualizacion de un pedido y en otro accedemos a los datos maestros de un cliente.
A esta opcion accederemos desde cualquier pantalla de SAP R/3 por el
men
u desplegable Sistema Crear Modo. Es importante saber distinguir
entre conexion real (tambien llamada sesion) y modo. Existe una limitacion
: Solo se pueden abrir 6 modos por conexi
on real o sesi
on
Esta limitacion se aplica solo a los modos, no a las conexiones fsicas. Para
las conexiones fsicas la u
nica limitacion es la que imponga la disponibilidad
de recursos en el Servidor de Presentacion. Cada vez que creemos un nuevo
2.11. MODOS
31
Figura 2.8: Listado de valores posibles

modo no estamos realizando una nueva conexion real sino que estamos usando
la misma conexion para simular conexiones virtuales.
La opcion del men
u desplegable Sistema Salir del sistema nos
desconecta de la conexion real con la que estemos trabajando, con lo cual se
cerraran todas las ventanas de los modos que correspondan a esa conexion
real.
Veamos los comandos mas habituales para la gestion de modos. Estos
comandos se deberan introducir en el campo de comandos de la barra
estandar de herramientas:
Llamar una transaccion
en el mismo modo (ventana) Indicar: /nxxxx (xxxx = codigo
de transaccion)
en un modo adicional Indicar: /oxxxx (xxxx = codigo de
transaccion)
Finalizar la transaccion actual Indicar: /n.
Atencion: Las modificaciones hechas se perderan sin que el sistema
emita un mensaje de advertencia.
Borrar el modo actual Indicar: /i.
AL SAPGUI
32
Generar una lista con los modos propios activos Indicar: /o.
Salir del sistema Indicar: /nend.
2.12.
Concepto de transacci
on
Una transaccion comercial es un intercambio entre una parte del sistema

y otra. La planta de produccion, por ejemplo, quiere un suministro desde el
almacen a cambio de un albaran. El almacen sabra utilizar este albaran para
conciliar el saldo de esta pieza en el inventario de las mismas. Mientras tanto,
el departamento de contabilidad habra anotado que el material ha pasado
de la cuenta del almacen a la de la planta de produccion y definira una
transaccion financiera para registrar el intercambio de valor por el material.
Cuando un usuario esta trabajando en un terminal, una transaccion con
el sistema no queda terminada hasta que este verifica que las entradas
de informacion son correctas. El sistema registrara automaticamente la
transaccion como un documento que queda en el sistema en prueba de quien
hizo la transaccion y cuando esta ocurrio exactamente.
Llevando esta vision al sistema SAP veremos que una transaccion se
compone de una o varias dynpros por las que va pasando el usuario en las que
se le pide los datos referentes a la operacion que quiere llevar a cabo. Tras
completar toda la informacion obligatoria y parte de los campos opcionales,
el usuario tiene la opcion de grabar la transaccion o de desechar toda la
operacion. Este es el punto clave de una transaccion; si se graba, entonces
todos los datos quedaran registrados, si se cancela, entonces ning
un dato se
grabara. El concepto de transaccion implica que no pueden quedarse grabados
solo una parte de los datos, porque esto provocara una inconsistencia en
el sistema. En el ejemplo anterior, si solo se registrara el movimiento de
mercancas entre la planta y el almacen y no se grabara la anotacion contable
correspondiente, no podramos, en un momento dado, sacar un balance
contable correcto.
En R/3 accedemos a las transacciones generalmente a traves del
men
u, pero tambien podemos acceder directamente tecleando su codigo de
transaccion en el campo de comandos. Los usuarios noveles no suelen utilizar
este u
ltimo metodo descrito, pero a medida que se acostumbran al sistema y
se dan cuenta que suelen ejecutar siempre la misma decena de transacciones se
aprenden el codigo y lo utilizan. En la seccion 2.14 veremos como se averigua
el codigo de una transaccion que estamos ejecutando.

2.13. OPCIONES TECNICAS
2.13.
33
Opciones t
ecnicas
Las opciones tecnicas del SAPGUI se encuentran en el u

ltimo boton a
la derecha de la barra estandar de herramientas y se puede acceder a ellas
pulsando el icono de la figura 2.9 que se encuentra en la parte superior derecha
de la ventana del sapgui.
Figura 2.9: Icono de acceso a las opciones tecnicas
Al pinchar el boton nos aparece el men

u de la figura 2.10 que tiene las
siguientes opciones.
Figura 2.10: Menu del icono de acceso a opciones tecnicas
Opciones nos permite reconfigurar el aspecto de nuestro SAPGUI estableciendo nuevos colores, fuentes. Esta opcion solo es valida para el modo
de visualizacion antiguo.
Portapapeles es una herramienta similar al Portapapeles de Windows que
nos permite realizar selecciones de texto en cualquier pantalla del
SAPGUI y llevar esa seleccion a cualquier editor de texto ( bien sea
dentro del Sistema R/3 como fuera de el ).
AL SAPGUI
34
Generar Gr
afico es una herramienta que nos crea una pantalla similar a la
que estamos visualizando con la herramienta de graficos de SAP R/3.
Solo funciona con pantallas en las que tengamos alg
un tipo de listado.
Tama
no est
andar cambia la pantalla del SAPGUI a su tama
no por
defecto. Esta opcion solo funciona con resoluciones de pantalla
superiores a 800x600.
Hardcopy (duplicado de pantalla) enva la pantalla actual del SAPGUI
a la impresora que tengamos configurada por defecto en el PC. Esta
es una herramienta que esta todava en desarrollo por SAP y que
todava produce errores en la impresion de estas capturas debido a
incompatibilidades con ciertos drives de monitores.
Acerca de nos muestra los datos tecnicos de version del SAPGUI que
estamos utilizando.
2.14.
La pantalla status
Existe en SAP R/3 una ventana que nos informa sobre la conexion actual
que hemos realizado en el sistema, as como sobre los datos tecnicos referentes
al sistema operativo, el sistema de gestion de base de datos del servidor y la
version de SAP instalada.
A esta pantalla accederemos desde el men
u SistemaStatus, el cual
siempre se encuentra disponible desde cualquier punto de navegacion de SAP.
En ella podemos distinguir varias partes que describimos a continuacion:
Datos utilizaci
on En esta parte se presentan los datos relativos a la
conexion que el usuario ha realizado sobre SAP como el mandante,
nombre de usuario, idioma de conexion, fecha y hora del sistema,
as como la fecha y hora de la conexion anterior que realizo ese mismo
usuario sobre ese sistema.
Se debera tener en cuenta que la hora aqu presentada no tiene nada
que ver con la hora presentada en la barra de estado ya que la que
aparece en la ventana status se refiere a la hora actual del servidor y
la hora de la barra de estado se refiere a la hora actual del PC, que en
general no coincidiran.
Datos SAP Este area esta destinada a mostrar informacion tecnica sobre
SAP R/3 y se compone de varias subpartes. La parte de Datos
Repository se refiere a la transaccion y programas asociados a dicha
2.14. LA PANTALLA STATUS
35
Figura 2.11: Status del sistema

transaccion desde donde se ha ejecutado la ventana Status. De
particular importancia es el campo transaccion, ya que es uno de los
que mas se consulta. La parte Datos Sistema SAP nos dice que version
de R/3 esta instalada en el servidor, el codigo que SAP asigna a
nuestra instalacion, as como la fecha de vencimiento de la licencia.
La parte Release base nos informa de la version base que tenemos
instalada. Ademas de la version base podemos tener instalados algunos
parches. SAP, periodicamente, enva unos parches que arreglan errores
en sus objetos estandar y estos deben ser instalados a medida que
son proporcionados al cliente para corregir malos funcionamientos de
ciertas aplicaciones.
Datos m
aquina y base de datos En esta u
ltima parte se presentan datos
relativos al sistema como puede ser el tipo de sistema operativo
instalado, nombre de la maquina, codigo de pagina instalado y tipo
de base de da tos.
Captulo 3
Arquitectura de un sistema R/3
3.1.
Introducci
on
El sistema R/3 de SAP se basa en una arquitectura cliente/servidor de 3

capas: la capa de base de datos, capa de aplicacion y capa de presentacion.
La idea fundamental de la filosofa cliente/servidor es la distribucion de las
tareas que debe realizar el sistema. Cada capa se encarga de proveer ciertos
servicios:
Figura 3.1: Capas de la estructura cliente/servidor de R/3
37
CAPITULO 3. ARQUITECTURA DE UN SISTEMA R/3
38
1. Capa de base de datos . Servicios de base de datos para el salvado y

recuperacion de los datos empresariales.
2. Capa de aplicacion. Servicios de aplicacion para el manejo de la logica
de aplicacion.
3. Capa de Presentacion. Servicios de presentacion para la implementacion del GUI.
La arquitectura multicapa cliente/servidor le confiere al sistema R/3 las
siguientes caractersticas:
Escalabilidad Permite la adicion de nuevos equipos en cualquiera de sus 3
niveles para acomodarse a los requerimientos dinamicos del sistema.
Portabilidad El software normalmente continua en vigencia mas tiempo
que el hardware que lo soporta, es por ello por lo que el software SAP
R/3 se caracteriza por su portabilidad a traves de distintos tipos de
hardware, sistemas operativos y RDBMS.
Apertura Todos los datos estan almacenados en tablas que son accesibles
sin necesidad de instrucciones complejas de recuperacion de datos.
Parametrizabilidad SAP R/3 es un software estandar que dispone
de herramientas especficas para la adaptacion del software a las
necesidades de la empresa. Estas herramientas, englobadas en lo que se
conoce como el customizing, permiten amoldar los procesos de negocio
establecidos en el estandar a la manera de trabajar de cada empresa.
El Sistema R/3 sigue varios estandares reconocidos internacionalmente e
interfaces abiertos:
TCP/IP
RFC
Como protocolo de comunicaciones.

Como el interface de programacion de mas alto
nivel. Funciones de aplicacion pueden ser llamadas
externamente.
CPI-C
Para comunicaciones entre programas.
SQL y ODBC
Para acceso a los datos guardados en RDBs.
OLE/DDE y RFC Para la integracion de aplicaciones de PC.
X.400/X.500
Como el interface de email.
EDI
Para el intercambio de datos a nivel de aplicacion.
ALE
Para la integracion on line de aplicaciones descentralizadas.
3.2. SERVICIOS DE BASE DE DATOS
39
Debido a su arquitectura abierta no hay practicamente ninguna restriccion en la portabilidad como podemos comprobar por la figura 3.2
S.O. soportados
RDBMS soportados
G.U.I. soportados
UNIX, Windows NT, AS/400, OS/390

Informix, Oracle, ADABAS, DB2, SQL Server
Windows, OS/2 , OSF/Motif, Macintosh
Figura 3.2: Arquitectura abierta de R/3
3.2.
Servicios de base de datos
Acceso a base de datos relacional

Para el acceso y manipulacion de datos, R/3 usa exclusivamente comandos
del lenguaje SQL. Se dispone de 2 tipos diferentes de SQL: el Open SQL
(extension de lenguaje de programacion ABAP/4 ) y el Native SQL (SQL
nativo de sistema de base de datos que tengamos por debajo de nuestro SAP)
Optimizaci
on de las operaciones cliente/servidor
Se dispone de un cache de cliente consistente en bufferes especiales en cada
servidor de aplicacion situados en la memoria principal. Reduce el trafico de
red y los accesos a base de datos.
La optimizacion de los bufferes es asegurada por el mecanismo de
sobrescritura LRU (Least Recently Used) que consigue mantener en memoria
40
los datos mas frecuentemente usados.

Administraci
on base de datos SAP
SAP ha desarrollado una serie de herramientas para la administracion de
la base de datos; para el caso de ORACLE como RDBMS son:
BRBACKUP
Herramienta para los backups online y offline de los

datos de aplicacion y control, as como de los logs.
BRRESTORE Herramienta para la restauracion de los datos de
aplicacion y control, as como de los logs.
BRARCHIVE Herramienta para el archivado de los logs.
SAPDBA
Herramienta que integra todas las tareas de administracion de la base de datos.
3.3.
Servicios de aplicaci
on
La capa de de aplicacion estara, en el caso mas general, compuesto de

multiples instancias; por lo que estos servicios estaran distribuidos por todas
estas instancias. Una instancia R/3 consiste de un dispatcher y de uno o
varios procesos de trabajo para cada uno de los servicios que debe proveer,
ademas de un conjunto de bufferes en memoria compartida
Los servicios de la capa de aplicacion se pueden clasificar en:
Dialogo
Actualizacion
Gestion Bloqueos
Procesamiento Batch
Servidor Mensajes
Gateway
Spool
D
V
E
B
M
G
S
El nombre de la instancia contiene el nombre del sistema R/3 al

que pertenece, junto con los servicios que proporciona y el puerto de
comunicaciones:
Un sistema R/3 central con una unica instancia ofreciendo todos los
servicios tendra el nombre:
<SID>_DVEBMGS00_<TCP/IP Port>

3.3. SERVICIOS DE APLICACION
41
Servicios de di
alogo
Cuando un usuario esta conectado a un sistema R/3 y realiza cualquier
peticion de informacion al sistema (por ejemplo visualizar una factura), esta
peticion es gestionada por el sistema a traves de una cola de trabajo o
proceso llamado de dialogo. Estos procesos act
uan como interlocutores entre
el usuario final y la base de datos.
Servicios de actualizaci
on
El sistema esta provisto de unas colas de trabajo especiales llamadas
de actualizacion por donde gestionara las modificaciones de los datos de
aplicacion en la base de datos.
Servicio de gesti
on de bloqueos
Este servicio juega un papel muy importante y, como el anterior, solo
una instancia dentro de un mismo sistema puede proveer este servicio. Este
servicio es el encargado de impedir que un objeto en SAP sea modificado por
mas de un usuario a la vez. Este servicio es absolutamente necesario para la
integridad de los datos de aplicacion.
Se recomienda que estos dos u
ltimos servicios corran en la misma instancia
ya que interact
uan entre s.
Servicios de procesamiento batch
El sistema R/3 proporciona unos procesos llamados de batch especficos
para la realizacion de tareas, especialmente largas, que no requieran la
intervencion del usuario final. De esta forma se podran planificar tareas
pesadas como la carga o modificacion masiva de datos maestros sin que el
usuario tenga que estar presente para su ejecucion.
Servidor de mensajes
Dentro de la capa de aplicacion hay una instancia entre el resto que
provee el servicio de servidor de mensajes; este servicio es necesario para
la comunicacion de todas las instancias de un sistema R/3, y monitoriza
y asigna recursos libres. La instancia donde corre este servicio es llamada
instancia central.
Servicio de Gateway
42
Cada instancia necesita de este servicio para realizar tareas que se

extienden mas alla de la instancia local:
Servicio de Spool
Este servicio es el encargado de gestionar las peticiones de impresion dentro
de SAP R/3.
-
Comunicacion entre diferentes sistemas R/3

Llamadas a funciones remotas
CPIC (Common Programming Interface for Comunications)
Conexion de sistemas externos tales como MAPI Server, sistemas EDI. . .
Existe un servicio de gateway por instancia y se activa automaticamente

sin la intervencion del administrador cuando la instancia arranca.
Figura 3.3: Esquema del funcionamiento del dispatcher
Dispatcher y procesos de trabajo

Los servicios de dialogo, gestion de bloqueos, actualizacion, fondo y spool
son provistos por los procesos de trabajo, los cuales son coordinados por el

3.4. SERVICIOS DE PRESENTACION
43
dispatcher. El dispatcher act

ua de interface entre la capa de presentacion
y la de aplicacion ya que todas las peticiones que vienen del nivel de
presentacion son recibidas por el dispatcher y son asignadas a procesos de
trabajo libres de las instancias. Las peticiones de usuario, una vez asignadas
por el dispatcher a su correspondiente proceso de trabajo, accederan a la
base de datos directamente con SQL.
SAP R/3 funciona como un grupo de procesos de sistema trabajando en
cooperacion y en paralelo. En cada servidor de aplicaciones existe un u
nico
dispatcher y varios procesos de trabajo.
3.4.
Servicios de presentaci
on
Las aplicaciones de SAP R/3 han sido dise

nadas siguiendo unos
estandares que aseguran uniformidad, integracion y ergonomicidad. Esta
uniformidad se extiende a todas las partes del dise
no del interface. Algunas
de estas partes en las que observaremos la consistencia del interface son:
Ayuda online Permite acceder a la documentacion sobre el uso de las
aplicaciones R/3. Esta ayuda trabaja con referencias de hipertexto
permitiendo la navegacion.
Elementos de control Se dispone de campos de entrada para la introduccion de datos, campos de salida para la visualizacion de los mismos,
table control para la visualizacion de datos en formato de tabla, pushbuttons, casillas de seleccion y radio buttons. Se implementan barras de
desplazamiento cuando la informacion a visualizar en pantalla supera
el tama
no de esta.
Men
us Todas las funciones implementadas en las aplicaciones R/3 pueden
ser accedidas va menus desplegables. Estos men
us desplegables se
encuentran uniformemente estructurados a lo largo de todas las
aplicaciones del sistema R/3 siguiendo una estructura arborea. Se
permite, ademas la creacion de men
us propios de usuario.
Barras de tareas La barra de tareas contiene los smbolos de los comandos
de navegacion mas usados.
Barras de botones Las funciones esenciales para el control de una aplicacion pueden ser accedidas a traves de las barras de botones.
Valores de entrada posibles En casi todos los campos de entrada se
dispone de una funcion que nos permite visualizar los valores limitados
para la introduccion de valores.
Captulo 4
Escenarios de configuraci
on
Cualquier entorno de software de gestion empresarial presenta la
necesidad de tener sistemas completos (hardware y software) separados
dedicados a funciones especficas. Entre estas funciones podemos destacar
el desarrollo del software, las pruebas del mismo, la formacion a los usuarios
finales y, la mas importante de todas, la puesta en produccion del software.
SAP R/3 dispone de m
ultiples alternativas de configuracion de escenarios.
Cada empresa debera decidir, segun los criterios que veremos posteriormente,
cual es la que mejor se ajusta a sus necesidades. Esta decision, debido al
caracter abierto y escalable de R/3, puede alterarse en cualquier momento si
se aprecia que los condicionantes de la empresa que llevaron a optar por una
solucion determinada han cambiado.
4.1.
Consideraciones generales sobre los sistemas R/3
Siguiendo la definicion de sistema R/3 que se da en el glosario, vamos a

indicar una serie de requerimientos y limitaciones que existen, y que deben
tenerse en cuenta a la hora de decidir el numero de sistemas necesarios para
una implantacion real.
La base de datos de un sistema R/3 requiere aproximadamente unos
15 Gb1 de disco duro y cada servidor de aplicaciones necesitara unos
2 Gb. Un mandante que contenga u
nicamente la parametrizacion basica
ocupa unos 500 Mb, pero si le a
nadimos los datos de aplicacion que se
van creando al entrar en productivo, los requerimientos de almacenamiento
puede incrementarse hasta varios gigabytes. Otros factores que influyen en
1
En la version 4.0B
45

CAPITULO 4. ESCENARIOS DE CONFIGURACION
46
la necesidad de espacio son el sistema de base de datos elegido, el n

umero de
mandantes creados, la cantidad de datos historicos que se guardan. . .
R/3 no provee de ninguna herramienta para separar los datos maestros
de los datos transaccionales. No podemos transportar u
nicamente los datos
maestros de proveedores sin pasar tambien los datos de sus pedidos y/o
facturas. Del mismo modo, tampoco podemos separar los datos de modulos
diferentes, una aplicacion individual como FI o HR no puede aislarse para
transportarse a otros sistemas.
Por otro lado, s que disponemos de herramientas para reinicializar los
datos transaccionales antes de la entrada en productivo 2 lo que nos permite
borrar toda la contabilidad, pedidos, facturas, ordenes de mantenimiento,
etc, que se hayan creado durante las pruebas.
4.2.
Descripci
on y funciones de cada sistema
Atendiendo u
nicamente a la funcion que van a cumplir, hay varios tipos
de sistemas R/3. Vamos a describir los tres mas habituales (desarrollo,
integracion y produccion) aunque dependiendo del tama
no y necesidades
de la empresa SAP tambien contempla la posibilidad de tener un sistema de
formacion aislado y un sistema de desarrollo de cliente propio.
4.2.1.
Sistema de desarrollo
Este es el sistema inicial donde se origina el software. Todos los desarrollos

y la parametrizacion se llevan a cabo aqu. Una vez que se han completado las
pruebas unitarias de los programas, estos pueden ser transportados al sistema
de integracion para hacer pruebas mas exhaustivas. Los datos de este sistema
suelen ser escasos (
unicamente los que se van creando como pruebas) y a veces
son inconsistentes. Debido al gran n
umero de personas (muchas veces ajenas
a la empresa) que acceden a este sistema debemos controlar, por motivos de
seguridad, que nunca tenga datos reales.
4.2.2.
Sistema de integraci
on
En este sistema se realizan pruebas definitivas del software que incluyen:

Pruebas integradas Con ellas nos aseguramos que nuestros desarrollos no
interfieren en otros modulos del sistema. Tambien debemos probar
2
Go Livees el termino ingles que se utiliza para referirse al momento en que el sistema
productivo se abre a los usuarios finales para que comienzen a trabajar.
4.3. MANDANTES
47
conjuntamente desarrollos de distintos modulos que interact

uen entre
s.
Pruebas de rendimiento Cargando el sistema de integracion con suficiente volumen de datos podemos probar la eficiencia de nuestro software permitiendonos descubrir errores no funcionales pero que nos imposibilitan poner en explotacion los programas.
Pruebas de usuario El usuario final no suele tener acceso al sistema de
desarrollo as que es en integracion donde debe comprobar que la
funcionalidad del software es la que el pidio en sus especificaciones.
Tambien le sirve para familiarizarse con los nuevos programas y su
interface y solicitar cambios en la interaccion si algo no es de su agrado.
La formacion a usuarios es otra de las funciones de este sistema.
Aprovechando la necesidad de volumen de datos que tienen las pruebas de
rendimiento, podemos ense
nar a los usuarios con ejemplos casi reales como
funciona el software que van a tener que utilizar.
Por u
ltimo, destacaremos como funcion importante la posibilidad de
probar el sistema de transporte. Al pasar el software de desarrollo a
integracion ya tenemos una prueba de como va a pasar de integracion a
produccion. Veremos el sistema de transporte detalladamente en captulos
posteriores.
4.2.3.
Sistema de producci
on
El sistema de produccion tiene una u

nica funcion: la explotacion real del
software. Aqu es donde se almacenan los datos reales de la empresa y donde
se ejecutan los procesos de negocio. Los otros sistemas deben garantizar
que los programas o parametrizaciones incorrectas no afecten ni al trabajo
productivo ni a los datos reales.
4.3.
4.3.1.
Mandantes
Mandantes est
andar
Cualquier sistema R/3 se instala inicialmente con tres mandantes

estandar. En el caso de un sistema IDES existe tambien el mandante 800 que
incluye un modelo de compa
nia completo para demostraciones y formacion.
Las funciones de los mandantes estandar son las siguientes:
48
Mandante 000 Es el mandante de referencia. No contiene datos de

parametrizacion empresarial y por lo tanto las creaciones de mandante
propios se deben hacer como copias de este para asegurarnos que
empezamos la parametrizacion desde cero. Durante un cambio de
version de R/3 los datos dependientes de mandante se actualizan
automaticamente en el 000 y los cambios al resto de mandantes se deben
hacer desde aqu. En el IMG se incluyen unos proyectos que destacan
los cambios entre diferentes versiones de SAP R/3 y que sirven de ayuda
despues del upgrade. Este mandante no debe borrarse del sistema ni
cambiarse ning
un aspecto de el.
Mandante 001 Es el mandante de ejemplo. Inicialmente es identico al 000
y salvo que lo cambiemos nosotros, ninguna actualizacion de R/3 lo
va a modificar, al contrario de lo que ocurre con el 000. Siempre lo
podemos tener como ejemplo de la instalacion inicial aunque SAP no
impone ninguna prohibicion de cambiarlo o borrarlo.
Mandante 066 Mandante del servicio EarlyWatch. Para garantizar la
confidencialidad de nuestros datos reales en productivo existe este
mandante aislado al que se conecta SAP cuando le pedimos que nos
realice un servicio de deteccion de problemas de rendimiento. Los
usuarios de este mandante tiene las autorizaciones mnimas para poder
ejecutar el informe de rendimiento. Este mandante tampoco debe ser
borrado ni modificado nunca.
4.3.2.
Mandantes propios
A partir del mandante de referencia 000 podemos crear tantos mandantes

como queramos (siempre que el tama
no de nuestra base de datos nos lo
permita). En el sistema de desarrollo se suelen crear varios mandantes, en
integracion alguno menos y en el sistema de produccion solo debe existir
un mandante propio. A continuacion vamos a describir los mandantes que se
crean habitualmente y cuales son sus funciones. Aunque vemos que tienen un
n
umero asignado, esto se ha hecho para facilitar la diferenciacion entre ellos.
En nuestros sistemas R/3 nosotros podemos darle el n
umero que queramos
a cada mandante propio.
Es posible implementar SAP con mas o menos mandantes de los
indicados pero hay que buscar el equilibrio entre muchos y pocos. Con
pocos mandantes podemos tener conflictos durante la parametrizacion, el
desarrollo de programas o las pruebas, pero con muchos mandantes estaremos
aumentando el tama
no de la base de datos y empeorando el rendimiento
4.3. MANDANTES
49
ademas de requerir un mayor esfuerzo en los procedimiento de administracion

de sistemas. Las funciones de los mandantes propios son las siguientes:
Mandante 200 Desarrollo y parametrizacion en el sistema de desarrollo.
Aqu iniciamos nuestro prototipo de empresa y creamos los primeros
desarrollos a medida que sean necesarios. Los programadores y
consultores de aplicacion trabajan en este sistema. No tendremos datos
maestros ni transaccionales de manera que la pruebas las realizaremos
en el mandante 220 despues de pasar todos los cambios hechos aqu.
Mandante 210 Trastero.3 Las pruebas inusuales de parametrizacion las
realizaremos en el 210 de manera que no interrumpamos el trabajo
normal del mandante 200. Los cambios que hagamos aqu no se
registran en ningun sitio de manera que si probamos algo que nos va
bien debemos repetirlo a mano en el 200 para que quede grabado en una
orden de transporte y se pueda pasar al mandante de pruebas unitarias.
Periodicamente y para mantener el mandante limpio se hara una copia
de refresco desde el 220.
Mandante 220 Pruebas unitarias en desarrollo. Los responsables de
desarrollo y parametrizacion efectuaran aqu las pruebas unitarias
del prototipo que se esta creando. Aqu si que tendremos datos
maestros y transaccionales aunque no seran muy fiables debido a que
la parametrizacion puede cambiarse.
Mandante 300 Pruebas integradas y control de calidad en integracion. La
funcion de este mandante es similar a la del 220 pero con la diferencia
de que las pruebas incluyen la interaccion entre los diferentes modulos,
rendimiento y aprobacion del usuario. Tambien se comprueba que
el paso de las ordenes de transporte desde el sistema de desarrollo
sea correcto como garanta de que el paso de esas mismas ordenes a
produccion tambien lo sea.
Mandante 310 Formacion a usuarios finales. Una vez superadas las pruebas
correspondientes al mandante 300, pasamos el prototipo aqu para que
los usuarios finales reciban los cursos de formacion y tengan un sitio
donde poder seguir practicando despues. De esta manera, los datos
maestros y transaccionales que crean no nos interfieren en nuestro
trabajo de implantacion habitual.
3
El palabra que utiliza SAP es sandbox que es una caja de arena en la que juegan
los ni
nos. El termino ha sido libremente traducido al castellano por los autores.

50
Mandante 320 Maestro de parametrizacion. Este mandante se usa u

nicamente como referencia para poder consultar la parametricacion que tenemos en productivo sin tener que acceder a la maquina de productivo,
no obligandonos a dar acceso a la misma a personal no autorizado. Para
que cumpla su funcion se deben transportar los cambios al mandante
400 y al 320 al mismo tiempo y mantenerlos siempre sincronizados.
Mandante 400 Mandante productivo. Aqu es donde se lleva a cabo la
explotacion real del software. Este es el u
nico mandante propio que
debe existir en el sistema productivo. Antes del arranque en productivo
realizaremos aqu las cargas iniciales de datos maestros, movimientos e
historicos.
4.4.
Comparaci
on de escenarios
SAP tiene contemplados escenarios de configuracion desde un solo sistema

hasta cuatro. El escenario que aconseja en todas sus especificaciones tecnicas
es el de tres sistemas aunque tambien es aceptable trabajar con dos (si
las necesidades de la empresa no son muy grandes). Trabajar con un solo
sistema R/3 es un caso excepcional como veremos mas adelante. Vamos a ver
esquematicamente las ventajas y desventajas de cada una las configuraciones.
4.4.1.
Configuraci
on con un s
olo sistema (Producci
on)
Ventajas
Al tener una sola maquina los costes de hardware son mnimos.
Todo el trabajo del transporte de elementos de desarrollo queda
suprimido con lo que la administracion del sistema se simplifica en
cierto modo.
Desventajas
Tendremos problemas con las tablas independientes de mandante.
Problemas durante la instalacion y pruebas de los parches.
Tendremos dificultades para crear nuevos desarrollos y tendremos
que provocar la indisponibilidad del sistema para realizar las pruebas
integradas.
DE ESCENARIOS
4.4. COMPARACION
51
El rendimiento de nuestra u
nica maquina sera malo ya que tendremos
todos los mandantes en la misma base de datos con el aumento de
tama
no de las tablas que ello implica.
Conclusi
on
SAP desaconseja totalmente esta configuracion. Algunos clientes se
decantan por ella alegando que no van a desarrollar nada de software
nuevo y que tampoco van a parametrizar mucho con lo que un sistema
R/3 basico les sirve para empezar a trabajar. La realidad demuestra mas
tarde que hacer esto significa infrautilizar el potencial de adaptabilidad y
crecimiento que tiene SAP y en poco tiempo instalan un segundo sistema
que les permite hacer cosas que antes no podan. La reduccion inicial de
costes en hardware tambien resulta enga
nosa porque en el presupuesto de
un proyecto de implantacion de R/3 el coste del hardware representa un
porcentaje bastante peque
no del total. Lo que ocurre es que es uno de los
primeros gastos en el que hay que incurrir y por eso da la impresion de que es
importante reducirlo al mnimo. Unicamente

se aconseja esta configuracion
para centros de formacion o demostracion del producto.
4.4.2.
Configuraci
on con dos sistemas (Desarrollo y
Producci
on)
Ventajas
Todos los desarrollos nuevos y la parametrizacion creada se puede
probar en el sistema de desarrollo sin interferir con el trabajo real en
productivo.
Tenemos los datos reales de nuestro sistema productivo aislados en una
maquina a la que no puede acceder el personal de desarrollo, de esta
manera garantizamos la confidencialidad de nuestra informacion. Este
punto puede ser en algunos caso vital, estrategicamente hablando, o
incluso de obligado cumplimiento legal, en el caso de la informacion
relativa a empleados, clientes y proveedores.
La inversion en hardware es reducida. El sistema de desarrollo puede ser
una maquina de caractersticas inferiores a la de productivo y estaremos
ajustando bastante nuestro presupuesto.
Desventajas

52
La cantidad y el ambito de actuacion de los desarrollos que hagan

estara limitado por la falta de un sistema dedicado a las pruebas
integradas. Tendremos que hacer el control de calidad y las pruebas
de aceptacion de usuario en el mismo sistema en el que desarrollamos
lo que puede implicar la interrupcion de las tareas de desarrollo durante
el tiempo que duren las mismas.
Tampoco podremos llevar a cabo pruebas de rendimiento sin perjudicar
a los equipos de desarrollo o al funcionamiento en productivo.
Tareas ineludibles y de gran complejidad como un cambio de version
nos dejan inservible el sistema de desarrollo durante todo el tiempo que
dura la actualizacion de version.
Conclusi
on
Esta es la solucion mnima que acepta SAP para una empresa que pretenda
sacar rentabilidad de R/3. Es una opcion correcta para empresas con un
peque
no n
umero de desarrollos y que implanta solo uno o dos modulos lo que
reduce la cantidad de parametrizacion a realizar. A medida que la empresa
vaya instalando mas modulos de R/3 o que vaya asimilando el Workbench
ABAP/4 como paquete de desarrollo es posible que se vea en la necesidad de
a
nadir un tercer sistema. En cualquier caso, es muy com
un ver empresas que
tienen esta configuracion desde hace varios a
nos y funcionan correctamente
con ella. En el caso de un cambio de version, que es uno de los proyectos
complicados que requieren una maquina aparte, la solucion por la que se
opta consiste en alquilar durante el tiempo de la actualizacion de version una
maquina de pruebas o subcontratar la migracion a una consultora externa
que tenga maquinas disponibles para ello.
4.4.3.
Configuraci
on con tres sistemas (Desarrollo,
Integraci
on y Producci
on)
Ventajas
La instalacion de aplicaciones o modulos adicionales se puede hacer sin
afectar al trabajo habitual de desarrollo.
La existencia del mandante trastero en el sistema de desarrollo facilita
la familiarizacion con las funcionalidades de los modulos y la realizacion
de pruebas sin peligro.
DE ESCENARIOS
4.4. COMPARACION
53
Disponemos del sistema de integracion para la realizacion de pruebas de

rendimiento, pruebas de aceptacion de usuario, formacion a usuarios. . .
Tres es el n
umero mnimo de sistemas que hacen falta para poder
probar el sistema de transporte. Al tener integracion como paso
intermedio antes de llevar el software a productivo podemos y hacer
este paso utilizando el sistema de transporte, podemos garantizar que
el transporte a productivo va a ser correcto siempre que haya sido
correcto el paso a integracion. La importancia de esta prueba radica en
que puede resultar frustrante haber pasado todo el ciclo de pruebas de
un desarrollo y que al final falle en produccion por una mala gestion
del sistema de transporte.
Desventajas
Necesitamos una inversion mayor en hardware, tanto en maquinas
para albergar los sistemas R/3 como en hardware auxiliar de
comunicaciones, copias de respaldo, administracion de red. . .
La administracion del sistema se complica y por lo tanto necesitaremos
mas personal y que ademas este bien formado en estas tareas. Este
punto es realmente importante porque si no somos cuidadosos en la
gestion de los transportes de workbench y customizing a traves de los
tres sistemas podemos llegar a anular alguna de las ventajas que supone
tenerlos y convertirla en un claro inconveniente.
Conclusi
on
Como decamos al principio esta es la configuracion que recomienda SAP y
es la que utilizan la mayora de las empresas grandes que tienen presupuesto
y personal suficiente para gestionar todos los sistemas. Cuando se instalan
muchos modulos diferentes y de areas diferentes (logstica, finanzas y recursos
humanos) se hace necesario tener un sistema aislado para las pruebas
integradas. Un configuracion con cuatro sistemas solo sera necesaria para
empresas que tengan un vol
umen de desarrollos propios realmente grandes.
Como se puede suponer, la gestion de un sistema as requiere de personal
realmente cualificado y de una metodologa y procedimientos de transporte
que eviten cualquier error ajeno a los desarrollos en s mismos.
Captulo 5
Monitorizaci
on de procesos y
usuarios
Una de las tareas basicas de administracion de un sistema SAP R/3
consiste en la monitorizacion de los procesos activos en las instancias que
conforman el sistema ya sea en el entorno de desarrollo, integracion o
produccion -, as como que usuarios han ejecutado tales procesos.
Sera labor del administrador el evitar que se ejecuten procesos demasiado
pesados que provoquen una ralentizacion global del sistema, manteniendo
un contacto estrecho con el departamento de desarrollo y con los usuarios
finales para identificar tales procesos para que sean ejecutados en modo batch
durante el procesamiento nocturno.
5.1.
Monitorizaci
on de procesos activos
El sistema SAP R/3 dispone de un monitor de procesos activos por el

cual podemos ver que usuario ha lanzado que proceso. Ademas, este monitor
nos informa de que procesos han sido lanzados en dialogo y que procesos
corren en modo batch.
Este monitor puede ser accedido directamente por la transaccion
SM50 o alternativamente por el men
u desplegable HerramientasGestion
MonitorSupervisar SistemaResumen Procesos.
En la pantalla de la figura 5.1 podemos ver que usuario esta realizando
peticiones al sistema, as como el tipo de proceso de trabajo que esta gestionando tales peticiones. Explicaremos la informacion mas importante que nos
proporciona el monitor. En la columna ID tenemos un identificador secuencial para cada uno de los procesos de trabajo y la columna Tipo nos dice la
naturaleza del proceso de trabajo:
55
56
DE PROCESOS Y USUARIOS
CAPITULO 5. MONITORIZACION
Figura 5.1: Monitor de procesos de una instancia
DIA
BTC
UPD
UPD2
ENQ
SPO
para
para
para
para
para
para
procesos
procesos
procesos
procesos
procesos
procesos
de dialogo
batch
de actualizacion V1
de actualizacion V2
de Enqueue
de spool
La columna IDP es el identificador del proceso a nivel de sistema

operativo. Cada uno de los procesos en SAP es realmente un proceso activo
a nivel de sistema operativo. Este codigo u
nico para cada proceso de trabajo
sirve para identificarlos.
La columna Status nos indica el status de cada uno de los procesos de
trabajo. El status puede tomar cada uno de estos valores:
En ejec.
Proceso de trabajo que esta actualmente gestionando

peticiones de usuario.
Espera
Proceso actualmente en espera de gestionar peticiones
de usuario.
Finalizado Proceso que ha sufrido alg
un error en el procesamiento
de alguna peticion de usuario y cuya actividad ha
sido cancelada automaticamente por el sistema o por
el administrador del mismo. Los procesos con tales
status no pueden volver a gestionar ninguna peticion
de usuario hasta que el administrador los vuelva a
activar.
DE PROCESOS ACTIVOS
5.1. MONITORIZACION
57
La columna Inicio nos indica si el proceso de trabajo se reinicia cuando

sufre un error para poder seguir gestionando futuras peticiones de usuario
o si por el contrario, cuando una de las peticiones sufra un error el proceso
se quede en status finalizado con lo cual no se reactivara automaticamente.
El valor por defecto es S, y es el valor que deberemos dejar para que los
procesos esten siempre activos aunque sufran alg
un error en su ejecucion.
Errores tpicos en la ejecucion de peticiones de usuario son la terminacion
manual de alg
un modo por parte del usuario. Para cambiar este valor de
S a No o viceversa deberemos acudir a la opcion del men
u desplegable
ProcesoReanudar tras error.
La columna Error nos indica el n
umero de errores que un proceso de
trabajo ha sufrido desde que se arranco el sistema por u
ltima vez.
La columna Sem
aforo nos indica el n
umero de semaforo asociado a cada
proceso. Para ciertos tipos de actividades como pueda ser la escritura en un
fichero de log a nivel de sistema operativo, el sistema asigna unos codigos a
cada proceso de trabajo. El semaforo para escritura en fichero del sistema
operativo es 22.
La columna CPU es el tiempo de CPU que esta consumiendo actualmente
el proceso de trabajo en formato minutos:segundos. Esta informacion por
defecto no esta activa, ya que su propia visualizacion consume recursos del
sistema. Para activarlo deberemos acudir a la barra de aplicaciones y pulsar
el boton CPU.
La columna Hora nos indica el tiempo en segundos que ese proceso
esta activo.
La columna Report nos indica el programa que internamente esta ejecutando el sistema para gestionar la peticion de usuario. Todas las pantallas
de SAP tienen por detras un programa en codigo fuente que es compilado la
primera vez que es llamado; las siguientes veces el programa ya se encuentra
en el buffer, por lo que el sistema no lo volvera a compilar hasta que lo pierda
del buffer y sea nuevamente llamado.
La columna Mandante nos indica el mandante al que se ha conectado
el usuario que esta ejecutando ese proceso.
La columna Usuario nos indica el usuario que ha realizado la peticion al
sistema asociada a ese proceso de trabajo.
La columna Acci
on indica el tipo de accion que es llevada a cabo
sobre la base de datos para gestionar la peticion de ese usuario. Acciones
tpicas pueden ser: Lectura secuencial, lectura directa, insert, update, delete.
Para mas informacion sobre las acciones que ese proceso esta realizando
posicionaremos el cursor sobre el proceso deseado y a continuacion
58
pulsaremos el boton Detalle de la barra de aplicaciones.

La barra de aplicaciones nos permite tambien refrescar el contenido de
la pantalla. Deberemos tener en cuenta que el monitor de esta pantalla
se activara exclusivamente cuando pulsemos el boton refrescar, por lo que
si deseamos tener en pantalla y en todo momento informacion actualizada
sobre los procesos actualmente en curso deberemos pulsar continuamente el
boton de refresco. Otra opcion que nos brinda la barra de aplicaciones del
monitor de procesos activos es la de borrar el modo de usuario asociado al
proceso en cuestion. Esta opcion se debera usar con cuidado y siempre con
el consentimiento del usuario ya que podemos provocar perdida de datos si
cancelamos un modo que este actualmente accediendo a la base de datos
para actualizar. Otra posibilidad es la de debugging. SAP, en su entorno
de desarrollo, dispone de una herramienta de depuracion de programas; este
debugger puede ser activado para un proceso siempre que seamos el due
no de
tal proceso. Con esto se pueden analizar errores de programacion en tiempo
de ejecucion.
Los procesos actualmente activos en la instancia en la que estamos
conectados se pueden cancelar manualmente por el administrador del sistema
con la opcion del men
u desplegable ProcesoCancelar con core y Proceso
Cancelar sin core. Ambas opciones cancelan el proceso a nivel de sistema
operativo asociado al proceso de SAP con la salvedad que la opcion con
core genera un fichero llamado core donde queda registrada la razon de la
cancelacion del proceso. Como este fichero no es editable, elegiremos la opcion
sin core para no crear en los discos duros informacion que no vayamos a usar.
La cancelacion manual de un proceso debe ser realizada con extremo cuidado
y siempre deberemos asegurarnos que dicha cancelacion no provoque ning
un
problema de inconsistencia en los datos de SAP.
Es muy importante tener en cuenta que la informacion visualizada en la
transaccion SM50 se limita exclusivamente a la instancia a la que estemos
conectados. Si nuestro sistema R/3 esta formado por varias instancias, para
poder visualizar los procesos de cada una de ellas tendremos que conectarnos
directamente a cada una para visualizar la SM50 recordemos que el
nombre del servidor sobre el que esta montado la instancia aparece en todo
momento en la barra de estado o acudir directamente a la transaccion SM51
(Herramientas Gestion MonitorSupervisar SistemaServidor ).
En la transaccion SM51 visualizamos las instancias que estan activas y
que componen el sistema SAP. Desde esta transaccion podremos saber si un
sistema SAP es distribudo o si por el contrario esta formado por una u
nica
instancia central.
En la columna Servidor aparece el nombre de la instancia. En la columna
M
aquina aparace el nombre del servidor sobre el que esta instalada la
DE PROCESOS ACTIVOS
5.1. MONITORIZACION
59
Figura 5.2: Monitor de instancias activas
instancia SAP y por u

ltimo, en la columna Tipo se visualizan los tipos
de procesos de trabajo que estan dados de alta en esa instancia.
En la barra de aplicaciones de esa pantalla tenemos la opcion de refresco
para actualizar la informacion. Tambien tenemos la opcion Procesos que nos
lleva directamente a la transaccion SM50 de cada una de las instancias sin
mas que posicionar el cursor sobre la instancia deseada y pulsar el boton
descrito. Accedemos a la misma transaccion si hacemos doble click sobre
cada una de las instancias.
La opcion Usuarios nos muestra un listado con los usuarios conectados a
la instancia que hayamos elegido. Esta opcion la veremos mas a fondo en la
siguiente seccion. La opcion Log del sistema nos lleva a la transaccion SM21
que esta descrita en el captulo 8.
La opcion Colector SO nos muestra informacion tecnica acerca del sistema
operativo tal como el n
umero de procesadores, el porcentaje de utilizacion
CPU, la cantidad de memoria disponible y libre, e informacion sobre la
paginacion. Esta opcion se encuentra disponible en el men
u desplegable Pasar
a Collector SO.
La opcion Login remoto nos abre un modo sobre la instancia previamente
seleccionada. El modo nuevo nos accede al men
u inicial de conexion a SAP.
La opcion Info Release nos muestra informacion sobre la version del kernel
de SAP instalado en la instancia que hayamos elegido. El kernel de SAP
esta formado por ficheros ejecutables compilados en lenguaje C necesarios
60
Figura 5.3: Monitor de sistema operativo
para el arranque y funcionamiento de SAP.
5.2.
Monitorizaci
on usuarios conectados
Otra tarea basica de administracion que se complementa con la monitorizacion de procesos activos es la monitorizacion de usuarios conectados al
sistema. Existe en el sistema una herramienta que nos proporciona en formato listado los usuarios que se han conectado a la instancia actual. Tal
informacion es mostrada en la transaccion SM04 Herramientas Gestion
MonitorSupervisar Sistema Usuarios Conectados.
La pantalla de usuarios conectados nos da la siguiente informacion:
1. Mandante de conexion .
2. Nombre de usuario en SAP .
3. Nombre del servidor de presentacion desde donde se ha realizado la
conexion.
4. Codigo de transaccion perteneciente al modo actualmente activo .
5. Hora a la que se ejecuto por u
ltima vez alg
un proceso desde el modo
activo asociado a la conexion fsica que estamos visualizando.
6. Cantidad de modos abiertos por el usuario .
USUARIOS CONECTADOS
5.2. MONITORIZACION
61
Figura 5.4: Monitor de conexion de usuarios por instancia
7. Cantidad de modos internos que el sistema ha debido abrir para

gestionar las peticiones del usuario. Estos modos internos no tienen
nada que ver con los modos externos o de usuario denominados
simplemente modos que se explicaron en el captulo 2.
Cada lnea de este listado corresponde con una conexion fsica al sistema
por usuario. Este monitor tiene ademas diversas funciones en su barra de
aplicaciones:
Una de ellas es la posibilidad de ver los modos abiertos por cada usuario.
Posicionando el cursor sobre un usuario y pulsando el boton Modos, o
alternativamente, haciendo doble click sobre un usuario, el sistema nos
muestra una ventana de dialogo con un listado de los modos abiertos por
usuario y conexion fsica.
Esta ventana nos muestra en orden de apertura los modos abiertos por el
usuario y conexion fsica elegidos, as como la hora a la que se ha realizado
la u
ltima peticion de informacion por tales modos. Tambien tenemos la
opcion de borrar el modo que queramos. Con esta u
ltima opcion estaremos
cerrando remotamente al usuario la pantalla asociada a ese modo. Esta opcion
habra que usarla siempre con el consentimiento del usuario y con extremo
cuidado. Tal accion de borrado manual de modo queda reflejado en el log del
sistema ver captulo 8 .
62
Figura 5.5: Lista de modos activos por usuario
Otra opcion de la barra de aplicaciones es la de refresco de pantalla. Esta

opcion es muy u
til ya que el sistema solo nos estara mostrando la informacion
actualizada cada vez que pulsemos la funcion de refresco. Tambien podremos
ordenar el listado por la columna deseada tanto en orden ascendente como
descendente.
Como una tercera opcion de la barra de aplicaciones el sistema, si
pulsamos el boton Info Usuario, nos muestra en una ventana de dialogo el
nombre, apellido, departamento y extension telefonica asociados al usuario
elegido. Estos datos apareceran siempre y cuando se hayan introducido en el
maestro de usuarios cuando se creo el usuario.
Figura 5.6: Informacion detalllada de usuario
Sera labor del administrador, en general, el crear los usuarios en el maestro

de usuarios con los permisos adecuados para que puedan desarrollar sus tareas
sin problema y el mantener actualizados sus datos basicos como el nombre,
departamento, telefono de contacto para que la gestion y monitorizacion de
USUARIOS CONECTADOS
5.2. MONITORIZACION
63
tales usuarios resulte mas sencilla.

La limitacion de este monitor es que el listado se restringe a usuarios
que se han conectado al sistema por la instancia desde donde estamos
iniciando el monitor de usuarios. Si nuestro sistema se compone de una u
nica
instancia, este listado nos mostrara al completo todos los usuarios conectados
al sistema, pero si nuestro sistema se compone de varias instancias tenemos
varias opciones para visualizar todos los usuarios conectados:
Abrir una conexion fsica por cada instancia de las que se componga
nuestro sistema SAP e iniciar desde cada conexion la transaccion SM04.
En un u
nico modo acudir a la transaccion SM51 y desde ah y
posicionandonos en cada una de las instancias activas pulsaremos el
boton Usuario de la barra de aplicaciones. De esta manera tendremos
un listado de usuarios por cada instancia.
Desde la SM50 elegir la opcion del men
u deplegable Pasar aTerminales.
Nos aparecera un listado con todas las conexiones fsicas que han realizado los usuarios en todo el sistema. Este listado muestra el mandante,
usuario, terminal e instancia a la que se ha conectado el usuario.
Crear un programa o query sencilla sobre la tabla USR41 que contiene
en todo momento los usuarios conectados por cualquier instancia. Hay
que tener en cuenta que el resultado se nos restringe al mandante al
que estamos conectados. Si el sistema tiene mas de un mandante donde
esten definidos los usuarios, el listado no sera completo.
Captulo 6
Procesamiento en fondo
6.1.
Conceptos de procesamiento en fondo
Ademas de la opcion de ejecutar programas y transacciones online, SAP

nos da la posibilidad de ejecutar procesos en fondo.Podemos encontrarnos con
otros terminos para referirse al mismo concepto como procesamiento batch
o procesamiento en segundo plano. Simplemente consiste en la ejecucion de
un proceso sin interaccion con el usuario, es decir, que lanzamos el proceso y
el sapgui nos devuelve el control aunque el programa todava no ha acabado
de ejecutarse.
Este modo de ejecucion de procesos adquiere una importancia vital
cuando tratamos con programas que tardan mucho tiempo en completarse.
Tradicionalmente se considera un buen tiempo de respuesta para un sistema
online el hecho de que no transcurran mas de dos segundos entre dos acciones
del usuario sobre el programa. Parece poco probable que un usuario este
esperando mas de cinco minutos a la respuesta del sistema sin pensar que
se ha quedado bloqueado o que ha fallado el programa, por eso, cuando se
prevea que un proceso va a durar mas tiempo debera ser lanzado en fondo.
El lanzamiento de programas en fondo nos permite mejorar el rendimiento
de las transacciones online ya que podemos determinar que la prioridad
de los mismos sea menor ya que el usuario no esta esperando respuesta
inmediata. Lo mas aconsejable es lanzar los programas en fondo durante
la noche, cuando la carga de usuarios que act
uan online es casi nula. Esto
u
ltimo se debera hacer cuando los procesos no sean crticos para la obtencion
de datos en tiempo real; es la direccion de la empresa la que debe decidir, por
ejemplo, si sus pedidos de compra deben emitirse online o por el contrario
pueden esperar todos a la noche.
65
CAPITULO 6. PROCESAMIENTO EN FONDO
66
6.2.
Definici
on de jobs
Un job es conjunto de uno o mas programas que se lanzan consecutivamente en proceso de fondo. Para crear un job 1 utilizaremos la transaccion
SM36, a la que se llega a traves de Herramientas CCMS Jobs Definicion, y que nos muestra la pantalla de la figura 6.1
Figura 6.1: Pantalla inicial de definicion de job
La definicion de un job tiene tres areas principales:

Informacion general
Hora de inicio o evento de ejecucion
Pasos
6.2.1.
Informaci
on general
La informacion general conforma la base de la definicion del job.

Primeramente debemos darle un nombre que defina el proposito que tiene.
Este nombre no es u
nico, lo que significa que podemos crear varios jobs que
se llamen actualizar estad
sticas enero. Esto se produce porque SAP
asigna un n
umero interno a cada job con el que diferencia a unos de otros
pero para nosotros esa clave es desconocida y solo podremos referirnos al job
por su nombre.
1
SAP utiliza la palabra definir para la accion de crear un job
DE JOBS
6.2. DEFINICION
67
Otro datos de informacion general es la clase de job que indica a SAP la

prioridad de ejecucion de los procesos que le mandamos y en funcion de ello
asigna los recursos adecuadamente. La clases posibles son:
A La mas alta prioridad. Se utiliza para procesos que son crticos para el
funcionamiento del sistema.
B Prioridad media. Para procesos periodicos que aseguran el mantenimiento
del sistema.
C Prioridad normal. Es la clase normal que se asigna a los jobs de usuario.
El administrador del sistema puede decidir reservar colas de BTC
especficas para los jobs de clase A de manera que nunca tenga que esperar
un proceso de este tipo a que haya recursos libres para su ejecucion.
Por u
ltimo, tenemos la posibilidad de determinar especficamente el
servidor de aplicaciones que dara curso a nuestra peticion de proceso de
fondo. Si no indicamos ninguna instancia por la que deba ejecutarse entonces
el sistema elegira la primera disponible.
6.2.2.
Hora de inicio o evento
Una vez definidas la caractersticas generales del job tenemos que indicar
cuando debe ejecutarse. Esta indicacion puede hacerse de diversas formas:
Ejecucion inmediata. Como su propio nombre indica nos permite iniciar
el job en el momento de acabar su definicion.
Ejecucion por fecha/hora. Deberemos indicarle un da y una hora en
la que queramos que comience el job. Ademas podemos marcar el job
como periodico, es decir, que se repetira su ejecucion cada cierto periodo
de tiempo (cada da, cada 35 minutos. . . ). Esta opcion es muy u
til
para la planificacion de jobs de mantenimiento o de recoleccion de
estadsticas, de hecho, al instalar SAP ya existen una serie de jobs
de estas caractersticas.
Por job. Con esta indicacion de comienzo podemos encadenar unos
jobs con otros, es decir, indicaremos al job B que empiece a ejecutarse
cuando acabe el job A. Tambien podemos especificar que solo comience
cuando la finalizacion del job A sea correcta, en caso de que el job A
haya sido cancelado en mitad de su ejecucion el job B no se ejecutara.
Por evento. El job comenzara cuando se produzca en el sistema el evento
que le indiquemos.
68
Un evento es un suceso se produce automaticamente en el sistema R/3

o que podemos provocar manualmente. Previamente, el evento debe estar
definido en la correspondiente tabla. SAP viene con una serie de eventos
predefinidos como pueden ser, el arranque o parada de las instancias, el
cambio de modo de operacion de nocturno a diurno, etc. El administrador o
los desarrolladores pueden crear otros eventos a conveniencia. Estos pueden
dispararse desde programas en ejecucion o podemos lanzarlos manualmente
a traves del men
u Herramientas CCMS Jobs Lanzar evento.
6.2.3.
Pasos
Tras definir como y cuando queremos que se procese el job, por u

ltimo,
vamos a decirle que es lo que queremos que haga. Los pasos de un job
los componen los diferentes programas que queremos que se ejecuten. Estos
programas pueden ser de tres tipos:
Un programa ABAP estandar o creado por nosotros al que le
indicaremos una variante que contenga los parametros de seleccion de
ese programa.
Un comando externo que se ejecutara en el sistema operativo donde
este el servidor de aplicaciones que procesa el job. Este tipo de pasos
son dependientes del sistema operativo, no sirven los mismos comandos
para Unix que para Windows NT. Un ejemplo clasico es la ordenacion
de un fichero que ha creado un programa en un paso previo y que lo
necesita otro programa de un paso posterior.
Un programa externo que reside en otro sistema distinto a R/3. Se
utiliza cuando tenemos otros sistemas de gestion distintos a SAP y
necesitamos tener interfases entre ellos.
Los pasos de un job constituyen un proceso unificado, esto implica que si
el primero de un job de tres pasos sufre un cancelacion, ninguno de los otros
dos pasos restantes se procesara. Es como si crearamos tres jobs encadenados
con dependencia de status con un paso cada uno.
6.3.
An
alisis de jobs
Una vez definido completamente el job podemos analizar y monitorizar

su situacion a traves de la transaccion SM37 o por el men
u Herramientas
CCMS Jobs Actualizacion que nos muestra la pantalla de la figura 6.2.

6.3. ANALISIS
DE JOBS
69
Figura 6.2: Pantalla inicial de seleccion de jobs
Inicialmente tendremos que introducir los criterios de seleccion de los jobs

que queremos analizar porque pueden existir cientos de jobs definidos en un
momento dado y nosotros estaremos interesados en unos pocos. La seleccion
se hace principalmente por nombre del job, usuario creador del job, fecha y
hora de comienzo y estado actual en el que se encuentra. Una vez introducidos
los datos y tras pulsar enter veremos la pantalla de la figura 6.3. En ella vemos
un listado de los jobs con diversos datos sobre el. La informacion que mas nos
interesa es el estado en el que se encuentra, en la siguiente seccion hablamos
de los diferentes estados de un job.
6.3.1.
Estados de un job
Una vez definido un job lo que nos interesa conocer en todo momento
su estado. Los posibles estados en los que se puede encontrar un job son los
siguientes:
Previsto Es el estado inicial en el que se encuentra cuando hemos definido
los datos generales y los pasos del job pero no hemos dicho nada acerca
de cuando debe ejecutarse. La eleccion del nombre no es muy acorde a
su significado real porque un job que esta previsto no se ejecutara nunca
a menos que lo liberemos o modifiquemos la seccion de datos de inicio.
Liberado Cuando definimos completamente un job con la transaccion SM36
o liberamos un job que estaba en estado previsto, entonces pasa a
70
liberado. En este estado permanecera hasta que se cumpla la condicion

de su fecha de inicio o se produzca el evento que lo lanza.
Listo Una vez se han cumplido las condiciones de inicio del job pasa al
estado listo en el que estara esperando a que haya recursos libres en el
sistema para ejecutarse. Normalmente no veremos jobs en este estado
a menos que tengamos el sistema tan cargado que no haya suficientes
colas de batch para atender a todos los jobs que estan en estado listo.
Activo El job se esta procesando. Podemos ver el log desde este momento
y ver lo que esta haciendo.
Finalizado El job completo su ejecucion correctamente.
Cancelado Alg
un problema hizo que el job finalizara de manera incorrecta.
Normalmente se producen cancelacion por errores de los programas que
componen el job o problemas de acceso a la base de datos. En el log
del job podemos ver el motivo de la cancelacion.
6.3.2.
Operaciones sobre jobs
El listado de la figura 6.3 es en realidad un completo centro de control

de los procesos en fondo. Si pulsamos en el men
u Job veremos todas las
operaciones posibles que podemos hacer para alterar el estado o composicion
de un job.
Figura 6.3: Resumen de jobs seleccionados

6.3. ANALISIS
DE JOBS
71
Vamos a describir alguna de las operaciones que podemos realizar sobre

los procesos en fondo:
Verificar status En alguna ocasiones podemos descubrir que un job que
creemos que esta activo porque la transaccion SM37 as nos lo
dice realmente no lo esta. Esto puede suceder cuando el proceso
del sistema operativo correspondiente a la cola BTC por donde va el
job es cancelado o el servidor de aplicaciones tiene alg
un problema
de rendimiento. Con esta opcion forzamos a SAP a comprobar que el
estado que nos da para el job es realmente el que tiene en el sistema
operativo. Cuando comprueba la actividad de un job que vemos como
activo y no recibe respuesta del sistema operativo nos dira que el
proceso ya no esta en activo y nos pregunta si queremos pasarlo a
estado cancelado.
Cancelar job activo Con esta opcion detenemos un job activo y lo
pasamos directamente a estado cancelado. Si tuviera un job encadenado
a continuacion este no se procesara.
Borrar . Una vez terminado o cancelado un job podemos borrarlo
manualmente de la lista con este punto del men
u.
LiberadoPrevisto Para poder deshacer la liberacion de un job utilizaremos esta opcion. Es muy u
til para no tener que borrar y redefinir un
job que hemos liberado a una hora concreta y despues nos hemos dado
cuenta de que no queremos lanzarlo a
un.
Copiar Si queremos que un job se ejecute dos o tres veces lo copiaremos con
esta opcion y liberaremos cada una de las copias convenientemente. Si
queremos que se ejecute mas veces deberamos pensar en la posibilidad
de crear un job periodico.
Modificar Siempre y cuando no haya comenzado la ejecucion del job
(mientras este en previsto o liberado) podremos modificar cualquier
dato de la definicion del mismo.
Repetir previsi
on Esta opcion es muy similar a la de copiar pero ademas
nos pide los datos de inicio del job, es decir, es como si copiamos un
job y liberamos inmediatamente la copia.
Traslado a otro servidor Con esta opcion cambiamos el servidor de
destino de un job que no este activo.
72
Capturar job activo Para comprobar en que punto va la ejecucion del

proceso que hemos lanzado podemos capturar un job que este activo.
Al pulsar este opcion se nos abre un modo nuevo con el depurador
(debugger ) de ABAP/4 parado en el punto del programa que estuviera
en ese momento. Solo tiene hacer esto sentido si conocemos y
entendemos el codigo fuente del programa que se procesa. Ademas hay
que ser cauteloso con esta opcion ya que hay determinadas fases de un
programa ABAP en las que el hecho de activarse el debugger provoca
una cancelacion con dump debido a un commit work implcito en la
base de datos.
Detalles de job Aqu podemos ver datos internos del job. El mas interesante es comprobar en que servidor de aplicaciones se esta procesando y en n
umero de cola BTC para poder monitorizar su estado y/o
rendimiento con la transaccion SM51.
Captulo 7
Servicios de actualizaci
on
El servicio de actualizacion en SAP R/3 es especialmente importante ya
que es el encargado de gestionar las modificaciones solicitadas por los usuarios
en las base de datos. Dichas actualizaciones se pueden generar a traves de
procesos de trabajo tipo dialogo, batch o update.
7.1.
Actualizaci
on sncrona y asncrona
La actualizacion en la base de datos de un sistema R/3 es mayoritariamente asncrona, es decir, el sistema gestiona la peticion de actualizacion del
usuario en un proceso aparte del proceso de dialogo del usuario. El efecto de
este tipo de actualizaciones es que el usuario se desentiende totalmente del
proceso de actualizacion, ya que no debe esperar a que el sistema acceda a
actualizar a la base de datos para poder seguir trabajando. Esto se traduce en
una mejora del rendimiento; el proceso de dialogo del usuario no espera a que
se terminen las actualizaciones para seguir procesando las peticiones de ese
usuario. La actualizacion asncrona no se realiza directamente en los procesos
de dialogo, sino que se gestionan en procesos de actualizacion especficos.
En la figura 7.1 se muestra en forma esquematica como las actualizaciones
asncronas pertenecientes a un proceso de trabajo a un usuario son lanzadas
en paralelo.
La actualizacion sncrona, aunque es menos frecuente, tambien se produce
en un sistema R/3, y se diferencia de la asncrona en que la peticion
de actualizacion en la base de datos se genera en el mismo proceso de
trabajo que gestiona el resto de peticiones del usuario dialogo si el usuario
esta trabajando en online o batch si el usuario ha dejado programado un job
. De esta forma el proceso de dialogo o batch debe esperar a que se realicen
las actualizaciones en la base de datos antes de seguir procesando el resto de
73
74
CAPITULO 7. SERVICIOS DE ACTUALIZACION
Figura 7.1: Esquema funcionamiento actualizacion asncrona
peticiones del usuario, por lo que el rendimiento sera peor que en el caso de
la actualizacion asncrona.
En la figura 7.2 se muestra en forma esquematica como las actualizaciones
sncronas pertenecientes a un proceso de trabajo asociado a un usuario
son lanzadas en el mismo proceso, obligando al proceso a esperar a que la
actualizacion termine para poder continuar.
Figura 7.2: Esquema funcionamiento actualizacion sncrona
Los usuarios no pueden elegir si los cambios en la base de datos se realizan
V1 Y V2
7.2. PROCESOS DE ACTUALIZACION
75
de forma sncrona o asncrona, ya que esto depende de la programacion de la

aplicacion en curso. Si se trata de actualizaciones dentro de alguna aplicacion
hecha a medida sera tarea del analista de la aplicacion el decidir que tipo
de actualizacion realizar. En lo que sigue nos ce
niremos a la actualizacion
asncrona, que a la postre es la que juega un papel mas importante en un
sistema SAP R/3.
7.2.
Procesos de actualizaci
on V1 y V2
La actualizacion asncrona presenta ademas una ventaja adicional:

implementa las LUW 1 . Las LUWs consisten en bloques autoconsistentes de
datos, de tal forma que su actualizacion en la base de datos es llevada a cabo
completamente. Si surgiera alg
un problema en la base de datos la grabacion
de cada LUW no se realizara, de esta manera se evitan las inconsistencias
que pudieran surgir al grabar una LUW a medias.
La actualizacion asncrona, consiste de 2 tipos de actualizacion : V1 y
V2. El sistema R/3 distingue entre componentes de actualizacion crtica
primaria (V1) y secundaria no crtica (V2). La diferenciacion entre estos
dos tipos de actualizacion permite que el sistema procese los cambios crticos
en la base de datos por delante de los cambios menos crticos asignandoles
diferentes LUWs; esto es necesario ya que las componentes V1 deben ser
realizadas cuanto antes. Para asegurar la consistencia de los datos, las
actualizaciones V1 se procesan con la supervision del gestor de bloqueos
de SAP R/3 que impide que varias modificaciones sobre el mismo objeto se
realicen concurrentemente.
Las componentes de actualizacion V1 y V2 se procesan por distintos
procesos de trabajo, siempre que en el sistema existan procesos de
actualizacion UPD y UP2: Las componentes V1 se gestionan por las colas
de trabajo UPD y los componentes V2 se gestionan por las colas de trabajo
UP2. Si no existen este tipo de procesos de trabajo, las componentes V2 se
gestionan tambien por las colas UPD.
7.3.
Monitorizaci
on del estado de la actualizaci
on del sistema
El sistema SAP R/3 dispone de una herramienta para la activacion y desactivacion generica de los servicios de actualizacion, as como para la mon1
Logical units of work o unidades l

ogicas de trabajo
76
itorizacion de las actualizaciones en curso y de las posibles actualizaciones

interrumpidas que puedan haber ocurrido.
El sistema SAP R/3, ante un problema grave en la base de datos como
pueda ser el llenado de alg
un tablespace a nivel del RDBMS reacciona
desactivando la actualizacion con lo cual todas las modificaciones a realizar en
la base de datos se quedan en un estado de espera hasta que la actualizacion
vuelva a estar activa. Esta desactivacion automatica tiene lugar en aras de
preservar la integridad de la base de datos y su ejecucion queda registrada en
el log del sistema (ver Captulo 8). Sera tarea del administrador el subsanar
el error que produjo la desactivacion de la actualizacion del sistema y su
posterior activacion. La actualizacion es activada automaticamente cada vez
que el sistema SAP R/3 es arrancado en el servidor, por lo que solo se
debera monitorizar su posible desactivacion.
La transaccion desde donde podremos gestionar centralmente la actualizacion es la SM13, o alternativamente por el men
u deplegable Herramientas
Gestion Monitor Actualizacion.
Figura 7.3: Pantalla principal monitor actualizacion
En ella, basicamente, se nos muestra si la actualizacion del sistema

esta activa o ha sido desactivada por alguna causa. Si la actualizacion ha
sido desactivada, el boton Info nos proporciona que proceso y usuario han
causado su desactivacion. El resto de campos son campos de seleccion para
monitorizar las actualizaciones que han tenido lugar y han fallado o las que
estan en curso. Como campos de seleccion tenemos:
7.4. ACTUALIZACIONES INTERRUMPIDAS
77
Mandante
Por defecto aparece el mandante al que nos hemos

conectado.
Usuario
Por defecto aparece el codigo de usuario con que nos
hemos conectado al sistema.
Status
Podremos elegir las actualizaciones que se han cancelado, las que todava no se han ejecutado, las que
tienen la parte V1 ejecutada, las que tienen la parte
V2 ejecutada o todas las actualizaciones con los 3 status anteriores.
Fecha y hora Podremos elegir una fecha y hora mnima a partir de
la cual mostrar los datos.
Ctdad. Reg. Podremos elegir la cantidad de actualizaciones a
visualizar .
Servidor
Podremos elegir las actualizaciones que se han realizado desde un servidor de aplicaciones determinado.
Se dispone, desde esta transaccion, de la posibilidad de activar como
de desactivar la actualizacion del sistema. El administrador puede, en caso
necesario, desactivar la actualizacion para evitar una situacion crtica si se ha
detectado alg
un problema grave en la base de datos. Esta opcion se encuentra
en la transaccion SM13, en el men
u desplegable Regs. Actualizacion
Actualizacion Desactivar (existe a este nivel tambien la opcion activar).
7.4.
Actualizaciones interrumpidas
Las actualizaciones en la base de datos se pueden ver interrumpidas por

dos tipos de problemas:
1. Problemas globales que afectan a toda la base de datos, como pueda ser
el llenado de un tablespace en un sistema R/3 sobre un RDBMS como
ORACLE o DB2 (en sistemas sobre SQL Server el concepto analogo al
tablespace es el device).
2. Problemas locales que afectan exclusivamente a ciertas aplicaciones
dentro del sistema SAP R/3 y que pueden venir causados por errores de
programacion o por la cancelacion abrupta del proceso de actualizacion
desde el servidor de presentacion debido a una cada del fludo electrico
o a una interrupcion deliberada del sistema por parte del usuario.
Las actualizaciones interrumpidas por este tipo de problemas las
debera supervisar el equipo de desarrollo de la aplicacion en cuestion,
78

y a la postre deberan ser ellos quienes decidan que hacer con estas
actualizaciones.
Un registro de actualizacion puede tener uno de los siguientes 6 estados:
1. Init. El registro no ha sido procesado todava.

2. Auto. El registro sera automaticamente actualizado cuando la actualizacion del sistema se active.
3. Run. El registro de actualizacion esta siendo procesado .
4. V1. La parte V1 ha sido completada.
5. V2. La parte V2 ha sido completada. Cuando esta parte se completa el
registro desaparece (es la configuracion por defecto) por lo que sera muy
dificil visualizar un registro en este status.
6. Err. Un error causo la interrupcion de la actualizacion del registro.
Para visualizar los registros de actualizacion interrumpidas acudiremos
a la transaccion SM13 y elegiremos el status C
ancelado en la pantalla de
seleccion. A continuacion pulsamos ejecutar y el sistema nos mostrara en un
listado las actualizaciones interrumpidas como el de la figura 7.4
Figura 7.4: Actualizaciones pendientes
En este listado nos aparece el mandante y usuario que han lanzado el

registro de actualizacion, as como la fecha y hora y transaccion desde donde
se ha realizado la actualizacion. Como u
ltimo campo tenemos el estado actual
del registro de actualizacion.
7.4. ACTUALIZACIONES INTERRUMPIDAS
79
Si queremos disponer de mas informacion acerca de los distintos modulos

que componen el registro de actualizacion podremos hacer doble click sobre
el o posicionar el cursor en la lnea deseada y a continuacion pulsar el boton
de M
odulos de Actualizacion en la barra de aplicaciones. A continuacion se
nos mostrara una pantalla similar a la de la figura 7.5.
Figura 7.5: Modulos de actualizacion
En esta pantalla se nos divide el registro de actualizacion en varios

modulos y se nos especifica si pertenecen a la parte V1 o V2. Conjuntamente
con el departamento de desarrollo y los usuarios finales se debera decidir
que hacer con los registros de actualizacion interrumpidos. Estos registros
pueden ser:
Contabilizados Esta opcion es para procesar registros de actualizacion
que se encuentren en status init. Para ejecutar esta opcion deberemos
posicionar el cursor sobre el registro deseado y elegir la opcion Regs.
Actualizacion Contabilizar Uno por uno (existe tambien la opcion
de contabilizar todos los registros visualizados).
Grabados posteriormente Opcion para registros cuya parte V1 haya
sido realizada y quede por hacer la parte V2. Con esta opcion
se contin
ua con la grabacion. Esta opcion se encuentra en Regs.
Actualizacion Grabar Posteriormente Uno por uno (existe
tambien la opcion de grabar posteriormente todos los registros
visualizados).
Reiniciados En casos aislados, un registro de actualizacion se puede
quedar indefinidamente es estatus Run aunque realmente no se
esta procesando. La opcion Reiniciar en Regs. Actualizacion

80
Reinicializar Status orden actualizacion Uno por uno (existe

tambien la opcion de reiniciar todos los registros visualizados) deja
el registro preparado para ser procesado de nuevo.
Borrados Opcion para eliminar los registros de actualizacion. Esta opcion
se encuentra en Regs. Actualizacion Borrar Uno por uno (existe
tambien la opcion de borrar todos los registros visualizados). Cuando
ninguna de las opciones anteriores funciona, como pueda ser para el caso
de actualizaciones que provengan de procesos batch, esta es la u
nica
posibilidad que resta. El borrado sera el paso previo a la repeticion
del proceso de actualizacion del objeto en cuestion alta de material,
alta de apunte contable, modificacion de pedido desde la aplicacion
correspondiente.
7.5.
Entradas de bloqueo
SAP R/3 dispone de un sistema de gestion de bloqueos de objetos para

evitar la modificacion concurrente de un objeto. Con esto, se asegura la
consistencia de los objetos en SAP R/3.
Cuando un usuario accede a modificar un objeto, el sistema genera un
registro de bloqueo con la informacion necesaria. Si un segundo usuario
intenta modificar ese mismo objeto mientras el 1er usuario lo tiene bloqueado,
el sistema le muestra al segundo usuario un mensaje de error indicandole que
un usuario ya esta tratando el objeto solicitado. Los bloqueos se establecen
al iniciar las transacciones de modificacion y no son liberados hasta que el
usuario pulsa Grabar, la informacion es actualizada en la base de datos y
la transaccion es finalizada.
Toda modificacion de un objeto desde cualquier aplicacion estandar
dentro de SAP R/3 genera entradas de bloqueo. Sera tarea del departamento
de desarrollo asegurar que las nuevas aplicaciones hechas a medida dentro de
SAP R/3 generen tales bloqueos cuando desde estas nuevas aplicaciones se
acceda a modificar alg
un objeto.
La transaccion que nos muestra los bloqueos actualmente activos en
el sistema es la SM12 y se puede acceder a ella por el siguiente men
u:
Herramientas Gestion Monitor Entradas de bloqueo.
En esta pantalla disponemos de unos parametros de seleccion para filtrar
los bloqueos actualmente activos. Los parametros son tabla, argumento de
bloqueo, mandante y usuario. En general no conoceremos el argumento de
bloqueo, ya que esa informacion depende del objeto que se este modificando.
Es mas normal conocer la tabla o usuario que esta produciendo un bloqueo.
7.5. ENTRADAS DE BLOQUEO
81
Figura 7.6: Pantalla principal entradas de bloqueo
Por defecto, el campo mandante y usuario estan rellenos con los valores por
defecto.
Una vez rellenos los parametros de seleccion con los valores deseados
pulsamos el boton Enter en la barra de aplicaciones y nos aparecera un
listado con las entradas de bloqueo que cumplen la seleccion realizada.
Figura 7.7: Listado de bloqueos activos en el sistema
El listado esta compuesto por los campos mandante, usuario, hora a la que
se ha producido el bloqueo, tabla a la que pertenece el registro bloqueado, y
argumento de bloqueo que en general correspondera con el codigo del objeto
que se este modificando. En la barra de aplicaciones disponemos de tres
opciones: Detalles, Borrado y Refrescar.
La opcion Detalles, a la que tambien se puede acceder haciendo doble
click sobre el registro deseado, nos muestra informacion adicional sobre la
entrada de bloqueo tal como la transaccion desde donde se ha producido el

82
bloqueo.
Figura 7.8: Informacion detallada de un bloqueo
En raras ocasiones puede llegar a ocurrir que el bloqueo generado por una
modificacion no se llegue a liberar, lo cual provoca que el resto de usuarios
no pueda acceder a modificar esos objetos debido al bloqueo. Existen dos
causas principales de bloqueos no liberados:
Actualizaciones interrumpidas Cuando un registro de actualizacion
queda interrumpido, su entrada de bloqueo correspondiente no es
liberada hasta que el registro de actualizacion en cuestion sea procesado
correctamente o borrado.
Estas entradas de bloqueo no se deberan borrar bajo ning
un concepto
ya que se podran causar inconsistencias en la base de datos. Estas
7.5. ENTRADAS DE BLOQUEO
83
entradas de bloqueo se liberaran automaticamente cuando el registro

de actualizacion interrumpida sea tratado.
Terminaci
on anormal de la conexi
on de usuario Si un usuario apaga
abruptamente su PC sin haberse desconectado previamente, el modo
de usuario puede quedar activo en el sistema, con lo cual los bloqueos
activados por el usuario no son liberados. Se deberan borrar los modos
que el usuario tenga activos en el sistema para eliminar las entradas de
bloqueo; si con ello no desaparecen, y estamos seguros que la entrada
de bloqueo no procede de una actualizacion interrumpida, podremos
borrar la entrada desde el listado de la transaccion SM12.
Captulo 8
Log del sistema y an
alisis de
dumps
8.1.
Conceptos del log del sistema
El sistema R/3 graba eventos y problemas, tales como borrado de modos

de usuarios del sistema, bloqueos de usuarios al introducir incorrectamente
la password, parada y arranque del sistema, etc en un log. Este log no es mas
que un fichero a nivel de sistema operativo. Si el sistema R/3 se ejecuta en
hosts UNIX, existen dos tipos de log del sistema:
Local
Cada servidor de aplicaciones de R/3 dispone de un log local que contiene
los mensajes que ha generado ese servidor. Este fichero de log local es un
fichero circular. Cuando el fichero llega a su tama
no maximo, el sistema
empieza a sobreescribir el fichero desde el principio (la informacion mas
antigua). El fichero de log local se guarda en cada servidor de aplicacion
en la siguiente ruta:
Entorno UNIX /usr/sap/<SID>/<instance number>/log/SLOG00
Entorno Windows NT C:\usr\sap\<SID>\<instance number>\log\Slog00.log
donde <SID> es el nombre de la base de datos SAP y <instance number>
es el n
umero de instancia.
Central
Cada servidor de aplicaciones copia las entradas del log local a un log
85

CAPITULO 8. LOG DEL SISTEMA Y ANALISIS
DE DUMPS
86
central. Esta opcion no se encuentra en servidores Windows NT ni AS/400,

solo existen logs locales (uno por servidor de aplicacion). El log central se
guarda en un servidor de aplicaciones seleccionado, el resto de servidores de
aplicacion envan sus mensajes locales a este servidor.
El log central es escrito en 2 ficheros: un fichero activo y un fichero antiguo.
El fichero activo contiene el log actual. Cuando el fichero activo llega a su
longitud maxima definido en los parametros del sistema, este borra el fichero
antiguo de logs, usa el fichero activo como fichero antiguo y crea un nuevo
fichero de log. Este cambio en el log no es notificado al usuario.
Mientras que el log local se mantiene siempre actualizado, el log central
puede sufrir retardos desde que se escribe un mensaje en el log local hasta
que ese mensaje es enviado al log central. Fallos de comunicaciones entre los
distintos servidores pueden resultar en retardos grandes en la escritura del
log central o incluso en perdida de estos mensajes.
8.1.1.
Accediendo al log local del sistema
Al log del Sistema se accede directamente por la transaccion SM21 o por

el men
u general HerramientasGestionMonitorLog Sistema .
La pantalla de selecccion de la transaccion SM21 tiene 2 modos: El modo
Normal y Experto. El modo normal es el definido por defecto, y al que se
entra directamente cuando se ejecuta la transaccion SM21. Para cambiar
a modo experto, deberemos ir al men
u desplegable TratarModo experto.
Ambos modos se diferencian en que este u
ltimo da mas opciones de seleccion.
8.1.2.
Accediendo al log local en modo normal
Accediendo a la transaccion SM21 directamente o a traves de men

u
entramos por defecto a la pantalla de seleccion del log local del servidor de
aplicaciones al que estemos conectados en Modo Normal.
Veamos los distintos parametros de seleccion que nos permitiran filtrar
los datos del log:
De Fecha/Hora a Fecha/Hora: Permite establecer un rango de fechas
de mensajes del log a visualizar.
Usuario: Nos permitira visualizar solo los mensajes que se hayan
grabado en el sistema debido exclusivamente a la actividad del usuario
especificado.
8.1. CONCEPTOS DEL LOG DEL SISTEMA
87
Figura 8.1: Pantalla principal log local del sistema
Codigo de transacion: Nos permitira visualizar los mensajes del log

debidos exclusivamente a la accion de los usuarios sobre la transaccion
especificada.
Proceso SAP: Nos permitira visualizar los mensajes de log debidos a
un proceso particular R/3. Valores posibles son:
DP
Dn
Procesos del dispatcher

Procesos de trabajo, donde n = 0,...,9 o n = a,
...,z . En el caso de tener mas de 10 procesos de
trabajo numeraremos los siguientes con las letras del
abecedario.
VB Actualizaciones
Vn Programas de actualizazion, donde n = 0,...,9 o n =
a, ...,z
Sn Spool, donde n = 0,...,9 o n = a, ...,z
MS Servidor de Mensajes
Clases de Problemas: Limita la visualizacion por tipo de mensaje, solo

DE DUMPS
88
errores, errores y advertencias y todos los mensajes. El valor por defecto

es la opcion todos los mensajes.
8.1.3.
Accediendo al log local en modo experto
Para acceder al log del sistema en modo experto deberemos acceder por
el men
u desplegable tal y como se ha explicado anteriormente. La pantalla
visualizada es igual que la anterior con la salvedad que se dispone de mas
opciones de filtro como es la opcion Atributos.
Figura 8.2: Parametros de seleccion adicionales en modo experto

Esta opcion nos permite filtrar ademas por:
Programa: Se restringe el resultado a los mensajes causados por la
ejecucion del programa especificado.
Clase de Problema: Limita el resultado a ciertos tipos de mensajes. Los
valores posibles son:
K
S
T
W
X
Mensajes del kernel del sistema

Mensajes de estado
Mensajes de transacciones
Mensajes de advertencia
Otros tipos de mensajes
De fichero / posicion a fichero / posicion: Define el segmento del fichero

de log a leer. Si ya se ha ledo el fichero una vez, se puede determinar
89
la posicion de una entrada especfica haciendo doble click; la posicion

se encuentra en la seccion de detalles tecnicos.
Formato mensaje (tipo): Se pueden seleccionar mensajes por el
formato de la componente del sistema. Para visualizar posibles valores,
deberemos pulsar el boton de ayuda de b
usqueda correspondiente.
Terminal: Se pueden filtrar los mensajes que han sido causados por la
actividad llevada a cabo desde un servidor de presentacion.
Clase de desarrollo: Se pueden filtrar los mensajes que han sido
producidos por la ejecucion de programas que pertenezcan a una clase
de desarrollo en particular. Las clases de desarrollo son agrupaciones
de objetos de Workbench o Customizing cuyo proposito es la
jerarquizacion de tales objetos para una mejor gestion as como el
posibilitar su transporte a otros entornos.
Con entradas internas Syslog: Visualizacion de mensajes relativos a los
procesos de recoleccion y envo de mensajes de log desde el log local al
log central. Esta opcion no esta disponible para entornos que no sean
Unix.
8.1.4.
Leyendo el log del sistema
Una vez introducidos los valores de seleccion en la pantalla accederemos

al contenido del log pulsando el boton Nueva Lectura syslog.
El log del sistema aparece en formato tabla con las siguientes columnas
en el siguiente orden:
Hora del mensaje
Proceso SAP
Mandante
Usuario
Codigo transaccion
No de mensaje
Texto del mensaje
8.1.5.
Opciones de relectura del log del sistema
Si hemos visualizado una vez el contenido del log del sistema filtrando
exclusivamente por fecha y sin salirnos de la transaccion volvemos a la
90

DE DUMPS
Figura 8.3: Contenido del log del sistema
pantalla de seleccion, el sistema muestra tres distintas opciones para volver

a visualizar la informacion:
Figura 8.4: Opciones de la barra de aplicaciones del log del sistema
Nueva Lectura en el Syslog. Vuelve a acceder al fichero para sacar un nuevo

listado con los parametros que se hayan seleccionado.
Solo Editar Nuevamente. Vuelve a mostrar el u
ltimo resultado del log
visualizado anteriormente con esta opcion.
Cargar en Syslog. Permite realizar una nueva lectura en el syslog filtrando
con otros valores pero mantiene en el buffer el anterior resultado que puede
ser accedido de nuevo a traves de la segunda opcion.
8.1.6.
91
Accediendo a logs remotos del sistema
Si el sistema SAP R/3 al que estamos conectados es un sistema

distribudo, es decir , esta compuesto de varios servidores de aplicaciones,
tendremos la posibilidad de acceder a cada uno de los logs locales de cada
uno de los servidores sin tener que conectarnos directamente a cada uno de
los servidores de aplicacion. Para ello usaremos las opciones de lectura de logs
remotos que nos ofrece la transaccion SM21. Estas opciones se encuentran
en el men
u desplegable en SyslogSeleccionar .
Figura 8.5: Pantalla principal log remoto del sistema
La opcion syslog local es la que esta activa por defecto y ya ha sido

explicada . La opcion syslog remoto nos lleva a una pantalla similar a la
pantalla de seleccion del syslog local con la salvedad que incluye un parametro
mas en la pantalla de seleccion. Este parametro es la instancia. Aqu le
podremos indicar el nombre de la instancia cuyo log del sistema queremos
visualizar.
La opcion todos los syslogs remotos nos lleva a una pantalla de seleccion
identica a la del log local con la salvedad que los mensajes que se visualizaran
corresponderan la los de todas las instancias que componen nuestro sistema
R/3. En la visualizacion de los mensajes del log aparecera un campo mas

DE DUMPS
92
llamado instancia que nos servira para conocer en que instancia se ha

generado cada mensaje.
La opcion Syslog Central no esta disponible para sistemas R/3 fuera del
entorno UNIX.
Es importante destacar que las u
nicas instancias que estan disponibles
para la visualizacion de los logs remotos son las que componen el sistema
R/3 al que estamos conectados.
8.2.
Concepto de dump
Dump o error en tiempo de ejecucion es un log de terminacion anormal

de ejecucion de cualquier programa. Esto se produce por una cancelacion del
programa que se esta actualmente ejecutando; el sistema nos muestra una
pantalla con un log de terminacion donde se puede encontrar informacion
acerca del error producido y su posible solucion.
Las posibles causas de terminacion anormal de programas, entre otras,
pueden ser:
Errores de sintaxis en programas hechos a medida.
Referencias obsoletas a objetos del Workbench hechos a medida que
han sido eliminados.
Cancelacion manual de un modo actualmente en ejecucion.
Cuando se produce una terminacion anormal de una ejecucion de un
programa, el dump es mostrado automaticamente en exclusiva al usuario cuyo
proceso de dialogo ha sido cancelado. En ese momento el usuario podra leer
ese log, pero si se sale de la pantalla del log del dump, este ya no se vuelve
a mostrar en pantalla. Para acceder de nuevo a el, deberemos acudir a
la transaccion donde se puede gestionar todos los dumps producidos en el
sistema.
8.2.1.
Accediendo a los dumps del sistema
La transaccion de los dumps es ST22; accediendo por el men

u desplegable
sera HerramientasGestion MonitorAnalisis de Dumps.
Por defecto solo se muestran los dumps producidos a fecha de hoy y el
da anterior. Si deseamos acceder a un dump mas antiguo deberemos pulsar
la opcion Pasar a Sel. Dump breve. A continuacion nos aparacera una
pantalla de seleccion donde podremos filtrar por fecha, usuario, maquina,
mandante.
8.2. CONCEPTO DE DUMP
Figura 8.6: Pantalla principal de analisis de dumps
Figura 8.7: B
usqueda de dumps antiguos
93
94

DE DUMPS
8.2.2.
Interpretando los dumps
Tanto si visualizamos los dumps producidos a fecha actual, como del da

anterior o alguna fecha mas antigua, estos apareceran en forma de lista. Esta
lista esta formada por los siguientes campos:
Fecha del dump
Hora del dump
Servidor de aplicaciones donde se ha producido
Usuario que ha provocado el dump
Breve descripcion del dump
Haciendo doble click en cada uno de ellos accederemos al log del dump
donde tendremos toda la informacion. El contenido de todos los dumps estan
organizados en las siguientes secciones:
1. Que sucedio? .
Seccion donde se explica brevemente el error.
2. Que se puede hacer? .
Seccion que explica brevemente las acciones a llevar a cabo.
3. Analisis error .
Seccion donde se explica mas detalladamente el error. Es una extension
de la seccion 1.
4. Notas para corregir errores .
Seccion donde se explica mas detalladamente las acciones a llevar a
cabo. Es una extension de la seccion 2.
5. Entorno sistema .
Seccion donde aparecen las variables del sistema mas importantes, tales
como la version de SAP, nombre del servidor, direccion IP, sistema
operativo, RDBMS, version del kernel, etc. . .
6. Usuario, transaccion.
Seccion donde aparece el usuario que ha generado el dump, programa
que se estaba ejecutando, transaccion, idioma, etc. . .
7. Informaciones lugar terminacion .
Seccion donde se especifica la linea del programa donde se ha producido
el error.
95
8. Detalle codigo fuente .

Seccion que muestra un intervalo del codigo fuente donde se ha
producido el error. La lnea donde se ha producido el error aparece
marcada con una flecha.
9. Contenido campos sistema.
Seccion donde se muestran los valores que tenan algunas variables del
sistema cuando se produjo el error.
10. Variables seleccionadas .
Seccion donde se detalla mas exhaustivamente el contenido de mas
variables cuando se produjo el error .
11. Llamadas / Eventos activos.
Seccion que detalla el evento o la llamada a la que pertenece la linea
de codigo que ha producido el error .
12. Notas internas .
Seccion que detalla la funcion C perteneciente al kernel de SAP donde
se ha producido el error .
13. Llamadas activas kernel SAP .
Seccion que detalla los elementos del kernel y su posicion que estaban
activos en el momento del error .
14. Lista programas ABAP involucrados .
Seccion que muestra los programas involucrados en la ejecucion del
programa que produjo el error .
15. Lista tablas internas .
Seccion que detalla el conjunto de tablas internas que se estaban
procesando en el momento del error y el contenido de su cabecera
cuando el error se produjo.
16. Directorio tablas aplicacion (contenidos) .
Seccion que detalla las tablas de aplicacion que han sido usadas durante
la ejecucion del programa que ha terminado en error.
17. Directorio ambitos datos (info gestion) .
Seccion que detalla el conjunto de objetos del workbench ( variables,
parametros, tablas) involucradas en la ejecucion del programa.
18. Directorio ambitos datos (contenidos).
Seccion de contenido parecido a la anterior .
96

DE DUMPS
19. ABAP/4 Bloques control CONT .

Seccion con informacion complementaria a la de la seccion 8 .
20. Fin analisis error tiempo ejecucion .
Seccion que marca el fin del log del dump.
Si bien el ttulo de cada seccion aparece en el idioma de conexion,
el contenido solo se encuentra disponible en ingles y en aleman. Si nos
conectamos al sistema en un idioma distinto del ingles y aleman, el dump
sera visualizado en el idioma configurado como de suplementacion, que en
general sera el ingles, sino se ha definido suplementacion de idioma (esto
pertenece a la instalacion de lenguajes) se visualizara en el idioma original
de SAP, que es el aleman.
Las secciones mas importantes y que mas nos pueden ayudar para
solucionar el error son la 1,3,7 y 8.
Ejemplo de log de dump
Errores tiempo ejecuci

on SYNTAX_ERROR
ocurrido el 20.07.2000 a 04:10:06
---------------------------------------------------------Syntax error in program "AQ99HA==========CAND1========= ".
---------------------> Qu
e sucedi
o ?
---------------------The following syntax error occurred in the program
AQ99HA==========CAND1========= :
"The data object "T750B" does not have a component called "PERNR".
"The current ABAP/4 program "AQ99HA==========CAND1========= " had
to be terminated because one of the statements could not be
executed.
This is probably due to an error in the ABAP/4 program.
-------------------------------> Qu
e se puede hacer ?
97
-------------------------------Please eliminate the error by performing a syntax check

(or an extended program check) on the program
"AQ99HA==========CAND1========= ".
You can also perform the syntax check from the ABAP/4 Editor.
If the problem persists, proceed as follows:
Print out the error message (using the "Print" function)
and make a note of the actions and input that caused the
error.
To resolve the problem, contact your SAP system administrator.
----------------An
alisis error
----------------The following syntax error was found in the program
AQ99HA==========CAND1========= :
"The data object "T750B" does not have a component called "PERNR".
-----------------------------------Notas para corregir errores
-----------------------------------Probably the only way to eliminate the error is to correct
the program.
If you cannot solve the problem yourself, please send the
following documents to SAP:
1. A hard copy print describing the problem.
To obtain this, select the "Print" function on the current screen.
2. A suitable hardcopy printout of the system log.
To obtain this, call the system log with Transaction SM21
and select the "Print" function to print out the relevant
part.
3. If the programs are your own programs or modified SAP programs,

DE DUMPS
98
supply the source code.

To do this, you can either use the "PRINT" command in the
editor or print the programs using the report RSINCL00.
4. Details regarding the conditions under which the error occurred
or which actions and input led to the error.
---------------------Entorno sistema
---------------------SAP Release.............. "40B"
Application server.......
Network address..........
Operating system.........
Release..................
Hardware type............
"prodsap1"
"10.190.20.13"
"AIX"
"3"
"000541934C00"
Database
Database
Database
Database
"sa3dbh2r"
"ORACLE"
"SP1"
"SAPR3"
server..........
type............
name............
owner...........
Character set............ "es_ES.ISO8859-1"

SAP kernel...............
Created on...............
Created in...............
Database version.........
"40B"
"Nov 4 1999 01:44:15"
"AIX 2 4 004218294C00"
"ORACLE 8.0.0.4"
Patch level.............. "542"

Patch text............... " "
Supported environment....
Database................. "ORACLE 8"
SAP database version..... "40B"
Operating system......... "AIX 2, AIX 1, AIX 3"
------------------------------Usuario, transacci
on....
99
------------------------------Client..............
User................
Language key........
Transaction.........
Program.............
Screen..............
Screen line.........
111
"116665u"
"S"
" "
"AQ99HA==========CAND1========= "
"SAPMSSY0 1000"
6
------------------------------------------Informaciones lugar terminaci

on
------------------------------------------The termination occurred in the ABAP/4 program
"AQ99HA==========CAND1========= " in " ".
The main program was " ".
The termination occurred in line 0 of the source code of
program " " (when calling the editor 00).
The program "AQ99HA==========CAND1========= " was started as a
background job.
-----------------------------------Contenido campos sistema
-----------------------------------Campo SY
-------SY-SUBRC
SY-TABIX
SY-FDPOS
SY-PAGNO
SY-COLNO
Contenido.......
---------------0
0
0
0
1
Campo SY
-------SY-INDEX
SY-DBCNT
SY-LSIND
SY-LINNO
Contenido...........
-------------------0
0
0
1
-------------------------------Variables seleccionadas
--------------------------------No existe ninguna informaci
on en el dump.
100

DE DUMPS
------------------------------------Llamadas / Eventos activos

------------------------------------No Tipo
Nombre Programa
Include L
nea
------------------------------------------------------1
??? ???
???
???
0
----------------Notas interna
-----------------The termination occurred in the function "ab_genprog" of the SAP
Basis System, specifically in line 845 of the module "abgen".
The internal operation just processed is " ".
Program name.........: "AQ99HA==========CAND1========= ".
Error message........: "The data object "T750B" does not
have a component called "PERNR". ".
---------------------------------------Llamadas activas kernel SAP
---------------------------------------AixStack at 0x100c3cb0
CTrcStack at 0x100c3fa0
rabax_CStackSave at 0x100683f0
ab_rabax at 0x1006f270
ab_genprog at 0x103fd33c
newload at 0x100dd164
ab_LoadProg at 0x100dd518
ab_dialg at 0x103558f0
dy_cdiag at 0x101fd310
ab_submit at 0x104ee7a8
ab_retdynp at 0x10351794
ab_run at 0x104eda34
dynpmcal at 0x104d62cc
dynppai0 at 0x104d7aec
dynprctl at 0x104d8cd0
dynpen00 at 0x104c0f30
Thdynpen00 at 0x100b4f14
TskhLoop at 0x100b9d7c
101
tskhstart at 0x100c2404
DpMain at 0x10016bb4
main at 0x100011fc
-----------------------------------------------Lista programas ABAP involucrados
------------------------------------------------------------------------------------------------------------No existe ninguna informaci
on en el dump.
---------------------------Lista tablas internas
--------------------------No existe ninguna informaci
on en el dump.
-----------------------------------------------------Directorio tablas aplicaci

on (contenidos)
-----------------------------------------------------Programa
Nombre........ Cont.....1....+....2....+....3....+....
----------------------------------------------------------------------------------------------------------Directorio
ambitos datos (info gesti
on)
--------------------------------------------------Programa
No .. Nombre........ Long Ofsg Tipo Next Fecha gen. H.gen.
--------------------------------------------------------------0 not assigned
1 /%_LISTTABLES
2 global stack
0
6968
65536
0 INVL
0 COMM
0 GLST
0
0
0
-------------------------------------------------Directorio
ambitos datos (contenidos)
--------------------------------------------------
102

DE DUMPS
Programa
No .. Nombre... Cont.....1....+....2....+....3....+....
--------------------------------------------------------?
0 not assigned
<initial>
1 /%_LISTTABLES |\0\0\00\0\0\0\0\0\0\0\0\0\0\0\0\0\
2 global stack
|
0000
----------------------------------------ABAP/4 Bloques control CONT
----------------------------------------No existe ninguna informaci
on en el dump.
---------------------------------------------Fin an
alisis error tiempo ejecuci
on
----------------------------------------------
Captulo 9
Gesti
on de spool
9.1.
Concepto de spool
En cualquier entorno de gestion empresarial se produce una gran cantidad

de informacion que en muchas ocasiones interesa sacar a papel a traves de
informes, listados, analisis. . . El spool es un almacen receptor de peticiones
de impresion que proporciona una serie de utilidades para controlar la salida
de informacion. Aunque se asocia directamente spool con imprimir en papel,
en SAP las posibilidades son mas amplias: podemos enviar una orden de
spool por fax, o imprimirla en un fichero. Nosotros nos limitaremos a ver
el funcionamiento de la salida por impresora para lo cual lo primero que
debemos hacer es aprender como se instala una.
9.2.
Instalaci
on de una impresora
Con la transaccion SPAD pantalla de la figura 9.1 a la que llegaremos

a traves de Herramientas CCMS Spool Gestion de spool podemos
instalar dispositivos de salida en nuestro sistema R/3. Vamos a describir
la instalacion de una impresora de tipo local a nivel de PC, es decir, una
impresora generica en la que cualquiera puede imprimir pero a cada persona
que lo haga le saldra la informacion por la impresora que tenga definida por
defecto en su servidor de presentacion.
En el campo dispositivo de salida introduciremos el nombre que le vamos
a dar a la impresora y tras pulsar el boton Gesti
on total y el boton con el
icono de un folio en blanco llegaremos a la pantalla de la figura 9.2 en la que
definiremos los siguientes datos:
Tipo de dispositivo. Es lo mas parecido a lo que en microinformatica
se denomina driver de la impresora. Para la creacion de una impresoral
103
104
DE SPOOL
CAPITULO 9. GESTION
Figura 9.1: Transaccion SPAD. Mantenimiento de dispositivos de salida
local elegiremos siempre el tipo SAPWIN. Este dispositivo precisa de un

programa llamado saplpd que forma parte de la instalacion del frontend
de SAP. Cuando se imprime algo el sapgui ejecuta automaticamente el
programa saplpd y este recibe los datos a imprimir y se encarga de
enviarlos a la impresora.
Clase de dispositivo. Seleccionamos de la lista la opcion Impresora
com
un.
Grupo de autorizaciones. Podemos restringir a los usuarios a que
puedan imprimir por determinadas impresoras. Esto es muy interesante
cuando disponemos de impresoras de alto rendimiento dedicadas a
la impresion de facturas, nominas, etc. No nos interesara, en estos
casos, que ning
un usuario pueda sacar listados por estas impresoras
interrumpiendo los largos procesos que suelen llevar a cabo. Como
estamos definiendo una impresora local para todo el mundo dejamos
este campo en blanco.
Modelo. Campo descriptivo para poner la marca y modelo de la
DE UNA IMPRESORA
9.2. INSTALACION
105
Figura 9.2: Datos generales para una impresora local
impresora.
Ubicacion. Campo descriptivo para indicar al usuario donde se encuentra fsicamente la impresora. Es u
til rellenarlo cuando disponemos de
salas separadas para las impresoras a las que hay que dirigirse para
recoger la salida del spool.
Por u
ltimo, pasamos a la pesta
na marcada con la etiqueta Acomplam.
SPOOL host y nos mostrara la pantalla de la figura 9.3
Aqu se le dice como esta conectada la impresora al servidor SAP.
Elegiremos de la lista la opcion F:Imprimir en front end que le marca
que debe enviar la informacion al PC para que sea este el que le de
salida. El campo impresora host debemos rellenarlo con el nombre DEFAULT
para indicarle que la orden de spool debe salir por la impresora que este
configurada por defecto en el PC. Una vez hecho esto solo nos queda pulsar
el boton de grabar y ya podemos usar la impresora instalada.
DE SPOOL
CAPITULO 9. GESTION
106
Figura 9.3: Tipo de impresora para una impresora local
9.3.
Como imprimir
Teniendo una impresora ya instalada podemos, desde cualquier pantalla

de listado, pulsar el icono de impresora de la barra de estandar de
herramientas y tendremos que rellenar las opciones que vemos en la figura
9.4.
El primer campo a rellenar es el nombre de la impresora por donde
queremos que salga nuestro listado1 . Este es el u
nico campo obligatorio, pero
tambien podemos indicar otras muchas opciones que vemos a continuacion.
La cantidad de copias que queremos sacar.
Si queremos todas las pagina o solo un rango de ellas.
El nombre y el ttulo de la orden de spool. Sera u
til para luego buscarla
entre el spool o entre el monton de hojas impresas que salen por una
impresora compartida.
La salida inmediata o el almacenamiento en el spool.
1
En la pantalla viene con el nombre generico de dispositivo de salida.
9.3. COMO IMPRIMIR
Figura 9.4: Ventana de dialogo para imprimir un listado
107
DE SPOOL
CAPITULO 9. GESTION
108
Podemos marcar el borrado de la orden tras la impresion correcta o,

por el contrario, dejar que la orden permanezca en el spool para futuras
reimpresiones.
La cantidad de das que debe permanecer en el spool antes de ser
borrada por los jobs de mantenimiento.
La impresion de una portada previa con el ttulo de la orden de spool
y el destinatario y departamento al que pertenece. Estos ultimos datos
tienen sentido en una empresa en la que haya servicio de entrega de
impresiones, es decir, que no tenemos que ir a la impresora sino que
nos envan los papeles a nuestro puesto de trabajo.
La cantidad de lneas y columna que queremos sacar y por lo tanto el
formato de la pagina.
9.4.
Operaciones sobre
ordenes de spool
Para poder administrar todas las peticiones de spool que hacemos SAP
provee de la transaccion SP01 que se encuentra en Herramientas CCMS
Spool Control de salida. En ella nos encontramos inicialmente una pantalla
con criterios de seleccion como la de la figura 9.5.
Aqu podemos elegir las ordenes de spool por varios criterios; los
mas habituales son el creador de la orden y la fecha. Tras pulsar F8
nos encontramos con un listado de las ordenes seleccionadas como el
de la figura 9.6. Este listado tiene la misma caracterstica que el de la
transaccion de gestion de jobs; es un programa de seleccion, listado y gestion
simultaneamente.
Las operaciones que podemos hacer sobre una orden de spool incluyen
la creacion de ordenes de salida, el cambio de los atributos, el borrado de
la orden o la visualizacion de su contenido. Esta u
ltima opcion es realmente
interesante cuando queremos comprobar el resultado de un programa que se
ha ejecutado en proceso de fonfo, pero no queremos imprimirlo hasta ver
si ha salido lo que esperabamos. En cuanto a los atributos, en la figura 9.7
podemos ver algunos de los que se pueden cambiar. Basicamente son los
mismos que definimos inicialmente al crear la orden de spool (ver figura
9.4). Por ejemplo, es muy habitual comprobar tras la salida al papel que un
listado que tiene 132 columnas en sus atributos ha salido con letra peque
na
y en formato horizontal pero no llega a ocupar realmente mas de 80. En ese
caso cambiaremos el campo edicion por un X 65 80 para conseguir un listado
con letra mas grande y en vertical y volveremos a repetir la salida de la orden.

9.4. OPERACIONES SOBRE ORDENES
DE SPOOL
Figura 9.5: Transaccion SP01. Seleccion de ordenes de spool
Figura 9.6: Transaccion SP01. Listado de ordenes de spool
109
110
DE SPOOL
CAPITULO 9. GESTION
Una de las labores del administrador consiste en asegurarse que las

ordenes de spool olvidadas por los usuarios no llenan nuestra base de
datos. Para ello dispone del programa RSPO0041 que le permite eliminar
masivamente el spool que lleve mas de n das almacenado.
Figura 9.7: Atributos de una orden de spool
Captulo 10
Gesti
on de usuarios y
autorizaciones
10.1.
Modelo de seguridad en R/3
En cualquier sistema de gestion de informacion integrado se guardan datos

de diferentes areas a los que solo pueden acceder algunas personas. Estas
restricciones pueden darse por varios motivos:
Proteger datos que afecten a la estrategia de la empresa para no ofrecer
ventajas a la competencia.
Evitar fraudes en la contabilidad o en los cobros y pagos.
Obligacion legal de proteger informacion ajena a la propia empresa
como los datos personales de sus empleados, las condiciones economicas
de los proveedores.
SAP contempla toda esta problematica implementando un modelo de
seguridad que permite proteger de una manera flexible los datos y las
operaciones que se hacen sobre ellos. En la figura 10.1 podemos ver un
esquema de los componentes de la seguridad en R/3.
En el lado derecho tenemos los objetos de autorizacion que se componen
de campos. Estos objetos representan lo que queremos proteger. Ejemplos de
objetos de autorizacion son:
S TCODE. Protege el codigo de transaccion y contiene un solo campo
que es la transaccion. Es el mas importante de todos porque todas
las operaciones que se hacen en SAP empiezan por el acceso a una
transaccion.
111
112
DE USUARIOS Y AUTORIZACIONES
CAPITULO 10. GESTION
Figura 10.1: Componentes de la seguridad en R/3
S TABU DIS. Proteccion del contenido de tablas de customizing.

Contiene dos campos que son el grupo de autorizaciones de la tabla
(DICBERCLS) a la que se quiere acceder y la actividad (ACTVT) que
se quiere ejecutar (crear, modificar, borrar. . . )
F BKPF BUK. Proteccion de la contabilizacion de documentos por
sociedad financiera. Se compone de dos campos; la sociedad (BUKRS) a
cuyos documentos contables queremos acceder y la actividad (ACTVT)
que se quiere hacer.
En el lado izquierdo de la figura vemos la estructura modular que va desde
la autorizacion simple sobre un u
nico objeto de autorizacion hasta el maestro
de usuarios que son los que acceden al sistema. Veamos lo que representa cada
uno de los niveles:
Autorizaciones. Una autorizacion consiste en una asignacion de
valores a los campos de un objeto de autorizacion. Por ejemplo,
crearemos una autorizacion para el objeto S TCODE que tenga el
valor FB01 para el campo TCODE. De esta manera el usuario que
tenga asignada esta autorizacion podra acceder a la transaccion de crear
documento contable. Tambien tendremos que crear otra autorizacion
10.2. MANTENIMIENTO DE USUARIOS
113
sobre el objeto F BKPF BUK con los valores 1000 para BUKRS y 01
para ACTVT con la que puedan completar la operacion de contabilizar
para la sociedad financiera 1000.
Perfiles. Un perfil es simplemente la agrupacion de varias autorizaciones que hayamos creado anteriormente. El perfil es la unidad mnima
de seguridad que le podemos asignar a un usuario, es decir, la u
nica
forma de asignar las dos autorizaciones del ejemplo anterior es incluirlas en un perfil que llamaremos CONTABLE e incluir este perfil en los
usuarios.
Grupos de actividad. Son las agrupaciones de transacciones y
actividades que se crean con el generador de perfiles. Estos grupos
de actividad contienen internamente perfiles (que a su vez contienen
autorizaciones) y se asignan directamente a los usuarios.
Usuarios. Para que un empleado tenga acceso a los datos de gestion
de la empresa debe disponer de un codigo de usuario en R/3. Este
usuario tendra asignados unos grupos de actividad o unos perfiles de
autorizacion (o ambos) para poder realizar las tareas que exige su
funcion o puesto de trabajo.
10.2.
Mantenimiento de usuarios
Para la creacion y mantenimiento de usuario R/3 dispone de la transaccion SU01 (Herramientas Gestion Actualizar usuarios Usuarios). En
la pantalla correspondiente a la figura 10.2 escribiremos el codigo del usuario
y pulsando uno de los botones de la barra de aplicacion o escogiendo una
de las opciones del men
u Usuario podemos realizar diversas acciones como
crear, modificar, cambiar clave acceso, bloquear. . .
Pulsando sobre el boton con el icono de un folio en blanco vamos a crear
un nuevo usuario en el sistema. Vemos en la figura 10.3 las siete pesta
nas
que componen el registro maestro de un usuario. Estas son:
Direcci
on. Se graban en este apartado datos personales como el
nombre, apellidos, departamento, telefono. . . . En el campo edicion
veremos el nombre tal y como aparecera en los listados o en otras
transacciones.
Datos logon. Es obligatorio indicar una clave inicial con la que
accedera el usuario, aunque en su primera conexion se le pedira que
la cambie. Tambien podemos limitar la validez temporal de manera
114
Figura 10.2: Pantalla inicial de la actualizacion de usuarios
que podemos tener empleados que accedan a nuestro sistema hasta

determinada fecha como puede ser el fin de su contrato o cesion a
nuestro departamento.
Valores fijos. En esta pesta
na definimos el men
u inicial de entrada
al sistema, la impresora SAP y algunos parametros de impresion por
defecto, y el formato en que debe ver el usuario las fechas y los importes
en todas las transacciones SAP. Esta u
ltima opcion, junto con la del uso
horario, es vital para empresas multinacionales que tienen empleados
en diversos pases.
Par
ametros. Existe la posibilidad de asignar parametros por defecto
para multitud de campos de todos los modulos de SAP. Si un empleado
solo realiza entradas de mercancas en el centro 1000, es muy u
til
asignarle ese valor en el parametro correspondiente consiguiendo que
en todas las pantallas de R/3 en la que aparezca el campo centro, este
se encuentre relleno automaticamente con el valor 1000.
papeles y perfiles. Las operaciones a las que esta autorizado un
usuario vienen determinadas por los valores que le ponemos en estas
dos pesta
nas. Al asignarles un papel le estamos a
nadienlo perfiles
tambien, pero existe la posibilidad de incluir perfiles manualmente. Esta
posibilidad se conserva por compatibilidad con versiones anteriores pero
no es el modo de trabajo habitual desde la version 4.6A.
Grupos. A la hora de descentralizar el mantenimiento de un
10.2. MANTENIMIENTO DE USUARIOS
Figura 10.3: Datos de direccion del maestro de usuarios
115
116
n
umero enorme de usuarios debemos agruparlos asignandoles la
pertenencia a uno o varios grupos. De esta manera podemos autorizar
a diversos administradores a gestionar los usuarios que pertenezcan a
determinados grupos.
10.3.
Generador de perfiles
Debido a la gran complejidad que supone la creacion manual de perfiles

y autorizaciones, desde la version 3.1G de R/3, existe el generador de
perfiles. Las ventajas que aporta para el administrador la utilizacion de esta
herramienta son m
ultiples aunque la mas destacable es que ya no necesita
conocer o investigar la funcionalidad de las transacciones que incluyen en
los perfiles de usuario. El generador de perfiles incluyen una base de datos
que relaciona cada una de las transacciones de R/3 con los objetos que
comprueba. En la version 3.0F y anteriores, la creacion de un perfil de
seguridad exiga un tedioso trabajo de b
usqueda de objetos que chequea
cada transaccion.
Para crear un papel disponemos de la transaccion PFCG que nos muestra
una pantalla como la de la figura 10.4.
Figura 10.4: Transaccion PFCG. Mantenimiento de papeles
10.3. GENERADOR DE PERFILES
117
Al pulsar el boton de crear pasaremos a la pantalla de la figura 10.5 en

la que vemos las diferentes partes de la creacion de un grupo de actividad
repartidas en cuatro pesta
nas. En la primera de ellas rellenamos unicamente
un descripcion corta del papel y tambien podemos completar el campo de
descripcion inferior en el que podemos indicar instrucciones sobre a quien se
debe asignar este perfil o cual es su funcion especfica.
Figura 10.5: Descripcion del papel
Al pasar a la pesta
na men
u (ver figura 10.6) vemos unos botones que
nos permiten incluir transacciones, informes o direcciones web en el grupo
de actividad. Observamos en la figura como se ha incluido ya la transaccion
de contabilizar documento (perteneciente al modulo FI). Esto implica que
el usuario al que se le asigne este perfil podra ejecutar la transaccion FB01,
pero no hemos determinado a
un para que sociedades financieras, cuentas o
deudores podra hacerlo.
En la figura 10.7 tenemos la pantalla de asignacion de valores a los objetos
de autorizacion a la que se llega a traves de la pesta
na Autorizaciones. Son
cuatros los objetos de la gestion financiera los que chequea esta transaccion
118
Figura 10.6: Transacciones asignadas a un papel
y habra que dar los valores correspondientes para el grupo de actividad.

Por ejemplo, en el objeto grupo de autorizacion de cuentas para deudores
podemos poner un 01 en actividad y un * en grupo de autorizaciones con lo
que estamos permitiendo crear para todos los grupos de deudores. El resto de
los objeto de autorizacion debe ser completado tambien, solo cuando hayamos
asignado valores a todos tendremos los semaforos en verde, indicacion de que
podemos grabar el papel.
Por u
ltimo, desp
ues de completar la grabacion del grupo, tenemos la
posibilidad de asignarselo a uno o varios usuarios. En la figura 10.8 conviene
fijarse en que tenemos los semaforos de las pesta
nas men
u y autorizaciones en
verde, indicandonos que los pasos anteriores se han procesado correctamente.
Es entonces, cuando podemos poner en la tabla de usuarios los codigos (el
nombre nos lo rellena el propio programa) a los que queremos incluir el
papel y la fecha de validez de la asignacion. Esta fecha de validez tiene la
misma funcion que la que vimos en el maestro de usuario, es decir, nos puede
interesar autorizar a un usuario a hacer determinadas cosas en el sistema
durante un tiempo limitado de tiempo. Para evitar el tener que acordarnos
de quitar la autorizacion cuando llegue el da, ponemos la fecha de validez y
entonces perdera la autorizacion al dia siguiente.
10.3. GENERADOR DE PERFILES
Figura 10.7: Asignacion de valores a los objetos de autorizacion
Figura 10.8: Asignacion de un papel a usuarios
119
Captulo 11
Sistema de transporte
El sistema R/3 dispone de una herramienta que nos permite pasar objetos
de un entorno (por ejemplo, desarrollo) a otro (por ejemplo, produccion
). Los objetos a pasar pueden ser definicion y contenido de tablas nuevas,
programas nuevos, datos de customizing e incluso modificaciones al estandar.
Este traspaso de informacion entre un sistema R/3 y otro nos facilita
el mantenimiento del sistema productivo ya que con ello evitamos tener
que duplicar el trabajo de programacion o repetir la inclusion de datos
de customizing. Todo ello redunda en una mayor productividad y en una
minimizacion de riesgos ya que la informacion, antes de ser insertada en el
sistema productivo, es probada en el sistema de desarrollo y su traspaso no
sera realizado hasta que el responsable del proyecto de el visto bueno.
La herramienta que permite este traspaso de informacion entre sistemas
R/3 es el llamado sistema de transportes.
11.1.
Ordenes
de transporte
El sistema de transporte se emplea, generalmente, para trasladar objetos

desde el sistema de desarrollo hasta el sistema de produccion; obviamente
si no existe tal separacion de sistemas, es decir, si solo se dispone de un
u
nico sistema la utilidad del sistema de transportes se reduce a traspasar
informacion dependiente de mandante de un mandante a otro dentro del
mismo sistema. El sistema de transporte puede usarse para:
Borrado de objetos obsoletos en el sistema destino.
Insercion de nuevos objetos en el sistema destino.
Modificacion de objetos ya existentes en el sistema destino.
121
CAPITULO 11. SISTEMA DE TRANSPORTE
122
Cuando se crea o modifica un objeto en el sistema de desarrollo, el

sistema propone un codigo u
nico para identificar la creacion o modificacion
de ese objeto, siempre y claro esta que el mandante donde se este trabajando
este configurado para registrar cualquier modificacion (ver captulo 12). El
codigo propuesto conforma lo que se denomina Orden de Transporte y a ella
se asociaran los objetos que el usuario cree o modifique, de tal manera que
el sistema bloqueara, dependiendo de la naturaleza de la orden, esos objetos
para que nadie mas que el propietario de esa orden de transporte pueda
modificar esos objetos mientras la orden no este liberada, es decir preparada
para ser transportada.
La nomenclatura de una orden de transporte es:
<SID>K9nnnnn
donde <SID> es el nombre de la base de datos del sistema donde estamos
trabajando y 9nnnnn es un n
umero secuencial que ira creciendo desde 900000
hasta 999999 a medida que vayamos creando nuevas ordenes de transporte.
El sistema de transportes no asocia directamente los objetos creados o
modificados a una orden de transporte sino que lo hace a traves de las tareas;
las tareas deben obligatoriamente pertenecer a una u
nica orden de transporte
y al igual que ellas siguen el mismo codigo secuencial de tal manera que nunca
pueden existir varias ordenes o tareas con el mismo codigo. Las tareas, al
igual que las ordenes, estan asignadas a un usuario y su finalidad es mejorar
la gestion de los cambios introducidos en el sistema ya que una orden puede
albergar varias tareas pertenecientes o no al mismo usuario.
Ejemplo: Supongamos un sistema SAP R/3 de desarrollo cuyo SID es
D10 en el cual el usuario USUARIO1 crea un nuevo programa llamado
ZPROGRAMA y una nueva tabla llamada ZTABLA. Supongamos que es
la primera orden de transporte que se genera en ese sistema por lo que su
codigo sera D10K900000, y que se usa la misma orden para englobar los dos
objetos.
Supongamos el mismo sistema pero el caso de introducir cada objeto en
una orden distinta, por ejemplo D10K900000 y D10K900002.
La diferencia basica entre un caso y otro sera que el transporte al sistema
productivo de la primera orden conllevara el transporte de los dos objetos
programa y tabla a la vez, mientras que en el segundo caso el transporte
de una orden conllevara el transporte solo del objeto asociado.
Sera tarea del propietario de la orden el decidir de cuantos objetos se va a
componer cada orden de transporte. No se debera crear una orden para cada
objeto a modificar o crear ya que esto complicara de manera excesiva nuestra

11.1. ORDENES
DE TRANSPORTE
Figura 11.1: Esquema de una orden de transporte
Figura 11.2: Esquema de ordenes de transporte
123
124
labor de gestion de las ordenes de transporte; tampoco se debera asignar una

u
nica orden de transporte a todos los objetos que vayamos a crear o modificar
ya que ello puede llegar a hacer inmanejable la orden debido a su tama
no.
Se debera, por lo tanto, llegar a un termino intermedio de tal forma que
incluyamos en una orden los objetos que puedan estar relacionados, bien
debido a su naturaleza, bien porque pertenezcan al mismo proyecto.
11.2.
Clases de desarrollo
Cuando nos disponemos, en el sistema de desarrollo, a crear nuevos

objetos con las herramientas de desarrollo apropiadas, el sistema antes de
asignarle una orden de transporte nos pedira asociar el nuevo objeto por
crear a una Clase de Desarrollo.
Las clases de desarrollo no son mas que agrupaciones logicas de objetos
que, ademas, tienen asignada internamente una ruta de transporte, es decir,
un sistema origen y un sistema destino de transporte. Al asociar un objeto
a una clase de desarrollo estaremos, implcitamente, asignandole la ruta de
transporte a seguir cuando la orden asociada a ese objeto sea transportada.
Todos los objetos estandar del sistema SAP R/3, ya sean programas, tablas,
ayudas de b
usqueda, etc, tienen asociado una clase de desarrollo estandar de
SAP.
Los objetos nuevos a crear deberan asociarse a clases de desarrollo nuevas,
que se distinguiran de las estandar por el primer caracter de su identificacion,
que siempre debera ser una Z. Como caso excepcional podremos asignar a
nuestros objetos la clase de desarrollo $ TMP, la cual es denominada temporal
o local y tiene como particularidad el hecho de que los objetos a ella asociados
no son transportados a ning
un sistema destino, y por lo tanto el sistema no le
asigna ninguna orden de transporte. Esta clase de desarrollo se debera asignar
a objetos que sean de pruebas y que no deseemos que vayan a pasar nunca
a formar parte del sistema de produccion. Hablamos entonces de objetos
locales privados o temporales. Ver figura 11.3.
11.3.
Tipos de
ordenes de transporte
El sistema SAP R/3 provee distinto tipo de ordenes de transporte para

cada tipo de cambio que se desee realizar en el sistema:
Ordenes
de customizing A la hora de implementar el modelo de empresa
en SAP R/3 se necesita establecer ciertos datos en la parametrizacion
del sistema. La parametrizacion afecta primordialmente a los procesos

11.3. TIPOS DE ORDENES
DE TRANSPORTE
125
Figura 11.3: Clase de desarrollo
de negocio y es, por ello, dependiente de mandante. Si un mandante

ha sido establecido con grabacion automatica de cambios (ver captulo
12), una tarea y una orden de customizing son creadas automaticamente
cuando un usuario en un sistema R/3 realiza cambios de customizing.
Ordenes de modificaci
on transportables A la vez que cambios en el
customizing, sera tambien necesario desarrollar nuevas aplicaciones
que se ajusten perfectamente a las necesidades de la empresa. Esto
permite moldear el sistema R/3 a cualquier necesidad. Estos cambios,
pertenecientes al area de desarrollo y que afectaran basicamente a
programas y tablas, son independientes de mandante; esto significa
que tienen efecto en todo el sistema. La creacion de nuevos objetos, o
la modificacion de los que proporciona SAP son grabados, de manera
similar al customizing, en tareas asignadas a ordenes de modificacion
transportables.
Ordenes
de modificaci
on locales Tambien se pueden realizar cambios
locales; se distinguen de los anteriores en que estos cambios no pueden
ser transportados a otros sistemas.
126
11.4.
Estados de una orden de transporte y

sus tareas
Desde que se crean una orden de transporte y sus correspondientes tareas

hasta que son liberadas (fase previa para el transporte de dicha orden a otro
sistema), estas pasan por dos estados:
Modificable Cuando la orden o tarea es creada para ser asociada a objetos
de desarrollo o de customizing, esta aparece con status modificable;
es decir, permite la inclusion y eliminacion de objetos asociados. Si se
trata de una orden, esta permite la asignacion o borrado de tareas; si
se trata de una tarea, esta permite la asignacion o desasignacion de
objetos del sistema .
Liberada El paso previo del transporte consistira en la liberacion de
la orden y sus tareas asociadas. Para poder liberar una orden, se
debera primero liberar todas sus tareas asociadas. La liberacion de una
tarea consiste en cerrarla para posteriores modificaciones; es decir, no se
podra asignar nuevos objetos a esa tarea ni desasignar los ya existentes.
La liberacion de una orden consiste en cerrarla para posteriores tareas;
no se podra crear ninguna nueva tarea asociada a esa orden ni se podran
borrar las ya existentes.
Una orden puede permanecer en status Modificable aunque todas sus
tareas asociadas esten en estado liberado; ello nos permitira asignarle nuevas
tareas con status modificable para poder seguir trabajando con ella hasta
que liberemos la orden.
La liberacion de una orden de transporte ademas de bloquearla para
cualquier modificacion futura, realiza el export de la orden. El export de
la orden consiste en la creacion de dos ficheros a nivel de sistema operativo
fichero data y fichero cofiles . En estos ficheros se produce la exportacion
de los datos fuera de su base de datos, de tal manera que puedan ser
transportados al sistema destino. As pues, el transporte no es mas que la
exportacion de informacion fuera de la base de datos de origen a fichero del
sistema operativo y la importacion de dicha informacion en la base de datos
destino.
Los dos ficheros creados en la exportacion de una orden de transporte
tienen la siguiente ubicacion en el sistema operativo:
Fichero data
Ubicado en /usr/sap/trans/data; es el que contiene toda la informacion
asociada a la orden de transporte; cuantos mas objetos esten asociados a la
11.5. CUSTOMIZING ORGANIZER Y WORKBENCH ORGANIZER 127
Figura 11.4: Esquema pasos del transporte
orden de transporte a liberar, mayor sera el fichero data a crear y mayor el

tiempo que llevara su creacion, es decir, la exportacion. La nomenclatura del
fichero data, siendo la de la orden liberada <SID>K9nnnnn, puede ser:
D9nnnnn.<SID>
R9nnnnn.<SID>
Fichero cofiles
Ubicado en /usr/sap/trans/cofiles; es un fichero de control necesario
para el transporte; su tama
no es mucho menor que el data ya que no contiene
los datos de la orden. La nomenclatura del fichero cofiles, siendo la de la orden
liberada <SID>K9nnnnn, es:
K9nnnnn.<SID>
11.5.
Customizing organizer y workbench

organizer
Para gestionar las ordenes de transporte y sus tareas podremos usar el

customizing organizer CO y el Workbench Organizer WBO . Tanto
uno como otro se pueden acceder a traves de las transacciones SE09 como
SE10 y desde ellas se puede gestionar las ordenes de transporte relativas a
128
desarrollo (ordenes de modificacion tanto locales como transportables; esta

herramienta la usaran los desarrolladores) y las de Customizing (herramienta
que usaran los consultores).
Figura 11.5: Pantalla principal Workbench Organizer

En ambas herramientas la pantalla de seleccion dispone como parametro
principal del usuario, que por defecto esta relleno con el nombre del
usuario con el que nos hemos conectado al sistema. Todas las ordenes
que visualicemos con esta herramienta seran las asociadas al usuario arriba
indicado. Como parametros adicionales podemos elegir visualizar las ordenes
modificables y las liberadas o solo uno de los dos tipos. Ademas, tambien
podemos restringir por fechas para evitar que el listado sea demasiado largo
si es que hemos trabajado con muchas ordenes de transporte. En el caso del
customizing organizer tenemos, ademas, la posibilidad de visualizar solo las
ordenes de customizing o solo las de workbench o ambas a la vez.
Una vez elegidos los parametros de seleccion del CO o del WBO
pulsaremos el boton de visualizacion y accederemos a una pantalla como
la mostrada en la figura 11.6.
11.5. CUSTOMIZING ORGANIZER Y WORKBENCH ORGANIZER 129
Figura 11.6: Ordenes

de transporte
Desde esta pantalla podremos identificar que objetos estan asociados a

que ordenes de transporte sin mas que ir desplegando la estructura en arbol
presentada. Esta estructura en arbol nos muestra en un primer nivel la orden
de transporte, en un segundo nivel las tareas asociadas a esa orden y en un
tercer y u
ltimo nivel los objetos asociados a esa tarea.
Tanto el primer como segundo nivel tienen asociado un propietario que
es mostrado a la derecha de la orden y tarea. El propietario de la orden no
tiene por que coincidir con el propietario de las tareas asociadas ya que el
propietario de esa orden puede crear tareas asociadas y repartir la propiedad
de ellas entre los usuarios que considere adecuados. Esto puede ser de utilidad
en el caso del desarrollo de una nueva aplicacion donde el jefe de proyecto
crea una u
nica orden, si as lo considera oportuno, y crea una tarea asociada
a esa orden por cada desarrollador involucrado en el proyecto asignando la
propiedad de cada tarea a cada uno de los desarrolladores. De esta manera,
cada desarrollador ira asignando sus objetos a su tarea con lo que no se
130
producira solapamiento. Una vez que los desarrolladores acaben su trabajo, el

jefe de proyecto les indicara que liberen sus tareas (la liberacion solo la puede
realizar el propietario), pero el jefe de proyecto sera el que tenga la decision
de cuando liberar la orden, de la cual el es propietario. La exportacion de la
orden a fichero no se producira hasta que el propietario de la orden ejecute
la liberacion de la misma.
Desde esta pantalla podremos ejecutar la liberacion de cualquier orden de
la que seamos propietarios. La liberacion debe llevar siempre esta secuencia:
Ejecutar la liberacion de todas las tareas asociadas a esa orden
Ejecutar la liberacion de la orden
Ademas de la liberacion podremos borrar asignaciones de objetos a tareas
con estatus modificable. Esta opcion nos permite eliminar la asignacion de
un objeto dentro de una tarea sin mas que posicionar el cursor en el objeto
deseado y pulsar a continuacion la opcion de borrar. Esta opcion no borra
fsicamente el objeto, solo su asignacion a una tarea, y debera ser usado
cuando, por error, hayamos incluido un objeto en una tarea no deseada. Esta
opcion de borrado tambien puede ser u
til para eliminar tareas con estatus
modificable de ordenes, la u
nica restriccion que nos impone el sistema es que
esas tareas deben estar vacas. La opcion de borrado bien de objetos o de
tareas solo es aplicable cuando la orden y la tarea asociada tienen el estatus
modificable, es decir, que no se ha liberado todava. Un tarea ya liberada no
permite la desasignacion de sus objetos mediante la opcion de borrado. En
esta pantalla, ademas, podremos cambiar el texto descriptivo asociado a una
orden con el boton de modificar.
Otra opcion muy importante disponible tanto en la pantalla inicial del
WBO y del CO as como en las pantallas donde se muestran las ordenes
de transporte seleccionadas de los dos organizers es la opcion crear orden.
Eligiendo esta opcion el sistema nos muestra la pantalla de dialogo que vemos
en la figura 11.7.
Como campo principal se nos pide que introduzcamos una descripcion
para la orden a crear cuya codificacion la dara automaticamente el sistema
al crearla. El sistema, ademas, crea la orden con una u
nica tarea cuyo
propietario es el mismo que el que ha creado la orden; esta opcion se puede
cambiar. Podremos introducir tantas tareas como queramos sin mas que
asignar nuevos empleados a las tareas a introducir en la orden el sistema
introducira tantas tareas en la orden como empleados se haya especificado .
A esta opcion de creacion de ordenes de transporte tambien se puede
acceder desde fuera de la transaccion SE09 y SE10 cuando modificamos o

11.6. TRANSPORTE MANUAL DE ORDENES
131
Figura 11.7: Creacion de una orden de transporte
creamos un nuevo objeto de desarrollo. El sistema nos pide asignarle una

orden ya creada o crear una nueva.
11.6.
Transporte manual de
ordenes
Una vez que una orden ha sido liberada, esta se encuentra preparada para
ser importada al sistema destino.
El programa de control del transporte se encuentra a nivel del
sistema operativo; es el llamado tp.exe que esta junto con el resto
de programas ejecutables de SAP que componen el Kernel en la ruta
/usr/sap/<SID>/SYS/exe/run, donde <SID> es el directorio que tiene igual
nombre que la base de datos de SAP instalada en el servidor.
El programa tp se debe ejecutar desde la ruta /usr/sap/trans/bin, en
el servidor y directorio adecuado dependiendo del sistema operativo:
En sistemas UNIX, este directorio del transporte debera estar
compartido via NFS para todos los entornos que conforman la ruta del
transporte. Es por ello por lo que podremos acceder a este path desde
cualquier servidor al que nos conectemos desde el sistema operativo
(por ejemplo via telnet).
132
En sistemas Windows NT, esta directorio de transporte debera estar

configurado como compartido para que desde todos los entornos
este disponible, sin embargo solo sera local para uno de ellos.
Accederemos a traves del emulador MSDOS en el servidor donde la
ruta es local.
Presentamos a continuacion la estructura en arbol del sistema operativo
UNIX que es necesaria para el transporte y explicaremos para que sirve cada
directorio:
/usr/sap/trans/bin
/usr/sap/trans/data
/usr/sap/trans/cofiles
/usr/sap/trans/log
/usr/sap/trans/buffer
Directorio desde donde se lanza el programa

de control del transporte, tp.
Directorio donde se almacenan los ficheros
data generados en la exportacion de datos
desde la base de datos que se realiza durante
la liberacion de una orden.
Directorio donde se almacenan los ficheros
cofiles generados en la exportacion de datos
desde la base de datos que se realiza durante
la liberacion de una orden.
Directorio donde se almacenan en ficheros los
logs de cada una de las ordenes de transporte
que se importan al sistema destino.
Directorio donde se almacena un listado con
todas y cada una de las ordenes de transporte
que han sido liberadas desde el sistema origen.
Antes de poder importar al sistema destino, el
programa de control del transporte chequea
que la orden solicitada se encuentra en el
listado mencionado y que esta todava sin
transportar; si es as, se ejecuta el transporte
al sistema destino. Las ordenes, por defecto,
al ser liberadas son a
nadidas al bufferpor lo
que no sera necesario incluir ninguna orden
en este listado a no ser que expresamente
hayamos eliminado su entrada de dicho listado
o que la orden ya haya sido transportada y
queramos volver a ejecutar su transporte.
Veamos a continuacion como deberemos usar el programa de control para

gestionar el transporte de las ordenes ejecutandolo desde el directorio bin

133
mencionado antes:
tp showbuffer <SID>
Nos muestra el listado de ordenes includas en el buffer. En lo que sigue,
<SID> se refiere al nombre del sistema destino del tranporte. Las ordenes que
ya han sido transportadas al sistema destino aparecen con el texto already
imported.
Figura 11.8: Listado de ordenes transportadas y liberadas
Todas las ejecuciones del comando tp, independientemente del argumento

asociado, devuelven un codigo de retorno cuyos valores pueden ser:
0 Operacion ejecutada con exito
4 Operacion ejecutada con advertencias
8 Operacion ejecutada con errores.
Un valor mayor que 8 tambien indicara que la operacion no se ha realizado
con exito.
tp delfrombuffer <orden> <SID>
134
Elimina del listado del directorio buffer la referencia a la orden de

transporte seleccionada. No borra la orden fsicamente, pero impide que se
pueda transportar esa orden.
tp addtobuffer <orden> <SID>
A
nade la orden seleccionada al buffer, dejando la orden preparada para
ser transportada. Esta operacion, por defecto, no es necesario ejecutarla a
no ser que una orden sea eliminada con el comando anterior y deseemos
posteriormente transportarla.
tp import <orden> <SID>
Importa al sistema destino la orden seleccionada, y lo hace en el
mandante cuyo nombre es el mismo que en el sistema origen. Si el mandante
destino de la orden no coincide con el mandante origen de la orden,
se debera obligatoriamente especificar el mandante destino con la opcion
client=<mandante destino> a
nadida despues del <SID>.
Figura 11.9: Transporte de una orden a un sistema destino
tp import all <SID>

Importa al sistema destino especificado todas las ordenes que hayan
sido liberadas y que, por tanto, se encuentran en el buffer. Las ordenes
son importadas por orden de aparicion en buffer, por lo que primero se
transportaran las ordenes que han sido liberadas primero. Si el mandante

135
destino no coincide con el origen, se debera usar la opcion especificada en el

caso anterior.
No se recomienda el uso de esta opcion ya que podemos desear importar
al sistema destino en un orden distinto al que han sido liberadas las ordenes
que se encuentran en el buffer, y este comando tiene un orden de transporte
preestablecido.
tp import <orden> <SID> client=<nnn> u1
La opcion u1 es el modo incondicional de sobreescritura. Habra que
especificarlo obligatoriamente si deseamos transportar al sistema destino una
segunda vez una orden. Esto es as porque el sistema chequea que la orden ya
ha sido transportada previamente y no vuelve a ejecutar la importacion. Para
obligarle a sobrescribir la misma orden que se ha transportado previamente,
sera necesario especificar la opcion u1.
Figura 11.10: Esquema ejemplo del transporte de una orden

Veamos a continuacion un ejemplo. Supongamos un sistema de desarrollo
D10 en un servidor NT llamado devsap10 y un sistema de produccion P10
en otro servidor NT llamado prodsap10. En ambos entornos esta establecida
la ruta del transporte D10 P10 a traves de la clase de desarrollo ZDEV.
Estableceremos el directorio de transporte C:\usr\sap\trans localmente en
el servidor de produccion, prodsap10.
136
Supongamos que creamos en el mandante 101 de D10 un programa

ZREPORT que queremos pasar al mandante 110 de produccion. Al crearlo,
le asignaremos la clase de desarrollo ZDEV y el sistema nos propondra un
codigo para su orden de transporte, por ejemplo D10K902010.
Al liberar esta orden, el sistema de desarrollo se conecta a :
\\prodsap10\usr\sap\trans
para crear en los subdirectorios data y cofiles los ficheros D902010.D10
y K902010.D10 correspondientemente. Abriendo una ventana de MSDOS en
el sistema de produccion, sistema destino del transporte, ejecutamos:
C:\usr\sap\trans\bin\tp showbuffer P10
para comprobar que la orden D10K902010 se encuentra en el buffer; si
acaba de ser liberada, aparecera la u
ltima del listado. Una vez comprobado
que la orden se encuentra en el buffer del sistema de produccion ejecutaremos
el transporte al mandante 110. Como el mandante destino y origen no
coinciden deberemos usar la opcion client=<SID>.
C:\usr\sap\trans\bin\tp import D10K902010 P10 client=110
Una vez que este comando ejecute la importacion y su codigo de retorno
sea 0, el programa ZREPORT estara disponible en el sistema de produccion.
11.7.
Log del transporte
Existe dentro del sistema SAP R/3 una herramienta que nos proporciona
mucha mas informacion sobre el transporte de una orden que el simple
codigo de retorno devuelto por el comando tp. Tal codigo de retorno nos
informa si el transporte se ha ejecutado correctamente, o si por el contrario ha
ocurrido alg
un problema; sin embargo no nos informa que tipo de problema
ha ocurrido. La herramienta del log del transporte esta disponible tanto en la
transaccion SE09 como en la SE10. Podemos pulsar el boton de visualizacion
individual aparece asociado a un icono de gafas en la barra de aplicaciones
si conocemos el n
umero de orden cuyo log queremos consultar:
Tambien podemos rellenar los parametros de seleccion explicados en la
seccion del WBO y CO para, posteriormente, buscar la orden en el listado
que nos aparezca en pantalla y una vez posicionado el cursor sobre la orden
deseada, pulsar la opcion log del transporte asociado a una hoja y gafas
dentro de la barra de aplicaciones.
11.7. LOG DEL TRANSPORTE
137
Figura 11.11: Visualizacion individual de ordenes
Figura 11.12: Log del transporte de una orden
Las dos opciones nos llevan a la misma pantalla. En ella, podemos ver
desde que sistema se ha producido el export as como el import en el sistema
destino con cada uno de sus pasos.
La importacion se realiza en varios pasos, dependiendo su n
umero del
tipo de objeto a transportar. Desglosando la estructura en arbol del log
podemos obtener distintos niveles de informacion, cada vez mas detallados.
Una vez que hemos visto en que paso del transporte se ha producido un error,
haremos doble click sobre esa lnea para acceder a un listado completo del
log en ese paso. Esto nos sirve para saber por que razon se ha producido un
error en el transporte y como habra que resolverlo. Los errores mas comunes
son de informacion incompleta en el sistema destino para poder activar las
modificaciones recien transportadas.
Un ejemplo puede ser que el codigo fuente de un programa que
queramos transportar al sistema destino del transporte haga referencia a
una tabla cuya definicion se encuentra en otra orden de transporte, todava
sin transportar. Si transportamos primero la orden del codigo fuente, la
importacion fallara devolviendo un codigo de retorno 8. Si visualizamos el
138
log del transporte de dicha orden veremos que el paso que ha fallado ha sido
la generacion del codigo fuente por hacer referencia a una tabla que todava
no existe en el sistema destino. Lo que deberemos hacer sera, pasar la orden
donde se encuentra la definicion de la tabla a la que se hace referencia en el
programa y, posteriormente, transportar de nuevo la orden que ha fallado
primero deberemos a
nadirla manualmente de nuevo al buffer .
Captulo 12
Gesti
on de mandantes
Como ya se vio en el captulo 2, los datos en la base de datos de SAP R/3
se dividen en dependientes de mandante y en independientes de mandante.
Un mandante es una unidad contable de negocio independiente que
incluye, ademas una hoja de balance tambien independiente. La implementacion del modelo de empresa basado en los requerimientos de la empresa
se conocen como customizing o parametrizacion. El customizing, dependiendo del tipo de datos a los que afecte, se puede dividir en dependiente o en
independiente de mandante.
Tambien vimos en el captulo 2 que un usuario, para trabajar con SAP
R/3, necesita conectarse a un mandante y lo que ello significaba. En este
captulo vamos a profundizar en el concepto, caractersticas y mantenimiento
de los mandantes en un sistema SAP R/3.
El sistema SAP R/3, cuando es instalado en los servidores, viene provisto
con mandantes estandar, es decir preconfigurados. Los mandantes estandar
son el 000, 001 y 066. En sistemas SAP R/3 destinados a la formacion y
educacion cuyo nombre es IDES existe ademas de los anteriores el mandante
800. Estos mandantes se distinguen principalmente de los anteriores por
estar ya parametrizados, es decir por tener implementados en cada uno de
los mandantes la modelizacion de una o varias empresas modelo ademas de
incluir datos de las actividades de negocio de cada una de las empresas.
Estos mandantes vienen provistos con unos usuarios estandar con
autorizacion global, es decir, sin restricciones, que en general, no deberan
ser usados para conectarse al sistema salvo por el administrador y que sea
estrictamente necesario. Estos usuarios son SAP* , DDIC y EARLYWATCH
(este u
ltimo solo existe en el mandante 066) .
139
140
12.1.
DE MANDANTES
Creaci
on de un nuevo mandante
Los mandantes estandar bajo ning

un concepto deberan ser usados como el
mandante de trabajo de la empresa. Estos mandantes, deberan permanecer en
el sistema sin ser modificados ni borrados y sin que se creen nuevos usuarios,
a excepcion del administrador del sistema, para que se conecten a ellos.
Es por ello, por lo que una de las primeras tareas del administrador
sera la creacion de un nuevo mandante cuyo destino final puede ser de test,
de produccion, de integracion. . . dependiendo del sistema SAP R/3 con el
que estemos tratando y de los requerimientos de la empresa.
La creacion de un nuevo mandante, en general, se realizara como copia
de uno ya existente. Se hara copia del 000 si se quiere partir de cero o
copia de alguno ya existente si ya hemos creado alguno previamente, se han
introducido datos en el y necesitamos una copia de el con datos incluidos.
Las copias de mandante pueden ser Locales (los mandantes fuente y
origen pertenecen al mismo sistema), Remotas (los mandantes fuente y origen
pertenecen a sistemas distintos), o a traves de un export de mandante (la
informacion del mandante se exporta a fichero por medio de ordenes de
transporte).
Cuando el sistema origen y el destino sean diferentes se debera tener
cuidado de copiar mandantes solo entre sistemas SAP R/3 que dispongan de
la misma version de SAP R/3, de otra manera una copia de mandante puede
dejar inconsistente por completo el sistema destino.
Un mandante es creado en dos pasos. El primer paso permite que el
nuevo mandante sea reconocido por el sistema, dandose de alta, ademas,
importantes parametros basicos. El segundo paso (descrito en la siguiente
seccion) llena el mandante de datos; solo despues de este paso el mandante
estara plenamente operativo.
El primer paso consiste, realmente, en dar de alta el mandante en la
tabla T000, que es la tabla donde estan referenciados todos los mandantes
activos en el sistema. Este alta en la tabla T000 se realiza a traves de la
transaccion SCC4 o a traves del men
u general Herramientas Gestion
Gestion Gestion de Mandantes Actualizar Mandantes .
A esta pantalla entraremos por defecto en modo visualizar. La informacion presentada es la de la tabla T000. Pulsando el boton que cambia a modo
modificar, tendremos la opcion de crear una nueva entrada; el primer campo
corresponde al codigo del mandante que vayamos a crear; el segundo campo
corresponde a una peque
na descripcion del mandante, el tercero a la ciudad
asociada a la empresa que va a usar ese mandante, as como la moneda basica
de la empresa que va a usar ese mandante.
Los siguientes datos a rellenar se refieren al papel del mandante, opciones
DE UN NUEVO MANDANTE
12.1. CREACION
141
Figura 12.1: Pantalla principal de la gestion de mandantes
de modificacion para objetos dependientes e independientes de mandante,

nivel de proteccion y restricciones.
Papel del mandante Cuando creamos un mandante deberemos asignarle
un papel, es decir un proposito o funcion para lo que se va a utilizar.
Los valores posibles son produccion , test , customizing , presentacion
, formacion o referencia SAP .
Modificaciones y transportes de objetos dependientes de mandante
Dependiendo del papel que tome el mandante puede llegar a ser necesaria la activacion o desactivacion del transporte para ese mandante en
concreto. Para mandantes productivos es aconsejable protegerlos contra cambios en el sistema; para mandantes de customizing todos los
cambios realizados deberan ser registrados en ordenes de transporte
para su posterior paso al mandante productivo. Veamos las distintas
opciones:
Modificaciones sin grabaci
on autom
atica No pide orden de
transporte al modificar el customizing. Sin embargo permite asignar ordenes de transporte manualmente. Para mandantes de formacion y test.
142
DE MANDANTES
Figura 12.2: Detalle de opciones de un mandante
DE UN NUEVO MANDANTE
12.1. CREACION
143
Grabaci
on autom
atica de modificaciones Al modificar customizing el sistema pide ordenes de transporte. Para mandantes de desarrollo.
No se permiten modificaciones No se permite modificar customizing. Permite asignar ordenes de transporte manualmente.
Opcion mas usada para mandantes de sistemas productivos.
No se permiten transportes Se permite modificar el customizing
pero las modificaciones no se registran automaticamente en
ordenes de transporte. Tampoco se permite la asignacion manual
a ordenes de transporte. Opcion mas usada para mandantes de
sistemas productivos
Modificaciones objetos independiente mandante Se puede limitar el
alcance de las modificaciones permitidas en el mandante. Las opciones
son:
Se permite modificar repository y customizing indep.mandante
Opcion mas usada para mandantes en sistemas de desarrollo o
pruebas donde sepamos que las modificaciones independientes de
mandante no afectaran negativamente al funcionamiento del sistema.
No modificaci
on de objetos customizing independ.de mandante
Las modificaciones del customizing que afectan a tablas independientes de mandante afectan a todo el sistema. En ciertos sistemas
no productivos con diversos mandantes donde se han realizado
tareas de customizing antagonicas, se debera usar esta opcion.
No modificaci
on de objetos repository Impide modificar objetos
standard del repository (tablas, programas, pantallas, etc...) y la
creacion de nuevos objetos de desarrollo.
No modif.de objetos repository y customizing indep.mandante
Opcion mas usada en mandantes de sistemas de productivo. Con
esta opcion se desactiva la posibilidad de modificar objetos standard de SAP (tablas, programas, etc. . . ) y la posibilidad de modificar opciones de customizing globales que afecten a todos los
mandantes.
Protecci
on Se pueden proteger mandantes de una copia de mandante o
de comparacion (existen herramientas que nos permiten comparar los
datos de distintos mandantes). Es importante tener los mandantes
DE MANDANTES
144
productivos protegidos contra copias intencionadas o no de

mandante. Veamos los distintos niveles de proteccion:
Nivel Protecci
on 0: No hay restricciones En este nivel no existe
proteccion .
Nivel Protecci
on 1: No se permite sobrescritura En este nivel
se protege contra copia de mandante. El mandante as protegido
no podra ser sobrescrito por una copia de mandante.
Nivel Protecci
on 2: No se permite sobrescritura ni comparaci
on
Este nivel ademas de proteger contra copia de mandante protege
contra la herramienta de comparacion. Esta opcion sera especialmente necesaria para mandantes productivos donde la informacion
all contenida es especialmente confidencial y donde se deberan
cumplir todos los requerimientos impuestos por las leyes oficiales
de proteccion de datos.
Restricciones Por u
ltimo podremos restringir el uso de herramientas CATT
o incluso proteger el mandante contra un upgrade - cambio de version
-. Las opciones son:
Inicio de procesos CATT permitido CATT proviene de Computer Aided Test Tool. Engloba un grupo de programas usados por
SAP para el chequeo del funcionamiento del sistema.
Protecci
on contra upgrade Si un mandante es protegido contra
upgrade, los datos dependientes de mandante en el no podran
ser modificados.
Esto compone lo que es el primer paso en la creacion de un mandante.
El segundo paso sera el llenado del nuevo mandante de datos a partir de un
mandante ya existente a traves de uno de los siguientes procesos:
Copia local
Copia remota
Transporte de mandante
12.2. COPIA LOCAL DE MANDANTE
12.2.
145
Copia local de mandante
Una vez completado el primer paso de la creacion de mandante, veamos

los pasos a seguir en el caso de que se quiera copiar con los datos de otro
mandante ya existente en el mismo sistema, es decir, lo que se llama una
copia local.
Deberemos entrar en el nuevo mandante creado como se ha explicado
en la seccion anterior. El u
nico usuario disponible en un mandante recien
creado y sin ning
un tipo de datos es el usuario SAP* con password PASS.
Este usuario esta disponible siempre en SAP ya que as se ha programado
el kernel. La password PASS solo esta activa en mandantes recien creados
o si en un mandante estandar o ya creado y con datos propios eliminamos
del maestro de usuarios el usuario SAP*; esta eliminacion del superusuario
SAP* no es sino una simple reinicializacion del usuario. Esto permite poder
acceder siempre a un mandante aunque por error se hayan eliminado todos
sus usuarios.
Una vez conectados al nuevo mandante recordemos que no estara plenamente operativo hasta que el la copia de datos se finalice deberemos acceder
a la opcion de Copia Local disponible en la transaccion SCCL o alternativamente Herramientas Gestion Gestion Gestion de Mandantes Copia
Mandante Copia Local.
Figura 12.3: Copia local de un mandante
En esta pantalla el mandante destino es el mandante al que nos hemos

conectado; deberemos elegir un perfil de copia, el mandante origen de copia
146
DE MANDANTES
de datos, el mandante origen de copia de datos de maestros de usuario y

si el proceso corre en modo test o real. El sistema permite elegir distintos
mandantes origen para copiar los usuarios y el resto de datos porque nos
puede llegar a interesar crear un mandante con los datos de uno pero con los
usuarios definidos en otro.
Si no estamos seguros de si el tama
no actual de nuestra base de datos
soportara el aumento debido a la creacion de un nuevo mandante deberemos
lanzar el proceso en modo test y comprobar en el log si tenemos suficiente
espacio libre en la base de datos o si por el contrario debemos aumentarla
como paso previo a una copia de mandante. Si no realizamos el proceso en
modo test y la copia se cancela por falta de espacio, no solo tendremos un
mandante creado a medias sino que ademas sera imposible seguir trabajando
en todo el sistema hasta que la base de datos sea extendida.
Los datos a copiar se establecen en los llamados Perfiles de Copia.
Al realizar la copia local se debe elegir un perfil de copia, con lo que
implcitamente se estara indicando el tipo de datos a copiar. Podremos
crear nuevos perfiles de copia a partir de los ya existentes. Para visualizar
el contenido de cada perfil desde la transaccion SCCL acudiremos al
men
u desplegable a la opcion Perfil Visualizar Perfil .
En ellos basicamente se puede elegir los datos a copiar que pueden ser
el maestro de usuarios, los datos de customizing , los datos de aplicaciones
, las variantes de reports y la validez (para todo tipo de copias, solo copias
locales, solo copias remotas, solo para export de mandantes ).
Una vez elegido el perfil lo u
nico que deberemos hacer es pulsar el boton
ejecutar o ejecutar en fondo. La opcion ejecutar realiza el proceso de copia en
dialogo con lo que el sistema no nos devuelve el control de nuestra sesion hasta
que termine el proceso de copia. Esta opcion es totalmente desaconsejable
porque la copia tarda mucho tiempo. Se recomienda usar siempre la opcion
ejecutar en fondo y programar la copia para una hora en la que sepamos que
la actividad del sistema va a ser nula o mnima.
Una vez lanzada la copia de mandante podremos acceder al log de la copia
a traves de la transaccion SCC3 o alternativamente por el men
u desplegable
Herramientas Gestion Gestion Gestion de Mandantes Logs de
Copia. En este log podremos ver el tanto por ciento de proceso de copia
ejecutado.
La copia de mandante consiste realmente en un proceso en el que
se accede alfabeticamente tabla a tabla para copiar los registros que
pertenecen al mandante origen en otros tantos registros cuyo mandante
sera el mandante destino de la copia. El tiempo que consuma el proceso
de copia dependera fundamentalmente de los recursos del sistema, los datos
elegidos a copiar en el perfil de copia, y el n
umero de registros de los
12.2. COPIA LOCAL DE MANDANTE
Figura 12.4: Detalle de un perfil de copia
147
148
DE MANDANTES
que se componga el mandante origen. Se debera tener en cuenta todo esto

para dimensionar los tablespaces o devices dependiendo del RDBMS
adecuadamente y evitar un llenado de ellos que provoque una cancelacion de
la copia.
Se debe recalcar que este proceso es muy crtico y extremadamente
sensible a la carga de trabajo del sistema, ya que consume muchos recursos.
En el momento de la ejecucion de la copia no debe haber ning
un usuario
conectado al mandante origen ni al destino y tampoco debe haber ning
un
proceso batch corriendo aparte del propio proceso de copia. De otra manera
se podra provocar una cancelacion en el proceso de copia.
12.3.
Copia remota de mandante
Cada sistema R/3 tiene claramente definidas sus tareas; as por ejemplo,
desarrollo y produccion deben estar en sistemas claramente separados. Para
poder realizar una copia de mandantes entre sistemas distintos existe la
herramienta de la copia remota. Debido a que los datos deben pasar a traves
de la red, una copia remota es mucho mas lenta que una copia local.
La transaccion de copia remota es SCC9 que puede ser accedida
por el men
u desplegable Herramientas Gestion Gestion Gestion de
Mandantes Copia de mandante Copia remota.
Figura 12.5: Copia remota de un mandante
12.4. TRANSPORTE DE MANDANTE
149
A diferencia de la copia local, en la copia remota exclusivamente se

debera indicar un destino fuente como origen de la copia. Este destino fuente
sera realmente una conexion RFC, necesaria para que ambos sistemas , fuente
y destino se puedan comunicar para el traspaso de datos. En la definicion de
este sistema logico estara incluido el sistema origen y el mandante origen. Por
las mismas razones que en la seccion de copia local se recomienda siempre
lanzar este proceso de copia en fondo.
El sistema, igual que en la copia local, bloquea los mandantes origen y
destino impidiendo que los usuarios se conecten, pero los usuarios conectados
previamente no seran desconectados. Sera tarea del administrador lanzar la
copia cuando no haya ninguna conexion al sistema o cancelar las conexiones
ya existentes.
En la copia remota, solo se copian datos de tablas no las definiciones de
tablas. Si se crearon tablas nuevas en el mandante origen cuyas definiciones
no fueron transportadas, estas tablas no son pasadas en el proceso de copia.
Se debera proceder a transportar todas las tablas nuevas que no se encuentran
en el sistema destino antes de realizar la copia remota.
12.4.
Transporte de mandante
Con esta herramienta los datos no son copiados directamente al mandante

destino sino que, a traves del programa de control de transporte tp, se realiza
un export del mandante consistente en la exportacion a fichero de toda la
informacion a copiar. El export genera tres ordenes de transporte, una orden
para los datos independientes de mandante, otra para los dependientes y otra
para los textos especficos.
Otra diferencia importante con respecto a la copia remota es que el
sistema destino no tiene por que ser accesible desde el sistema origen , como
ocurra en la copia remota. Aunque el sistema destino, en este caso, no tiene
por que ser distinto del origen, este metodo se recomienda solo para el caso de
copia a un sistema destino diferente del origen ya que para copiar mandantes
dentro de un mismo sistema disponemos de la copia local que consume menos
tiempo.
Accederemos a esta herramienta en la transaccion SCC8 o a traves
del men
u desplegable Herramientas Gestion Gestion Gestion de
Mandantes Transporte de Mandante Export de Mandante.
En este caso, igual que en los anteriores, se debera elegir un perfil de copia,
y se podra elegir entre ejecucion real o de test as como un lanzamiento del
proceso de exportacion en dialogo o background. Por las mismas razones que
en las dos secciones anteriores se debera elegir la ejecucion en background.
150
DE MANDANTES
Figura 12.6: Export de mandante
El sistema nos mostrara a continuacion una ventana de dialogo

informandonos de las tres ordenes de transporte que se van a generar:
Orden generada con datos indep. de mandante:
Orden generada con datos dep. de mandante:
Orden generada con los textos especficos:
<SID>KO(No secuencial)
<SID>KT(No secuencial)
<SID>SX(No secuencial)
Este proceso de exportacion de mandante tambien queda registrado en

el log de copia, en la transaccion SCC3. La creacion de estas 3 ordenes de
transporte lleva asociada la creacion de ficheros a nivel de sistema operativo,
con lo que tendremos como limitacion de espacio para esas ordenes el asignado
a la unidad donde este establecido el directorio de transportes en entornos
Windows , o el asignado al file system correspondiente en entornos UNIX
. Deberemos recordar que la exportacion de mandante puede llegar a crear
ficheros de gran tama
no, dependiendo de la informacion asociada al mandante
a exportar; por lo que un llenado del file system o de la unidad de disco
asignada causara una cancelacion del proceso de exportacion.
Una vez creadas satisfactoriamente las ordenes de transporte lo u
nico que
restara sera importar (como se vio en el captulo 11) en el sistema destino
primero la orden asociada a los datos independiente de mandante, y despues
la orden asociada a los datos dependientes de mandante con el programa de
control de transporte tp.
Como tercer paso deberemos importar los textos especficos conectandonos
12.4. TRANSPORTE DE MANDANTE
151
al sistema destino y accediendo a Herramientas Gestion Gestion

Gestion de Mandantes Transporte de Mandante Trabajo Repaso Import. Introduciremos la orden de los textos especficos y pulsaremos ejecutar
en dialogo o background.
Captulo 13
Mantenimiento de instancias
13.1.
Perfiles del sistema
El sistema SAP R/3 dispone de unos parametros de configuracion

necesarios para el arranque y funcionamiento de sus instancias. En
este captulo veremos como gestionar tales parametros para optimizar el
funcionamiento del sistema R/3. Tales parametros nos permitiran configurar
tama
no de bufferes, idioma de conexion por defecto, mandante de conexion
por defecto, tiempo de expiracion de passwords, n
umero intentos fallidos de
conexion para bloquear usuario, etc. . .
13.1.1.
Mantenimiento de perfiles del sistema
Los parametros activos se mantienen desde los Perfiles del Sistema. Estos
perfiles son realmente 3 ficheros a nivel de sistema operativo donde se guarda
toda la informacion tecnica del sistema R/3:
1. Perfil de Inicio: El nombre es Start <n
umero instancia> <nombre
m
aquina>. Es un perfil u
nico por instancia del sistema R/3 que contiene
parametros necesarios para el arranque de SAP en los servidores que
componen el sistema.
2. Perfil por Defecto: El nombre es DEFAULT. Es un perfil u
nico por sistema
R/3 que contiene parametros globales para todo el sistema.
3. Perfil de Instancia: El nombre es <SID> <n
umero instancia> <nombre
de m
aquina> y es un perfil u
nico por instancia del sistema R/3 con
parametros especficos de cada instancia.
153
CAPITULO 13. MANTENIMIENTO DE INSTANCIAS
154
Estos tres perfiles estan almacenados a nivel de sistema operativo en tres

ficheros con los nombres especificados anteriormente en el siguiente path de
la instancia central:
\usr\sap\<SID>\SYS\profile\
donde <SID> es el System Identification, es decir, el nombre de la base de
datos del sistema R/3 que esta compuesto de tres caracteres y que se establece
en tiempo de instalacion del sistema en los servidores.
Ejemplo: Supongamos un sistema R/3 compuesto de 2 instancias; una
instancia central y otra de aplicaciones, cada una de ellas en una maquina
distinta. Supongamos que tenemos la siguiente configuracion:
Nombre base de datos SAP (SID): P11
Nombre maquina de la instancia central: servr001
Identificador instancia central: 00(este valor de identificador para la
instancia se establece en tiempo de instalacion y no se puede cambiar)
Nombre maquina de la instancia de aplicaciones: servr002
Identificador instancia aplicaciones: 10
Los perfiles del sistema seran, en este caso, cinco: un u
nico perfil por
defecto y dos perfiles de inicio y de instancia por cada una de las instancias
que componen nuestro sistema:
Perfil
Perfil
Perfil
Perfil
Perfil
por defecto:
DEFAULT
inicio instancia central:
START DVEMGS00 servr001
instancia insta. central:
P11 DVEBMGS00 servr001
inicio instancia aplicacl: START D10 servr002
de instancia insta. aplic.: P11 D10 servr001
Hay una herramienta en SAP para gestionar el mantenimiento de estos

perfiles sin tener que bajar a nivel de sistema operativo. Esta herramienta se
encuentra en la transaccion RZ10, accesible por el men
u desplegable desde
Herramientas CCMS ConfiguracionActualizar Perfiles.
En esta transaccion existen 3 niveles de gestion de perfiles, en cada uno
de los niveles se muestra distinto tipo de informacion:
Datos de gestion. En este nivel se mantiene el path completo del fichero a
nivel de sistema operativo, as como fechas de modificacion y activacion
del perfil en cuestion y autor de dicha modificacion y activacion.
13.1. PERFILES DEL SISTEMA
Figura 13.1: Pantalla pricipal perfiles del sistema
Figura 13.2: Datos de gestion de un perfil
155
156
Actualizacion basica . En este nivel no se permite introducir ning

un
parametro nuevo, solo modificacion de los parametros basicos que
componen el perfil.
Este nivel es especialmente importante en el caso del perfil de instancia
ya que permite, de una manera muy sencilla y segura, cambiar los
parametros relativos a los bufferes y al n
umero de colas de trabajo.
Sera este el perfil que debamos modificar si deseamos que una instancia
o varias tengan una distribucion distinta de sus colas de trabajo.
Figura 13.3: Actualizacion basica de un perfil
Actualizacion ampliada . En este nivel se permite la visualizacion o

modificacion de todos los parametros activos en el perfil seleccionado,
as como la introduccion de nuevos parametros. Algunos parametros
tienen documentacion asociada en este nivel que puede ser visualizada
pulsando F1 sobre el parametro deseado.
13.1. PERFILES DEL SISTEMA
157
Figura 13.4: Actualizacion ampliada de un perfil
13.1.2.
Importaci
on de perfiles del sistema
La primera vez que se accede a esta herramienta desde que se instala

el sistema SAP R/3, los perfiles no se encuentran disponibles desde SAP;
existen solo a nivel de sistema operativo por lo que sera necesario importar
dichos perfiles para que se puedan mantener desde dentro del sistema. A
esta herramienta de importacion se accede desde la RZ10 en la opcion del
men
u desplegable UtilidadesImportar Perfil De servidores Activos.
Una vez que ejecutemos la importacion de los perfiles desde el sistema
operativo, los tendremos disponibles en la transaccion RZ10. Pulsando
la ayuda de b
usqueda correspondiente al campo Perfil, el sistema nos
mostrara en un listado los perfiles importados.
158
13.1.3.
Visualizaci
on todos los par
ametros activos
Existen mas parametros tecnicos de configuracion SAP que los que

aparecen en los perfiles antes indicados. Se pueden ver todos los parametros
activos en SAP ejecutando el programa RSPARAM desde la transaccion
SE38 (editor ABAP/4). Si un parametro no aparece en ninguno de los tres
perfiles del sistema no quiere decir que no exista, ya que puede encontrarse
activo en el sistema pero no aparecer en ninguno de los tres perfiles por
tener asociado su valor por defecto. Para saber si un parametro determinado
esta activo en el sistema deberemos ejecutar el programa antes mencionado
y comprobar si aparece en el listado. Si no aparece, esto significara que el
parametro no esta activo en el sistema.
Si deseamos modificar un parametro al que solo se puede acceder a traves
de la ejecucion del programa RSPARAM, deberemos proceder incluyendolo
como un parametro nuevo en cualquiera de los perfiles existentes. Si es un
parametro que debe tener un valor distinto por cada instancia o que solo
se debe activar en determinadas instancias de nuestro sistema, deberemos
incluirlo en el perfil de instancia de las instancias adecuadas; si el parametro
es global para todo el sistema R/3 deberemos incluirlo una u
nica vez en el
perfil por defecto (otra posibilidad menos recomendada es que se incluya en
cada uno de los perfiles de instancia de las instancias que conforman nuestro
sistema SAP R/3).
Importante: Cualquier modificacion sobre cualquiera de los perfiles de
inicio y de instancia bien sea en la modificacion del valor de un parametro
o en la inclusion de un nuevo parametro no toman efecto hasta que la
instancia en cuestion sea reiniciada. Cualquier modificacion sobre el perfil por
defecto no toma efecto hasta que el sistema R/3 al completo es reiniciado.
Este hecho es avisado por el sistema R/3 cada vez que se procede a la
modificacion de cualquiera de sus tres perfiles a traves de una ventana de
dialogo.
La modificacion de los perfiles del sistema requiere de un paso mas ademas
de la grabacion en s de las modificaciones; este paso es la Activaci
on del
perfil. El concepto de activacion o generacion se encuentra presente en muchas
de las aplicaciones de SAP como puede ser el mantenimiento de perfiles y
autorizaciones de usuario, programacion o mantenimiento de tablas, etc. . . La
grabacion de una modificacion de tales objetos supone la creacion de una
nueva version de ese objeto a nivel de SAP R/3 pero el sistema no la toma
como la actual. La activacion o generacion de ese objeto supone, en algunos
casos como los programas y tablas, la modificacion real de ese objeto en la
base de datos o la modificacion real a nivel de sistema operativo como es el
caso de la activacion de los perfiles del sistema.

13.2. MODOS DE OPERACION
13.1.4.
159
Par
ametros m
as importantes de un sistema
R/3
Debido al gran n
umero de parametros existentes en un sistema R/3 es
practicamente imposible conocer a fondo todos ellos, sin embargo existen
varios que, por su importancia en procesos basicos de administracion, toman
un papel muy importante. A continuacion listamos algunos de los parametros
mas importantes.
Nombre parametro
Valor de ejemplo Descripcion
SAPSYSTEMNAME
INSTANCE NAME
SAPSYSTEM
SAPGLOBALHOST
rdisp/wp no dia
rdisp/wp no vb
rdisp/wp no vb2
rdisp/wp no enq
rdisp/wp no btc
rdisp/wp no spo
zcsa/installed languages
US1
DVEBMGS00
00
uisabl4
6
2
1
1
2
1
DES
zcsa/system language
login/system client
S
800
13.2.
Nombre de la base de datos

Nombre instancia
N
umero de instancia
Nombre del servidor
N
umero colas de dialogo
N
umero colas de update
N
umero colas de update2
N
umero colas de enqueue
N
umero colas de batch
N
umero colas de spool
Idiomas instalados D -aleman, E -ingles- , S -espa
nolidioma por defecto
mandante por defecto
Modos de Operaci
on
En muchos casos sera absolutamente necesario cambiar la configuracion

de las colas de trabajo de nuestro sistema R/3 de una forma periodica
debido a exigencias de operativa de nuestra empresa. Las exigencias mas
comunes son la definicion de mas procesos de trabajo de tipo batch durante
el procesamiento nocturno, que deberan ser minimizadas en cantidad durante
el horario de trabajo de nuestra empresa para dar mas prioridad a los procesos
de dialogo. Esto nos optimizara la ejecucion de jobs de carga o modificacion
masiva de datos que se pueden realizar sin intervencion del usuario durante
la noche. Esta modificacion en el n
umero de procesos de trabajo, si no
dispusieramos de la herramienta de Modos de Operaci
on, nos llevara a tener
que modificar los perfiles de instancia de cada una de las instancias que
conforman nuestro sistema R/3 y reiniciar nuestro sistema cada vez que se
160
quisiera cambiar la configuracion de los procesos de trabajo.

Un Modo de Operaci
on no es mas que el n
umero y tipo de colas de
trabajo de una instancia asignados a un intervalo horario. De esta manera
nos aseguraremos que nuestro sistema R/3 funcione con una configuracion
de procesos determinada durante un intervalo de tiempo, y ademas el
sistema cambiara en modo on line, sin necesidad de parar el sistema, a otra
configuracion cuando llegue la hora de su activacion.
Ejemplo : Supongamos un sistema SAP formado por una u
nica instancia
donde estan configuradas 15 colas de trabajo. Podemos definir dos modos
de operacion: diurno y nocturno. En el modo de operacion diurno daremos
prioridad a los procesos de dialogo definiendo mas procesos DIA mientras
que en el nocturno daremos prioridad a los procesos en fondo definiendo mas
colas BTC .
Modo Diurno activo de las 8.00 am hasta las 8.00 pm
Formado por 7 colas DIA
3 colas BTC
1 cola SPO
1 cola ENQ
2 colas UPD
1 cola UP2
En el modo diurno nos debemos asegurar que el sistema va a poder
gestionar sin problemas las peticiones de los usuarios, las cuales entraran
por los procesos de dialogo; es por ello que las colas DIA deben superar al
resto de colas .
Modo Nocturno activo de las 8.00 pm hasta las 8.00 am
Formado por
3 colas DIA
7 colas BTC
1 cola SPO
1 cola ENQ
2 colas UPD
1 cola UP2
En el modo nocturno no habra ning
un usuario conectado al sistema y nos
deberemos asegurar que el sistema podra gestionar sin problemas todos los
jobs que haya planificados; es por ello que las colas BTC deben superar al
resto de colas. No se debe reducir nunca a cero el n
umero de colas de DIA ya
que hay procesos internos de SAP que necesitan de estas colas y ademas, de
otra forma, no podramos conectarnos al sistema en caso de urgencia ya que

161
las conexiones de los usuarios al sistema se gestionan a traves de procesos

DIA.
13.2.1.
Gesti
on de modos de operaci
on
Para crear modos de operacion deberemos acceder a la transaccion

RZ04, o alternativamente por el men
u desplegable Herramientas CCMS
Configuracion Mod Oper + Servidores .
Figura 13.5: Modos de operacion
En esta pantalla apareceran los modos de operacion definidos en nuestro

sistema como muestra la figura 13.5. Haciendo doble click en cada una
de las entradas o posicionando el cursor en una entrada y pulsando la
opcion Instancias/Form.op accederemos a una pantalla donde aparecen los
siguientes campos:
162
Host
Nombre del servidor a nivel de sistema operativo .

Servidor
Nombre de la instancia instalada en el servidor
anteriormente mencionado .
Perfil Instancia
Nombre del perfil de instancia de la instancia
anteriormente mencionada.
Forma Operacion
Modo de operacion asociados a la instancia.
Procesos de trabajo N
umero y tipo de colas de trabajo de las que se
compone el modo de operacion anteriormente
mencionado. El campo Sum es la suma de
todos los procesos de trabajo, el cual debe ser
el mismo para todos los modos de operacion
definidos en nuestro sistema.
Si deseamos modificar la configuracion de alguno de los modos de
operacion definidos en el sistema, haremos doble click sobre el modo de
operacion deseado con lo que accederemos a la ventana de dialogo de la
figura 13.6 donde podremos, con los botones + , aumentar o disminuir
el n
umero de colas de un tipo determinado:
2
Figura 13.6: Distribucion de procesos de trabajo
La u
nica limitacion que impone esta herramienta es que el total de
procesos no puede cambiar. Si aumentamos el n
umero de colas de dialogo,
posicionandonos en la linea correspondiente y pulsando el boton +, el

163
sistema automaticamente disminuira en la misma cantidad el n

umero de
colas de fondo, y viceversa, si aumentamos en una cantidad el n
umero de
colas de fondo el sistema disminuira en la misma cantidad el n
umero de colas
de dialogo.
Si deseamos aumentar o disminuir el n
umero total de colas de una o varias
instancias, no podremos realizarlo a traves de los modos de operacion, sino
que se debera realizar a traves del mantenimiento de los perfiles de instancia,
con lo que el cambio no se activara realmente hasta que las instancias
modificadas sean reiniciadas de nuevo.
Hasta ahora hemos visto como crear o modificar un modo de operacion,
pero este no se activa realmente hasta que no es asociado a un intervalo
horario. Como u
ltimo paso deberemos asociar los modos definidos a unas
horas determinadas en la transaccion SM63 o a traves del men
u desplegable
Herramientas CCMS Configuracion Planificar Modos Operacion:
Figura 13.7: Pantalla principal asignacion horaria
En esta pantalla tenemos la posibilidad de asociar un modo de operacion,

bien sea normal (diario) o excepcional (valido solo para determinados das),
a un intervalo horario. Elegiremos la opcion modo de operacion normal
y pulsaremos bien visualizar o bien modificar. En la siguiente pantalla
podremos, si hemos elegido modificar, asociar el modo que deseemos a unas
164
horas determinadas.
Figura 13.8: Asignacion horaria a modos de operacion
13.3.
Grupos de logon
En sistemas SAP R/3 con m

ultiples servidores de aplicaciones es
importante distribuir la carga de trabajo tan optimamente como sea posible,
es decir, deberemos evitar a toda costa que unos servidores de aplicaciones
soporten toda la carga de trabajo debido a que un tanto por ciento muy
elevado de los usuarios se hayan conectado a esas instancias y que otros
se encuentren practicamente sin realizar ning
un trabajo debido a un bajo
13.3. GRUPOS DE LOGON
165
n
umero de conexiones de usuario. Para evitar este tipo de problemas que
puede afectar muy negativamente al rendimiento global del sistema se deben
usar los Grupos de Logon.
Un grupo de logon es un subconjunto de servidores de aplicacion
disponibles en nuestro sistema R/3. Cuando los usuarios se conectan al
sistema R/3 deberan elegir uno de los grupos de logon definidos con lo que
la conexion al sistema R/3 se produce exclusivamente a traves de una de
las instancias asociadas a ese grupo. De esta manera, definiendo grupos de
logon para cada una de las areas de aplicacion de SAP que sean usadas por
nuestra empresa, podremos conseguir un optimo balance de carga de trabajo
en los servidores SAP. La definicion de grupos de logon, ademas, nos permite
un rendimiento optimo de los bufferes ya que los usuarios que van a realizar
tareas similares se conectaran por el mismo grupo de logon con lo cual un
tanto por ciento muy elevado de los programas que vayan a ser usados por
un usuario que se acaba de conectar ya se encuentra en los bufferes de dichas
instancias con lo que el acceso a la informacion es mucho mas rapido.
Dependiendo del tama
no y areas de nuestra empresa que trabajen con
SAP deberemos definir uno o varios grupos de logon por cada departamento,
area de trabajo, modulos de SAP, etc . . .
13.3.1.
Gesti
on de grupos de logon
Los grupos de logon se pueden definir en la transaccion SMLG, por el

men
u desplegable Herramientas CCMS Configuracion Grupos Acceso
En esta pantalla aparecen los grupos de logon ya definidos, sus instancias
asociadas y si se encuentran activos o no. Para definir un grupo nuevo
pulsaremos el boton Crear Entrada .
En esta ventana deberemos introducir el nombre descriptivo del grupo,
que en general sera un nombre descriptivo del conjunto de usuarios que lo
vayan a usar; por ejemplo, si creamos un grupo de logon para el departamento
de recursos humanos, lo mas logico sera dar ese mismo nombre al grupo de
logon.
Ademas del nombre descriptivo se debera introducir la instancia por la
que se conectaran los usuarios que entren por ese grupo. Podremos restringir
los accesos a este grupo de logon por direccion IP, por tiempo de respuesta
o por n
umero de usuarios ya conectados. Estas restricciones, si se activan,
permitiran accesos a traves de dicho grupo solo si el servidor de presentacion
se encuentra en el intervalo de direcciones IP includas, o solo si su conexion
a red es de un tiempo de respuesta menor que el especificado o si el n
umero
de usuarios conectados a este grupo no supera el maximo establecido.
Una vez que se han definido los grupos de logon, cada servidor de
166
Figura 13.9: Pantalla principal grupos de logon
presentacion debera tener instalado el programa saplogon.exe, que se instala

con el sapgui. Este programa permite tener un u
nico icono de conexion a
SAP para todos los sistemas SAP y grupos de logon de los que dispongamos.
13.3.2.
Saplogon
A continuacion veremos como se debe usar el programa saplogon incluido

como opcion de instalacion del sapgui. Lo primero que deberemos hacer
es ejecutar el programa que se encontrara dentro del grupo de programas
instalado con el sapgui o SAP Frontend en nuestro PC, como muestra la
figura 13.11.
Los botones Server y Groups sirven para crear iconos de servidores de
aplicaciones y grupos de logon respectivamente para el acceso a uno o varios
sistemas SAP R/3. Como ya se ha explicado anteriormente, los accesos a
traves de iconos de servidores de aplicacion nos conectan a un sistema SAP
por un servidor determinado, mientras que los grupos de logon nos conectan
a traves de uno de los servidores que tenga asociados ese grupo, con lo cual
si un servidor queda indisponible, el grupo de logon elige automaticamente
otro servidor asociado. Esto redunda en una mejor gestion de acceso de los
usuarios.
Para crear en el saplogon tantas entradas como servidores hay en un
167
Figura 13.10: Pantalla detalles creacion grupo logon
sistema, lo u
nico que deberemos hacer es pulsar el boton Server. En la
pantalla que se muestra en la figura 13.12 deberemos elegir el sistema SAP
al que nos queremos conectar.
En el campo ID introduciremos el valor del SID de nuestro sistema y en
message server el servidor donde esta la instancia central. A continuacion
pulsaremos el boton Generate List y entonces el programa se comunica con
el sistema y recupera todas y cada una de las instancias que componen el
sistema SAP.
Si pulsamos el boton Logon, el programa simplemente nos conecta al
sistema indicado a traves del servidor seleccionado, pero no a
nade la entrada
al saplogon. Si pulsamos el boton Add, los servidores seleccionados son
a
nadidos al saplogon.
De manera similar podemos insertar los grupos de logon definidos en
un sistema; pulsando el boton Groups del saplogon e introduciendo los
valores deseados en los campos ID y message server obtendremos un listado
de los grupos de logon definidos en ese sistema en la transaccion SMLG.
Procediendo de igual manera que con la opcion Server, obtendremos el listado
168
Figura 13.11: Pantalla de saplogon
de grupos de logon.
Si a
nadimos todos los servidores y todos los grupos de logon, obtendremos
un saplogon con todos los servidores y grupos de logon definidos en nuestro
sistema.
Por u
ltimo veremos las opciones New, Properties y Delete del saplogon. La
opcion Properties nos permite crear de una manera mas rapida que la opcion
Server una entrada de icono de acceso a traves de un servidor de aplicaciones.
Para ello lo u
nico que deberemos indicar es el nombre del servidor en el campo
Application Server, una descripcion del icono en el campo Description y por
u
ltimo indicar el n
umero de instancia de ese servidor si la instancia es
u
nica, el n
umero sera 00 en el campo System Number.
La opcion Edit edita la entrada seleccionada, ya sea icono de servidor
o de grupo, y por u
ltimo, la opcion Delete elimina la entrada del saplogon
seleccionada.
El programa saplogon, en definitiva, nos facilita la conexion a cualquier
servidor SAP evitando que tengamos el escritorio de nuestro PC plagado de
iconos de acceso a distintos servidores y/o sistemas SAP R/3.
Figura 13.12: Opcion de seleccion servidor en saplogon
Figura 13.13: Opcion propiedades en saplogon
169
Ap
endice A
Transacciones m
as comunes
DB02 Analisis de tablas e Indices
DB14 Mostrar logs actividad SAPDBA
PFCG Generador de perfiles.
RZ01 Monitor para prevision de jobs
RZ02 Grafico grafos de instancias SAP
RZ03 Representacion,Control instancias SAP
RZ04 Actualizar instancias SAP
RZ06 Alerts Thresholds Maintenance
RZ08 Monitor alert SAP
RZ10 Actualizar parametros perfil
RZ11 Actualizacion parametros de perfil
RZ12 Actual.asignacion grupos serv.RFC
SA38 Informes ABAP
SA39 SA38 para transaccion parametros
SAR Actualizar codigos de transaccion
SAR0 Visualizar arbol de informes estand.
SARA Gestion de archivos
171
172
COMUNES
APENDICE
A. TRANSACCIONES MAS
SARL Llamada de ArchiveLink Monitor

SARP Reporting (Estruct.arbol): efectuar
SART Visualizar arbol de informes
SC38 Lanzar report remoto
SC80 CATT Utilities
SCAT Computer Aided Test Tool
SCC1 Copia mandante - seleccion especial
SCC3 Copia mandante Log
SCC4 Gestion mandantes
SCC5 Borrado de mandante
SCC6 Importacion de mandante
SCC7 Import.mandante - tratam.posterior
SCC8 Export mandante
SCC9 Copia mandante remota
SCCL Import.mandante - tratam.posterior
SCMP Comparacion vista/tablas
SCPF Generar gua implem. para la empresa
SCPI Interfase optimizacion de produccion
SCT1 Resumen - Imports logicos
SCU0 Comparac.Customizing
SE01 Transport Organizer
SE03 Workbench Organizer: Herramientas
SE06 Instalar Workbench Organizer
SE07 Visual.status gestion transp
SE09 Workbench Organizer
173
SE10 Customizing Organizer
SE11 Actualizacion Dictionary ABAP
SE13 Param.memoria para actual.tablas
SE14 Utilities para tablas Dictionary
SE15 Sistema Info Dictionary
SE16 Browser de datos
SE17 Visualizar tabla (general)
SE30 Analisis tiempo ejecucion ABAP
SE37 Modulos de funciones ABAP
SE38 Editor ABAP
SE39 Editor Split screen Comp. report
SE41 Menu Painter
SE43 Actualizar men
u de ambito
SE51 Screen Painter
SE54 Generar vista tabla
SE61 Docu R/3
SE63 Acceso Traduccion
SE80 Browser Repository
SE84 Sistema Info Repository
SE85 Sistema Info ABAP/4 Dictionary
SE86 ABAP/4 Sistema Info
SE91 Actualizar mensajes
SE93 Actualizar codigos de transaccion
SEWA Earlywatch Alert
SM0 Resumen de procesos de trabajo
174
COMUNES
APENDICE
A. TRANSACCIONES MAS
SM01 Bloquear transacciones

SM02 Mensajes de sistema
SM04 Lista de usuarios
SM12 Visualizar y borrar bloqueos
SM13 Visualizar registros actualizacion
SM21 Log de sistema
SM30 Llamar actualizacion de vistas
SM31 Actualizar tablas
SM35 Monitoring batch input
SM36 Solicitud para proceso de fondo
SM37 Resumen de jobs de fondo
SM38 Transaccion de gestion queue
SM39 Analisis jobs
SM49 Ejecucion comandos OS externos
SM50 Resumen de procesos de trabajo
SM51 Lista con Sistemas SAP
SM59 Destinos RFC (visualizar y actual.)
SMLI Utilidad para import de idiomas
SMLT Utilidad para transporte de idiomas
SMOD Gestion de ampliaciones SAP
SMX Visualizar jobs propios
ST01 Trace sistema
ST22 ABAP/4 Analisis errores tiempo ejec.
STAT Estadsticas de acceso al sistema
SU01 Actualizacion de usuarios
175
SU01D Visualizar usuarios
SU02 Actualizar perfiles de autorizacion
SU03 Actualizar autorizaciones
SU10 Modificaciones masa Maestros usuario
SU12 Modificaciones masa Maestros usuario
SU20 Actualizar campos de autorizacion
SU21 Actualizar objetos de autorizacion
SU22 Utiliz.obj.autoriz.en transacciones
SU24 Verif.obj.autoriz.bajo transacciones
SU53 Visualizar valores de verificacion
SUIM Llamada arbol report.AUTH (infosist)
SUPC Perfiles para grupos actividad
SUSE Actual.p.Self Upgrading Software
Ap
endice B
Recursos Web
http://www.sap.com
Pagina principal de SAP. La version espa
nola esta en http://www.sap.
com/spain
http://www.sappro.com
Pagina de la editorial Wellesley Information Services que edita la revista
Sap Professional Journal. Se pueden consultar ndices de las revistas
anteriores y solicitar un ejemplar de muestra gratuito para evaluar la
publicacion antes de suscribirse.
http://www.sapfans.com
Excelente web dedicada enteramente a SAP. Tienen foros de usuarios,
chat, artculos, descripciones de los diferentes productos de SAP, etc.
Son especialmente interesantes los foros de discusion abiertos de los
que existe uno por cada modulo de SAP R/3. Se puede descargar
ficheros .zip con el historial de preguntas y respuestas de los foros mas
concurridos.
http://www.erpfans.com
Web de la misma serie que el anterior pero mas general, con referencias
a otros productos ERP como Baan, PeopleSoft, Oracle Financials, etc.
http://www.sapclub.com
Noticias, empleo, foros, test de conocimientos sobre el modulo BASIS,
salvapantallas y fondos de escritorio con SAP como tema principal.
http://www.erpsupersite.com/sap/
Noticias acerca de SAP, catalogos de libros, analisis de implantaciones
en empresas, etc.
177
178
APENDICE
B. RECURSOS WEB
http://www.saplabs.com
Pagina de los diversos laboratorios Technical Core Competence de
SAP que hay en el mundo. Existe un link a cada uno de ellos
y all encontraremos ofertas de empleo, descripciones de los nuevos
proyectos, software para descargar y enlaces a la documentacion del
Simplification Group. Esta documentacion incluye artculos, white
papers e incluso libros completos, todo ello en formato PDF. Es la
mejor documentacion disponible gratuitamente que existe.
http://www.realtimeusa.com/sap-group/archives/
Archivos con los mensajes del grupo de noticias de SAP comp.
soft-sys.business.sap. Es un grupo moderado (por lo menos no
hay que sufrir el spam :-) y el contenido es interesante.
Ap
endice C
Casos reales
C.1.
Autodesk, Inc.
Sector
Autodesk, Inc. centra sus actividades en el desarrollo y venta de productos
de software informatico. Es uno de los principales productores de software
CAD/CAM. Su central se encuentra en San Rafael, California y posee 4
centros de desarrollo en USA y Suiza as como veinte subsidiarias repartidas
por Europa y Asia.
Autodesk se encontraba, antes de la implementacion del sistema SAP
R/3, en una situacion en la que sus sistemas de gestion no se correspondan
con las necesidades de la empresa, razon por la cual se necesitaba un cambio
radical que se ajustara a la situacion de rapido crecimiento y expansion
internacional que estaba experimentando.
El proyecto que se planifico para conseguir tales fines, System 2000, se
baso en cinco objetivos principales:
Globalizacion del software de aplicacion de negocio: Los procesos de
negocio no se deban ver limitados por limitaciones del sistema o por
fronteras geograficas. La informacion deba fluir en tiempo real para
todos los aspectos del negocio.
El nuevo sistema informatico deba ser capaz de soportar todos los
idiomas, operaciones, as como procedimientos de calculo de impuestos
especficos de cada pas en los que Autodesk tena alg
un centro o filial.
Los tiempos de los procesos de negocio se deban ser claramente
reducidos.
Gestion precisa de inventario.
179

APENDICE
C. CASOS REALES
180
Como manufacturador de productos de software para UNIX y

Windows NT, Autodesk insistio en disponer de un sistema abierto
con arquitectura cliente / servidor para la gestion de sus procesos de
negocio.
El producto R/3 de SAP resulto ser el sistema que mejor se ajustaba
a las necesidades de la empresa. Los modulos R/3 de contabilidad
financiera, controlling, gestion de materiales, ventas y distribucion fueron
implementados en los centros americanos en solo 6 meses.
C.2.
Schweppes, S.A.
Sector
Schweppes, S.A. pertenece al grupo Cadbury Schweppes dentro de su
division de bebidas y su actividad radica en la fabricacion y distribucion de
bebidas refrescantes.
Schweppes esta compuesto por una plantilla de mas de 1.000 personas.
Dispone de una sofisticada red de distribucion formada por 30 delegaciones
de ventas, 8 cabeceras de area, mas de 1.000 distribuidores y 20 almacenes, lo
que le permite dar servicio a sus mas de 200.000 clientes de una forma rapida
y eficaz. Toda esta infraestructura, la existencia de sistemas de informacion
distribuidos sin ninguna conexion entre las aplicaciones y sin una conexion
geografica entre las distintas areas de venta y las oficinas centrales llevo a
Schweppes en 1989 a tomar la decision de elegir SAP R/2 como la mejor
herramienta para la gestion de la compa
na.
La calidad del paquete SAP R/3 evaluado en la casa matriz y la
experiencia obtenida de la utilizacion del sistema R/2 llevo a Schweppes
en 1995 a seguir con la tecnologa de SAP; en este caso el sistema R/3, como
la opcion segura para la gestion de la empresa. Entre otras razones estaba
el que SAP R/3 encajaba dentro de las estrategias de futuro en el sector de
consumo en temas tan importantes como:
ECR.
Intranet.
Internet.
Comunicacion con distribuidores, proveedores y clientes
Las razones que llevaron a elegir R/3 como sistema de informacion fueron:

C.3. IBM ESPANA
181
El sistema deba ser u

nico para conseguir una reduccion de costes.
Deba cumplir los requerimientos para la transicion de milenio.
Facilidad de conversion de moneda.
Implantaci
on
La implantacion de SAP R/3 en Schweppes fue realizada de abril de 1996
a junio de 1997. El primer paso se dio en abril de 1996 con la implantacion
del modulo de control de calidad (QM). En el mes de octubre se implanto el
modulo de gestion de materiales (MM). En el mes de enero se implantaron
los modulos de FI, CO, AM y FI-SL en el area financiera. Los modulos de
ventas y vistribucion (SD) y planificacion de la produccion (PP) quedaron
implantados en junio de 1997.
Infraestructura
Esta basada en una plataforma AIX con un SP de IBM para produccion en
el mismo frameen el que reside el sistema de data warehouse, herramienta
complementaria a SAP R/3 y con Oracle como base de datos. Asimismo,
existe una maquina de backup y un entorno RS 6000 separado para test.
Pasar de un entorno host a un entorno cliente / servidor ha supuesto
montar toda una nueva infraestructura en cuanto a redes LAN y WAN,
cambio de estaciones de trabajo, etc. . . que ha sido importante debido a la
dispersion de las fabricas, oficinas y delegaciones. Existen otras herramientas
colaterales como datawarehousing, EIS y desarrollos verticales, todas ellas
perfectamente integradas con R/3 y bajo el mismo entorno cliente / servidor,
de modo que todas las funcionalidades se encuentren cubiertas.
C.3.
IBM Espa
na
Sector
IBM centra sus actividades en investigacion, desarrollo y venta de
productos y servicios de tecnologa de la informacion.
El hecho que IBM opere en 164 pases en los 5 continentes supone
una gran diversidad de necesidades especficas a nivel de cada pas, lo cual
lleva a distintas aplicaciones y distintos procesos. Ademas, el operar en un
mercado cada vez mas multinacional impone una unificacion de procesos que
permita hacer negocios cross-border, as como una reduccion en el desarrollo

APENDICE
C. CASOS REALES
182
y mantenimiento de miles de aplicaciones que hoy en da mantiene el negocio

de IBM.
Estudio de Necesidades
En un estudio de necesidades, existan basicamente dos opciones, ademas
de otras peque
nas firmas que se descartaron, entre otros motivos por el hecho
de no ser internacionales o tener una estructura de soporte no suficiente para
el proyecto que se quera abordar.
Las dos opciones eran ir a SAP o desarrollar un sistema propio. IBM
aposto por SAP R/3 entre otras razones:
Disponer de un sistema ya desarrollado que permite unificar y
simplificar los procesos a nivel internacional
Por su arquitectura integrada en un entorno cliente / servidor.
Su compatibilidad con aplicaciones desarrolladas en otros lenguajes e
instaladas en otros entornos.
Por la flexibilidad que supone respecto a tecnologas ya anticuadas.
Por su estructura de soporte.
Proyecto Piloto
Como proyecto piloto se eligio Espa
na por el tama
no de su mercado y
caractersticas para la instalacion de SAP R/3 a nivel internacional. En
una primera fase se instalaron los modulos de ventas y distribucion (SD)
y gestion de materiales (MM) de la version 3.0D. Para 1998 estaba prevista
la implementacion del modulo de finanzas (FI) casi en su totalidad.
La division encargada de utilizar el sistema es Fulfilment dentro de ella
basicamente el departmento de administracion. La aplicacion se utiliza para
cubrir los siguientes procesos comerciales:
2
Preparacion de una propuesta.

El pedido.
El envo a la planta de fabricacion.
El envo desde la planta al pas.
El envo al cliente.

C.3. IBM ESPANA
183
Facturacion.
Dada la naturaleza del negocio fue necesario la realizacion de algunas
interfaces con otras aplicaciones para la conexion con otros departmentos y
divisiones de la empresa. Ello llevo a una reingeniera de procesos. Dicha
reingeniera ha trado consigo una simplificacion que se ha visto reflejada en
un mejor servicio al cliente que es el objetivo primordial de IBM.
La instalacion del R/3 se hizo bajo sistema operativo UNIX en un SP2
de IBM con base de datos DB2.
Ap
endice D
Glosario
ABAP Advance Business Application Programming. Es el lenguaje de
programacion del sistema SAP R/3. Es un lenguaje de cuarta
generacion, con una sintaxis mezcla entre COBOL y SQL.
ASAP AcceleratedSAP. Metodologa de implementacion de SAP R/3 que
busca el ahorro maximo de tiempo de parametrizacion.
Batch input Metodo para la importacion rapida y consistente de datos en
R/3 partiendo de ficheros externos.
CATT Computer-Aided Test Tool. Herramienta para la generacion de datos
de test para probar el software.
CO Customizing Organizer. Herramienta para administrar las ordenes de
transporte de parametrizacion.
Dynpro DYNamic PROgram. Programa dinamico que consiste en una
pantalla y la logica de proceso subyacente que la controla. Es algo
similar a un form de visual basic.
EarlyWatch Service Servicio de alerta previa que ofrece SAP a sus clientes
para que, aprovechando la mayor experiencia de sus consultores,
detecten rapidamente problemas de rendimiento en nuestro sistema
productivo.
Entreprise IMG Gua de implementacion de la empresa. Cuando se inicia
la parametrizacion de un sistema SAP hay que crear el Enterprise IMG
incluyendo los modulos que se va a implementar.
185
186
APENDICE
D. GLOSARIO
Front End Termino que engloba a los ordenadores, programas y procesos

que se ejecutan en el cliente y que procesan datos antes de enviarlos al
servidor.
GUI Graphical User Interface. Programa mediante el cual el usuario puede
intercambiar informacion con el ordenador de manera facil e intuitiva.
Hot Package Conjunto de objetos del repositorio que SAP pone disponibles
a sus clientes para arreglar los errores o faltas graves de funcionalidad
de los programas estandar. Son los equivalentes a los Service Packs que
proporciona Microsoft para sus sistemas operativos.
IDES International Demo and Education System. Es un sistema R/3 que
se vende con un modelo de empresa parametrizado y completamente
funcional. Se usa para las demostraciones y los cursos de formacion.
IMG Implementation Guide. Transaccion que contiene un arbol con cientos
de transacciones de parametrizacion agrupadas por modulos y que
constituyen el punto de trabajo principal del equipo que implanta SAP
R/3 en una empresa.
LUW Logical Unit of Work. Secuencia indivisible de operaciones de base
de datos que forman una actualizacion que aegura la integrad de los
datos.
Modo Cada una de las seis pantallas como maximo que puede abrir un
usuario desde que abre una sesion con R/3.
OSS Online Service System. Servicio de atencion al cliente de SAP que
funciona conectandose a una serie de servidores dispuestos a lo largo
del mundo que proveen de un servicio 24x7. Se puede buscar nuestro
problema en la base de conocimiento de SAP o abrir una nueva
indidencia si no encontramos nada parecido a lo nuestro.
RDBMS Relational Database Management System. Hace referencia a
alguno de los sistemas de gestion de bases de datos relacionales sobre
los que funciona R/3 como Oracle, DB2. SQL Server. . .
RFC Remote Function Call. Mediante este protocolo se permite que
programa externos a SAP escritos en lenguajes distintos a ABAP
ejecuten operaciones sobre la base de datos de R/3.
SAP Sistemas, Productos, Aplicaciones para el Proceso de Datos.
187
SAPGUI SAP Graphical User Interface. Programa principal con el que nos
conectaremos a R/3.
Sesi
on Cada una de las conexiones que un usuario hace con el servidor R/3
en las que le pide el mandante, el usuario y la clave.
Sistema R/3 Recibe este nombre el conjunto formado por el servidor
central de base de datos, los servidores de aplicacion que trabajen con
el junto con el software R/3 instalado en ellos. La identificacion de un
sistema SAP se denomina SAPSID o simplemente SID y es un codigo
de tres caracteres.
WBO Workbench Organizer. Herramienta para administrar las ordenes de
transporte de desarrollo.
WP Work process. Cada uno de los procesos que los servidores de aplicacion
proporcionan a SAP para gestionar las peticiones de dialogo, fondo,
spool, actualizacion. . .
Bibliografa
[1] Fundamentos de SAP R/3 Dennis L. Prince Anaya Multimedia
ISBN: 8441510261
http://www.anayamultimedia.es
[2] SAP R/3 System Administration : The Official SAP Guide Liane
Will Ed.Sybex ISBN: 0782124267
http://www.amazon.com/exec/obidos/ASIN/0782124267/qid=
963220261/sr=1-64/104-9469904-0307951
[3] SAP R/3 System : A Client/Server Technology Rudiger BuckEmden, Jurgen Galimow, Sap Ag Addison-Wesley Pub Co ISBN:
0201403501
http://www.amazon.com/exec/obidos/ASIN/0201403501/qid%
3D963223251/104-9469904-0307951
[4] The R/3 System Landscape - Simplification Group
http://207.105.30.51/simple/sysadmin/files/Landscape-I.pdf
[5] Edicion Especial SAP R/3 ASAP World Consultancy. Blain, Jonathan
Prentice Hall Iberia ISBN: 0789713519
http://www.amazon.com/exec/obidos/ISBN%3D0789713519/
thesapfansclubanA/104-9469904-0307951
[6] As es SAP R/3 Hernandez Mu
noz, Jose Antonio Osborne McGrawHill ISBN: 8448121007
http://www.mcgrawhill.es/McGrawHill/catalogo.htm
[7] System Administration Made Easy Release 4.0B - Simplification Group
http://207.105.30.51/simple/sysadmin/saezindex.htm
[8] Authorizations Made Easy Guide 4.0B - Simplification Group
http://207.105.30.51/simple/authorization/40_pdf_files/
amez4ball.pdf
189

Adm SAP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Adm SAP

Uploaded by

Copyright:

Available Formats

DE SISTEMAS DE

Universidad de Deusto - Facultad de Ingeniera

Copyright (c) 2004 Pablo Perez Perez y Antonio Toledo Carnicero.

Sobre los autores

8. Log del sistema y an

8.1.4. Leyendo el log del sistema . . . . . . . .

13.3. Grupos de logon . . . . . . . . . . . . . . . . . . . . . . . . . 164

3.1. Capas de la estructura cliente/servidor de R/3 . . . . . . . . . 37

Monitor de procesos de una instancia . . . . .

6.1. Pantalla inicial de definicion de job . . . . . . . . . . . . . . . 66

Esquema funcionamiento actualizacion asncrona .

7.6. Pantalla principal entradas de bloqueo . . . . . . . . . . . . . 81

Pantalla principal log local del sistema . . . . . . . . .

Transaccion SPAD. Mantenimiento de dispositivos

10.1. Componentes de la seguridad en R/3 . . . . . . . .

11.1. Esquema de una orden de transporte . . . . .

12.1. Pantalla principal de la gestion de mandantes

13.1. Pantalla pricipal perfiles del sistema . . .

Tras la continua y masiva introduccion de la informatica en los sistemas

todo el codigo de cosecha propia que tiene la planta esta escrito

GENERAL DE SAP R/3

entre modulos de SAP permiten tener disponible en tiempo real y

Para referirse a la adecuaci

Como apuntabamos anteriormente el software de SAP es un compendio

GENERAL DE SAP R/3

compra y almacenaje de materia prima, pasando por la fabricacion del

3. Recursos Humanos HR Human Resources. Tradicionalmente, la

Nomina PA Payroll Accounting. Mantiene todos los datos de los

GENERAL DE SAP R/3

Aunque la cantidad de aplicaciones desarrolladas por SAP es enorme,

Screen Painter Con esta herramienta crearemos rapidamente interfases

Abreviatura de dynamic programs

Pantalla de logon a SAP R/3

Una vez que tengamos instalado el SAPGUI y pulsemos el icono

El concepto se puede definir desde 2 puntos de vista distintos pero

Figura 2.1: Pantalla de entrada a SAP R/3

2.2. CONCEPTO DE MANDANTE

As pues, cuando el usuario user1, conectado al mandante 015, solicita

Figura 2.2: Barra de ttulo

La barra de herramientas estandar es de particular interes, ya que contiene

Es un prompt de linea de comandos, y en el se pueden introducir

Se debera pulsar este boton cuando deseemos confirmar la grabacion de

Se debera pulsar este boton si queremos regresar a la pantalla anterior

Se debera pulsar este boton si queremos salir de la actual aplicacion. El

Se debera pulsar este boton si deseamos imprimir los datos que

Se debera pulsar este boton si deseamos realizar una b

Se debera pulsar este boton si deseamos seguir buscando la cadena de

2.6. LA BARRA DE APLICACIONES

Los botones de paginacion nos permiten colocarnos en las paginas

Figura 2.3: Barra de aplicaciones

Figura 2.4: Pantalla principal

Es la parte principal de la aplicacion y dependiendo de esta podra estar

Figura 2.5: Barra de estado

la de mostrarnos los mensajes de Informaci

Un elemento final de la ventana R/3 es la ventana de dialogo en la que el

Figura 2.6: Ventana de dialogo

El sistema SAP R/3 dispone de una herramienta especfica para la

Figura 2.7: Ayuda de b

Los modos externos en un sistema R/3 son conexiones virtuales que un

Figura 2.8: Listado de valores posibles

Una transaccion comercial es un intercambio entre una parte del sistema

Las opciones tecnicas del SAPGUI se encuentran en el u

Figura 2.9: Icono de acceso a las opciones tecnicas

Al pinchar el boton nos aparece el men