Administracion De Sap R3

´ DE SISTEMAS DE GESTION ´ INFORMACION

Universidad de Deusto - Facultad de Ingenier´ıa Antonio Toledo Carnicero Pablo P´erez P´erez c Octubre de 2006

c

copyleft Copyright (c) 2006 Pablo P´erez P´erez 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) 2006 Pablo P´erez P´erez y Antonio Toledo Carnicero. Esta obra esta licenciada bajos los t´erminos de la licencia Atribuci´on-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 15 a˜ nos la implantaci´on de sistemas de informaci´on tipo ERP en las grandes empresas ha sido masiva. SAP R/3 es el m´aximo exponente de ello al ser el l´ıder mundial en n´ umero de instalaciones. La gran amplitud y complejidad de un sistema R/3 exige la especializaci´on del personal de la empresa en cada uno de sus aspectos como pueden ser, la funcionalidad, la parametrizaci´on, la programaci´on o la administraci´on del sistema. Es en este u ´ltimo aspecto, la administraci´on del sistema, en el que se centra la presente obra.

Audencia Este libro est´a espec´ıficamente escrito para los alumnos de la asignatura Gesti´on de Sistemas de Informaci´ on dentro del quinto curso del programa de estudios de Ingenier´ıa en Inform´atica de ESIDE en la Universidad de Deusto. Son a ellos, principalmente, a qui´en va dirigido el libro. No obstante, a lo largo de nuestra experiencia laboral hemos tenido la oportunidad de mostrar varios cap´ıtulos del libro a diversas personas que trabajan con SAP R/3. A algunos programadores y t´ecnicos de atenci´on 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. Tambi´en puede servir como introducci´on a los que quieran iniciarse en la administraci´on de sistemas R/3.

Sobre los autores Pablo P´ erez complet´o sus estudios de licenciatura en inform´atica en la Universidad de Deusto en el a˜ no 1995. Comenz´o su experiencia con SAP R/3 en 1997, en la empresa de automoci´on Grupo Antol´ın, como programador de ABAP/4 y administrador de sistemas. Posteriormente ha 3

4 trabajado como analista y consultor t´ecnico de SAP para varias empresas y form´o parte durante 5 a˜ nos del equipo de desarrollo de Finanzas y Control de Gesti´on en la el´ectrica Iberdrola. En la actualidad es el responsable de los sistemas inform´aticos de la empresa reprogr´afica Cianoplan y ocasionalmente trabaja como analista freelance de ABAP/4. Su experiencia docente incluye varias ediciones del Master de Consultor´ıa e Implantaci´ on de Sistemas de Informaci´on y la Diplomatura de Especializaci´ on en Gesti´ on de Sistemas y Redes, ambos t´ıtulos de postgrado impartidos por la Universidad de Deusto. Antonio Toledo es licenciado en Ciencias F´ısicas por la Universidad del Pa´ıs Vasco desde el a˜ no 1995. Su experiencia laboral se inici´o en Grupo Antol´ın, una multinacional del sector de la automoci´on, como programador ABAP/4 y administrador de Sistemas SAP. Posteriormente ha formado parte de varias empresas del sector de las TI como Ceinsa o IT Deusto. Actualmente es jefe de proyectos del ´area de sistemas en la empresa AVN y ha formado parte de los equipos de administraci´on y soporte SAP de empresas como Iberdrola o Eroski. Ha colaborado en varias ocasiones como profesor en el Master de Consultor´ıa e Implantaci´ on de Sistemas de Informaci´ on y la Diplomatura de Especializaci´ on en Gesti´ on de Sistemas y Redes de la Universidad de Deusto.

´Indice general Copyleft

2

1. Introducci´ on a SAP R/3 1.1. Software est´andar vs. software a medida 1.2. Visi´on general de SAP R/3 . . . . . . . 1.2.1. Caracter´ısticas principales . . . . 1.2.2. M´odulos . . . . . . . . . . . . . . 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 t´ıtulo . . . . . . . . . . 2.4. El men´ u desplegable . . . . . . . . 2.5. La barra est´andar de herramientas 2.6. La barra de aplicaciones . . . . . . 2.7. La pantalla principal . . . . . . . . 2.8. La barra de estado . . . . . . . . . 2.9. Ventana de di´alogo . . . . . . . . . 2.10. Ayudas de b´ usqueda . . . . . . . . 2.11. Modos . . . . . . . . . . . . . . . . 2.12. Concepto de transacci´on . . . . . . 2.13. Opciones t´ecnicas . . . . . . . . . . 2.14. La pantalla status . . . . . . . . . . 3. Arquitectura de un sistema R/3 3.1. Introducci´on . . . . . . . . . . . 3.2. Servicios de base de datos . . . 3.3. Servicios de aplicaci´on . . . . . 3.4. Servicios de presentaci´on . . . . 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

6

4. Escenarios de configuraci´ on 4.1. Consideraciones generales sobre los sistemas R/3 . . . . . . . . 4.2. Descripci´on y funciones de cada sistema . . . . . . . . . . . . 4.2.1. Sistema de desarrollo . . . . . . . . . . . . . . . . . . . 4.2.2. Sistema de integraci´on . . . . . . . . . . . . . . . . . . 4.2.3. Sistema de producci´on . . . . . . . . . . . . . . . . . . 4.3. Mandantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Mandantes est´andar . . . . . . . . . . . . . . . . . . . 4.3.2. Mandantes propios . . . . . . . . . . . . . . . . . . . . 4.4. Comparaci´on de escenarios . . . . . . . . . . . . . . . . . . . . 4.4.1. Configuraci´on con un s´olo sistema (Producci´on) . . . . 4.4.2. Configuraci´on con dos sistemas (Desarrollo y Producci´on) 4.4.3. Configuraci´on con tres sistemas (Desarrollo, Integraci´on y Producci´on) . . . . . . . . . . . . . . . . . .

45 45 46 46 46 47 47 47 48 50 50 51 52

5. Monitorizaci´ on de procesos y usuarios 55 5.1. Monitorizaci´on de procesos activos . . . . . . . . . . . . . . . 55 5.2. Monitorizaci´on usuarios conectados . . . . . . . . . . . . . . . 61 6. Procesamiento en fondo 6.1. Conceptos de procesamiento en fondo 6.2. Definici´on de jobs . . . . . . . . . . . 6.2.1. Informaci´on general . . . . . . 6.2.2. Hora de inicio o evento . . . . 6.2.3. Pasos . . . . . . . . . . . . . . 6.3. An´alisis de jobs . . . . . . . . . . . . 6.3.1. Estados de un job . . . . . . . 6.3.2. Operaciones sobre jobs . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

7. Servicios de actualizaci´ on 7.1. Actualizaci´on s´ıncrona y as´ıncrona . . . . . 7.2. Procesos de actualizaci´on V1 y V2 . . . . . 7.3. Monitorizaci´on del estado de la actualizaci´on 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

7

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. Instalaci´on 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. Creaci´on 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. Importaci´on de perfiles del sistema . . . . 13.1.3. Visualizaci´on todos los par´ametros activos 13.1.4. Par´ametros m´as importantes de un sistema 13.2. Modos de Operaci´on . . . . . . . . . . . . . . . . 13.2.1. Gesti´on de modos de operaci´on . . . . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . R/3 . . . . . .

. . . . . . .

. . . . . . .

139 140 145 148 149

´INDICE GENERAL

8

13.3. Grupos de logon . . . . . . . . . . . . . . . . . . . . . . . . . 164 13.3.1. Gesti´on 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 t´ıtulo . . . . . . . . . . . . . . . . 2.3. Barra de aplicaciones . . . . . . . . . . . . . 2.4. Pantalla principal . . . . . . . . . . . . . . . 2.5. Barra de estado . . . . . . . . . . . . . . . . 2.6. Ventana de di´alogo . . . . . . . . . . . . . . 2.7. Ayuda de b´ usqueda . . . . . . . . . . . . . . 2.8. Listado de valores posibles . . . . . . . . . . 2.9. Icono de acceso a las opciones t´ecnicas . . . 2.10. Menu del icono de acceso a opciones t´ecnicas 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. 5.7. 5.8.

Monitor de procesos de una instancia . . . . . . . Monitor de instancias activas . . . . . . . . . . . Monitor de sistema operativo . . . . . . . . . . . Monitor global de procesos activos . . . . . . . . Monitor de conexi´on de usuarios por instancia . . Lista de modos activos por usuario . . . . . . . . Informaci´on detalllada de usuario . . . . . . . . . Usuarios conectados vistos en la transacci´on AL08

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

56 59 60 60 61 62 63 64

6.1. Pantalla inicial de definici´on de job . . . . . . . . . . . . . . . 66 6.2. Pantalla inicial de selecci´on de jobs . . . . . . . . . . . . . . . 69 6.3. Resumen de jobs seleccionados . . . . . . . . . . . . . . . . . . 70 7.1. Esquema funcionamiento actualizaci´on as´ıncrona . . . . . . . . 74 7.2. Esquema funcionamiento actualizaci´on s´ıncrona . . . . . . . . 74 7.3. Pantalla principal monitor actualizaci´on . . . . . . . . . . . . 76 9

´INDICE DE FIGURAS

10 7.4. 7.5. 7.6. 7.7. 7.8.

Actualizaciones pendientes . . . . . . . . M´odulos de actualizaci´on . . . . . . . . . Pantalla principal entradas de bloqueo . Listado de bloqueos activos en el sistema Informaci´on detallada de un bloqueo . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

78 79 81 81 82

8.1. 8.2. 8.3. 8.4. 8.5. 8.6. 8.7.

Pantalla principal log local del sistema . . . . . . . . . Par´ametros de selecci´on 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 an´alisis de dumps . . . . . . . . . B´ usqueda de dumps antiguos . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

87 88 90 90 91 93 93

9.1. 9.2. 9.3. 9.4. 9.5. 9.6. 9.7.

Transacci´on SPAD. Mantenimiento de dispositivos Datos generales para una impresora local . . . . . Tipo de impresora para una impresora local . . . Ventana de di´alogo para imprimir un listado . . . Transacci´on SP01. Selecci´on de ´ordenes de spool . Transacci´on SP01. Listado de ´ordenes de spool . . Atributos de una orden de spool . . . . . . . . . .

de salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

104 105 106 107 109 109 110

10.1. Componentes de la seguridad en R/3 . . . . . . . . 10.2. Pantalla inicial de la actualizaci´on 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. Asignaci´on de valores a los objetos de autorizaci´on . 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. Creaci´on 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.Visualizaci´on individual de ´ordenes . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

123 123 125 127 128 129 131 133 134 135 137

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

´INDICE DE FIGURAS

11

11.12.Log del transporte de una orden . . . . . . . . . . . . . . . . . 137 12.1. Pantalla principal de la gesti´on 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 gesti´on de un perfil . . . . . . . 13.3. Actualizaci´on b´asica de un perfil . . . . . 13.4. Actualizaci´on ampliada de un perfil . . . 13.5. Modos de operaci´on . . . . . . . . . . . . 13.6. Distribuci´on de procesos de trabajo . . . 13.7. Pantalla principal asignaci´on horaria . . 13.8. Asignaci´on horaria a modos de operaci´on 13.9. Pantalla principal grupos de logon . . . . 13.10.Pantalla detalles creaci´on grupo logon . . 13.11.Pantalla de saplogon . . . . . . . . . . . 13.12.Opci´on de selecci´on servidor en saplogon 13.13.Opci´on propiedades en saplogon . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

155 155 156 157 161 162 163 164 166 167 168 169 169

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

Cap´ıtulo 1 Introducci´ on a SAP R/3 1.1.

Software est´ andar vs. software a medida

Tras la continua y masiva introducci´on de la inform´atica en los sistemas de gesti´on empresariales durante mas de treinta a˜ nos, nos encontramos a principio de los noventa con un panorama variopinto. Los diversos departamentos de gesti´on de la mayor´ıa de las empresas utilizan varios software diferentes hechos a medida por el propio departamento de TI1 o por alguna consultor´ıa externa. La compatibilidad es casi nula y la creaci´on de interfases para integrar los datos de un departamento con otro est´a a la orden del d´ıa. Veamos un ejemplo clarificador de esta situaci´on. El director del departamento de TI de una empresa dedicada a la fabricaci´on de grandes piezas industriales, refleja su ca´otica situaci´on: ”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 planificaci´on de recursos de fabricaci´on (MRP) opera en un VAX de gama alta. Y parte del software de gesti´on de la fabricaci´on y de transporte opera en un AS/400. Pr´acticamente 1

Tecnolog´ıas de la informaci´ on

13

´ A SAP R/3 CAP´ITULO 1. INTRODUCCION

14

todo el c´odigo 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 situaci´on 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 evoluci´on que ha venido sufriendo la industria y la tecnolog´ıa, se han quedado obsoletos. Adem´as de las deficiencias que cada empresa detecta en sus sistemas de informaci´on tenemos que tener en cuenta otros factores generales que afectan a todas ellas. Problemas como el efecto 2000 o la introducci´on del Euro como moneda u ´nica en los pa´ıses de la CEE no pueden ser obviados por el departamento de TI. La pregunta que se plantea cualquier empresa en esta situaci´on es la siguiente ¿Vamos rehaciendo y adaptando nuestro software o adquirimos una soluci´on est´andar?. Veremos que casi todas la grandes empresas han optado por una solucion est´andar. En la mayor´ıa de los casos se trata de SAP R/3 , por ello es el l´ıder 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 Caracter´ısticas principales

Las m´ ultiples ventajas del software R/3 hace que se haya convertido en uno de los est´andares de hecho dentro de las grandes corporaciones. A continuaci´on detallaremos algunas de estas ventajas. Exhaustivo El sistema R/3 engloba la pr´actica totalidad de los procesos de gesti´on de la empresa. En el siguiente apartado veremos detallados la cantidad de m´odulos que incluye. Integrado Tal cantidad de modulos no aportar´ıan demasiado valor a˜ nadido a la empresa si no fuera por la integraci´on. 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 gesti´on. Como ejemplo ilustrativo diremos que una entrada de mercanc´ıas en R/3 puede producir una actualizaci´on del inventario de almac´en, un apunte contable en la contabilidad financiera, un actualizacion del sistema de informaci´on del control de costes y un aviso a producci´on de que hay nueva materia prima en almac´en. Abierto Tecnol´ogicamente 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 est´andares 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 parametrizaci´on 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 integraci´on con el est´andar. Global El sistema R/3 soporta su utilizaci´on en varios idiomas, la contabilizaci´on de documentos en cualquier moneda y tiene recogidas las particularidades fiscales y de gesti´on de recursos humanos de un gran n´ umero de pa´ıses. Esta globalidad es el argumento de mayor peso en la decisi´on 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. Adem´as, la constante investigaci´on llevada a cabo por SAP hace que su software este al d´ıa incluyendo la u ´ltima tecnolog´ıas disponibles como EDI, Data Warehouse, clientes Java, comercio electr´onico. . . . 1

Para referirse a la adecuaci´ on del sistema a la necesidades del cliente se escuchar´a frecuentemente el termino anglosaj´on 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 ”modificaci´on de los par´ametros del sistema para adecuarlo a las necesidades del cliente”

´ A SAP R/3 CAP´ITULO 1. INTRODUCCION

16

1.2.2.

M´ odulos

Como apuntabamos anteriormente el software de SAP es un compendio realmente exhaustivo de aplicaciones de gesti´on. A cada uno de los componentes que sirven para gestionar cada una de la ´areas de la empresa se les denomina m´odulos y se les nombra con dos letras correspondientes a las iniciales del nombre en ingl´es. Los m´odulos principales (finanzas, log´ıstica y recursos humanos) se componen a su vez de subm´odulos. Estos son los principales m´odulos y sus caracter´ısticas. 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 m´odulos 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 p´erdidas y ganancias) en todo momento. Los subm´odulos que la componen son los siguientes. Control de Gesti´ on CO Controlling. La contabilidad financiera no siempre puede proporcionar informaci´on desde todos los puntos de vista que una gesti´on eficaz de costes requiere y es, en este punto, donde act´ ua el m´odulo CO. Partiendo de los datos de FI, la contabilidad anal´ıtica nos muestra los ingresos, gastos e inversiones desde vistas diferentes. Si juntamos esto con el sistema de planificaci´on y previsi´on de costes obtendremos un sistema de informaci´on completo con las comparativas del plan contra el real que nos permiten saber si nos ajustamos al presupuesto y el porqu´e. Tesoreria TR Treasury. Representa la soluci´on completa para una gesti´on econ´omico financiera eficaz. Nos permite asegurar la liquidez de la empresa en todo momento y estructurar los activos financieros de la manera m´as lucrativa posible. Activos Fijos AM Asset Management. Nos permite controlar el ciclo de vida completo del nuestro inmovilizado, desde la inversi´on inicial en activos fijos en curso, pasando por la contabilizaci´on de la manera m´as conveniente las amortizaciones, la puesta en explotaci´on de dicho inmovilizado y la enajenaci´on del mismo. Existe otro peque˜ no subm´odulo denominado gestion de inversiones (IM Investment Management) que esta muy relacionado con AM. 2. Log´ıstica LO Logistics. Bajo este ep´ıgrafe se engloba la gesti´on 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 fabricaci´on del producto hasta su venta y distribuci´on. Es el m´odulo m´as grande de todos ellos y el que m´as componentes tiene. Describimos a continuaci´on los m´as usados aunque existen otros menos conocidos como la gesti´on del servicio al cliente, la gesti´on de proyectos y la gesti´on de la calidad de productos. Gesti´on de Materiales MM Materials Management. Optimiza todos los procesos de compra a trav´es de varias funciones disponibles. Por un lado permite automatizar las evaluaciones de proveedores mediante la entrada de ofertas y el mantenimiento de registros info. Tambi´en podemos reducir los costes de aprovisionamiento y almacenamiento, gracias a la precisi´on de la gesti´on de stocks y de almacenes. Este es uno de los puntos donde m´as claramente poder apreciar el retorno de la inversi´on porque los costes de almacenaje es una de las principales preocupaciones de las empresas en la actualidad. Un completo sistema de verificaci´on de facturas nos proporciona la integraci´on necesaria con los modulos contables FI, CO y TR para tener la informaci´on actualizada en tiempo real. Planificaci´on de la Producci´ on PP Production Planning. Proporciona procesos completos para todos los tipos de fabricaci´on: fabricaci´on repetitiva, fabricaci´on contra pedido, fabricaci´on contra cat´alogo, fabricaci´on por procesos, fabricaci´on por lotes y en serie, hasta la gesti´on integrada de cadenas de suministro con funciones MRP y Kanban. La integraci´on con MM puede provocar la solicitud de necesidades autom´atica al lanzar la planificaci´on 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 producci´on y de esto se encarga el m´odulo de PM. Aplicaciones como la planificaci´on de las revisiones, la programaci´on de ´ordenes de mantenimiento, las gesti´on notificaciones de aprobaci´on nos aseguran una rendimiento ´optimo de nuestra f´abrica. Integrando todo esto con PP (podemos modificar las ´ordenes de producci´on en funci´on de la disponibilidad de la cadena de producci´on), 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 CAP´ITULO 1. INTRODUCCION Ventas y Distribuci´ on SD Sales and Distribution. La cambiante realidad de los mercados actuales es un reto para cualquier programa de gesti´on 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 m´odulos financieros del estado de nuestras ventas es una labor imprescindible para poder conocer el estado econ´omico y financiero actualizado de la empresa.

3. Recursos Humanos HR Human Resources. Tradicionalmente, la gesti´on de recursos humanos se ha considerado una ´area aislada del resto de sistemas de gesti´on de la empresa. SAP, sin embargo, ha llevado su m´axima de integraci´on hasta el punto de incluir la gesti´on de turnos y plantillas, los horarios de f´abricas, y el absentismo laboral en los procesos de negocio de la fabricaci´on y el mantemiento de planta entre otros. Los dos subm´odulos principales son PA y PD aunque tambi´en existen soluciones menos usadas como la gesti´on de candidatos, el calendario de f´abrica y la gesti´on de viajes y gastos.

N´omina PA Payroll Accounting. Mantiene todos los datos de los empleados en unas estructuras denominadas infotipos que nos permiten calcular el pago de la n´omina y contabilizarla tanto en FI como CO de manera autom´atica. Existen infotipos para todas las caracter´ısticas de un empleado, como datos personales, salario bruto, datos familiares, turnos, retenes, retenciones fiscales. . . Este subm´odulo es posiblemente el m´as espec´ıfico de cada pa´ıs debido a que las leyes que rigen las relaciones laborales difieren mucho de unos pa´ıses a otros. Es por ello que SAP porporciona unos programas diferentes para cada pa´ıs y un servicio de actualizaci´on para poder estar al d´ıa con los cambios que se producen en materia de legislaci´on laboral (aparici´on de nuevas modalidades de contrataci´on, cambios en la normativa fiscal, etc. . . ) Estructura Organizativa PD Personnel Development. Este subm´odulo se encarga de gestionar la estructura de la empresa organizando la misma en departamentos, ´areas, grupos de trabajo, etc. . . Permite la definicici´on de tareas de puestos de trabajo y la reorganizaci´on 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 espec´ıfica de su negocio que no este contemplada en el est´andar. Tambi´en puede darse el caso de que la funcionalidad que ofrece el est´andar 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 programaci´on ABAP/4 se caracteriza por su total integraci´on en el sistema R/3. No en vano todo el software de aplicaci´on (se calcula que m´as de treinta millones de l´ıneas de c´odigo) 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 gesti´on. Es un lenguaje de muy alto nivel, f´acil de leer y se aprende r´apidamente. Data Dictionary Es el punto de referencia para los programadores ya que permite aislarles del sistema de gesti´on 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 permiti´endonos 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 autorizaci´on. Editor de programas El editor ABAP/4, aparte de proveer de las funciones b´asicas para la edici´on de texto, tiene m´ ultiples caracter´ısticas que facilitan la programaci´on enormemente. Nos permite efectuar una verificaci´on de sintaxis y aceptar las sugerencias del dispositivo de correci´on autom´atica que tiene incluido. Tambi´en nos permite resaltar las palabras clave y tener una vista en forma de estructura jer´arquica que ofrece la posibilidad de ocultar o desglosar bloques sint´acticos. De esta forma, el programador obtiene una buena visi´on de conjunto de la estructura general del programa.

´ A SAP R/3 CAP´ITULO 1. INTRODUCCION

20

Screen Painter Con esta herramienta crearemos r´apidamente interfases gr´aficas de usuario incluyendo una amplia gama de elementos de control, como botones de pulsaci´on, 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 l´ogica de proceso de la misma. Esta l´ogica 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 m´as alabada por los programadores habituales de este lenguaje. Tiene todas las ventajas de este tipo de ayudas a la programaci´on (creaci´on de breakpoints, watchpoints, ejecuci´on paso a paso, ejecuci´on por bloques. . . ) pero adem´as nos permite hacer todo esto viendo el c´odigo fuente del programa, por lo que la localizaci´on 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 an´alisis del tiempo de ejecuci´on, el Object Browser, el sistema de test asistido por ordenador (CATT), etc. . .

2

Abreviatura de dynamic programs

Cap´ıtulo 2 Introducci´ on al sapgui Como cualquier software que est´e basado en arquitectura cliente/servidor, SAP R/3 dispone de un programa cliente que se debe instalar en cada uno de los servidores de presentaci´on (PC’s) para poder realizar la conexi´on 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 aparecer´a la pantalla de conexi´on 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.Tambi´en podremos elegir el idioma de conexi´on. 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 conectar´a en el idioma que tenga asignado por defecto en su registro maestro de usuario. En esta pantalla aparece un nuevo concepto: Mandante. Este es quiz´a el t´ermino m´as importante dentro SAP R/3. El usuario, adem´as de los datos arriba especificados, deber´a indicar a qu´e mandante se quiere conectar.

2.2.

Concepto de mandante

El concepto se puede definir desde 2 puntos de vista distintos pero complementarios: La Visi´on L´ogica y la Visi´ on F´ısica. 21

22

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

Figura 2.1: Pantalla de entrada a SAP R/3 La Visi´ on L´ ogica. El mandante no es m´as que una unidad organizativa divisoria de la empresa y permite que distintos usuarios est´en trabajando en el mismo sistema sin ning´ un tipo de interferencia mutua ya que cada usuario s´olo dispondr´a de acceso para visualizar y actualizar los datos de aplicaci´on de la empresa que est´en asociados al mandante al que est´an 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 aplicaci´on de la empresa (datos de clientes, proveedores, pedidos, facturas, cuentas contables, etc. . . ) as´ı como la mayor´ıa de los datos de parametrizaci´on de la empresa. Se llaman dependientes de mandante porque s´olo son accesibles desde el mandante en el que se crearon. Estos tipo de datos son los m´as habituales en un sistema SAP R/3. Datos independientes de mandante. Se engloban aqu´ı ciertos datos de la parametrizaci´on 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 modificaci´on de este tipo de datos, el sistema avisa con un mensaje informativo inform´andonos de que la modificaci´on afectar´a a todos los mandantes. Se ha de ser especialmente cuidadoso al modificar la parametrizaci´on independiente de mandante. La Visi´ on F´ısica. La base de datos de SAP R/3 est´a 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 informaci´on pedida. El mandante es el primer campo clave de la mayor´ıa 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 est´a asignando en ese momento el valor del mandante elegido, con lo que el usuario s´olo podr´a acceder a visualizar o modificar los datos de cada tabla que tengan como mandante el que ha elegido en tiempo de conexi´on. 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 instrucci´on SQL el campo mandante y el valor actual que tenga. Ejemplo: Situaci´ on 1: Los usuarios user1 y user2 est´an ambos conectados al mandante 015 de un mismo sistema. Mientras el usuario user1 est´a modificando la factura 1000, el usuario user2 s´olo podr´a acceder en modo visualizaci´on ya que la factura est´a siendo bloqueada por el usuario user1; sin embargo, cuando el usuario user1 termine de modificarla, user2 podr´a ver la modificaci´on realizada por user1, e incluso podr´a realizar cualquier modificaci´on posterior. Situaci´ on 2: El usuario user1 est´a conectado al mandante 015 y el usuario user2 est´a conectado al mandante 016 del mismo sistema. Ahora los 2 usuarios no pueden acceder a la misma informaci´on ya que sus conexiones al sistema est´an ”l´ogicamente 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 est´a accediendo a la tabla de facturas, pero en cada caso accede al registro compuesto por el mandante de conexi´on del usuario y el n´ umero de factura:

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

24

Mandante 015 015 016 016

Num. f´actura 1000 1010 1000 1050

Descripci´on 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 descripci´on Factura X, mientras que si el usuario user2 se conecta al mandante 016 para solicitar la factura 1000, el sistema le mostrar´a la factura con descripci´on Factura Z.

2.3.

La barra de t´ıtulo

Figura 2.2: Barra de t´ıtulo Con la visualizaci´on antigua del sapgui se encuentra en la parte superior de la pantalla y su funci´on principal es mostrarnos la descripci´on de la transacci´on o men´ u de ´ambito en curso. En la nueva visualizaci´on del sapgui se encuentra entre la barra est´andar 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 b´asica para la navegaci´on 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. Opci´on para crear y borrar modos, desconexi´on del sistema, ver el status de nuestra sesi´on 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 est´andar es de particular inter´es, ya que contiene muchos de los botones necesarios para realizar las acciones m´as comunes tales como grabar, enter, imprimir, etc. . . Las funciones asignadas a la barra de herramientas est´andar son las siguientes. Bot´ on Enter

Se deber´a pulsar este bot´on para chequear los datos introducidos en una pantalla. El bot´on enter realiza la misma funci´on 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 c´odigos de transacciones o men´ us de ´ambito. Bot´ on Grabar

Se deber´a pulsar este bot´on cuando deseemos confirmar la grabaci´on de los datos introducidos. Bot´ on Back

Se deber´a pulsar este bot´on si queremos regresar a la pantalla anterior sin grabar los datos introducidos. Bot´ on Exit

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

26

Se deber´a pulsar este bot´on si queremos salir de la actual aplicaci´on. El sistema nos devuelve a la anterior aplicaci´on. Bot´ on Cancel

Se deber´a pulsar este bot´on si deseamos salir de la tarea actual sin grabar. Bot´ on Imprimir

Se deber´a pulsar este bot´on si deseamos imprimir los datos que actualmente aparecen en pantalla. El bot´on de impresi´on estar´a activado u ´nicamente en pantallas donde se los datos aparezcan en formato de listado y formato de tabla. Bot´ on Buscar

Se deber´a pulsar este bot´on si deseamos realizar una b´ usqueda de una cadena de caracteres en la pantalla actual. El bot´on de buscar estar´a activado u ´nicamente en pantallas donde los datos aparezcan en formato de listado y formato de tabla. Bot´ on Buscar Siguiente

Se deber´a pulsar este bot´on si deseamos seguir buscando la cadena de caracteres indicada en una b´ usqueda anterior con el bot´on buscar. El bot´on de buscar siguiente estar´a 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 paginaci´on nos permiten colocarnos en las p´aginas deseadas dentro de los listados que podamos obtener en pantalla. Los botones de paginaci´on estar´an activado u ´nicamente en pantallas donde los datos aparezcan en formato de listado y formato de tabla. Disponemos de las opciones primera p´agina, p´agina arriba, p´agina abajo yu ´ltima p´agina:

2.6.

La barra de aplicaciones

Figura 2.3: Barra de aplicaciones Con la visualizaci´on antigua del sapgui se encuentra entre la barra est´andar de herramientas y la parte principal de la pantalla. En ella disponemos de las opciones b´asicas para el control de la aplicaci´on actual (ejemplos de aplicaciones: visualizar pedido de compras, creaci´on de cliente, .. ). En la nueva visualizaci´on del sapgui se encuentra entre la barra de t´ıtulos y la parte principal de la pantalla.

2.7.

La pantalla principal

Figura 2.4: Pantalla principal

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

28

Es la parte principal de la aplicaci´on y dependiendo de ´esta podr´a 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 funci´on principal es ´ la de mostrarnos los mensajes de Informaci´ on, Advertencia, Error o Exito que la aplicaci´on en curso nos muestre al navegar por ella. Como funciones adicionales, la barra de estado nos muestra tambi´en: 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 contendr´a 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 instalaci´on 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 m´as que pulsar la tecla Insert de nuestro teclado. En la visualizaci´on antigua del sapgui aparece la hora que tiene configurada el servidor de presentaci´on a nivel de sistema operativo. Sin embargo, en la nueva visualizaci´on 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 configuraci´on de cada servidor de presentaci´on.

´ 2.9. VENTANA DE DIALOGO

2.9.

29

Ventana de di´ alogo

Un elemento final de la ventana R/3 es la ventana de di´alogo en la que el sistema nos presenta una ventana flotante donde normalmente nos pedir´a la introducci´on de alg´ un dato o la confirmaci´on o anulaci´on de alg´ un mensaje sin posibilidad de retornar o avanzar en la navegaci´on hasta que el usuario introduzca la informaci´on pedida. Ver figura 2.6.

Figura 2.6: Ventana de di´alogo

2.10.

Ayudas de b´ usqueda

El sistema SAP R/3 dispone de una herramienta espec´ıfica para la determinaci´on de valores posibles en un campo de entrada. Esta herramienta se conoce con el nombre de Ayudas de B´ usqueda a partir de la versi´on 4.0B de SAP R/3 (hasta esta versi´on 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 mayor´ıa 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 podr´a estar activa permanentemente o s´olo cuando posicionemos el cursor sobre dicho campo. Veamos esto con un ejemplo:

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

30

Figura 2.7: Ayuda de b´ usqueda En una pantalla cualquiera del m´odulo de Gesti´ on de Materiales(MM) debemos introducir un valor en el concepto Material ; sin embargo no conocemos qu´e valores posibles puede tomar ese campo. Para saber qu´e posibles valores puede llegar a tomar el campo Material haremos uso de la ayuda de b´ usqueda asociada. Para ello pulsaremos su bot´on de ayuda de b´ usqueda o la tecla de funci´on F4 estando posicionados en el campo. A continuaci´on nos aparecer´a 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 ser´a un valor no v´alido y el sistema mostrar´a 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 conexi´on real al sistema. A efectos de servidor de presentaci´on esto se traduce en la creaci´on 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 visualizaci´on de un pedido y en otro accedemos a los datos maestros de un cliente. A esta opci´on accederemos desde cualquier pantalla de SAP R/3 por el men´ u desplegable Sistema → Crear Modo. Es importante saber distinguir entre conexi´on real (tambi´en llamada sesi´on) y modo. Existe una limitaci´on : S´olo se pueden abrir 6 modos por conexi´ on real o sesi´ on Esta limitaci´on se aplica s´olo a los modos, no a las conexiones f´ısicas. Para las conexiones f´ısicas la u ´nica limitaci´on es la que imponga la disponibilidad de recursos en el Servidor de Presentaci´on. Cada vez que creemos un nuevo

2.11. MODOS

31

Figura 2.8: Listado de valores posibles modo no estamos realizando una nueva conexi´on real sino que estamos usando la misma conexi´on para simular conexiones virtuales. La opci´on del men´ u desplegable Sistema → Salir del sistema nos desconecta de la conexi´on real con la que estemos trabajando, con lo cual se cerrar´an todas las ventanas de los modos que correspondan a esa conexi´on real. Veamos los comandos m´as habituales para la gesti´on de modos. Estos comandos se deber´an introducir en el campo de comandos de la barra est´andar de herramientas: Llamar una transacci´on • en el mismo modo (ventana) → Indicar: /nxxxx (xxxx = c´odigo de transacci´on) • en un modo adicional → Indicar: /oxxxx (xxxx = c´odigo de transacci´on) Finalizar la transacci´on actual → Indicar: /n. Atenci´on: Las modificaciones hechas se perder´an sin que el sistema emita un mensaje de advertencia. Borrar el modo actual → Indicar: /i.

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

32

Generar una lista con los modos propios activos → Indicar: /o. Salir del sistema → Indicar: /nend.

2.12.

Concepto de transacci´ on

Una transacci´on comercial es un intercambio entre una parte del sistema y otra. La planta de producci´on, por ejemplo, quiere un suministro desde el almac´en a cambio de un albar´an. El almac´en sabr´a utilizar este albar´an para conciliar el saldo de esta pieza en el inventario de las mismas. Mientras tanto, el departamento de contabilidad habr´a anotado que el material ha pasado de la cuenta del almac´en a la de la planta de producci´on y definir´a una transacci´on financiera para registrar el intercambio de valor por el material. Cuando un usuario est´a trabajando en un terminal, una transacci´on con el sistema no queda terminada hasta que ´este verifica que las entradas de informaci´on son correctas. El sistema registrar´a autom´aticamente la transacci´on como un documento que queda en el sistema en prueba de qui´en hizo la transacci´on y cu´ando ´esta ocurri´o exactamente. Llevando esta visi´on al sistema SAP veremos que una transacci´on 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 operaci´on que quiere llevar a cabo. Tras completar toda la informaci´on obligatoria y parte de los campos opcionales, el usuario tiene la opci´on de grabar la transacci´on o de desechar toda la operaci´on. Este es el punto clave de una transacci´on; si se graba, entonces todos los datos quedar´an registrados, si se cancela, entonces ning´ un dato se grabar´a. El concepto de transacci´on implica que no pueden quedarse grabados s´olo una parte de los datos, porque esto provocar´ıa una inconsistencia en el sistema. En el ejemplo anterior, si s´olo se registrara el movimiento de mercanc´ıas entre la planta y el almac´en y no se grabara la anotaci´on contable correspondiente, no podr´ıamos, en un momento dado, sacar un balance contable correcto. En R/3 accedemos a las transacciones generalmente a trav´es del men´ u, pero tambi´en podemos acceder directamente tecleando su c´odigo de transacci´on en el campo de comandos. Los usuarios noveles no suelen utilizar este u ´ltimo m´etodo 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 c´odigo y lo utilizan. En la secci´on 2.14 veremos como se averigua el c´odigo de una transacci´on que estamos ejecutando.

´ 2.13. OPCIONES TECNICAS

2.13.

33

Opciones t´ ecnicas

Las opciones t´ecnicas del SAPGUI se encuentran en el u ´ltimo bot´on a la derecha de la barra est´andar 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 t´ecnicas

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 t´ecnicas

Opciones nos permite reconfigurar el aspecto de nuestro SAPGUI estableciendo nuevos colores, fuentes. Esta opci´on s´olo es v´alida para el modo de visualizaci´on 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 selecci´on a cualquier editor de texto ( bien sea dentro del Sistema R/3 como fuera de ´el ).

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

34

Generar Gr´ afico es una herramienta que nos crea una pantalla similar a la que estamos visualizando con la herramienta de gr´aficos de SAP R/3. S´olo 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 opci´on s´olo funciona con resoluciones de pantalla superiores a 800x600. Hardcopy (duplicado de pantalla) env´ıa la pantalla actual del SAPGUI a la impresora que tengamos configurada por defecto en el PC. Esta es una herramienta que est´a todav´ıa en desarrollo por SAP y que todav´ıa produce errores en la impresi´on de estas capturas debido a incompatibilidades con ciertos drives de monitores. Acerca de nos muestra los datos t´ecnicos de versi´on del SAPGUI que estamos utilizando.

2.14.

La pantalla status

Existe en SAP R/3 una ventana que nos informa sobre la conexi´on actual que hemos realizado en el sistema, as´ı como sobre los datos t´ecnicos referentes al sistema operativo, el sistema de gesti´on de base de datos del servidor y la versi´on de SAP instalada. A esta pantalla accederemos desde el men´ u Sistema→Status, el cual siempre se encuentra disponible desde cualquier punto de navegaci´on de SAP. En ella podemos distinguir varias partes que describimos a continuaci´on: Datos utilizaci´ on En esta parte se presentan los datos relativos a la conexi´on que el usuario ha realizado sobre SAP como el mandante, nombre de usuario, idioma de conexi´on, fecha y hora del sistema, as´ı como la fecha y hora de la conexi´on anterior que realiz´o ese mismo usuario sobre ese sistema. Se deber´a 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 coincidir´an. Datos SAP Este ´area est´a destinada a mostrar informaci´on t´ecnica sobre SAP R/3 y se compone de varias subpartes. La parte de Datos Repository se refiere a la transacci´on y programas asociados a dicha

2.14. LA PANTALLA STATUS

35

Figura 2.11: Status del sistema transacci´on desde donde se ha ejecutado la ventana Status. De particular importancia es el campo transacci´on, ya que es uno de los que m´as se consulta. La parte Datos Sistema SAP nos dice qu´e versi´on de R/3 est´a instalada en el servidor, el c´odigo que SAP asigna a nuestra instalaci´on, as´ı como la fecha de vencimiento de la licencia. La parte Release base nos informa de la versi´on base que tenemos instalada. Adem´as de la versi´on base podemos tener instalados algunos parches. SAP, peri´odicamente, env´ıa unos parches que arreglan errores en sus objetos est´andar 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 m´aquina, c´odigo de p´agina instalado y tipo de base de da tos.

Cap´ıtulo 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 aplicaci´on y capa de presentaci´on. La idea fundamental de la filosof´ıa cliente/servidor es la distribuci´on 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

CAP´ITULO 3. ARQUITECTURA DE UN SISTEMA R/3

38

1. Capa de base de datos . Servicios de base de datos para el salvado y recuperaci´on de los datos empresariales. 2. Capa de aplicaci´on. Servicios de aplicaci´on para el manejo de la l´ogica de aplicaci´on. 3. Capa de Presentaci´on. Servicios de presentaci´on para la implementaci´on del GUI. La arquitectura multicapa cliente/servidor le confiere al sistema R/3 las siguientes caracter´ısticas: Escalabilidad Permite la adici´on de nuevos equipos en cualquiera de sus 3 niveles para acomodarse a los requerimientos din´amicos del sistema. Portabilidad El software normalmente continua en vigencia m´as tiempo que el hardware que lo soporta, es por ello por lo que el software SAP R/3 se caracteriza por su portabilidad a trav´es de distintos tipos de hardware, sistemas operativos y RDBMS. Apertura Todos los datos est´an almacenados en tablas que son accesibles sin necesidad de instrucciones complejas de recuperaci´on de datos. Parametrizabilidad SAP R/3 es un software est´andar que dispone de herramientas espec´ıficas para la adaptaci´on 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 est´andar a la manera de trabajar de cada empresa. El Sistema R/3 sigue varios est´andares reconocidos internacionalmente e interfaces abiertos: TCP/IP RFC

Como protocolo de comunicaciones. Como el interface de programaci´on de m´as alto nivel. Funciones de aplicaci´on 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 integraci´on de aplicaciones de PC. X.400/X.500 Como el interface de email. EDI Para el intercambio de datos a nivel de aplicaci´on. ALE Para la integraci´on on line de aplicaciones descentralizadas.

3.2. SERVICIOS DE BASE DE DATOS

39

Debido a su arquitectura abierta no hay pr´acticamente ninguna restricci´on 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 manipulaci´on de datos, R/3 usa exclusivamente comandos del lenguaje SQL. Se dispone de 2 tipos diferentes de SQL: el Open SQL (extensi´on de lenguaje de programaci´on 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 cach´e de cliente consistente en bufferes especiales en cada servidor de aplicaci´on situados en la memoria principal. Reduce el tr´afico de red y los accesos a base de datos. La optimizaci´on de los bufferes es asegurada por el mecanismo de sobrescritura LRU (Least Recently Used) que consigue mantener en memoria

CAP´ITULO 3. ARQUITECTURA DE UN SISTEMA R/3

40

los datos m´as frecuentemente usados. Administraci´ on base de datos SAP SAP ha desarrollado una serie de herramientas para la administraci´on 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 aplicaci´on y control, as´ı como de los logs. BRRESTORE Herramienta para la restauraci´on de los datos de aplicaci´on y control, as´ı como de los logs. BRARCHIVE Herramienta para el archivado de los logs. SAPDBA Herramienta que integra todas las tareas de administraci´on de la base de datos.

3.3.

Servicios de aplicaci´ on

La capa de de aplicaci´on estar´a, en el caso m´as general, compuesto de multiples instancias; por lo que estos servicios estar´an 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, adem´as de un conjunto de bufferes en memoria compartida Los servicios de la capa de aplicaci´on se pueden clasificar en: Dialogo Actualizaci´on Gesti´on 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 tendr´a el nombre: <SID>_DVEBMGS00_

´ 3.3. SERVICIOS DE APLICACION

41

Servicios de di´ alogo Cuando un usuario est´a conectado a un sistema R/3 y realiza cualquier petici´on de informaci´on al sistema (por ejemplo visualizar una factura), esta petici´on es gestionada por el sistema a trav´es de una cola de trabajo o proceso llamado de di´alogo. Estos procesos act´ uan como interlocutores entre el usuario final y la base de datos. Servicios de actualizaci´ on El sistema est´a provisto de unas colas de trabajo especiales llamadas de actualizaci´on por donde gestionar´a las modificaciones de los datos de aplicaci´on en la base de datos. Servicio de gesti´ on de bloqueos Este servicio juega un papel muy importante y, como el anterior, s´olo 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 m´as de un usuario a la vez. Este servicio es absolutamente necesario para la integridad de los datos de aplicaci´on. 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 espec´ıficos para la realizaci´on de tareas, especialmente largas, que no requieran la intervenci´on del usuario final. De esta forma se podr´an planificar tareas pesadas como la carga o modificaci´on masiva de datos maestros sin que el usuario tenga que estar presente para su ejecuci´on. Servidor de mensajes Dentro de la capa de aplicaci´on hay una instancia entre el resto que provee el servicio de servidor de mensajes; este servicio es necesario para la comunicaci´on 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

CAP´ITULO 3. ARQUITECTURA DE UN SISTEMA R/3

42

Cada instancia necesita de este servicio para realizar tareas que se extienden m´as all´a de la instancia local: Servicio de Spool Este servicio es el encargado de gestionar las peticiones de impresi´on dentro de SAP R/3. -

Comunicaci´on entre diferentes sistemas R/3 Llamadas a funciones remotas CPIC (Common Programming Interface for Comunications) Conexi´on de sistemas externos tales como MAPI Server, sistemas EDI. . .

Existe un servicio de gateway por instancia y se activa autom´aticamente sin la intervenci´on del administrador cuando la instancia arranca.

Figura 3.3: Esquema del funcionamiento del dispatcher

Dispatcher y procesos de trabajo Los servicios de di´alogo, gesti´on de bloqueos, actualizaci´on, 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 presentaci´on y la de aplicaci´on ya que todas las peticiones que vienen del nivel de presentaci´on 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, acceder´an a la base de datos directamente con SQL. SAP R/3 funciona como un grupo de procesos de sistema trabajando en cooperaci´on 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 est´andares que aseguran uniformidad, integraci´on 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 documentaci´on sobre el uso de las aplicaciones R/3. Esta ayuda trabaja con referencias de hipertexto permitiendo la navegaci´on. Elementos de control Se dispone de campos de entrada para la introducci´on de datos, campos de salida para la visualizaci´on de los mismos, table control para la visualizaci´on de datos en formato de tabla, pushbuttons, casillas de selecci´on y radio buttons. Se implementan barras de desplazamiento cuando la informaci´on a visualizar en pantalla supera el tama˜ no de ´esta. Men´ us Todas las funciones implementadas en las aplicaciones R/3 pueden ser accedidas v´ıa menus desplegables. Estos men´ us desplegables se encuentran uniformemente estructurados a lo largo de todas las aplicaciones del sistema R/3 siguiendo una estructura arb´orea. Se permite, adem´as la creaci´on de men´ us propios de usuario. Barras de tareas La barra de tareas contiene los s´ımbolos de los comandos de navegaci´on m´as usados. Barras de botones Las funciones esenciales para el control de una aplicaci´on pueden ser accedidas a trav´es de las barras de botones. Valores de entrada posibles En casi todos los campos de entrada se dispone de una funci´on que nos permite visualizar los valores limitados para la introducci´on de valores.

Cap´ıtulo 4 Escenarios de configuraci´ on Cualquier entorno de software de gesti´on empresarial presenta la necesidad de tener sistemas completos (hardware y software) separados dedicados a funciones espec´ıficas. Entre estas funciones podemos destacar el desarrollo del software, las pruebas del mismo, la formaci´on a los usuarios finales y, la m´as importante de todas, la puesta en producci´on del software. SAP R/3 dispone de m´ ultiples alternativas de configuraci´on de escenarios. Cada empresa deber´a decidir, segun los criterios que veremos posteriormente, cual es la que mejor se ajusta a sus necesidades. Esta decisi´on, debido al car´acter 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 soluci´on determinada han cambiado.

4.1.

Consideraciones generales sobre los sistemas R/3

Siguiendo la definici´on 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 implantaci´on real. La base de datos de un sistema R/3 requiere aproximadamente unos 15 Gb1 de disco duro y cada servidor de aplicaciones necesitar´a unos 2 Gb. Un mandante que contenga u ´nicamente la parametrizaci´on b´asica ocupa unos 500 Mb, pero si le a˜ nadimos los datos de aplicaci´on 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

´ CAP´ITULO 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 hist´oricos 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 tambi´en los datos de sus pedidos y/o facturas. Del mismo modo, tampoco podemos separar los datos de m´odulos diferentes, una aplicaci´on 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 funci´on que van a cumplir, hay varios tipos de sistemas R/3. Vamos a describir los tres m´as habituales (desarrollo, integraci´on y producci´on) aunque dependiendo del tama˜ no y necesidades de la empresa SAP tambi´en contempla la posibilidad de tener un sistema de formaci´on 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 parametrizaci´on se llevan a cabo aqu´ı. Una vez que se han completado las pruebas unitarias de los programas, estos pueden ser transportados al sistema de integraci´on para hacer pruebas m´as 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 m´odulos del sistema. Tambi´en debemos probar 2

”Go Live”es el t´ermino ingl´es 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 m´odulos que interact´ uen entre s´ı. Pruebas de rendimiento Cargando el sistema de integraci´on con suficiente volumen de datos podemos probar la eficiencia de nuestro software permiti´endonos descubrir errores no funcionales pero que nos imposibilitan poner en explotaci´on los programas. Pruebas de usuario El usuario final no suele tener acceso al sistema de desarrollo as´ı que es en integraci´on donde debe comprobar que la funcionalidad del software es la que ´el pidi´o en sus especificaciones. Tambi´en le sirve para familiarizarse con los nuevos programas y su interface y solicitar cambios en la interacci´on si algo no es de su agrado. La formaci´on 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 funci´on importante la posibilidad de probar el sistema de transporte. Al pasar el software de desarrollo a integraci´on ya tenemos una prueba de como va a pasar de integraci´on a producci´on. Veremos el sistema de transporte detalladamente en cap´ıtulos posteriores.

4.2.3.

Sistema de producci´ on

El sistema de producci´on tiene una u ´nica funci´on: la explotaci´on 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 est´andar. En el caso de un sistema IDES existe tambi´en el mandante 800 que incluye un modelo de compa˜ nia completo para demostraciones y formaci´on. Las funciones de los mandantes est´andar son las siguientes:

48

´ CAP´ITULO 4. ESCENARIOS DE CONFIGURACION

Mandante 000 Es el mandante de referencia. No contiene datos de parametrizaci´on empresarial y por lo tanto las creaciones de mandante propios se deben hacer como copias de este para asegurarnos que empezamos la parametrizaci´on desde cero. Durante un cambio de versi´on de R/3 los datos dependientes de mandante se actualizan autom´aticamente 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 id´entico al 000 y salvo que lo cambiemos nosotros, ninguna actualizaci´on de R/3 lo va a modificar, al contrario de lo que ocurre con el 000. Siempre lo podemos tener como ejemplo de la instalaci´on inicial aunque SAP no impone ninguna prohibici´on 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 detecci´on de problemas de rendimiento. Los usuarios de este mandante tiene las autorizaciones m´ınimas 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 integraci´on alguno menos y en el sistema de producci´on solo debe existir un mandante propio. A continuaci´on 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 diferenciaci´on entre ellos. En nuestros sistemas R/3 nosotros podemos darle el n´ umero que queramos a cada mandante propio. Es posible implementar SAP con m´as o menos mandantes de los indicados pero hay que buscar el equilibrio entre muchos y pocos. Con pocos mandantes podemos tener conflictos durante la parametrizaci´on, 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

adem´as de requerir un mayor esfuerzo en los procedimiento de administraci´on de sistemas. Las funciones de los mandantes propios son las siguientes: Mandante 200 Desarrollo y parametrizaci´on 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 aplicaci´on trabajan en este sistema. No tendremos datos maestros ni transaccionales de manera que la pruebas las realizaremos en el mandante 220 despu´es de pasar todos los cambios hechos aqu´ı. Mandante 210 Trastero.3 Las pruebas inusuales de parametrizaci´on 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. Peri´odicamente 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 parametrizaci´on efectuar´an aqu´ı las pruebas unitarias del prototipo que se est´a creando. Aqu´ı si que tendremos datos maestros y transaccionales aunque no ser´an muy fiables debido a que la parametrizaci´on puede cambiarse. Mandante 300 Pruebas integradas y control de calidad en integraci´on. La funci´on de este mandante es similar a la del 220 pero con la diferencia de que las pruebas incluyen la interacci´on entre los diferentes m´odulos, rendimiento y aprobaci´on del usuario. Tambi´en se comprueba que el paso de las ´ordenes de transporte desde el sistema de desarrollo sea correcto como garant´ıa de que el paso de esas mismas ´ordenes a producci´on tambi´en lo sea. Mandante 310 Formaci´on 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 formaci´on y tengan un sitio donde poder seguir practicando despu´es. De esta manera, los datos maestros y transaccionales que crean no nos interfieren en nuestro trabajo de implantaci´on habitual. 3

El palabra que utiliza SAP es ”sandbox” que es una caja de arena en la que juegan los ni˜ nos. El t´ermino ha sido libremente traducido al castellano por los autores.

´ CAP´ITULO 4. ESCENARIOS DE CONFIGURACION

50

Mandante 320 Maestro de parametrizaci´on. Este mandante se usa u ´nicamente como referencia para poder consultar la parametricaci´on 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 funci´on 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 explotaci´on 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 hist´oricos.

4.4.

Comparaci´ on de escenarios

SAP tiene contemplados escenarios de configuraci´on desde un s´olo sistema hasta cuatro. El escenario que aconseja en todas sus especificaciones t´ecnicas es el de tres sistemas aunque tambi´en es aceptable trabajar con dos (si las necesidades de la empresa no son muy grandes). Trabajar con un s´olo sistema R/3 es un caso excepcional como veremos m´as adelante. Vamos a ver esquem´aticamente 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 m´aquina los costes de hardware son m´ınimos. Todo el trabajo del transporte de elementos de desarrollo queda suprimido con lo que la administraci´on del sistema se simplifica en cierto modo. Desventajas Tendremos problemas con las tablas independientes de mandante. Problemas durante la instalaci´on 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 m´aquina ser´a 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 configuraci´on. 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 b´asico les sirve para empezar a trabajar. La realidad demuestra m´as 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 pod´ıan. La reducci´on inicial de costes en hardware tambi´en resulta enga˜ nosa porque en el presupuesto de un proyecto de implantaci´on 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 impresi´on de que es ´ importante reducirlo al m´ınimo. Unicamente se aconseja esta configuraci´on para centros de formaci´on o demostraci´on del producto.

4.4.2.

Configuraci´ on con dos sistemas (Desarrollo y Producci´ on)

Ventajas Todos los desarrollos nuevos y la parametrizaci´on 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 m´aquina a la que no puede acceder el personal de desarrollo, de esta manera garantizamos la confidencialidad de nuestra informaci´on. Este punto puede ser en algunos caso vital, estrat´egicamente hablando, o incluso de obligado cumplimiento legal, en el caso de la informaci´on relativa a empleados, clientes y proveedores. La inversi´on en hardware es reducida. El sistema de desarrollo puede ser una m´aquina de caracter´ısticas inferiores a la de productivo y estaremos ajustando bastante nuestro presupuesto. Desventajas

´ CAP´ITULO 4. ESCENARIOS DE CONFIGURACION

52

La cantidad y el ´ambito de actuaci´on de los desarrollos que hagan estar´a limitado por la falta de un sistema dedicado a las pruebas integradas. Tendremos que hacer el control de calidad y las pruebas de aceptaci´on de usuario en el mismo sistema en el que desarrollamos lo que puede implicar la interrupci´on 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 versi´on nos dejan inservible el sistema de desarrollo durante todo el tiempo que dura la actualizaci´on de versi´on. Conclusi´ on Esta es la soluci´on m´ınima que acepta SAP para una empresa que pretenda sacar rentabilidad de R/3. Es una opci´on correcta para empresas con un peque˜ no n´ umero de desarrollos y que implanta s´olo uno o dos m´odulos lo que reduce la cantidad de parametrizaci´on a realizar. A medida que la empresa vaya instalando m´as m´odulos 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 configuraci´on desde hace varios a˜ nos y funcionan correctamente con ella. En el caso de un cambio de versi´on, que es uno de los proyectos complicados que requieren una m´aquina aparte, la soluci´on por la que se opta consiste en alquilar durante el tiempo de la actualizaci´on de versi´on una m´aquina de pruebas o subcontratar la migraci´on a una consultor´ıa externa que tenga m´aquinas disponibles para ello.

4.4.3.

Configuraci´ on con tres sistemas (Desarrollo, Integraci´ on y Producci´ on)

Ventajas La instalaci´on de aplicaciones o m´odulos adicionales se puede hacer sin afectar al trabajo habitual de desarrollo. La existencia del mandante trastero en el sistema de desarrollo facilita la familiarizaci´on con las funcionalidades de los m´odulos y la realizaci´on de pruebas sin peligro.

´ DE ESCENARIOS 4.4. COMPARACION

53

Disponemos del sistema de integraci´on para la realizaci´on de pruebas de rendimiento, pruebas de aceptaci´on de usuario, formaci´on a usuarios. . . Tres es el n´ umero m´ınimo de sistemas que hacen falta para poder probar el sistema de transporte. Al tener integraci´on 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 integraci´on. 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 producci´on por una mala gesti´on del sistema de transporte. Desventajas Necesitamos una inversi´on mayor en hardware, tanto en m´aquinas para albergar los sistemas R/3 como en hardware auxiliar de comunicaciones, copias de respaldo, administracion de red. . . La administraci´on del sistema se complica y por lo tanto necesitaremos m´as personal y que adem´as est´e bien formado en estas tareas. Este punto es realmente importante porque si no somos cuidadosos en la gesti´on 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 dec´ıamos al principio ´esta es la configuraci´on que recomienda SAP y es la que utilizan la mayor´ıa de las empresas grandes que tienen presupuesto y personal suficiente para gestionar todos los sistemas. Cuando se instalan muchos m´odulos diferentes y de ´areas diferentes (log´ıstica, finanzas y recursos humanos) se hace necesario tener un sistema aislado para las pruebas integradas. Un configuraci´on con cuatro sistemas solo ser´a necesaria para empresas que tengan un vol´ umen de desarrollos propios realmente grandes. Como se puede suponer, la gesti´on de un sistema as´ı requiere de personal realmente cualificado y de una metodolog´ıa y procedimientos de transporte que eviten cualquier error ajeno a los desarrollos en s´ı mismos.

Cap´ıtulo 5 Monitorizaci´ on de procesos y usuarios Una de las tareas b´asicas de administraci´on de un sistema SAP R/3 consiste en la monitorizaci´on de los procesos activos en las instancias que conforman el sistema – ya sea en el entorno de desarrollo, integraci´on o producci´on -, as´ı como qu´e usuarios han ejecutado tales procesos. Ser´a labor del administrador el evitar que se ejecuten procesos demasiado pesados que provoquen una ralentizaci´on 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 qu´e usuario ha lanzado qu´e proceso. Adem´as, este monitor nos informa de qu´e procesos han sido lanzados en di´alogo y qu´e procesos corren en modo batch. Este monitor puede ser accedido directamente por la transacci´on SM50 o alternativamente por el men´ u desplegable Herramientas→Gesti´on→ Monitor→Supervisar Sistema→Resumen Procesos. En la pantalla de la figura 5.1 podemos ver qu´e usuario est´a realizando peticiones al sistema, as´ı como el tipo de proceso de trabajo que est´a gestionando tales peticiones. Explicaremos la informaci´on m´as 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 CAP´ITULO 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 di´alogo batch de actualizaci´on V1 de actualizaci´on 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 c´odigo 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 est´a 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 petici´on de usuario y cuya actividad ha sido cancelada autom´aticamente por el sistema o por el administrador del mismo. Los procesos con tales status no pueden volver a gestionar ninguna petici´on 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 reactivar´a autom´aticamente. El valor por defecto es ”S´ı”, y es el valor que deberemos dejar para que los procesos est´en siempre activos aunque sufran alg´ un error en su ejecuci´on. Errores t´ıpicos en la ejecuci´on de peticiones de usuario son la terminaci´on manual de alg´ un modo por parte del usuario. Para cambiar este valor de S´ı a No o viceversa deberemos acudir a la opci´on del men´ u desplegable Proceso→Reanudar tr´as error. La columna Error nos indica el n´ umero de errores que un proceso de trabajo ha sufrido desde que se arranc´o el sistema por u ´ltima vez. La columna Sem´ aforo nos indica el n´ umero de sem´aforo 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 c´odigos a cada proceso de trabajo. El sem´aforo para escritura en fichero del sistema operativo es ”22”. La columna CPU es el tiempo de CPU que est´a consumiendo actualmente el proceso de trabajo en formato minutos:segundos. Esta informaci´on por defecto no est´a activa, ya que su propia visualizaci´on consume recursos del sistema. Para activarlo deberemos acudir a la barra de aplicaciones y pulsar el bot´on CPU. La columna Hora nos indica el tiempo en segundos que ese proceso est´a activo. La columna Report nos indica el programa que internamente est´a ejecutando el sistema para gestionar la petici´on de usuario. Todas las pantallas de SAP tienen por detr´as un programa en c´odigo 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 volver´a 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 est´a ejecutando ese proceso. La columna Usuario nos indica el usuario que ha realizado la petici´on al sistema asociada a ese proceso de trabajo. La columna Acci´ on indica el tipo de acci´on que es llevada a cabo sobre la base de datos para gestionar la petici´on de ese usuario. Acciones t´ıpicas pueden ser: Lectura secuencial, lectura directa, insert, update, delete. Para m´as informaci´on sobre las acciones que ese proceso est´a realizando posicionaremos el cursor sobre el proceso deseado y a continuaci´on

58

´ DE PROCESOS Y USUARIOS CAP´ITULO 5. MONITORIZACION

pulsaremos el bot´on Detalle de la barra de aplicaciones. La barra de aplicaciones nos permite tambi´en refrescar el contenido de la pantalla. Deberemos tener en cuenta que el monitor de esta pantalla se activar´a exclusivamente cuando pulsemos el bot´on refrescar, por lo que si deseamos tener en pantalla y en todo momento informaci´on actualizada sobre los procesos actualmente en curso deberemos pulsar continuamente el bot´on de refresco. Otra opci´on que nos brinda la barra de aplicaciones del monitor de procesos activos es la de borrar el modo de usuario asociado al proceso en cuesti´on. Esta opci´on se deber´a usar con cuidado y siempre con el consentimiento del usuario ya que podemos provocar p´erdida de datos si cancelamos un modo que est´e 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 depuraci´on 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 programaci´on en tiempo de ejecuci´on. Los procesos actualmente activos en la instancia en la que estamos conectados se pueden cancelar manualmente por el administrador del sistema con la opci´on del men´ u desplegable Proceso→Cancelar 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 opci´on con core genera un fichero llamado core donde queda registrada la raz´on de la cancelaci´on del proceso. Como este fichero no es editable, elegiremos la opci´on sin core para no crear en los discos duros informaci´on que no vayamos a usar. La cancelaci´on manual de un proceso debe ser realizada con extremo cuidado y siempre deberemos asegurarnos que dicha cancelaci´on no provoque ning´ un problema de inconsistencia en los datos de SAP. Es muy importante tener en cuenta que la informaci´on visualizada en la transacci´on SM50 se limita exclusivamente a la instancia a la que estemos conectados. Si nuestro sistema R/3 est´a formado por varias instancias, para poder visualizar los procesos de cada una de ellas tendremos que realizar cualquiera de las siguientes acciones: 1. Conectarnos directamente a cada una para visualizar la SM50 (recordemos que el nombre del servidor sobre el que est´a montado la instancia aparece en todo momento en la barra de estado). 2. Acudir directamente a la transacci´on SM51 (Herramientas→ Gesti´on→ Monitor→Supervisar Sistema→Servidor ). En la transacci´on SM51 visualizamos las instancias que est´an activas y que componen el sistema SAP. Desde esta transacci´on podremos saber

´ DE PROCESOS ACTIVOS 5.1. MONITORIZACION

59

Figura 5.2: Monitor de instancias activas

si un sistema SAP es distribu´ıdo o si por el contrario est´a 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 est´a instalada la instancia SAP y por u ´ltimo, en la columna Tipo se visualizan los tipos de procesos de trabajo que est´an dados de alta en esa instancia. En la barra de aplicaciones de esa pantalla tenemos la opci´on de refresco para actualizar la informaci´on. Tambi´en tenemos la opci´on Procesos que nos lleva directamente a la transacci´on SM50 de cada una de las instancias sin m´as que posicionar el cursor sobre la instancia deseada y pulsar el bot´on descrito. Accedemos a la misma transacci´on si hacemos doble click sobre cada una de las instancias. La opci´on Usuarios nos muestra un listado con los usuarios conectados a la instancia que hayamos elegido. Esta opci´on la veremos m´as a fondo en la siguiente secci´on. La opci´on Log del sistema nos lleva a la transacci´on SM21 que est´a descrita en el cap´ıtulo 8. La opci´on Colector SO nos muestra informaci´on t´ecnica acerca del sistema operativo tal como el n´ umero de procesadores, el porcentaje de utilizaci´on CPU, la cantidad de memoria disponible y libre, e informaci´on sobre la paginaci´on. Esta opci´on se encuentra disponible

60

´ DE PROCESOS Y USUARIOS CAP´ITULO 5. MONITORIZACION en el men´ u desplegable Pasar a→ Collector SO.

Figura 5.3: Monitor de sistema operativo

La opci´on Login remoto nos abre un modo sobre la instancia previamente seleccionada. El modo nuevo nos accede al men´ u inicial de conexi´on a SAP. La opci´on Info Release nos muestra informaci´on sobre la versi´on del kernel de SAP instalado en la instancia que hayamos elegido. El kernel de SAP est´a formado por ficheros ejecutables compilados en lenguaje C necesarios para el arranque y funcionamiento de SAP. 3. Ejecutar la transacci´on SM66 de Procesos Globales activos (Herramientas→ Gesti´on→ Monitor→ Rendimiento→ Exceptions/Users→ Active Users→ All Processes) que se muestra en la figura 5.4

Figura 5.4: Monitor global de procesos activos

´ USUARIOS CONECTADOS 5.2. MONITORIZACION

5.2.

61

Monitorizaci´ on usuarios conectados

Otra tarea b´asica de administraci´on que se complementa con la monitorizaci´on de procesos activos es la monitorizaci´on 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 informaci´on es mostrada en la transacci´on SM04 Herramientas→ Gesti´on→ Monitor→Supervisar Sistema→ Usuarios Conectados.

Figura 5.5: Monitor de conexi´on de usuarios por instancia

La pantalla de usuarios conectados nos da la siguiente informaci´on: 1. Mandante de conexi´on . 2. Nombre de usuario en SAP . 3. Nombre del servidor de presentaci´on desde donde se ha realizado la conexi´on. 4. C´odigo de transacci´on perteneciente al modo actualmente activo . 5. Hora a la que se ejecut´o por u ´ltima vez alg´ un proceso desde el modo activo asociado a la conexi´on f´ısica que estamos visualizando. 6. Cantidad de modos abiertos por el usuario .

62

´ DE PROCESOS Y USUARIOS CAP´ITULO 5. MONITORIZACION

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 cap´ıtulo 2. Cada l´ınea de este listado corresponde con una conexi´on f´ısica al sistema por usuario. Este monitor tiene adem´as 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 bot´on Modos, o alternativamente, haciendo doble click sobre un usuario, el sistema nos muestra una ventana de di´alogo con un listado de los modos abiertos por usuario y conexi´on f´ısica.

Figura 5.6: Lista de modos activos por usuario Esta ventana nos muestra en orden de apertura los modos abiertos por el usuario y conexi´on f´ısica elegidos, as´ı como la hora a la que se ha realizado la u ´ltima petici´on de informaci´on por tales modos. Tambi´en tenemos la opci´on de borrar el modo que queramos. Con esta u ´ltima opci´on estaremos cerrando remotamente al usuario la pantalla asociada a ese modo. Esta opci´on habr´a que usarla siempre con el consentimiento del usuario y con extremo cuidado. Tal acci´on de borrado manual de modo queda reflejado en el log del sistema – ver cap´ıtulo 8 –. Otra opci´on de la barra de aplicaciones es la de refresco de pantalla. Esta opci´on es muy u ´til ya que el sistema s´olo nos estar´a mostrando la informaci´on actualizada cada vez que pulsemos la funci´on de refresco. Tambi´en podremos ordenar el listado por la columna deseada tanto en orden ascendente como descendente. Como una tercera opci´on de la barra de aplicaciones el sistema, si pulsamos el bot´on Info Usuario, nos muestra en una ventana de di´alogo el

´ USUARIOS CONECTADOS 5.2. MONITORIZACION

63

nombre, apellido, departamento y extensi´on telef´onica asociados al usuario elegido. Estos datos aparecer´an siempre y cuando se hayan introducido en el maestro de usuarios cuando se cre´o el usuario.

Figura 5.7: Informaci´on detalllada de usuario

Ser´a 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 b´asicos como el nombre, departamento, tel´efono de contacto para que la gesti´on y monitorizaci´on de tales usuarios resulte m´as sencilla. La limitaci´on 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 mostrar´a 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 conexi´on f´ısica por cada instancia de las que se componga nuestro sistema SAP e iniciar desde cada conexi´on la transacci´on SM04. En un u ´nico modo acudir a la transacci´on SM51 y desde ah´ı y posicion´andonos en cada una de las instancias activas pulsaremos el bot´on Usuario de la barra de aplicaciones. De esta manera tendremos un listado de usuarios por cada instancia. Desde el men´ u desplegable inicial de SAP ejecutar Gestion→ Monitor→ Rendimiento→ Exceptions/Users→ Active Users, o alternativamente ejecutar la transacci´on AL08 que se muestra en la figura 5.8. Esta transacci´on muestra los usuarios actualmente conectados al sistema y agrupados por instancia de conexi´on.

64

´ DE PROCESOS Y USUARIOS CAP´ITULO 5. MONITORIZACION

Figura 5.8: Usuarios conectados vistos en la transacci´on AL08

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 m´as de un mandante donde est´en definidos los usuarios, el listado no ser´a completo.

Cap´ıtulo 6 Procesamiento en fondo 6.1.

Conceptos de procesamiento en fondo

Adem´as de la opci´on de ejecutar programas y transacciones online, SAP nos da la posibilidad de ejecutar procesos en fondo.Podemos encontrarnos con otros t´erminos para referirse al mismo concepto como procesamiento batch o procesamiento en segundo plano. Simplemente consiste en la ejecuci´on de un proceso sin interacci´on con el usuario, es decir, que lanzamos el proceso y el sapgui nos devuelve el control aunque el programa todav´ıa no ha acabado de ejecutarse. Este modo de ejecuci´on 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 m´as de dos segundos entre dos acciones del usuario sobre el programa. Parece poco probable que un usuario este esperando m´as 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 m´as tiempo deber´ıa 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 m´as 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 deber´a hacer cuando los procesos no sean cr´ıticos para la obtenci´on de datos en tiempo real; es la direcci´on 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

CAP´ITULO 6. PROCESAMIENTO EN FONDO

66

6.2.

Definici´ on de jobs

Un job es conjunto de uno o m´as programas que se lanzan consecutivamente en proceso de fondo. Para crear un job 1 utilizaremos la transacci´on SM36, a la que se llega a traves de Herramientas→ CCMS→ Jobs→ Definici´on, y que nos muestra la pantalla de la figura 6.1

Figura 6.1: Pantalla inicial de definici´on de job

La definici´on de un job tiene tres ´areas principales: Informaci´on general Hora de inicio o evento de ejecuci´on Pasos

6.2.1.

Informaci´ on general

La informaci´on general conforma la base de la definici´on del job. Primeramente debemos darle un nombre que defina el prop´osito 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 s´olo podremos referirnos al job por su nombre. 1

SAP utiliza la palabra definir para la acci´on de crear un job

´ DE JOBS 6.2. DEFINICION

67

Otro datos de informaci´on general es la clase de job que indica a SAP la prioridad de ejecuci´on de los procesos que le mandamos y en funci´on de ello asigna los recursos adecuadamente. La clases posibles son: A La m´as alta prioridad. Se utiliza para procesos que son cr´ıticos para el funcionamiento del sistema. B Prioridad media. Para procesos peri´odicos 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 espec´ıficas 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 ejecuci´on. Por u ´ltimo, tenemos la posibilidad de determinar espec´ıficamente el servidor de aplicaciones que dara curso a nuestra petici´on 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 caracter´ısticas generales del job tenemos que indicar cu´ando debe ejecutarse. Esta indicaci´on puede hacerse de diversas formas: Ejecuci´on inmediata. Como su propio nombre indica nos permite iniciar el job en el momento de acabar su definici´on. Ejecuci´on por fecha/hora. Deberemos indicarle un d´ıa y una hora en la que queramos que comience el job. Adem´as podemos marcar el job como peri´odico, es decir, que se repetir´a su ejecuci´on cada cierto periodo de tiempo (cada d´ıa, cada 35 minutos. . . ). Esta opci´on es muy u ´til para la planificaci´on de jobs de mantenimiento o de recolecci´on de estad´ısticas, de hecho, al instalar SAP ya existen una serie de jobs de estas caracter´ısticas. Por job. Con esta indicaci´on 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 s´olo comience cuando la finalizaci´on del job A sea correcta, en caso de que el job A haya sido cancelado en mitad de su ejecuci´on el job B no se ejecutar´a. Por evento. El job comenzar´a cuando se produzca en el sistema el evento que le indiquemos.

CAP´ITULO 6. PROCESAMIENTO EN FONDO

68

Un evento es un suceso se produce autom´aticamente 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 operaci´on de nocturno a diurno, etc. El administrador o los desarrolladores pueden crear otros eventos a conveniencia. Estos pueden dispararse desde programas en ejecuci´on o podemos lanzarlos manualmente a trav´es del men´ u Herramientas→ CCMS→ Jobs→ Lanzar evento.

6.2.3.

Pasos

Tras definir c´omo y cu´ando queremos que se procese el job, por u ´ltimo, vamos a decirle qu´e 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 est´andar o creado por nosotros al que le indicaremos una variante que contenga los par´ametros de selecci´on de ese programa. Un comando externo que se ejecutar´a 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 cl´asico es la ordenaci´on 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 gesti´on 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 cancelaci´on, ninguno de los otros dos pasos restantes se procesar´a. 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 situaci´on a trav´es de la transacci´on SM37 o por el men´ u Herramientas→ CCMS→ Jobs→ Actualizaci´on que nos muestra la pantalla de la figura 6.2.

´ 6.3. ANALISIS DE JOBS

69

Figura 6.2: Pantalla inicial de selecci´on de jobs

Inicialmente tendremos que introducir los criterios de selecci´on 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 selecci´on 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 informaci´on que m´as nos interesa es el estado en el que se encuentra, en la siguiente secci´on 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 elecci´on del nombre no es muy acorde a su significado real porque un job que esta previsto no se ejecutar´a nunca a menos que lo liberemos o modifiquemos la secci´on 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

CAP´ITULO 6. PROCESAMIENTO EN FONDO

70

liberado. En este estado permanecer´a hasta que se cumpla la condici´on 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 estar´a 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 est´an en estado listo. Activo El job se est´a procesando. Podemos ver el log desde este momento y ver lo que est´a haciendo. Finalizado El job complet´o su ejecuci´on correctamente. Cancelado Alg´ un problema hizo que el job finalizara de manera incorrecta. Normalmente se producen cancelaci´on 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 cancelaci´on.

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 composici´on 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 est´a activo – porque la transacci´on SM37 as´ı nos lo dice – realmente no lo est´a. 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 est´a opci´on 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 dir´a que el proceso ya no est´a en activo y nos pregunta si queremos pasarlo a estado cancelado. Cancelar job activo Con esta opci´on detenemos un job activo y lo pasamos directamente a estado cancelado. Si tuviera un job encadenado a continuaci´on este no se procesar´a. Borrar . Una vez terminado o cancelado un job podemos borrarlo manualmente de la lista con este punto del men´ u. Liberado→Previsto Para poder deshacer la liberaci´on de un job utilizaremos esta opci´on. Es muy u ´til para no tener que borrar y redefinir un job que hemos liberado a una hora concreta y despu´es 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 opci´on y liberaremos cada una de las copias convenientemente. Si queremos que se ejecute m´as veces deber´ıamos pensar en la posibilidad de crear un job peri´odico. Modificar Siempre y cuando no haya comenzado la ejecuci´on del job (mientras este en previsto o liberado) podremos modificar cualquier dato de la definici´on del mismo. Repetir previsi´ on Esta opci´on es muy similar a la de copiar pero adem´as 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 opci´on cambiamos el servidor de destino de un job que no este activo.

72

CAP´ITULO 6. PROCESAMIENTO EN FONDO

Capturar job activo Para comprobar en que punto va la ejecuci´on del proceso que hemos lanzado podemos capturar un job que este activo. Al pulsar este opci´on se nos abre un modo nuevo con el depurador (debugger ) de ABAP/4 parado en el punto del programa que estuviera en ese momento. S´olo tiene hacer esto sentido si conocemos y entendemos el c´odigo fuente del programa que se procesa. Adem´as hay que ser cauteloso con est´a opci´on ya que hay determinadas fases de un programa ABAP en las que el hecho de activarse el debugger provoca una cancelaci´on con dump debido a un commit work impl´ıcito en la base de datos. Detalles de job Aqu´ı podemos ver datos internos del job. El m´as interesante es comprobar en que servidor de aplicaciones se est´a procesando y en n´ umero de cola BTC para poder monitorizar su estado y/o rendimiento con la transacci´on SM51.

Cap´ıtulo 7 Servicios de actualizaci´ on El servicio de actualizaci´on 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 trav´es de procesos de trabajo tipo di´alogo, batch o update.

7.1.

Actualizaci´ on s´ıncrona y as´ıncrona

La actualizaci´on en la base de datos de un sistema R/3 es mayoritariamente as´ıncrona, es decir, el sistema gestiona la petici´on de actualizaci´on 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 actualizaci´on, 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 di´alogo del usuario no espera a que se terminen las actualizaciones para seguir procesando las peticiones de ese usuario. La actualizaci´on as´ıncrona no se realiza directamente en los procesos de di´alogo, sino que se gestionan en procesos de actualizaci´on espec´ıficos. En la figura 7.1 se muestra en forma esquem´atica c´omo las actualizaciones as´ıncronas pertenecientes a un proceso de trabajo a un usuario son lanzadas en paralelo. La actualizaci´on s´ıncrona, aunque es menos frecuente, tambi´en se produce en un sistema R/3, y se diferencia de la as´ıncrona en que la petici´on de actualizaci´on en la base de datos se genera en el mismo proceso de trabajo que gestiona el resto de peticiones del usuario – di´alogo si el usuario est´a trabajando en online o batch si el usuario ha dejado programado un job –. De esta forma el proceso de di´alogo o batch debe esperar a que se realicen las actualizaciones en la base de datos antes de seguir procesando el resto de 73

74

´ CAP´ITULO 7. SERVICIOS DE ACTUALIZACION

Figura 7.1: Esquema funcionamiento actualizaci´on as´ıncrona

peticiones del usuario, por lo que el rendimiento ser´a peor que en el caso de la actualizaci´on as´ıncrona. En la figura 7.2 se muestra en forma esquem´atica c´omo las actualizaciones s´ıncronas pertenecientes a un proceso de trabajo asociado a un usuario son lanzadas en el mismo proceso, obligando al proceso a esperar a que la actualizaci´on termine para poder continuar.

Figura 7.2: Esquema funcionamiento actualizaci´on s´ıncrona

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 s´ıncrona o as´ıncrona, ya que esto depende de la programaci´on de la aplicaci´on en curso. Si se trata de actualizaciones dentro de alguna aplicaci´on hecha a medida ser´a tarea del analista de la aplicaci´on el decidir qu´e tipo de actualizaci´on realizar. En lo que sigue nos ce˜ niremos a la actualizaci´on as´ıncrona, que a la postre es la que juega un papel m´as importante en un sistema SAP R/3.

7.2.

Procesos de actualizaci´ on V1 y V2

La actualizaci´on as´ıncrona presenta adem´as una ventaja adicional: implementa las LUW 1 . Las LUWs consisten en bloques autoconsistentes de datos, de tal forma que su actualizaci´on en la base de datos es llevada a cabo completamente. Si surgiera alg´ un problema en la base de datos la grabaci´on de cada LUW no se realizar´ıa, de esta manera se evitan las inconsistencias que pudieran surgir al grabar una LUW a medias. La actualizaci´on as´ıncrona, consiste de 2 tipos de actualizaci´on : V1 y V2. El sistema R/3 distingue entre componentes de actualizaci´on cr´ıtica primaria (V1) y secundaria no cr´ıtica (V2). La diferenciaci´on entre estos dos tipos de actualizaci´on permite que el sistema procese los cambios cr´ıticos en la base de datos por delante de los cambios menos cr´ıticos asign´andoles 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 supervisi´on del gestor de bloqueos de SAP R/3 que impide que varias modificaciones sobre el mismo objeto se realicen concurrentemente. Las componentes de actualizaci´on V1 y V2 se procesan por distintos procesos de trabajo, siempre que en el sistema existan procesos de actualizaci´on 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 tambi´en 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 activaci´on y desactivaci´on gen´erica de los servicios de actualizaci´on, as´ı como para la mon1

Logical units of work o unidades l´ ogicas de trabajo

76

´ CAP´ITULO 7. SERVICIOS DE ACTUALIZACION

itorizaci´on 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 actualizaci´on con lo cual todas las modificaciones a realizar en la base de datos se quedan en un estado de espera hasta que la actualizaci´on vuelva a estar activa. Esta desactivaci´on autom´atica tiene lugar en aras de preservar la integridad de la base de datos y su ejecuci´on queda registrada en el log del sistema (ver Cap´ıtulo 8). Ser´a tarea del administrador el subsanar el error que produjo la desactivaci´on de la actualizaci´on del sistema y su posterior activaci´on. La actualizaci´on es activada autom´aticamente cada vez que el sistema SAP R/3 es arrancado en el servidor, por lo que s´olo se deber´a monitorizar su posible desactivaci´on. La transacci´on desde donde podremos gestionar centralmente la actualizaci´on es la SM13, o alternativamente por el men´ u deplegable Herramientas → Gesti´on → Monitor → Actualizaci´on.

Figura 7.3: Pantalla principal monitor actualizaci´on

En ella, b´asicamente, se nos muestra si la actualizaci´on del sistema est´a activa o ha sido desactivada por alguna causa. Si la actualizaci´on ha sido desactivada, el bot´on Info nos proporciona qu´e proceso y usuario han causado su desactivaci´on. El resto de campos son campos de selecci´on para monitorizar las actualizaciones que han tenido lugar y han fallado o las que est´an en curso. Como campos de selecci´on tenemos:

7.4. ACTUALIZACIONES INTERRUMPIDAS

77

Mandante

Por defecto aparece el mandante al que nos hemos conectado. Usuario Por defecto aparece el c´odigo de usuario con que nos hemos conectado al sistema. Status Podremos elegir las actualizaciones que se han cancelado, las que todav´ıa 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 m´ınima 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 transacci´on, de la posibilidad de activar como de desactivar la actualizaci´on del sistema. El administrador puede, en caso necesario, desactivar la actualizaci´on para evitar una situaci´on cr´ıtica si se ha detectado alg´ un problema grave en la base de datos. Esta opci´on se encuentra en la transacci´on SM13, en el men´ u desplegable Regs. Actualizaci´on → Actualizaci´on → Desactivar (existe a este nivel tambi´en la opci´on 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 an´alogo 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 programaci´on o por la cancelaci´on abrupta del proceso de actualizaci´on desde el servidor de presentaci´on debido a una ca´ıda del flu´ıdo el´ectrico o a una interrupci´on deliberada del sistema por parte del usuario. Las actualizaciones interrumpidas por este tipo de problemas las deber´a supervisar el equipo de desarrollo de la aplicaci´on en cuesti´on,

78

´ CAP´ITULO 7. SERVICIOS DE ACTUALIZACION y a la postre deber´an ser ellos quienes decidan qu´e hacer con estas actualizaciones. Un registro de actualizaci´on puede tener uno de los siguientes 6 estados:

1. Init. El registro no ha sido procesado todav´ıa. 2. Auto. El registro ser´a autom´aticamente actualizado cuando la actualizaci´on del sistema se active. 3. Run. El registro de actualizaci´on est´a 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 configuraci´on por defecto) por lo que ser´a muy dificil visualizar un registro en este status. 6. Err. Un error caus´o la interrupci´on de la actualizaci´on del registro. Para visualizar los registros de actualizaci´on interrumpidas acudiremos a la transacci´on SM13 y elegiremos el status C ¸ ancelado” en la pantalla de selecci´on. A continuaci´on pulsamos ejecutar y el sistema nos mostrar´a 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 actualizaci´on, as´ı como la fecha y hora y transacci´on desde d´onde se ha realizado la actualizaci´on. Como u ´ltimo campo tenemos el estado actual del registro de actualizaci´on.

7.4. ACTUALIZACIONES INTERRUMPIDAS

79

Si queremos disponer de m´as informaci´on acerca de los distintos m´odulos que componen el registro de actualizaci´on podremos hacer doble click sobre ´el o posicionar el cursor en la l´ınea deseada y a continuaci´on pulsar el bot´on de M´ odulos de Actualizaci´on en la barra de aplicaciones. A continuaci´on se nos mostrar´a una pantalla similar a la de la figura 7.5.

Figura 7.5: M´odulos de actualizaci´on

En esta pantalla se nos divide el registro de actualizaci´on en varios m´odulos y se nos especifica si pertenecen a la parte V1 o V2. Conjuntamente con el departamento de desarrollo y los usuarios finales se deber´a decidir qu´e hacer con los registros de actualizaci´on interrumpidos. Estos registros pueden ser: Contabilizados Esta opci´on es para procesar registros de actualizaci´on que se encuentren en status init. Para ejecutar esta opci´on deberemos posicionar el cursor sobre el registro deseado y elegir la opci´on Regs. Actualizaci´on → Contabilizar → Uno por uno (existe tambi´en la opci´on de contabilizar todos los registros visualizados). Grabados posteriormente Opci´on para registros cuya parte V1 haya sido realizada y quede por hacer la parte V2. Con esta opci´on se contin´ ua con la grabaci´on. Esta opci´on se encuentra en Regs. Actualizaci´on → Grabar Posteriormente → Uno por uno (existe tambi´en la opci´on de grabar posteriormente todos los registros visualizados). Reiniciados En casos aislados, un registro de actualizaci´on se puede quedar indefinidamente es estatus Run” aunque realmente no se est´a procesando. La opci´on Reiniciar en Regs. Actualizaci´on →

´ CAP´ITULO 7. SERVICIOS DE ACTUALIZACION

80

Reinicializar → Status orden actualizaci´on → Uno por uno (existe tambi´en la opci´on de reiniciar todos los registros visualizados) deja el registro preparado para ser procesado de nuevo. Borrados Opci´on para eliminar los registros de actualizaci´on. Esta opci´on se encuentra en Regs. Actualizaci´on → Borrar → Uno por uno (existe tambi´en la opci´on 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 ser´a el paso previo a la repetici´on del proceso de actualizaci´on del objeto en cuesti´on –alta de material, alta de apunte contable, modificaci´on de pedido– desde la aplicaci´on correspondiente.

7.5.

Entradas de bloqueo

SAP R/3 dispone de un sistema de gesti´on de bloqueos de objetos para evitar la modificaci´on 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 informaci´on 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 indic´andole que un usuario ya est´a tratando el objeto solicitado. Los bloqueos se establecen al iniciar las transacciones de modificaci´on y no son liberados hasta que el usuario pulsa ”Grabar”, la informaci´on es actualizada en la base de datos y la transacci´on es finalizada. Toda modificaci´on de un objeto desde cualquier aplicaci´on est´andar dentro de SAP R/3 genera entradas de bloqueo. Ser´a 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 transacci´on 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 → Gesti´on → Monitor → Entradas de bloqueo. En esta pantalla disponemos de unos par´ametros de selecci´on para filtrar los bloqueos actualmente activos. Los par´ametros son tabla, argumento de bloqueo, mandante y usuario. En general no conoceremos el argumento de bloqueo, ya que esa informaci´on depende del objeto que se est´e modificando. Es m´as normal conocer la tabla o usuario que est´a produciendo un bloqueo.

7.5. ENTRADAS DE BLOQUEO

81

Figura 7.6: Pantalla principal entradas de bloqueo

Por defecto, el campo mandante y usuario est´an rellenos con los valores por defecto. Una vez rellenos los par´ametros de selecci´on con los valores deseados pulsamos el bot´on ”Enter” en la barra de aplicaciones y nos aparecer´a un listado con las entradas de bloqueo que cumplen la selecci´on realizada.

Figura 7.7: Listado de bloqueos activos en el sistema

El listado est´a 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 corresponder´a con el c´odigo del objeto que se est´e modificando. En la barra de aplicaciones disponemos de tres opciones: Detalles, Borrado y Refrescar. La opci´on ”Detalles”, a la que tambi´en se puede acceder haciendo doble click sobre el registro deseado, nos muestra informaci´on adicional sobre la entrada de bloqueo tal como la transacci´on desde donde se ha producido el

´ CAP´ITULO 7. SERVICIOS DE ACTUALIZACION

82 bloqueo.

Figura 7.8: Informaci´on detallada de un bloqueo

En raras ocasiones puede llegar a ocurrir que el bloqueo generado por una modificaci´on 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 actualizaci´on queda interrumpido, su entrada de bloqueo correspondiente no es liberada hasta que el registro de actualizaci´on en cuesti´on sea procesado correctamente o borrado. Estas entradas de bloqueo no se deber´an borrar bajo ning´ un concepto ya que se podr´ıan causar inconsistencias en la base de datos. Estas

7.5. ENTRADAS DE BLOQUEO

83

entradas de bloqueo se liberar´an autom´aticamente cuando el registro de actualizaci´on 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 deber´an 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 actualizaci´on interrumpida, podremos borrar la entrada desde el listado de la transacci´on SM12.

Cap´ıtulo 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 m´as 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 m´aximo, el sistema empieza a sobreescribir el fichero desde el principio (la informaci´on m´as antigua). El fichero de log local se guarda en cada servidor de aplicaci´on en la siguiente ruta: Entorno UNIX → /usr/sap/<SID>//log/SLOG00 Entorno Windows NT → C:\usr\sap\<SID>\\log\Slog00.log donde <SID> es el nombre de la base de datos SAP y es el n´ umero de instancia. Central Cada servidor de aplicaciones copia las entradas del log local a un log 85

´ CAP´ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS

86

central. Esta opci´on no se encuentra en servidores Windows NT ni AS/400, s´olo existen logs locales (uno por servidor de aplicaci´on). El log central se guarda en un servidor de aplicaciones seleccionado, el resto de servidores de aplicaci´on env´ıan 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 m´axima definido en los par´ametros 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 p´erdida de estos mensajes.

8.1.1.

Accediendo al log local del sistema

Al log del Sistema se accede directamente por la transacci´on SM21 o por el men´ u general Herramientas→Gesti´on→Monitor→Log Sistema . La pantalla de seleccci´on de la transacci´on 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 transacci´on SM21. Para cambiar a modo experto, deberemos ir al men´ u desplegable Tratar→Modo experto. Ambos modos se diferencian en que ´este u ´ltimo da m´as opciones de selecci´on.

8.1.2.

Accediendo al log local en modo normal

Accediendo a la transacci´on SM21 – directamente o a trav´es de men´ u– entramos por defecto a la pantalla de selecci´on del log local del servidor de aplicaciones al que estemos conectados en Modo Normal. Veamos los distintos par´ametros de selecci´on que nos permitir´an 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 permitir´a visualizar s´olo 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

C´odigo de transaci´on: Nos permitir´a visualizar los mensajes del log debidos exclusivamente a la acci´on de los usuarios sobre la transacci´on especificada. Proceso SAP: Nos permitir´a 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 m´as de 10 procesos de trabajo numeraremos los siguientes con las letras del abecedario. VB Actualizaciones Vn Programas de actualizazi´on, 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 visualizaci´on por tipo de mensaje, s´olo

´ CAP´ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS

88

errores, errores y advertencias y todos los mensajes. El valor por defecto es la opci´on 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 m´as opciones de filtro como es la opci´on Atributos.

Figura 8.2: Par´ametros de selecci´on adicionales en modo experto Esta opci´on nos permite filtrar adem´as por: Programa: Se restringe el resultado a los mensajes causados por la ejecuci´on 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 / posici´on a fichero / posici´on: Define el segmento del fichero de log a leer. Si ya se ha le´ıdo el fichero una vez, se puede determinar

8.1. CONCEPTOS DEL LOG DEL SISTEMA

89

la posici´on de una entrada espec´ıfica haciendo doble click; la posici´on se encuentra en la secci´on de detalles t´ecnicos. Formato mensaje (tipo): Se pueden seleccionar mensajes por el formato de la componente del sistema. Para visualizar posibles valores, deberemos pulsar el bot´on 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 presentaci´on. Clase de desarrollo: Se pueden filtrar los mensajes que han sido producidos por la ejecuci´on de programas que pertenezcan a una clase de desarrollo en particular. Las clases de desarrollo son agrupaciones de objetos de Workbench o Customizing cuyo prop´osito es la jerarquizaci´on de tales objetos para una mejor gesti´on as´ı como el posibilitar su transporte a otros entornos. Con entradas internas Syslog: Visualizaci´on de mensajes relativos a los procesos de recolecci´on y env´ıo de mensajes de log desde el log local al log central. Esta opci´on no esta disponible para entornos que no sean Unix.

8.1.4.

Leyendo el log del sistema

Una vez introducidos los valores de selecci´on en la pantalla accederemos al contenido del log pulsando el bot´on 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 C´odigo transacci´on 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 transacci´on volvemos a la

90

´ CAP´ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS

Figura 8.3: Contenido del log del sistema

pantalla de selecci´on, el sistema muestra tres distintas opciones para volver a visualizar la informaci´on:

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 par´ametros que se hayan seleccionado. S´olo Editar Nuevamente. Vuelve a mostrar el u ´ltimo resultado del log visualizado anteriormente con esta opci´on. 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 trav´es de la segunda opci´on.

8.1. CONCEPTOS DEL LOG DEL SISTEMA

8.1.6.

91

Accediendo a logs remotos del sistema

Si el sistema SAP R/3 al que estamos conectados es un sistema distribu´ıdo, es decir , est´a 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 aplicaci´on. Para ello usaremos las opciones de lectura de logs remotos que nos ofrece la transacci´on SM21. Estas opciones se encuentran en el men´ u desplegable en Syslog→Seleccionar .

Figura 8.5: Pantalla principal log remoto del sistema

La opci´on syslog local es la que est´a activa por defecto y ya ha sido explicada . La opci´on syslog remoto nos lleva a una pantalla similar a la pantalla de selecci´on del syslog local con la salvedad que incluye un par´ametro m´as en la pantalla de selecci´on. Este par´ametro es la instancia. Aqu´ı le podremos indicar el nombre de la instancia cuyo log del sistema queremos visualizar. La opci´on todos los syslogs remotos nos lleva a una pantalla de selecci´on id´entica a la del log local con la salvedad que los mensajes que se visualizar´an corresponder´an la los de todas las instancias que componen nuestro sistema R/3. En la visualizaci´on de los mensajes del log aparecer´a un campo m´as

´ CAP´ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS

92

llamado instancia que nos servir´a para conocer en qu´e instancia se ha generado cada mensaje. La opci´on Syslog Central no est´a disponible para sistemas R/3 fuera del entorno UNIX. Es importante destacar que las u ´nicas instancias que estan disponibles para la visualizaci´on 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 ejecuci´on es un log de terminaci´on anormal de ejecuci´on de cualquier programa. Esto se produce por una cancelaci´on del programa que se est´a actualmente ejecutando; el sistema nos muestra una pantalla con un log de terminaci´on donde se puede encontrar informaci´on acerca del error producido y su posible soluci´on. Las posibles causas de terminaci´on 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. Cancelaci´on manual de un modo actualmente en ejecuci´on. Cuando se produce una terminaci´on anormal de una ejecuci´on de un programa, el dump es mostrado autom´aticamente en exclusiva al usuario cuyo proceso de di´alogo ha sido cancelado. En ese momento el usuario podr´a 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 transacci´on donde se puede gestionar todos los dumps producidos en el sistema.

8.2.1.

Accediendo a los dumps del sistema

La transacci´on de los dumps es ST22; accediendo por el men´ u desplegable ser´a Herramientas→Gesti´on → Monitor→An´alisis de Dumps. Por defecto s´olo se muestran los dumps producidos a fecha de hoy y el d´ıa anterior. Si deseamos acceder a un dump m´as antiguo deberemos pulsar la opci´on Pasar a → Sel. Dump breve. A continuaci´on nos aparacer´a una pantalla de selecci´on donde podremos filtrar por fecha, usuario, m´aquina, mandante.

8.2. CONCEPTO DE DUMP

Figura 8.6: Pantalla principal de an´alisis de dumps

Figura 8.7: B´ usqueda de dumps antiguos

93

94

´ CAP´ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS

8.2.2.

Interpretando los dumps

Tanto si visualizamos los dumps producidos a fecha actual, como del d´ıa anterior o alguna fecha m´as antigua, ´estos aparecer´an en forma de lista. Esta lista est´a 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 descripci´on del dump Haciendo doble click en cada uno de ellos accederemos al log del dump donde tendremos toda la informaci´on. El contenido de todos los dumps est´an organizados en las siguientes secciones: 1. ¿Qu´e sucedi´o? . Secci´on donde se explica brevemente el error. 2. ¿Qu´e se puede hacer? . Secci´on que explica brevemente las acciones a llevar a cabo. 3. An´alisis error . Secci´on donde se explica m´as detalladamente el error. Es una extensi´on de la secci´on 1. 4. Notas para corregir errores . Secci´on donde se explica m´as detalladamente las acciones a llevar a cabo. Es una extensi´on de la secci´on 2. 5. Entorno sistema . Secci´on donde aparecen las variables del sistema m´as importantes, tales como la versi´on de SAP, nombre del servidor, direcci´on IP, sistema operativo, RDBMS, version del kernel, etc. . . 6. Usuario, transacci´on. Secci´on donde aparece el usuario que ha generado el dump, programa que se estaba ejecutando, transacci´on, idioma, etc. . . 7. Informaciones lugar terminaci´on . Secci´on donde se especifica la linea del programa donde se ha producido el error.

8.2. CONCEPTO DE DUMP

95

8. Detalle c´odigo fuente . Secci´on que muestra un intervalo del c´odigo fuente donde se ha producido el error. La l´ınea donde se ha producido el error aparece marcada con una flecha. 9. Contenido campos sistema. Secci´on donde se muestran los valores que ten´ıan algunas variables del sistema cuando se produjo el error. 10. Variables seleccionadas . Secci´on donde se detalla m´as exhaustivamente el contenido de m´as variables cuando se produjo el error . 11. Llamadas / Eventos activos. Secci´on que detalla el evento o la llamada a la que pertenece la linea de c´odigo que ha producido el error . 12. Notas internas . Secci´on que detalla la funci´on C –perteneciente al kernel de SAP– donde se ha producido el error . 13. Llamadas activas kernel SAP . Secci´on que detalla los elementos del kernel y su posici´on que estaban activos en el momento del error . 14. Lista programas ABAP involucrados . Secci´on que muestra los programas involucrados en la ejecuci´on del programa que produjo el error . 15. Lista tablas internas . Secci´on 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 aplicaci´on (contenidos) . Secci´on que detalla las tablas de aplicaci´on que han sido usadas durante la ejecuci´on del programa que ha terminado en error. 17. Directorio ´ambitos datos (info gesti´on) . Secci´on que detalla el conjunto de objetos del workbench ( variables, par´ametros, tablas) involucradas en la ejecuci´on del programa. 18. Directorio ´ambitos datos (contenidos). Secci´on de contenido parecido a la anterior .

96

´ CAP´ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS

19. ABAP/4 Bloques control CONT . Secci´on con informaci´on complementaria a la de la seccion 8 . 20. Fin an´alisis error tiempo ejecuci´on . Secci´on que marca el fin del log del dump. Si bien el t´ıtulo de cada secci´on aparece en el idioma de conexi´on, el contenido s´olo se encuentra disponible en ingl´es y en alem´an. Si nos conectamos al sistema en un idioma distinto del ingl´es y alem´an, el dump ser´a visualizado en el idioma configurado como de suplementaci´on, que en general ser´a el ingl´es, sino se ha definido suplementaci´on de idioma (esto pertenece a la instalaci´on de lenguajes) se visualizar´a en el idioma original de SAP, que es el alem´an. Las secciones m´as importantes y que m´as 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 ?

8.2. CONCEPTO DE DUMP

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,

´ CAP´ITULO 8. LOG DEL SISTEMA Y ANALISIS 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....

8.2. CONCEPTO DE DUMP

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

´ CAP´ITULO 8. LOG DEL SISTEMA Y ANALISIS 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

8.2. CONCEPTO DE DUMP

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

´ CAP´ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS

Programa No .. Nombre... Cont.....1....+....2....+....3....+.... --------------------------------------------------------? 0 not assigned 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 ----------------------------------------------

Cap´ıtulo 9 Gesti´ on de spool 9.1.

Concepto de spool

En cualquier entorno de gesti´on empresarial se produce una gran cantidad de informaci´on que en muchas ocasiones interesa sacar a papel a trav´es de informes, listados, an´alisis. . . El spool es un almac´en receptor de peticiones de impresi´on que proporciona una serie de utilidades para controlar la salida de informaci´on. Aunque se asocia directamente spool con imprimir en papel, en SAP las posibilidades son m´as 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 c´omo se instala una.

9.2.

Instalaci´ on de una impresora

Con la transacci´on SPAD – pantalla de la figura 9.1 a la que llegaremos a trav´es de Herramientas→ CCMS→ Spool→ Gesti´on de spool – podemos instalar dispositivos de salida en nuestro sistema R/3. Vamos a describir la instalaci´on de una impresora de tipo local a nivel de PC, es decir, una impresora gen´erica en la que cualquiera puede imprimir pero a cada persona que lo haga le saldr´a la informaci´on por la impresora que tenga definida por defecto en su servidor de presentaci´on. 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 bot´on 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 m´as parecido a lo que en microinform´atica se denomina driver de la impresora. Para la creacion de una impresoral 103

104

´ DE SPOOL CAP´ITULO 9. GESTION

Figura 9.1: Transacci´on 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 instalaci´on del frontend de SAP. Cuando se imprime algo el sapgui ejecuta autom´aticamente 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 opci´on 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 impresi´on de facturas, n´ominas, 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. Ubicaci´on. Campo descriptivo para indicar al usuario donde se encuentra f´ısicamente 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 mostrar´a la pantalla de la figura 9.3 Aqu´ı se le dice como esta conectada la impresora al servidor SAP. Elegiremos de la lista la opci´on F:Imprimir en front end que le marca que debe enviar la informaci´on 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 s´olo nos queda pulsar el bot´on de grabar y ya podemos usar la impresora instalada.

´ DE SPOOL CAP´ITULO 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 est´andar 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 tambi´en podemos indicar otras muchas opciones que vemos a continuaci´on. La cantidad de copias que queremos sacar. Si queremos todas las p´agina o s´olo un rango de ellas. El nombre y el t´ıtulo de la orden de spool. Ser´a u ´til para luego buscarla entre el spool o entre el mont´on 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 gen´erico de dispositivo de salida.

9.3. COMO IMPRIMIR

Figura 9.4: Ventana de di´alogo para imprimir un listado

107

´ DE SPOOL CAP´ITULO 9. GESTION

108

Podemos marcar el borrado de la orden tras la impresi´on correcta o, por el contrario, dejar que la orden permanezca en el spool para futuras reimpresiones. La cantidad de d´ıas que debe permanecer en el spool antes de ser borrada por los jobs de mantenimiento. La impresi´on de una portada previa con el t´ıtulo 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 env´ıan los papeles a nuestro puesto de trabajo. La cantidad de l´ıneas y columna que queremos sacar y por lo tanto el formato de la p´agina.

9.4.

Operaciones sobre ´ ordenes de spool

Para poder administrar todas las peticiones de spool que hacemos SAP provee de la transacci´on 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 m´as 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 caracter´ıstica que el de la transacci´on de gesti´on de jobs; es un programa de selecci´on, listado y gesti´on simult´aneamente. Las operaciones que podemos hacer sobre una orden de spool incluyen la creaci´on de ´ordenes de salida, el cambio de los atributos, el borrado de la orden o la visualizaci´on de su contenido. Esta u ´ltima opci´on 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. B´asicamente 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 m´as de 80. En ese caso cambiaremos el campo edici´on por un X 65 80 para conseguir un listado con letra m´as grande y en vertical y volveremos a repetir la salida de la orden.

´ 9.4. OPERACIONES SOBRE ORDENES DE SPOOL

Figura 9.5: Transacci´on SP01. Selecci´on de ´ordenes de spool

Figura 9.6: Transacci´on SP01. Listado de ´ordenes de spool

109

110

´ DE SPOOL CAP´ITULO 9. GESTION

Una de las labores del administrador consiste en asegurarse que las o´rdenes 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 m´as de n d´ıas almacenado.

Figura 9.7: Atributos de una orden de spool

Cap´ıtulo 10 Gesti´ on de usuarios y autorizaciones 10.1.

Modelo de seguridad en R/3

En cualquier sistema de gesti´on de informaci´on integrado se guardan datos de diferentes ´areas a los que s´olo 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. Obligaci´on legal de proteger informaci´on ajena a la propia empresa como los datos personales de sus empleados, las condiciones econ´omicas de los proveedores. SAP contempla toda esta problem´atica 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 autorizaci´on que se componen de campos. Estos objetos representan lo que queremos proteger. Ejemplos de objetos de autorizaci´on son: S TCODE. Protege el c´odigo de transacci´on y contiene un s´olo campo que es la transacci´on. Es el m´as importante de todos porque todas las operaciones que se hacen en SAP empiezan por el acceso a una transacci´on. 111

112

´ DE USUARIOS Y AUTORIZACIONES CAP´ITULO 10. GESTION

Figura 10.1: Componentes de la seguridad en R/3

S TABU DIS. Protecci´on 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. Protecci´on de la contabilizaci´on 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 autorizaci´on simple sobre un u ´nico objeto de autorizaci´on hasta el maestro de usuarios que son los que acceden al sistema. Veamos lo que representa cada uno de los niveles: Autorizaciones. Una autorizaci´on consiste en una asignaci´on de valores a los campos de un objeto de autorizaci´on. Por ejemplo, crearemos una autorizaci´on para el objeto S TCODE que tenga el valor FB01 para el campo TCODE. De est´a manera el usuario que tenga asignada esta autorizaci´on podr´a acceder a la transacci´on de crear documento contable. Tambi´en tendremos que crear otra autorizaci´on

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 operaci´on de contabilizar para la sociedad financiera 1000. Perfiles. Un perfil es simplemente la agrupaci´on de varias autorizaciones que hayamos creado anteriormente. El perfil es la unidad m´ınima 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 gesti´on de la empresa debe disponer de un c´odigo de usuario en R/3. Este usuario tendr´a asignados unos grupos de actividad o unos perfiles de autorizaci´on (o ambos) para poder realizar las tareas que exige su funci´on o puesto de trabajo.

10.2.

Mantenimiento de usuarios

Para la creaci´on y mantenimiento de usuario R/3 dispone de la transacci´on SU01 (Herramientas→ Gesti´on→ Actualizar usuarios→ Usuarios). En la pantalla correspondiente a la figura 10.2 escribiremos el c´odigo del usuario y pulsando uno de los botones de la barra de aplicaci´on o escogiendo una de las opciones del men´ u Usuario podemos realizar diversas acciones como crear, modificar, cambiar clave acceso, bloquear. . . Pulsando sobre el bot´on 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, tel´efono. . . . En el campo edici´on veremos el nombre tal y como aparecer´a en los listados o en otras transacciones. Datos logon. Es obligatorio indicar una clave inicial con la que acceder´a el usuario, aunque en su primera conexi´on se le pedir´a que la cambie. Tambi´en podemos limitar la validez temporal de manera

114

´ DE USUARIOS Y AUTORIZACIONES CAP´ITULO 10. GESTION

Figura 10.2: Pantalla inicial de la actualizaci´on de usuarios

que podemos tener empleados que accedan a nuestro sistema hasta determinada fecha como puede ser el fin de su contrato o cesi´on a nuestro departamento. Valores fijos. En esta pesta˜ na definimos el men´ u inicial de entrada al sistema, la impresora SAP y algunos par´ametros de impresi´on por defecto, y el formato en que debe ver el usuario las fechas y los importes en todas las transacciones SAP. Esta u ´ltima opci´on, junto con la del uso horario, es vital para empresas multinacionales que tienen empleados en diversos pa´ıses. Par´ ametros. Existe la posibilidad de asignar par´ametros por defecto para multitud de campos de todos los m´odulos de SAP. Si un empleado solo realiza entradas de mercanc´ıas en el centro 1000, es muy u ´til asignarle ese valor en el par´ametro correspondiente consiguiendo que en todas las pantallas de R/3 en la que aparezca el campo centro, ´este se encuentre relleno autom´aticamente 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 tambi´en, 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 versi´on 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

´ DE USUARIOS Y AUTORIZACIONES CAP´ITULO 10. GESTION n´ umero enorme de usuarios debemos agruparlos asign´andoles 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 creaci´on 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 utilizaci´on de esta herramienta son m´ ultiples aunque la m´as 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 versi´on 3.0F y anteriores, la creaci´on de un perfil de seguridad exig´ıa un tedioso trabajo de b´ usqueda de objetos que chequea cada transacci´on. Para crear un papel disponemos de la transacci´on 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 bot´on de crear pasaremos a la pantalla de la figura 10.5 en la que vemos las diferentes partes de la creaci´on de un grupo de actividad repartidas en cuatro pesta˜ nas. En la primera de ellas rellenamos unicamente un descripci´on corta del papel y tambi´en podemos completar el campo de descripci´on inferior en el que podemos indicar instrucciones sobre a qui´en se debe asignar este perfil o cual es su funci´on espec´ıfica.

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 transacci´on de contabilizar documento (perteneciente al m´odulo FI). Esto implica que el usuario al que se le asigne este perfil podr´a ejecutar la transacci´on FB01, pero no hemos determinado a´ un para que sociedades financieras, cuentas o deudores podr´a hacerlo. En la figura 10.7 tenemos la pantalla de asignaci´on de valores a los objetos de autorizaci´on a la que se llega a trav´es de la pesta˜ na Autorizaciones. Son cuatros los objetos de la gesti´on financiera los que chequea esta transacci´on

118

´ DE USUARIOS Y AUTORIZACIONES CAP´ITULO 10. GESTION

Figura 10.6: Transacciones asignadas a un papel

y habr´a que dar los valores correspondientes para el grupo de actividad. Por ejemplo, en el objeto grupo de autorizaci´on 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 autorizaci´on debe ser completado tambi´en, solo cuando hayamos asignado valores a todos tendremos los sem´aforos en verde, indicaci´on de que podemos grabar el papel. Por u ´ltimo, desp´ ues de completar la grabaci´on del grupo, tenemos la posibilidad de asign´arselo a uno o varios usuarios. En la figura 10.8 conviene fijarse en que tenemos los sem´aforos de las pesta˜ nas men´ u y autorizaciones en verde, indic´andonos que los pasos anteriores se han procesado correctamente. Es entonces, cuando podemos poner en la tabla de usuarios los c´odigos (el nombre nos lo rellena el propio programa) a los que queremos incluir el papel y la fecha de validez de la asignaci´on. Esta fecha de validez tiene la misma funci´on 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 autorizaci´on cuando llegue el d´ıa, ponemos la fecha de validez y entonces perder´a la autorizaci´on al dia siguiente.

10.3. GENERADOR DE PERFILES

Figura 10.7: Asignaci´on de valores a los objetos de autorizaci´on

Figura 10.8: Asignacion de un papel a usuarios

119

Cap´ıtulo 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, producci´on ). Los objetos a pasar pueden ser definici´on y contenido de tablas nuevas, programas nuevos, datos de customizing e incluso modificaciones al est´andar. Este traspaso de informaci´on 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 programaci´on o repetir la inclusi´on de datos de customizing. Todo ello redunda en una mayor productividad y en una minimizaci´on de riesgos ya que la informaci´on, antes de ser insertada en el sistema productivo, es probada en el sistema de desarrollo y su traspaso no ser´a realizado hasta que el responsable del proyecto d´e el visto bueno. La herramienta que permite este traspaso de informaci´on 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 producci´on; obviamente si no existe tal separaci´on de sistemas, es decir, si s´olo se dispone de un u ´nico sistema la utilidad del sistema de transportes se reduce a traspasar informaci´on 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. Inserci´on de nuevos objetos en el sistema destino. Modificaci´on de objetos ya existentes en el sistema destino. 121

CAP´ITULO 11. SISTEMA DE TRANSPORTE

122

Cuando se crea o modifica un objeto en el sistema de desarrollo, el sistema propone un c´odigo u ´nico para identificar la creaci´on o modificaci´on de ese objeto, siempre y claro est´a que el mandante donde se est´e trabajando est´e configurado para registrar cualquier modificaci´on (ver cap´ıtulo 12). El c´odigo propuesto conforma lo que se denomina Orden de Transporte y a ella se asociar´an los objetos que el usuario cree o modifique, de tal manera que el sistema bloquear´a, dependiendo de la naturaleza de la orden, esos objetos para que nadie m´as que el propietario de esa orden de transporte pueda modificar esos objetos mientras la orden no est´e 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 ir´a 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 trav´es de las tareas; las tareas deben obligatoriamente pertenecer a una u ´nica orden de transporte y al igual que ellas siguen el mismo c´odigo secuencial de tal manera que nunca pueden existir varias ´ordenes o tareas con el mismo c´odigo. Las tareas, al igual que las ´ordenes, est´an asignadas a un usuario y su finalidad es mejorar la gesti´on 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 c´odigo ser´a 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 b´asica entre un caso y otro ser´a que el transporte al sistema productivo de la primera orden conllevar´a el transporte de los dos objetos – programa y tabla – a la vez, mientras que en el segundo caso el transporte de una orden conllevar´a el transporte s´olo del objeto asociado. Ser´a tarea del propietario de la orden el decidir de cuantos objetos se va a componer cada orden de transporte. No se deber´a crear una orden para cada objeto a modificar o crear ya que esto complicar´a 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

CAP´ITULO 11. SISTEMA DE TRANSPORTE

labor de gesti´on de las ´ordenes de transporte; tampoco se deber´a 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 deber´a, por lo tanto, llegar a un t´ermino 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 pedir´a asociar el nuevo objeto por crear a una Clase de Desarrollo. Las clases de desarrollo no son m´as que agrupaciones l´ogicas de objetos que, adem´as, 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, impl´ıcitamente, asign´andole la ruta de transporte a seguir cuando la orden asociada a ese objeto sea transportada. Todos los objetos est´andar del sistema SAP R/3, ya sean programas, tablas, ayudas de b´ usqueda, etc, tienen asociado una clase de desarrollo est´andar de SAP. Los objetos nuevos a crear deber´an asociarse a clases de desarrollo nuevas, que se distinguir´an de las est´andar por el primer car´acter de su identificaci´on, que siempre deber´a 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 deber´a asignar a objetos que sean de pruebas y que no deseemos que vayan a pasar nunca a formar parte del sistema de producci´on. 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 parametrizaci´on del sistema. La parametrizaci´on 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 grabaci´on autom´atica de cambios (ver cap´ıtulo 12), una tarea y una orden de customizing son creadas autom´aticamente 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, ser´a tambi´en 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 afectar´an b´asicamente a programas y tablas, son independientes de mandante; esto significa que tienen efecto en todo el sistema. La creaci´on de nuevos objetos, o la modificaci´on de los que proporciona SAP son grabados, de manera similar al customizing, en tareas asignadas a ´ordenes de modificaci´on transportables. ´ Ordenes de modificaci´ on locales Tambi´en se pueden realizar cambios locales; se distinguen de los anteriores en que estos cambios no pueden ser transportados a otros sistemas.

126

11.4.

CAP´ITULO 11. SISTEMA DE TRANSPORTE

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 inclusi´on y eliminaci´on de objetos asociados. Si se trata de una orden, ´esta permite la asignaci´on o borrado de tareas; si se trata de una tarea, esta permite la asignaci´on o desasignaci´on de objetos del sistema . Liberada El paso previo del transporte consistir´a en la liberaci´on de la orden y sus tareas asociadas. Para poder liberar una orden, se deber´a primero liberar todas sus tareas asociadas. La liberaci´on de una tarea consiste en cerrarla para posteriores modificaciones; es decir, no se podr´a asignar nuevos objetos a esa tarea ni desasignar los ya existentes. La liberaci´on de una orden consiste en cerrarla para posteriores tareas; no se podr´a crear ninguna nueva tarea asociada a esa orden ni se podr´an borrar las ya existentes. Una orden puede permanecer en status Modificable aunque todas sus tareas asociadas est´en en estado liberado; ello nos permitir´a asignarle nuevas tareas con status modificable para poder seguir trabajando con ella hasta que liberemos la orden. La liberaci´on de una orden de transporte adem´as de bloquearla para cualquier modificaci´on futura, realiza el export de la orden. El export de la orden consiste en la creaci´on de dos ficheros a nivel de sistema operativo – fichero data y fichero cofiles –. En estos ficheros se produce la exportaci´on 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 m´as que la exportaci´on de informaci´on fuera de la base de datos de origen a fichero del sistema operativo y la importaci´on de dicha informaci´on en la base de datos destino. Los dos ficheros creados en la exportaci´on de una orden de transporte tienen la siguiente ubicaci´on en el sistema operativo: Fichero data Ubicado en /usr/sap/trans/data; es el que contiene toda la informaci´on asociada a la orden de transporte; cuantos m´as objetos est´en asociados a la

11.5. CUSTOMIZING ORGANIZER Y WORKBENCH ORGANIZER 127

Figura 11.4: Esquema pasos del transporte

orden de transporte a liberar, mayor ser´a el fichero data a crear y mayor el tiempo que llevar´a su creaci´on, es decir, la exportaci´on. 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 trav´es de las transacciones SE09 como SE10 y desde ellas se puede gestionar las ´ordenes de transporte relativas a

128

CAP´ITULO 11. SISTEMA DE TRANSPORTE

desarrollo (´ordenes de modificaci´on tanto locales como transportables; esta herramienta la usar´an los desarrolladores) y las de Customizing (herramienta que usar´an los consultores).

Figura 11.5: Pantalla principal Workbench Organizer En ambas herramientas la pantalla de selecci´on dispone como par´ametro principal del usuario, que por defecto est´a relleno con el nombre del usuario con el que nos hemos conectado al sistema. Todas las ´ordenes que visualicemos con esta herramienta ser´an las asociadas al usuario arriba indicado. Como par´ametros adicionales podemos elegir visualizar las ´ordenes modificables y las liberadas o s´olo uno de los dos tipos. Adem´as, tambi´en 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, adem´as, la posibilidad de visualizar s´olo las ´ordenes de customizing o s´olo las de workbench o ambas a la vez. Una vez elegidos los par´ametros de selecci´on del CO o del WBO pulsaremos el bot´on de visualizaci´on 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 qu´e objetos est´an asociados a qu´e ´ordenes de transporte sin m´as 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 qu´e 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 aplicaci´on 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 ir´a asignando sus objetos a su tarea con lo que no se

130

CAP´ITULO 11. SISTEMA DE TRANSPORTE

producir´a solapamiento. Una vez que los desarrolladores acaben su trabajo, el jefe de proyecto les indicar´a que liberen sus tareas (la liberaci´on s´olo la puede realizar el propietario), pero el jefe de proyecto ser´a el que tenga la decisi´on de cu´ando liberar la orden, de la cual ´el es propietario. La exportaci´on de la orden a fichero no se producir´a hasta que el propietario de la orden ejecute la liberaci´on de la misma. Desde esta pantalla podremos ejecutar la liberaci´on de cualquier orden de la que seamos propietarios. La liberaci´on debe llevar siempre esta secuencia: Ejecutar la liberaci´on de todas las tareas asociadas a esa orden Ejecutar la liberaci´on de la orden Adem´as de la liberaci´on podremos borrar asignaciones de objetos a tareas con estatus modificable. Esta opci´on nos permite eliminar la asignaci´on de un objeto dentro de una tarea sin m´as que posicionar el cursor en el objeto deseado y pulsar a continuaci´on la opci´on de borrar. Esta opci´on no borra f´ısicamente el objeto, s´olo su asignaci´on a una tarea, y deber´a ser usado cuando, por error, hayamos incluido un objeto en una tarea no deseada. Esta opci´on de borrado tambi´en puede ser u ´til para eliminar tareas con estatus modificable de ´ordenes, la u ´nica restricci´on que nos impone el sistema es que esas tareas deben estar vac´ıas. La opci´on de borrado – bien de objetos o de tareas – s´olo es aplicable cuando la orden y la tarea asociada tienen el estatus modificable, es decir, que no se ha liberado todav´ıa. Un tarea ya liberada no permite la desasignaci´on de sus objetos mediante la opci´on de borrado. En esta pantalla, adem´as, podremos cambiar el texto descriptivo asociado a una orden con el bot´on de modificar. Otra opci´on 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 opci´on crear orden. Eligiendo esta opci´on el sistema nos muestra la pantalla de di´alogo que vemos en la figura 11.7. Como campo principal se nos pide que introduzcamos una descripci´on para la orden a crear cuya codificaci´on la dar´a autom´aticamente el sistema al crearla. El sistema, adem´as, crea la orden con una u ´nica tarea cuyo propietario es el mismo que el que ha creado la orden; esta opci´on se puede cambiar. Podremos introducir tantas tareas como queramos sin m´as que asignar nuevos empleados a las tareas a introducir en la orden – el sistema introducir´a tantas tareas en la orden como empleados se haya especificado –. A esta opci´on de creaci´on de ´ordenes de transporte tambi´en se puede acceder desde fuera de la transacci´on SE09 y SE10 cuando modificamos o

´ 11.6. TRANSPORTE MANUAL DE ORDENES

131

Figura 11.7: Creaci´on 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 est´a 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 deber´a 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).

CAP´ITULO 11. SISTEMA DE TRANSPORTE

132

En sistemas Windows NT, esta directorio de transporte deber´a estar configurado como compartido para que desde todos los entornos est´e disponible, sin embargo s´olo ser´a local para uno de ellos. Accederemos a trav´es del emulador MSDOS en el servidor donde la ruta es local. Presentamos a continuaci´on la estructura en ´arbol del sistema operativo UNIX que es necesaria para el transporte y explicaremos para qu´e 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 exportaci´on de datos desde la base de datos que se realiza durante la liberaci´on de una orden. Directorio donde se almacenan los ficheros cofiles generados en la exportaci´on de datos desde la base de datos que se realiza durante la liberaci´on 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 est´a todav´ıa sin transportar; si es as´ı, se ejecuta el transporte al sistema destino. Las ´ordenes, por defecto, al ser liberadas son a˜ nadidas al ”buffer”por lo que no ser´a 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 continuaci´on c´omo deberemos usar el programa de control para gestionar el transporte de las ´ordenes ejecut´andolo desde el directorio bin

´ 11.6. TRANSPORTE MANUAL DE ORDENES

133

mencionado antes: tp showbuffer <SID> Nos muestra el listado de ´ordenes inclu´ıdas 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 c´odigo de retorno cuyos valores pueden ser: 0 → Operaci´on ejecutada con ´exito 4 → Operaci´on ejecutada con advertencias 8 → Operaci´on ejecutada con errores. Un valor mayor que 8 tambi´en indicar´a que la operaci´on no se ha realizado con ´exito. tp delfrombuffer <SID>

134

CAP´ITULO 11. SISTEMA DE TRANSPORTE

Elimina del listado del directorio buffer la referencia a la orden de transporte seleccionada. No borra la orden f´ısicamente, pero impide que se pueda transportar esa orden. tp addtobuffer <SID> A˜ nade la orden seleccionada al buffer, dejando la orden preparada para ser transportada. Esta operaci´on, por defecto, no es necesario ejecutarla a no ser que una orden sea eliminada con el comando anterior y deseemos posteriormente transportarla. tp import <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 deber´a obligatoriamente especificar el mandante destino con la opci´on client=<mandante destino> a˜ nadida despu´es 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 aparici´on en buffer, por lo que primero se transportar´an las ´ordenes que han sido liberadas primero. Si el mandante

´ 11.6. TRANSPORTE MANUAL DE ORDENES

135

destino no coincide con el origen, se deber´a usar la opci´on especificada en el caso anterior. No se recomienda el uso de esta opci´on 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 <SID> client= u1 La opci´on u1 es el modo incondicional de sobreescritura. Habr´a 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 importaci´on. Para obligarle a sobrescribir la misma orden que se ha transportado previamente, ser´a necesario especificar la opci´on u1.

Figura 11.10: Esquema ejemplo del transporte de una orden Veamos a continuaci´on un ejemplo. Supongamos un sistema de desarrollo D10 en un servidor NT llamado devsap10 y un sistema de producci´on P10 en otro servidor NT llamado prodsap10. En ambos entornos est´a establecida la ruta del transporte D10 → P10 a trav´es de la clase de desarrollo ZDEV. Estableceremos el directorio de transporte C:\usr\sap\trans localmente en el servidor de producci´on, prodsap10.

136

CAP´ITULO 11. SISTEMA DE TRANSPORTE

Supongamos que creamos en el mandante 101 de D10 un programa ZREPORT que queremos pasar al mandante 110 de producci´on. Al crearlo, le asignaremos la clase de desarrollo ZDEV y el sistema nos propondr´a un c´odigo 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 producci´on, 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, aparecer´a la u ´ltima del listado. Una vez comprobado que la orden se encuentra en el buffer del sistema de producci´on ejecutaremos el transporte al mandante 110. Como el mandante destino y origen no coinciden deberemos usar la opci´on client=<SID>. C:\usr\sap\trans\bin\tp import D10K902010 P10 client=110 Una vez que este comando ejecute la importaci´on y su c´odigo de retorno sea 0, el programa ZREPORT estar´a disponible en el sistema de producci´on.

11.7.

Log del transporte

Existe dentro del sistema SAP R/3 una herramienta que nos proporciona mucha m´as informaci´on sobre el transporte de una orden que el simple c´odigo de retorno devuelto por el comando tp. Tal c´odigo 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 qu´e tipo de problema ha ocurrido. La herramienta del log del transporte est´a disponible tanto en la transacci´on SE09 como en la SE10. Podemos pulsar el bot´on de visualizaci´on individual – aparece asociado a un icono de gafas – en la barra de aplicaciones si conocemos el n´ umero de orden cuyo log queremos consultar: Tambi´en podemos rellenar los par´ametros de selecci´on explicados en la secci´on 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 opci´on log del transporte – asociado a una hoja y gafas – dentro de la barra de aplicaciones.

11.7. LOG DEL TRANSPORTE

137

Figura 11.11: Visualizaci´on 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 qu´e sistema se ha producido el export as´ı como el import en el sistema destino con cada uno de sus pasos. La importaci´on 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 informaci´on, cada vez m´as detallados. Una vez que hemos visto en qu´e paso del transporte se ha producido un error, haremos doble click sobre esa l´ınea para acceder a un listado completo del log en ese paso. Esto nos sirve para saber por qu´e raz´on se ha producido un error en el transporte y c´omo habr´a que resolverlo. Los errores m´as comunes son de informaci´on incompleta en el sistema destino para poder activar las modificaciones reci´en transportadas. Un ejemplo puede ser que el c´odigo fuente de un programa que queramos transportar al sistema destino del transporte haga referencia a una tabla cuya definici´on se encuentra en otra orden de transporte, todav´ıa sin transportar. Si transportamos primero la orden del c´odigo fuente, la importaci´on fallar´a devolviendo un c´odigo de retorno 8. Si visualizamos el

138

CAP´ITULO 11. SISTEMA DE TRANSPORTE

log del transporte de dicha orden veremos que el paso que ha fallado ha sido la generaci´on del c´odigo fuente por hacer referencia a una tabla que todav´ıa no existe en el sistema destino. Lo que deberemos hacer ser´a, pasar la orden donde se encuentra la definici´on 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 –.

Cap´ıtulo 12 Gesti´ on de mandantes Como ya se vio en el cap´ıtulo 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, adem´as una hoja de balance tambi´en independiente. La implementaci´on del modelo de empresa basado en los requerimientos de la empresa se conocen como customizing o parametrizaci´on. El customizing, dependiendo del tipo de datos a los que afecte, se puede dividir en dependiente o en independiente de mandante. Tambi´en vimos en el cap´ıtulo 2 que un usuario, para trabajar con SAP R/3, necesita conectarse a un mandante y lo que ello significaba. En este cap´ıtulo vamos a profundizar en el concepto, caracter´ısticas 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 est´andar, es decir preconfigurados. Los mandantes est´andar son el 000, 001 y 066. En sistemas SAP R/3 destinados a la formaci´on y educaci´on cuyo nombre es IDES existe adem´as 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 modelizaci´on de una o varias empresas modelo adem´as de incluir datos de las actividades de negocio de cada una de las empresas. Estos mandantes vienen provistos con unos usuarios est´andar con autorizaci´on global, es decir, sin restricciones, que en general, no deber´an 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 s´olo existe en el mandante 066) . 139

140

12.1.

´ DE MANDANTES CAP´ITULO 12. GESTION

Creaci´ on de un nuevo mandante

Los mandantes est´andar bajo ning´ un concepto deber´an ser usados como el mandante de trabajo de la empresa. Estos mandantes, deber´an permanecer en el sistema sin ser modificados ni borrados y sin que se creen nuevos usuarios, a excepci´on del administrador del sistema, para que se conecten a ellos. Es por ello, por lo que una de las primeras tareas del administrador ser´a la creaci´on de un nuevo mandante cuyo destino final puede ser de test, de producci´on, de integraci´on. . . dependiendo del sistema SAP R/3 con el que estemos tratando y de los requerimientos de la empresa. La creaci´on de un nuevo mandante, en general, se realizar´a como copia de uno ya existente. Se har´a 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 trav´es de un export de mandante (la informaci´on del mandante se exporta a fichero por medio de ´ordenes de transporte). Cuando el sistema origen y el destino sean diferentes se deber´a tener cuidado de copiar mandantes s´olo entre sistemas SAP R/3 que dispongan de la misma versi´on 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, d´andose de alta, adem´as, importantes par´ametros b´asicos. El segundo paso (descrito en la siguiente secci´on) llena el mandante de datos; s´olo despu´es de este paso el mandante estar´a plenamente operativo. El primer paso consiste, realmente, en dar de alta el mandante en la tabla T000, que es la tabla donde est´an referenciados todos los mandantes activos en el sistema. Este alta en la tabla T000 se realiza a trav´es de la transacci´on SCC4 o a trav´es del men´ u general Herramientas→ Gesti´on→ Gesti´on→ Gesti´on de Mandantes→ Actualizar Mandantes . A esta pantalla entraremos por defecto en modo visualizar. La informaci´on presentada es la de la tabla T000. Pulsando el bot´on que cambia a modo modificar, tendremos la opci´on de crear una nueva entrada; el primer campo corresponde al c´odigo del mandante que vayamos a crear; el segundo campo corresponde a una peque˜ na descripci´on del mandante, el tercero a la ciudad asociada a la empresa que va a usar ese mandante, as´ı como la moneda b´asica 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 gesti´on de mandantes

de modificaci´on para objetos dependientes e independientes de mandante, nivel de protecci´on y restricciones. Papel del mandante Cuando creamos un mandante deberemos asignarle un papel, es decir un prop´osito o funci´on para lo que se va a utilizar. Los valores posibles son producci´on , test , customizing , presentaci´on , formaci´on o referencia SAP . Modificaciones y transportes de objetos dependientes de mandante Dependiendo del papel que tome el mandante puede llegar a ser necesaria la activaci´on o desactivaci´on 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 deber´an 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 formaci´on y test.

142

´ DE MANDANTES CAP´ITULO 12. GESTION

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. Opci´on m´as usada para mandantes de sistemas productivos. No se permiten transportes Se permite modificar el customizing pero las modificaciones no se registran autom´aticamente en ´ordenes de transporte. Tampoco se permite la asignaci´on manual a ´ordenes de transporte. Opci´on m´as 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 Opci´on m´as usada para mandantes en sistemas de desarrollo o pruebas donde sepamos que las modificaciones independientes de mandante no afectar´an 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 antag´onicas, se deber´a usar esta opci´on. No modificaci´ on de objetos repository Impide modificar objetos standard del repository (tablas, programas, pantallas, etc...) y la creaci´on de nuevos objetos de desarrollo. No modif.de objetos repository y customizing indep.mandante Opci´on m´as usada en mandantes de sistemas de productivo. Con esta opci´on 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 comparaci´on (existen herramientas que nos permiten comparar los datos de distintos mandantes). Es importante tener los mandantes

´ DE MANDANTES CAP´ITULO 12. GESTION

144

productivos protegidos contra copias – intencionadas o no – de mandante. Veamos los distintos niveles de protecci´on: Nivel Protecci´ on 0: No hay restricciones En este nivel no existe protecci´on . Nivel Protecci´ on 1: No se permite sobrescritura En este nivel se protege contra copia de mandante. El mandante as´ı protegido no podr´a ser sobrescrito por una copia de mandante. Nivel Protecci´ on 2: No se permite sobrescritura ni comparaci´ on Este nivel adem´as de proteger contra copia de mandante protege contra la herramienta de comparaci´on. Esta opci´on ser´a especialmente necesaria para mandantes productivos donde la informaci´on all´ı contenida es especialmente confidencial y donde se deber´an cumplir todos los requerimientos impuestos por las leyes oficiales de protecci´on de datos. Restricciones Por u ´ltimo podremos restringir el uso de herramientas CATT o incluso proteger el mandante contra un upgrade - cambio de versi´on -. 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 podr´an ser modificados. Esto compone lo que es el primer paso en la creaci´on de un mandante. El segundo paso ser´a el llenado del nuevo mandante de datos a partir de un mandante ya existente a trav´es 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 creaci´on 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 secci´on anterior. El u ´nico usuario disponible en un mandante reci´en creado y sin ning´ un tipo de datos es el usuario SAP* con password PASS. Este usuario est´a disponible siempre en SAP ya que as´ı se ha programado el kernel. La password PASS s´olo est´a activa en mandantes reci´en creados o si en un mandante estandar o ya creado y con datos propios eliminamos del maestro de usuarios el usuario SAP*; esta eliminaci´on del superusuario SAP* no es sino una simple reinicializaci´on 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 estar´a plenamente operativo hasta que el la copia de datos se finalice – deberemos acceder a la opci´on de Copia Local disponible en la transacci´on SCCL o alternativamente Herramientas→ Gesti´on→ Gesti´on→ Gesti´on 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 CAP´ITULO 12. GESTION

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 soportar´a el aumento debido a la creaci´on 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 s´olo tendremos un mandante creado a medias sino que adem´as ser´a 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 impl´ıcitamente se estar´a 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 transacci´on SCCL acudiremos al men´ u desplegable a la opci´on Perfil→ Visualizar Perfil . En ellos b´asicamente 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, s´olo copias locales, s´olo copias remotas, s´olo para export de mandantes ). Una vez elegido el perfil lo u ´nico que deberemos hacer es pulsar el bot´on ejecutar o ejecutar en fondo. La opci´on ejecutar realiza el proceso de copia en di´alogo con lo que el sistema no nos devuelve el control de nuestra sesi´on hasta que termine el proceso de copia. Esta opci´on es totalmente desaconsejable porque la copia tarda mucho tiempo. Se recomienda usar siempre la opci´on ejecutar en fondo y programar la copia para una hora en la que sepamos que la actividad del sistema va a ser nula o m´ınima. Una vez lanzada la copia de mandante podremos acceder al log de la copia a trav´es de la transacci´on SCC3 o alternativamente por el men´ u desplegable Herramientas→ Gesti´on→ Gesti´on→ Gesti´on 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 alfab´eticamente tabla a tabla para copiar los registros que pertenecen al mandante origen en otros tantos registros cuyo mandante ser´a el mandante destino de la copia. El tiempo que consuma el proceso de copia depender´a 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 CAP´ITULO 12. GESTION

que se componga el mandante origen. Se deber´a tener en cuenta todo esto para dimensionar los tablespaces o devices – dependiendo del RDBMS – adecuadamente y evitar un llenado de ellos que provoque una cancelaci´on de la copia. Se debe recalcar que este proceso es muy cr´ıtico y extremadamente sensible a la carga de trabajo del sistema, ya que consume muchos recursos. En el momento de la ejecuci´on 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 podr´ıa provocar una cancelaci´on 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 producci´on 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 trav´es de la red, una copia remota es mucho m´as lenta que una copia local. La transacci´on de copia remota es SCC9 que puede ser accedida por el men´ u desplegable Herramientas→ Gesti´on→ Gesti´on→ Gesti´on 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 deber´a indicar un destino fuente como origen de la copia. Este destino fuente ser´a realmente una conexi´on RFC, necesaria para que ambos sistemas , fuente y destino se puedan comunicar para el traspaso de datos. En la definici´on de este sistema l´ogico estar´a incluido el sistema origen y el mandante origen. Por las mismas razones que en la secci´on 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 ser´an desconectados. Ser´a tarea del administrador lanzar la copia cuando no haya ninguna conexi´on al sistema o cancelar las conexiones ya existentes. En la copia remota, s´olo 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 deber´a 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 trav´es del programa de control de transporte tp, se realiza un export del mandante consistente en la exportaci´on a fichero de toda la informaci´on 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 espec´ıficos. Otra diferencia importante con respecto a la copia remota es que el sistema destino no tiene por qu´e ser accesible desde el sistema origen , como ocurr´ıa en la copia remota. Aunque el sistema destino, en este caso, no tiene por qu´e ser distinto del origen, este m´etodo se recomienda s´olo 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 transacci´on SCC8 o a trav´es del men´ u desplegable Herramientas→ Gesti´on→ Gesti´on→ Gesti´on de Mandantes→ Transporte de Mandante→ Export de Mandante. En este caso, igual que en los anteriores, se deber´a elegir un perfil de copia, y se podr´a elegir entre ejecuci´on real o de test as´ı como un lanzamiento del proceso de exportaci´on en di´alogo o background. Por las mismas razones que en las dos secciones anteriores se deber´a elegir la ejecuci´on en background.

150

´ DE MANDANTES CAP´ITULO 12. GESTION

Figura 12.6: Export de mandante

El sistema nos mostrar´a a continuaci´on una ventana de di´alogo inform´andonos 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 espec´ıficos:

<SID>KO(No secuencial) <SID>KT(No secuencial) <SID>SX(No secuencial)

Este proceso de exportaci´on de mandante tambi´en queda registrado en el log de copia, en la transacci´on SCC3. La creaci´on de estas 3 ´ordenes de transporte lleva asociada la creaci´on de ficheros a nivel de sistema operativo, con lo que tendremos como limitaci´on de espacio para esas ´ordenes el asignado a la unidad donde est´e establecido el directorio de transportes – en entornos Windows –, o el asignado al file system correspondiente – en entornos UNIX –. Deberemos recordar que la exportaci´on de mandante puede llegar a crear ficheros de gran tama˜ no, dependiendo de la informaci´on asociada al mandante a exportar; por lo que un llenado del file system o de la unidad de disco asignada causar´a una cancelaci´on del proceso de exportaci´on. Una vez creadas satisfactoriamente las ´ordenes de transporte lo u ´nico que restar´a ser´a importar (como se vio en el cap´ıtulo 11) en el sistema destino primero la orden asociada a los datos independiente de mandante, y despu´es la orden asociada a los datos dependientes de mandante con el programa de control de transporte tp. Como tercer paso deberemos importar los textos espec´ıficos conect´andonos

12.4. TRANSPORTE DE MANDANTE

151

al sistema destino y accediendo a Herramientas→ Gesti´on→ Gesti´on→ Gesti´on de Mandantes→ Transporte de Mandante →Trabajo Repaso Import. Introduciremos la orden de los textos espec´ıficos y pulsaremos ejecutar en di´alogo o background.

Cap´ıtulo 13 Mantenimiento de instancias 13.1.

Perfiles del sistema

El sistema SAP R/3 dispone de unos par´ametros de configuraci´on necesarios para el arranque y funcionamiento de sus instancias. En este cap´ıtulo veremos c´omo gestionar tales par´ametros para optimizar el funcionamiento del sistema R/3. Tales par´ametros nos permitir´an configurar tama˜ no de bufferes, idioma de conexi´on por defecto, mandante de conexi´on por defecto, tiempo de expiraci´on de passwords, n´ umero intentos fallidos de conexi´on para bloquear usuario, etc. . .

13.1.1.

Mantenimiento de perfiles del sistema

Los par´ametros activos se mantienen desde los Perfiles del Sistema. Estos perfiles son realmente 3 ficheros a nivel de sistema operativo donde se guarda toda la informaci´on t´ecnica del sistema R/3: 1. Perfil de Inicio: El nombre es Start <nombre m´ aquina>. Es un perfil u ´nico por instancia del sistema R/3 que contiene par´ametros 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 par´ametros globales para todo el sistema. 3. Perfil de Instancia: El nombre es <SID> <nombre de m´ aquina> y es un perfil u ´nico por instancia del sistema R/3 con par´ametros espec´ıficos de cada instancia. 153

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

154

Estos tres perfiles est´an 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 est´a compuesto de tres caracteres y que se establece en tiempo de instalaci´on 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 m´aquina distinta. Supongamos que tenemos la siguiente configuraci´on: Nombre base de datos SAP (SID): ”P11” Nombre m´aquina de la instancia central: ”servr001” Identificador instancia central: ”00”(este valor de identificador para la instancia se establece en tiempo de instalaci´on y no se puede cambiar) Nombre m´aquina de la instancia de aplicaciones: ”servr002” Identificador instancia aplicaciones: ”10” Los perfiles del sistema ser´an, 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 transacci´on RZ10, accesible por el men´ u desplegable desde Herramientas→ CCMS→ Configuraci´on→Actualizar Perfiles. En esta transacci´on existen 3 niveles de gesti´on de perfiles, en cada uno de los niveles se muestra distinto tipo de informaci´on: Datos de gesti´on. En este nivel se mantiene el path completo del fichero a nivel de sistema operativo, as´ı como fechas de modificaci´on y activaci´on del perfil en cuesti´on y autor de dicha modificaci´on y activaci´on.

13.1. PERFILES DEL SISTEMA

Figura 13.1: Pantalla pricipal perfiles del sistema

Figura 13.2: Datos de gesti´on de un perfil

155

156

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

Actualizaci´on b´asica . En este nivel no se permite introducir ning´ un par´ametro nuevo, s´olo modificaci´on de los par´ametros b´asicos 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 par´ametros relativos a los bufferes y al n´ umero de colas de trabajo. Ser´a este el perfil que debamos modificar si deseamos que una instancia o varias tengan una distribuci´on distinta de sus colas de trabajo.

Figura 13.3: Actualizaci´on b´asica de un perfil

Actualizaci´on ampliada . En este nivel se permite la visualizaci´on o modificaci´on de todos los par´ametros activos en el perfil seleccionado, as´ı como la introducci´on de nuevos par´ametros. Algunos par´ametros tienen documentaci´on asociada en este nivel que puede ser visualizada pulsando F1 sobre el par´ametro deseado.

13.1. PERFILES DEL SISTEMA

157

Figura 13.4: Actualizaci´on 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 s´olo a nivel de sistema operativo por lo que ser´a necesario importar dichos perfiles para que se puedan mantener desde dentro del sistema. A esta herramienta de importaci´on se accede desde la RZ10 en la opci´on del men´ u desplegable Utilidades→Importar Perfil→ De servidores Activos. Una vez que ejecutemos la importaci´on de los perfiles desde el sistema operativo, los tendremos disponibles en la transacci´on RZ10. Pulsando la ayuda de b´ usqueda correspondiente al campo Perfil, el sistema nos mostrar´a en un listado los perfiles importados.

158

13.1.3.

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

Visualizaci´ on todos los par´ ametros activos

Existen m´as par´ametros t´ecnicos de configuraci´on SAP que los que aparecen en los perfiles antes indicados. Se pueden ver todos los par´ametros activos en SAP ejecutando el programa RSPARAM desde la transacci´on SE38 (editor ABAP/4). Si un par´ametro 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 par´ametro determinado est´a activo en el sistema deberemos ejecutar el programa antes mencionado y comprobar si aparece en el listado. Si no aparece, esto significar´a que el par´ametro no est´a activo en el sistema. Si deseamos modificar un par´ametro al que s´olo se puede acceder a trav´es de la ejecuci´on del programa RSPARAM, deberemos proceder incluy´endolo como un par´ametro nuevo en cualquiera de los perfiles existentes. Si es un par´ametro que debe tener un valor distinto por cada instancia o que s´olo se debe activar en determinadas instancias de nuestro sistema, deberemos incluirlo en el perfil de instancia de las instancias adecuadas; si el par´ametro 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 modificaci´on sobre cualquiera de los perfiles de inicio y de instancia – bien sea en la modificaci´on del valor de un par´ametro o en la inclusi´on de un nuevo par´ametro – no toman efecto hasta que la instancia en cuesti´on sea reiniciada. Cualquier modificaci´on 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 modificaci´on de cualquiera de sus tres perfiles a trav´es de una ventana de di´alogo. La modificaci´on de los perfiles del sistema requiere de un paso m´as adem´as de la grabaci´on en s´ı de las modificaciones; este paso es la Activaci´ on del perfil. El concepto de activaci´on o generaci´on se encuentra presente en muchas de las aplicaciones de SAP como puede ser el mantenimiento de perfiles y autorizaciones de usuario, programaci´on o mantenimiento de tablas, etc. . . La grabaci´on de una modificaci´on de tales objetos supone la creaci´on de una nueva versi´on de ese objeto a nivel de SAP R/3 pero el sistema no la toma como la actual. La activaci´on o generaci´on de ese objeto supone, en algunos casos como los programas y tablas, la modificaci´on real de ese objeto en la base de datos o la modificaci´on real a nivel de sistema operativo como es el caso de la activaci´on 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 par´ametros existentes en un sistema R/3 es pr´acticamente imposible conocer a fondo todos ellos, sin embargo existen varios que, por su importancia en procesos b´asicos de administraci´on, toman un papel muy importante. A continuaci´on listamos algunos de los par´ametros m´as importantes. Nombre par´ametro

Valor de ejemplo Descripci´on

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 -alem´an, E -ingl´es- , S -espa˜ nolidioma por defecto mandante por defecto

Modos de Operaci´ on

En muchos casos ser´a absolutamente necesario cambiar la configuraci´on de las colas de trabajo de nuestro sistema R/3 de una forma peri´odica debido a exigencias de operativa de nuestra empresa. Las exigencias m´as comunes son la definici´on de m´as procesos de trabajo de tipo batch durante el procesamiento nocturno, que deber´an ser minimizadas en cantidad durante el horario de trabajo de nuestra empresa para dar m´as prioridad a los procesos de di´alogo. Esto nos optimizar´a la ejecuci´on de jobs de carga o modificaci´on masiva de datos que se pueden realizar sin intervenci´on del usuario durante la noche. Esta modificaci´on en el n´ umero de procesos de trabajo, si no dispusi´eramos de la herramienta de Modos de Operaci´ on, nos llevar´ıa 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

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

quisiera cambiar la configuraci´on de los procesos de trabajo. Un Modo de Operaci´ on no es m´as 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 configuraci´on de procesos determinada durante un intervalo de tiempo, y adem´as el sistema cambiar´a en modo on line, sin necesidad de parar el sistema, a otra configuraci´on cuando llegue la hora de su activaci´on. Ejemplo : Supongamos un sistema SAP formado por una u ´nica instancia donde est´an configuradas 15 colas de trabajo. Podemos definir dos modos de operaci´on: diurno y nocturno. En el modo de operaci´on diurno daremos prioridad a los procesos de di´alogo definiendo m´as procesos DIA mientras que en el nocturno daremos prioridad a los procesos en fondo definiendo m´as 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 entrar´an por los procesos de di´alogo; 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 habr´a ning´ un usuario conectado al sistema y nos deberemos asegurar que el sistema podr´a 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 adem´as, de otra forma, no podr´ıamos conectarnos al sistema en caso de urgencia ya que

´ 13.2. MODOS DE OPERACION

161

las conexiones de los usuarios al sistema se gestionan a trav´es de procesos DIA.

13.2.1.

Gesti´ on de modos de operaci´ on

Para crear modos de operaci´on deberemos acceder a la transacci´on RZ04, o alternativamente por el men´ u desplegable Herramientas→ CCMS→ Configuraci´on→ Mod Oper + Servidores .

Figura 13.5: Modos de operaci´on

En esta pantalla aparecer´an los modos de operaci´on 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 opci´on Instancias/Form.op – accederemos a una pantalla donde aparecen los siguientes campos:

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

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 Operaci´on Modo de operaci´on asociados a la instancia. Procesos de trabajo N´ umero y tipo de colas de trabajo de las que se compone el modo de operaci´on 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 operaci´on definidos en nuestro sistema. Si deseamos modificar la configuraci´on de alguno de los modos de operaci´on definidos en el sistema, haremos doble click sobre el modo de operaci´on deseado con lo que accederemos a la ventana de di´alogo 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: Distribuci´on de procesos de trabajo

La u ´nica limitaci´on que impone esta herramienta es que el total de procesos no puede cambiar. Si aumentamos el n´ umero de colas de di´alogo, posicion´andonos en la linea correspondiente y pulsando el bot´on ”+”, el

´ 13.2. MODOS DE OPERACION

163

sistema autom´aticamente disminuir´a 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 disminuir´a en la misma cantidad el n´ umero de colas de di´alogo. Si deseamos aumentar o disminuir el n´ umero total de colas de una o varias instancias, no podremos realizarlo a trav´es de los modos de operaci´on, sino que se deber´a realizar a trav´es del mantenimiento de los perfiles de instancia, con lo que el cambio no se activar´a realmente hasta que las instancias modificadas sean reiniciadas de nuevo. Hasta ahora hemos visto c´omo crear o modificar un modo de operaci´on, 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 transacci´on SM63 o a trav´es del men´ u desplegable Herramientas→ CCMS→ Configuraci´on→ Planificar Modos Operaci´on:

Figura 13.7: Pantalla principal asignaci´on horaria

En esta pantalla tenemos la posibilidad de asociar un modo de operaci´on, bien sea normal (diario) o excepcional (v´alido s´olo para determinados d´ıas), a un intervalo horario. Elegiremos la opci´on modo de operaci´on 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

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

horas determinadas.

Figura 13.8: Asignaci´on horaria a modos de operaci´on

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 pr´acticamente 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 aplicaci´on disponibles en nuestro sistema R/3. Cuando los usuarios se conectan al sistema R/3 deber´an elegir uno de los grupos de logon definidos con lo que la conexi´on al sistema R/3 se produce exclusivamente a trav´es de una de las instancias asociadas a ese grupo. De esta manera, definiendo grupos de logon para cada una de las ´areas de aplicaci´on de SAP que sean usadas por nuestra empresa, podremos conseguir un ´optimo balance de carga de trabajo en los servidores SAP. La definici´on de grupos de logon, adem´as, nos permite un rendimiento ´optimo de los bufferes ya que los usuarios que van a realizar tareas similares se conectar´an 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 informaci´on es mucho m´as r´apido. 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, m´odulos de SAP, etc . . .

13.3.1.

Gesti´ on de grupos de logon

Los grupos de logon se pueden definir en la transacci´on SMLG, por el men´ u desplegable Herramientas→ CCMS→ Configuraci´on→ 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 bot´on Crear Entrada . En esta ventana deberemos introducir el nombre descriptivo del grupo, que en general ser´a 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 m´as l´ogico ser´a dar ese mismo nombre al grupo de logon. Adem´as del nombre descriptivo se deber´a introducir la instancia por la que se conectar´an los usuarios que entren por ese grupo. Podremos restringir los accesos a este grupo de logon por direcci´on IP, por tiempo de respuesta o por n´ umero de usuarios ya conectados. Estas restricciones, si se activan, permitir´an accesos a trav´es de dicho grupo s´olo si el servidor de presentaci´on se encuentra en el intervalo de direcciones IP inclu´ıdas, o s´olo si su conexi´on 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 m´aximo establecido. Una vez que se han definido los grupos de logon, cada servidor de

166

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

Figura 13.9: Pantalla principal grupos de logon

presentaci´on deber´a tener instalado el programa saplogon.exe, que se instala con el sapgui. Este programa permite tener un u ´nico icono de conexi´on a SAP para todos los sistemas SAP y grupos de logon de los que dispongamos.

13.3.2.

Saplogon

A continuaci´on veremos c´omo se debe usar el programa saplogon incluido como opci´on de instalaci´on del sapgui. Lo primero que deberemos hacer es ejecutar el programa que se encontrar´a 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 trav´es de iconos de servidores de aplicaci´on nos conectan a un sistema SAP por un servidor determinado, mientras que los grupos de logon nos conectan a trav´es de uno de los servidores que tenga asociados ese grupo, con lo cual si un servidor queda indisponible, el grupo de logon elige autom´aticamente otro servidor asociado. Esto redunda en una mejor gesti´on de acceso de los usuarios. Para crear en el saplogon tantas entradas como servidores hay en un

13.3. GRUPOS DE LOGON

167

Figura 13.10: Pantalla detalles creaci´on grupo logon

sistema, lo u ´nico que deberemos hacer es pulsar el bot´on 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 est´a la instancia central. A continuaci´on pulsaremos el bot´on 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 bot´on Logon, el programa simplemente nos conecta al sistema indicado a trav´es del servidor seleccionado, pero no a˜ nade la entrada al saplogon. Si pulsamos el bot´on Add, los servidores seleccionados son a˜ nadidos al saplogon. De manera similar podemos insertar los grupos de logon definidos en un sistema; pulsando el bot´on 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 transacci´on SMLG. Procediendo de igual manera que con la opci´on Server, obtendremos el listado

168

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

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 opci´on Properties nos permite crear de una manera m´as r´apida que la opci´on Server una entrada de icono de acceso a trav´es de un servidor de aplicaciones. Para ello lo u ´nico que deberemos indicar es el nombre del servidor en el campo Application Server, una descripci´on 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 ser´a 00 – en el campo System Number. La opci´on Edit edita la entrada seleccionada, ya sea icono de servidor o de grupo, y por u ´ltimo, la opci´on Delete elimina la entrada del saplogon seleccionada. El programa saplogon, en definitiva, nos facilita la conexi´on 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.

13.3. GRUPOS DE LOGON

Figura 13.12: Opci´on de selecci´on servidor en saplogon

Figura 13.13: Opci´on propiedades en saplogon

169

Ap´ endice A Transacciones m´ as comunes DB02 An´alisis de tablas e ´Indices DB14 Mostrar logs actividad SAPDBA PFCG Generador de perfiles. RZ01 Monitor para previsi´on de jobs RZ02 Gr´afico grafos de instancias SAP RZ03 Representaci´on,Control instancias SAP RZ04 Actualizar instancias SAP RZ06 Alerts Thresholds Maintenance RZ08 Monitor alert SAP RZ10 Actualizar par´ametros perfil RZ11 Actualizaci´on par´ametros de perfil RZ12 Actual.asignaci´on grupos serv.RFC SA38 Informes ABAP SA39 SA38 para transacci´on par´ametros SAR Actualizar c´odigos de transacci´on SAR0 Visualizar ´arbol de informes est´and. SARA Gesti´on 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 - selecci´on especial SCC3 Copia mandante Log SCC4 Gesti´on mandantes SCC5 Borrado de mandante SCC6 Importaci´on de mandante SCC7 Import.mandante - tratam.posterior SCC8 Export mandante SCC9 Copia mandante remota SCCL Import.mandante - tratam.posterior SCMP Comparaci´on vista/tablas SCPF Generar gu´ıa implem. para la empresa SCPI Interfase optimizaci´on de producci´on SCT1 Resumen - Imports l´ogicos SCU0 Comparac.Customizing SE01 Transport Organizer SE03 Workbench Organizer: Herramientas SE06 Instalar Workbench Organizer SE07 Visual.status gesti´on transp SE09 Workbench Organizer

173 SE10 Customizing Organizer SE11 Actualizaci´on Dictionary ABAP SE13 Par´am.memoria para actual.tablas SE14 Utilities para tablas Dictionary SE15 Sistema Info Dictionary SE16 Browser de datos SE17 Visualizar tabla (general) SE30 An´alisis tiempo ejecuci´on ABAP SE37 M´odulos 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 Traducci´on SE80 Browser Repository SE84 Sistema Info Repository SE85 Sistema Info ABAP/4 Dictionary SE86 ABAP/4 Sistema Info SE91 Actualizar mensajes SE93 Actualizar c´odigos de transacci´on 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 actualizaci´on SM21 Log de sistema SM30 Llamar actualizaci´on de vistas SM31 Actualizar tablas SM35 Monitoring batch input SM36 Solicitud para proceso de fondo SM37 Resumen de jobs de fondo SM38 Transacci´on de gesti´on queue SM39 An´alisis jobs SM49 Ejecuci´on 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 Gesti´on de ampliaciones SAP SMX Visualizar jobs propios ST01 Trace sistema ST22 ABAP/4 An´alisis errores tiempo ejec. STAT Estad´ısticas de acceso al sistema SU01 Actualizaci´on de usuarios

175 SU01D Visualizar usuarios SU02 Actualizar perfiles de autorizaci´on SU03 Actualizar autorizaciones SU10 Modificaciones masa Maestros usuario SU12 Modificaciones masa Maestros usuario SU20 Actualizar campos de autorizaci´on SU21 Actualizar objetos de autorizaci´on SU22 Utiliz.obj.autoriz.en transacciones SU24 Verif.obj.autoriz.bajo transacciones SU53 Visualizar valores de verificaci´on 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 versi´on 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 publicaci´on antes de suscribirse. http://www.sapfans.com Excelente web dedicada enteramente a SAP. Tienen foros de usuarios, chat, art´ıculos, descripciones de los diferentes productos de SAP, etc. Son especialmente interesantes los foros de discusi´on abiertos de los que existe uno por cada m´odulo 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, cat´alogos de libros, an´alisis 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 documentaci´on del Simplification Group. Esta documentaci´on incluye art´ıculos, white papers e incluso libros completos, todo ello en formato PDF. Es la mejor documentaci´on 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 inform´atico. 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 implementaci´on del sistema SAP R/3, en una situaci´on en la que sus sistemas de gesti´on no se correspond´ıan con las necesidades de la empresa, raz´on por la cual se necesitaba un cambio radical que se ajustara a la situaci´on de r´apido crecimiento y expansi´on internacional que estaba experimentando. El proyecto que se planific´o para conseguir tales fines, System 2000, se bas´o en cinco objetivos principales: Globalizaci´on del software de aplicaci´on de negocio: Los procesos de negocio no se deb´ıan ver limitados por limitaciones del sistema o por fronteras geogr´aficas. La informaci´on deb´ıa fluir en tiempo real para todos los aspectos del negocio. El nuevo sistema inform´atico deb´ıa ser capaz de soportar todos los idiomas, operaciones, as´ı como procedimientos de c´alculo de impuestos espec´ıficos de cada pa´ıs en los que Autodesk ten´ıa alg´ un centro o filial. Los tiempos de los procesos de negocio se deb´ıan ser claramente reducidos. Gesti´on precisa de inventario. 179

´ APENDICE C. CASOS REALES

180

Como manufacturador de productos de software para UNIX y Windows NT, Autodesk insisti´o en disponer de un sistema abierto con arquitectura cliente / servidor para la gesti´on de sus procesos de negocio. El producto R/3 de SAP result´o ser el sistema que mejor se ajustaba a las necesidades de la empresa. Los m´odulos R/3 de contabilidad financiera, controlling, gesti´on de materiales, ventas y distribuci´on fueron implementados en los centros americanos en s´olo 6 meses.

C.2.

Schweppes, S.A.

Sector Schweppes, S.A. pertenece al grupo Cadbury Schweppes dentro de su divisi´on de bebidas y su actividad radica en la fabricaci´on y distribuci´on de bebidas refrescantes. Schweppes est´a compuesto por una plantilla de m´as de 1.000 personas. Dispone de una sofisticada red de distribuci´on formada por 30 delegaciones de ventas, 8 cabeceras de ´area, m´as de 1.000 distribuidores y 20 almacenes, lo que le permite dar servicio a sus m´as de 200.000 clientes de una forma r´apida y eficaz. Toda esta infraestructura, la existencia de sistemas de informaci´on distribuidos sin ninguna conexi´on entre las aplicaciones y sin una conexi´on geogr´afica entre las distintas ´areas de venta y las oficinas centrales llev´o a Schweppes en 1989 a tomar la decisi´on de elegir SAP R/2 como la mejor herramienta para la gesti´on de la compa˜ n´ıa. La calidad del paquete SAP R/3 evaluado en la casa matriz y la experiencia obtenida de la utilizaci´on del sistema R/2 llev´o a Schweppes en 1995 a seguir con la tecnolog´ıa de SAP; en este caso el sistema R/3, como la opci´on segura para la gesti´on 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. Comunicaci´on con distribuidores, proveedores y clientes Las razones que llevaron a elegir R/3 como sistema de informaci´on fueron:

˜ C.3. IBM ESPANA

181

El sistema deb´ıa ser u ´nico para conseguir una reducci´on de costes. Deb´ıa cumplir los requerimientos para la transici´on de milenio. Facilidad de conversi´on de moneda. Implantaci´ on La implantaci´on 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 implantaci´on del m´odulo de control de calidad (QM). En el mes de octubre se implant´o el m´odulo de gesti´on de materiales (MM). En el mes de enero se implantaron los m´odulos de FI, CO, AM y FI-SL en el ´area financiera. Los m´odulos de ventas y vistribuci´on (SD) y planificaci´on de la producci´on (PP) quedaron implantados en junio de 1997. Infraestructura Est´a basada en una plataforma AIX con un SP de IBM para producci´on en el mismo ”frame”en el que reside el sistema de data warehouse, herramienta complementaria a SAP R/3 y con Oracle como base de datos. Asimismo, existe una m´aquina 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 dispersi´on de las f´abricas, 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 investigaci´on, desarrollo y venta de productos y servicios de tecnolog´ıa de la informaci´on. El hecho que IBM opere en 164 pa´ıses en los 5 continentes supone una gran diversidad de necesidades espec´ıficas a nivel de cada pa´ıs, lo cual lleva a distintas aplicaciones y distintos procesos. Adem´as, el operar en un mercado cada vez m´as multinacional impone una unificaci´on de procesos que permita hacer negocios cross-border, as´ı como una reducci´on en el desarrollo

´ APENDICE C. CASOS REALES

182

y mantenimiento de miles de aplicaciones que hoy en d´ıa mantiene el negocio de IBM. Estudio de Necesidades En un estudio de necesidades, exist´ıan b´asicamente dos opciones, adem´as 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 quer´ıa abordar. Las dos opciones eran ir a SAP o desarrollar un sistema propio. IBM apost´o 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 tecnolog´ıas ya anticuadas. Por su estructura de soporte. Proyecto Piloto Como proyecto piloto se eligi´o Espa˜ na por el tama˜ no de su mercado y caracter´ısticas para la instalaci´on de SAP R/3 a nivel internacional. En una primera fase se instalaron los m´odulos de ventas y distribuci´on (SD) y gesti´on de materiales (MM) de la versi´on 3.0D. Para 1998 estaba prevista la implementaci´on del m´odulo de finanzas (FI) casi en su totalidad. La divisi´on encargada de utilizar el sistema es ”Fulfilment dentro de ella b´asicamente el departmento de administraci´on. La aplicaci´on se utiliza para cubrir los siguientes procesos comerciales: 2

Preparaci´on de una propuesta. El pedido. El env´ıo a la planta de fabricaci´on. El env´ıo desde la planta al pa´ıs. El env´ıo al cliente.

˜ C.3. IBM ESPANA

183

Facturaci´on. Dada la naturaleza del negocio fue necesario la realizaci´on de algunas interfaces con otras aplicaciones para la conexi´on con otros departmentos y divisiones de la empresa. Ello llev´o a una reingenier´ıa de procesos. Dicha reingenier´ıa ha tra´ıdo consigo una simplificaci´on que se ha visto reflejada en un mejor servicio al cliente que es el objetivo primordial de IBM. La instalaci´on 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 programaci´on del sistema SAP R/3. Es un lenguaje de cuarta generaci´on, con una sintaxis mezcla entre COBOL y SQL. ASAP AcceleratedSAP. Metodolog´ıa de implementaci´on de SAP R/3 que busca el ahorro m´aximo de tiempo de parametrizaci´on. Batch input M´etodo para la importaci´on r´apida y consistente de datos en R/3 partiendo de ficheros externos. CATT Computer-Aided Test Tool. Herramienta para la generaci´on de datos de test para probar el software. CO Customizing Organizer. Herramienta para administrar las ´ordenes de transporte de parametrizaci´on. Dynpro DYNamic PROgram. Programa din´amico que consiste en una pantalla y la l´ogica 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 r´apidamente problemas de rendimiento en nuestro sistema productivo. Entreprise IMG Gu´ıa de implementaci´on de la empresa. Cuando se inicia la parametrizaci´on de un sistema SAP hay que crear el Enterprise IMG incluyendo los m´odulos que se va a implementar. 185

186

´ APENDICE D. GLOSARIO

Front End T´ermino 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 informaci´on con el ordenador de manera f´acil 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 est´andar. 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 formaci´on. IMG Implementation Guide. Transacci´on que contiene un ´arbol con cientos de transacciones de parametrizaci´on agrupadas por m´odulos 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 actualizaci´on que aegura la integrad de los datos. Modo Cada una de las seis pantallas como m´aximo que puede abrir un usuario desde que abre una sesi´on con R/3. OSS Online Service System. Servicio de atenci´on al cliente de SAP que funciona conect´andose 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 gesti´on 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 conexi´ones 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 aplicaci´on que trabajen con ´el junto con el software R/3 instalado en ellos. La identificaci´on de un sistema SAP se denomina SAPSID o simplemente SID y es un c´odigo 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 aplicaci´on proporcionan a SAP para gestionar las peticiones de di´alogo, fondo, spool, actualizaci´on. . .

Bibliograf´ıa [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] Edici´on 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 Hern´andez Mu˜ noz, Jos´e 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