DE SISTEMAS DE GESTION INFORMACION

Universidad de Deusto - Facultad de Ingenier a

Antonio Toledo Carnicero Pablo P erez P erez c Octubre de 2004

c
copyleft
Copyright (c) 2004 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) 2004 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 10 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 camente 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 aca 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 licenciando en Ciencias F sicas por la Universidad del Pa s Vasco desde el a no 1995. Trabaj o tambi en como programador de ABAP/4 y administrador de sistemas en la empresa Grupo Antol n. Despu es prest o servicios de administraci on y consultor a de sistemas formando parte de la empresa Ceinsa. En la actualidad trabaja en la consultora IT Deusto formando parte del equipo de administraci on de sistemas SAP R/3 de Iberdrola. 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 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 2 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 45 45 46 46 46 47 47 47 48 50 50 51 52

4. Escenarios de conguraci 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. Conguraci on con un s olo sistema (Producci on) . . . . 4.4.2. Conguraci on con dos sistemas (Desarrollo y Producci on) 4.4.3. Conguraci on con tres sistemas (Desarrollo, Integraci on y Producci on) . . . . . . . . . . . . . . . . . .

5. Monitorizaci on de procesos y usuarios 55 5.1. Monitorizaci on de procesos activos . . . . . . . . . . . . . . . 55 5.2. Monitorizaci on usuarios conectados . . . . . . . . . . . . . . . 60 6. Procesamiento en fondo 6.1. Conceptos de procesamiento en fondo 6.2. Denici 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 . . . . 65 65 66 66 67 68 68 69 70 73 73 75 75 77 80 85 85 86 86 88

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

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

. . . . . . . . . . sistema . . . . . . . . . .

. . . . .

. . . . .

. . . . .

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

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

 INDICE GENERAL 8.1.4. Leyendo el log del sistema . . . . . . . . 8.1.5. Opciones de relectura del log del sistema 8.1.6. Accediendo a logs remotos del sistema . 8.2. Concepto de dump . . . . . . . . . . . . . . . . 8.2.1. Accediendo a los dumps del sistema . . . 8.2.2. Interpretando los dumps . . . . . . . . . 9. Gesti on de spool 9.1. Concepto de spool . . . . . . . . . 9.2. Instalaci on de una impresora . . . . 9.3. Como imprimir . . . . . . . . . . . 9.4. Operaciones sobre ordenes de spool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 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 perles . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . 121 . 121 . 124 . 124 . 126 . 127 . 131 . 136 139 140 145 148 149

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

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

13.Mantenimiento de instancias 13.1. Perles del sistema . . . . . . . . . . . . . . . . . 13.1.1. Mantenimiento de perles del sistema . . . 13.1.2. Importaci on de perles 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 . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

153 . 153 . 153 . 157 . 158 . 159 . 159 . 161

INDICE GENERAL 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 B. Recursos Web

171 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 guras
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. Monitor de procesos de una instancia . . . . . Monitor de instancias activas . . . . . . . . . Monitor de sistema operativo . . . . . . . . . Monitor de conexi on de usuarios por instancia Lista de modos activos por usuario . . . . . . Informaci on detalllada de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 59 60 61 62 62

6.1. Pantalla inicial de denici on de job . . . . . . . . . . . . . . . 66 6.2. Pantalla inicial de selecci on de jobs . . . . . . . . . . . . . . . 69 6.3. Resumen de jobs seleccionados . . . . . . . . . . . . . . . . . . 70 7.1. 7.2. 7.3. 7.4. 7.5. Esquema funcionamiento actualizaci on as ncrona . Esquema funcionamiento actualizaci on s ncrona . Pantalla principal monitor actualizaci on . . . . . Actualizaciones pendientes . . . . . . . . . . . . . M odulos de actualizaci on . . . . . . . . . . . . . . 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 74 76 78 79

10

INDICE DE FIGURAS 7.6. Pantalla principal entradas de bloqueo . . . . . . . . . . . . . 81 7.7. Listado de bloqueos activos en el sistema . . . . . . . . . . . . 81 7.8. Informaci on detallada de un bloqueo . . . . . . . . . . . . . . 82 8.1. 8.2. 8.3. 8.4. 8.5. 8.6. 8.7. 9.1. 9.2. 9.3. 9.4. 9.5. 9.6. 9.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 . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 88 90 90 91 93 93 104 105 106 107 109 109 110 112 114 115 116 117 118 119 119 123 123 125 127 128 129 131 133 134 135 137 137

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

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 . . . . . . . . . . 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 . . . . . . 11.12. Log del transporte de una orden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

 INDICE DE FIGURAS 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 perl de copia . . . . . . . . . . 12.5. Copia remota de un mandante . . . . . . . . . 12.6. Export de mandante . . . . . . . . . . . . . . 13.1. Pantalla pricipal perles del sistema . . . 13.2. Datos de gesti on de un perl . . . . . . . 13.3. Actualizaci on b asica de un perl . . . . . 13.4. Actualizaci on ampliada de un perl . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11 141 142 145 147 148 150 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 claricador de esta situaci on. El director del departamento de TI de una empresa dedicada a la fabricaci on de grandes piezas industriales, reeja 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 planicaci 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

14

A SAP R/3 CAP ITULO 1. INTRODUCCION 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 especicas 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 deciencias 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 nanciera, 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 scales 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 nales 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. . . .
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 signicado completo de customizing viene a ser modicaci on de los par ametros del sistema para adecuarlo a las necesidades del cliente
1

16

A SAP R/3 CAP ITULO 1. INTRODUCCION

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 (nanzas, 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 nanciera. 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 nanciera no siempre puede proporcionar informaci on desde todos los puntos de vista que una gesti on ecaz 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 planicaci 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 nanciera ecaz. Nos permite asegurar la liquidez de la empresa en todo momento y estructurar los activos nancieros 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 jos 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 vericaci 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. Planicaci 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 planicaci 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 planicaci on de las revisiones, la programaci on de ordenes de mantenimiento, las gesti on noticaciones de aprobaci on nos aseguran una rendimiento optimo de nuestra f abrica. Integrando todo esto con PP (podemos modicar 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 sucientemente exible 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 nancieros del estado de nuestras ventas es una labor imprescindible para poder conocer el estado econ omico y nanciero 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 scales. . . Este subm odulo es posiblemente el m as espec co de cada pa s debido a que las leyes que rigen las relaciones laborales dieren 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 scal, 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 denicici on de tareas de puestos de trabajo y la reorganizaci on de los mismos.

 GENERAL DE SAP R/3 1.2. VISION

19

1.2.3.

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 ca 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, modicar y borrar los objetos de bases de datos, entre los que se incluyen tablas, estructuras, vistas, elementos de datos y dominios. Las deniciones de las tablas, por ejemplo, pueden ser referenciadas directamente en los programas permiti endonos modicar 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 vericaci 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.

20

A SAP R/3 CAP ITULO 1. INTRODUCCION

Screen Painter Con esta herramienta crearemos r apidamente interfases gr acas 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 denicion 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. . .

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 (PCs) 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 gura 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 especicados, deber a indicar a qu e mandante se quiere conectar.

2.2.

Concepto de mandante

El concepto se puede denir 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 modicaci on de este tipo de datos, el sistema avisa con un mensaje informativo inform andonos de que la modicaci on afectar a a todos los mandantes. Se ha de ser especialmente cuidadoso al modicar 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 modicar 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 modicando 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 modicarla, user2 podr a ver la modicaci on realizada por user1, e incluso podr a realizar cualquier modicaci 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:

24

AL SAPGUI CAP ITULO 2. INTRODUCCION 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 jas 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

25

2.5.

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 conrmar 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

26

AL SAPGUI CAP ITULO 2. INTRODUCCION

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

28

AL SAPGUI CAP ITULO 2. INTRODUCCION

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 congurada 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 congurada el Sistema R/3 en el servidor, sino que es dependiente de la conguraci on de cada servidor de presentaci on.

 2.9. VENTANA DE DIALOGO

29

2.9.

Ventana de di alogo

Un elemento nal de la ventana R/3 es la ventana de di alogo en la que el sistema nos presenta una ventana otante donde normalmente nos pedir a la introducci on de alg un dato o la conrmaci 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 gura 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 ca 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 identican por aparecer a la derecha del campo de entrada un peque no recuadro con una echa vertical apuntando hacia abajo como podemos ver en la gura 2.7. Esta echa podr a estar activa permanentemente o s olo cuando posicionemos el cursor sobre dicho campo. Veamos esto con un ejemplo:

30

AL SAPGUI CAP ITULO 2. INTRODUCCION

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 gura 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 modicaciones hechas se perder an sin que el sistema emita un mensaje de advertencia. Borrar el modo actual Indicar: /i.

32

AL SAPGUI CAP ITULO 2. INTRODUCCION 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 denir a una transacci on nanciera 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 verica 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

33

2.13.

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 gura 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 gura 2.10 que tiene las siguientes opciones.

Figura 2.10: Menu del icono de acceso a opciones t ecnicas

Opciones nos permite recongurar 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 ).

34

AL SAPGUI CAP ITULO 2. INTRODUCCION

Generar Gr aco es una herramienta que nos crea una pantalla similar a la que estamos visualizando con la herramienta de gr acos 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 congurada 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 SistemaStatus, 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 reere a la hora actual del servidor y la hora de la barra de estado se reere 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 reere 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 losof 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

38

CAP ITULO 3. ARQUITECTURA DE UN SISTEMA R/3

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 conere 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 cas 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 gura 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 bueres especiales en cada servidor de aplicaci on situados en la memoria principal. Reduce el tr aco de red y los accesos a base de datos. La optimizaci on de los bueres es asegurada por el mecanismo de sobrescritura LRU (Least Recently Used) que consigue mantener en memoria

40

CAP ITULO 3. ARQUITECTURA DE UN SISTEMA R/3

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 oine 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 bueres en memoria compartida Los servicios de la capa de aplicaci on se pueden clasicar 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_<TCP/IP Port>

 3.3. SERVICIOS DE APLICACION Servicios de di alogo

41

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 nal 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 modicaciones 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 modicado 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 cos para la realizaci on de tareas, especialmente largas, que no requieran la intervenci on del usuario nal. De esta forma se podr an planicar tareas pesadas como la carga o modicaci 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

42

CAP ITULO 3. ARQUITECTURA DE UN SISTEMA R/3

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 conguraci on

Cualquier entorno de software de gesti on empresarial presenta la necesidad de tener sistemas completos (hardware y software) separados dedicados a funciones espec cas. Entre estas funciones podemos destacar el desarrollo del software, las pruebas del mismo, la formaci on a los usuarios nales y, la m as importante de todas, la puesta en producci on del software. SAP R/3 dispone de m ultiples alternativas de conguraci 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 denici 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 inuyen en
1

En la version 4.0B

45

46

CAP ITULO 4. ESCENARIOS DE CONFIGURACION

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 denitivas del software que incluyen: Pruebas integradas Con ellas nos aseguramos que nuestros desarrollos no intereren en otros m odulos del sistema. Tambi en debemos probar
Go Livees el t ermino ingl es que se utiliza para referirse al momento en que el sistema productivo se abre a los usuarios nales para que comienzen a trabajar.
2

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 suciente volumen de datos podemos probar la eciencia de nuestro software permiti endonos descubrir errores no funcionales pero que nos imposibilitan poner en explotaci on los programas. Pruebas de usuario El usuario nal 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 especicaciones. 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 modicar, 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 condencialidad 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 modicado 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 conictos 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 ables 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 nales. Una vez superadas las pruebas correspondientes al mandante 300, pasamos el prototipo aqu para que los usuarios nales 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 intereren en nuestro trabajo de implantaci on habitual.
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.
3

50

CAP ITULO 4. ESCENARIOS DE CONFIGURACION

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 conguraci on desde un s olo sistema hasta cuatro. El escenario que aconseja en todas sus especicaciones 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 conguraciones.

4.4.1.
Ventajas

Conguraci on con un s olo sistema (Producci on)

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 simplica en cierto modo. Desventajas Tendremos problemas con las tablas independientes de mandante. Problemas durante la instalaci on y pruebas de los parches. Tendremos dicultades 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 conguraci 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 signica 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 conguraci on para centros de formaci on o demostraci on del producto.

4.4.2.
Ventajas

Conguraci on con dos sistemas (Desarrollo y Producci on)

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 condencialidad 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

52

CAP ITULO 4. ESCENARIOS DE CONFIGURACION 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 conguraci 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.
Ventajas

Conguraci on con tres sistemas (Desarrollo, Integraci on y Producci on)

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 nal 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 conguraci on que recomienda SAP y es la que utilizan la mayor a de las empresas grandes que tienen presupuesto y personal suciente para gestionar todos los sistemas. Cuando se instalan muchos m odulos diferentes y de areas diferentes (log stica, nanzas y recursos humanos) se hace necesario tener un sistema aislado para las pruebas integradas. Un conguraci 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 cualicado 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 nales para identicar 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 HerramientasGesti on MonitorSupervisar SistemaResumen Procesos. En la pantalla de la gura 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 identicador 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 identicador 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 identicarlos. 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 nalizado 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 ProcesoReanudar 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 chero de log a nivel de sistema operativo, el sistema asigna unos c odigos a cada proceso de trabajo. El sem aforo para escritura en chero 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 buer, por lo que el sistema no lo volver a a compilar hasta que lo pierda del buer 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 ProcesoCancelar con core y Proceso Cancelar sin core. Ambas opciones cancelan el proceso a nivel de sistema operativo asociado al proceso de SAP con la salvedad que la opci on con core genera un chero llamado core donde queda registrada la raz on de la cancelaci on del proceso. Como este chero 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 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 o acudir directamente a la transacci on SM51 (Herramientas Gesti on MonitorSupervisar SistemaServidor ). En la transacci on SM51 visualizamos las instancias que est an activas y que componen el sistema SAP. Desde esta transacci on podremos saber 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

 DE PROCESOS ACTIVOS 5.1. MONITORIZACION

59

Figura 5.2: Monitor de instancias activas

instancia SAP y por u ltimo, en la columna Tipo se visualizan los tipos de procesos de trabajo que 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 en el men u desplegable Pasar a Collector SO. 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 cheros ejecutables compilados en lenguaje C necesarios

60

DE PROCESOS Y USUARIOS CAP ITULO 5. MONITORIZACION

Figura 5.3: Monitor de sistema operativo

para el arranque y funcionamiento de SAP.

5.2.

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 MonitorSupervisar Sistema Usuarios Conectados. 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 .

 USUARIOS CONECTADOS 5.2. MONITORIZACION

61

Figura 5.4: Monitor de conexi on de usuarios por instancia

7. Cantidad de modos internos que el sistema ha debido abrir para gestionar las peticiones del usuario. Estos modos internos no tienen nada que ver con los modos externos o de usuario denominados simplemente modos que se explicaron en el 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. 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 reejado en el log del sistema ver cap tulo 8 .

62

DE PROCESOS Y USUARIOS CAP ITULO 5. MONITORIZACION

Figura 5.5: Lista de modos activos por usuario

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 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.6: 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

 USUARIOS CONECTADOS 5.2. MONITORIZACION

63

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 la SM50 elegir la opci on del men u deplegable Pasar aTerminales. Nos aparecer a un listado con todas las conexiones f sicas que han realizado los usuarios en todo el sistema. Este listado muestra el mandante, usuario, terminal e instancia a la que se ha conectado el usuario. Crear un programa o query sencilla sobre la tabla USR41 que contiene en todo momento los usuarios conectados por cualquier instancia. Hay que tener en cuenta que el resultado se nos restringe al mandante al que estamos conectados. Si el sistema tiene m as de un mandante donde est en denidos 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

66

CAP ITULO 6. PROCESAMIENTO EN FONDO

6.2.

Denici 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 Denici on, y que nos muestra la pantalla de la gura 6.1

Figura 6.1: Pantalla inicial de denici on de job

La denici 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 denici on del job. Primeramente debemos darle un nombre que dena el prop osito que tiene. Este nombre no es u nico, lo que signica 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 denir 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 cas 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 camente 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 denidas 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 denici 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 planicaci 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 especicar que s olo comience cuando la nalizaci 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.

68

CAP ITULO 6. PROCESAMIENTO EN FONDO

Un evento es un suceso se produce autom aticamente en el sistema R/3 o que podemos provocar manualmente. Previamente, el evento debe estar denido en la correspondiente tabla. SAP viene con una serie de eventos predenidos 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 denir 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 chero 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 unicado, 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 denido 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 gura 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 denidos 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 gura 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 denido 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 denido 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 signicado real porque un job que esta previsto no se ejecutar a nunca a menos que lo liberemos o modiquemos la secci on de datos de inicio. Liberado Cuando denimos completamente un job con la transaccion SM36 o liberamos un job que estaba en estado previsto, entonces pasa a

70

CAP ITULO 6. PROCESAMIENTO EN FONDO 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 sucientes 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 nalizara 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 gura 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: Vericar 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. LiberadoPrevisto Para poder deshacer la liberaci on de un job utilizaremos esta opci on. Es muy u til para no tener que borrar y redenir 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. Modicar Siempre y cuando no haya comenzado la ejecuci on del job (mientras este en previsto o liberado) podremos modicar cualquier dato de la denici 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 modicaciones 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 cos. En la gura 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 gura 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: 1 implementa las LUW . 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 modicaciones 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 modicaciones 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 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.

77

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 u 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 conguraci on por defecto) por lo que ser a muy dicil 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 gura 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 gura 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 especica si pertenecen a la parte V1 o V2. Conjuntamente con el departamento de desarrollo y los usuarios nales 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 indenidamente es estatus Run aunque realmente no se est a procesando. La opci on Reiniciar en Regs. Actualizaci on

80

CAP ITULO 7. SERVICIOS DE ACTUALIZACION 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, modicaci 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 modicaci on concurrente de un objeto. Con esto, se asegura la consistencia de los objetos en SAP R/3. Cuando un usuario accede a modicar un objeto, el sistema genera un registro de bloqueo con la informaci on necesaria. Si un segundo usuario intenta modicar 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 modicaci 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 nalizada. Toda modicaci 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 modicar 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 ltrar 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 modicando. 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 modicando. 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

82 bloqueo.

CAP ITULO 7. SERVICIOS DE ACTUALIZACION

Figura 7.8: Informaci on detallada de un bloqueo

En raras ocasiones puede llegar a ocurrir que el bloqueo generado por una modicaci on no se llegue a liberar, lo cual provoca que el resto de usuarios no pueda acceder a modicar 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 chero 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 chero de log local es un chero circular. Cuando el chero llega a su tama no m aximo, el sistema empieza a sobreescribir el chero desde el principio (la informaci on m as antigua). El chero de log local se guarda en cada servidor de aplicaci on en la siguiente ruta: Entorno UNIX /usr/sap/<SID>/<instance number>/log/SLOG00 Entorno Windows NT C:\usr\sap\<SID>\<instance number>\log\Slog00.log donde <SID> es el nombre de la base de datos SAP y <instance number> es el n umero de instancia. Central Cada servidor de aplicaciones copia las entradas del log local a un log 85

86

CAP ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS

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 cheros: un chero activo y un chero antiguo. El chero activo contiene el log actual. Cuando el chero activo llega a su longitud m axima denido en los par ametros del sistema, este borra el chero antiguo de logs, usa el chero activo como chero antiguo y crea un nuevo chero de log. Este cambio en el log no es noticado 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 HerramientasGesti onMonitorLog Sistema . La pantalla de seleccci on de la transacci on SM21 tiene 2 modos: El modo Normal y Experto. El modo normal es el denido 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 TratarModo 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 ltrar 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 especicado.

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 especicada. 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

88

CAP ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS 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 ltro como es la opci on Atributos.

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

8.1. CONCEPTOS DEL LOG DEL SISTEMA

89

la posici on de una entrada espec ca 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 ltrar los mensajes que han sido causados por la actividad llevada a cabo desde un servidor de presentaci on. Clase de desarrollo: Se pueden ltrar 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 o N 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 ltrando 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 chero 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 ltrando con otros valores pero mantiene en el buer el anterior resultado que puede ser accedido de nuevo a trav es de la segunda opci on.

8.1. CONCEPTOS DEL LOG DEL SISTEMA

91

8.1.6.

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 SyslogSeleccionar .

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

92

CAP ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS

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 HerramientasGesti on MonitorAn 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 ltrar por fecha, usuario, m aquina, mandante.

8.2. CONCEPTO DE DUMP

93

Figura 8.6: Pantalla principal de an alisis de dumps

Figura 8.7: B usqueda de dumps antiguos

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 especica 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 echa. 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 n 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 congurado como de suplementaci on, que en general ser a el ingl es, sino se ha denido 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 -------------------------------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.

97

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,

98

CAP ITULO 8. LOG DEL SISTEMA Y ANALISIS DE DUMPS 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............ Database Database Database Database server.......... type............ name............ owner........... "prodsap1" "10.190.20.13" "AIX" "3" "000541934C00" "sa3dbh2r" "ORACLE" "SP1" "SAPR3"

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 ------------------------------Client.............. User................ Language key........ Transaction......... Program............. Screen.............. Screen line......... 111 "116665u" "S" " " "AQ99HA==========CAND1========= " "SAPMSSY0 1000" 6

99

------------------------------------------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 tskhstart at 0x100c2404 DpMain at 0x10016bb4 main at 0x100011fc -----------------------------------------------Lista programas ABAP involucrados ------------------------------------------------

101

-------------------------------------------------------------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 <initial> 1 /%_LISTTABLES |\0\0\00\0\0\0\0\0\0\0\0\0\0\0\0\0\ 2 global stack | 0000 ----------------------------------------ABAP/4 Bloques control CONT ----------------------------------------No existe ninguna informaci on en el dump. ---------------------------------------------Fin an alisis error tiempo ejecuci on ----------------------------------------------

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 chero. 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 gura 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 denida 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 gura 9.2 en la que deniremos 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 deniendo 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 gura 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 congurada 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.

106

DE SPOOL CAP ITULO 9. GESTION

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 gura 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 au 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

107

Figura 9.4: Ventana de di alogo para imprimir un listado

108

DE SPOOL CAP ITULO 9. GESTION 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 gura 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 gura 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 gura 9.7 podemos ver algunos de los que se pueden cambiar. B asicamente son los mismos que denimos inicialmente al crear la orden de spool (ver gura 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

109

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

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

110

DE SPOOL CAP ITULO 9. GESTION

Una de las labores del administrador consiste en asegurarse que las rdenes de spool olvidadas por los usuarios no llenan nuestra base de o 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 exible los datos y las operaciones que se hacen sobre ellos. En la gura 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, modicar, borrar. . . ) F BKPF BUK. Protecci on de la contabilizaci on de documentos por sociedad nanciera. 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 gura 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 nanciera 1000. Perles. Un perl es simplemente la agrupaci on de varias autorizaciones que hayamos creado anteriormente. El perl 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 perl que llamaremos CONTABLE e incluir este perl en los usuarios. Grupos de actividad. Son las agrupaciones de transacciones y actividades que se crean con el generador de perles. Estos grupos de actividad contienen internamente perles (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 perles 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 gura 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, modicar, 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 gura 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 n de su contrato o cesi on a nuestro departamento. Valores jos. En esta pesta na denimos 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 perles. 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 perles tambi en, pero existe la posibilidad de incluir perles 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

115

Figura 10.3: Datos de direccion del maestro de usuarios

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 perles

Debido a la gran complejidad que supone la creaci on manual de perles y autorizaciones, desde la version 3.1G de R/3, existe el generador de perles. 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 perles de usuario. El generador de perles 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 perl 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 gura 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 gura 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 perl o cual es su funci on espec ca.

Figura 10.5: Descripcion del papel

Al pasar a la pesta na men u (ver gura 10.6) vemos unos botones que nos permiten incluir transacciones, informes o direcciones web en el grupo de actividad. Observamos en la gura 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 perl podr a ejecutar la transacci on FB01, pero no hemos determinado a un para que sociedades nancieras, cuentas o deudores podr a hacerlo. En la gura 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 nanciera 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 gura 10.8 conviene jarse 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

119

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

Figura 10.8: Asignacion de un papel a usuarios

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 denici on y contenido de tablas nuevas, programas nuevos, datos de customizing e incluso modicaciones 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. Modicaci on de objetos ya existentes en el sistema destino. 121

122

CAP ITULO 11. SISTEMA DE TRANSPORTE

Cuando se crea o modica un objeto en el sistema de desarrollo, el sistema propone un c odigo u nico para identicar la creaci on o modicaci on de ese objeto, siempre y claro est a que el mandante donde se est e trabajando est e congurado para registrar cualquier modicaci 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 modique, 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 modicar 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 modicados 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 nalidad 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 modicar o crear ya que esto complicar a de manera excesiva nuestra

 11.1. ORDENES DE TRANSPORTE

123

Figura 11.1: Esquema de una orden de transporte

Figura 11.2: Esquema de ordenes de transporte

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 modicar 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 identicaci 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 gura 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 modicaci 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 signica que tienen efecto en todo el sistema. La creaci on de nuevos objetos, o la modicaci on de los que proporciona SAP son grabados, de manera similar al customizing, en tareas asignadas a ordenes de modicaci on transportables. Ordenes de modicaci 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

CAP ITULO 11. SISTEMA DE TRANSPORTE

11.4.

Estados de una orden de transporte y sus tareas

Desde que se crean una orden de transporte y sus correspondientes tareas hasta que son liberadas (fase previa para el transporte de dicha orden a otro sistema), estas pasan por dos estados: Modicable Cuando la orden o tarea es creada para ser asociada a objetos de desarrollo o de customizing, esta aparece con status modicable; 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 modicaciones; 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 Modicable aunque todas sus tareas asociadas est en en estado liberado; ello nos permitir a asignarle nuevas tareas con status modicable 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 modicaci on futura, realiza el export de la orden. El export de la orden consiste en la creaci on de dos cheros a nivel de sistema operativo chero data y chero coles . En estos cheros 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 chero del sistema operativo y la importaci on de dicha informaci on en la base de datos destino. Los dos cheros 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 chero data a crear y mayor el tiempo que llevar a su creaci on, es decir, la exportaci on. La nomenclatura del chero data, siendo la de la orden liberada <SID>K9nnnnn, puede ser: D9nnnnn.<SID> R9nnnnn.<SID> Fichero coles Ubicado en /usr/sap/trans/cofiles; es un chero 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 chero coles, 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 modicaci 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 modicables 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 gura 11.6.

11.5. CUSTOMIZING ORGANIZER Y WORKBENCH ORGANIZER 129

Figura 11.6: Ordenes de transporte

Desde esta pantalla podremos identicar 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 chero 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 modicable. 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 modicable 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 modicable, 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 modicar. 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 gura 11.7. Como campo principal se nos pide que introduzcamos una descripci on para la orden a crear cuya codicaci 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 especicado . 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 modicamos 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).

132

CAP ITULO 11. SISTEMA DE TRANSPORTE En sistemas Windows NT, esta directorio de transporte deber a estar congurado 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 Directorio desde donde se lanza el programa de control del transporte, tp. Directorio donde se almacenan los cheros 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 cheros coles 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 cheros 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 buerpor 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.

/usr/sap/trans/coles

/usr/sap/trans/log

/usr/sap/trans/buer

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 mencionado antes: tp showbuer <SID>

133

Nos muestra el listado de ordenes inclu das en el buer. En lo que sigue, <SID> se reere 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 delfrombuer <orden> <SID>

134

CAP ITULO 11. SISTEMA DE TRANSPORTE

Elimina del listado del directorio buer la referencia a la orden de transporte seleccionada. No borra la orden f sicamente, pero impide que se pueda transportar esa orden. tp addtobuer <orden> <SID> A nade la orden seleccionada al buer, 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 <orden> <SID> Importa al sistema destino la orden seleccionada, y lo hace en el mandante cuyo nombre es el mismo que en el sistema origen. Si el mandante destino de la orden no coincide con el mandante origen de la orden, se deber a obligatoriamente especicar 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 especicado todas las ordenes que hayan sido liberadas y que, por tanto, se encuentran en el buer. Las ordenes son importadas por orden de aparici on en buer, 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 especicada 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 buer, y este comando tiene un orden de transporte preestablecido. tp import <orden> <SID> client=<nnn> u1 La opci on u1 es el modo incondicional de sobreescritura. Habr a que especicarlo 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 especicar 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 coles los cheros 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 buer; si acaba de ser liberada, aparecer a la u ltima del listado. Una vez comprobado que la orden se encuentra en el buer 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 modicaciones 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 denici 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 denici 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 buer .

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 signicaba. 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 precongurados. 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

DE MANDANTES CAP ITULO 12. GESTION

12.1.

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 modicados 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 nal 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 chero 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 modicar, 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 reeren 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 modicaci 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 . Modicaciones 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: Modicaciones sin grabaci on autom atica No pide orden de transporte al modicar 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 modicaciones Al modicar customizing el sistema pide ordenes de transporte. Para mandantes de desarrollo. No se permiten modicaciones No se permite modicar customizing. Permite asignar ordenes de transporte manualmente. Opci on m as usada para mandantes de sistemas productivos. No se permiten transportes Se permite modicar el customizing pero las modicaciones 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 Modicaciones objetos independiente mandante Se puede limitar el alcance de las modicaciones permitidas en el mandante. Las opciones son: Se permite modicar repository y customizing indep.mandante Opci on m as usada para mandantes en sistemas de desarrollo o pruebas donde sepamos que las modicaciones independientes de mandante no afectar an negativamente al funcionamiento del sistema. No modicaci on de objetos customizing independ.de mandante Las modicaciones 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 modicaci on de objetos repository Impide modicar 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 modicar objetos standard de SAP (tablas, programas, etc. . . ) y la posibilidad de modicar 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

144

DE MANDANTES CAP ITULO 12. GESTION 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 condencial y donde se deber an cumplir todos los requerimientos impuestos por las leyes ociales 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 modicados. 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

145

12.2.

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 nalice 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 perl 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 denidos 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 suciente 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 Perles de Copia. Al realizar la copia local se debe elegir un perl de copia, con lo que impl citamente se estar a indicando el tipo de datos a copiar. Podremos crear nuevos perles de copia a partir de los ya existentes. Para visualizar el contenido de cada perl desde la transacci on SCCL acudiremos al men u desplegable a la opci on Perl Visualizar Perl . 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 perl 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 perl de copia, y el n umero de registros de los

12.2. COPIA LOCAL DE MANDANTE

147

Figura 12.4: Detalle de un perl de copia

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 denidas 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 denici 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 deniciones de tablas. Si se crearon tablas nuevas en el mandante origen cuyas deniciones 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 chero 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 cos. 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 perl 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 cos: <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 cheros 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 le system correspondiente en entornos UNIX . Deberemos recordar que la exportaci on de mandante puede llegar a crear cheros de gran tama no, dependiendo de la informaci on asociada al mandante a exportar; por lo que un llenado del le 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 cos 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 cos y pulsaremos ejecutar en di alogo o background.

Cap tulo 13 Mantenimiento de instancias

13.1. Perles del sistema

El sistema SAP R/3 dispone de unos par ametros de conguraci 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 congurar tama no de bueres, 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 perles del sistema

Los par ametros activos se mantienen desde los Perles del Sistema. Estos perles son realmente 3 cheros a nivel de sistema operativo donde se guarda toda la informaci on t ecnica del sistema R/3: 1. Perl de Inicio: El nombre es Start <n umero instancia> <nombre m aquina>. Es un perl 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. Perl por Defecto: El nombre es DEFAULT. Es un perl u nico por sistema R/3 que contiene par ametros globales para todo el sistema. 3. Perl de Instancia: El nombre es <SID> <n umero instancia> <nombre de m aquina> y es un perl u nico por instancia del sistema R/3 con par ametros espec cos de cada instancia. 153

154

CAP ITULO 13. MANTENIMIENTO DE INSTANCIAS

Estos tres perles est an almacenados a nivel de sistema operativo en tres cheros con los nombres especicados anteriormente en el siguiente path de la instancia central: \usr\sap\<SID>\SYS\profile\ donde <SID> es el System Identication, 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 conguraci on: Nombre base de datos SAP (SID): P11 Nombre m aquina de la instancia central: servr001 Identicador instancia central: 00(este valor de identicador para la instancia se establece en tiempo de instalaci on y no se puede cambiar) Nombre m aquina de la instancia de aplicaciones: servr002 Identicador instancia aplicaciones: 10 Los perles del sistema ser an, en este caso, cinco: un u nico perl por defecto y dos perles de inicio y de instancia por cada una de las instancias que componen nuestro sistema: Perl Perl Perl Perl Perl 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 perles 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 Conguraci onActualizar Perles. En esta transacci on existen 3 niveles de gesti on de perles, 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 chero a nivel de sistema operativo, as como fechas de modicaci on y activaci on del perl en cuesti on y autor de dicha modicaci on y activaci on.

13.1. PERFILES DEL SISTEMA

155

Figura 13.1: Pantalla pricipal perles del sistema

Figura 13.2: Datos de gesti on de un perl

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 modicaci on de los par ametros b asicos que componen el perl. Este nivel es especialmente importante en el caso del perl de instancia ya que permite, de una manera muy sencilla y segura, cambiar los par ametros relativos a los bueres y al n umero de colas de trabajo. Ser a este el perl que debamos modicar 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 perl

Actualizaci on ampliada . En este nivel se permite la visualizaci on o modicaci on de todos los par ametros activos en el perl 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 perl

13.1.2.

Importaci on de perles del sistema

La primera vez que se accede a esta herramienta desde que se instala el sistema SAP R/3, los perles no se encuentran disponibles desde SAP; existen s olo a nivel de sistema operativo por lo que ser a necesario importar dichos perles 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 UtilidadesImportar Perl De servidores Activos. Una vez que ejecutemos la importaci on de los perles desde el sistema operativo, los tendremos disponibles en la transacci on RZ10. Pulsando la ayuda de b usqueda correspondiente al campo Perl, el sistema nos mostrar a en un listado los perles importados.

158

CAP ITULO 13. MANTENIMIENTO DE INSTANCIAS

13.1.3.

Visualizaci on todos los par ametros activos

Existen m as par ametros t ecnicos de conguraci on SAP que los que aparecen en los perles 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 perles del sistema no quiere decir que no exista, ya que puede encontrarse activo en el sistema pero no aparecer en ninguno de los tres perles 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 signicar a que el par ametro no est a activo en el sistema. Si deseamos modicar 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 perles 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 perl 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 perl por defecto (otra posibilidad menos recomendada es que se incluya en cada uno de los perles de instancia de las instancias que conforman nuestro sistema SAP R/3). Importante: Cualquier modicaci on sobre cualquiera de los perles de inicio y de instancia bien sea en la modicaci 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 modicaci on sobre el perl 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 modicaci on de cualquiera de sus tres perles a trav es de una ventana de di alogo. La modicaci on de los perles del sistema requiere de un paso m as adem as de la grabaci on en s de las modicaciones; este paso es la Activaci on del perl. El concepto de activaci on o generaci on se encuentra presente en muchas de las aplicaciones de SAP como puede ser el mantenimiento de perles y autorizaciones de usuario, programaci on o mantenimiento de tablas, etc. . . La grabaci on de una modicaci 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 modicaci on real de ese objeto en la base de datos o la modicaci on real a nivel de sistema operativo como es el caso de la activaci on de los perles del sistema.

 13.2. MODOS DE OPERACION

159

13.1.4.

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 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 zcsa/system language login/system client Valor de ejemplo Descripci on US1 DVEBMGS00 00 uisabl4 6 2 1 1 2 1 DES S 800 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

13.2.

Modos de Operaci on

En muchos casos ser a absolutamente necesario cambiar la conguraci 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 denici 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 modicaci on masiva de datos que se pueden realizar sin intervenci on del usuario durante la noche. Esta modicaci 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 modicar los perles 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 conguraci 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 conguraci 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 conguraci on cuando llegue la hora de su activaci on. Ejemplo : Supongamos un sistema SAP formado por una u nica instancia donde est an conguradas 15 colas de trabajo. Podemos denir dos modos de operaci on: diurno y nocturno. En el modo de operaci on diurno daremos prioridad a los procesos de di alogo deniendo m as procesos DIA mientras que en el nocturno daremos prioridad a los procesos en fondo deniendo 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 planicados; 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 Conguraci on Mod Oper + Servidores .

Figura 13.5: Modos de operaci on

En esta pantalla aparecer an los modos de operaci on denidos en nuestro sistema como muestra la gura 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:

162 Host

CAP ITULO 13. MANTENIMIENTO DE INSTANCIAS Nombre del servidor a nivel de sistema operativo . Servidor Nombre de la instancia instalada en el servidor anteriormente mencionado . Perl Instancia Nombre del perl 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 denidos en nuestro sistema.

Si deseamos modicar la conguraci on de alguno de los modos de operaci on denidos 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 gura 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 perles de instancia, con lo que el cambio no se activar a realmente hasta que las instancias modicadas sean reiniciadas de nuevo. Hasta ahora hemos visto c omo crear o modicar 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 denidos a unas horas determinadas en la transacci on SM63 o a trav es del men u desplegable Herramientas CCMS Conguraci on Planicar 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 modicar. En la siguiente pantalla podremos, si hemos elegido modicar, 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 denidos 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, deniendo 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 denici on de grupos de logon, adem as, nos permite un rendimiento optimo de los bueres 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 bueres 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 denir 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 denir en la transacci on SMLG, por el men u desplegable Herramientas CCMS Conguraci on Grupos Acceso En esta pantalla aparecen los grupos de logon ya denidos, sus instancias asociadas y si se encuentran activos o no. Para denir 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 especicado o si el n umero de usuarios conectados a este grupo no supera el m aximo establecido. Una vez que se han denido 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 gura 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 gura 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 denidos 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 denidos 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 denidos 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 denitiva, 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

169

Figura 13.12: Opci on de selecci on servidor en saplogon

Figura 13.13: Opci on propiedades en saplogon

Ap endice A Transacciones m as comunes

DB02 An alisis de tablas e Indices DB14 Mostrar logs actividad SAPDBA PFCG Generador de perles. RZ01 Monitor para previsi on de jobs RZ02 Gr aco 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 perl RZ11 Actualizaci on par ametros de perl 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 perles de autorizaci on SU03 Actualizar autorizaciones SU10 Modicaciones masa Maestros usuario SU12 Modicaciones 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 vericaci on SUIM Llamada arbol report.AUTH (infosist) SUPC Perles 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 cheros .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 Simplication 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.
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 planic o para conseguir tales nes, 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 acas. La informaci on deb a uir 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 cos de cada pa s en los que Autodesk ten a alg un centro o lial. Los tiempos de los procesos de negocio se deb an ser claramente reducidos. Gesti on precisa de inventario. 179

Autodesk, Inc.

180

APENDICE C. CASOS REALES 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 nanciera, controlling, gesti on de materiales, ventas y distribuci on fueron implementados en los centros americanos en s olo 6 meses.

C.2.
Sector

Schweppes, S.A.

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 sosticada 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 ecaz. Toda esta infraestructura, la existencia de sistemas de informaci on distribuidos sin ninguna conexi on entre las aplicaciones y sin una conexi on geogr aca entre las distintas areas de venta y las ocinas 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 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

181

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 nanciera. Los m odulos de ventas y vistribuci on (SD) y planicaci 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 frameen el que reside el sistema de data warehouse, herramienta complementaria a SAP R/3 y con Oracle como base de datos. Asimismo, existe una 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, ocinas 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.
Sector

IBM Espa na

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 cas 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 unicaci on de procesos que permita hacer negocios cross-border, as como una reducci on en el desarrollo

182

APENDICE C. CASOS REALES

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 rmas que se descartaron, entre otros motivos por el hecho de no ser internacionales o tener una estructura de soporte no suciente 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 unicar y simplicar 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 exibilidad 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 nanzas (FI) casi en su totalidad. La divisi on encargada de utilizar el sistema es Fullment dentro de ella b asicamente el departmento de administraci on. La aplicaci on se utiliza para cubrir los siguientes procesos comerciales: 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.
2

 C.3. IBM ESPANA Facturaci on.

183

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 simplicaci on que se ha visto reejada 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 cheros 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 identicaci 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 Ocial 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 - Simplication 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 - Simplication Group http://207.105.30.51/simple/sysadmin/saezindex.htm [8] Authorizations Made Easy Guide 4.0B - Simplication Group http://207.105.30.51/simple/authorization/40_pdf_files/ amez4ball.pdf

189