GESTIÓN DE SISTEMAS DE INFORMACIÓN

Transcripción

1 c GESTIÓN DE SISTEMAS DE INFORMACIÓN Universidad de Deusto - Facultad de Ingeniería Antonio Toledo Carnicero Pablo Pérez Pérez Octubre de 2004

2 c c o p y l e f t Copyright (c) 2004 Pablo Pérez Pérez y Antonio Toledo Carnicero. This work is licensed under the Creative Commons Attribution- NonCommercial-ShareAlike License. To view a copy of this license, visit 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 Comercial- Comparte Igual de Creative Commons. Para ver una copia de esta licencia visite o escriba una carta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

3 Prefacio En los últimos 10 años 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úmero 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 ú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ón 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 ú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érez completó sus estudios de licenciatura en informática en la Universidad de Deusto en el año 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 4 trabajado como analista y consultor técnico de SAP para varias empresas y formó parte durante 5 años 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ón de Sistemas de Información y la Diplomatura de Especialización en Gestión 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ño 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ón y la Diplomatura de Especialización en Gestión de Sistemas y Redes de la Universidad de Deusto.

5 Índice general Copyleft 2 1. Introducción a SAP R/ Software estándar vs. software a medida Visión general de SAP R/ Características principales Módulos Entorno de desarrollo Introducción al sapgui Pantalla de logon a SAP R/ Concepto de mandante La barra de título El menú desplegable La barra estándar de herramientas La barra de aplicaciones La pantalla principal La barra de estado Ventana de diálogo Ayudas de búsqueda Modos Concepto de transacción Opciones técnicas La pantalla status Arquitectura de un sistema R/ Introducción Servicios de base de datos Servicios de aplicación Servicios de presentación

6 6 ÍNDICE GENERAL 4. Escenarios de configuración Consideraciones generales sobre los sistemas R/ Descripción y funciones de cada sistema Sistema de desarrollo Sistema de integración Sistema de producción Mandantes Mandantes estándar Mandantes propios Comparación de escenarios Configuración con un sólo sistema (Producción) Configuración con dos sistemas (Desarrollo y Producción) Configuración con tres sistemas (Desarrollo, Integración y Producción) Monitorización de procesos y usuarios Monitorización de procesos activos Monitorización usuarios conectados Procesamiento en fondo Conceptos de procesamiento en fondo Definición de jobs Información general Hora de inicio o evento Pasos Análisis de jobs Estados de un job Operaciones sobre jobs Servicios de actualización Actualización síncrona y asíncrona Procesos de actualización V1 y V Monitorización del estado de la actualización del sistema Actualizaciones interrumpidas Entradas de bloqueo Log del sistema y análisis de dumps Conceptos del log del sistema Accediendo al log local del sistema Accediendo al log local en modo normal Accediendo al log local en modo experto

7 ÍNDICE GENERAL Leyendo el log del sistema Opciones de relectura del log del sistema Accediendo a logs remotos del sistema Concepto de dump Accediendo a los dumps del sistema Interpretando los dumps Gestión de spool Concepto de spool Instalación de una impresora Como imprimir Operaciones sobre órdenes de spool Gestión de usuarios y autorizaciones Modelo de seguridad en R/ Mantenimiento de usuarios Generador de perfiles Sistema de transporte Órdenes de transporte Clases de desarrollo Tipos de órdenes de transporte Estados de una orden de transporte y sus tareas Customizing organizer y workbench organizer Transporte manual de órdenes Log del transporte Gestión de mandantes Creación de un nuevo mandante Copia local de mandante Copia remota de mandante Transporte de mandante Mantenimiento de instancias Perfiles del sistema Mantenimiento de perfiles del sistema Importación de perfiles del sistema Visualización todos los parámetros activos Parámetros más importantes de un sistema R/ Modos de Operación Gestión de modos de operación

8 8 ÍNDICE GENERAL Grupos de logon Gestión de grupos de logon Saplogon A. Transacciones más comunes 171 B. Recursos Web 177 C. Casos reales 179 C.1. Autodesk, Inc C.2. Schweppes, S.A C.3. IBM España D. Glosario 185

9 Índice de figuras 2.1. Pantalla de entrada a SAP R/ Barra de título Barra de aplicaciones Pantalla principal Barra de estado Ventana de diálogo Ayuda de búsqueda Listado de valores posibles Icono de acceso a las opciones técnicas Menu del icono de acceso a opciones técnicas Status del sistema Capas de la estructura cliente/servidor de R/ Arquitectura abierta de R/ Esquema del funcionamiento del dispatcher Monitor de procesos de una instancia Monitor de instancias activas Monitor de sistema operativo Monitor de conexión de usuarios por instancia Lista de modos activos por usuario Información detalllada de usuario Pantalla inicial de definición de job Pantalla inicial de selección de jobs Resumen de jobs seleccionados Esquema funcionamiento actualización asíncrona Esquema funcionamiento actualización síncrona Pantalla principal monitor actualización Actualizaciones pendientes Módulos de actualización

10 10 ÍNDICE DE FIGURAS 7.6. Pantalla principal entradas de bloqueo Listado de bloqueos activos en el sistema Información detallada de un bloqueo 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úsqueda de dumps antiguos Transacción SPAD. Mantenimiento de dispositivos de salida 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 Componentes de la seguridad en R/ Pantalla inicial de la actualización de usuarios Datos de direccion del maestro de usuarios Transaccion PFCG. Mantenimiento de papeles Descripcion del papel Transacciones asignadas a un papel Asignación de valores a los objetos de autorización Asignacion de un papel a usuarios Esquema de una orden de transporte Esquema de ordenes de transporte Clase de desarrollo Esquema pasos del transporte Pantalla principal Workbench Organizer Órdenes de transporte Creación de una orden de transporte Listado de órdenes transportadas y liberadas Transporte de una orden a un sistema destino Esquema ejemplo del transporte de una orden Visualización individual de órdenes Log del transporte de una orden

11 ÍNDICE DE FIGURAS Pantalla principal de la gestión de mandantes Detalle de opciones de un mandante Copia local de un mandante Detalle de un perfil de copia Copia remota de un mandante Export de mandante Pantalla pricipal perfiles del sistema Datos de gestión de un perfil Actualización básica de un perfil Actualización ampliada de un perfil Modos de operación Distribución de procesos de trabajo Pantalla principal asignación horaria Asignación horaria a modos de operación Pantalla principal grupos de logon Pantalla detalles creación grupo logon Pantalla de saplogon Opción de selección servidor en saplogon Opción propiedades en saplogon

12

13 Capítulo 1 Introducción a SAP R/ Software estándar 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ños, 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 TI 1 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 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ón 13

14 14 CAPÍTULO 1. INTRODUCCIÓN A SAP R/3 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 Existe una red de area local que engloba a toda la planta y que opera Novell 3.11, asi como una pequeña 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ñaron para las necesidades especificas de la empresa hace unos años 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 única en los países de la CEE no pueden ser obviados por el departamento de TI. La pregunta que se plantea cualquier empresa en esta situació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 Visión general de SAP R/ Características principales Las múltiples 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ñadido a la empresa si no fuera por la integración. Las interrelaciones estrechas

15 1.2. VISIÓN GENERAL DE SAP R/3 15 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ño 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úmero 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 última tecnologías disponibles como EDI, Data Warehouse, clientes Java, comercio electrónico Para referirse a la adecuación del sistema a la necesidades del cliente se escuchará frecuentemente el termino anglosajón customizing que en castellano se traduce por parametrización. 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

16 16 CAPÍTULO 1. INTRODUCCIÓN A SAP R/ Módulos 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ón Financiera FI Financial Accounting. Reúne 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ñia (balance y cuenta de pérdidas y ganancias) en todo momento. Los submódulos que la componen son los siguientes. Control de Gestión 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úa 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ño 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

17 1.2. VISIÓN GENERAL DE SAP R/3 17 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ón 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.

18 18 CAPÍTULO 1. INTRODUCCIÓN A SAP R/3 Ventas y Distribución 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.

19 1.2. VISIÓN GENERAL DE SAP R/ 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ños 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úsqueda, 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últiples 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.

20 20 CAPÍTULO 1. INTRODUCCIÓN A SAP R/3 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ón 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... 2 Abreviatura de dynamic programs

21 Capítulo 2 Introducción 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 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üe 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 Concepto de mandante El concepto se puede definir desde 2 puntos de vista distintos pero complementarios: La Visión Lógica y la Visión Física. 21

22 22 CAPÍTULO 2. INTRODUCCIÓN AL SAPGUI Figura 2.1: Pantalla de entrada a SAP R/3 La Visión Lógica. 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ún 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ón 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

23 2.2. CONCEPTO DE MANDANTE 23 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ón 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ón 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úmero de factura:

24 24 CAPÍTULO 2. INTRODUCCIÓN AL SAPGUI Mandante Num. fáctura Descripción 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 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ú 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 El menú desplegable El menú 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ú desplegable se caracteriza por tener fijas las ú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.

25 2.5. LA BARRA ESTÁNDAR DE HERRAMIENTAS La barra estándar 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ón 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ús de ámbito. Botón Grabar Se deberá pulsar este botón cuando deseemos confirmar la grabación de los datos introducidos. Botón Back Se deberá pulsar este botón si queremos regresar a la pantalla anterior sin grabar los datos introducidos. Botón Exit

26 26 CAPÍTULO 2. INTRODUCCIÓN AL SAPGUI Se deberá pulsar este botón si queremos salir de la actual aplicación. El sistema nos devuelve a la anterior aplicación. Botón Cancel Se deberá pulsar este botón si deseamos salir de la tarea actual sin grabar. Botón 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 únicamente en pantallas donde se los datos aparezcan en formato de listado y formato de tabla. Botón Buscar Se deberá pulsar este botón si deseamos realizar una búsqueda de una cadena de caracteres en la pantalla actual. El botón de buscar estará activado únicamente en pantallas donde los datos aparezcan en formato de listado y formato de tabla. Botón Buscar Siguiente Se deberá pulsar este botón si deseamos seguir buscando la cadena de caracteres indicada en una búsqueda anterior con el botón buscar. El botón de buscar siguiente estará activado únicamente en pantallas donde los datos aparezcan en formato de listado y formato de tabla. Botones de Paginación

27 2.6. LA BARRA DE APLICACIONES 27 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 únicamente 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 y ú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 La pantalla principal Figura 2.4: Pantalla principal

28 28 CAPÍTULO 2. INTRODUCCIÓN AL SAPGUI 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 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ón, Advertencia, Error o Éxito 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úmero 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.

29 2.9. VENTANA DE DIÁLOGO Ventana de diálogo 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ún dato o la confirmación o anulación de algún 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álogo Ayudas de búsqueda 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úsqueda 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úsqueda son muy ú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ño 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:

30 30 CAPÍTULO 2. INTRODUCCIÓN AL SAPGUI Figura 2.7: Ayuda de búsqueda En una pantalla cualquiera del módulo de Gestión 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úsqueda asociada. Para ello pulsaremos su botón de ayuda de búsqueda 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 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ódulo 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ú 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ón real o sesión Esta limitación se aplica sólo a los modos, no a las conexiones físicas. Para las conexiones físicas la única limitación es la que imponga la disponibilidad de recursos en el Servidor de Presentación. Cada vez que creemos un nuevo

31 2.11. MODOS 31 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ú 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.

32 32 CAPÍTULO 2. INTRODUCCIÓN AL SAPGUI Generar una lista con los modos propios activos Indicar: /o. Salir del sistema Indicar: /nend Concepto de transacción 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ún 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ú, 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 ú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.

33 2.13. OPCIONES TÉCNICAS Opciones técnicas Las opciones técnicas del SAPGUI se encuentran en el ú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écnicas Al pinchar el boton nos aparece el menú de la figura 2.10 que tiene las siguientes opciones. Figura 2.10: Menu del icono de acceso a opciones técnicas 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 ).

34 34 CAPÍTULO 2. INTRODUCCIÓN AL SAPGUI Generar Gráfico 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ún tipo de listado. Tamaño estándar cambia la pantalla del SAPGUI a su tamaño 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 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ú 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ón 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

35 2.14. LA PANTALLA STATUS 35 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áquina y base de datos En esta ú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.

36

37 Capítulo 3 Arquitectura de un sistema R/ Introducción 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 37

38 38 CAPÍTULO 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 CPI-C SQL y ODBC OLE/DDE y RFC X.400/X.500 EDI ALE Como protocolo de comunicaciones. Como el interface de programación de más alto nivel. Funciones de aplicación pueden ser llamadas externamente. Para comunicaciones entre programas. Para acceso a los datos guardados en RDBs. Para la integración de aplicaciones de PC. Como el interface de . Para el intercambio de datos a nivel de aplicación. Para la integración on line de aplicaciones descentralizadas.

39 3.2. SERVICIOS DE BASE DE DATOS 39 Debido a su arquitectura abierta no hay prácticamente ninguna restricción 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/ 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ón 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

40 40 CAPÍTULO 3. ARQUITECTURA DE UN SISTEMA R/3 los datos más frecuentemente usados. Administración base de datos SAP SAP ha desarrollado una serie de herramientas para la administración de la base de datos; para el caso de ORACLE como RDBMS son: BRBACKUP BRRESTORE BRARCHIVE SAPDBA Herramienta para los backups online y offline de los datos de aplicación y control, así como de los logs. Herramienta para la restauración de los datos de aplicación y control, así como de los logs. Herramienta para el archivado de los logs. Herramienta que integra todas las tareas de administración de la base de datos Servicios de aplicación 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á el nombre: <SID>_DVEBMGS00_<TCP/IP Port>

41 3.3. SERVICIOS DE APLICACIÓN 41 Servicios de diálogo 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úan como interlocutores entre el usuario final y la base de datos. Servicios de actualización 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ón 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 últimos servicios corran en la misma instancia ya que interactúan 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

42 42 CAPÍTULO 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ón entre diferentes sistemas R/3 - Llamadas a funciones remotas - CPIC (Common Programming Interface for Comunications) - Conexión de sistemas externos tales como MAPI Server, sistemas EDI... Existe un servicio de gateway por instancia y se activa automáticamente sin la intervención 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

43 3.4. SERVICIOS DE PRESENTACIÓN 43 dispatcher. El dispatcher actúa 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 único dispatcher y varios procesos de trabajo Servicios de presentación Las aplicaciones de SAP R/3 han sido diseñadas siguiendo unos estándares que aseguran uniformidad, integración y ergonomicidad. Esta uniformidad se extiende a todas las partes del diseño 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ño de ésta. Menús Todas las funciones implementadas en las aplicaciones R/3 pueden ser accedidas vía menus desplegables. Estos menús 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ús 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.

44

45 Capítulo 4 Escenarios de configuración 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últiples 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 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 Gb 1 de disco duro y cada servidor de aplicaciones necesitará unos 2 Gb. Un mandante que contenga únicamente la parametrización básica ocupa unos 500 Mb, pero si le añadimos 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 45

46 46 CAPÍTULO 4. ESCENARIOS DE CONFIGURACIÓN la necesidad de espacio son el sistema de base de datos elegido, el número 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 únicamente 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 Descripción y funciones de cada sistema Atendiendo únicamente 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ño 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 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 (únicamente los que se van creando como pruebas) y a veces son inconsistentes. Debido al gran número de personas (muchas veces ajenas a la empresa) que acceden a este sistema debemos controlar, por motivos de seguridad, que nunca tenga datos reales Sistema de integración 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ódulos del sistema. También debemos probar 2 Go Live es el término inglés que se utiliza para referirse al momento en que el sistema productivo se abre a los usuarios finales para que comienzen a trabajar.

47 4.3. MANDANTES 47 conjuntamente desarrollos de distintos módulos que interactúen 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ñar a los usuarios con ejemplos casi reales como funciona el software que van a tener que utilizar. Por ú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 Sistema de producción El sistema de producción tiene una única 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 Mandantes Mandantes estándar 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ñia completo para demostraciones y formación. Las funciones de los mandantes estándar son las siguientes:

48 48 CAPÍTULO 4. ESCENARIOS DE CONFIGURACIÓN 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ún 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 Mandantes propios A partir del mandante de referencia 000 podemos crear tantos mandantes como queramos (siempre que el tamaño 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úmero asignado, esto se ha hecho para facilitar la diferenciación entre ellos. En nuestros sistemas R/3 nosotros podemos darle el número 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ño de la base de datos y empeorando el rendimiento

49 4.3. MANDANTES 49 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ños. El término ha sido libremente traducido al castellano por los autores.

50 50 CAPÍTULO 4. ESCENARIOS DE CONFIGURACIÓN Mandante 320 Maestro de parametrización. Este mandante se usa únicamente 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 único mandante propio que debe existir en el sistema productivo. Antes del arranque en productivo realizaremos aquí las cargas iniciales de datos maestros, movimientos e históricos Comparación 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 Configuración con un sólo sistema (Producción) 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.

51 4.4. COMPARACIÓN DE ESCENARIOS 51 El rendimiento de nuestra única máquina será malo ya que tendremos todos los mandantes en la misma base de datos con el aumento de tamaño de las tablas que ello implica. Conclusión 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ñosa porque en el presupuesto de un proyecto de implantación de R/3 el coste del hardware representa un porcentaje bastante pequeño 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. Únicamente se aconseja esta configuración para centros de formación o demostración del producto Configuración con dos sistemas (Desarrollo y Producción) 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

52 52 CAPÍTULO 4. ESCENARIOS DE CONFIGURACIÓN 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ón 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ño número 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ñadir un tercer sistema. En cualquier caso, es muy común ver empresas que tienen esta configuración desde hace varios años 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 Configuración con tres sistemas (Desarrollo, Integración y Producción) 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.

53 4.4. COMPARACIÓN DE ESCENARIOS 53 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úmero 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ón 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úmen 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.

54

55 Capítulo 5 Monitorización 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 Monitorización 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ú 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

56 56 CAPÍTULO 5. MONITORIZACIÓN DE PROCESOS Y USUARIOS Figura 5.1: Monitor de procesos de una instancia DIA BTC UPD UPD2 ENQ SPO para procesos de diálogo para procesos batch para procesos de actualización V1 para procesos de actualización V2 para procesos de Enqueue para procesos 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ódigo ú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. Espera Finalizado Proceso de trabajo que está actualmente gestionando peticiones de usuario. Proceso actualmente en espera de gestionar peticiones de usuario. Proceso que ha sufrido algún 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.

57 5.1. MONITORIZACIÓN DE PROCESOS ACTIVOS 57 La columna Inicio nos indica si el proceso de trabajo se reinicia cuando sufre un error para poder seguir gestionando futuras peticiones de usuario o si por el contrario, cuando una de las peticiones sufra un error el proceso se quede en status finalizado con lo cual no se reactivará 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ún error en su ejecución. Errores típicos en la ejecución de peticiones de usuario son la terminación manual de algún modo por parte del usuario. Para cambiar este valor de Sí a No o viceversa deberemos acudir a la opción del menú desplegable Proceso Reanudar trás error. La columna Error nos indica el número de errores que un proceso de trabajo ha sufrido desde que se arrancó el sistema por última vez. La columna Semáforo nos indica el número 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ón 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

58 58 CAPÍTULO 5. MONITORIZACIÓN DE PROCESOS Y USUARIOS 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ño 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ú 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ún 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 única instancia central. En la columna Servidor aparece el nombre de la instancia. En la columna Máquina aparace el nombre del servidor sobre el que está instalada la

59 5.1. MONITORIZACIÓN DE PROCESOS ACTIVOS 59 Figura 5.2: Monitor de instancias activas instancia SAP y por ú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úmero 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ú 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ú 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

60 60 CAPÍTULO 5. MONITORIZACIÓN DE PROCESOS Y USUARIOS Figura 5.3: Monitor de sistema operativo para el arranque y funcionamiento de SAP Monitorización 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 última vez algún proceso desde el modo activo asociado a la conexión física que estamos visualizando. 6. Cantidad de modos abiertos por el usuario.

61 5.2. MONITORIZACIÓN USUARIOS CONECTADOS 61 Figura 5.4: Monitor de conexión 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 última petición de información por tales modos. También tenemos la opción de borrar el modo que queramos. Con esta ú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.

62 62 CAPÍTULO 5. MONITORIZACIÓN DE PROCESOS Y USUARIOS 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 ú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ón 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

63 5.2. MONITORIZACIÓN USUARIOS CONECTADOS 63 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 única 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 único 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ú 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.

64

65 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úan online es casi nula. Esto ú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

66 66 CAPÍTULO 6. PROCESAMIENTO EN FONDO 6.2. Definición 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ón de job La definición de un job tiene tres áreas principales: Información general Hora de inicio o evento de ejecución Pasos Información 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 único, lo que significa que podemos crear varios jobs que se llamen actualizar estadísticas enero. Esto se produce porque SAP asigna un número 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ón de crear un job

67 6.2. DEFINICIÓN DE JOBS 67 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 ú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 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 ú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.

68 68 CAPÍTULO 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ú Herramientas CCMS Jobs Lanzar evento Pasos Tras definir cómo y cuándo queremos que se procese el job, por ú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 Análisis 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ú Herramientas CCMS Jobs Actualización que nos muestra la pantalla de la figura 6.2.

69 6.3. ANÁLISIS DE JOBS 69 Figura 6.2: Pantalla inicial de selección 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 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

70 70 CAPÍTULO 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ún 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 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ú Job veremos todas las operaciones posibles que podemos hacer para alterar el estado o composición de un job. Figura 6.3: Resumen de jobs seleccionados

71 6.3. ANÁLISIS DE JOBS 71 Vamos a describir alguna de las operaciones que podemos realizar sobre los procesos en fondo: Verificar status En alguna ocasiones podemos descubrir que un job que creemos que está 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ún 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ú. Liberado Previsto Para poder deshacer la liberación de un job utilizaremos esta opción. Es muy ú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ún. 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ón 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.

72 72 CAPÍTULO 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úmero de cola BTC para poder monitorizar su estado y/o rendimiento con la transacción SM51.

73 Capítulo 7 Servicios de actualización 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 Actualización 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

74 74 CAPÍTULO 7. SERVICIOS DE ACTUALIZACIÓN Figura 7.1: Esquema funcionamiento actualización 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ón síncrona Los usuarios no pueden elegir si los cambios en la base de datos se realizan

75 7.2. PROCESOS DE ACTUALIZACIÓN V1 Y V2 75 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ñiremos a la actualización asíncrona, que a la postre es la que juega un papel más importante en un sistema SAP R/ Procesos de actualización 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ún 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 Monitorización del estado de la actualización 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 mon- 1 Logical units of work o unidades lógicas de trabajo

76 76 CAPÍTULO 7. SERVICIOS DE ACTUALIZACIÓN 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ún 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ú deplegable Herramientas Gestión Monitor Actualización. Figura 7.3: Pantalla principal monitor actualización 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:

77 7.4. ACTUALIZACIONES INTERRUMPIDAS 77 Mandante Usuario Status Fecha y hora Ctdad. Reg. Servidor Por defecto aparece el mandante al que nos hemos conectado. Por defecto aparece el código de usuario con que nos hemos conectado al sistema. 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. Podremos elegir una fecha y hora mínima a partir de la cual mostrar los datos. Podremos elegir la cantidad de actualizaciones a visualizar. 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ún problema grave en la base de datos. Esta opción se encuentra en la transacción SM13, en el menú desplegable Regs. Actualización Actualización Desactivar (existe a este nivel también la opción activar) 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,

78 78 CAPÍTULO 7. SERVICIOS DE ACTUALIZACIÓN 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 Ç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 último campo tenemos el estado actual del registro de actualización.

79 7.4. ACTUALIZACIONES INTERRUMPIDAS 79 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ódulos 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ódulos de actualización 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úa 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

80 80 CAPÍTULO 7. SERVICIOS DE ACTUALIZACIÓN 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 única 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 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ún 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ú: 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.

81 7.5. ENTRADAS DE BLOQUEO 81 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

82 82 CAPÍTULO 7. SERVICIOS DE ACTUALIZACIÓN bloqueo. Figura 7.8: Información 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ún concepto ya que se podrían causar inconsistencias en la base de datos. Estas

83 7.5. ENTRADAS DE BLOQUEO 83 entradas de bloqueo se liberarán automáticamente cuando el registro de actualización interrumpida sea tratado. Terminación anormal de la conexión 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.

84

85 Capítulo 8 Log del sistema y análisis 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ño 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úmero de instancia. Central Cada servidor de aplicaciones copia las entradas del log local a un log 85

86 86 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS 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 Accediendo al log local del sistema Al log del Sistema se accede directamente por la transacción SM21 o por el menú 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ú desplegable Tratar Modo experto. Ambos modos se diferencian en que éste último da más opciones de selección Accediendo al log local en modo normal Accediendo a la transacción SM21 directamente o a través de menú 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.

87 8.1. CONCEPTOS DEL LOG DEL SISTEMA 87 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 Procesos del dispatcher Dn Procesos de trabajo, donde n = 0,...,9 o n = a,...,z. En el caso de tener más de 10 procesos de trabajo numeraremos los siguientes con las letras del abecedario. VB Actualizaciones Vn Programas de actualizazión, 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ón por tipo de mensaje, sólo

88 88 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS DE DUMPS errores, errores y advertencias y todos los mensajes. El valor por defecto es la opción todos los mensajes Accediendo al log local en modo experto Para acceder al log del sistema en modo experto deberemos acceder por el menú desplegable tal y como se ha explicado anteriormente. La pantalla visualizada es igual que la anterior con la salvedad que se dispone de más opciones de filtro como es la opción 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ón a fichero / posición: Define el segmento del fichero de log a leer. Si ya se ha leído el fichero una vez, se puede determinar

89 8.1. CONCEPTOS DEL LOG DEL SISTEMA 89 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úsqueda 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 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 N o de mensaje Texto del mensaje 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ón volvemos a la

90 90 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS DE DUMPS Figura 8.3: Contenido del log del sistema pantalla de selección, el sistema muestra tres distintas opciones para volver a visualizar la información: 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 ú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.

91 8.1. CONCEPTOS DEL LOG DEL SISTEMA 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ú 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

92 92 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS 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 únicas instancias que estan disponibles para la visualización de los logs remotos son las que componen el sistema R/3 al que estamos conectados 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 Accediendo a los dumps del sistema La transacción de los dumps es ST22; accediendo por el menú 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.

93 8.2. CONCEPTO DE DUMP 93 Figura 8.6: Pantalla principal de análisis de dumps Figura 8.7: Búsqueda de dumps antiguos

94 94 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS DE DUMPS 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 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 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 Usuario, transacción. Sección donde aparece el usuario que ha generado el dump, programa que se estaba ejecutando, transacción, idioma, etc Informaciones lugar terminación. Sección donde se especifica la linea del programa donde se ha producido el error.

95 8.2. CONCEPTO DE DUMP 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.

96 96 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS DE DUMPS 19. ABAP/4 Bloques control CONT. Sección con información complementaria a la de la seccion 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ón SYNTAX_ERROR ocurrido el a 04:10: Syntax error in program "AQ99HA==========CAND1========= " > Qué sucedió? 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é se puede hacer?

97 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álisis 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 A suitable hardcopy printout of the system log. To obtain this, call the system log with Transaction SM21 and select the "Print" function to print out the relevant part. 3. If the programs are your own programs or modified SAP programs,

98 98 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS 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 RSINCL 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... "prodsap1" Network address... " " Operating system... "AIX" Release... "3" Hardware type... " C00" Database server... "sa3dbh2r" Database type... "ORACLE" Database name... "SP1" Database owner... "SAPR3" Character set... "es_es.iso8859-1" SAP kernel... "40B" Created on... "Nov :44:15" Created in... "AIX C00" Database version... "ORACLE " Patch level... "542" Patch text... " " Supported environment... Database... "ORACLE 8" SAP database version... "40B" Operating system... "AIX 2, AIX 1, AIX 3" Usuario, transacción...

99 8.2. CONCEPTO DE DUMP Client User... "116665u" Language key... "S" Transaction... " " Program... "AQ99HA==========CAND1========= " Screen... "SAPMSSY0 1000" Screen line Informaciones lugar terminación 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 Contenido... Campo SY Contenido SY-SUBRC 0 SY-INDEX 0 SY-TABIX 0 SY-DBCNT 0 SY-FDPOS 0 SY-LSIND 0 SY-PAGNO 0 SY-LINNO 1 SY-COLNO Variables seleccionadas No existe ninguna información en el dump.

100 100 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS DE DUMPS Llamadas / Eventos activos N o Tipo Nombre Programa Include Línea ???????????? 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 0x ab_run at 0x104eda34 dynpmcal at 0x104d62cc dynppai0 at 0x104d7aec dynprctl at 0x104d8cd0 dynpen00 at 0x104c0f30 Thdynpen00 at 0x100b4f14 TskhLoop at 0x100b9d7c

101 8.2. CONCEPTO DE DUMP 101 tskhstart at 0x100c2404 DpMain at 0x10016bb4 main at 0x100011fc Lista programas ABAP involucrados No existe ninguna información en el dump Lista tablas internas No existe ninguna información en el dump Directorio tablas aplicación (contenidos) Programa Nombre... Cont Directorio ámbitos datos (info gestión) Programa N o.. Nombre... Long Ofsg Tipo Next Fecha gen. H.gen not assigned 0 0 INVL 0 1 /%_LISTTABLES COMM 0 2 global stack GLST Directorio ámbitos datos (contenidos)

102 102 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS DE DUMPS Programa N o.. Nombre... Cont ? 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 ABAP/4 Bloques control CONT No existe ninguna información en el dump Fin análisis error tiempo ejecución

103 Capítulo 9 Gestión 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 Instalación 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ón 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 104 CAPÍTULO 9. GESTIÓN DE SPOOL Figura 9.1: Transacción 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ún. 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ún 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

105 9.2. INSTALACIÓN DE UNA IMPRESORA 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 útil rellenarlo cuando disponemos de salas separadas para las impresoras a las que hay que dirigirse para recoger la salida del spool. Por último, pasamos a la pestaña 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.

106 106 CAPÍTULO 9. GESTIÓN DE SPOOL 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 listado 1. Este es el único 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á ú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érico de dispositivo de salida.

107 9.3. COMO IMPRIMIR 107 Figura 9.4: Ventana de diálogo para imprimir un listado

108 108 CAPÍTULO 9. GESTIÓN DE SPOOL 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 Operaciones sobre órdenes 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 ú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ña 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 para conseguir un listado con letra más grande y en vertical y volveremos a repetir la salida de la orden.

109 9.4. OPERACIONES SOBRE ÓRDENES DE SPOOL 109 Figura 9.5: Transacción SP01. Selección de órdenes de spool Figura 9.6: Transacción SP01. Listado de órdenes de spool

110 110 CAPÍTULO 9. GESTIÓN DE SPOOL Una de las labores del administrador consiste en asegurarse que las ó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ás de n días almacenado. Figura 9.7: Atributos de una orden de spool

111 Capítulo 10 Gestión de usuarios y autorizaciones 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 112 CAPÍTULO 10. GESTIÓN DE USUARIOS Y AUTORIZACIONES 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 único 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

113 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 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 única forma de asignar las dos autorizaciones del ejemplo anterior es incluirlas en un perfil que llamaremos CONTABLE e incluir este perfil en los usuarios. Grupos de actividad. Son las agrupaciones de transacciones y actividades que se crean con el generador de perfiles. Estos grupos de actividad contienen internamente perfiles (que a su vez contienen autorizaciones) y se asignan directamente a los usuarios. Usuarios. Para que un empleado tenga acceso a los datos de gestió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 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ú 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ñas que componen el registro maestro de un usuario. Estas son: Dirección. 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 114 CAPÍTULO 10. GESTIÓN DE USUARIOS Y AUTORIZACIONES Figura 10.2: Pantalla inicial de la actualización 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ña definimos el menú 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 última opción, junto con la del uso horario, es vital para empresas multinacionales que tienen empleados en diversos países. Parámetros. 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 ú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 papeles y perfiles. Las operaciones a las que esta autorizado un usuario vienen determinadas por los valores que le ponemos en estas dos pestañas. Al asignarles un papel le estamos añadienlo 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

115 10.2. MANTENIMIENTO DE USUARIOS 115 Figura 10.3: Datos de direccion del maestro de usuarios

116 116 CAPÍTULO 10. GESTIÓN DE USUARIOS Y AUTORIZACIONES número enorme de usuarios debemos agruparlos asignándoles la pertenencia a uno o varios grupos. De esta manera podemos autorizar a diversos administradores a gestionar los usuarios que pertenezcan a determinados grupos 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últiples 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úsqueda 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 Figura 10.4: Transaccion PFCG. Mantenimiento de papeles

117 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ñas. 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ña menú (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ún 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ña Autorizaciones. Son cuatros los objetos de la gestión financiera los que chequea esta transacción

118 118 CAPÍTULO 10. GESTIÓN DE USUARIOS Y AUTORIZACIONES 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 último, despúes 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ñas menú 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.

119 10.3. GENERADOR DE PERFILES 119 Figura 10.7: Asignación de valores a los objetos de autorización Figura 10.8: Asignacion de un papel a usuarios

120

121 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 Órdenes 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 único 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

122 122 CAPÍTULO 11. SISTEMA DE TRANSPORTE Cuando se crea o modifica un objeto en el sistema de desarrollo, el sistema propone un código único 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úmero secuencial que irá creciendo desde hasta 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 única 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 D10K y D10K 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

123 11.1. ÓRDENES DE TRANSPORTE 123 Figura 11.1: Esquema de una orden de transporte Figura 11.2: Esquema de ordenes de transporte

124 124 CAPÍTULO 11. SISTEMA DE TRANSPORTE labor de gestión de las órdenes de transporte; tampoco se deberá asignar una única orden de transporte a todos los objetos que vayamos a crear o modificar ya que ello puede llegar a hacer inmanejable la orden debido a su tamaño. 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 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úsqueda, 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ún 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 Tipos de órdenes 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: Órdenes 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

125 11.3. TIPOS DE ÓRDENES 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ón 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. Órdenes de modificación 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 126 CAPÍTULO 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

127 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ño 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> 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 128 CAPÍTULO 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.

129 11.5. CUSTOMIZING ORGANIZER Y WORKBENCH ORGANIZER 129 Figura 11.6: Órdenes 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 ú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 única orden, si así lo considera oportuno, y crea una tarea asociada a esa orden por cada desarrollador involucrado en el proyecto asignando la propiedad de cada tarea a cada uno de los desarrolladores. De esta manera, cada desarrollador irá asignando sus objetos a su tarea con lo que no se

130 130 CAPÍTULO 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 útil para eliminar tareas con estatus modificable de órdenes, la única 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 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 única 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

131 11.6. TRANSPORTE MANUAL DE ÓRDENES 131 Figura 11.7: Creación de una orden de transporte creamos un nuevo objeto de desarrollo. El sistema nos pide asignarle una orden ya creada o crear una nueva Transporte manual de órdenes 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).

132 132 CAPÍTULO 11. SISTEMA DE TRANSPORTE 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ñadidas 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

133 11.6. TRANSPORTE MANUAL DE ÓRDENES 133 mencionado antes: tp showbuffer <SID> Nos muestra el listado de órdenes incluídas en el buffer. En lo que sigue, <SID> se refiere al nombre del sistema destino del tranporte. Las órdenes que ya han sido transportadas al sistema destino aparecen con el texto already imported. Figura 11.8: Listado de órdenes 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 134 CAPÍTULO 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ñade 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ñadida 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

135 11.6. TRANSPORTE MANUAL DE ÓRDENES 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 136 CAPÍTULO 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 D10K 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 D D10 y K 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 D10K se encuentra en el buffer; si acaba de ser liberada, aparecerá la ú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 D10K 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 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ún 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úmero 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.

137 11.7. LOG DEL TRANSPORTE 137 Figura 11.11: Visualización individual de órdenes 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úmero 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 138 CAPÍTULO 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ñadirla manualmente de nuevo al buffer.

139 Capítulo 12 Gestión 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 último sólo existe en el mandante 066). 139

140 140 CAPÍTULO 12. GESTIÓN DE MANDANTES Creación de un nuevo mandante Los mandantes estándar bajo ningún 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ú 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ña 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

141 12.1. CREACIÓN DE UN NUEVO MANDANTE 141 Figura 12.1: Pantalla principal de la gestión 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ón automática 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 142 CAPÍTULO 12. GESTIÓN DE MANDANTES Figura 12.2: Detalle de opciones de un mandante

143 12.1. CREACIÓN DE UN NUEVO MANDANTE 143 Grabación automática 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ón 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ón 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ón 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

144 144 CAPÍTULO 12. GESTIÓN DE MANDANTES productivos protegidos contra copias intencionadas o no de mandante. Veamos los distintos niveles de protección: Nivel Protección 0: No hay restricciones protección. En este nivel no existe Nivel Protección 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ón 2: No se permite sobrescritura ni comparación 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 ú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ón 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

145 12.2. COPIA LOCAL DE MANDANTE 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 único usuario disponible en un mandante recién creado y sin ningún 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 146 CAPÍTULO 12. GESTIÓN DE MANDANTES de datos, el mandante origen de copia de datos de maestros de usuario y si el proceso corre en modo test o real. El sistema permite elegir distintos mandantes origen para copiar los usuarios y el resto de datos porque nos puede llegar a interesar crear un mandante con los datos de uno pero con los usuarios definidos en otro. Si no estamos seguros de si el tamaño 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ú 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 único 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ú 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úmero de registros de los

147 12.2. COPIA LOCAL DE MANDANTE 147 Figura 12.4: Detalle de un perfil de copia

148 148 CAPÍTULO 12. GESTIÓN DE MANDANTES 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ún usuario conectado al mandante origen ni al destino y tampoco debe haber ningún proceso batch corriendo aparte del propio proceso de copia. De otra manera se podría provocar una cancelación en el proceso de copia 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ú desplegable Herramientas Gestión Gestión Gestión de Mandantes Copia de mandante Copia remota. Figura 12.5: Copia remota de un mandante

149 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 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ú 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 150 CAPÍTULO 12. GESTIÓN DE MANDANTES 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: <SID>KO(N o secuencial) Orden generada con datos dep. de mandante: <SID>KT(N o secuencial) Orden generada con los textos específicos: <SID>SX(N o 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ño, 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 único 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

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

152

153 Capítulo 13 Mantenimiento de instancias 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ño de bufferes, idioma de conexión por defecto, mandante de conexión por defecto, tiempo de expiración de passwords, número intentos fallidos de conexión para bloquear usuario, etc 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úmero instancia> <nombre máquina>. Es un perfil único 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 único por sistema R/3 que contiene parámetros globales para todo el sistema. 3. Perfil de Instancia: El nombre es <SID> <número instancia> <nombre de máquina> y es un perfil único por instancia del sistema R/3 con parámetros específicos de cada instancia. 153

154 154 CAPÍTULO 13. MANTENIMIENTO DE INSTANCIAS 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 único perfil por defecto y dos perfiles de inicio y de instancia por cada una de las instancias que componen nuestro sistema: Perfil por defecto: Perfil inicio instancia central: Perfil instancia insta. central: Perfil inicio instancia aplicacl: Perfil de instancia insta. aplic.: DEFAULT START DVEMGS00 servr001 P11 DVEBMGS00 servr001 START D10 servr002 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ú 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.

155 13.1. PERFILES DEL SISTEMA 155 Figura 13.1: Pantalla pricipal perfiles del sistema Figura 13.2: Datos de gestión de un perfil

156 156 CAPÍTULO 13. MANTENIMIENTO DE INSTANCIAS Actualización básica. En este nivel no se permite introducir ningún 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úmero 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ón básica 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.

157 13.1. PERFILES DEL SISTEMA 157 Figura 13.4: Actualización ampliada de un perfil Importación 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ú 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úsqueda correspondiente al campo Perfil, el sistema nos mostrará en un listado los perfiles importados.

158 158 CAPÍTULO 13. MANTENIMIENTO DE INSTANCIAS Visualización todos los parámetros 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 única vez en el perfil por defecto (otra posibilidad menos recomendada es que se incluya en cada uno de los perfiles de instancia de las instancias que conforman nuestro sistema SAP R/3). Importante: Cualquier modificació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ón 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.

159 13.2. MODOS DE OPERACIÓN Parámetros más importantes de un sistema R/3 Debido al gran número 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ón SAPSYSTEMNAME US1 Nombre de la base de datos INSTANCE NAME DVEBMGS00 Nombre instancia SAPSYSTEM 00 Número de instancia SAPGLOBALHOST uisabl4 Nombre del servidor rdisp/wp no dia 6 Número colas de dialogo rdisp/wp no vb 2 Número colas de update rdisp/wp no vb2 1 Número colas de update2 rdisp/wp no enq 1 Número colas de enqueue rdisp/wp no btc 2 Número colas de batch rdisp/wp no spo 1 Número colas de spool zcsa/installed languages DES Idiomas instalados D -alemán-, E -inglés-, S -españolzcsa/system language S idioma por defecto login/system client 800 mandante por defecto Modos de Operación 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úmero de procesos de trabajo, si no dispusiéramos de la herramienta de Modos de Operación, 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 160 CAPÍTULO 13. MANTENIMIENTO DE INSTANCIAS quisiera cambiar la configuración de los procesos de trabajo. Un Modo de Operación no es más que el número 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 única 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 Formado por activo de las 8.00 am hasta las 8.00 pm 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 Formado por activo de las 8.00 pm hasta las 8.00 am 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ún 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úmero 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

161 13.2. MODOS DE OPERACIÓN 161 las conexiones de los usuarios al sistema se gestionan a través de procesos DIA Gestión de modos de operación Para crear modos de operación deberemos acceder a la transacción RZ04, o alternativamente por el menú desplegable Herramientas CCMS Configuración Mod Oper + Servidores. Figura 13.5: Modos de operación En esta pantalla aparecerán los modos de operación definidos en nuestro sistema como muestra la figura 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:

162 162 CAPÍTULO 13. MANTENIMIENTO DE INSTANCIAS Host Servidor Perfil Instancia Forma Operación Procesos de trabajo Nombre del servidor a nivel de sistema operativo. Nombre de la instancia instalada en el servidor anteriormente mencionado. Nombre del perfil de instancia de la instancia anteriormente mencionada. Modo de operación asociados a la instancia. Número 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úmero de colas de un tipo determinado: 2 Figura 13.6: Distribución de procesos de trabajo La única limitación que impone esta herramienta es que el total de procesos no puede cambiar. Si aumentamos el número de colas de diálogo, posicionándonos en la linea correspondiente y pulsando el botón +, el

163 13.2. MODOS DE OPERACIÓN 163 sistema automáticamente disminuirá en la misma cantidad el número de colas de fondo, y viceversa, si aumentamos en una cantidad el número de colas de fondo el sistema disminuirá en la misma cantidad el número de colas de diálogo. Si deseamos aumentar o disminuir el número 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 último paso deberemos asociar los modos definidos a unas horas determinadas en la transacción SM63 o a través del menú desplegable Herramientas CCMS Configuración Planificar Modos Operación: Figura 13.7: Pantalla principal asignación 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 164 CAPÍTULO 13. MANTENIMIENTO DE INSTANCIAS horas determinadas. Figura 13.8: Asignación horaria a modos de operación Grupos de logon En sistemas SAP R/3 con múltiples servidores de aplicaciones es importante distribuir la carga de trabajo tan óptimamente 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ácticamente sin realizar ningún trabajo debido a un bajo

165 13.3. GRUPOS DE LOGON 165 número 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ño 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 Gestión de grupos de logon Los grupos de logon se pueden definir en la transacción SMLG, por el menú 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úmero 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úmero 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 166 CAPÍTULO 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 único icono de conexión a SAP para todos los sistemas SAP y grupos de logon de los que dispongamos 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 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

167 13.3. GRUPOS DE LOGON 167 Figura 13.10: Pantalla detalles creación grupo logon sistema, lo único que deberemos hacer es pulsar el botón Server. En la pantalla que se muestra en la figura 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ñade la entrada al saplogon. Si pulsamos el botón Add, los servidores seleccionados son añadidos 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 168 CAPÍTULO 13. MANTENIMIENTO DE INSTANCIAS Figura 13.11: Pantalla de saplogon de grupos de logon. Si añadimos 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 ú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 único que deberemos indicar es el nombre del servidor en el campo Application Server, una descripción del icono en el campo Description y por último indicar el número de instancia de ese servidor si la instancia es única, el número 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 ú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.

169 13.3. GRUPOS DE LOGON 169 Figura 13.12: Opción de selección servidor en saplogon Figura 13.13: Opción propiedades en saplogon