administracion SAP by Freddy Jesus Estanga

´ 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érez Pérez y Antonio Toledo Carnicero. Esta obra esta licenciada bajos los términos de la licencia Atribución-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ón de sistemas de información tipo ERP en las grandes empresas ha sido masiva. SAP R/3 es el máximo 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ón del personal de la empresa en cada uno de sus aspectos como pueden ser, la funcionalidad, la parametrización, la programación o la administración del sistema. Es en este u ´ltimo aspecto, la administración del sistema, en el que se centra la presente obra.

Audencia Este libro está espec´ıficamente escrito para los alumnos de la asignatura Gestión de Sistemas de Informaci´ on dentro del quinto curso del programa de estudios de Ingenier´ıa en Informática de ESIDE en la Universidad de Deusto. Son a ellos, principalmente, a quién 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écnicos de atención 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én puede servir como introducción a los que quieran iniciarse en la administración de sistemas R/3.

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

4 trabajado como analista y consultor técnico de SAP para varias empresas y formó parte durante 5 a˜ nos del equipo de desarrollo de Finanzas y Control de Gestión en la eléctrica Iberdrola. En la actualidad es el responsable de los sistemas informáticos de la empresa reprográfica 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ón 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ó también como programador de ABAP/4 y administrador de sistemas en la empresa Grupo Antol´ın. Después prestó servicios de administración 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ón de sistemas SAP R/3 de Iberdrola. Ha colaborado en varias ocasiones como profesor en el Master de Consultor´ıa e Implantación de Sistemas de Informaci´ on y la Diplomatura de Especialización 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ándar vs. software a medida 1.2. Visión general de SAP R/3 . . . . . . . 1.2.1. Caracter´ısticas principales . . . . 1.2.2. Módulos . . . . . . . . . . . . . . 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ándar de herramientas 2.6. La barra de aplicaciones . . . . . . 2.7. La pantalla principal . . . . . . . . 2.8. La barra de estado . . . . . . . . . 2.9. Ventana de diálogo . . . . . . . . . 2.10. Ayudas de b´ usqueda . . . . . . . . 2.11. Modos . . . . . . . . . . . . . . . . 2.12. Concepto de transacción . . . . . . 2.13. Opciones técnicas . . . . . . . . . . 2.14. La pantalla status . . . . . . . . . . 3. Arquitectura de un sistema R/3 3.1. Introducción . . . . . . . . . . . 3.2. Servicios de base de datos . . . 3.3. Servicios de aplicación . . . . . 3.4. Servicios de presentación . . . . 5

. . . .

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

. . . .

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

. . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

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

. . . .

. . . . .

13 13 14 14 16 19

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

21 21 21 24 24 25 27 27 28 29 29 30 32 33 34

. . . .

37 37 39 40 43

´INDICE GENERAL

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

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

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

. . . . . . . .

7. Servicios de actualizaci´ on 7.1. Actualización s´ıncrona y as´ıncrona . . . . . 7.2. Procesos de actualización V1 y V2 . . . . . 7.3. Monitorización del estado de la actualización 7.4. Actualizaciones interrumpidas . . . . . . . . 7.5. Entradas de bloqueo . . . . . . . . . . . . .

. . . . . . . .

. . . . del . . . .

8. Log del sistema y an´ alisis de dumps 8.1. Conceptos del log del sistema . . . . . . . . . . 8.1.1. Accediendo al log local del sistema . . . 8.1.2. Accediendo al log local en modo normal 8.1.3. Accediendo al log local en modo experto

. . . . . . . .

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

. . . .

. . . . . . . .

. . . . .

. . . .

. . . . . . . .

. . . . .

. . . .

. . . . . . . .

65 65 66 66 67 68 68 69 70

. . . . .

73 73 75 75 77 80

. . . .

85 85 86 86 88

´INDICE GENERAL

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

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

89 89 91 92 92 94

. . . .

103 . 103 . 103 . 106 . 108

10.Gesti´ on de usuarios y autorizaciones 111 10.1. Modelo de seguridad en R/3 . . . . . . . . . . . . . . . . . . . 111 10.2. Mantenimiento de usuarios . . . . . . . . . . . . . . . . . . . . 113 10.3. Generador de perfiles . . . . . . . . . . . . . . . . . . . . . . . 116 11.Sistema de transporte ´ 11.1. Ordenes de transporte . . . . . . 11.2. Clases de desarrollo . . . . . . . . 11.3. Tipos de ´ordenes de transporte . . 11.4. Estados de una orden de transporte 11.5. Customizing organizer y workbench 11.6. Transporte manual de ´ordenes . . 11.7. Log del transporte . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . y sus tareas organizer . . . . . . . . . . . . . . .

12.Gesti´ on de mandantes 12.1. Creaci´on de un nuevo mandante . . 12.2. Copia local de mandante . . . . . . 12.3. Copia remota de mandante . . . . . 12.4. Transporte de mandante . . . . . . .

. . . .

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

. . . . . . .

121 . 121 . 124 . 124 . 126 . 127 . 131 . 136

. . . .

. . . . . . .

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

13.Mantenimiento de instancias 13.1. Perfiles del sistema . . . . . . . . . . . . . . . . . 13.1.1. Mantenimiento de perfiles del sistema . . . 13.1.2. Importación de perfiles del sistema . . . . 13.1.3. Visualización todos los parámetros activos 13.1.4. Parámetros más importantes de un sistema 13.2. Modos de Operación . . . . . . . . . . . . . . . . 13.2.1. Gestión de modos de operación . . . . . .

. . . .

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

. . . . . . .

139 140 145 148 149

´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

171

B. Recursos Web

177

C. Casos reales 179 C.1. Autodesk, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 C.2. Schweppes, S.A. . . . . . . . . . . . . . . . . . . . . . . . . . . 180 C.3. IBM Espa˜ na . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 D. Glosario

185

Índice de figuras 2.1. Pantalla de entrada a SAP R/3 . . . . . . . 2.2. Barra de t´ıtulo . . . . . . . . . . . . . . . . 2.3. Barra de aplicaciones . . . . . . . . . . . . . 2.4. Pantalla principal . . . . . . . . . . . . . . . 2.5. Barra de estado . . . . . . . . . . . . . . . . 2.6. Ventana de diálogo . . . . . . . . . . . . . . 2.7. Ayuda de b´ usqueda . . . . . . . . . . . . . . 2.8. Listado de valores posibles . . . . . . . . . . 2.9. Icono de acceso a las opciones técnicas . . . 2.10. Menu del icono de acceso a opciones técnicas 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 definici´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ón as´ıncrona . Esquema funcionamiento actualización s´ıncrona . Pantalla principal monitor actualización . . . . . Actualizaciones pendientes . . . . . . . . . . . . . Módulos de actualización . . . . . . . . . . . . . . 9

. . . . .

74 74 76 78 79

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

Pantalla principal log local del sistema . . . . . . . . . Parámetros de selección 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álisis de dumps . . . . . . . . . B´ usqueda de dumps antiguos . . . . . . . . . . . . . .

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

Transacción SPAD. Mantenimiento de dispositivos Datos generales para una impresora local . . . . . Tipo de impresora para una impresora local . . . Ventana de diálogo para imprimir un listado . . . Transacción SP01. Selección de órdenes de spool . Transacción SP01. Listado de órdenes de spool . . Atributos de una orden de spool . . . . . . . . . .

. . . . . . .

87 88 90 90 91 93 93

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

. . . . . . .

104 105 106 107 109 109 110

10.1. Componentes de la seguridad en R/3 . . . . . . . . 10.2. Pantalla inicial de la actualización 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ón de valores a los objetos de autorización . 10.8. Asignacion de un papel a usuarios . . . . . . . . . .

. . . . . . . .

112 114 115 116 117 118 119 119

11.1. Esquema de una orden de transporte . . . . . 11.2. Esquema de ordenes de transporte . . . . . . . 11.3. Clase de desarrollo . . . . . . . . . . . . . . . 11.4. Esquema pasos del transporte . . . . . . . . . 11.5. Pantalla principal Workbench Organizer . . . ´ 11.6. Ordenes de transporte . . . . . . . . . . . . . 11.7. Creación de una orden de transporte . . . . . 11.8. Listado de órdenes 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ón individual de órdenes . . . . . . 11.12.Log del transporte de una orden . . . . . . . .

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

123 123 125 127 128 129 131 133 134 135 137 137

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

´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 perfil de copia . . . . . . . . . . 12.5. Copia remota de un mandante . . . . . . . . . 12.6. Export de mandante . . . . . . . . . . . . . .

. . . . . .

141 142 145 147 148 150

13.1. Pantalla pricipal perfiles del sistema . . . 13.2. Datos de gestión de un perfil . . . . . . . 13.3. Actualización básica de un perfil . . . . . 13.4. Actualización ampliada de un perfil . . . 13.5. Modos de operación . . . . . . . . . . . . 13.6. Distribución de procesos de trabajo . . . 13.7. Pantalla principal asignación horaria . . 13.8. Asignación horaria a modos de operación 13.9. Pantalla principal grupos de logon . . . . 13.10.Pantalla detalles creación grupo logon . . 13.11.Pantalla de saplogon . . . . . . . . . . . 13.12.Opción de selección servidor en saplogon 13.13.Opción propiedades en saplogon . . . . .

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

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

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

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

Software est´ andar vs. software a medida

Tras la continua y masiva introducción de la informática en los sistemas de gestión empresariales durante mas de treinta a˜ nos, nos encontramos a principio de los noventa con un panorama variopinto. Los diversos departamentos de gestión 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ón de interfases para integrar los datos de un departamento con otro está a la orden del d´ıa. Veamos un ejemplo clarificador de esta situación. El director del departamento de TI de una empresa dedicada a la fabricación de grandes piezas industriales, refleja su caótica situación: ”Nuestra planta de 1.500 trabajadores esta operando sobre una amalgama formada por sistemas anticuados y modernos servidores. Estamos operando TCP/IP, IPX y Decnet en nuestra Ethernet y tenemos concentradores de todo tipo. Algunos departamentos tienen clientes ligeros y estan formulando grandes demandas en la red ya que operan procesos en el servidor y estan reenviando datos de un sitio para otro. Los sistemas de contabilidad e inventario que tiene la planta operan en mainframes de arquitectura 370. Un desfasado sistema de planificación de recursos de fabricación (MRP) opera en un VAX de gama alta. Y parte del software de gestión de la fabricación y de transporte opera en un AS/400. Prácticamente 1

Tecnolog´ıas de la informaci´ on

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

todo el código 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ón como esta obliga al departamento de TI a incurrir en grandes costes para poder mantener en pie unos sistemas que ya no son tan efectivos como antes. Hablamos de programas que se dise˜ naron para las necesidades especificas de la empresa hace unos a˜ nos y que con la evolución que ha venido sufriendo la industria y la tecnolog´ıa, se han quedado obsoletos. Además de las deficiencias que cada empresa detecta en sus sistemas de información tenemos que tener en cuenta otros factores generales que afectan a todas ellas. Problemas como el efecto 2000 o la introducción del Euro como moneda u ńica 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ón es la siguiente ¿Vamos rehaciendo y adaptando nuestro software o adquirimos una solución estándar?. Veremos que casi todas la grandes empresas han optado por una solucion estándar. 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ándares de hecho dentro de las grandes corporaciones. A continuación detallaremos algunas de estas ventajas. Exhaustivo El sistema R/3 engloba la práctica totalidad de los procesos de gestión de la empresa. En el siguiente apartado veremos detallados la cantidad de módulos que incluye. Integrado Tal cantidad de modulos no aportar´ıan demasiado valor a˜ nadido a la empresa si no fuera por la integración. Las interrelaciones estrechas

´ GENERAL DE SAP R/3 1.2. VISION

entre modulos de SAP permiten tener disponible en tiempo real y con exactitud los principales indicadores de gestión. Como ejemplo ilustrativo diremos que una entrada de mercanc´ıas en R/3 puede producir una actualización del inventario de almacén, un apunte contable en la contabilidad financiera, un actualizacion del sistema de información del control de costes y un aviso a producción de que hay nueva materia prima en almacén. Abierto Tecnológicamente 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ándares 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ón 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ón con el estándar. Global El sistema R/3 soporta su utilización en varios idiomas, la contabilización de documentos en cualquier moneda y tiene recogidas las particularidades fiscales y de gestión de recursos humanos de un gran n´ umero de pa´ıses. Esta globalidad es el argumento de mayor peso en la decisión de una multinacional a la hora de adquirir SAP. Actualizado Dos de los grandes problemas de los departamentos de TI a finales de los 90 han sido el efecto 2000 y la entrada en vigor del euro. El software SAP R/3 tiene contemplados y solucionados estos problemas. Además, la constante investigación 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ónico. . . . 1

Para referirse a la adecuaci´ on del sistema a la necesidades del cliente se escuchará frecuentemente el termino anglosajón customizing que en castellano se traduce por parametrizaci´ on. La palabra inglesa proviene de customer – cliente – por lo que el significado completo de customizing viene a ser ”modificación de los parámetros del sistema para adecuarlo a las necesidades del cliente”

´ 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ón. A cada uno de los componentes que sirven para gestionar cada una de la áreas de la empresa se les denomina módulos y se les nombra con dos letras correspondientes a las iniciales del nombre en inglés. Los módulos principales (finanzas, log´ıstica y recursos humanos) se componen a su vez de submódulos. Estos son los principales módulos y sus caracter´ısticas. 1. Gesti´ on Financiera FI Financial Accounting. Re´ une todos los datos de la empresa relevantes para la contabilidad financiera. Recibe todas la imputaciones contables del resto de módulos 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érdidas y ganancias) en todo momento. Los submódulos que la componen son los siguientes. Control de Gesti´ on CO Controlling. La contabilidad financiera no siempre puede proporcionar información desde todos los puntos de vista que una gestión eficaz de costes requiere y es, en este punto, donde act´ ua el módulo CO. Partiendo de los datos de FI, la contabilidad anal´ıtica nos muestra los ingresos, gastos e inversiones desde vistas diferentes. Si juntamos esto con el sistema de planificación y previsión de costes obtendremos un sistema de información completo con las comparativas del plan contra el real que nos permiten saber si nos ajustamos al presupuesto y el porqué. Tesoreria TR Treasury. Representa la solución completa para una gestión económico financiera eficaz. Nos permite asegurar la liquidez de la empresa en todo momento y estructurar los activos financieros de la manera más lucrativa posible. Activos Fijos AM Asset Management. Nos permite controlar el ciclo de vida completo del nuestro inmovilizado, desde la inversión inicial en activos fijos en curso, pasando por la contabilización de la manera más conveniente las amortizaciones, la puesta en explotación de dicho inmovilizado y la enajenación del mismo. Existe otro peque˜ no submódulo 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ón de todo el ciclo de vida de los productos de una empresa, desde la

´ GENERAL DE SAP R/3 1.2. VISION

compra y almacenaje de materia prima, pasando por la fabricación del producto hasta su venta y distribución. Es el módulo más grande de todos ellos y el que más componentes tiene. Describimos a continuación los más usados aunque existen otros menos conocidos como la gestión del servicio al cliente, la gestión de proyectos y la gestión de la calidad de productos. Gestión de Materiales MM Materials Management. Optimiza todos los procesos de compra a través 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én podemos reducir los costes de aprovisionamiento y almacenamiento, gracias a la precisión de la gestión de stocks y de almacenes. Este es uno de los puntos donde más claramente poder apreciar el retorno de la inversión porque los costes de almacenaje es una de las principales preocupaciones de las empresas en la actualidad. Un completo sistema de verificación de facturas nos proporciona la integración necesaria con los modulos contables FI, CO y TR para tener la información actualizada en tiempo real. Planificación de la Producci´ on PP Production Planning. Proporciona procesos completos para todos los tipos de fabricación: fabricación repetitiva, fabricación contra pedido, fabricación contra catálogo, fabricación por procesos, fabricación por lotes y en serie, hasta la gestión integrada de cadenas de suministro con funciones MRP y Kanban. La integración con MM puede provocar la solicitud de necesidades automática al lanzar la planificación 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ón y de esto se encarga el módulo de PM. Aplicaciones como la planificación de las revisiones, la programación de órdenes de mantenimiento, las gestión notificaciones de aprobación nos aseguran una rendimiento óptimo de nuestra fábrica. Integrando todo esto con PP (podemos modificar las órdenes de producción en función de la disponibilidad de la cadena de producción), con HR (calendarios laborales, turnos. . . ) y con MM (creando solicitudes de necesidad de repuestos, por ejemplo) tenemos controlada una pieza vital de la empresa.

´ A SAP R/3 CAPÍTULO 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ón de ventas. SD es lo suficientemente flexible como para poder adecuarnos a precios, condiciones de entrega, descuentos, comisiones y ofertas que a veces cambian a diario. Informar adeduadamente a los módulos financieros del estado de nuestras ventas es una labor imprescindible para poder conocer el estado económico y financiero actualizado de la empresa.

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

Nómina PA Payroll Accounting. Mantiene todos los datos de los empleados en unas estructuras denominadas infotipos que nos permiten calcular el pago de la nómina y contabilizarla tanto en FI como CO de manera automática. Existen infotipos para todas las caracter´ısticas de un empleado, como datos personales, salario bruto, datos familiares, turnos, retenes, retenciones fiscales. . . Este submódulo es posiblemente el más espec´ıfico de cada pa´ıs debido a que las leyes que rigen las relaciones laborales difieren mucho de unos pa´ıses a otros. Es por ello que SAP porporciona unos programas diferentes para cada pa´ıs y un servicio de actualización para poder estar al d´ıa con los cambios que se producen en materia de legislación laboral (aparición de nuevas modalidades de contratación, cambios en la normativa fiscal, etc. . . ) Estructura Organizativa PD Personnel Development. Este submódulo se encarga de gestionar la estructura de la empresa organizando la misma en departamentos, áreas, grupos de trabajo, etc. . . Permite la definicición de tareas de puestos de trabajo y la reorganización de los mismos.

´ GENERAL DE SAP R/3 1.2. VISION

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´ıfica de su negocio que no este contemplada en el estándar. También puede darse el caso de que la funcionalidad que ofrece el estándar 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ón ABAP/4 se caracteriza por su total integración en el sistema R/3. No en vano todo el software de aplicación (se calcula que más de treinta millones de l´ıneas de código) 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ón. Es un lenguaje de muy alto nivel, fácil de leer y se aprende rápidamente. Data Dictionary Es el punto de referencia para los programadores ya que permite aislarles del sistema de gestión de base de datos que se utilize por debajo. Desde un misma pantalla se puede crear, modificar y borrar los objetos de bases de datos, entre los que se incluyen tablas, estructuras, vistas, elementos de datos y dominios. Las definiciones de las tablas, por ejemplo, pueden ser referenciadas directamente en los programas permitiéndonos modificar posteriormente las tablas sin tener que cambiar los programas. Tenemos la posibilidad de gestionar otros objetos del data dictionary como las ayudas de b´ usqueda, los objetos de bloqueo o los objetos de autorización. Editor de programas El editor ABAP/4, aparte de proveer de las funciones básicas para la edición de texto, tiene m´ ultiples caracter´ısticas que facilitan la programación enormemente. Nos permite efectuar una verificación de sintaxis y aceptar las sugerencias del dispositivo de correción automática que tiene incluido. También nos permite resaltar las palabras clave y tener una vista en forma de estructura jerárquica que ofrece la posibilidad de ocultar o desglosar bloques sintácticos. De esta forma, el programador obtiene una buena visión de conjunto de la estructura general del programa.

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

Screen Painter Con esta herramienta crearemos rápidamente interfases gráficas de usuario incluyendo una amplia gama de elementos de control, como botones de pulsación, botones de radio, checkboxes, etiquetas, campos de entrada, listas de base de datos. . . Las pantallas que se crean se denominan dynpro 2 y en ellas se incluye la definicion de la pantalla y sus campos y la lógica de proceso de la misma. Esta lógica 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ás alabada por los programadores habituales de este lenguaje. Tiene todas las ventajas de este tipo de ayudas a la programación (creación de breakpoints, watchpoints, ejecución paso a paso, ejecución por bloques. . . ) pero además nos permite hacer todo esto viendo el código fuente del programa, por lo que la localización 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álisis del tiempo de ejecución, 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é 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ón (PC’s) para poder realizar la conexión 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á la pantalla de conexión al sistema R/3 indicada en la figura 2.1. En esta pantalla deberemos introducir el usuario que nos hayan asignado as´ı como su clave de acceso.También podremos elegir el idioma de conexión. SAP R/3 es un software multiling¨ ue que permite presentar al usuario todos los textos que aparezcan en pantalla en el idioma que él elija, siempre que ese idioma haya sido previamente instalado en el sistema. Si el usuario no introduce idioma alguno, se conectará 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á el término más importante dentro SAP R/3. El usuario, además de los datos arriba especificados, deberá indicar a qué mandante se quiere conectar.

2.2.

Concepto de mandante

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

´ 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ás que una unidad organizativa divisoria de la empresa y permite que distintos usuarios estén trabajando en el mismo sistema sin ning´ un tipo de interferencia mutua ya que cada usuario sólo dispondrá de acceso para visualizar y actualizar los datos de aplicación de la empresa que estén asociados al mandante al que están 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ón de la empresa (datos de clientes, proveedores, pedidos, facturas, cuentas contables, etc. . . ) as´ı como la mayor´ıa de los datos de parametrización de la empresa. Se llaman dependientes de mandante porque sólo son accesibles desde el mandante en el que se crearon. Estos tipo de datos son los más habituales en un sistema SAP R/3. Datos independientes de mandante. Se engloban aqu´ı ciertos datos de la parametrización de la empresa que son accesibles desde cualquier mandante creado. Este tipo de datos son los menos numerosos. Cada vez que se va a proceder a la modificación de este tipo de datos, el sistema avisa con un mensaje informativo informándonos de que la modificación afectará a todos los mandantes. Se ha de ser especialmente cuidadoso al modificar la parametrización independiente de mandante. La Visi´ on F´ısica. La base de datos de SAP R/3 está formada por tablas relacionales. Cuando el usuario navega por las pantallas de SAP es

2.2. CONCEPTO DE MANDANTE

el sistema R/3 el que accede a dichas tablas para irle mostrando al usuario la información 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á asignando en ese momento el valor del mandante elegido, con lo que el usuario sólo podrá acceder a visualizar o modificar los datos de cada tabla que tengan como mandante el que ha elegido en tiempo de conexión. Sin embargo, si una tabla es independiente de mandante, ésta 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ón SQL el campo mandante y el valor actual que tenga. Ejemplo: Situaci´ on 1: Los usuarios user1 y user2 están ambos conectados al mandante 015 de un mismo sistema. Mientras el usuario user1 está modificando la factura 1000, el usuario user2 sólo podrá acceder en modo visualización ya que la factura está siendo bloqueada por el usuario user1; sin embargo, cuando el usuario user1 termine de modificarla, user2 podrá ver la modificación realizada por user1, e incluso podrá realizar cualquier modificación posterior. Situaci´ on 2: El usuario user1 está conectado al mandante 015 y el usuario user2 está conectado al mandante 016 del mismo sistema. Ahora los 2 usuarios no pueden acceder a la misma información ya que sus conexiones al sistema están ”lógicamente 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 ésta 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á accediendo a la tabla de facturas, pero en cada caso accede al registro compuesto por el mandante de conexión del usuario y el n´ umero de factura:

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

2.3.

La barra de t´ıtulo

Figura 2.2: Barra de t´ıtulo Con la visualización antigua del sapgui se encuentra en la parte superior de la pantalla y su función principal es mostrarnos la descripción de la transacción o men´ u de ámbito en curso. En la nueva visualización del sapgui se encuentra entre la barra estándar 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ásica para la navegación por las distintas aplicaciones del sistema SAP R/3. En él podremos encontrar todas las funciones necesarias para un llevar a cabo un control total sobre las transacciones y programas. El men´ u desplegable se caracteriza por tener fijas las u ´ltimas dos opciones de la derecha. Estas dos opciones son: Sistema. Opción para crear y borrar modos, desconexión del sistema, ver el status de nuestra sesión entre otras. Ayuda. Acceso a la ayuda online de SAP.

´ 2.5. LA BARRA ESTANDAR DE HERRAMIENTAS

2.5.

La barra est´ andar de herramientas

La barra de herramientas estándar es de particular interés, ya que contiene muchos de los botones necesarios para realizar las acciones más comunes tales como grabar, enter, imprimir, etc. . . Las funciones asignadas a la barra de herramientas estándar son las siguientes. Bot´ on Enter

Se deberá pulsar este botón para chequear los datos introducidos en una pantalla. El botón enter realiza la misma función que pulsar la tecla enter del teclado. Campo de Comandos

Es un prompt de linea de comandos, y en él se pueden introducir comandos tales como códigos de transacciones o men´ us de ámbito. Bot´ on Grabar

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

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

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

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

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

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

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

Se deberá pulsar este botón si deseamos seguir buscando la cadena de caracteres indicada en una b´ usqueda anterior con el botón buscar. El botón de buscar siguiente estará activado u ńicamente en pantallas donde los datos aparezcan en formato de listado y formato de tabla. Botones de Paginaci´ on

2.6. LA BARRA DE APLICACIONES

Los botones de paginación nos permiten colocarnos en las páginas deseadas dentro de los listados que podamos obtener en pantalla. Los botones de paginación estarán activado u ńicamente en pantallas donde los datos aparezcan en formato de listado y formato de tabla. Disponemos de las opciones primera página, página arriba, página abajo yu ´ltima página:

2.6.

La barra de aplicaciones

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

2.7.

La pantalla principal

Figura 2.4: Pantalla principal

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

Es la parte principal de la aplicación y dependiendo de ésta podrá 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ón principal es ´ la de mostrarnos los mensajes de Informaci´ on, Advertencia, Error o Exito que la aplicación en curso nos muestre al navegar por ella. Como funciones adicionales, la barra de estado nos muestra también: 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, éste se comunica con el RDBMS - que debe haber sido previamente instalado - para crear la base de datos que contendrá 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ón 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ás que pulsar la tecla Insert de nuestro teclado. En la visualización antigua del sapgui aparece la hora que tiene configurada el servidor de presentación a nivel de sistema operativo. Sin embargo, en la nueva visualización no aparece la hora del PC. Esta hora no es la hora que tiene configurada el Sistema R/3 en el servidor, sino que es dependiente de la configuración de cada servidor de presentación.

´ 2.9. VENTANA DE DIALOGO

2.9.

Ventana de di´ alogo

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

Figura 2.6: Ventana de di´alogo

2.10.

Ayudas de b´ usqueda

El sistema SAP R/3 dispone de una herramienta espec´ıfica para la determinación 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ón 4.0B de SAP R/3 (hasta esta versión la herramienta era conocida como matchcodes). Junto con este cambio de nombre se produce a su vez una mejora sustancial de la herramienta. Las ayudas de b´ usqueda son muy u ´tiles ya que en la mayor´ıa de los casos en que deberemos introducir un dato en un campo no conoceremos los valores posibles. Se encuentran activas en casi todos los campos de entrada de cualquier pantalla de SAP R/3 y se identifican por aparecer a la derecha del campo de entrada un peque˜ no recuadro con una flecha vertical apuntando hacia abajo como podemos ver en la figura 2.7. Esta flecha podrá estar activa permanentemente o sólo cuando posicionemos el cursor sobre dicho campo. Veamos esto con un ejemplo:

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

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

2.11. MODOS

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

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

´ 2.13. OPCIONES TECNICAS

2.13.

Opciones t´ ecnicas

Las opciones técnicas del SAPGUI se encuentran en el u ´ltimo botón a la derecha de la barra estándar de herramientas y se puede acceder a ellas pulsando el icono de la figura 2.9 que se encuentra en la parte superior derecha de la ventana del sapgui.

Figura 2.9: Icono de acceso a las opciones t´ecnicas

Al pinchar el boton nos aparece el men´ u de la figura 2.10 que tiene las siguientes opciones.

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

Opciones nos permite reconfigurar el aspecto de nuestro SAPGUI estableciendo nuevos colores, fuentes. Esta opción sólo es válida para el modo de visualización 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ón a cualquier editor de texto ( bien sea dentro del Sistema R/3 como fuera de él ).

´ AL SAPGUI CAP´ITULO 2. INTRODUCCION

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

2.14.

La pantalla status

Existe en SAP R/3 una ventana que nos informa sobre la conexión actual que hemos realizado en el sistema, as´ı como sobre los datos técnicos referentes al sistema operativo, el sistema de gestión de base de datos del servidor y la versión de SAP instalada. A esta pantalla accederemos desde el men´ u Sistema→Status, el cual siempre se encuentra disponible desde cualquier punto de navegación de SAP. En ella podemos distinguir varias partes que describimos a continuación: Datos utilizaci´ on En esta parte se presentan los datos relativos a la conexión que el usuario ha realizado sobre SAP como el mandante, nombre de usuario, idioma de conexión, fecha y hora del sistema, as´ı como la fecha y hora de la conexión anterior que realizó ese mismo usuario sobre ese sistema. Se deberá tener en cuenta que la hora aqu´ı presentada no tiene nada que ver con la hora presentada en la barra de estado ya que la que aparece en la ventana status se refiere a la hora actual del servidor y la hora de la barra de estado se refiere a la hora actual del PC, que en general no coincidirán. Datos SAP Este área está destinada a mostrar información técnica sobre SAP R/3 y se compone de varias subpartes. La parte de Datos Repository se refiere a la transacción y programas asociados a dicha

2.14. LA PANTALLA STATUS

Figura 2.11: Status del sistema transacción desde donde se ha ejecutado la ventana Status. De particular importancia es el campo transacción, ya que es uno de los que más se consulta. La parte Datos Sistema SAP nos dice qué versión de R/3 está instalada en el servidor, el código que SAP asigna a nuestra instalación, as´ı como la fecha de vencimiento de la licencia. La parte Release base nos informa de la versión base que tenemos instalada. Además de la versión base podemos tener instalados algunos parches. SAP, periódicamente, env´ıa unos parches que arreglan errores en sus objetos estándar 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áquina, código de página 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ón y capa de presentación. La idea fundamental de la filosof´ıa cliente/servidor es la distribución 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

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ón de los datos empresariales. 2. Capa de aplicación. Servicios de aplicación para el manejo de la lógica de aplicación. 3. Capa de Presentación. Servicios de presentación para la implementación del GUI. La arquitectura multicapa cliente/servidor le confiere al sistema R/3 las siguientes caracter´ısticas: Escalabilidad Permite la adición de nuevos equipos en cualquiera de sus 3 niveles para acomodarse a los requerimientos dinámicos del sistema. Portabilidad El software normalmente continua en vigencia más 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és de distintos tipos de hardware, sistemas operativos y RDBMS. Apertura Todos los datos están almacenados en tablas que son accesibles sin necesidad de instrucciones complejas de recuperación de datos. Parametrizabilidad SAP R/3 es un software estándar que dispone de herramientas espec´ıficas para la adaptación 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ándar a la manera de trabajar de cada empresa. El Sistema R/3 sigue varios estándares reconocidos internacionalmente e interfaces abiertos: TCP/IP RFC

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

3.2. SERVICIOS DE BASE DE DATOS

Debido a su arquitectura abierta no hay pr´acticamente ninguna restricci´on en la portabilidad como podemos comprobar por la figura 3.2 S.O. soportados RDBMS soportados G.U.I. soportados

UNIX, Windows NT, AS/400, OS/390 Informix, Oracle, ADABAS, DB2, SQL Server Windows, OS/2 , OSF/Motif, Macintosh

Figura 3.2: Arquitectura abierta de R/3

3.2.

Servicios de base de datos

Acceso a base de datos relacional Para el acceso y manipulación de datos, R/3 usa exclusivamente comandos del lenguaje SQL. Se dispone de 2 tipos diferentes de SQL: el Open SQL (extensión de lenguaje de programación 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é de cliente consistente en bufferes especiales en cada servidor de aplicación situados en la memoria principal. Reduce el tráfico de red y los accesos a base de datos. La optimización de los bufferes es asegurada por el mecanismo de sobrescritura LRU (Least Recently Used) que consigue mantener en memoria

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

los datos m´as frecuentemente usados. Administraci´ on base de datos SAP SAP ha desarrollado una serie de herramientas para la administraci´on de la base de datos; para el caso de ORACLE como RDBMS son: BRBACKUP

Herramienta para los backups online y offline de los datos de aplicación y control, as´ı como de los logs. BRRESTORE Herramienta para la restauración de los datos de aplicación y control, as´ı como de los logs. BRARCHIVE Herramienta para el archivado de los logs. SAPDBA Herramienta que integra todas las tareas de administración de la base de datos.

3.3.

Servicios de aplicaci´ on

La capa de de aplicación estará, en el caso más general, compuesto de multiples instancias; por lo que estos servicios estarán 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ás de un conjunto de bufferes en memoria compartida Los servicios de la capa de aplicación se pueden clasificar en: Dialogo Actualización Gestión 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 Cuando un usuario está conectado a un sistema R/3 y realiza cualquier petición de información al sistema (por ejemplo visualizar una factura), esta petición es gestionada por el sistema a través de una cola de trabajo o proceso llamado de diálogo. Estos procesos act´ uan como interlocutores entre el usuario final y la base de datos. Servicios de actualizaci´ on El sistema está provisto de unas colas de trabajo especiales llamadas de actualización por donde gestionará las modificaciones de los datos de aplicación en la base de datos. Servicio de gesti´ on de bloqueos Este servicio juega un papel muy importante y, como el anterior, sólo una instancia dentro de un mismo sistema puede proveer este servicio. Este servicio es el encargado de impedir que un objeto en SAP sea modificado por más de un usuario a la vez. Este servicio es absolutamente necesario para la integridad de los datos de aplicación. Se recomienda que estos dos u ´ltimos servicios corran en la misma instancia ya que interact´ uan entre s´ı. Servicios de procesamiento batch El sistema R/3 proporciona unos procesos llamados de batch espec´ıficos para la realización de tareas, especialmente largas, que no requieran la intervención del usuario final. De esta forma se podrán planificar tareas pesadas como la carga o modificación masiva de datos maestros sin que el usuario tenga que estar presente para su ejecución. Servidor de mensajes Dentro de la capa de aplicación hay una instancia entre el resto que provee el servicio de servidor de mensajes; este servicio es necesario para la comunicación de todas las instancias de un sistema R/3, y monitoriza y asigna recursos libres. La instancia donde corre este servicio es llamada instancia central. Servicio de Gateway

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

Cada instancia necesita de este servicio para realizar tareas que se extienden más allá de la instancia local: Servicio de Spool Este servicio es el encargado de gestionar las peticiones de impresión 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álogo, gestión de bloqueos, actualización, fondo y spool son provistos por los procesos de trabajo, los cuales son coordinados por el

´ 3.4. SERVICIOS DE PRESENTACION

dispatcher. El dispatcher act´ ua de interface entre la capa de presentación y la de aplicación ya que todas las peticiones que vienen del nivel de presentación 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án a la base de datos directamente con SQL. SAP R/3 funciona como un grupo de procesos de sistema trabajando en cooperación y en paralelo. En cada servidor de aplicaciones existe un u ńico 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ándares que aseguran uniformidad, integración 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ón sobre el uso de las aplicaciones R/3. Esta ayuda trabaja con referencias de hipertexto permitiendo la navegación. Elementos de control Se dispone de campos de entrada para la introducción de datos, campos de salida para la visualización de los mismos, table control para la visualización de datos en formato de tabla, pushbuttons, casillas de selección y radio buttons. Se implementan barras de desplazamiento cuando la información a visualizar en pantalla supera el tama˜ no de ésta. 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órea. Se permite, además la creación de men´ us propios de usuario. Barras de tareas La barra de tareas contiene los s´ımbolos de los comandos de navegación más usados. Barras de botones Las funciones esenciales para el control de una aplicación pueden ser accedidas a través de las barras de botones. Valores de entrada posibles En casi todos los campos de entrada se dispone de una función que nos permite visualizar los valores limitados para la introducción de valores.

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

4.1.

Consideraciones generales sobre los sistemas R/3

Siguiendo la definición 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ón real. La base de datos de un sistema R/3 requiere aproximadamente unos 15 Gb1 de disco duro y cada servidor de aplicaciones necesitará unos 2 Gb. Un mandante que contenga u ńicamente la parametrización básica ocupa unos 500 Mb, pero si le a˜ nadimos los datos de aplicación que se van creando al entrar en productivo, los requerimientos de almacenamiento puede incrementarse hasta varios gigabytes. Otros factores que influyen en 1

En la version 4.0B

´ 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óricos que se guardan. . . R/3 no provee de ninguna herramienta para separar los datos maestros de los datos transaccionales. No podemos transportar u ńicamente los datos maestros de proveedores sin pasar también los datos de sus pedidos y/o facturas. Del mismo modo, tampoco podemos separar los datos de módulos diferentes, una aplicación 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, órdenes de mantenimiento, etc, que se hayan creado durante las pruebas.

4.2.

Descripci´ on y funciones de cada sistema

Atendiendo u ńicamente a la función que van a cumplir, hay varios tipos de sistemas R/3. Vamos a describir los tres más habituales (desarrollo, integración y producción) aunque dependiendo del tama˜ no y necesidades de la empresa SAP también contempla la posibilidad de tener un sistema de formación 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ón 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ón para hacer pruebas más exhaustivas. Los datos de este sistema suelen ser escasos (´ unicamente los que se van creando como pruebas) y a veces son inconsistentes. Debido al gran n´ umero de personas (muchas veces ajenas a la empresa) que acceden a este sistema debemos controlar, por motivos de seguridad, que nunca tenga datos reales.

4.2.2.

Sistema de integraci´ on

En este sistema se realizan pruebas definitivas del software que incluyen: Pruebas integradas Con ellas nos aseguramos que nuestros desarrollos no interfieren en otros m´odulos del sistema. Tambi´en debemos probar 2

”Go Live”es el t´ermino ingl´es que se utiliza para referirse al momento en que el sistema productivo se abre a los usuarios finales para que comienzen a trabajar.

4.3. MANDANTES

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

4.2.3.

Sistema de producci´ on

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

´ CAP´ITULO 4. ESCENARIOS DE CONFIGURACION

Mandante 000 Es el mandante de referencia. No contiene datos de parametrización empresarial y por lo tanto las creaciones de mandante propios se deben hacer como copias de este para asegurarnos que empezamos la parametrización desde cero. Durante un cambio de versión de R/3 los datos dependientes de mandante se actualizan automáticamente 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 él. Mandante 001 Es el mandante de ejemplo. Inicialmente es idéntico al 000 y salvo que lo cambiemos nosotros, ninguna actualización de R/3 lo va a modificar, al contrario de lo que ocurre con el 000. Siempre lo podemos tener como ejemplo de la instalación inicial aunque SAP no impone ninguna prohibición de cambiarlo o borrarlo. Mandante 066 Mandante del servicio EarlyWatch. Para garantizar la confidencialidad de nuestros datos reales en productivo existe este mandante aislado al que se conecta SAP cuando le pedimos que nos realice un servicio de detección de problemas de rendimiento. Los usuarios de este mandante tiene las autorizaciones m´ınimas para poder ejecutar el informe de rendimiento. Este mandante tampoco debe ser borrado ni modificado nunca.

4.3.2.

Mandantes propios

A partir del mandante de referencia 000 podemos crear tantos mandantes como queramos (siempre que el tama˜ no de nuestra base de datos nos lo permita). En el sistema de desarrollo se suelen crear varios mandantes, en integración alguno menos y en el sistema de producción solo debe existir un mandante propio. A continuación 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ón 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ás o menos mandantes de los indicados pero hay que buscar el equilibrio entre muchos y pocos. Con pocos mandantes podemos tener conflictos durante la parametrización, 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

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

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

´ CAP´ITULO 4. ESCENARIOS DE CONFIGURACION

Mandante 320 Maestro de parametrización. Este mandante se usa u ńicamente como referencia para poder consultar la parametricación 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ón 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ón real del software. Este es el u ńico 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óricos.

4.4.

Comparaci´ on de escenarios

SAP tiene contemplados escenarios de configuración desde un sólo sistema hasta cuatro. El escenario que aconseja en todas sus especificaciones técnicas es el de tres sistemas aunque también es aceptable trabajar con dos (si las necesidades de la empresa no son muy grandes). Trabajar con un sólo sistema R/3 es un caso excepcional como veremos más adelante. Vamos a ver esquemáticamente las ventajas y desventajas de cada una las configuraciones.

4.4.1.

Configuraci´ on con un s´ olo sistema (Producci´ on)

Ventajas Al tener una sola máquina los costes de hardware son m´ınimos. Todo el trabajo del transporte de elementos de desarrollo queda suprimido con lo que la administración del sistema se simplifica en cierto modo. Desventajas Tendremos problemas con las tablas independientes de mandante. Problemas durante la instalación y pruebas de los parches. Tendremos dificultades para crear nuevos desarrollos y tendremos que provocar la indisponibilidad del sistema para realizar las pruebas integradas.

´ DE ESCENARIOS 4.4. COMPARACION

El rendimiento de nuestra u ńica máquina será malo ya que tendremos todos los mandantes en la misma base de datos con el aumento de tama˜ no de las tablas que ello implica. Conclusi´ on SAP desaconseja totalmente esta configuración. 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ásico les sirve para empezar a trabajar. La realidad demuestra más tarde que hacer esto significa infrautilizar el potencial de adaptabilidad y crecimiento que tiene SAP y en poco tiempo instalan un segundo sistema que les permite hacer cosas que antes no pod´ıan. La reducción inicial de costes en hardware también resulta enga˜ nosa porque en el presupuesto de un proyecto de implantación 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ón de que es ´ importante reducirlo al m´ınimo. Unicamente se aconseja esta configuración para centros de formación o demostración del producto.

4.4.2.

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

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

´ CAP´ITULO 4. ESCENARIOS DE CONFIGURACION

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

4.4.3.

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

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

´ DE ESCENARIOS 4.4. COMPARACION

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

Cap´ıtulo 5 Monitorizaci´ on de procesos y usuarios Una de las tareas básicas de administración de un sistema SAP R/3 consiste en la monitorización de los procesos activos en las instancias que conforman el sistema – ya sea en el entorno de desarrollo, integración o producción -, as´ı como qué usuarios han ejecutado tales procesos. Será labor del administrador el evitar que se ejecuten procesos demasiado pesados que provoquen una ralentización global del sistema, manteniendo un contacto estrecho con el departamento de desarrollo y con los usuarios finales para identificar tales procesos para que sean ejecutados en modo batch durante el procesamiento nocturno.

5.1.

Monitorizaci´ on de procesos activos

El sistema SAP R/3 dispone de un monitor de procesos activos por el cual podemos ver qué usuario ha lanzado qué proceso. Además, este monitor nos informa de qué procesos han sido lanzados en diálogo y qué procesos corren en modo batch. Este monitor puede ser accedido directamente por la transacción SM50 o alternativamente por el men´ u desplegable Herramientas→Gestión→ Monitor→Supervisar Sistema→Resumen Procesos. En la pantalla de la figura 5.1 podemos ver qué usuario está realizando peticiones al sistema, as´ı como el tipo de proceso de trabajo que está gestionando tales peticiones. Explicaremos la información más importante que nos proporciona el monitor. En la columna ID tenemos un identificador secuencial para cada uno de los procesos de trabajo y la columna Tipo nos dice la naturaleza del proceso de trabajo: 55

´ 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álogo batch de actualización V1 de actualización V2 de Enqueue de spool

La columna IDP es el identificador del proceso a nivel de sistema operativo. Cada uno de los procesos en SAP es realmente un proceso activo a nivel de sistema operativo. Este c´odigo u ´nico para cada proceso de trabajo sirve para identificarlos. La columna Status nos indica el status de cada uno de los procesos de trabajo. El status puede tomar cada uno de estos valores: En ejec.

Proceso de trabajo que está 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ón de usuario y cuya actividad ha sido cancelada automáticamente por el sistema o por el administrador del mismo. Los procesos con tales status no pueden volver a gestionar ninguna petición de usuario hasta que el administrador los vuelva a activar.

´ DE PROCESOS ACTIVOS 5.1. MONITORIZACION

La columna Inicio nos indica si el proceso de trabajo se reinicia cuando sufre un error para poder seguir gestionando futuras peticiones de usuario o si por el contrario, cuando una de las peticiones sufra un error el proceso se quede en status finalizado con lo cual no se reactivará automáticamente. El valor por defecto es ”S´ı”, y es el valor que deberemos dejar para que los procesos estén siempre activos aunque sufran alg´ un error en su ejecución. Errores t´ıpicos en la ejecución de peticiones de usuario son la terminación manual de alg´ un modo por parte del usuario. Para cambiar este valor de S´ı a No o viceversa deberemos acudir a la opción del men´ u desplegable Proceso→Reanudar trás error. La columna Error nos indica el n´ umero de errores que un proceso de trabajo ha sufrido desde que se arrancó el sistema por u ´ltima vez. La columna Sem´ aforo nos indica el n´ umero de semáforo asociado a cada proceso. Para ciertos tipos de actividades como pueda ser la escritura en un fichero de log a nivel de sistema operativo, el sistema asigna unos códigos a cada proceso de trabajo. El semáforo para escritura en fichero del sistema operativo es ”22”. La columna CPU es el tiempo de CPU que está consumiendo actualmente el proceso de trabajo en formato minutos:segundos. Esta información por defecto no está activa, ya que su propia visualización consume recursos del sistema. Para activarlo deberemos acudir a la barra de aplicaciones y pulsar el botón CPU. La columna Hora nos indica el tiempo en segundos que ese proceso está activo. La columna Report nos indica el programa que internamente está ejecutando el sistema para gestionar la petición de usuario. Todas las pantallas de SAP tienen por detrás un programa en código fuente que es compilado la primera vez que es llamado; las siguientes veces el programa ya se encuentra en el buffer, por lo que el sistema no lo volverá a compilar hasta que lo pierda del buffer y sea nuevamente llamado. La columna Mandante nos indica el mandante al que se ha conectado el usuario que está ejecutando ese proceso. La columna Usuario nos indica el usuario que ha realizado la petición al sistema asociada a ese proceso de trabajo. La columna Acci´ on indica el tipo de acción que es llevada a cabo sobre la base de datos para gestionar la petición de ese usuario. Acciones t´ıpicas pueden ser: Lectura secuencial, lectura directa, insert, update, delete. Para más información sobre las acciones que ese proceso está realizando posicionaremos el cursor sobre el proceso deseado y a continuación

´ DE PROCESOS Y USUARIOS CAP´ITULO 5. MONITORIZACION

pulsaremos el botón Detalle de la barra de aplicaciones. La barra de aplicaciones nos permite también refrescar el contenido de la pantalla. Deberemos tener en cuenta que el monitor de esta pantalla se activará exclusivamente cuando pulsemos el botón refrescar, por lo que si deseamos tener en pantalla y en todo momento información actualizada sobre los procesos actualmente en curso deberemos pulsar continuamente el botón de refresco. Otra opción 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ón. Esta opción se deberá usar con cuidado y siempre con el consentimiento del usuario ya que podemos provocar pérdida de datos si cancelamos un modo que esté 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ón 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ón en tiempo de ejecución. Los procesos actualmente activos en la instancia en la que estamos conectados se pueden cancelar manualmente por el administrador del sistema con la opción del men´ u desplegable Proceso→Cancelar con core y Proceso→ Cancelar sin core. Ambas opciones cancelan el proceso a nivel de sistema operativo asociado al proceso de SAP con la salvedad que la opción con core genera un fichero llamado core donde queda registrada la razón de la cancelación del proceso. Como este fichero no es editable, elegiremos la opción sin core para no crear en los discos duros información que no vayamos a usar. La cancelación manual de un proceso debe ser realizada con extremo cuidado y siempre deberemos asegurarnos que dicha cancelación no provoque ning´ un problema de inconsistencia en los datos de SAP. Es muy importante tener en cuenta que la información visualizada en la transacción SM50 se limita exclusivamente a la instancia a la que estemos conectados. Si nuestro sistema R/3 está 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á montado la instancia aparece en todo momento en la barra de estado – o acudir directamente a la transacción SM51 (Herramientas→ Gestión→ Monitor→Supervisar Sistema→Servidor ). En la transacción SM51 visualizamos las instancias que están activas y que componen el sistema SAP. Desde esta transacción podremos saber si un sistema SAP es distribu´ıdo o si por el contrario está formado por una u ńica 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á instalada la

´ DE PROCESOS ACTIVOS 5.1. MONITORIZACION

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án dados de alta en esa instancia. En la barra de aplicaciones de esa pantalla tenemos la opción de refresco para actualizar la información. También tenemos la opción Procesos que nos lleva directamente a la transacción SM50 de cada una de las instancias sin más que posicionar el cursor sobre la instancia deseada y pulsar el botón descrito. Accedemos a la misma transacción si hacemos doble click sobre cada una de las instancias. La opción Usuarios nos muestra un listado con los usuarios conectados a la instancia que hayamos elegido. Esta opción la veremos más a fondo en la siguiente sección. La opción Log del sistema nos lleva a la transacción SM21 que está descrita en el cap´ıtulo 8. La opción Colector SO nos muestra información técnica acerca del sistema operativo tal como el n´ umero de procesadores, el porcentaje de utilización CPU, la cantidad de memoria disponible y libre, e información sobre la paginación. Esta opción se encuentra disponible en el men´ u desplegable Pasar a→ Collector SO. La opción Login remoto nos abre un modo sobre la instancia previamente seleccionada. El modo nuevo nos accede al men´ u inicial de conexión a SAP. La opción Info Release nos muestra información sobre la versión del kernel de SAP instalado en la instancia que hayamos elegido. El kernel de SAP está formado por ficheros ejecutables compilados en lenguaje C necesarios

´ 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ásica de administración que se complementa con la monitorización de procesos activos es la monitorización 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ón es mostrada en la transacción SM04 Herramientas→ Gestión→ Monitor→Supervisar Sistema→ Usuarios Conectados. La pantalla de usuarios conectados nos da la siguiente información: 1. Mandante de conexión . 2. Nombre de usuario en SAP . 3. Nombre del servidor de presentación desde donde se ha realizado la conexión. 4. Código de transacción perteneciente al modo actualmente activo . 5. Hora a la que se ejecutó por u ´ltima vez alg´ un proceso desde el modo activo asociado a la conexión f´ısica que estamos visualizando. 6. Cantidad de modos abiertos por el usuario .

´ USUARIOS CONECTADOS 5.2. MONITORIZACION

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ón f´ısica al sistema por usuario. Este monitor tiene además 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ón Modos, o alternativamente, haciendo doble click sobre un usuario, el sistema nos muestra una ventana de diálogo con un listado de los modos abiertos por usuario y conexión f´ısica. Esta ventana nos muestra en orden de apertura los modos abiertos por el usuario y conexión f´ısica elegidos, as´ı como la hora a la que se ha realizado la u ´ltima petición de información por tales modos. También tenemos la opción de borrar el modo que queramos. Con esta u ´ltima opción estaremos cerrando remotamente al usuario la pantalla asociada a ese modo. Esta opción habrá que usarla siempre con el consentimiento del usuario y con extremo cuidado. Tal acción de borrado manual de modo queda reflejado en el log del sistema – ver cap´ıtulo 8 –.

´ DE PROCESOS Y USUARIOS CAP´ITULO 5. MONITORIZACION

Figura 5.5: Lista de modos activos por usuario

Otra opción de la barra de aplicaciones es la de refresco de pantalla. Esta opción es muy u ´til ya que el sistema sólo nos estará mostrando la información actualizada cada vez que pulsemos la función de refresco. También podremos ordenar el listado por la columna deseada tanto en orden ascendente como descendente. Como una tercera opción de la barra de aplicaciones el sistema, si pulsamos el botón Info Usuario, nos muestra en una ventana de diálogo el nombre, apellido, departamento y extensión telefónica asociados al usuario elegido. Estos datos aparecerán siempre y cuando se hayan introducido en el maestro de usuarios cuando se creó el usuario.

Figura 5.6: Informaci´on detalllada de usuario

Será 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ásicos como el nombre, departamento, teléfono de contacto para que la gestión y monitorización de

´ USUARIOS CONECTADOS 5.2. MONITORIZACION

tales usuarios resulte más sencilla. La limitación 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 ńica instancia, este listado nos mostrará 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ón f´ısica por cada instancia de las que se componga nuestro sistema SAP e iniciar desde cada conexión la transacción SM04. En un u ńico modo acudir a la transacción SM51 y desde ah´ı y posicionándonos en cada una de las instancias activas pulsaremos el botón Usuario de la barra de aplicaciones. De esta manera tendremos un listado de usuarios por cada instancia. Desde la SM50 elegir la opción del men´ u deplegable Pasar a→Terminales. Nos aparecerá 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ás de un mandante donde estén definidos los usuarios, el listado no será completo.

Cap´ıtulo 6 Procesamiento en fondo 6.1.

Conceptos de procesamiento en fondo

Además de la opción de ejecutar programas y transacciones online, SAP nos da la posibilidad de ejecutar procesos en fondo.Podemos encontrarnos con otros términos para referirse al mismo concepto como procesamiento batch o procesamiento en segundo plano. Simplemente consiste en la ejecución de un proceso sin interacción 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ón 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ás de dos segundos entre dos acciones del usuario sobre el programa. Parece poco probable que un usuario este esperando más 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ás 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ás 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á hacer cuando los procesos no sean cr´ıticos para la obtención de datos en tiempo real; es la dirección de la empresa la que debe decidir, por ejemplo, si sus pedidos de compra deben emitirse online o por el contrario pueden esperar todos a la noche. 65

CAP´ITULO 6. PROCESAMIENTO EN FONDO

6.2.

Definici´ on de jobs

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

Figura 6.1: Pantalla inicial de definici´on de job

La definición de un job tiene tres áreas principales: Información general Hora de inicio o evento de ejecución Pasos

6.2.1.

Informaci´ on general

La información general conforma la base de la definición del job. Primeramente debemos darle un nombre que defina el propósito que tiene. Este nombre no es u ńico, lo que significa que podemos crear varios jobs que se llamen actualizar estad´ ısticas enero. Esto se produce porque SAP asigna un n´ umero interno a cada job con el que diferencia a unos de otros pero para nosotros esa clave es desconocida y sólo podremos referirnos al job por su nombre. 1

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

´ DE JOBS 6.2. DEFINICION

Otro datos de información general es la clase de job que indica a SAP la prioridad de ejecución de los procesos que le mandamos y en función de ello asigna los recursos adecuadamente. La clases posibles son: A La más alta prioridad. Se utiliza para procesos que son cr´ıticos para el funcionamiento del sistema. B Prioridad media. Para procesos periódicos que aseguran el mantenimiento del sistema. C Prioridad normal. Es la clase normal que se asigna a los jobs de usuario. El administrador del sistema puede decidir reservar colas de BTC espec´ıficas para los jobs de clase A de manera que nunca tenga que esperar un proceso de este tipo a que haya recursos libres para su ejecución. Por u ´ltimo, tenemos la posibilidad de determinar espec´ıficamente el servidor de aplicaciones que dara curso a nuestra petición de proceso de fondo. Si no indicamos ninguna instancia por la que deba ejecutarse entonces el sistema elegira la primera disponible.

6.2.2.

Hora de inicio o evento

Una vez definidas la caracter´ısticas generales del job tenemos que indicar cuándo debe ejecutarse. Esta indicación puede hacerse de diversas formas: Ejecución inmediata. Como su propio nombre indica nos permite iniciar el job en el momento de acabar su definición. Ejecución por fecha/hora. Deberemos indicarle un d´ıa y una hora en la que queramos que comience el job. Además podemos marcar el job como periódico, es decir, que se repetirá su ejecución cada cierto periodo de tiempo (cada d´ıa, cada 35 minutos. . . ). Esta opción es muy u ´til para la planificación de jobs de mantenimiento o de recolección de estad´ısticas, de hecho, al instalar SAP ya existen una serie de jobs de estas caracter´ısticas. Por job. Con esta indicación de comienzo podemos encadenar unos jobs con otros, es decir, indicaremos al job B que empiece a ejecutarse cuando acabe el job A. Tambien podemos especificar que sólo comience cuando la finalización del job A sea correcta, en caso de que el job A haya sido cancelado en mitad de su ejecución el job B no se ejecutará. Por evento. El job comenzará cuando se produzca en el sistema el evento que le indiquemos.

CAP´ITULO 6. PROCESAMIENTO EN FONDO

Un evento es un suceso se produce automáticamente en el sistema R/3 o que podemos provocar manualmente. Previamente, el evento debe estar definido en la correspondiente tabla. SAP viene con una serie de eventos predefinidos como pueden ser, el arranque o parada de las instancias, el cambio de modo de operación de nocturno a diurno, etc. El administrador o los desarrolladores pueden crear otros eventos a conveniencia. Estos pueden dispararse desde programas en ejecución o podemos lanzarlos manualmente a través del men´ u Herramientas→ CCMS→ Jobs→ Lanzar evento.

6.2.3.

Pasos

Tras definir cómo y cuándo queremos que se procese el job, por u ´ltimo, vamos a decirle qué 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ándar o creado por nosotros al que le indicaremos una variante que contenga los parámetros de selección de ese programa. Un comando externo que se ejecutará 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ásico es la ordenación de un fichero que ha creado un programa en un paso previo y que lo necesita otro programa de un paso posterior. Un programa externo que reside en otro sistema distinto a R/3. Se utiliza cuando tenemos otros sistemas de gestión distintos a SAP y necesitamos tener interfases entre ellos. Los pasos de un job constituyen un proceso unificado, esto implica que si el primero de un job de tres pasos sufre un cancelación, ninguno de los otros dos pasos restantes se procesará. Es como si crearamos tres jobs encadenados con dependencia de status con un paso cada uno.

6.3.

An´ alisis de jobs

Una vez definido completamente el job podemos analizar y monitorizar su situación a través de la transacción SM37 o por el men´ u Herramientas→ CCMS→ Jobs→ Actualización que nos muestra la pantalla de la figura 6.2.

´ 6.3. ANALISIS DE JOBS

Figura 6.2: Pantalla inicial de selecci´on de jobs

Inicialmente tendremos que introducir los criterios de selección de los jobs que queremos analizar porque pueden existir cientos de jobs definidos en un momento dado y nosotros estaremos interesados en unos pocos. La selección se hace principalmente por nombre del job, usuario creador del job, fecha y hora de comienzo y estado actual en el que se encuentra. Una vez introducidos los datos y tras pulsar enter veremos la pantalla de la figura 6.3. En ella vemos un listado de los jobs con diversos datos sobre él. La información que más nos interesa es el estado en el que se encuentra, en la siguiente sección hablamos de los diferentes estados de un job.

6.3.1.

Estados de un job

Una vez definido un job lo que nos interesa conocer en todo momento su estado. Los posibles estados en los que se puede encontrar un job son los siguientes: Previsto Es el estado inicial en el que se encuentra cuando hemos definido los datos generales y los pasos del job pero no hemos dicho nada acerca de cuando debe ejecutarse. La elección del nombre no es muy acorde a su significado real porque un job que esta previsto no se ejecutará nunca a menos que lo liberemos o modifiquemos la sección de datos de inicio. Liberado Cuando definimos completamente un job con la transaccion SM36 o liberamos un job que estaba en estado previsto, entonces pasa a

CAP´ITULO 6. PROCESAMIENTO EN FONDO

liberado. En este estado permanecerá hasta que se cumpla la condición 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á esperando a que haya recursos libres en el sistema para ejecutarse. Normalmente no veremos jobs en este estado a menos que tengamos el sistema tan cargado que no haya suficientes colas de batch para atender a todos los jobs que están en estado listo. Activo El job se está procesando. Podemos ver el log desde este momento y ver lo que está haciendo. Finalizado El job completó su ejecución correctamente. Cancelado Alg´ un problema hizo que el job finalizara de manera incorrecta. Normalmente se producen cancelación 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ón.

6.3.2.

Operaciones sobre jobs

El listado de la figura 6.3 es en realidad un completo centro de control de los procesos en fondo. Si pulsamos en el men´ u Job veremos todas las operaciones posibles que podemos hacer para alterar el estado o composici´on de un job.

Figura 6.3: Resumen de jobs seleccionados

´ 6.3. ANALISIS DE JOBS

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

CAP´ITULO 6. PROCESAMIENTO EN FONDO

Capturar job activo Para comprobar en que punto va la ejecución del proceso que hemos lanzado podemos capturar un job que este activo. Al pulsar este opción 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ólo tiene hacer esto sentido si conocemos y entendemos el código fuente del programa que se procesa. Además hay que ser cauteloso con está opción ya que hay determinadas fases de un programa ABAP en las que el hecho de activarse el debugger provoca una cancelación 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ás interesante es comprobar en que servidor de aplicaciones se está procesando y en n´ umero de cola BTC para poder monitorizar su estado y/o rendimiento con la transacción SM51.

Cap´ıtulo 7 Servicios de actualizaci´ on El servicio de actualización en SAP R/3 es especialmente importante ya que es el encargado de gestionar las modificaciones solicitadas por los usuarios en las base de datos. Dichas actualizaciones se pueden generar a través de procesos de trabajo tipo diálogo, batch o update.

7.1.

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

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

´ CAP´ITULO 7. SERVICIOS DE ACTUALIZACION

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

peticiones del usuario, por lo que el rendimiento será peor que en el caso de la actualización as´ıncrona. En la figura 7.2 se muestra en forma esquemática cómo 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ón 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

de forma s´ıncrona o as´ıncrona, ya que esto depende de la programación de la aplicación en curso. Si se trata de actualizaciones dentro de alguna aplicación hecha a medida será tarea del analista de la aplicación el decidir qué tipo de actualización realizar. En lo que sigue nos ce˜ niremos a la actualización as´ıncrona, que a la postre es la que juega un papel más importante en un sistema SAP R/3.

7.2.

Procesos de actualizaci´ on V1 y V2

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

Logical units of work o unidades l´ ogicas de trabajo

´ CAP´ITULO 7. SERVICIOS DE ACTUALIZACION

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

Figura 7.3: Pantalla principal monitor actualizaci´on

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

7.4. ACTUALIZACIONES INTERRUMPIDAS

Mandante

Por defecto aparece el mandante al que nos hemos conectado. Usuario Por defecto aparece el código de usuario con que nos hemos conectado al sistema. Status Podremos elegir las actualizaciones que se han cancelado, las que todav´ıa no se han ejecutado, las que tienen la parte V1 ejecutada, las que tienen la parte V2 ejecutada o todas las actualizaciones con los 3 status anteriores. Fecha y hora Podremos elegir una fecha y hora m´ınima a partir de la cual mostrar los datos. Ctdad. Reg. Podremos elegir la cantidad de actualizaciones a visualizar . Servidor Podremos elegir las actualizaciones que se han realizado desde un servidor de aplicaciones determinado. Se dispone, desde esta transacción, de la posibilidad de activar como de desactivar la actualización del sistema. El administrador puede, en caso necesario, desactivar la actualización para evitar una situación cr´ıtica si se ha detectado alg´ un problema grave en la base de datos. Esta opción se encuentra en la transacción SM13, en el men´ u desplegable Regs. Actualización → Actualización → Desactivar (existe a este nivel también la opción 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álogo 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ón o por la cancelación abrupta del proceso de actualización desde el servidor de presentación debido a una ca´ıda del flu´ıdo eléctrico o a una interrupción deliberada del sistema por parte del usuario. Las actualizaciones interrumpidas por este tipo de problemas las deberá supervisar el equipo de desarrollo de la aplicación en cuestión,

´ CAPÍTULO 7. SERVICIOS DE ACTUALIZACION y a la postre deberán ser ellos quienes decidan qué hacer con estas actualizaciones. Un registro de actualización puede tener uno de los siguientes 6 estados:

1. Init. El registro no ha sido procesado todav´ıa. 2. Auto. El registro será automáticamente actualizado cuando la actualización del sistema se active. 3. Run. El registro de actualización está siendo procesado . 4. V1. La parte V1 ha sido completada. 5. V2. La parte V2 ha sido completada. Cuando esta parte se completa el registro desaparece (es la configuración por defecto) por lo que será muy dificil visualizar un registro en este status. 6. Err. Un error causó la interrupción de la actualización del registro. Para visualizar los registros de actualización interrumpidas acudiremos a la transacción SM13 y elegiremos el status C ¸ ancelado” en la pantalla de selección. A continuación pulsamos ejecutar y el sistema nos mostrará en un listado las actualizaciones interrumpidas como el de la figura 7.4

Figura 7.4: Actualizaciones pendientes

En este listado nos aparece el mandante y usuario que han lanzado el registro de actualización, as´ı como la fecha y hora y transacción desde dónde se ha realizado la actualización. Como u ´ltimo campo tenemos el estado actual del registro de actualización.

7.4. ACTUALIZACIONES INTERRUMPIDAS

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

Figura 7.5: M´odulos de actualizaci´on

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

´ CAP´ITULO 7. SERVICIOS DE ACTUALIZACION

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

7.5.

Entradas de bloqueo

SAP R/3 dispone de un sistema de gestión de bloqueos de objetos para evitar la modificación concurrente de un objeto. Con esto, se asegura la consistencia de los objetos en SAP R/3. Cuando un usuario accede a modificar un objeto, el sistema genera un registro de bloqueo con la información necesaria. Si un segundo usuario intenta modificar ese mismo objeto mientras el 1er usuario lo tiene bloqueado, el sistema le muestra al segundo usuario un mensaje de error indicándole que un usuario ya está tratando el objeto solicitado. Los bloqueos se establecen al iniciar las transacciones de modificación y no son liberados hasta que el usuario pulsa ”Grabar”, la información es actualizada en la base de datos y la transacción es finalizada. Toda modificación de un objeto desde cualquier aplicación estándar dentro de SAP R/3 genera entradas de bloqueo. Será tarea del departamento de desarrollo asegurar que las nuevas aplicaciones hechas a medida dentro de SAP R/3 generen tales bloqueos cuando desde estas nuevas aplicaciones se acceda a modificar alg´ un objeto. La transacción 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ón → Monitor → Entradas de bloqueo. En esta pantalla disponemos de unos parámetros de selección para filtrar los bloqueos actualmente activos. Los parámetros son tabla, argumento de bloqueo, mandante y usuario. En general no conoceremos el argumento de bloqueo, ya que esa información depende del objeto que se esté modificando. Es más normal conocer la tabla o usuario que está produciendo un bloqueo.

7.5. ENTRADAS DE BLOQUEO

Figura 7.6: Pantalla principal entradas de bloqueo

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

Figura 7.7: Listado de bloqueos activos en el sistema

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

´ CAP´ITULO 7. SERVICIOS DE ACTUALIZACION

82 bloqueo.

Figura 7.8: Informaci´on detallada de un bloqueo

En raras ocasiones puede llegar a ocurrir que el bloqueo generado por una modificación no se llegue a liberar, lo cual provoca que el resto de usuarios no pueda acceder a modificar esos objetos debido al bloqueo. Existen dos causas principales de bloqueos no liberados: Actualizaciones interrumpidas Cuando un registro de actualización queda interrumpido, su entrada de bloqueo correspondiente no es liberada hasta que el registro de actualización en cuestión sea procesado correctamente o borrado. Estas entradas de bloqueo no se deberán borrar bajo ning´ un concepto ya que se podr´ıan causar inconsistencias en la base de datos. Estas

7.5. ENTRADAS DE BLOQUEO

entradas de bloqueo se liberarán automáticamente cuando el registro de actualización 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án 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ón interrumpida, podremos borrar la entrada desde el listado de la transacción 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ás que un fichero a nivel de sistema operativo. Si el sistema R/3 se ejecuta en hosts UNIX, existen dos tipos de log del sistema: Local Cada servidor de aplicaciones de R/3 dispone de un log local que contiene los mensajes que ha generado ese servidor. Este fichero de log local es un fichero circular. Cuando el fichero llega a su tama˜ no máximo, el sistema empieza a sobreescribir el fichero desde el principio (la información más antigua). El fichero de log local se guarda en cada servidor de aplicación 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

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

central. Esta opción no se encuentra en servidores Windows NT ni AS/400, sólo existen logs locales (uno por servidor de aplicación). El log central se guarda en un servidor de aplicaciones seleccionado, el resto de servidores de aplicación env´ıan sus mensajes locales a este servidor. El log central es escrito en 2 ficheros: un fichero activo y un fichero antiguo. El fichero activo contiene el log actual. Cuando el fichero activo llega a su longitud máxima definido en los parámetros del sistema, éste borra el fichero antiguo de logs, usa el fichero activo como fichero antiguo y crea un nuevo fichero de log. Este cambio en el log no es notificado al usuario. Mientras que el log local se mantiene siempre actualizado, el log central puede sufrir retardos desde que se escribe un mensaje en el log local hasta que ese mensaje es enviado al log central. Fallos de comunicaciones entre los distintos servidores pueden resultar en retardos grandes en la escritura del log central o incluso en pérdida de estos mensajes.

8.1.1.

Accediendo al log local del sistema

Al log del Sistema se accede directamente por la transacción SM21 o por el men´ u general Herramientas→Gestión→Monitor→Log Sistema . La pantalla de seleccción de la transacción SM21 tiene 2 modos: El modo Normal y Experto. El modo normal es el definido por defecto, y al que se entra directamente cuando se ejecuta la transacción SM21. Para cambiar a modo experto, deberemos ir al men´ u desplegable Tratar→Modo experto. Ambos modos se diferencian en que éste u ´ltimo da más opciones de selección.

8.1.2.

Accediendo al log local en modo normal

Accediendo a la transacción SM21 – directamente o a través de men´ u– entramos por defecto a la pantalla de selección del log local del servidor de aplicaciones al que estemos conectados en Modo Normal. Veamos los distintos parámetros de selección que nos permitirán filtrar los datos del log: De Fecha/Hora a Fecha/Hora: Permite establecer un rango de fechas de mensajes del log a visualizar. Usuario: Nos permitirá visualizar sólo los mensajes que se hayan grabado en el sistema debido exclusivamente a la actividad del usuario especificado.

8.1. CONCEPTOS DEL LOG DEL SISTEMA

Figura 8.1: Pantalla principal log local del sistema

Código de transación: Nos permitirá visualizar los mensajes del log debidos exclusivamente a la acción de los usuarios sobre la transacción especificada. Proceso SAP: Nos permitirá visualizar los mensajes de log debidos a un proceso particular R/3. Valores posibles son: DP Dn

Procesos del dispatcher Procesos de trabajo, donde n = 0,...,9 o n = a, ...,z . En el caso de tener m´as de 10 procesos de trabajo numeraremos los siguientes con las letras del abecedario. VB Actualizaciones Vn Programas de actualizazi´on, donde n = 0,...,9 o n = a, ...,z Sn Spool, donde n = 0,...,9 o n = a, ...,z MS Servidor de Mensajes

Clases de Problemas: Limita la visualizaci´on por tipo de mensaje, s´olo

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

errores, errores y advertencias y todos los mensajes. El valor por defecto es la opci´on todos los mensajes.

8.1.3.

Accediendo al log local en modo experto

Para acceder al log del sistema en modo experto deberemos acceder por el men´ u desplegable tal y como se ha explicado anteriormente. La pantalla visualizada es igual que la anterior con la salvedad que se dispone de m´as opciones de filtro como es la opci´on Atributos.

Figura 8.2: Parámetros de selección adicionales en modo experto Esta opción nos permite filtrar además por: Programa: Se restringe el resultado a los mensajes causados por la ejecución del programa especificado. Clase de Problema: Limita el resultado a ciertos tipos de mensajes. Los valores posibles son: K S T W X

Mensajes del kernel del sistema Mensajes de estado Mensajes de transacciones Mensajes de advertencia Otros tipos de mensajes

De fichero / posici´on a fichero / posici´on: Define el segmento del fichero de log a leer. Si ya se ha le´ıdo el fichero una vez, se puede determinar

8.1. CONCEPTOS DEL LOG DEL SISTEMA

la posición de una entrada espec´ıfica haciendo doble click; la posición se encuentra en la sección de detalles técnicos. Formato mensaje (tipo): Se pueden seleccionar mensajes por el formato de la componente del sistema. Para visualizar posibles valores, deberemos pulsar el botón de ayuda de b´ usqueda correspondiente. Terminal: Se pueden filtrar los mensajes que han sido causados por la actividad llevada a cabo desde un servidor de presentación. Clase de desarrollo: Se pueden filtrar los mensajes que han sido producidos por la ejecución 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ósito es la jerarquización de tales objetos para una mejor gestión as´ı como el posibilitar su transporte a otros entornos. Con entradas internas Syslog: Visualización de mensajes relativos a los procesos de recolección y env´ıo de mensajes de log desde el log local al log central. Esta opción no esta disponible para entornos que no sean Unix.

8.1.4.

Leyendo el log del sistema

Una vez introducidos los valores de selección en la pantalla accederemos al contenido del log pulsando el botón 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ódigo transacción No de mensaje Texto del mensaje

8.1.5.

Opciones de relectura del log del sistema

Si hemos visualizado una vez el contenido del log del sistema filtrando exclusivamente por fecha y sin salirnos de la transacci´on volvemos a la

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

Figura 8.3: Contenido del log del sistema

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

Figura 8.4: Opciones de la barra de aplicaciones del log del sistema

Nueva Lectura en el Syslog. Vuelve a acceder al fichero para sacar un nuevo listado con los parámetros que se hayan seleccionado. Sólo Editar Nuevamente. Vuelve a mostrar el u ´ltimo resultado del log visualizado anteriormente con esta opción. Cargar en Syslog. Permite realizar una nueva lectura en el syslog filtrando con otros valores pero mantiene en el buffer el anterior resultado que puede ser accedido de nuevo a través de la segunda opción.

8.1. CONCEPTOS DEL LOG DEL SISTEMA

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á 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ón. Para ello usaremos las opciones de lectura de logs remotos que nos ofrece la transacción SM21. Estas opciones se encuentran en el men´ u desplegable en Syslog→Seleccionar .

Figura 8.5: Pantalla principal log remoto del sistema

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

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

llamado instancia que nos servirá para conocer en qué instancia se ha generado cada mensaje. La opción Syslog Central no está disponible para sistemas R/3 fuera del entorno UNIX. Es importante destacar que las u ńicas instancias que estan disponibles para la visualización 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ón es un log de terminación anormal de ejecución de cualquier programa. Esto se produce por una cancelación del programa que se está actualmente ejecutando; el sistema nos muestra una pantalla con un log de terminación donde se puede encontrar información acerca del error producido y su posible solución. Las posibles causas de terminación 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ón manual de un modo actualmente en ejecución. Cuando se produce una terminación anormal de una ejecución de un programa, el dump es mostrado automáticamente en exclusiva al usuario cuyo proceso de diálogo ha sido cancelado. En ese momento el usuario podrá leer ese log, pero si se sale de la pantalla del log del dump, éste ya no se vuelve a mostrar en pantalla. Para acceder de nuevo a él, deberemos acudir a la transacción donde se puede gestionar todos los dumps producidos en el sistema.

8.2.1.

Accediendo a los dumps del sistema

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

8.2. CONCEPTO DE DUMP

Figura 8.6: Pantalla principal de an´alisis de dumps

Figura 8.7: B´ usqueda de dumps antiguos

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

8.2. CONCEPTO DE DUMP

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

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

19. ABAP/4 Bloques control CONT . Sección con información complementaria a la de la seccion 8 . 20. Fin análisis error tiempo ejecución . Sección que marca el fin del log del dump. Si bien el t´ıtulo de cada sección aparece en el idioma de conexión, el contenido sólo se encuentra disponible en inglés y en alemán. Si nos conectamos al sistema en un idioma distinto del inglés y alemán, el dump será visualizado en el idioma configurado como de suplementación, que en general será el inglés, sino se ha definido suplementación de idioma (esto pertenece a la instalación de lenguajes) se visualizará en el idioma original de SAP, que es el alemán. Las secciones más importantes y que más 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. To resolve the problem, contact your SAP system administrator. ----------------AnÂ´ alisis error ----------------The following syntax error was found in the program AQ99HA==========CAND1========= : "The data object "T750B" does not have a component called "PERNR". -----------------------------------Notas para corregir errores -----------------------------------Probably the only way to eliminate the error is to correct the program. If you cannot solve the problem yourself, please send the following documents to SAP: 1. A hard copy print describing the problem. To obtain this, select the "Print" function on the current screen. 2. A suitable hardcopy printout of the system log. To obtain this, call the system log with Transaction SM21 and select the "Print" function to print out the relevant part. 3. If the programs are your own programs or modified SAP programs,

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

supply the source code. To do this, you can either use the "PRINT" command in the editor or print the programs using the report RSINCL00. 4. Details regarding the conditions under which the error occurred or which actions and input led to the error. ---------------------Entorno sistema ---------------------SAP Release.............. "40B" Application server....... Network address.......... Operating system......... Release.................. Hardware type............

"prodsap1" "10.190.20.13" "AIX" "3" "000541934C00"

Database Database Database Database

"sa3dbh2r" "ORACLE" "SP1" "SAPR3"

server.......... type............ name............ owner...........

Character set............ "es_ES.ISO8859-1" SAP kernel............... Created on............... Created in............... Database version.........

"40B" "Nov 4 1999 01:44:15" "AIX 2 4 004218294C00" "ORACLE 8.0.0.4"

Patch level.............. "542" Patch text............... " " Supported environment.... Database................. "ORACLE 8" SAP database version..... "40B" Operating system......... "AIX 2, AIX 1, AIX 3" ------------------------------Usuario, transacci´ on....

8.2. CONCEPTO DE DUMP

------------------------------Client.............. User................ Language key........ Transaction......... Program............. Screen.............. Screen line.........

111 "116665u" "S" " " "AQ99HA==========CAND1========= " "SAPMSSY0 1000" 6

------------------------------------------Informaciones lugar terminaci´ on ------------------------------------------The termination occurred in the ABAP/4 program "AQ99HA==========CAND1========= " in " ". The main program was " ". The termination occurred in line 0 of the source code of program " " (when calling the editor 00). The program "AQ99HA==========CAND1========= " was started as a background job. -----------------------------------Contenido campos sistema -----------------------------------Campo SY -------SY-SUBRC SY-TABIX SY-FDPOS SY-PAGNO SY-COLNO

Contenido....... ---------------0 0 0 0 1

Campo SY -------SY-INDEX SY-DBCNT SY-LSIND SY-LINNO

Contenido........... -------------------0 0 0 1

-------------------------------Variables seleccionadas --------------------------------No existe ninguna informaci´ on en el dump.

100

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

------------------------------------Llamadas / Eventos activos ------------------------------------No Tipo Nombre Programa Include L´ ınea ------------------------------------------------------1 ??? ??? ??? ??? 0 ----------------Notas interna -----------------The termination occurred in the function "ab_genprog" of the SAP Basis System, specifically in line 845 of the module "abgen". The internal operation just processed is " ". Program name.........: "AQ99HA==========CAND1========= ". Error message........: "The data object "T750B" does not have a component called "PERNR". ". ---------------------------------------Llamadas activas kernel SAP ---------------------------------------AixStack at 0x100c3cb0 CTrcStack at 0x100c3fa0 rabax_CStackSave at 0x100683f0 ab_rabax at 0x1006f270 ab_genprog at 0x103fd33c newload at 0x100dd164 ab_LoadProg at 0x100dd518 ab_dialg at 0x103558f0 dy_cdiag at 0x101fd310 ab_submit at 0x104ee7a8 ab_retdynp at 0x10351794 ab_run at 0x104eda34 dynpmcal at 0x104d62cc dynppai0 at 0x104d7aec dynprctl at 0x104d8cd0 dynpen00 at 0x104c0f30 Thdynpen00 at 0x100b4f14 TskhLoop at 0x100b9d7c

8.2. CONCEPTO DE DUMP

101

tskhstart at 0x100c2404 DpMain at 0x10016bb4 main at 0x100011fc -----------------------------------------------Lista programas ABAP involucrados ------------------------------------------------------------------------------------------------------------No existe ninguna informaci´ on en el dump. ---------------------------Lista tablas internas --------------------------No existe ninguna informaci´ on en el dump.

-----------------------------------------------------Directorio tablas aplicaci´ on (contenidos) -----------------------------------------------------Programa Nombre........ Cont.....1....+....2....+....3....+.... ----------------------------------------------------------------------------------------------------------Directorio ´ ambitos datos (info gesti´ on) --------------------------------------------------Programa No .. Nombre........ Long Ofsg Tipo Next Fecha gen. H.gen. --------------------------------------------------------------0 not assigned 1 /%_LISTTABLES 2 global stack

0 6968 65536

0 INVL 0 COMM 0 GLST

0 0 0

-------------------------------------------------Directorio ´ ambitos datos (contenidos) --------------------------------------------------

102

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

Programa No .. Nombre... Cont.....1....+....2....+....3....+.... --------------------------------------------------------? 0 not assigned <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ón empresarial se produce una gran cantidad de información que en muchas ocasiones interesa sacar a papel a través de informes, listados, análisis. . . El spool es un almacén receptor de peticiones de impresión que proporciona una serie de utilidades para controlar la salida de información. Aunque se asocia directamente spool con imprimir en papel, en SAP las posibilidades son más amplias: podemos enviar una orden de spool por fax, o imprimirla en un fichero. Nosotros nos limitaremos a ver el funcionamiento de la salida por impresora para lo cual lo primero que debemos hacer es aprender cómo se instala una.

9.2.

Instalaci´ on de una impresora

Con la transacción SPAD – pantalla de la figura 9.1 a la que llegaremos a través de Herramientas→ CCMS→ Spool→ Gestión de spool – podemos instalar dispositivos de salida en nuestro sistema R/3. Vamos a describir la instalación de una impresora de tipo local a nivel de PC, es decir, una impresora genérica en la que cualquiera puede imprimir pero a cada persona que lo haga le saldrá la información por la impresora que tenga definida por defecto en su servidor de presentación. 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ón con el icono de un folio en blanco llegaremos a la pantalla de la figura 9.2 en la que definiremos los siguientes datos: Tipo de dispositivo. Es lo más parecido a lo que en microinformática 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ón del frontend de SAP. Cuando se imprime algo el sapgui ejecuta automáticamente 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ón 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ón de facturas, nóminas, etc. No nos interesara, en estos casos, que ning´ un usuario pueda sacar listados por estas impresoras interrumpiendo los largos procesos que suelen llevar a cabo. Como estamos definiendo una impresora local para todo el mundo dejamos este campo en blanco. Modelo. Campo descriptivo para poner la marca y modelo de la

´ DE UNA IMPRESORA 9.2. INSTALACION

105

Figura 9.2: Datos generales para una impresora local

impresora. Ubicación. 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á la pantalla de la figura 9.3 Aqu´ı se le dice como esta conectada la impresora al servidor SAP. Elegiremos de la lista la opción F:Imprimir en front end que le marca que debe enviar la información al PC para que sea este el que le de salida. El campo impresora host debemos rellenarlo con el nombre DEFAULT para indicarle que la orden de spool debe salir por la impresora que este configurada por defecto en el PC. Una vez hecho esto sólo nos queda pulsar el botón de grabar y ya podemos usar la impresora instalada.

´ DE SPOOL CAP´ITULO 9. GESTION

106

Figura 9.3: Tipo de impresora para una impresora local

9.3.

Como imprimir

Teniendo una impresora ya instalada podemos, desde cualquier pantalla de listado, pulsar el icono de impresora de la barra de estándar de herramientas y tendremos que rellenar las opciones que vemos en la figura 9.4. El primer campo a rellenar es el nombre de la impresora por donde queremos que salga nuestro listado1 . Este es el u ńico campo obligatorio, pero también podemos indicar otras muchas opciones que vemos a continuación. La cantidad de copias que queremos sacar. Si queremos todas las página o sólo un rango de ellas. El nombre y el t´ıtulo de la orden de spool. Será u ´til para luego buscarla entre el spool o entre el montón de hojas impresas que salen por una impresora compartida. La salida inmediata o el almacenamiento en el spool. 1

En la pantalla viene con el nombre gen´erico de dispositivo de salida.

9.3. COMO IMPRIMIR

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

107

´ DE SPOOL CAP´ITULO 9. GESTION

108

Podemos marcar el borrado de la orden tras la impresión 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ón 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ágina.

9.4.

Operaciones sobre ´ ordenes de spool

Para poder administrar todas las peticiones de spool que hacemos SAP provee de la transacción SP01 que se encuentra en Herramientas→ CCMS→ Spool→ Control de salida. En ella nos encontramos inicialmente una pantalla con criterios de seleccion como la de la figura 9.5. Aqu´ı podemos elegir las órdenes de spool por varios criterios; los más habituales son el creador de la orden y la fecha. Tras pulsar F8 nos encontramos con un listado de las órdenes seleccionadas como el de la figura 9.6. Este listado tiene la misma caracter´ıstica que el de la transacción de gestión de jobs; es un programa de selección, listado y gestión simultáneamente. Las operaciones que podemos hacer sobre una orden de spool incluyen la creación de órdenes de salida, el cambio de los atributos, el borrado de la orden o la visualización de su contenido. Esta u ´ltima opción es realmente interesante cuando queremos comprobar el resultado de un programa que se ha ejecutado en proceso de fonfo, pero no queremos imprimirlo hasta ver si ha salido lo que esperabamos. En cuanto a los atributos, en la figura 9.7 podemos ver algunos de los que se pueden cambiar. Básicamente son los mismos que definimos inicialmente al crear la orden de spool (ver figura 9.4). Por ejemplo, es muy habitual comprobar tras la salida al papel que un listado que tiene 132 columnas en sus atributos ha salido con letra peque˜ na y en formato horizontal pero no llega a ocupar realmente más de 80. En ese caso cambiaremos el campo edición por un X 65 80 para conseguir un listado con letra más grande y en vertical y volveremos a repetir la salida de la orden.

´ 9.4. OPERACIONES SOBRE ORDENES DE SPOOL

Figura 9.5: Transacción SP01. Selección de órdenes de spool

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

109

110

´ DE SPOOL CAP´ITULO 9. GESTION

Una de las labores del administrador consiste en asegurarse que las o´rdenes de spool olvidadas por los usuarios no llenan nuestra base de datos. Para ello dispone del programa RSPO0041 que le permite eliminar masivamente el spool que lleve m´as de n d´ıas almacenado.

Figura 9.7: Atributos de una orden de spool

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

Modelo de seguridad en R/3

En cualquier sistema de gestión de información integrado se guardan datos de diferentes áreas a los que sólo 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ón legal de proteger información ajena a la propia empresa como los datos personales de sus empleados, las condiciones económicas de los proveedores. SAP contempla toda esta problemática implementando un modelo de seguridad que permite proteger de una manera flexible los datos y las operaciones que se hacen sobre ellos. En la figura 10.1 podemos ver un esquema de los componentes de la seguridad en R/3. En el lado derecho tenemos los objetos de autorización que se componen de campos. Estos objetos representan lo que queremos proteger. Ejemplos de objetos de autorización son: S TCODE. Protege el código de transacción y contiene un sólo campo que es la transacción. Es el más importante de todos porque todas las operaciones que se hacen en SAP empiezan por el acceso a una transacción. 111

112

´ DE USUARIOS Y AUTORIZACIONES CAP´ITULO 10. GESTION

Figura 10.1: Componentes de la seguridad en R/3

S TABU DIS. Protección del contenido de tablas de customizing. Contiene dos campos que son el grupo de autorizaciones de la tabla (DICBERCLS) a la que se quiere acceder y la actividad (ACTVT) que se quiere ejecutar (crear, modificar, borrar. . . ) F BKPF BUK. Protección de la contabilización de documentos por sociedad financiera. Se compone de dos campos; la sociedad (BUKRS) a cuyos documentos contables queremos acceder y la actividad (ACTVT) que se quiere hacer. En el lado izquierdo de la figura vemos la estructura modular que va desde la autorización simple sobre un u ńico objeto de autorización hasta el maestro de usuarios que son los que acceden al sistema. Veamos lo que representa cada uno de los niveles: Autorizaciones. Una autorización consiste en una asignación de valores a los campos de un objeto de autorización. Por ejemplo, crearemos una autorización para el objeto S TCODE que tenga el valor FB01 para el campo TCODE. De está manera el usuario que tenga asignada esta autorización podrá acceder a la transacción de crear documento contable. También tendremos que crear otra autorización

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ón de contabilizar para la sociedad financiera 1000. Perfiles. Un perfil es simplemente la agrupación de varias autorizaciones que hayamos creado anteriormente. El perfil es la unidad m´ınima de seguridad que le podemos asignar a un usuario, es decir, la u ńica forma de asignar las dos autorizaciones del ejemplo anterior es incluirlas en un perfil que llamaremos CONTABLE e incluir este perfil en los usuarios. Grupos de actividad. Son las agrupaciones de transacciones y actividades que se crean con el generador de perfiles. Estos grupos de actividad contienen internamente perfiles (que a su vez contienen autorizaciones) y se asignan directamente a los usuarios. Usuarios. Para que un empleado tenga acceso a los datos de gestión de la empresa debe disponer de un código de usuario en R/3. Este usuario tendrá asignados unos grupos de actividad o unos perfiles de autorización (o ambos) para poder realizar las tareas que exige su función o puesto de trabajo.

10.2.

Mantenimiento de usuarios

Para la creación y mantenimiento de usuario R/3 dispone de la transacción SU01 (Herramientas→ Gestión→ Actualizar usuarios→ Usuarios). En la pantalla correspondiente a la figura 10.2 escribiremos el código del usuario y pulsando uno de los botones de la barra de aplicación o escogiendo una de las opciones del men´ u Usuario podemos realizar diversas acciones como crear, modificar, cambiar clave acceso, bloquear. . . Pulsando sobre el botón con el icono de un folio en blanco vamos a crear un nuevo usuario en el sistema. Vemos en la figura 10.3 las siete pesta˜ nas que componen el registro maestro de un usuario. Estas son: Direcci´ on. Se graban en este apartado datos personales como el nombre, apellidos, departamento, teléfono. . . . En el campo edición veremos el nombre tal y como aparecerá en los listados o en otras transacciones. Datos logon. Es obligatorio indicar una clave inicial con la que accederá el usuario, aunque en su primera conexión se le pedirá que la cambie. También podemos limitar la validez temporal de manera

114

´ DE USUARIOS Y AUTORIZACIONES CAP´ITULO 10. GESTION

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

que podemos tener empleados que accedan a nuestro sistema hasta determinada fecha como puede ser el fin de su contrato o cesión a nuestro departamento. Valores fijos. En esta pesta˜ na definimos el men´ u inicial de entrada al sistema, la impresora SAP y algunos parámetros de impresión 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ón, 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ámetros por defecto para multitud de campos de todos los módulos 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ámetro correspondiente consiguiendo que en todas las pantallas de R/3 en la que aparezca el campo centro, éste se encuentre relleno automáticamente con el valor 1000. papeles y perfiles. Las operaciones a las que esta autorizado un usuario vienen determinadas por los valores que le ponemos en estas dos pesta˜ nas. Al asignarles un papel le estamos a˜ nadienlo perfiles también, pero existe la posibilidad de incluir perfiles manualmente. Esta posibilidad se conserva por compatibilidad con versiones anteriores pero no es el modo de trabajo habitual desde la versión 4.6A. Grupos. A la hora de descentralizar el mantenimiento de un

10.2. MANTENIMIENTO DE USUARIOS

Figura 10.3: Datos de direccion del maestro de usuarios

115

116

´ DE USUARIOS Y AUTORIZACIONES CAP´ITULO 10. GESTION n´ umero enorme de usuarios debemos agruparlos asign´andoles la pertenencia a uno o varios grupos. De esta manera podemos autorizar a diversos administradores a gestionar los usuarios que pertenezcan a determinados grupos.

10.3.

Generador de perfiles

Debido a la gran complejidad que supone la creación manual de perfiles y autorizaciones, desde la version 3.1G de R/3, existe el generador de perfiles. Las ventajas que aporta para el administrador la utilización de esta herramienta son m´ ultiples aunque la más destacable es que ya no necesita conocer o investigar la funcionalidad de las transacciones que incluyen en los perfiles de usuario. El generador de perfiles incluyen una base de datos que relaciona cada una de las transacciones de R/3 con los objetos que comprueba. En la versión 3.0F y anteriores, la creación de un perfil de seguridad exig´ıa un tedioso trabajo de b´ usqueda de objetos que chequea cada transacción. Para crear un papel disponemos de la transacción PFCG que nos muestra una pantalla como la de la figura 10.4.

Figura 10.4: Transaccion PFCG. Mantenimiento de papeles

10.3. GENERADOR DE PERFILES

117

Al pulsar el botón de crear pasaremos a la pantalla de la figura 10.5 en la que vemos las diferentes partes de la creación de un grupo de actividad repartidas en cuatro pesta˜ nas. En la primera de ellas rellenamos unicamente un descripción corta del papel y también podemos completar el campo de descripción inferior en el que podemos indicar instrucciones sobre a quién se debe asignar este perfil o cual es su función espec´ıfica.

Figura 10.5: Descripcion del papel

Al pasar a la pesta˜ na men´ u (ver figura 10.6) vemos unos botones que nos permiten incluir transacciones, informes o direcciones web en el grupo de actividad. Observamos en la figura como se ha incluido ya la transacción de contabilizar documento (perteneciente al módulo FI). Esto implica que el usuario al que se le asigne este perfil podrá ejecutar la transacción FB01, pero no hemos determinado a´ un para que sociedades financieras, cuentas o deudores podrá hacerlo. En la figura 10.7 tenemos la pantalla de asignación de valores a los objetos de autorización a la que se llega a través de la pesta˜ na Autorizaciones. Son cuatros los objetos de la gestión financiera los que chequea esta transacción

118

´ DE USUARIOS Y AUTORIZACIONES CAP´ITULO 10. GESTION

Figura 10.6: Transacciones asignadas a un papel

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

10.3. GENERADOR DE PERFILES

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

Figura 10.8: Asignacion de un papel a usuarios

119

Cap´ıtulo 11 Sistema de transporte El sistema R/3 dispone de una herramienta que nos permite pasar objetos de un entorno (por ejemplo, desarrollo) a otro (por ejemplo, producción ). Los objetos a pasar pueden ser definición y contenido de tablas nuevas, programas nuevos, datos de customizing e incluso modificaciones al estándar. Este traspaso de información 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ón o repetir la inclusión de datos de customizing. Todo ello redunda en una mayor productividad y en una minimización de riesgos ya que la información, antes de ser insertada en el sistema productivo, es probada en el sistema de desarrollo y su traspaso no será realizado hasta que el responsable del proyecto dé el visto bueno. La herramienta que permite este traspaso de información 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ón; obviamente si no existe tal separación de sistemas, es decir, si sólo se dispone de un u ńico sistema la utilidad del sistema de transportes se reduce a traspasar información 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ón de nuevos objetos en el sistema destino. Modificación de objetos ya existentes en el sistema destino. 121

CAP´ITULO 11. SISTEMA DE TRANSPORTE

122

Cuando se crea o modifica un objeto en el sistema de desarrollo, el sistema propone un código u ńico para identificar la creación o modificación de ese objeto, siempre y claro está que el mandante donde se esté trabajando esté configurado para registrar cualquier modificación (ver cap´ıtulo 12). El código propuesto conforma lo que se denomina Orden de Transporte y a ella se asociarán los objetos que el usuario cree o modifique, de tal manera que el sistema bloqueará, dependiendo de la naturaleza de la orden, esos objetos para que nadie más que el propietario de esa orden de transporte pueda modificar esos objetos mientras la orden no esté 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á creciendo desde 900000 hasta 999999 a medida que vayamos creando nuevas órdenes de transporte. El sistema de transportes no asocia directamente los objetos creados o modificados a una orden de transporte sino que lo hace a través de las tareas; las tareas deben obligatoriamente pertenecer a una u ńica orden de transporte y al igual que ellas siguen el mismo código secuencial de tal manera que nunca pueden existir varias órdenes o tareas con el mismo código. Las tareas, al igual que las órdenes, están asignadas a un usuario y su finalidad es mejorar la gestión 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ódigo será 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ásica entre un caso y otro será que el transporte al sistema productivo de la primera orden conllevará el transporte de los dos objetos – programa y tabla – a la vez, mientras que en el segundo caso el transporte de una orden conllevará el transporte sólo del objeto asociado. Será tarea del propietario de la orden el decidir de cuantos objetos se va a componer cada orden de transporte. No se deberá crear una orden para cada objeto a modificar o crear ya que esto complicará de manera excesiva nuestra

Â´ 11.1. ORDENES DE TRANSPORTE

Figura 11.1: Esquema de una orden de transporte

Figura 11.2: Esquema de ordenes de transporte

123

124

CAP´ITULO 11. SISTEMA DE TRANSPORTE

labor de gestión de las órdenes de transporte; tampoco se deberá asignar una u ńica orden de transporte a todos los objetos que vayamos a crear o modificar ya que ello puede llegar a hacer inmanejable la orden debido a su tama˜ no. Se deberá, por lo tanto, llegar a un término 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á asociar el nuevo objeto por crear a una Clase de Desarrollo. Las clases de desarrollo no son más que agrupaciones lógicas de objetos que, además, 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ándole la ruta de transporte a seguir cuando la orden asociada a ese objeto sea transportada. Todos los objetos estándar del sistema SAP R/3, ya sean programas, tablas, ayudas de b´ usqueda, etc, tienen asociado una clase de desarrollo estándar de SAP. Los objetos nuevos a crear deberán asociarse a clases de desarrollo nuevas, que se distinguirán de las estándar por el primer carácter de su identificación, que siempre deberá 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á asignar a objetos que sean de pruebas y que no deseemos que vayan a pasar nunca a formar parte del sistema de producción. Hablamos entonces de objetos locales privados o temporales. Ver figura 11.3.

11.3.

Tipos de ´ ordenes de transporte

El sistema SAP R/3 provee distinto tipo de órdenes 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ón del sistema. La parametrización 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ón automática de cambios (ver cap´ıtulo 12), una tarea y una orden de customizing son creadas automáticamente cuando un usuario en un sistema R/3 realiza cambios de customizing. Ordenes de modificaci´ on transportables A la vez que cambios en el customizing, será también 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 área de desarrollo y que afectarán básicamente a programas y tablas, son independientes de mandante; esto significa que tienen efecto en todo el sistema. La creación de nuevos objetos, o la modificación de los que proporciona SAP son grabados, de manera similar al customizing, en tareas asignadas a órdenes de modificación transportables. ´ Ordenes de modificaci´ on locales También se pueden realizar cambios locales; se distinguen de los anteriores en que estos cambios no pueden ser transportados a otros sistemas.

126

11.4.

CAP´ITULO 11. SISTEMA DE TRANSPORTE

Estados de una orden de transporte y sus tareas

Desde que se crean una orden de transporte y sus correspondientes tareas hasta que son liberadas (fase previa para el transporte de dicha orden a otro sistema), éstas pasan por dos estados: Modificable Cuando la orden o tarea es creada para ser asociada a objetos de desarrollo o de customizing, ésta aparece con status modificable; es decir, permite la inclusión y eliminación de objetos asociados. Si se trata de una orden, ésta permite la asignación o borrado de tareas; si se trata de una tarea, esta permite la asignación o desasignación de objetos del sistema . Liberada El paso previo del transporte consistirá en la liberación de la orden y sus tareas asociadas. Para poder liberar una orden, se deberá primero liberar todas sus tareas asociadas. La liberación de una tarea consiste en cerrarla para posteriores modificaciones; es decir, no se podrá asignar nuevos objetos a esa tarea ni desasignar los ya existentes. La liberación de una orden consiste en cerrarla para posteriores tareas; no se podrá crear ninguna nueva tarea asociada a esa orden ni se podrán borrar las ya existentes. Una orden puede permanecer en status Modificable aunque todas sus tareas asociadas estén en estado liberado; ello nos permitirá asignarle nuevas tareas con status modificable para poder seguir trabajando con ella hasta que liberemos la orden. La liberación de una orden de transporte además de bloquearla para cualquier modificación futura, realiza el export de la orden. El export de la orden consiste en la creación de dos ficheros a nivel de sistema operativo – fichero data y fichero cofiles –. En estos ficheros se produce la exportación 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ás que la exportación de información fuera de la base de datos de origen a fichero del sistema operativo y la importación de dicha información en la base de datos destino. Los dos ficheros creados en la exportación de una orden de transporte tienen la siguiente ubicación en el sistema operativo: Fichero data Ubicado en /usr/sap/trans/data; es el que contiene toda la información asociada a la orden de transporte; cuantos más objetos estén 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á el fichero data a crear y mayor el tiempo que llevará su creación, es decir, la exportación. La nomenclatura del fichero data, siendo la de la orden liberada <SID>K9nnnnn, puede ser: D9nnnnn.<SID> R9nnnnn.<SID> Fichero cofiles Ubicado en /usr/sap/trans/cofiles; es un fichero de control necesario para el transporte; su tama˜ no es mucho menor que el data ya que no contiene los datos de la orden. La nomenclatura del fichero cofiles, siendo la de la orden liberada <SID>K9nnnnn, es: K9nnnnn.<SID>

11.5.

Customizing organizer y workbench organizer

Para gestionar las órdenes 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és de las transacciones SE09 como SE10 y desde ellas se puede gestionar las órdenes de transporte relativas a

128

CAP´ITULO 11. SISTEMA DE TRANSPORTE

desarrollo (órdenes de modificación tanto locales como transportables; esta herramienta la usarán los desarrolladores) y las de Customizing (herramienta que usarán los consultores).

Figura 11.5: Pantalla principal Workbench Organizer En ambas herramientas la pantalla de selección dispone como parámetro principal del usuario, que por defecto está relleno con el nombre del usuario con el que nos hemos conectado al sistema. Todas las órdenes que visualicemos con esta herramienta serán las asociadas al usuario arriba indicado. Como parámetros adicionales podemos elegir visualizar las órdenes modificables y las liberadas o sólo uno de los dos tipos. Además, también podemos restringir por fechas para evitar que el listado sea demasiado largo si es que hemos trabajado con muchas órdenes de transporte. En el caso del customizing organizer tenemos, además, la posibilidad de visualizar sólo las órdenes de customizing o sólo las de workbench o ambas a la vez. Una vez elegidos los parámetros de selección del CO o del WBO pulsaremos el botón de visualización y accederemos a una pantalla como la mostrada en la figura 11.6.

11.5. CUSTOMIZING ORGANIZER Y WORKBENCH ORGANIZER 129

´ Figura 11.6: Ordenes de transporte

Desde esta pantalla podremos identificar qué objetos están asociados a qué órdenes de transporte sin más que ir desplegando la estructura en árbol presentada. Esta estructura en árbol 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é 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ón donde el jefe de proyecto crea una u ńica 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á asignando sus objetos a su tarea con lo que no se

130

CAP´ITULO 11. SISTEMA DE TRANSPORTE

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

´ 11.6. TRANSPORTE MANUAL DE ORDENES

131

Figura 11.7: Creaci´on de una orden de transporte

creamos un nuevo objeto de desarrollo. El sistema nos pide asignarle una orden ya creada o crear una nueva.

11.6.

Transporte manual de ´ ordenes

Una vez que una orden ha sido liberada, ésta 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á 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á estar compartido via NFS para todos los entornos que conforman la ruta del transporte. Es por ello por lo que podremos acceder a este path desde cualquier servidor al que nos conectemos desde el sistema operativo (por ejemplo via telnet).

CAP´ITULO 11. SISTEMA DE TRANSPORTE

132

En sistemas Windows NT, esta directorio de transporte deberá estar configurado como compartido para que desde todos los entornos esté disponible, sin embargo sólo será local para uno de ellos. Accederemos a través del emulador MSDOS en el servidor donde la ruta es local. Presentamos a continuación la estructura en árbol del sistema operativo UNIX que es necesaria para el transporte y explicaremos para qué sirve cada directorio: /usr/sap/trans/bin /usr/sap/trans/data

/usr/sap/trans/cofiles

/usr/sap/trans/log

/usr/sap/trans/buffer

Directorio desde donde se lanza el programa de control del transporte, tp. Directorio donde se almacenan los ficheros data generados en la exportación de datos desde la base de datos que se realiza durante la liberación de una orden. Directorio donde se almacenan los ficheros cofiles generados en la exportación de datos desde la base de datos que se realiza durante la liberación de una orden. Directorio donde se almacenan en ficheros los logs de cada una de las órdenes de transporte que se importan al sistema destino. Directorio donde se almacena un listado con todas y cada una de las órdenes 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á todav´ıa sin transportar; si es as´ı, se ejecuta el transporte al sistema destino. Las órdenes, por defecto, al ser liberadas son a˜ nadidas al ”buffer”por lo que no será necesario incluir ninguna orden en este listado a no ser que expresamente hayamos eliminado su entrada de dicho listado o que la orden ya haya sido transportada y queramos volver a ejecutar su transporte.

Veamos a continuación cómo deberemos usar el programa de control para gestionar el transporte de las órdenes ejecutándolo desde el directorio bin

´ 11.6. TRANSPORTE MANUAL DE ORDENES

133

mencionado antes: tp showbuffer <SID> Nos muestra el listado de ´ordenes inclu´ıdas en el buffer. En lo que sigue, <SID> se refiere al nombre del sistema destino del tranporte. Las ´ordenes que ya han sido transportadas al sistema destino aparecen con el texto already imported.

Figura 11.8: Listado de ´ordenes transportadas y liberadas

Todas las ejecuciones del comando tp, independientemente del argumento asociado, devuelven un código de retorno cuyos valores pueden ser: 0 → Operación ejecutada con éxito 4 → Operación ejecutada con advertencias 8 → Operación ejecutada con errores. Un valor mayor que 8 también indicará que la operación no se ha realizado con éxito. tp delfrombuffer <orden> <SID>

134

CAP´ITULO 11. SISTEMA DE TRANSPORTE

Elimina del listado del directorio buffer la referencia a la orden de transporte seleccionada. No borra la orden f´ısicamente, pero impide que se pueda transportar esa orden. tp addtobuffer <orden> <SID> A˜ nade la orden seleccionada al buffer, dejando la orden preparada para ser transportada. Esta operación, 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á obligatoriamente especificar el mandante destino con la opción client=<mandante destino> a˜ nadida después del <SID>.

Figura 11.9: Transporte de una orden a un sistema destino

tp import all <SID> Importa al sistema destino especificado todas las órdenes que hayan sido liberadas y que, por tanto, se encuentran en el buffer. Las órdenes son importadas por orden de aparición en buffer, por lo que primero se transportarán las órdenes que han sido liberadas primero. Si el mandante

´ 11.6. TRANSPORTE MANUAL DE ORDENES

135

destino no coincide con el origen, se deberá usar la opción especificada en el caso anterior. No se recomienda el uso de esta opción ya que podemos desear importar al sistema destino en un orden distinto al que han sido liberadas las órdenes que se encuentran en el buffer, y este comando tiene un orden de transporte preestablecido. tp import <orden> <SID> client=<nnn> u1 La opción u1 es el modo incondicional de sobreescritura. Habrá que especificarlo obligatoriamente si deseamos transportar al sistema destino una segunda vez una orden. Esto es as´ı porque el sistema chequea que la orden ya ha sido transportada previamente y no vuelve a ejecutar la importación. Para obligarle a sobrescribir la misma orden que se ha transportado previamente, será necesario especificar la opción u1.

Figura 11.10: Esquema ejemplo del transporte de una orden Veamos a continuación un ejemplo. Supongamos un sistema de desarrollo D10 en un servidor NT llamado devsap10 y un sistema de producción P10 en otro servidor NT llamado prodsap10. En ambos entornos está establecida la ruta del transporte D10 → P10 a través de la clase de desarrollo ZDEV. Estableceremos el directorio de transporte C:\usr\sap\trans localmente en el servidor de producción, 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ón. Al crearlo, le asignaremos la clase de desarrollo ZDEV y el sistema nos propondrá un código para su orden de transporte, por ejemplo D10K902010. Al liberar esta orden, el sistema de desarrollo se conecta a : \\prodsap10\usr\sap\trans para crear en los subdirectorios data y cofiles los ficheros D902010.D10 y K902010.D10 correspondientemente. Abriendo una ventana de MSDOS en el sistema de producción, sistema destino del transporte, ejecutamos: C:\usr\sap\trans\bin\tp showbuffer P10 para comprobar que la orden D10K902010 se encuentra en el buffer; si acaba de ser liberada, aparecerá la u ´ltima del listado. Una vez comprobado que la orden se encuentra en el buffer del sistema de producción ejecutaremos el transporte al mandante 110. Como el mandante destino y origen no coinciden deberemos usar la opción client=<SID>. C:\usr\sap\trans\bin\tp import D10K902010 P10 client=110 Una vez que este comando ejecute la importación y su código de retorno sea 0, el programa ZREPORT estará disponible en el sistema de producción.

11.7.

Log del transporte

Existe dentro del sistema SAP R/3 una herramienta que nos proporciona mucha más información sobre el transporte de una orden que el simple código de retorno devuelto por el comando tp. Tal código 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é tipo de problema ha ocurrido. La herramienta del log del transporte está disponible tanto en la transacción SE09 como en la SE10. Podemos pulsar el botón de visualización 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én podemos rellenar los parámetros de selección explicados en la sección 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ón 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é sistema se ha producido el export as´ı como el import en el sistema destino con cada uno de sus pasos. La importación se realiza en varios pasos, dependiendo su n´ umero del tipo de objeto a transportar. Desglosando la estructura en árbol del log podemos obtener distintos niveles de información, cada vez más detallados. Una vez que hemos visto en qué 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é razón se ha producido un error en el transporte y cómo habrá que resolverlo. Los errores más comunes son de información incompleta en el sistema destino para poder activar las modificaciones recién transportadas. Un ejemplo puede ser que el código fuente de un programa que queramos transportar al sistema destino del transporte haga referencia a una tabla cuya definición se encuentra en otra orden de transporte, todav´ıa sin transportar. Si transportamos primero la orden del código fuente, la importación fallará devolviendo un código 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ón del código fuente por hacer referencia a una tabla que todav´ıa no existe en el sistema destino. Lo que deberemos hacer será, pasar la orden donde se encuentra la definición de la tabla a la que se hace referencia en el programa y, posteriormente, transportar de nuevo la orden que ha fallado – primero deberemos a˜ nadirla manualmente de nuevo al buffer –.

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

140

12.1.

´ DE MANDANTES CAP´ITULO 12. GESTION

Creaci´ on de un nuevo mandante

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

´ DE UN NUEVO MANDANTE 12.1. CREACION

141

Figura 12.1: Pantalla principal de la gesti´on de mandantes

de modificación para objetos dependientes e independientes de mandante, nivel de protección y restricciones. Papel del mandante Cuando creamos un mandante deberemos asignarle un papel, es decir un propósito o función para lo que se va a utilizar. Los valores posibles son producción , test , customizing , presentación , formación o referencia SAP . Modificaciones y transportes de objetos dependientes de mandante Dependiendo del papel que tome el mandante puede llegar a ser necesaria la activación o desactivación 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án ser registrados en órdenes de transporte para su posterior paso al mandante productivo. Veamos las distintas opciones: Modificaciones sin grabaci´ on autom´ atica No pide orden de transporte al modificar el customizing. Sin embargo permite asignar órdenes de transporte manualmente. Para mandantes de formación y test.

142

´ DE MANDANTES CAP´ITULO 12. GESTION

Figura 12.2: Detalle de opciones de un mandante

´ DE UN NUEVO MANDANTE 12.1. CREACION

143

Grabaci´ on autom´ atica de modificaciones Al modificar customizing el sistema pide órdenes de transporte. Para mandantes de desarrollo. No se permiten modificaciones No se permite modificar customizing. Permite asignar órdenes de transporte manualmente. Opción más usada para mandantes de sistemas productivos. No se permiten transportes Se permite modificar el customizing pero las modificaciones no se registran automáticamente en órdenes de transporte. Tampoco se permite la asignación manual a órdenes de transporte. Opción más usada para mandantes de sistemas productivos Modificaciones objetos independiente mandante Se puede limitar el alcance de las modificaciones permitidas en el mandante. Las opciones son: Se permite modificar repository y customizing indep.mandante Opción más usada para mandantes en sistemas de desarrollo o pruebas donde sepamos que las modificaciones independientes de mandante no afectarán negativamente al funcionamiento del sistema. No modificaci´ on de objetos customizing independ.de mandante Las modificaciones del customizing que afectan a tablas independientes de mandante afectan a todo el sistema. En ciertos sistemas no productivos con diversos mandantes donde se han realizado tareas de customizing antagónicas, se deberá usar esta opción. No modificaci´ on de objetos repository Impide modificar objetos standard del repository (tablas, programas, pantallas, etc...) y la creación de nuevos objetos de desarrollo. No modif.de objetos repository y customizing indep.mandante Opción más usada en mandantes de sistemas de productivo. Con esta opción se desactiva la posibilidad de modificar objetos standard de SAP (tablas, programas, etc. . . ) y la posibilidad de modificar opciones de customizing globales que afecten a todos los mandantes. Protecci´ on Se pueden proteger mandantes de una copia de mandante o de comparación (existen herramientas que nos permiten comparar los datos de distintos mandantes). Es importante tener los mandantes

´ DE MANDANTES CAP´ITULO 12. GESTION

144

productivos protegidos contra copias – intencionadas o no – de mandante. Veamos los distintos niveles de protección: Nivel Protecci´ on 0: No hay restricciones En este nivel no existe protección . Nivel Protecci´ on 1: No se permite sobrescritura En este nivel se protege contra copia de mandante. El mandante as´ı protegido no podrá ser sobrescrito por una copia de mandante. Nivel Protecci´ on 2: No se permite sobrescritura ni comparaci´ on Este nivel además de proteger contra copia de mandante protege contra la herramienta de comparación. Esta opción será especialmente necesaria para mandantes productivos donde la información all´ı contenida es especialmente confidencial y donde se deberán cumplir todos los requerimientos impuestos por las leyes oficiales de protección de datos. Restricciones Por u ´ltimo podremos restringir el uso de herramientas CATT o incluso proteger el mandante contra un upgrade - cambio de versión -. 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 él no podrán ser modificados. Esto compone lo que es el primer paso en la creación de un mandante. El segundo paso será el llenado del nuevo mandante de datos a partir de un mandante ya existente a través de uno de los siguientes procesos: Copia local Copia remota Transporte de mandante

12.2. COPIA LOCAL DE MANDANTE

12.2.

145

Copia local de mandante

Una vez completado el primer paso de la creación 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ón anterior. El u ńico usuario disponible en un mandante recién creado y sin ning´ un tipo de datos es el usuario SAP* con password PASS. Este usuario está disponible siempre en SAP ya que as´ı se ha programado el kernel. La password PASS sólo está activa en mandantes recién creados o si en un mandante estandar o ya creado y con datos propios eliminamos del maestro de usuarios el usuario SAP*; esta eliminación del superusuario SAP* no es sino una simple reinicialización 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á plenamente operativo hasta que el la copia de datos se finalice – deberemos acceder a la opción de Copia Local disponible en la transacción SCCL o alternativamente Herramientas→ Gestión→ Gestión→ Gestión de Mandantes→ Copia Mandante→ Copia Local.

Figura 12.3: Copia local de un mandante

En esta pantalla el mandante destino es el mandante al que nos hemos conectado; deberemos elegir un perfil de copia, el mandante origen de copia

146

´ DE MANDANTES CAP´ITULO 12. GESTION

de datos, el mandante origen de copia de datos de maestros de usuario y si el proceso corre en modo test o real. El sistema permite elegir distintos mandantes origen para copiar los usuarios y el resto de datos porque nos puede llegar a interesar crear un mandante con los datos de uno pero con los usuarios definidos en otro. Si no estamos seguros de si el tama˜ no actual de nuestra base de datos soportará el aumento debido a la creación de un nuevo mandante deberemos lanzar el proceso en modo test y comprobar en el log si tenemos suficiente espacio libre en la base de datos o si por el contrario debemos aumentarla como paso previo a una copia de mandante. Si no realizamos el proceso en modo test y la copia se cancela por falta de espacio, no sólo tendremos un mandante creado a medias sino que además será imposible seguir trabajando en todo el sistema hasta que la base de datos sea extendida. Los datos a copiar se establecen en los llamados Perfiles de Copia. Al realizar la copia local se debe elegir un perfil de copia, con lo que impl´ıcitamente se estará indicando el tipo de datos a copiar. Podremos crear nuevos perfiles de copia a partir de los ya existentes. Para visualizar el contenido de cada perfil desde la transacción SCCL acudiremos al men´ u desplegable a la opción Perfil→ Visualizar Perfil . En ellos básicamente 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ólo copias locales, sólo copias remotas, sólo para export de mandantes ). Una vez elegido el perfil lo u ńico que deberemos hacer es pulsar el botón ejecutar o ejecutar en fondo. La opción ejecutar realiza el proceso de copia en diálogo con lo que el sistema no nos devuelve el control de nuestra sesión hasta que termine el proceso de copia. Esta opción es totalmente desaconsejable porque la copia tarda mucho tiempo. Se recomienda usar siempre la opción 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és de la transacción SCC3 o alternativamente por el men´ u desplegable Herramientas→ Gestión→ Gestión→ Gestión 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éticamente tabla a tabla para copiar los registros que pertenecen al mandante origen en otros tantos registros cuyo mandante será el mandante destino de la copia. El tiempo que consuma el proceso de copia dependerá fundamentalmente de los recursos del sistema, los datos elegidos a copiar en el perfil de copia, y el n´ umero de registros de los

12.2. COPIA LOCAL DE MANDANTE

Figura 12.4: Detalle de un perfil de copia

147

148

´ DE MANDANTES CAP´ITULO 12. GESTION

que se componga el mandante origen. Se deberá 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ón 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ón 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ón en el proceso de copia.

12.3.

Copia remota de mandante

Cada sistema R/3 tiene claramente definidas sus tareas; as´ı por ejemplo, desarrollo y producción 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és de la red, una copia remota es mucho más lenta que una copia local. La transacción de copia remota es SCC9 que puede ser accedida por el men´ u desplegable Herramientas→ Gestión→ Gestión→ Gestión 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á indicar un destino fuente como origen de la copia. Este destino fuente será realmente una conexión RFC, necesaria para que ambos sistemas , fuente y destino se puedan comunicar para el traspaso de datos. En la definición de este sistema lógico estará incluido el sistema origen y el mandante origen. Por las mismas razones que en la sección 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án desconectados. Será tarea del administrador lanzar la copia cuando no haya ninguna conexión al sistema o cancelar las conexiones ya existentes. En la copia remota, sólo se copian datos de tablas no las definiciones de tablas. Si se crearon tablas nuevas en el mandante origen cuyas definiciones no fueron transportadas, estas tablas no son pasadas en el proceso de copia. Se deberá 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és del programa de control de transporte tp, se realiza un export del mandante consistente en la exportación a fichero de toda la información a copiar. El export genera tres órdenes de transporte, una orden para los datos independientes de mandante, otra para los dependientes y otra para los textos espec´ıficos. Otra diferencia importante con respecto a la copia remota es que el sistema destino no tiene por qué ser accesible desde el sistema origen , como ocurr´ıa en la copia remota. Aunque el sistema destino, en este caso, no tiene por qué ser distinto del origen, este método se recomienda sólo 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ón SCC8 o a través del men´ u desplegable Herramientas→ Gestión→ Gestión→ Gestión de Mandantes→ Transporte de Mandante→ Export de Mandante. En este caso, igual que en los anteriores, se deberá elegir un perfil de copia, y se podrá elegir entre ejecución real o de test as´ı como un lanzamiento del proceso de exportación en diálogo o background. Por las mismas razones que en las dos secciones anteriores se deberá elegir la ejecución en background.

150

´ DE MANDANTES CAP´ITULO 12. GESTION

Figura 12.6: Export de mandante

El sistema nos mostrará a continuación una ventana de diálogo informándonos de las tres órdenes de transporte que se van a generar: Orden generada con datos indep. de mandante: Orden generada con datos dep. de mandante: Orden generada con los textos espec´ıficos:

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

Este proceso de exportación de mandante también queda registrado en el log de copia, en la transacción SCC3. La creación de estas 3 órdenes de transporte lleva asociada la creación de ficheros a nivel de sistema operativo, con lo que tendremos como limitación de espacio para esas órdenes el asignado a la unidad donde esté establecido el directorio de transportes – en entornos Windows –, o el asignado al file system correspondiente – en entornos UNIX –. Deberemos recordar que la exportación de mandante puede llegar a crear ficheros de gran tama˜ no, dependiendo de la información asociada al mandante a exportar; por lo que un llenado del file system o de la unidad de disco asignada causará una cancelación del proceso de exportación. Una vez creadas satisfactoriamente las órdenes de transporte lo u ńico que restará será 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és la orden asociada a los datos dependientes de mandante con el programa de control de transporte tp. Como tercer paso deberemos importar los textos espec´ıficos conectándonos

12.4. TRANSPORTE DE MANDANTE

151

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

Cap´ıtulo 13 Mantenimiento de instancias 13.1.

Perfiles del sistema

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

13.1.1.

Mantenimiento de perfiles del sistema

Los parámetros activos se mantienen desde los Perfiles del Sistema. Estos perfiles son realmente 3 ficheros a nivel de sistema operativo donde se guarda toda la información técnica del sistema R/3: 1. Perfil de Inicio: El nombre es Start <n´ umero instancia> <nombre m´ aquina>. Es un perfil u ńico por instancia del sistema R/3 que contiene parámetros necesarios para el arranque de SAP en los servidores que componen el sistema. 2. Perfil por Defecto: El nombre es DEFAULT. Es un perfil u ńico por sistema R/3 que contiene parámetros globales para todo el sistema. 3. Perfil de Instancia: El nombre es <SID> <n´ umero instancia> <nombre de m´ aquina> y es un perfil u ńico por instancia del sistema R/3 con parámetros espec´ıficos de cada instancia. 153

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

154

Estos tres perfiles están almacenados a nivel de sistema operativo en tres ficheros con los nombres especificados anteriormente en el siguiente path de la instancia central: \usr\sap\<SID>\SYS\profile\ donde <SID> es el System Identification, es decir, el nombre de la base de datos del sistema R/3 que está compuesto de tres caracteres y que se establece en tiempo de instalación 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áquina distinta. Supongamos que tenemos la siguiente configuración: Nombre base de datos SAP (SID): ”P11” Nombre máquina de la instancia central: ”servr001” Identificador instancia central: ”00”(este valor de identificador para la instancia se establece en tiempo de instalación y no se puede cambiar) Nombre máquina de la instancia de aplicaciones: ”servr002” Identificador instancia aplicaciones: ”10” Los perfiles del sistema serán, en este caso, cinco: un u ńico perfil por defecto y dos perfiles de inicio y de instancia por cada una de las instancias que componen nuestro sistema: Perfil Perfil Perfil Perfil Perfil

por defecto: DEFAULT inicio instancia central: START DVEMGS00 servr001 instancia insta. central: P11 DVEBMGS00 servr001 inicio instancia aplicacl: START D10 servr002 de instancia insta. aplic.: P11 D10 servr001

Hay una herramienta en SAP para gestionar el mantenimiento de estos perfiles sin tener que bajar a nivel de sistema operativo. Esta herramienta se encuentra en la transacción RZ10, accesible por el men´ u desplegable desde Herramientas→ CCMS→ Configuración→Actualizar Perfiles. En esta transacción existen 3 niveles de gestión de perfiles, en cada uno de los niveles se muestra distinto tipo de información: Datos de gestión. En este nivel se mantiene el path completo del fichero a nivel de sistema operativo, as´ı como fechas de modificación y activación del perfil en cuestión y autor de dicha modificación y activación.

13.1. PERFILES DEL SISTEMA

Figura 13.1: Pantalla pricipal perfiles del sistema

Figura 13.2: Datos de gestiÂ´on de un perfil

155

156

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

Actualización básica . En este nivel no se permite introducir ning´ un parámetro nuevo, sólo modificación de los parámetros básicos que componen el perfil. Este nivel es especialmente importante en el caso del perfil de instancia ya que permite, de una manera muy sencilla y segura, cambiar los parámetros relativos a los bufferes y al n´ umero de colas de trabajo. Será este el perfil que debamos modificar si deseamos que una instancia o varias tengan una distribución distinta de sus colas de trabajo.

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

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

13.1. PERFILES DEL SISTEMA

157

Figura 13.4: Actualizaci´on ampliada de un perfil

13.1.2.

Importaci´ on de perfiles del sistema

La primera vez que se accede a esta herramienta desde que se instala el sistema SAP R/3, los perfiles no se encuentran disponibles desde SAP; existen sólo a nivel de sistema operativo por lo que será necesario importar dichos perfiles para que se puedan mantener desde dentro del sistema. A esta herramienta de importación se accede desde la RZ10 en la opción del men´ u desplegable Utilidades→Importar Perfil→ De servidores Activos. Una vez que ejecutemos la importación de los perfiles desde el sistema operativo, los tendremos disponibles en la transacción RZ10. Pulsando la ayuda de b´ usqueda correspondiente al campo Perfil, el sistema nos mostrará en un listado los perfiles importados.

158

13.1.3.

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

Visualizaci´ on todos los par´ ametros activos

Existen más parámetros técnicos de configuración SAP que los que aparecen en los perfiles antes indicados. Se pueden ver todos los parámetros activos en SAP ejecutando el programa RSPARAM desde la transacción SE38 (editor ABAP/4). Si un parámetro no aparece en ninguno de los tres perfiles del sistema no quiere decir que no exista, ya que puede encontrarse activo en el sistema pero no aparecer en ninguno de los tres perfiles por tener asociado su valor por defecto. Para saber si un parámetro determinado está activo en el sistema deberemos ejecutar el programa antes mencionado y comprobar si aparece en el listado. Si no aparece, esto significará que el parámetro no está activo en el sistema. Si deseamos modificar un parámetro al que sólo se puede acceder a través de la ejecución del programa RSPARAM, deberemos proceder incluyéndolo como un parámetro nuevo en cualquiera de los perfiles existentes. Si es un parámetro que debe tener un valor distinto por cada instancia o que sólo se debe activar en determinadas instancias de nuestro sistema, deberemos incluirlo en el perfil de instancia de las instancias adecuadas; si el parámetro es global para todo el sistema R/3 deberemos incluirlo una u ńica vez en el perfil por defecto (otra posibilidad menos recomendada es que se incluya en cada uno de los perfiles de instancia de las instancias que conforman nuestro sistema SAP R/3). Importante: Cualquier modificación sobre cualquiera de los perfiles de inicio y de instancia – bien sea en la modificación del valor de un parámetro o en la inclusión de un nuevo parámetro – no toman efecto hasta que la instancia en cuestión sea reiniciada. Cualquier modificación sobre el perfil por defecto no toma efecto hasta que el sistema R/3 al completo es reiniciado. Este hecho es avisado por el sistema R/3 cada vez que se procede a la modificación de cualquiera de sus tres perfiles a través de una ventana de diálogo. La modificación de los perfiles del sistema requiere de un paso más además de la grabación en s´ı de las modificaciones; este paso es la Activaci´ on del perfil. El concepto de activación o generación se encuentra presente en muchas de las aplicaciones de SAP como puede ser el mantenimiento de perfiles y autorizaciones de usuario, programación o mantenimiento de tablas, etc. . . La grabación de una modificación de tales objetos supone la creación de una nueva versión de ese objeto a nivel de SAP R/3 pero el sistema no la toma como la actual. La activación o generación de ese objeto supone, en algunos casos como los programas y tablas, la modificación real de ese objeto en la base de datos o la modificación real a nivel de sistema operativo como es el caso de la activación de los perfiles del sistema.

´ 13.2. MODOS DE OPERACION

13.1.4.

159

Par´ ametros m´ as importantes de un sistema R/3

Debido al gran n´ umero de parámetros existentes en un sistema R/3 es prácticamente imposible conocer a fondo todos ellos, sin embargo existen varios que, por su importancia en procesos básicos de administración, toman un papel muy importante. A continuación listamos algunos de los parámetros más importantes. Nombre parámetro

Valor de ejemplo Descripci´on

SAPSYSTEMNAME INSTANCE NAME SAPSYSTEM SAPGLOBALHOST rdisp/wp no dia rdisp/wp no vb rdisp/wp no vb2 rdisp/wp no enq rdisp/wp no btc rdisp/wp no spo zcsa/installed languages

US1 DVEBMGS00 00 uisabl4 6 2 1 1 2 1 DES

zcsa/system language login/system client

S 800

13.2.

Nombre de la base de datos Nombre instancia N´ umero de instancia Nombre del servidor N´ umero colas de dialogo N´ umero colas de update N´ umero colas de update2 N´ umero colas de enqueue N´ umero colas de batch N´ umero colas de spool Idiomas instalados D -alem´an, E -ingl´es- , S -espa˜ nolidioma por defecto mandante por defecto

Modos de Operaci´ on

En muchos casos será absolutamente necesario cambiar la configuración de las colas de trabajo de nuestro sistema R/3 de una forma periódica debido a exigencias de operativa de nuestra empresa. Las exigencias más comunes son la definición de más procesos de trabajo de tipo batch durante el procesamiento nocturno, que deberán ser minimizadas en cantidad durante el horario de trabajo de nuestra empresa para dar más prioridad a los procesos de diálogo. Esto nos optimizará la ejecución de jobs de carga o modificación masiva de datos que se pueden realizar sin intervención del usuario durante la noche. Esta modificación en el n´ umero de procesos de trabajo, si no dispusiéramos de la herramienta de Modos de Operaci´ on, nos llevar´ıa a tener que modificar los perfiles de instancia de cada una de las instancias que conforman nuestro sistema R/3 y reiniciar nuestro sistema cada vez que se

160

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

quisiera cambiar la configuración de los procesos de trabajo. Un Modo de Operaci´ on no es más que el n´ umero y tipo de colas de trabajo de una instancia asignados a un intervalo horario. De esta manera nos aseguraremos que nuestro sistema R/3 funcione con una configuración de procesos determinada durante un intervalo de tiempo, y además el sistema cambiará en modo on line, sin necesidad de parar el sistema, a otra configuración cuando llegue la hora de su activación. Ejemplo : Supongamos un sistema SAP formado por una u ńica instancia donde están configuradas 15 colas de trabajo. Podemos definir dos modos de operación: diurno y nocturno. En el modo de operación diurno daremos prioridad a los procesos de diálogo definiendo más procesos DIA mientras que en el nocturno daremos prioridad a los procesos en fondo definiendo más 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án por los procesos de diálogo; 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á ning´ un usuario conectado al sistema y nos deberemos asegurar que el sistema podrá gestionar sin problemas todos los jobs que haya planificados; es por ello que las colas BTC deben superar al resto de colas. No se debe reducir nunca a cero el n´ umero de colas de DIA ya que hay procesos internos de SAP que necesitan de estas colas y además, 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ón deberemos acceder a la transacción RZ04, o alternativamente por el men´ u desplegable Herramientas→ CCMS→ Configuración→ Mod Oper + Servidores .

Figura 13.5: Modos de operaci´on

En esta pantalla aparecerán los modos de operación definidos en nuestro sistema como muestra la figura 13.5. Haciendo doble click en cada una de las entradas – o posicionando el cursor en una entrada y pulsando la opción Instancias/Form.op – accederemos a una pantalla donde aparecen los siguientes campos:

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

162 Host

Nombre del servidor a nivel de sistema operativo . Servidor Nombre de la instancia instalada en el servidor anteriormente mencionado . Perfil Instancia Nombre del perfil de instancia de la instancia anteriormente mencionada. Forma Operación Modo de operación asociados a la instancia. Procesos de trabajo N´ umero y tipo de colas de trabajo de las que se compone el modo de operación 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ón definidos en nuestro sistema. Si deseamos modificar la configuración de alguno de los modos de operación definidos en el sistema, haremos doble click sobre el modo de operación deseado con lo que accederemos a la ventana de diálogo de la figura 13.6 donde podremos, con los botones ”+ ”−”, aumentar o disminuir el n´ umero de colas de un tipo determinado: 2

Figura 13.6: Distribuci´on de procesos de trabajo

La u ńica limitación que impone esta herramienta es que el total de procesos no puede cambiar. Si aumentamos el n´ umero de colas de diálogo, posicionándonos en la linea correspondiente y pulsando el botón ”+”, el

´ 13.2. MODOS DE OPERACION

163

sistema automáticamente disminuirá 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á en la misma cantidad el n´ umero de colas de diálogo. Si deseamos aumentar o disminuir el n´ umero total de colas de una o varias instancias, no podremos realizarlo a través de los modos de operación, sino que se deberá realizar a través del mantenimiento de los perfiles de instancia, con lo que el cambio no se activará realmente hasta que las instancias modificadas sean reiniciadas de nuevo. Hasta ahora hemos visto cómo crear o modificar un modo de operación, pero éste no se activa realmente hasta que no es asociado a un intervalo horario. Como u ´ltimo paso deberemos asociar los modos definidos a unas horas determinadas en la transacción SM63 o a través del men´ u desplegable Herramientas→ CCMS→ Configuración→ Planificar Modos Operación:

Figura 13.7: Pantalla principal asignaci´on horaria

En esta pantalla tenemos la posibilidad de asociar un modo de operación, bien sea normal (diario) o excepcional (válido sólo para determinados d´ıas), a un intervalo horario. Elegiremos la opción modo de operación normal y pulsaremos bien visualizar o bien modificar. En la siguiente pantalla podremos, si hemos elegido modificar, asociar el modo que deseemos a unas

164

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

horas determinadas.

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

13.3.

Grupos de logon

En sistemas SAP R/3 con m´ ultiples servidores de aplicaciones es importante distribuir la carga de trabajo tan ´optimamente como sea posible, es decir, deberemos evitar a toda costa que unos servidores de aplicaciones soporten toda la carga de trabajo debido a que un tanto por ciento muy elevado de los usuarios se hayan conectado a esas instancias y que otros se encuentren pr´acticamente sin realizar ning´ un trabajo debido a un bajo

13.3. GRUPOS DE LOGON

165

n´ umero de conexiones de usuario. Para evitar este tipo de problemas que puede afectar muy negativamente al rendimiento global del sistema se deben usar los Grupos de Logon. Un grupo de logon es un subconjunto de servidores de aplicación disponibles en nuestro sistema R/3. Cuando los usuarios se conectan al sistema R/3 deberán elegir uno de los grupos de logon definidos con lo que la conexión al sistema R/3 se produce exclusivamente a través de una de las instancias asociadas a ese grupo. De esta manera, definiendo grupos de logon para cada una de las áreas de aplicación de SAP que sean usadas por nuestra empresa, podremos conseguir un óptimo balance de carga de trabajo en los servidores SAP. La definición de grupos de logon, además, nos permite un rendimiento óptimo de los bufferes ya que los usuarios que van a realizar tareas similares se conectarán por el mismo grupo de logon con lo cual un tanto por ciento muy elevado de los programas que vayan a ser usados por un usuario que se acaba de conectar ya se encuentra en los bufferes de dichas instancias con lo que el acceso a la información es mucho más rápido. Dependiendo del tama˜ no y áreas de nuestra empresa que trabajen con SAP deberemos definir uno o varios grupos de logon por cada departamento, área de trabajo, módulos de SAP, etc . . .

13.3.1.

Gesti´ on de grupos de logon

Los grupos de logon se pueden definir en la transacción SMLG, por el men´ u desplegable Herramientas→ CCMS→ Configuración→ Grupos Acceso En esta pantalla aparecen los grupos de logon ya definidos, sus instancias asociadas y si se encuentran activos o no. Para definir un grupo nuevo pulsaremos el botón Crear Entrada . En esta ventana deberemos introducir el nombre descriptivo del grupo, que en general será 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ás lógico será dar ese mismo nombre al grupo de logon. Además del nombre descriptivo se deberá introducir la instancia por la que se conectarán los usuarios que entren por ese grupo. Podremos restringir los accesos a este grupo de logon por dirección IP, por tiempo de respuesta o por n´ umero de usuarios ya conectados. Estas restricciones, si se activan, permitirán accesos a través de dicho grupo sólo si el servidor de presentación se encuentra en el intervalo de direcciones IP inclu´ıdas, o sólo si su conexión a red es de un tiempo de respuesta menor que el especificado o si el n´ umero de usuarios conectados a este grupo no supera el máximo establecido. Una vez que se han definido los grupos de logon, cada servidor de

166

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

Figura 13.9: Pantalla principal grupos de logon

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

13.3.2.

Saplogon

A continuación veremos cómo se debe usar el programa saplogon incluido como opción de instalación del sapgui. Lo primero que deberemos hacer es ejecutar el programa que se encontrará dentro del grupo de programas instalado con el sapgui o SAP Frontend en nuestro PC, como muestra la figura 13.11. Los botones Server y Groups sirven para crear iconos de servidores de aplicaciones y grupos de logon respectivamente para el acceso a uno o varios sistemas SAP R/3. Como ya se ha explicado anteriormente, los accesos a través de iconos de servidores de aplicación nos conectan a un sistema SAP por un servidor determinado, mientras que los grupos de logon nos conectan a través de uno de los servidores que tenga asociados ese grupo, con lo cual si un servidor queda indisponible, el grupo de logon elige automáticamente otro servidor asociado. Esto redunda en una mejor gestión 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 ńico que deberemos hacer es pulsar el botón Server. En la pantalla que se muestra en la figura 13.12 deberemos elegir el sistema SAP al que nos queremos conectar. En el campo ID introduciremos el valor del SID de nuestro sistema y en message server el servidor donde está la instancia central. A continuación pulsaremos el botón 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ón Logon, el programa simplemente nos conecta al sistema indicado a través del servidor seleccionado, pero no a˜ nade la entrada al saplogon. Si pulsamos el botón Add, los servidores seleccionados son a˜ nadidos al saplogon. De manera similar podemos insertar los grupos de logon definidos en un sistema; pulsando el botón Groups del saplogon e introduciendo los valores deseados en los campos ID y message server obtendremos un listado de los grupos de logon definidos en ese sistema en la transacción SMLG. Procediendo de igual manera que con la opción Server, obtendremos el listado

168

CAP´ITULO 13. MANTENIMIENTO DE INSTANCIAS

Figura 13.11: Pantalla de saplogon

de grupos de logon. Si a˜ nadimos todos los servidores y todos los grupos de logon, obtendremos un saplogon con todos los servidores y grupos de logon definidos en nuestro sistema. Por u ´ltimo veremos las opciones New, Properties y Delete del saplogon. La opción Properties nos permite crear de una manera más rápida que la opción Server una entrada de icono de acceso a través de un servidor de aplicaciones. Para ello lo u ńico que deberemos indicar es el nombre del servidor en el campo Application Server, una descripción del icono en el campo Description y por u ´ltimo indicar el n´ umero de instancia de ese servidor – si la instancia es u ńica, el n´ umero será 00 – en el campo System Number. La opción Edit edita la entrada seleccionada, ya sea icono de servidor o de grupo, y por u ´ltimo, la opción Delete elimina la entrada del saplogon seleccionada. El programa saplogon, en definitiva, nos facilita la conexión a cualquier servidor SAP evitando que tengamos el escritorio de nuestro PC plagado de iconos de acceso a distintos servidores y/o sistemas SAP R/3.

13.3. GRUPOS DE LOGON

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

Figura 13.13: Opci´on propiedades en saplogon

169

Ap´ endice A Transacciones m´ as comunes DB02 Análisis de tablas e Índices DB14 Mostrar logs actividad SAPDBA PFCG Generador de perfiles. RZ01 Monitor para previsión de jobs RZ02 Gráfico grafos de instancias SAP RZ03 Representación,Control instancias SAP RZ04 Actualizar instancias SAP RZ06 Alerts Thresholds Maintenance RZ08 Monitor alert SAP RZ10 Actualizar parámetros perfil RZ11 Actualización parámetros de perfil RZ12 Actual.asignación grupos serv.RFC SA38 Informes ABAP SA39 SA38 para transacción parámetros SAR Actualizar códigos de transacción SAR0 Visualizar árbol de informes estánd. SARA Gestión de archivos 171

172

´ ´ COMUNES APENDICE A. TRANSACCIONES MAS

SARL Llamada de ArchiveLink Monitor SARP Reporting (Estruct.árbol): efectuar SART Visualizar árbol de informes SC38 Lanzar report remoto SC80 CATT Utilities SCAT Computer Aided Test Tool SCC1 Copia mandante - selección especial SCC3 Copia mandante Log SCC4 Gestión mandantes SCC5 Borrado de mandante SCC6 Importación de mandante SCC7 Import.mandante - tratam.posterior SCC8 Export mandante SCC9 Copia mandante remota SCCL Import.mandante - tratam.posterior SCMP Comparación vista/tablas SCPF Generar gu´ıa implem. para la empresa SCPI Interfase optimización de producción SCT1 Resumen - Imports lógicos SCU0 Comparac.Customizing SE01 Transport Organizer SE03 Workbench Organizer: Herramientas SE06 Instalar Workbench Organizer SE07 Visual.status gestión transp SE09 Workbench Organizer

173 SE10 Customizing Organizer SE11 Actualización Dictionary ABAP SE13 Parám.memoria para actual.tablas SE14 Utilities para tablas Dictionary SE15 Sistema Info Dictionary SE16 Browser de datos SE17 Visualizar tabla (general) SE30 Análisis tiempo ejecución ABAP SE37 Módulos de funciones ABAP SE38 Editor ABAP SE39 Editor Split screen Comp. report SE41 Menu Painter SE43 Actualizar men´ u de ámbito SE51 Screen Painter SE54 Generar vista tabla SE61 Docu R/3 SE63 Acceso Traducción SE80 Browser Repository SE84 Sistema Info Repository SE85 Sistema Info ABAP/4 Dictionary SE86 ABAP/4 Sistema Info SE91 Actualizar mensajes SE93 Actualizar códigos de transacción 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ón SM21 Log de sistema SM30 Llamar actualización de vistas SM31 Actualizar tablas SM35 Monitoring batch input SM36 Solicitud para proceso de fondo SM37 Resumen de jobs de fondo SM38 Transacción de gestión queue SM39 Análisis jobs SM49 Ejecución 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ón de ampliaciones SAP SMX Visualizar jobs propios ST01 Trace sistema ST22 ABAP/4 Análisis errores tiempo ejec. STAT Estad´ısticas de acceso al sistema SU01 Actualización de usuarios

175 SU01D Visualizar usuarios SU02 Actualizar perfiles de autorización SU03 Actualizar autorizaciones SU10 Modificaciones masa Maestros usuario SU12 Modificaciones masa Maestros usuario SU20 Actualizar campos de autorización SU21 Actualizar objetos de autorización SU22 Utiliz.obj.autoriz.en transacciones SU24 Verif.obj.autoriz.bajo transacciones SU53 Visualizar valores de verificación SUIM Llamada árbol report.AUTH (infosist) SUPC Perfiles para grupos actividad SUSE Actual.p.Self Upgrading Software

Ap´ endice B Recursos Web http://www.sap.com Pagina principal de SAP. La versión 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ón 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ón abiertos de los que existe uno por cada módulo de SAP R/3. Se puede descargar ficheros .zip con el historial de preguntas y respuestas de los foros mas concurridos. http://www.erpfans.com Web de la misma serie que el anterior pero mas general, con referencias a otros productos ERP como Baan, PeopleSoft, Oracle Financials, etc. http://www.sapclub.com Noticias, empleo, foros, test de conocimientos sobre el modulo BASIS, salvapantallas y fondos de escritorio con SAP como tema principal. http://www.erpsupersite.com/sap/ Noticias acerca de SAP, catálogos de libros, análisis 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ón del Simplification Group. Esta documentación incluye art´ıculos, white papers e incluso libros completos, todo ello en formato PDF. Es la mejor documentación disponible gratuitamente que existe. http://www.realtimeusa.com/sap-group/archives/ Archivos con los mensajes del grupo de noticias de SAP comp. soft-sys.business.sap. Es un grupo moderado (por lo menos no hay que sufrir el spam :-) y el contenido es interesante.

Ap´ endice C Casos reales C.1.

Autodesk, Inc.

Sector Autodesk, Inc. centra sus actividades en el desarrollo y venta de productos de software informático. 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ón del sistema SAP R/3, en una situación en la que sus sistemas de gestión no se correspond´ıan con las necesidades de la empresa, razón por la cual se necesitaba un cambio radical que se ajustara a la situación de rápido crecimiento y expansión internacional que estaba experimentando. El proyecto que se planificó para conseguir tales fines, System 2000, se basó en cinco objetivos principales: Globalización del software de aplicación de negocio: Los procesos de negocio no se deb´ıan ver limitados por limitaciones del sistema o por fronteras geográficas. La información deb´ıa fluir en tiempo real para todos los aspectos del negocio. El nuevo sistema informático deb´ıa ser capaz de soportar todos los idiomas, operaciones, as´ı como procedimientos de cálculo de impuestos espec´ıficos de cada pa´ıs en los que Autodesk ten´ıa alg´ un centro o filial. Los tiempos de los procesos de negocio se deb´ıan ser claramente reducidos. Gestión precisa de inventario. 179

´ APENDICE C. CASOS REALES

180

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

C.2.

Schweppes, S.A.

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

˜ C.3. IBM ESPANA

181

El sistema deb´ıa ser u ńico para conseguir una reducción de costes. Deb´ıa cumplir los requerimientos para la transición de milenio. Facilidad de conversión de moneda. Implantaci´ on La implantación 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ón del módulo de control de calidad (QM). En el mes de octubre se implantó el módulo de gestión de materiales (MM). En el mes de enero se implantaron los módulos de FI, CO, AM y FI-SL en el área financiera. Los módulos de ventas y vistribución (SD) y planificación de la producción (PP) quedaron implantados en junio de 1997. Infraestructura Está basada en una plataforma AIX con un SP de IBM para producción en el mismo ”frame”en el que reside el sistema de data warehouse, herramienta complementaria a SAP R/3 y con Oracle como base de datos. Asimismo, existe una máquina 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ón de las fábricas, oficinas y delegaciones. Existen otras herramientas colaterales como datawarehousing, EIS y desarrollos verticales, todas ellas perfectamente integradas con R/3 y bajo el mismo entorno cliente / servidor, de modo que todas las funcionalidades se encuentren cubiertas.

C.3.

IBM Espa˜ na

Sector IBM centra sus actividades en investigación, desarrollo y venta de productos y servicios de tecnolog´ıa de la información. El hecho que IBM opere en 164 pa´ıses en los 5 continentes supone una gran diversidad de necesidades espec´ıficas a nivel de cada pa´ıs, lo cual lleva a distintas aplicaciones y distintos procesos. Además, el operar en un mercado cada vez más multinacional impone una unificación de procesos que permita hacer negocios cross-border, as´ı como una reducción en el desarrollo

´ APENDICE C. CASOS REALES

182

y mantenimiento de miles de aplicaciones que hoy en d´ıa mantiene el negocio de IBM. Estudio de Necesidades En un estudio de necesidades, exist´ıan básicamente dos opciones, además de otras peque˜ nas firmas que se descartaron, entre otros motivos por el hecho de no ser internacionales o tener una estructura de soporte no suficiente para el proyecto que se quer´ıa abordar. Las dos opciones eran ir a SAP o desarrollar un sistema propio. IBM apostó por SAP R/3 entre otras razones: Disponer de un sistema ya desarrollado que permite unificar y simplificar los procesos a nivel internacional Por su arquitectura integrada en un entorno cliente / servidor. Su compatibilidad con aplicaciones desarrolladas en otros lenguajes e instaladas en otros entornos. Por la flexibilidad que supone respecto a tecnolog´ıas ya anticuadas. Por su estructura de soporte. Proyecto Piloto Como proyecto piloto se eligió Espa˜ na por el tama˜ no de su mercado y caracter´ısticas para la instalación de SAP R/3 a nivel internacional. En una primera fase se instalaron los módulos de ventas y distribución (SD) y gestión de materiales (MM) de la versión 3.0D. Para 1998 estaba prevista la implementación del módulo de finanzas (FI) casi en su totalidad. La división encargada de utilizar el sistema es ”Fulfilment dentro de ella básicamente el departmento de administración. La aplicación se utiliza para cubrir los siguientes procesos comerciales: 2

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

˜ C.3. IBM ESPANA

183

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

186

´ APENDICE D. GLOSARIO

Front End Término 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ón con el ordenador de manera fácil 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ándar. 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ón. IMG Implementation Guide. Transacción que contiene un árbol con cientos de transacciones de parametrización agrupadas por módulos 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ón que aegura la integrad de los datos. Modo Cada una de las seis pantallas como máximo que puede abrir un usuario desde que abre una sesión con R/3. OSS Online Service System. Servicio de atención al cliente de SAP que funciona conectándose 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ón 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ónes 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ón que trabajen con él junto con el software R/3 instalado en ellos. La identificación de un sistema SAP se denomina SAPSID o simplemente SID y es un código de tres caracteres. WBO Workbench Organizer. Herramienta para administrar las órdenes de transporte de desarrollo. WP Work process. Cada uno de los procesos que los servidores de aplicación proporcionan a SAP para gestionar las peticiones de diálogo, fondo, spool, actualización. . .

Bibliograf´ıa [1] Fundamentos de SAP R/3 – Dennis L. Prince – Anaya Multimedia – ISBN: 8441510261 http://www.anayamultimedia.es [2] SAP R/3 System Administration : The Official SAP Guide – Liane Will – Ed.Sybex – ISBN: 0782124267 http://www.amazon.com/exec/obidos/ASIN/0782124267/qid= 963220261/sr=1-64/104-9469904-0307951 [3] SAP R/3 System : A Client/Server Technology – Rudiger BuckEmden, Jurgen Galimow, Sap Ag – Addison-Wesley Pub Co – ISBN: 0201403501 http://www.amazon.com/exec/obidos/ASIN/0201403501/qid% 3D963223251/104-9469904-0307951 [4] The R/3 System Landscape - Simplification Group http://207.105.30.51/simple/sysadmin/files/Landscape-I.pdf [5] Edición 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ández Mu˜ noz, José Antonio – Osborne McGrawHill – ISBN: 8448121007 http://www.mcgrawhill.es/McGrawHill/catalogo.htm [7] System Administration Made Easy Release 4.0B - Simplification Group http://207.105.30.51/simple/sysadmin/saezindex.htm [8] Authorizations Made Easy Guide 4.0B - Simplification Group http://207.105.30.51/simple/authorization/40_pdf_files/ amez4ball.pdf

189