Introducción a SAP

Lección 1: Qué es SAP?

¿Qué es SAP? SAP es una empresa con sede en Alemania creada en el año 1972. Es junto con Oracle una de las más grandes en la venta de software empresarial. Actualmente la mayoría de las grandes corporaciones utilizan para el manejo de sus negocios alguna implementación de SAP, lo que asegura un gran futuro de SAP dentro de las empresas a largo plazo. Su logro actual es que también están implementando su software en empresas de pequeña y mediana envergadura (PyMEs) de la mano de productos como SAP Business One.

SAP Software Su nombre corresponde a las iniciales de las siglas Sistemas, Aplicaciones y Productos. SAP actualmente tiene una amplia gama de productos, entre los que se destacan los siguientes: SAP R/3 (ahora llamado SAP ECC - Enterprise Central Components) es lo que se llama un sistema ERP (Enterprise Resource Planning) que resumiendo es un sistema que abarca todas las unidades centrales del negocio de una empresa. Entre estas están la facturación, las ventas, la logística, las finanzas, entre otras las cuales se conocen como módulos. La ventaja que tiene este tipo de sistemas es que integran todas estas actividades en un sólo programa, por lo tanto todo se mantiene relacionado, favoreciendo la interacción de las diferentes áreas. Una característica importante es que SAP R/3 proporciona la oportunidad de sustituir un gran número de sistemas independientes, que se han desarrollado e instalado en organizaciones ya establecidas, por un solo sistema modular.

Como referencia, nombramos los módulos que contiene SAP R/3: FI: Contabilidad Financiera CO: Controlling IM: Inversiones TR: Tesorería LO: Gestión de datos de logística EC: Enterprise controlling MM: Gestión de materiales

Figura 1 - Módulos de R/3 SD: Gestión de Ventas PS: Gestión de Proyectos QM: Gestión de la Calidad PP: Planeamiento de Producción HR: Gestión de Recursos Humanos PM: Gestión de Mantenimiento

Existen también otras herramientas de SAP entre las que se destacan:

SAP CRM: Manejo de las relaciones con los clientes. SAP SRM: Manejo de las relaciones con los proveedores. SAP PLM: Manejo integral de productos. SAP SCM: Manejo de logística y demanda. SAP Netweaver: esta es una aplicación abierta de integración para todas las

demás aplicaciones de SAP y algunas de terceros también.

Figura 2 - SAP Netweaver

Lección 2: Aplicaciones y Componentes de SAP

Productos SAP a la medida de la compañía

En los últimos años SAP ofrece un abanico de productos para empresas u organizaciones de todos los tamaños. Estos se caracterizan principalmente por su escalabilidad asegurando de que puedan ajustarse a la talla de cada compañía y también se adapten a los constantes cambios en los procesos de la misma.

Figura 3 – Diferentes tamaños, diferentes productos.

SAP Business One: es una aplicación de ERP con una interfaz similar a la de Windows, la cual ha sido desarrollada específicamente para pequeñas y medianas compañías. Este software permite gestionar las áreas más importantes del negocio en una aplicación simple e integrada.

Esta solución es ideal para compañías con menos de 100 empleados y hasta 30 usuarios y necesiten un sistema a su alcance económico y que pueda cubrir los procesos centrales (core) tales como financieros, ventas, servicios al cliente y operaciones.

SAP Business by Design: esta es la última solución desarrollada por SAP para las pequeñas y medianas compañías de 100 a 500 empleados que quieran administrar y mejorar sus procesos centrales financieros, de recursos humanos, proyectos, abastecimiento, etc. Está enfocado principalmente a las empresas medianas que aún no utilizan software de negocio integrado.

Ofrece protocolos de comunicación estándar tal como los Web Services que permite la interacción entre diferentes aplicaciones (A2A) y sistemas (B2B).

SAP Buiness All-In-One: es la solución ideal para aquellas empresas de mediana escala con requerimientos muy específicos de la industria a la que pertenecen y con varias divisiones y una infraestructura de IT madura. Este software está basado en un SAP ERP. Está pensado para una implementación rápida utilizando escenarios ya pre-configurados basados en las mejores prácticas del mercado en las que se encuentran

estas industrias.

Aplicaciones SAP

Si bien la aplicación más conocida, o bien con la cual SAP pudo expandirse mundialmente es SAP R/3, hoy existe un conjunto de aplicaciones las cuales pueden licenciarse de manera conjunta o por separado.

SAP Business Suite: esta es la familia de aplicaciones de negocio que se compone de diferentes productos los cuales dan soporte a todos los procesos de una compañía.

SAP Business Suite provee:

Un completo espectro de soluciones de negocio

Una infraestructura abierta y flexible con años de madurez y solidez

Componentes adaptables a los requerimientos de negocio

Numerosas funciones específicas de la industria

Figura 4 – SAP Business Suite

Las nuevas funciones para la suite de SAP se obtienen hoy con los enhancement packages.

Componentes de Software

Numerosas aplicaciones son provistas dentro del conjunto del SAP Business Suite. Estas aplicaciones, en muchos casos, requieren de las mismas funciones en algunas de sus sub áreas. Por lo tanto diferentes aplicaciones contienen componentes de software similares. Por esto podemos decir que un componente de software es la unidad más pequeña, instalable y que puede ser mantenida.

Lección 3: SAP Netweaver.

Concepto de SAP Netweaver

La plataforma tecnológica de SAP Netweaver está diseñada para poder introducir de manera paulatina y flexible los procesos más importantes de una compañía ya que nos proporciona a un alto nivel las funciones necesarias y los estándares de la industria para integración. De esta manera podemos definir a SAP Netweaver como la base técnica del SAP Business Suite.

SAP Netweaver nos permite integrar y conectar gente, información y procesos de negocio a través de diferentes tecnologías permitiendo ajustarse rápidamente a los cambios que puedan surgir en una compañía. De esta manera la integración está unificada en una única plataforma lo que facilita que no tenga que ser desarrollada por cada cliente.

Prácticas y Escenarios IT

SAP Netweaver permite implementar procesos de IT dentro de un rango de soluciones denominados prácticas de IT. Para cada una de estas prácticas SAP Netweaver soporta un rango de actividades claves las cuales se pueden realizar con los componentes integrados en la plataforma de SAP Netweaver.

Esto nos permite que los objetivos de cada compañía puedan alcanzarse en proyectos individuales y manejables, o sea, en pasos secuenciales de acuerdo a la importancia de cada uno.

Para cada práctica de IT SAP Netweaver provee los escenarios correspondientes que sirven como guías de implementación.

Figura 5 - Escenarios y Prácticas de IT

En conclusión, los escenarios de IT nos brindan una ayuda al momento de la instalación, configuración y operación de SAP Netweaver.

Las capas de SAP Netweaver

SAP Netweaver está dividido en cuatro capas de integración que consisten cada una de funciones centrales:

Integración de Gente (People Integration): permite que los usuarios de diferentes aplicaciones tengan acceso a la información y funciones que necesitan de manera rápida y eficiente en una interfaz concentrada. Dentro de esta capa encontramos principalmente la aplicación SAP Netweaver Portal que provee funciones más importantes en este contexto.

Figura 6 - SAP Netweaver Portal

Integración de la Información (Information Integration): esta capa provee el acceso a toda la información de la compañía ya sea estructurada o no lo que significa que es información que fue generada por un sistema no-SAP. Las principales áreas de integración de información están formadas por SAP Netweaver Business Intelligence (BI) y SAP Netweaver Master Data que permite gestionar de manera central los datos maestros de la compañía.

Figura 7 - SAP Netweaver BI

Integración de procesos (Process Integration): esta es la capa que se encarga de comunicar las aplicaciones de nuestra compañía (o fuera de ella también) en ambientes heterogéneos. SAP Netweaver Process Integration (PI) juega un rol fundamental aquí para conectar los sistemas SAP y no-SAP utilizando diferentes

estándares de comunicación.

Figura 8 - SAP Netweaver PI

Plataforma de Aplicación (Application Platform): El Servidor de Aplicación SAP NetWeaver, denominado comúnmente como SAP Netweaver AS, por sus siglas en inglés provee la infraestructura para la operación de las aplicaciones de negocio que están basadas sobre las tecnologías J2EE o ABAP. Adicionalmente los estándares abiertos, acceso a aplicaciones web y servicios web completan la plataforma de aplicación.

En conclusión el SAP Netweaver AS es el entorno de ejecución para las aplicaciones de nuestras aplicaciones SAP. Las herramientas necesarias para el desarrollo de nuestras propias aplicaciones también están incluidas dentro del mismo.

Figura 9 - SAP Netweaver AS

Plataforma del sistema SAP

Lección 1: Arquitectura del SAP Netweaver AS

Arquitectura del SAP Netweaver AS

La mayoría de los sistemas SAP están basados sobre un servidor de aplicación Netweaver como entorno de ejecución, junto con la base de datos, el SAP Netweaver AS es la plataforma de aplicación de SAP Netweaver.

Figura 10 – SAP Netweaver AS

La evolución de la tecnología del servidor de aplicación SAP, antes conocido como SAP Basis es lo que hoy representa el servidor de aplicación Netweaver donde las aplicaciones web tienen una especial relevancia.

¿Qué características tiene el SAP Netweaver AS?

Un entorno confiable y comprobado de ejecución el cual es continuamente desarrollado y mejorado.

Un framework de ejecución de procesos complejos de negocio que cumple con los estándares de seguridad más altos.

Un ambiente de desarrollo integrado y de fácil utilización.

Soporta estándares abiertos incluyendo HTTPS, HTTP, SMTP, WebDAV, SOAP, SSL, SSO, X.509, Unicode, HTML, XML y WML.

Alta escalabilidad

Soporta diferentes bases de datos y sistemas operativos (multiplataforma).

Arquitectura principal del SAP Netweaver AS

Durante la implementación de un sistema SAP deberemos decidir la arquitectura de nuestro sistema SAP y cómo distribuir los procesos en el hardware que tengamos disponible. Las aplicaciones que ejecutaremos deben ser implementadas de manera independiente del hardware, sistema operativo y base de datos que utilicemos. Para esto el SAP Netweaver AS provee dos ambientes de ejecución: ABAP y JAVA.

Cliente – Servidor

En una definición orientada al hardware cuando nos referimos a una configuración cliente-servidor este último provee en una red datos, memoria y otros recursos a las estaciones de trabajo (workstations).

En una visión orientada a software, el cliente y el servidor son ambos definidos a nivel de procesos (servicios).

En este contexto un servicio es provisto por un componente de software que puede consistir en un proceso o un grupo de procesos, tal como lo es un Servidor de Aplicación Web SAP (SAP Web AS) y es un servidor para ese servicio específico. Los componentes de software que usan ese servicio son los clientes.

Al mismo tiempo, un cliente puede comportarse como servidor para otros servicios específicos. La siguiente imagen puede clarificar un poco más los conceptos:

Figura 11 – Dos definiciones de Cliente-Servidor

Configuración Cliente-Servidor de Sistemas SAP

En un sistema de software de negocios generalmente encontraremos los siguientes procesos:

Procesos de presentación (por ejemplo para presentar las pantallas) Procesos de aplicación (por ejemplo, para ejecutar los programas de aplicación) Procesos de base de datos (por ejemplo, para gestionar y organizar los datos de

la base)

En la implementación de un sistema SAP la configuración de estos procesos puede resultar single-tier o multi-tier dependiendo del número de capas de hardware utilizadas. El sistema SAP ECC es un ejemplo de software de aplicación de negocios.

Figura 12 – Configuraciones Cliente-Servidor.

Conformación de un sistema SAP

En muchas ocasiones debemos referirnos a los componentes de la infraestructura de SAP y vamos a ver ahora como está conformado un sistema SAP. Los elementos que conforman un sistema SAP son los que se muestran en la siguiente imagen: Figura 13– Componentes de un sistema SAP, una base de datos y una o más instancias.

La instancia que junto con la base de datos constituyen un sistema funcional se denomina instancia central. En cada sistema SAP encontraremos una instancia central. Si el sistema está configurado solo con la instancia central y esta corre en el mismo servidor donde se encuentra la base de datos entonces nos encontramos frente a un sistema central.

Figura 13 – Componentes de un sistema SAP

Es posible instalar más de una instancia de un mismo sistema o de diferentes sistemas en un mismo servidor. Así también como más de un sistema (base datos e instancia central) en un mismo servidor si contamos con suficiente hardware para esto.

Un sistema SAP se identifica con tres caracteres (System ID: SID). El conjunto de sistemas SAP de un mismo producto (Ej: ECC) se referencia como landscape, aunque esto no es exclusivo de SAP. En una empresa u organización dentro de un landscape SAP cada SID es único y no debe repetirse.

¿Qué es una instancia SAP?

Básicamente una instancia de SAP es una unidad administrativa en la que los componentes de un sistema SAP que provee uno o más servicios se encuentran combinados. Si bien ahora puede no quedar muy claro este concepto vamos a ir desarrollándolo de ahora en más.

Los servicios que ofrece una instancia de SAP pueden ser iniciados o detenidos en conjunto. Por lo tanto podemos pensar que en un sistema SAP con más de una instancia podríamos tener una de estas detenida y otra u otras funcionando al mismo tiempo. La instancia central siempre debe estar funcionando al menos para que un sistema SAP esté operativo.

En SAP el término instancia también es comúnmente referenciado como servidor de aplicación desde un punto de vista de software ya que es el entorno de ejecución para las aplicaciones de negocios de SAP.

Variantes de Servidores de Aplicación Netweaver SAP

Las instancias de los sistemas SAP pueden ser de los siguientes tipos:

Instancia basada en ABAP Instancia basada en JAVA Instancia mixta ABAP+JAVA

Estas tres variantes no pueden ser instaladas en un mismo sistema SAP. Si una instancia es JAVA pura, entonces todas las demás instancias del sistema deberán ser del mismo tipo. Las demás combinaciones son posibles. El siguiente cuadro resume estas combinaciones:

Cuadro 1 – Combinaciones posibles de instancias en un sistema SAP

Instancias ABAP

Primero nos enfocaremos en instancias puramente ABAP.

El dispatcher (despachante) de ABAP es el proceso principal de una instancia ABAP. Este proceso se encarga de iniciar otros procesos configurados en la instancia denominados work processes (procesos de trabajo), el Gateway (no se muestra en la figura 14 – Sistema SAP ABAP) y el Internet Communication Manager (ICM).

Cada instancia ABAP se configura con un perfil de instancia y cada instancia posee su propia área de memoria en el servidor donde corre así también como su propia estructura de directorio.

Figura 14– Sistema SAP ABAP

Una instancia tiene un único dispatcher y cuando levantamos una instancia el dispatcher es lo primero que inicia. Dos procesos de diálogo se requieren mínimamente por instancia, luego veremos con mayor detalle cada tipo de proceso que podemos tener en una instancia.

Cada instancia se identifica dentro de un sistema SAP por un número de dos dígitos. Por lo general en manera secuencial empezando por 00 (doble cero). Cuando instalamos el sistema tenemos la opción de elegir el número de instancia entre 00 y 97.

Cuando agregamos instancias a nuestro sistema tenemos que elegir un número que no esté utilizado si la instancia se instala en el mismo servidor que la o las anteriores. Podemos concluir entonces que cada número de instancia es único por servidor.

Si varias instancias son instaladas en un mismo servidor, cada una de ellas tendrá su propia área de memoria y su propia estructura de directorio en el sistema de archivos del servidor.

En los sistemas SAP basados en ABAP o ABAP+JAVA podemos distinguir la instancia central de las demás ya que en esta encontraremos un proceso especial denominado Message Server (Servidor de Mensajes), este proceso es único para todo nuestro sistema SAP. También la instancia central es la única que ofrece uno o más work process de enqueue (encolado).

Instancias JAVA

El dispatcher de JAVA también es el proceso central de una instancia JAVA. Este proceso, de manera similar que el dispatcher de ABAP, distribuye las solicitudes que llegan a la instancia entre los server processes (servidores de proceso) disponibles.

Figura 15 – Sistema JAVA

También en este caso cada instancia de JAVA posee un único dispatcher. Una instancia de JAVA requiere mínimamente un server process. Si instalamos más de una instancia en un servidor, cada una de estas tendrá un número de instancia diferente.

Un sistema SAP JAVA pude tener varias instancias pero solo una instancia central. En este caso, la instancia central se diferencia de las demás porque incluye un proceso adicional denominado SDM que son las siglas en inglés de Software Deployment Manager el cual se configura solo uno para todo el sistema.

A diferencia del sistema SAP ABAP, acá encontraremos como se puede observar en la figura 15 – Sistema JAVA, una instancia de Servicios Centrales (JAVA Central Services). La instancia JAVA CS proporciona el JAVA Message Server (Servidor de Mensajes) y JAVA Enqueue Server (Servidor de Encolado).

En un escenario clásico la instancia central y el JAVA CS se alojan en el mismo servidor. Instancias adicionales pueden ser instaladas en el mismo servidor donde se encuentra la instancia central o los servicios centrales.

Instancias ABAP+JAVA

Como ya podrás deducir en este tipo de instancias vamos a encontrar procesos ABAP y JAVA. Una instancia central ABAP+JAVA estará conformada por los procesos de una instancia central ABAP y los procesos de una instancia central JAVA.

Recordemos que la instancia de servicios centrales es una instancia independiente, por lo tanto no es parte de la instancia central ABAP+JAVA.

Figura 16 – Sistema ABAP+JAVA

Lección 2: Procesos del SAP Netweaver AS.

Procesos del SAP Netweaver AS

Cuando un usuario trabaja con SAP utiliza alguna de las aplicaciones que provee el producto, tal como el ECC. Esta aplicación puede haber sido diseñada en el lenguaje de programación ABAP o en JAVA. De esto se deduce que dependiendo del lenguaje con que se decidió crear la aplicación va a ser procesada por la parte de ABAP o de JAVA de nuestro servidor Netweaver SAP.

En cada una de las instancias ABAP y JAVA corren una serie de procesos en paralelo los cuales trabajan en conjunto y se comunican en algunos casos. Veamos en la siguiente figura los procesos del entorno de ejecución ABAP:

Figura 17 – Procesos del entorno de ejecución ABAP

El dispatcher de ABAP es quien se encarga de distribuir los pedidos entre los work processes. Como ya vimos antes, este proceso se encuentra en cada instancia ABAP de nuestro sistema SAP.

¿Qué tipos de work processes son los que dependen de la administración del dispatcher?

Procesos de diálogo (tipo D) Procesos de Background (tipo B) Procesos de Lock Managment (tipo E) Procesos de Update 1 y 2 (tipo V) Procesos de Spool (tipo S)

La cantidad de procesos de cada tipo que una instancia tendrá se determinan configurando el parámetro correspondiente en el perfil de la instancia. La siguiente tabla describe estos parámetros:

Tabla 1 – Parámetros de Work Processes

Veamos ahora otros procesos, que no son work processes, y que proveen servicios de comunicación interna y externa.

El Message Server (MS) maneja las comunicaciones entre los dispatchers distribuidos en todo el sistema. De esta manera se logra la escalabilidad de múltiples servidores de aplicación (instancias) en paralelo. El message server se configura sólo uno para todo el sistema SAP.

El Gateway (GW) permite la comunicación entre sistemas SAP, o entre sistemas SAP y sistemas de aplicación externos. Existe uno por dispatcher o instancia ABAP.

El Internet Communication Manager (ICM) permite la comunicación con el sistema SAP a través de protocolos web tales como HTTP. El ICM recibe los pedidos del cliente y los reenvía al sistema SAP para su posterior procesamiento.

En los sistemas mixtos ABAP+JAVA, el ICM puede reconocer si el pedido es una llamada para el AS ABAP o para el AS JAVA ya que ambos manejan aplicaciones web. Es posible configurar o no un ICM por cada servidor de aplicación.

Lección 3: Procesos de Diálogo ABAP.

PROCESOS DE DIALOGO ABAP

La capa de presentación

Los usuarios pueden loguearse al sistema SAP utilizando diferentes front ends, tal como el clásico SAP GUI el cual usaremos durante el curso pero también podrían utilizar un navegador y así trabajar con las aplicaciones de SAP que estén desarrolladas para este tipo de interfaz de usuario.

En ambos casos, los programas que conforman esas aplicaciones están desarrollados para que sean ejecutados en el entorno de ejecución ABAP de nuestro sistema SAP. Sin importar si son transacciones clásicas o aplicaciones web serán ejecutadas por el proceso de diálogo de la instancia de ABAP.

Las aplicaciones web también pueden ser desarrolladas en JAVA por lo que serían procesadas por este entorno. Cuando llega la solicitud al sistema se determina si es ABAP o JAVA y se reenvía al entorno adecuado.

Procesando solicitudes de SAP GUI

Veamos cómo funciona el procesamiento de la solicitud de un usuario, como por ejemplo el llamado a una transacción, en el servidor de aplicación ABAP. Como muestra la siguiente imagen, el procesamiento involucra diferentes procesos en las tres capas (presentación, aplicación y base de datos):

Figura 18 – Procesando solicitudes de usuario ABAP.

Cuando el usuario llama a una transacción o cambia de pantalla dentro de una misma función, esto es tomado por el programa de presentación SAP GUI, el cual lo convierte en un formato interno y enviado al AS ABAP.

El dispatcher (ABAP) es el proceso central del AS ABAP. Se encarga de gestionar los recursos para las aplicaciones escritas en ABAP en coordinación con el sistema operativo respectivo donde corre nuestro sistema SAP.

Las principales tareas del dispatcher incluye la distribución de solicitudes entre sus work processes, la integración de la capa de presentación y la organización de las comunicaciones.

La solicitud enviada por el SAP GUI entra en una cola de solicitudes en el dispatcher. En cuanto existe un proceso de diálogo libre, la solicitud es enviada por el dispatcher a este work process. Esto significa que no hay una relación fija entre los work process y los usuarios (más adelante volveremos sobre esto).

Para poder procesar las solicitudes de usuario, frecuentemente el work process necesitará leer datos desde o escribirlos en la base de datos del sistema. Es por esto que cada work process está conectado directamente a la base de datos.

Finalmente, una vez que la solicitud ha sido completamente procesada por el work process la respuesta es enviada nuevamente a través del dispatcher al SAP GUI. El SAP GUI interpreta la respuesta y genera una pantalla para el usuario.

Figura 19 – Flujo de procesamiento de solicitudes de diálogo.

En la figura podemos observar la relación entre los componentes y en cual sentido se realiza la comunicación en cada caso.

Los buffers que se muestran dentro del área indicada como Shared Memory (Memoria Compartida) ayudan a agilizar el tiempo de la respuesta por parte del servidor de aplicación a la capa de presentación SAP GUI ya que datos que son accedidos frecuentemente pueden alojarse en alguno de estos buffers en vez de tener que solicitarlos a través de una consulta a la base de datos.

Interface con la base de datos del sistema

Dentro del lenguaje de programación ABAP el programador puede utilizar lo que se conoce como ABAP Open SQL (SQL = Structured Query Language) para acceder a los datos de la aplicación ABAP. Cuando se elige este método el programador se independiza del RDBMS sobre el cual se instaló el sistema SAP. La interfaz de base de datos, que existe en cada work process del AS ABAP, traduce la sentencia Open SQL al

correspondiente lenguaje SQL para la base de datos específica utilizada que sería el Native SQL (SQL Nativo).

Esto es importante porque de esta manera los programas ABAP aseguran que sean independientes de la base de datos.

Otra ventaja importante de utilizar Open SQL, es que cuando la interface de base de datos del work process interpreta la sentencia intenta utilizar de manera óptima los buffers del servidor de aplicación SAP para acceder a los datos rápidamente.

Mucha información que no suele cambiar frecuentemente es la que se aloja en estos buffers del AS ABAP, entre otros, se encuentran los programas ABAP, las pantallas, información del diccionario ABAP y tablas con datos estáticos.

Figura 20 – Flujo de sentencias SQL.

Sin embargo es posible utilizar Native SQL para acceder a los objetos de la base de datos, esto significa que la interface de base de datos y el buffer local no serán utilizados en estos casos.

Si el programa ABAP tiene en su código sentencias Native SQL, este pierde la independencia de la plataforma de base de datos del sistema SAP.

Lección 4: Proceso de Bloqueo

Para asegurar la consistencia de datos dentro de nuestro sistema SAP, debemos asegurarnos de que los registros de datos no puedan ser accesados y cambiados por más de un usuario al mismo tiempo.

Para lograr esto, el sistema SAP tiene su propio concepto de administración de bloqueos (lock management)

Transacciones de base de datos

Desde la perspectiva de la base de datos, vimos en la lección anterior que cada paso de diálogo forma una unidad física y lógica: la transacción de base de datos. El sistema de base de datos sobre el que corre nuestro sistema SAP puede coordinar este tipo de transacciones de base de datos.

Transacciones SAP

Desde el punto de vista de SAP, de todas formas, esto no es suficiente para asegurar la consistencia porque las transacciones SAP, las cuales se forman por una secuencia lógica de pasos de trabajo relacionados que son consistentes en términos de negocio, los cuales se forman generalmente de varios pasos de diálogo.

El sistema SAP necesita administrar su propio concepto de bloqueo. Esto se logra utilizando el work process de enqueue (encolado). Esto también asegura la independencia de plataforma utilizada para el sistema.

Sistema de bloqueo en SAP

El concepto de bloqueo de SAP funciona sobre el principio de que los programas SAP realizan entradas de registros en la tabla de bloqueo (lock table). Solo pueden generarse nuevas entradas en esta tabla si no existen otras ya para el objeto que intenta bloquearse.

Enqueue Work Process

El enqueue work process maneja los bloqueos lógicos de las transacciones de SAP en la tabla de bloqueo. Esta tabla se sitúa en la memoria principal de la instancia donde el proceso corre.

Figura 21 – Gestión de bloqueos en SAP

En la figura 21 se muestra un escenario con dos instancias, podemos deducir que la instancia central es aquella donde el enqueue work process se encuentra corriendo.

Un work process de diálogo que corre en la misma instancia que el enqueue work process puede acceder directamente a la tabla de bloqueo en la memoria principal para chequear si un nuevo bloqueo puede generarse, esto es, si no ocurrirá un conflicto con un bloqueo ya establecido.

Si el bloqueo puede crearse, entonces el work process de diálogo crea la entrada en la tabla y se le entrega una key (llave) al usuario la cual se mantiene en la memoria de contexto de usuario.

Si el work process de diálogo y el enqueue work process corren en diferentes instancias se comunicarán a través del message server. En este caso la solicitud de bloqueo se reenvía desde el work process de diálogo al enqueue work process a través de los respectivos dispatchers y el message server. Ahora el enqueue work process es quien se encarga de chequear si puede crearse un bloqueo en la tabla. Si esto es posible, el bloqueo se realiza y la key generada se envía a través del dispatcher y el message server.

Modos de bloqueos

Cuando se solicita el bloqueo, el sistema verifica si el bloqueo generará un conflicto con alguna de las entradas que ya pudiesen existir en la tabla. Si esto ocurre, la solicitud de bloqueo es rechazada. La aplicación informa al usuario que la operación solicitada no puede realizarse en este momento.

Los desarrolladores son quienes deciden el modo de bloqueo para la aplicación:

Bloqueo de Escritura Exclusivo (Exclusive write lock), denominado con la letra E en la tabla de bloqueos. Los datos bloqueados solo pueden ser editados por un usuario. El modo Exclusivo (E) rechaza cualquier otro tipo de bloqueo por otra transacción. Sólo puede acumular otros bloqueos E por el mismo usuario.

Bloqueo de Lectura Compartido (Shared Lock Mode), estos bloqueos se identifican con la letra S en la tabla de bloqueo. Se aceptan solicitudes adicionales de lectura. Una solicitud de escritura es rechazada.

Bloqueo de Escritura Mejorado (Exclusive Noncumulative Write Lock), identificados con la letra X en la tabla, solo puede ser solicitado una vez, todas las demás solicitudes se rechazan.

Bloqueo Optimístico (Optimistic Lock), denominados con la letra O en la tabla de bloqueo. Al comienzo se establecen como bloqueos de lectura y luego pueden transformarse en bloqueos de escritura. Permite bloqueos adicionales del mismo tipo sobre un objeto. Cuando un usuario pasa al modo de modificación en una transacción el bloqueo pasa al tipo E. Si otros bloqueos de tipo O existen sobre el objeto estos son eliminados de la tabla.

La transacción SM12 muestra los bloqueos que actualmente hay en el sistema.

Figura 22 – Transacción SM12

Lección 5: Proceso de Update

En el sistema SAP, un proceso de negocio es mapeado utilizando una transacción que puede contener varios cambios de pantalla, por ejemplo, la creación de una orden de compra.

Los cambios en los datos efectuados en este proceso se suponen que serán ejecutados completamente o no serán modificados en absoluto en la base de datos (concepto Atómico del sistema transaccional).

Si la operación es finalizada durante la ejecución o un error ocurre, entonces ningún cambio en la base de datos debe efectuarse. El sistema de Actualización de SAP (SAP Update System), el cual se describe a continuación, es quien se encarga de esto.

El sistema de actualización

El sistema de actualización es una tecnología que permite a las transacciones de SAP quitar carga de trabajo intensa en los cambios a nivel de la base de datos. Estos cambios se realizan luego de manera asincrónica en un proceso especial denominado update work process (proceso de actualización).

Los procesos de diálogo pasan los datos que van a escribirse en la base de datos al proceso de actualización. El proceso de diálogo no espera que la actualización se complete para continuar, por esto es que la actualización es asincrónica, no en simultáneo. Los pasos que suceden en un proceso de actualización se muestra en la siguiente figura:

Figura 23 – Principio de actualización asincrónica.

La tarea del proceso de diálogo se completa con el comando ABAP COMMIT WORK ; la parte de actualización de la transacción comienza aquí: el message server transfiere la solicitud de actualización a un proceso de actualización. Aquí, cada paso de diálogo corresponde a una transacción de base de datos, la cual se realiza completamente o no con un comando COMMIT.

La parte de actualización de la transacción SAP es ejecutada en una única transacción de base de datos. Es en ese momento cuando los datos se copian a las tablas de la aplicación. Si un usuario quiere cambiar datos en una transacción SAP, llama a la transacción correspondiente en diálogo, realiza las entradas o modificaciones en las pantallas y luego inicia el proceso de actualización cuando guarda los datos.

Proceso de actualización asincrónica

Veamos ahora que pasos suceden cuando se realiza una modificación de datos en una transacción SAP:

El programa bloquea los registros de datos de la aplicación para otros usuarios. Esto se logra por supuesto a través del enqueue work process (utilizando el message server si fuese apropiado). El enqueue work process realizará las entradas correspondientes en la tabla de bloqueo si es que ya no están bloqueados los datos por otro usuario, en este caso informará al usuario que los datos no pueden modificarse en este momento.

Si el enqueue work process puede realizar el bloqueo en la tabla de bloqueo, envía la clave de bloqueo (lock key) al usuario. El programa lee el o los registros que serán modificados desde la base de datos y el usuario realiza las modificaciones en la pantalla de la transacción SAP.

En el proceso de diálogo active, el programa llama a un modulo de función ABAP usando la sentencia CALL FUNCTION … IN UPDATE TASK y escribe los cambios realizados por el usuario a las tablas de actualización de la base de datos. Estas tablas se conocen como las tablas VB* porque sus nombres comienzan con las letras “VB”. Actúan como memoria temporaria y guardan los datos que serán modificados hasta que puedan ser guardados en las tablas de la aplicación en la base de datos en una única transacción de base de datos.

En el final de la parte de diálogo de la transacción, por ejemplo, cuando el usuario guarda los datos (posiblemente luego de completar otros pasos de diálogo), el programa inicia la finalización de la transacción con la sentencia ABAP COMMIT WORK. El proceso de diálogo que hasta acá manejo el paso de diálogo dispara ahora el proceso de actualización.

En base a la información que recibe del proceso de diálogo (datos para actualizar, clave de bloqueo) el proceso de actualización lee las tablas VB* para identificar los datos que pertenecen a esta transacción SAP ya que pueden haber más registros en la tabla VB* al mismo tiempo de otras transacciones SAP.

El proceso de actualización transfiere los cambios marcados y obtenidos de las tablas VB* a la base de datos con una sentencia única de actualización en las tablas de la aplicación y evalúa la respuesta de la base. Si los cambios son realizados, el proceso de actualización confirma los cambios con el comando de base de datos commit luego del último cambio en la base de datos y borra las entradas de las tablas VB*. Si un error ocurre, el proceso de actualización dispara un rollback en la base de datos y deja la información en las tablas VB* marcándola como defectuosa.

Por último, las entradas en la tabla de bloqueo son eliminadas.

Los pasos explicados previamente son los que se ilustran en la siguiente imagen:

Figura 24 – Proceso de actualización asincrónico

La transacción SM13 nos permite visualizar si existen actualizaciones pendientes en el sistema SAP y cuál es su estado. Aquellas que están marcadas como erróneas no deben reprocesarse por el administrador sino por el mismo usuario utilizando la transacción para tal fin.

Figura 25 – Transacción SM13 – Actualizaciones

Lección 6: Otros Procesos ABAP

Impresión

El sistema SAP provee una amplia variedad de opciones para representar los datos de negocio u otros. Estos datos, creados y formateados en un paso de diálogo, pueden luego ser enviados a impresoras y otros dispositivos de salidas como faxes, e-mails, etc. Particularmente una impresora debe ser configurada en el sistema antes de que pueda ser utilizada.

Los usuarios pueden seleccionar al momento de imprimir entre las impresoras configuradas en el sistema. También cada usuario puede tener una impresora configurada por defecto en su registro de usuario (Transacción SU01). Una vez que la impresora está configurada, el sistema SAP tiene toda la información que necesita para poder crear lo que se denomina un spool request.

Spool Request

Un spool request contiene información sobre los datos de salida (output), su formato y el modelo de impresora utilizado. El spool request generado se almacena en un área temporal de almacenamiento llamada TemSe (temporary sequential file)

Los spool requests pueden ser creados por procesos de diálogo o por procesos de background. Los procesos de spool no crean spool requests.

Figura 26 – Impresión en un servidor de aplicación ABAP

Spool work process

Como puede verse en la figura 26, un spool work process formatea los datos especificados en el spool request y crea un output request. El output request contiene todos los datos en un formato apropiado para la impresora específica que el usuario seleccionó. Estos datos pueden ser enviados por el spool work process al sistema operativo que puede ser local si es en la misma computadora o remoto si es a través de la red.

De todas maneras, veremos con mayor detalle la administración de impresión más adelante en el curso.

Dos transacciones que son útiles son la transacción SP02 donde podemos ver nuestros propios spool requests y output requests. La otra es la transacción SU3 donde podemos especificar configuraciones personales de impresión en la sección Spool Control.

Figura 27 – Transacción SP02

Figura 28 –Transacción SU3: Configuraciones Personales

Procesamiento en Background

El procesamiento en background del sistema SAP es un método para automatizar tareas rutinarias y para optimizar el uso de recursos de los sistemas SAP en una organización.

Podemos utilizar el procesamiento en background para ejecutar programas que insumen mucho tiempo o hacen un uso intensivo de recursos, por ejemplo la base de datos, y programarlos para que corran fuera de horarios de picos altos de utilización.

Los programas que se ejecutan utilizando el procesamiento de background no están sujetos a las restricciones de los procesos de diálogo que luego de un tiempo definido son terminados por el sistema.

El background process

La separación del procesamiento de background en work process especiales nos da una dimensión adicional para separar el procesamiento de background del de diálogo. Normalmente el procesamiento de background y el procesamiento interactivo, o de diálogo se realizan en distintos tiempos. Diálogo durante el día y background durante la noche.

También es posible utilizar los background work process para separar el procesamiento de background y el trabajo interactivo en diferentes servidores de aplicación (o instancias).

Figura 29 – Planificación de tareas de background (Jobs)

El planeamiento se realiza mediante los work processes de diálogo y luego la ejecución la realiza el background work process como se ve en la figura 29. La transacción SMX nos muestra los jobs planificados por nuestro usuario.

Figura 285 – Transacción SMX

Comunicación vía el Gateway

Cada instancia de un sistema ABAP (o ABAP+JAVA) contiene un Gateway. Este es utilizado para la comunicación entre los work processes de diferentes instancias o sistemas SAP así también como con programas externos. El Gateway reader, usualmente llamado solamente Gateway, es el proceso principal del sistema de Gateway. El dispatcher se encarga de iniciarlo y verificarlo periódicamente.

Figura 30 – Comunicación vía Gateway

En las comunicaciones entre instancias o sistemas SAP realizadas utilizando funciones remotas (Remote Function Call) RFC o CPIC siempre está involucrado el Gateway de cada instancia. Como se muestra en la imagen, la comunicación se inicia en el proceso de diálogo, pasa por el dispatcher y se reenvía al Gateway para establecer la comunicación con su par de la otra instancia (u otro sistema SAP).

Con la transacción SMGW se pueden monitorear las conexiones del Gateway.

Internet Communication Manager (ICM)

El Internet Communication Manager (Administrador de Comunicaciones de Internet) es quien se encarga de que funcionen adecuadamente las comunicaciones entre un sistema SAP (Servidor de aplicación SAP Netweaver) y el mundo exterior vía los protocolos HTTP, HTTPS y SMTP. En su rol como servidor, el ICM puede procesar solicitudes que llegan desde Internet como URLs con la combinación de servidor-puerto en la cual el ICM está configurado para escuchar. El ICM luego llama al proceso local del servidor de aplicación que se ocupará finalmente de la solicitud URL.

Como consideración para la implementación, debemos pensar que necesitaremos del ICM si queremos que el servidor de aplicación SAP tenga comunicación con Internet a través de alguno de los protocolos ya mencionados.

El ICM es un componente del servidor de aplicación SAP, por lo que podremos administrar uno por cada instancia del sistema SAP. Es un proceso que se implementa por separado el cual es iniciado y monitoreado por el dispatcher. Se puede configurar a través de parámetros que se configuran en los perfiles de cada instancia.

Figura 31 – Internet Communication Manager (ICM)

Tareas Básicas de Administración

Lección 1: Proceso de Logon en un sistema ABAP

Para crear una conexión entre el front-end (interfaz de usuario) y una instancia de un sistema SAP, el programa sapgui requiere cierta información como parámetros de inicio. Estos parámetros, normalmente son creados utilizando el programa saplogon.

Esta información se almacena parcialmente en archivos de configuración del SAP Logon y parcialmente se obtiene directamente de una consulta al proceso Message

Server del sistema SAP. El SAP Logon luego puede iniciar el programa SAP GUI con estas especificaciones obtenidas.

Veamos en la siguiente figura como sucede el proceso de logon al sistema SAP.

Figura 32 – Proceso de Logon al sistema SAP ABAP

Luego de que la pantalla de logon se transfiere desde el dispatcher al front-end (no mostrado en la figura), el usuario envía a través del SAP GUI los datos de logon necesarios: cliente, usuario, contraseña y opcionalmente el idioma de logon. Esto se muestra en el paso 3 de la figura.

Luego de que el dispatcher dispone de un work process de diálogo libre para procesar el logon, transfiere los datos de logon a este work process, paso 4.

El work process ahora verifica si la combinación de usuario y contraseña es válida para el sistema enviando una consulta a la base de datos (pasos 5 al 8).

Una respuesta positiva de la base de datos al work process resulta en el envío de la pantalla inicial del sistema al front-end.

Durante la sesión de logon, la asignación del usuario a la instancia es única. Esto significa que una vez que el usuario ingresa al sistema estará asignado a trabajar en una instancia determinada por el message server durante todo el tiempo que el usuario este logueado con la sesión.

Solamente durante un nuevo logon el usuario posiblemente sea asignado a una instancia diferente por el message server.

Es posible loguearse al sistema sin pasar a través del Message Server. Para esto debemos especificar explícitamente la instancia a la que vamos a realizar la conexión.

Lección 2: Configuración del SAP Logon

El programa SAP Logón provee a los usuarios una forma sencilla de loguearse a un sistema SAP a través del programa para Windows SAP GUI.

Existen versiones de programas SAP GUI basados en JAVA que pueden ser utilizados en entornos como Linux, MacOS, etc. SAP Logón fue diseñado para front-ends de plataformas Windows.

El programa SAP Logon evalúa varios archivos de configuración que se encuentran en el front-end del usuario. Estos archivos también pueden ser editados utilizando SAP Logon.

Figura 33 – Programa SAP logon

En principio, SAP Logon simplemente inicia el programa SAP GUI para un sistema SAP seleccionado con ciertos parámetros. (ver también la cadena de conexión SAP GUI)

Figura 34 – SAP Logon, Sistemas.

Se pueden realizar varias configuraciones generales a través de las opciones de SAP Logon. Se puede por ejemplo, configurar los niveles de trace para conexiones SAP GUI. Las contraseñas pueden también quedar registradas en el archivo de trace generado, por lo que deberemos tener especial cuidado al utilizarlo; el archivo de trace debería ser eliminado una vez que sea utilizado.

Podemos utilizar el botón Nueva entrada… para crear una nueva conexión a un sistema. Una especie de asistente nos lleva a través de varias opciones para crear nuevas conexiones. Hay tres posibles opciones:

1. La selección de un sistema que ya fue previamente configurado en el archivo sapmsg.ini seguido de la selección del modo de logón: Grupo de logón o logón a una instancia específica.

Figura 35 – Opción 1

2. La definición de una nueva conexión, eligiendo la opción Sistema específico de usuario, en donde se realiza una consulta al Message Server para conocer que servidores o grupos de servidores existen en el sistema.

Figura 36 – Opción 2

3. La definición de una nueva conexión también pero como sistema específico de usuario con la especificación explícita de todos los detalles de conexión (Servidor de aplicación, número de sistema y ID de sistema) sin consultar al Message Server.

Figura 37 – Opción 3

En los casos 1 y 2 se necesita del ABAP Message Server del sistema al que queremos crear la conexión. En el caso 3, definimos una conexión directa al dispatcher seleccionado, o sea a una instancia específica del sistema. No hay necesidad de una consulta al Message Server aquí.

Si ves los botones Grupos… y Servidor… en vez del botón Nueva Entrada… el asistente está desactivado. Para activarlo, selecciona Opciones desde el menú en la esquina superior izquierda del SAP Logon. Selecciona la opción Con Asistente y confirma con OK y luego con Sí.

Figura 38 - Activación de Asistente

Cuando nos logueamos utilizando un grupo de logon, el message server de ABAP es consultado primero para poder identificar la instancia con mayor disponibilidad en base

a la cantidad de work process de diálogo que tenga configurada y los usuarios que ya estén conectados a esta en el momento dentro del grupo de logón elegido.

El archivo de configuración sapmsg.ini se evalúa para mostrar los sistemas ya configurados en el SAP Logon. La siguiente imagen muestra un ejemplo del contenido del archivo sapmsg.ini:

Figura 39 - Archivo sampsg.ini

El message server del sistema seleccionado es consultado para mostrar los grupos de logón y servidores de aplicación disponibles.

Para que la conexión al message server del sistema específico en el archivo sapmsg.ini funcione es necesario del archivo services de Microsoft Windows con el cual se especifica el puerto de comunicación del message server del ID (Identification) del sistema seleccionado, denominado SID (System ID). Continuando el ejemplo se muestra las entradas en el archivo servicespara los puertos del Message Server de cada sistema:

Figura 40 - Archivo services

Una conexión es luego creada al servidor y al message server que corre sobre este utilizando la información de los archivos sapmsg.ini yservices.

Resumen de la utilización de archivos por SAP Logon

Inicio de SAP Logon: lee saplogon.ini

Botón Acceder al Sistema: accede al sistema seleccionado

Botón Entrada Sistema Variable…: Ningún cambio al archivo saplogon.ini, evalúa los archivos sapmsg.ini y services.

Botón Nueva Entrada…: Edita saplogon.ini, evalúa sapmsg.ini y el archivo services.

Botón Modificar Entrada…: Edita saplogon.ini

Botón Borrar Entrada…: Edita saplogon.ini

Con el botón Nueva Entrada…, se puede crear una conexión a un sistema SAP que no necesariamente se encuentra en el archivo sapmsg.ini y el archivo services.

En este caso tendremos que ingresar toda la información que es relevante para loguearse al sistema.

Figura 41 - Configuración específica de usuario

El nombre del servidor o dirección IP donde se encuentra la instancia a la que queremos contactar y el número de sistema son esenciales, así también como el SID del sistema y una descripción.

El número de instancia especifica los últimos dos dígitos del puerto de 4 dígitos que utiliza el dispatcher de cada instancia. Los primeros dos dígitos son fijos, y son 32. Esto significa que los números de puertos entre 3200 y 3299 son posibles. Los puertos 3298 y 3299 están asignados a los programas niping y saprouter y no se deberían utilizar para los puertos de los dispatchers.

La configuración para una conexión, tal como su nombre en el SAP Logon, puede ser modificada utilizando el botón Modificar Entrada…

Se puede especificar un string (secuencia) de SAProuter para las conexiones de SAP GUI. Un SAProuter es asignado a la transferencia de datos para esta conexión. El Saprouter es un programa que actúa como un punto intermedio en la conexión entre el front-end y el sistema SAP.

¿Dónde se almacena cada archivo?

La siguiente lista muestra los archivos que mencionamos anteriormente y cuáles son sus posibles ubicaciones; en el caso de múltiples lugares posibles, la secuencia que utiliza SAP Logon también se muestra:

saplogon.ini, sapmsg.ini, saprouter.ini:

1.Directorio de SAP GUI 2.Directorio de Windows

services (Windows) Windows/system32/drivers/etc/services

Otra opción es configurar shortcuts (accesos directos) utilizando la solapa Accesos Directos en el SAP Logon.

Con los shortcuts, necesitamos ingresar el password, después de la cual el sistema nos lleva directamente a una transacción preasignada.

En teoría, también es posible guardar el password en el shortcut. De todas formas, no es recomendable por cuestiones de seguridad. Los shortcuts se guardan en un archivo llamado sapshortcut.ini en el directorio de Windows en la computadora del usuario, front-end.

String de conexión SAP GUI

El string de conexión SAP GUI describe una serie de parámetros para llamar al programa SAP GUI.

En su forma más simple, una llamada a SAP GUI puede verse de la siguiente forma:

Sapgui

Si se va a utilizar un grupo de logón, la estructura de conexión es algo más compleja:

/M/ Para especificar el servidor del Message Server, luego

/S/ Para especificar el Puerto del Message Server, y

/G/ Es utilizado para especificar el nombre del grupo de logón seleccionado.

sapgui/M/<servidor_de_Message_Server>/S/<Puerto_Message_Server>/G/<Grupo_de_Logon> Esta sería la estructura completa de un string de conexión completo

sapgui/M/sapdp01/S/3600/G/SPACE sería un ejemplo concreto del string de conexión.

Utilización de Grupos de Logon

Los sistemas SAP muchas veces tienen más que sólo una o dos instancias. Cada una de estas instancias ofrece una cantidad de work processes de varios tipos y pueden acceder a los recursos de hardware.

Algunas situaciones en las que las tareas a realizar en una instancia demandan una utilización intensiva del hardware, por lo tanto, degradando todo el trabajo que pueda ser realizado en esta instancia. Largos tiempos de respuesta de los procesos de diálogo son particularmente molestos para los usuarios que se ven afectados por esto lo que lleva a costos altos debido a una pobre disponibilidad del sistema. Ejemplos de estas situaciones pueden ser:

Carga debido a un gran número de solicitudes RFC externas. Carga debido a un complejo esquema de work processes de background Carga debido a numerosas tareas de update

Alternativas podemos utilizar para separar las cargas de trabajo mediante los grupos de logon:

Configurar un grupo de logon especial para recibir solicitudes RFC Configurar un grupo de logon especial para las actividades de background Configurar un grupo de logon especial para las tareas de diálogo Utilizar un grupo de logon para distribuir la carga de diálogo de la mejor manera

SAP recomienda que en los sistemas SAP con instancias múltiples configurar un grupo de logon para las conexiones de diálogo con el objetivo de que los usuarios experimenten tiempos de respuesta similares.

Este grupo de logon es llamado por ejemplo PUBLIC. Si consideramos que es útil, podemos elegir no incluir la instancia central de nuestro sistema SAP en este grupo de logon.

Por defecto, cada instancia de un sistema SAP (incluyendo la instancia central) es asignada al grupo de logon SPACE.

La transacción SMLG es la que nos permitirá crear y administrar los grupos de logon en el sistema.

Lección 3: Transacciones de Análisis

SM51 – Ver las instancias activas y los servicios que cada una ofrece, dando clic en el host name.

Dando clic en el botón Release Notes podemos observar la versión del Kernel

Para pasar a la transacción sm04 podemos dar clic en el botón de usuarios para ver que usuarios se encuentran logueados en la misma instancia

Podemos observar las sesiones del usuario, seleccionamos el usuario y damos clic en el botón Sessions.

Podemos cerrar alguna sesión del usuario.

La transacción al08 es informativa, podemos observar los usuarios que se encuentran logueados.

La transacción sm50 muestra una vista de procesos,

Podemos modificar el nivel de trace para un work processes determinado.

En la transacción sm21, podemos visualizar diferentes tipos de eventos registrados por el sistema,

El nivel de prioridad identifica donde sucedió un problema

La transacción st22, nos permite ver los errores en tiempo de ejecución de los programas ABAP

La información recopilada por el sistema luego de que ocurre el error, se divide en diferentes áreas de vista para ser visualizada por el usuario, el programador o por el administrador del sistema.

La transacción sm02 es utilizada para crear mensajes para ser visualizados por el usuario del sistema, son visto por el usuario cuando cambia de transacción.

Lección 4: Inicio y parada del sistema SAP.

Lección 5: Logs de Inicio del sistema

Problemas ocurridos durante el inicio del sistema SAP deben ser analizados por el administrador del sistema. Los archivos de log y trace generados son de gran ayuda para identificar la causa.

Registrando el Proceso de Inicio

El proceso de inicio es una fase especialmente importante, el cual es registrado por el sistema operativo, el sistema SAP y la base de datos.

Si el sistema SAP no inicia, podemos encontrar mensajes de error pertinentes en los archivos de log. Podría ser por ejemplo que existan problemas iniciando la base de datos, lo que significa que el sistema SAP no podría ser iniciado.

Figura 42 – Registrando el Proceso de Inicio del Sistema SAP

Los logs sobre el proceso de inicio del sistema SAP se almacenan en el file system. Si hay problemas durante el inicio, estos logs pueden proveer información muy útil tal como mensajes de error o descripción de problemas.

Estos archivos están en el directorio local (DIR_HOME) de la instancia respectiva. Durante el proceso de inicio, los archivos de log STDERR son creados por el Servicio de SAP. Los procesos de inicio escriben cada uno de estos archivos, dependiendo de la secuencia en la que estos componentes están listados en el perfil de inicio de la instancia (start profile).

El contenido de estos archivos de log por lo tanto depende de la configuración individual del sistema, y podría, por ejemplo, ser como sigue:

STDERR1: Información sobre el proceso de inicio del sistema de base de datos. STDERR2: Información sobre el proceso de inicio del message server. STDERR3: Información sobre el proceso de inicio del dispatcher.

Puedes configurar el nivel de detalle de la información registrada en cuatro niveles diferentes a través del parámetro de perfil rdisp/TRACE. Los posibles valores para este parámetro son:

0: Solamente errores 1: Errores y advertencias (por defecto) 2: Mensajes de error y resumen de traza (trace) 3: Mensajes de error y traza completa

Cuanto más alto el nivel de traza, más grande la cantidad de información registrada, y por lo tanto mayor el tamaño de los archivos generados. En conclusión, deberíamos incrementar el valor por defecto sólo por períodos cortos para el análisis de problemas.

El nivel de traza puede ser configurado por separado para cada work process en la vista de procesos (Transacción SM50).

Figure 43 - Análisis de Problemas

Si el sistema SAP no inicia correctamente, esto puede ser debido a una variedad de razones.

Para analizar el problema, podemos proceder de la siguiente manera:

Verifica los mensajes de error y advertencia en el sistema operativo con las herramientas correspondientes del mismo.

Verifica el status de la base de datos respectiva utilizando los archivos de log de errores. (Puedes encontrar más información en la lección: Apéndice: Logs de Base de Datos)

Verifica el log de inicio en la consola de SAP (SAP MC). Selecciona la instancia que está con problemas, y desde el menú de contexto, selecciona List Developer Traces (Listar Trazas de Desarrollador)

Verifica los archivos de error stderr que fueron creados por el Servicio de SAP. Verifica los trace files (archivos de traza) individuales de los work processes:

dev_ms: developer trace (traza de desarrollador) del Message Server. dev_rd: developer trace del Gateway. dev_disp: developer trace para el dispatcher dev_wm: developer trace para los work processes (m es el número de ID de work process que vemos en la transacción SM50).

Si aún puedes loguearte al sistema SAP, verfica el log del sistema utilizando la transacción SM21.

Lección 6: Apéndice - Logs de Base de Datos.

En algunas ocasiones, frente a un error con nuestro sistema SAP, deberemos acceder a los logs de la base de datos sobre la que está instalado el sistema.

1| Max DB

Figura 44 – Logs de Max DB

Los mensajes de sistema y errores son registrados por Max DB en el siguiente directorio: <Unidad>:\sapdb\data\wrk\<SID>

Donde <SID> es el nombre de nuestra base de datos, la cual coincide con el del sistema SAP.

Los mensajes de sistema son registrados en el log del Kernel (knldiag). Este contiene los siguientes tipos de mensaje en un orden cronológico:

Inicio y parada de la base de datos. Información sobre las áreas físicas de almacenamiento. Procesos de usuarios. Mensajes de error de sistema

El log se escribe con una modalidad conocida como anillo o circular, lo que significa que es sobreescrita cada vez que alcanza un cierto tamaño. Un nuevo archivo de log es creado después de cada inicio del sistema de base de datos.

Una copia del log anterior (knldiag.old) se crea antes de reiniciar el sistema de base de datos.

Todos los mensajes de error y advertencia relativos al sistema de base de datos son registrados en el log de errores (knldiag.err), incluyendo los mensajes para el inicio y parada de sistema.

2| MS SQL Server

Figura 45 – Logs de MS SQL Server

MS SQL Server registra todos los eventos significativos tales como los de inicio y parada de la base de datos y mensajes de error en el archivo:

<Unidad>:…\MSSQL\LOG\ERRORLOG

Una nueva versión del archivo de log de errores es creado con cada inicio del MS SQL SERVER. Las versiones de estos archivos de logs se almacenan en el órden ERRORLOG.1, ERRORLOG.2 y así sucesivamente.

La versión más vieja se almacena como ERRORLOG.6. En cada reinicio del SQL Server, el archivo más antiguo (ERRORLOG.6) se sobreescrito y los demás se renombran para mantener el órden mencionado.

Estos archivos de logs pueden ser visualizados utilizando la herramienta del sistema MS SQL SERVER: Enterprise Manager o Management Studio dependiendo la versión.

Los mensajes registrados por el servicio SQLServerAgent también se almacenan en la misma ubicación con el nombre de archivo SQLAGENT.OUT. Las últimas seis versiones de este log también son guardadas.

3| ORACLE

Figura 46 – Logs de Oracle

La base de datos Oracle registra todos los eventos significativos tales como el inicio y parada de la base de datos y mensajes de error en el archivo:

<Unidad>:\oracle\<SID>\saptrace\background\ALRT.LOG. Información detallada sobre errors se registra en el archivo de traza de Oracle (Oracle trace file):

<Unidad>:\oracle\<SID>\saptrace\usertrace\Ora<no>.trc. Si el administrador del sistema administra la base de datos con el usuario sapdba, este escribe sus propios archivos de log en los siguientes directorios:

<Unidad>:\oracle\<SID>\sapreorg <Unidad>:\oracle\<SID>\sapcheck <Unidad>:\oracle\<SID>\sapbackup

4| DB2 (UDB)

Figura 47 – Logs de DB2

La base de datos DB2 registra todos los eventos significativos en el archivo db2diag.log. La ruta bajo la cual este archivo estará almacenado se define con el parámetro Diagnostic Directory Data Path (DIAGPATH).

Esta ruta se configura en el Database Manager Configuration. El valor por defecto es :

$DB2INSPROF/DB2INSTANCE.

El archivo db2diag.log contiene la siguiente información:

El lugar en el cual el error ha sido reportado. Los IDs de la aplicaciones permiten la comparación entre entradas que pertenecen a una aplicación particular tal como SAP en el archivo db2diag.log

Un mensaje de diagnóstico con la razón del error. El mensaje usualmente comienza con “DIA”.

Toda la información disponible tal como la estructura de datos SQLCA y punteros a otros archivos de dump o trap.

Información detallada sobre los errores se registra en los archivos de traza (trace) o volcado (dump) DB2, los cuales también se almacenan en la ruta definida por el

parámetro DIAGPATH. Estos archivos son solamente creados si un problema serio interno de DB2 ocurre.

Podemos acceder al directorio de volcado mediante la transacción DB6COCKPIT y seleccionando Diagnósticos –> Directorio de Volcado en el área de navegación.

Si lo que queremos es mostrar el contenido de un log de error o un archivo de traza, solo necesitamos hacer doble click sobre el archivo.

5| Informix

Figura 48 - Logs de Informix

Todos los eventos significativos, tales como inicio y parada de la base de datos y mensajes de error son registrados por INFORMIX en el archivo:

$INFORMIXDIR/online.<hostname>.<SID>.log

Información detallada de los errores se registra en el archivo de traza (trace file) af.<unique no>

En ciertas ocasiones, el contenido de la memoria compartida es copiada a los archivos shmem.<unique no>

El directorio en donde estos archivos son almacenados se define utilizando el parámetro DUMPDIR. El valor por defecto de este parámetro es /tmp.

Mantener el sistema y la base de datos

Lección 1: Evaluación de parámetros SAP

En muchas ocasiones, ya sea porque necesitamos resolver algún problema o porque nos gustaría realizar ajustes en el sistema para mejorar la performance del mismo tendremos que evaluar y mantener los parámetros del sistema SAP.

Configuración de los Parámetros del Sistema

La configuración de las instancias y por lo tanto del sistema SAP se realiza usando los parámetros del sistema. Los valores por defecto para estos parámetros son definidos en el código de programa del kernel del sistema.

Figura 49 – Asignando los Parámetros del Sistema

La figura muestra los lugares donde están definidos los parámetros del sistema y la secuencia de lectura de los mismos. También podemos observar que existe una prioridad o peso del parámetro dependiendo de dónde lo definamos. Esto significa que un parámetro que tiene un valor definido por defecto en el kernel del sistema, cuando está definido en el perfil DEFAULT.PFL tomará el valor de este último, y si está definido también en el perfil de la instancia, entonces será ese valor con el que finalmente funcionará el sistema.

Podemos cambiar los valores por defecto de los parámetros utilizando los archivos de perfiles, los cuales son leídos cuando las instancias del sistema se levantan. Estos archivos de perfiles son creados durante la instalación del sistema y pueden ser editados luego.

Como los archivos de perfiles son solamente leídos cuando inicia el sistema, necesitamos reiniciar la instancia o el sistema completo después de cambiar algún parámetro.

El dynamic switching (cambio dinámico) de parámetros, el cual se realiza mientras el sistema se encuentra operando, es posible para un pequeño grupo de parámetros del sistema.

Figura 50 – Archivos de Perfiles a nivel del Sistema Operativo

Los archivos de perfil son automáticamente creados durante la instalación. Después de que se completa la instalación, los archivos de perfiles son almacenados a nivel del sistema operativo en el directorio:

usr\sap\<SID>\SYS\profile

Este directorio puede ser leído por todas las instancias de un sistema SAP utilizando las técnicas de montaje o de directorio compartido dependiendo el sistema operativo por supuesto donde esté instalado el sistema.

El sistema SAP tiene tres perfiles de sistema. Estos son:

Start Profile (Perfil de Inicio) Default Profile (Perfil por Defecto) Instance Profile (Perfil de Instancia)

Visualización de los Parámetros

En principio, podemos cambiar estos archivos con herramientas de edición del sistema operativo. Quienes editen estos archivos, deben asegurarse que los cambios realizados sean correctos ya que si son configurados de manera incorrecta pueden llevar a que el sistema no inicie.

Es mucho más conveniente y seguro realizar los cambios de los parámetros de perfiles utilizando las herramientas en el sistema SAP.

Figura 51 – Archivos de Perfiles (Profile Files)

El perfil específico por instancia de inicio, cuya nomenclatura es: START<instancia><número de instancia><nombre de servidor> especifica que procesos van a iniciar por cada instancia estos procesos son por ejemplo el MS y dispatcher.

Existe solo un único pefil por defecto, cuyo nombre es DEFAULT.PFL, por cada sistema SAP y el cual es leído por todas las instancias SAP. Contiene configuraciones que afectan a todo el sistema, tal como el nombre del sistema, el nombre del servidor de base de datos o el cliente de logon por defecto para el sistema.

El perfil de instancia, <SID>_<instancia número de instancia>_<nombre de servidor> define parámetros que aplican para una instancia, tales como el número y tipo de work processes, o la definición del tamaño de área de memoria principal asignada al sistema SAP. El perfil de la instancia es por lo tanto específico por instancia.

Figura 52 – Visualización de Parámetros del Sistema

Los valores actuales de los parámetros del sistema pueden visualizarse en el sistema. Para esto, podemos optar por dos maneras: el reporte RSPFPAR y la transacción RZ11. Ambas funciones muestran los parámetros para la instancia en la que el usuario se encuentra logueado.

El reporte RSPFPAR muestra una lista de todos los parámetros específicos de instancia, y de los parámetros que aplican para todo el sistema también. Esta lista se puede acotar a un rango específico de parámetros.

El resultado es una tabla donde se muestra por cada parámetro los valores por defecto del sistema tal como están definidos en el programa del kernel y si el valor por defecto ha sido anulado por un valor definido por el usuario ya sea en el perfil por defecto o en el específico de la instancia, se mostrará este valor también. Una breve descripción y, si se requiere, documentación para los parámetros puede ser visualizada también.

Figura 53 – Reporte RSPFPAR

La transacción RZ11 muestra información y documentación para los parámetros de forma individual. También muestra con el indicador Conmutación Dinámica (Dynamically Switchable) si el parámetro puede tomar un cambio de inmediato sin tener que reiniciar el sistema.

Figura 54 – Transacción RZ11

Cuando modificamos un parámetro utilizando la transacción RZ11, la modificación se mantendrá mientras la instancia esté activa. Una vez que reiniciemos la instancia el valor del parámetro volverá al que estaba definido previamente ya sea del kernel o del perfil de la instancia.

Modificar parámetros que tienen la propiedad de conmutación dinámica en la transacción RZ11 es útil para realizar pruebas sin tener que reiniciar la instancia o el sistema enteramente. Luego, si decidimos que el cambio debe ser permanente lo haremos utilizando la herramienta de mantenimiento de parámetros, transacción RZ10.

En la tabla TPFYPROPTY, todos los parámetros que pueden ser cambiados dinámicamente están identificados con el indicador Dinámico (Dynamic). Puedes utilizar la transacción SE16, por ejemplo, para visualizar esta tabla.

Fuera del sistema SAP, podemos visualizar los parámetros a nivel del sistema operativo si estamos trabajando con el usuario <SID>adm con el programa sappfpar. Podemos obtener el valor actual de un parámetro con el comando sappfpar .

El comando sappfpar all devuelve una lista de todos los parámetros. Podemos verificar que parámetros están configurados utilizando sappfpar check. El comando sappfpar help devuelve una breve ayuda sobre las posibles opciones de ejecución del programa.

También es posible especificar un perfil de instancia, un número de instancia o el nombre del sistema SAP con este comando si utilizamos las opciones pf=ruta y nombre del perfil de la instancia, nr=número de la instancia o name=SID

Para la evaluación de los parámetros de perfiles utilizando las herramientas descriptas, algunos parámetros de perfiles son los mismos para todo el sistema mientras que otros serán diferentes por cada instancia. El reporte RSPFPAR muestra la configuración de la instancia en la que se ejecuta el mismo.

Lección 2: Mantenimiento de parámetros SAP

Lección 3: Configuración de Modos de Operación

Lección 4: Tareas relacionadas a la base de datos de SAP

Esta primera lección de tres, describe de una manera simple la arquitectura y funcionalidad de las bases de datos relacionales. Basándonos luego en este conocimiento, veremos cómo realizar las actividades primarias de la base de datos mediante la planificación en el calendario de base de datos, transacción DB13.

Fundamentos de Administración de Base de Datos

Un sistema de base de datos (Database Management System: DBMS) incluye procesos de base de datos, un buffer en la memoria principal, data files (archivos de datos) que contienen la información, y log files (archivos de registro) donde los cambios a la información son registrados.

Cuando el sistema SAP inicia, todos los work processes se conectan a un proceso de la base de datos. Las consultas a la base de datos pasan de los work processes de SAP a los procesos de base de datos asignados, los cuales ejecutan la solicitud en la base de datos.º

Los datos se almacenan en los data files, el acceso a los datos siempre se realiza mediante la utilización del buffer en la memoria principal.

Procesos especiales de la base de datos se encargan del intercambio de datos entre el buffer y los data files. Durante este intercambio, los datos se leen y se escriben siempre en páginas completas, las cuales normalmente contienen cientos de registros de datos.

Figura 55 - Conceptos de Base de Datos

Si se realizan cambios a los datos, estos son registrados en el log file, por lo tanto el archivo contiene el estado de los cambios realizados a la base de datos. Solo los cambios, pero no las páginas completas, se registran en el buffer de log.

Las entradas se escriben desde el log buffer al log file, el cual puede ser sólo uno o más de uno dependiendo de la base de datos.

Para cada base de datos, existe un mecanismo que realiza un backup (respaldo) de la información desde el log file a otros archivos o a un medio de backup. Esto asegura que el archivo de log no se vuelva demasiado grande porque con cada respaldo del log file, el espacio ocupado por la información respaldada es liberado por el sistema de base de datos para ser reutilizado y registrar nuevos cambios a la base de datos en el log file.

SAP recomienda que realicemos un espejado del archivo de log. Algunas bases de datos proveen un software especial que realiza el espejado de los archivos. El espejado de log file mediante este software especial se realiza mediante una escritura de dos log files en paralelo (primario y secundario). El sistema de base de datos puede solamente sobrescribir los archivos de log primario y secundario una vez que el primario ha sido respaldado (backup).

Cuando hay problemas para acceder a un log file primario, el archivo es marcado como defectuoso, y la base de datos debe llevarse a un estado operacional OFFLINE. Para restaurar el log file defectuoso, es necesario reemplazarlo completamente con el contenido del log file secundario.

El mecanismo de log no debe ser desactivado nunca en un sistema productivo; de otra manera el estado de las modificaciones a los datos podría perderse ante una falla. Esto significa que habría un riesgo alto de pérdida de datos ante una destrucción del disco duro de los archivos de datos de la base.

Un sistema de base de datos siempre incluye datos estructurados que contiene información esencial de la base de datos, tal como el número de data files.

Lección 5: Backup y Recuperación de la base de datos

Esta lección muestra los conceptos sobre el respaldo de la base de datos. Estos conceptos incluyen un backup regular de datos y de la información de log. Estos backups son realizados mediante el calendario de planificación de base de datos, transacción DB13.

Para proteger el sistema SAP contra la pérdida de información si un error ocurre, el administrador regularmente realiza los backups.

Concepto de Backup

El concepto de backup para la base de datos siempre incluye un backup regular de los data files, la información de log y los datos estructurados de información de la base de datos misma.

El backup de los data files y la información de log se realiza en pasos diferentes. Todos los data files y los datos estructurados son respaldados en un solo paso. En otro paso, la información de log se respalda de forma separada.

Figura 56 – Backup de Data Files e información de Log

Se pueden planificar ambos pasos en un sistema SAP (excepto en una plataforma AS400) como acciones regulares utilizando el calendario de planificación de base de datos, transacción DB13.

Escenarios para la Recuperación de una Base de Datos

Si es necesario realizar una recuperación de la base de datos, el momento al cual podremos recrearla de manera consistente dependerá no solamente de la disponibilidad del backup de data files con el que contemos, sino también de la disponibilidad de los backups de información de log con la que contemos.

Si un backup de data files se pierde o está corrupto, una recuperación puede basarse en el último backup válido de data files y luego recuperarla a un punto más reciente en el tiempo, si los respaldos de información de log están disponibles sin ningún faltante. Esto significa que tenemos que contar con todos los backups de información de log que se realizaron a partir del backup de data files que utilizamos para la recuperación hasta el punto en el tiempo que necesitemos recrear la base de datos.

Recuperar la base de datos (con pérdida de datos)

Observando la figura 462, si un accidente del disco duro ocurre en un punto entre t1 y t2, todos los datos respaldados en el backup de data files t1 son recreados con la recuperación. Si ninguna acción se realiza luego de esto, todos los cambios a la información (creación, modificación o borrado) que fueron realizados después del punto t1 se perderán.

Figura 57 – Recuperación con pérdida de datos

Recuperar la base de datos (sin pérdida de datos)

Todos los datos del backup de data files t1 son recuperados. Algunas bases de datos permiten recuperar solamente los data files que faltan o inclusive objetos específicos de la base de datos como por ejemplo una tabla determinada.

Luego, toda la información de log consecutiva respaldada desde el punto t1 (22,23,…) son tomados para la recreación de la base de datos. En el último paso, el archivo de información de log que tenía la base de datos hasta el punto del accidente es recuperado. Esto significa que toda la información ahora está en el mismo estado hasta el punto en el que ocurrió la falla del disco duro.

Solamente si toda la información de log desde el último backup de data files está disponible, sin faltantes, la recuperación de la base de datos será sin pérdida de datos.

Figura 58 – Recuperación sin Pérdida de Datos

Almacenando los backups de data files e información de log

La información de log respaldada en los backups es borrada a nivel del sistema operativo para evitar problemas de espacio en disco. Si un accidente de disco ocurre en el punto t5 de la figura 463, y un medio de backup del backup de data files t3 se encuentra defectuoso, un backup anterior en el tiempo (en este caso, t1) debe ser utilizado.

Para recuperar la base de datos sin pérdida de información, es absolutamente necesario contar con todos los backups de información de log (en este caso t2 y t4) que se generaron luego del backup de data files en el punto t1. Por esto es necesario mantener siempre backups de data files e información de log más antiguos del último backup de data files.

Otras consideraciones: Algunas base de datos también requieren de la información de log para poder realizar una recreación de la base de datos. Por lo tanto deberíamos asegurarnos que se realicen backups tanto de data files y la información de log regularmente.

Ciclo de Backup

Hay diferentes variantes para un completo backup de data files diario, dependiendo de la base de datos. Al menos un backup online debería realizarse de la base de datos, con un subsecuente backup completo de información de log.

Los medios de backup utilizados pueden ser sobrescritos nuevamente cada 28 días. Esto es una recomendación. Los backups podrían ser retenidos por mucho más tiempo en una compañía.

SAP recomienda que la duración de un ciclo de backup sea de 28 días. Esto significa que los backups de data files e información de log son sobrescritos después de 28 días, al menos.

Figura 59 – Ciclo de Backup Recomendado

En un sistema productivo SAP recomienda realizar un completo backup de datos diariamente. Algunas bases de datos ofrecen la opción de realizar backups diferenciales o incrementales de data files, lo que no realiza un completo backup de la base de datos (estos backups serán referidos como backups parciales de ahora en más).

Si se utiliza un backup parcial de datos como estrategia diaria de backup, se debería realizar un backup completo al menos una vez por semana. Debería haber al menos cuatro backups completos de la base de datos contenidos en un ciclo de backup. La información de log debería respaldarse al menos una vez por día. También es recomendable duplicar los medios de backup para la información de log para asegurar que contamos con todos los backups de log en caso de que alguno se encuentre defectuoso.

En muchas compañías generalmente se realizan backups de la información de log más de una vez por día con frecuencias de hasta 30 minutos. Esto dependerá muchas veces de la cantidad de información que se modifique en la base de datos durante el día lo que impacta directamente en un crecimiento de la información de log.

Por último es recomendable realizar un backup de data file e información de log con verificación al menos una vez en el ciclo. Esto asegura que el backup es legible en el dispositivo de backup, pero incrementa el tiempo total del respaldo de la información.

Planificación y Monitoreo de Backups

En el sistema SAP, puedes planificar y monitorear backups regulares con la transacción DB13.

Figura 60 – Transacción DB13

Figura 61 – Planificación de Backup

Si por ejemplo utilizamos un medio externo como un dispositivo de cinta, deberemos verificar que medio se requiere para el próximo backup cada día e insertar el medio (cinta) correspondiente antes de iniciar el backup.

Verifica diariamente si los backups se han completado satisfactoriamente. En el calendario de planificación, un backup exitoso se muestra en verde o amarillo (cuando hay alguna advertencia). Si el indicador es de color rojo, entonces un error sucedió durante la ejecución del backup, por lo tanto es inutilizable.

Figura 62 – Código de colores de estado de tareas.

Información adicional se puede ver en la transacción DB12, la cual nos permite visualizar los registros de sucesos de las actividades realizadas en la base de datos.

Figura 63 – Transacción DB12 ½

Esta transacción además del listado de registros, nos permite visualizar las áreas de datos y log utilizadas por la base de datos.

Figura 64– Transacción DB12 2/2

A partir de la versión SAP Web Application Server 6.10, es posible controlar y monitorear los backups para todos los sistemas del landscape con el calendario de planificación central, transacción DB13C. La planificación se transfiere a los sistemas remotos utilizando una conexión de tipo RFC.

DB13 fue mejorada para la versión SAP Netweaver 7.00, lo que permite utilizar la misma para planificar acciones en otras bases de datos. Para poder realizar esto, primero es necesario crear las conexiones a estos sistemas en DB13.

El botón de documentación , nos puede dar mayor información sobre las tareas que son posibles realizar desde la transacción DB13 y recomendaciones.

Lección 6: Monitoreo de base de datos

Dependiendo de la base de datos que se utilice para el sistema SAP, existe una cantidad de verificaciones periódicas que deben llevarse a cabo adicionalmente a la realización de los backups.

Para asegurarnos una óptima performance de la base de datos y por lo tanto, una buena performance del sistema SAP, el administrador debe realizar verificaciones adicionales a la base de datos, las cuales pueden ser planificadas regularmente.

Monitoreo Regular de la Base de Datos

Además de los chequeos de la ejecución de los respaldos de la base de datos, existe una serie de verificaciones que podremos realizar mediante la transacción DB13 también.

Figura 65– Monitoreo de Base de Datos

Estas verificaciones, incluyen entre otras:

Generación de estadísticas para asegurar una buena performance cuando se accede a los registros.

Crecimiento de la base de datos y espacio disponible Chequeo de errores o problemas generales de la base de datos

La generación periódica de estadísticas es un importante prerrequisito para un acceso eficiente a los registros. Cuando una sentencia SQL es ejecutada, la base de datos tiene que optar por una de las posibles alternativas para acceder a los datos requeridos.

En la sentencia SQL, la condición WHERE especifica el número de registros que se obtendrán para la consulta. La base de datos debe encargarse ahora de obtener la información tan rápido como pueda, en otras palabras, en la menor cantidad de accesos posibles.

La base puede leer el contenido completo de una tabla, lo que se denomina Full Table Scan o acceder a una tabla a través de un índice (index scan). Utilizando las estadísticas, el Optimizador Basado en Costo (Cost Based Optimizer) de la base de datos calcula el acceso de lectura respectivo para todas las posibles alternativas y elige el mejor (el más económico) camino de acceso.

Figura 66 – Determinando el Mejor Camino de Acceso

Actualización de Estadísticas

Las estadísticas contienen información sobre el número de entradas en la tabla, el número de bloques que son ocupados por la tabla y el índice de la tabla y la selectividad de los registros según los valores de los campos.

La duración recomendada para la generación de las estadísticas puede variar dependiendo de la base de datos que utilicemos o de la versión. En principio, la actualización de estadísticas solo tienen que ser generadas cuando una tabla ha crecido o reducido notablemente su tamaño. Esto es porque la generación de estadísticas en el entorno SAP se ejecuta en dos pasos:

En el primer paso, un chequeo es realizado para determinar si es necesaria la generación de estadísticas para la tabla. Para hacer esto, el número actual de registros de datos se compara con el número de registros de datos que existían la última vez que se ejecutaron las estadísticas.

En el segundo paso, las estadísticas son generadas para todas las tablas para las cuales su tamaño ha cambiado de manera considerable.

Dependiendo de la base de datos que se use, ambos pasos son planificados en la transacción DB13 en un único job o en jobs separados.

La generación de estadísticas es sumamente importante para el acceso eficiente a los datos y debería ser verificado regularmente por el administrador.

Monitor CCMS

Otra tarea importante del administrador además de asegurar el acceso eficiente a la base de datos es verificar el crecimiento de la base de datos, en particular el espacio libre disponible para la base. Esto se puede realizar utilizando las herramientas propias de la base de datos o desde el mismo sistema SAP.

La Figura 67, muestra una sección del monitor de base de datos que puede ser utilizado para monitorear que tan llena está la base de datos. Como muestra la Figura 67, se puede monitorear no solamente el fill level (nivel de llenado) de la base, sino también la performance y las actividades planificadas tales como el backup y la generación de estadísticas.

Figura 67 – Monitor CCMS: Base de Datos.

La transacción DB02 nos permite realizar un análisis del estado de la base de datos, donde podemos verificar entre otras cosas el tamaño total de la base de datos y el espacio ocupado realmente o estadísticas de las tablas e información sobre tablas o de índices perdidos así también como el nivel de llenado histórico.

Figura 68– Análisis de Base de Datos (DB02)

DBACOCKPIT

La transacción DBACOCKPIT concentra todas las operaciones y funciones de monitoreo para la base de datos. En vez de tener que llamar a cada una de las transacciones que vimos anteriormente podemos acceder directamente a la transacción DBACOCKPIT y desde allí realizar todas las tareas necesarias para la administración de la base de datos.

Figura 69 – Transacción DBACOCKPIT

Usuarios, Roles y Autorizaciones Lección 1: Concepto de Administración de usuarios ABAP Los usuarios de los sistemas SAP requieren contar con las autorizaciones apropiadas para ingresar al sistema. El administrador crea y configura un ID de Usuario en el sistema para cada usuario.

Bases de Administración de Usuarios

El concepto de registro maestro de usuario y el concepto de autorización serán explicados con mayor detalle abajo. Ambos conceptos son muy importantes para comprender mejor los sistemas SAP.

Figura 70- Usuarios en el ambiente SAP

El término usuario generalmente se utiliza para hacer referencia a una identificación de usuario (ID de usuario). La gente se loguea a un sistema operativo, una base de datos o a un sistema SAP utilizando un usuario y contraseña válidos.

Los sistemas operativos, las bases de datos y el sistema SAP usualmente tienen diferente conceptos de autorización. Si una combinación de usuario y contraseña es creada en un sistema SAP para una persona, esto no significa que es posible para esa persona loguearse en el sistema operativo del servidor con el mismo usuario y contraseña. De todas formas, es posible que una combinación idéntica de usuario y contraseña se creen para loguearse al sistema operativo y al sistema SAP.

Las solicitudes de los usuarios son procesadas por los work processes de SAP. Estos work processes utilizan un mismo usuario para acceder a la base de datos.

Los datos de usuarios y autorizaciones son dependientes del cliente.

El acceso a nivel del sistema operativo de un servidor de aplicación SAP y del servidor de la base de datos deben ser protegidos o la operación y los datos del sistema SAP pueden ponerse en riesgo.

Autorizaciones

Figura 71– Usuarios y Autorizaciones

La protección de autorizaciones se realiza en dos niveles:

1- ¿Puede una transacción ser accedida?

2- Autorizaciones para realizar acciones y tratamiento de datos durante el uso propio de la transacción.

Una persona puede loguearse a un cliente de un sistema SAP si conoce la combinación de usuario y contraseña. Si el usuario luego intenta iniciar una transacción para la cual no tiene autorización, el sistema rechaza al usuario con un mensaje de error apropiado.

Si el usuario inicia una transacción para la cual tiene autorización, el sistema muestra la pantalla inicial de la transacción. Dependiendo de la transacción que haya ejecutado, el usuario ingresa datos y realiza acciones en la pantalla. Verificaciones adicionales de autorización se llevan a cabo para los datos y acciones que se realizan para proteger los mismos.

A los usuarios se les asignan autorizaciones mediante roles. Las autorizaciones son combinadas en roles y los roles luego se ingresan en el registro maestro de usuario. Esto se explica con mayor detalle en las próximas lecciones.

Figura 72 – Registro Maestro de Usuario.

Tipos de Usuarios

El tipo de usuario es una propiedad importante de un usuario. Diferentes tipos de usuario existen para diferentes propósitos:

Diálogo

Un usuario normal de Diálogo se utiliza para todas las formas posibles de logón por una persona. Durante un logón de diálogo, el sistema verifica si la contraseña es inicial o expiró entonces el usuario tiene la oportunidad de cambiar su contraseña.

También el sistema verifica si múltiple sesiones son creadas con el mismo usuario y si permite que el usuario decida qué hacer en los casos que sea posible utilizar múltiples sesiones.

Sistema

El tipo de usuario Sistema se utiliza en comunicaciones dentro de un sistema o para procesamiento de fondo. Este tipo de usuario no puede utilizarse para acceder mediante el programa SAP GUI o ningún otro método que pueda utilizar una persona, podemos decir que no es interactivo.

También se puden usar los usuarios de tipo Sistema para aplicaciones que requieren de comunicaciones RFC tales como ALE, Workflow, Transport Management System, Central User Administration. Los usuarios de este tipo quedan exentos del parámetro de sistema del período de validez de contraseña. Solo los administradores pueden cambiar la contraseña.

Comunicaciones

Utiliza el usuario de tipo Comunicaciones para el logón de usuarios no-interactivos entre sistemas. No es posible utilizar estos usuarios para un logón de diálogo. La configuración usual del período de validez de contraseña aplica para estos usuarios también.

Servicio

Un usuario de tipo Servicio es un usuario de diálogo que está disponible para un gran número de usuarios anónimos. En general, estos tipos de usuarios están muy restringidos en cuanto a autorizaciones.

Los usuarios de Servicio son usados, por ejemplo, para accesos anónimos al sistema utilizando ITS o servicios ICF. El sistema no verifica por la validez de la contraseña durante el logón de este tipo de usuarios, por lo que están exentos.

Solamente el administrador de usuarios puede cambiar la contraseña. Múltiples sesiones se permiten para estos usuarios.

Referencia

Como el tipo de usuario de Servicio, un usuario de Referencia no está vinculado a una persona. No es posible utilizar este tipo de usuario para loguearse al sistema. Un usuario de Referencia es utilizado solamente para asignar autorizaciones adicionales en la solapa de Roles del registro de usuario.

Figura 73 – Tipos de Usuarios

Transacción de Administración de Usuarios SU01.

Para iniciar el mantenimiento de usuarios, transacción SU01, selecciona desde el menú Tools → Administration → User Maintenance → Users.

Es posible crear un nuevo registro maestro de usuario copiando un registro de usuario existente o creando completamente uno nuevo.

El registro maestro de usuario contiene toda la información y configuraciones que se requieren para poder loguearse a un cliente del sistema SAP. Estos datos están divididos en las siguientes solapas de la transacción SU01: Address: información personal y de contacto. Logon data: período de validez de la contraseña y del usuario. Tipo de usuario. Defaults: valores por defecto para una impresora, lenguaje de logón, etc. Parameters: Valores específicos de usuario para campos estándar en el sistema SAP. Roles and Profiles: Roles y perfiles que son asignados al usuario. Groups: Asignación de grupos para el usuario, utilizado para el mantenimiento masivo de usuarios.

El requisito mínimo para la creación de usuarios es ingresar al menos el apellido (Last Name) en la solapa Address, y la contraseña inicial en la solapa Logon Data.

Lección 2: Concepto de Autorización. Las autorizaciones de los usuarios son creadas usando roles y perfiles. Los administradores crean los roles y el sistema provee el soporte para la creación de las autorizaciones asociadas.

Objetos de Autorización y Chequeo de Autorización

Comprender el concepto de autorización de SAP requiere el conocimiento del rol y perfil de autorización en el registro maestro de un usuario. Esta lección provee el conocimiento necesario para poder crear los roles y autorizaciones propios.

Figura 74 – Objetos de Autorización

Las acciones y los accesos a los datos están protegidos a través de los objetos de autorización en el sistema SAP. Los objetos de autorización se encuentran en el sistema SAP.

Para facilitar un poco la organización, los objetos de autorización están divididos en diferentes clases.

Los objetos de autorización permiten verificaciones complejas que involucran múltiples condiciones que permiten a un usuario realizar una acción. Las condiciones son especificadas en los campos de autorización para el objeto de autorización y son evaluados estos campos mediante la condición lógica AND para la verificación. O sea, se deben cumplir todas las condiciones para que la verificación de autorización sea exitosa.

Los objetos de autorización y los campos que contienen tienen nombres técnicos y descriptivos. En el ejemplo de la figura 74, el objeto de autorización User Master Maintenance: User Groups (nombre técnico: S_USER_GRP) contiene dos campos de autorización: Actividad (nombre técnico: ACTVT) y User Group in User Master Record (nombre técnico: CLASS).

El objeto de autorización S_USER_GRP protege el registro maestro de usuario justamente. Un objeto de autorización puede incluir hasta diez campos de autorización.

Una autorización siempre se asocia con solo un objeto de autorización y está formada por el valor para los campos del objeto de autorización. Una autorización es un permiso para realizar cierta acción en el sistema SAP. La acción es definida sobre la base de los valores para cada uno de los campos de un objeto de autorización.

Por ejemplo, la autorización B en la figura para el objeto de autorización S_USER_GRP permite mostrar todos los registros de usuarios que NO están asignados al grupo SUPER. La autorización A, en cambio, permite mostrar registros de usuarios pertenecientes a ese grupo.

Es posible que existan múltiples autorizaciones para un objeto de autorización. Algunas autorizaciones ya están incluidas en el sistema por SAP, pero la mayor parte son creadas específicamente por requerimientos de los clientes.

Figura 75 – Verificación de Autorización

Cuando un usuario se loguea a un cliente de un sistema SAP, sus autorizaciones son cargadas en el contexto de usuario. El contexto de usuario se encuentra en el buffer (en la memoria principal, puedes consultarla mediante la transacción SU56) del servidor de aplicación.

Cuando el usuario llama a la transacción, el sistema verifica si el usuario tiene la autorización necesaria en el contexto de usuario para acceder a la transacción. Las verificaciones de autorización utilizan las autorizaciones que existen en el contexto de usuario. Si se asignan nuevas autorizaciones al usuario, podría ser necesario para este usuario volverse a loguear al sistema SAP para poder utilizar estas nuevas autorizaciones.

Si la verificación de autorización para llamar a la transacción es exitosa, el sistema luego muestra la pantalla inicial de la transacción. Dependiendo de la transacción, el usuario puede crear datos o seleccionar acciones. Cuando el usuario realiza la acción, los datos son enviados al dispatcher, el cual los pasa a un work process para que ejecute el procesamiento.

Verificaciones de autorización (AUTHORITY-CHECK) que son realizadas durante la ejecución en el work process son programadas dentro del código por los desarrolladores ABAP para proteger los datos y las acciones que van a realizarse.

Si el contexto de usuario contiene todas las autorizaciones requeridas para la verificación (código de retorno = 0), los datos y las acciones son procesadas y la próxima pantalla es devuelta al usuario. Si falta alguna de las autorizaciones requeridas, el procesamiento no se realiza y el usuario recibe un mensaje que indica que las autorizaciones son insuficientes.

Esto se controla mediante la evaluación del código de retorno. En este caso, no sería igual a 0.

Todas las autorizaciones son permisos. No hay autorizaciones para prohibir.

Todo aquello que no está explícitamente permitido está prohibido. Esto es lo que se conoce como concepto de autorización positivo.

Mantenimiento de Roles: Menú y Autorizaciones

Figura 76 – Mantenimiento de Roles

El Mantenimiento de Roles (transacción PFCG, previamente también llamada Profile Generator o Activades de Grupo) simplifica la creación de autorizaciones y sus respectivas asignaciones a los usuarios.

En el mantenimiento de roles, las transacciones, que desde el punto de vista de la compañía, pertenecen a un mismo grupo se seleccionan. El mantenimiento de roles crea las autorizaciones con los valores de campos requeridos para los objetos de autorización que son verificados en la transacción elegida.

Un rol puede ser asignado a varios usuarios. Los cambios a un rol por lo tanto tienen efecto sobre todos estos usuarios. Los usuarios pueden ser asignados a más de un rol.

El menú de usuario se compone del menú de rol y contiene las entradas (transacciones, URLs, reportes, etc) que son asignadas al usuario a través de los roles.

Figura 77 – Menú de usuario

Puedes acceder al mantenimiento de roles con la transacción PFCG o mediante el menú de la pantalla inicial del sistema en Tools → Administration → User Maintenance → Role Administration → Roles. Ingresa el nombre del rol y presiona el botón Create o Change. Selecciona la solapa Menu.

Selecciona y modifica las funciones: En el árbol de menú se pueden realizar ajustes para los roles individuales. Se pueden insertar o borrar transacciones en el árbol de transacciones.

Si se selecciona el botón Report, puedes integrar reportes (programas ABAP). En este caso la transacción PFCG se encarga de crear los códigos de transacción (si es que no existen para el reporte) con el cual los reportes luego pueden ser accedidos. Si seleccionamos el botón Other, es posible agregar direcciones de internet o vínculos a archivos.

Modificación de Menús: podemos crear, mover, borrar y renombrar directorios y sub-directorios si es necesario. La función Drag&Drop se puede utilizar también.

Figura 78 – Generando Perfiles de Autorización

El mantenimiento de roles automáticamente crea las autorizaciones que están asociadas con las transacciones especificadas en el árbol del menú. De todas maneras, todos los valores de autorización deben ser verificados manualmente y ajustados si fuese necesario para que concuerden con los requerimientos y permisos que se deben otorgar con el rol.

El administrador del sistema es responsable para esta tarea, junto con el área apropiada para quien se están creando o modificando los roles.

Selecciona la solapa Authorizations y luego el botón Change Authorization Data o Display Authorization Data, dependiendo en cual modo estemos trabajando en la transacción PFCG.

En la pantalla que ingresamos podremos ver y modificar el contenido de las autorizaciones, o sea los valores propuestos para los campos de los objetos de autorización. El significado de los indicadores es el siguiente:

Luz verde: el objeto de autorización tiene un valor propuesto para cada uno de los campos.

Luz amarilla: el objeto de autorización necesita mantenimiento manual al menos para uno de los campos.

Luz roja: Los niveles organizacionales no están definidos.

Figura 78_b – Significado de los indicadores

La falta de un valor propuesto por PFCG para alguno de los campos del objeto de autorización puede ser por ejemplo en los casos de accesos a archivos externos donde no se puede determinar si el acceso será de lectura o de lectura/escritura.

Algunos campos aparecen en muchas autorizaciones por lo que estos campos se denominan Niveles Organizacionales. Si editamos una entrada en el nivel

organizacional utilizando el botón entonces los cambios afectarán a todos los objetos de autorización que lo contienen.

¿Qué son los Niveles Organizacionales? Son campos determinados por SAP en el Concepto de Autorización que se refieren a la estructura de la compañía. Estos campos aparecen en la mayoría de las autorizaciones. Por lo tanto dentro de un rol estos campos pueden aparecer muchas veces. El botón Organizational levels… en la transacción PFCG facilita su mantenimiento.

Una vez que todas las autorizaciones han sido mantenidas como se requiere, el perfil

de autorización puede ser generado mediante el botón Generate . Las autorizaciones se combinan en un perfil. Los perfiles deben ingresarse en los registros maestros de usuarios, esto se denomina Comparación de Registros Maestros de Usuarios (User Master Record Comparission)

Usuarios y Roles

La asignación de usuarios a roles se realiza mediante la transacción PFCG (mantenimiento de roles) o en la transacción de mantenimiento de usuario SU01. Selecciona la solapa User y los ID de usuarios a los que se les asignará el rol.

Figura 79 – Asignación de Roles a Usuarios

Los usuarios pueden recibir más de un rol, esto es útil para algunas actividades (como impresión) que serán permitidas para la mayoría de los usuarios.

La asignación de roles a los usuarios no otorga automáticamente las correspondientes autorizaciones a los usuarios. Para asignar las autorizaciones, es necesario realizar una comparación de registros de usuarios mediante la cual los perfiles de los roles son insertados en el registro maestro de usuario.

Figura 80 – Comparación de Registro Maestro de Usuario

Una comparación de registros maestros de usuarios determina si los perfiles de autorización deben ser agregados o eliminados del usuario basándose en la asignación de roles para este.

Durante una comparación se agregarán perfiles al maestro de usuario si nuevos roles son agregados.

Si la asignación de roles es removida manualmente o porque se cumple la fecha de vencimiento del rol para el usuario los perfiles correspondientes son eliminados del registro maestro de usuario.

La comparación puede realizarse por cada rol individualmente. Seleccionando el rol en la función de mantenimiento de roles en la solapa User y luego seleccionando User comparison. En la ventana que aparece, seleccionamos Complete comparison.

Para más información, selecciona el botón de información en la transacción PFCG y el mismo botón en la comparación de maestros de usuarios. Durante una comparación completa, los perfiles obsoletos son eliminados. Si múltiples asignaciones de roles va a ser actualizada, puedes realizar una comparación en la transacción PFCG seleccionando Utilities → Mass comparison o

llamando a la transacción PFUD. Puedes seleccionar los roles que desees o actualizar todas las asignaciones si ingresas el caracter asterisco (*). También puedes activar una comparación de registros maestros de usuarios periódicamente si seleccionas Utilities → Mass comparison. Selecciona la opción Schedule o Check job for full reconciliation. El sistema luego muestra una ventana de búsqueda para el job de background PFCG_TIME_DEPENDENCY. Si no encuentra el job, tenemos la opción de crear uno. El valor por defecto es que todos los registros maestros de usuarios serán comparados una vez por día.

Lección 3: Asignación de Roles y perfiles

Lección 4: Parámetros de Login e información de usuario. En esta lección veremos una serie de parámetros importantes para la administración de usuarios, por ejemplo, el comportamiento de logon.

Parámetros del Sistema para Logon de Usuarios

Figura 81 – Parámetros del Sistema para Logon de Usuarios 1/2

Podemos especificar la longitud mínima de la contraseña con el parámetro login/min_password_lng.

El parámetro login/min_password_digits, login/min_password_letters, login/min_password_lowercase, login/min_password_uppercase, y login/min_password_specials especifican el número de dígitos, letras (mayúsculas y minúsculas) o caracteres especiales que una contraseña puede contener. El rango de valores es entre 1 y 40.

El parámetro login/password_expiration_time especifica el número de días en los cuales un usuario debe cambiar su contraseña. Si el parámetro se configura en 0, el usuario no necesita cambiar su contraseña.

Existen algunas reglas generales sobre las contraseñas que no pueden desactivarse.

Una contraseña: Debe ser al menos de 6 caracteres de largo. No puede comenzar con ? o ! No puede ser pass La nueva contraseña debe diferir de la anterior al menos en 1 carácter.

La configuración que determina que los usuarios deben crear una nueva contraseña que difiera de las 5 últimas no es más mandataria. Se puede utilizar el parámetro login/password_history_size para configurar el historial entre 1 y 100. El valor propuesto por defecto se mantiene en 5.

Se pueden definir restricciones adicionales en la tabla USR40.

SAP Web Application Server 6.20 y 6.40 ofrecían los parámetros login/password_max_new_valid y login/password_max_reset_valid. Estos parámetros especificaban por cuanto tiempo una contraseña inicial para un usuario creado o una contraseña recreada por el administrador del sistema para un usuario era válida. Con SAP Netweaver AS 7.0, estos parámetros han sido reemplazados por login/password_max_idle_initial.

El parámetro login/password_max_idle_initial indica por cuánto tiempo una contraseña nueva (seleccionada por un administrador) permanece válida si no es utilizada. Una vez que el período se cumple, la contraseña no puede ser utilizada para la autenticación en el sistema.

El administrador de usuarios puede reactivar la contraseña asignando nuevamente una contraseña inicial.

Otro nuevo parámetro introducido luego de la versión SAP Web AS 6.40 es login/password_max_idle_productive. Este indica el máximo tiempo que una contraseña productiva (contraseña seleccionada por el usuario) permanece válida cuando esta no es usada.

Una vez que este período ha caducado, la contraseña no puede ser utilizada para autenticación. El administrador de usuarios puede reactivar la contraseña mediante la asignación de una nueva contraseña inicial.

Con el parámetro login/min_password_diff, el administrador puede determinar el número de caracteres diferentes que una contraseña nueva debe poseer en comparación con la contraseña anterior. Este parámetro no tiene efecto cuando la contraseña del usuario es creada o reactivada.

Figura 82 – Parámetros del Sistema para Logon de Usuarios 2/2

Figura 83 – RZ11: Parámetros de Logon

Puedes configurar el número de intentos fallidos de logon después de los cuales SAP GUI se cierra usando el parámetro login/fails_to_session_end. Si el usuario quiere intentar de nuevo, deberá reiniciar SAP GUI.

Puedes también configurar el número de intentos fallidos de logon después de los cuales el usuario se bloquea en el sistema SAP usando el parámetro login/fails_to_user_lock. El contador de intentos fallidos se reinicia después de un intento exitoso de logon.

A la medianoche de la hora del servidor, los usuarios que se bloquearon como resultado de intentos incorrectos de logon no son desbloqueados automáticamente por el sistema, valor por defecto desde la versión SAP Netweaver 7.0. Se puede reactivar este desbloqueo automático con el parámetro login/failed_user_auto_unlock = 1.

El administrador puede desbloquear, bloquear o asignar una nueva contraseña a los usuarios en la transacción SU01, mantenimiento de usuarios.

Si el parámetro login/disable_multi_gui_login se configura con el valor 1, un usuario no puede ingresar a un cliente más de una vez, o sea con más de una sesión. Esto puede ser útil por razones de seguridad del sistema. Si el parámetro está configurado en 1, el usuario tendrá las siguientes opciones cuando abre más de una sesión:

Continuar con este logon y finalizar cualquier otro logon en el sistema.

Terminar este logon.

Tenemos la opción de excluir de este parámetro a los usuarios que especifiquemos en el parámetro login/multi_login_users separados por comas y sin espacios.

Usuarios estándar

Figura 84 – Usuarios estándar

Esencialmente, hay dos tipos de usuarios estándar: aquellos creados por la instalación del sistema SAP y aquellos creados durante la copia de un cliente.

Durante la instalación del sistema SAP, el cliente 000 y 066 son creados (el cliente 001 no siempre es creado durante la instalación. Es creado por ejemplo durante la instalación de un sistema ERP 6.0).

Usuarios estándar son predefinidos en los clientes. Como estos nombres de usuarios y sus contraseñas son estándar, pueden ser conocidos por otras personas por lo tanto es aconsejable que como administradores del sistema protejamos estos usuarios de accesos no autorizados.

El usuario estándar del sistema SAP*

SAP* es el único usuario para el cual no se requiere un registro maestro de usuario (no existe una entrada en las tablas de usuarios) ya que está definido en el kernel del sistema. SAP* tiene por defecto la contraseña pass y autorización de acceso irrestricto para el sistema.

Cuando instalamos un sistema SAP, un registro maestro de usuario se crea automáticamente para SAP* en el cliente 000 (y 001 si existe). Durante el proceso de instalación se nos solicitará indicar una contraseña. La instalación solo nos permitirá continuar una vez que una contraseña se ha ingresado para el usuario SAP*.

El registro maestro de usuario creado para el usuario SAP* desactiva las propiedades especiales de SAP*, por lo que solo las autorizaciones y contraseñas definidas en el registro maestro del usuario aplican ahora.

El usuario DDIC

Este usuario es responsable de mantener el Diccionario ABAP (ABAP Dictionary) y la logística de software.

Cuando instalamos el sistema, un registro maestro de usuario se crea automáticamente en el cliente 000 (y 001 si aplica) para el usuario DDIC.

Con este usuario también, se nos requerirá cambiar la contraseña estándar durante la instalación. Ciertas autorizaciones son predefinidas en el código del sistema para el usuario DDIC, lo que significa que por ejemplo, solo el usuario DDIC puede realizar un logon al sistema durante la instalación de una nueva versión (upgrade).

En versiones anteriores las contraseñas que tenían por defecto los usuarios SAP* y DDIC eran 06071992 y 19920706 respectivamente. Luego era necesario modificar estas contraseñas una vez instalado el sistema.

El usuario EarlyWatch

El usuario EarlyWatch se crea en el cliente 066 y está protegido con la contraseña support. Los expertos de SAP del servicio EarlyWatch son quienes utilizan este usuario. Este usuario no debe ser borrado ni la contraseña debe ser cambiada.

Este usuario solo debe ser utilizado para las funciones de EarlyWatch: monitoreo y peformance. Las autorizaciones necesarias para este usuario ya son provistas durante la creación del mismo en el proceso de instalación.

Caracteristicas especiales de SAP* Si copias un cliente, el usuario SAP* siempre está disponible. Este usuario no tiene un registro maestro de usuario y está programado en código del sistema (kernel). Para proteger el sistema contra accesos no autorizados, debemos crear un registro de usuario para este usuario estándar. Crea un usuario SAP* con autorizaciones totales en el sistema (perfil SAP_ALL).

Si borramos el registro de usuario SAP* (tabla USR02), la contraseña inicial pass con las propiedades vuelven a ser válidas nuevamente: el usuario tiene autorizaciones totales ya que no se realizan verificaciones de autorización para este usuario.

La contraseña estándar no puede ser cambiada.

¿De qué manera podemos proteger el sistema contra este potencial riesgo de acceso no autorizado?

Se puede desactivar el usuario SAP* que viene incluido en el sistema. Para esto, debemos configurar el parámetro del sistema login/no_automatic_user_sapstar con el valor 1. Si el parámetro está activo, o sea con el valor 1, SAP* no es válido en el sistema. Si el registro maestro de usuario de SAP* es borrado, el logon con la contraseña pass no funciona.

Si quisiéramos reinstalar el comportamiento anterior de SAP*, debemos cambiar el parámetro con el valor 0 y reiniciar el sistema.

Es conveniente activar el parámetro en el perfil global del sistema DEFAULT.PFL para que tenga efecto en todas las instancias del sistema (de todas formas si existiera el parámetro también en un perfil de instancia con el valor 0, este sobrescribe el que está en el perfil global).

También crear el registro maestro de usuario SAP* en todas las instancias y así asegurar que no se podrá ingresar con el usuario pass si el parámetro es desactivado (valor 0).

Lección 5: Concepto Administración Avanzada de Usuarios

Administración Central de Usuarios

Figura 85 – Administración Central de Usuarios

Cuando tenemos que operar múltiples sistemas SAP con una determinada cantidad de clientes y tenemos que crear usuarios idénticos varias veces en diferentes clientes, podemos reducir significativamente el esfuerzo de administración usando Administración Central de Usuarios, que por las siglas en inglés se conoce como CUA (Central User Administration). Podremos realizar la administración de forma central desde un cliente si utilizamos CUA. Este cliente se denomina Sistema Central (Central System). Los clientes para los cuales se realiza la administración desde el sistema central se denominan Sistemas Hijos (Child Systems).

Puedes especificar para cada usuario en que clientes podrá ingresar. Utilizando CUA no significa que todos los usuarios pueden ser usados en todos los clientes del landscape. Puedes también especificar que información del registro maestro de usuario podrá ser mantenida de forma central y que información se podrá mantener de forma local

también. Algunas veces es útil permitir que cierta información de usuarios sea mantenida de forma local por los usuarios o por un administrador en los sistemas hijos.

La información del usuario se intercambia mediante ALE. ALE significa Application Link Enabling y es una tecnología para configurar y operar aplicaciones SAP distribuidas. ALE permite un proceso de intercambio controlado de mensajes de negocio entre sistemas SAP que no tienen una conexión permanente. El procesamiento asincrónico de la comunicación asegura que la operación sea libre de errores.

Figura 86 - ¿Qué Información Puede Ser Distribuida?

La siguiente información puede ser distribuida utilizando CUA:

Registro Maestro de Usuarios: Dirección, Datos Logon, Valores Fijos, Parámetros (addresses, logon data, user defaults y user parameters) Los usuarios son asignados a los roles simples o compuestos y los perfiles para todos los sistemas hijos. Utilizar CUA tiene la ventaja que como administradores no necesitamos ingresar a cada cliente para gestionar estas asignaciones localmente.

Contraseña inicial: Cuando los usuarios son creados una contraseña inicial es transferida a los sistemas hijos donde el usuario existirá. Esta luego será modificada de la forma tradicional.

Bloqueo: adicionalmente a las formas normales de bloqueo (intentos fallidos de logon o bloqueos por el administrador) hay un nuevo bloqueo general. Este tiene efecto en todos los sistemas hijos en los que un usuario existe y puede quitarse el bloqueo de forma local en cada cliente o de forma central desde el sistema central.

Es posible asignar un rol simple o compuesto y perfiles de autorización desde el sistema central. De todas formas, los perfiles de autorización se mantienen localmente más bien que de forma central ya que diferentes configuraciones de sistema y versiones pueden requerir una administración local de los perfiles de autorización.

Comunicación y Logística de Software

Lección 1: Fundamentos de Conexiones RFC

Los sistemas SAP pueden comunicarse entre sí utilizando Llamadas de Funciones Remotas, que por sus siglas en inglés se conocen como RFCs (Remote Function Calls). Un prerrequisito para esto es que el administrador haya configurado el sistema de interfaces.

Fundamentos de RFC

Las Llamadas de Funciones Remotas han sido utilizadas por muchos años como la interfaz técnica con la que los sistemas SAP y no-SAP usualmente se conectan. No tiene relevancia si el intercambio de información se realiza de manera sincrónica o asincrónica, periódica o aperiódica, o transaccional.

Figura 87– La interfaz RFC

Una RFC es la llamada a un módulo de función que está corriendo en un sistema diferente al programa que realiza la llamada. Podemos llamar a un módulo de función en el mismo sistema mediante una RFC también. De todas maneras, las RFCs normalmente son utilizadas cuando los módulos de funciones, el que llama y el que recibe el llamado, se encuentran en sistemas diferentes.

En el sistema SAP, el sistema de interfaz RFC provee esta función. El sistema de interfaz RFC permite llamadas a funciones entre dos sistemas SAP o entre un sistema SAP y un sistema no-SAP externo.

RFC es un protocolo de interfaz de SAP basado en la intefaz de Programación Común Para Comunicaciones, por sus siglas en inglés CPI-C (Common Programming Interface for Communication) y permite comunicación entre programas de diferentes hosts. Esto permite que las aplicaciones externas puedan llamar funciones ABAP y los sistemas SAP contactar aplicaciones externas que sean compatibles mediante RFC.

RFC significa que los programadores ABAP no tienen que escribir sus propias rutinas de comunicación. Para una llamada RFC, la interfaz RFC:

Convierte todos los parámetros al formato requerido en el sistema remoto.

Invoca a las rutinas de comunicación que se requieren para la comunicación con el sistema remoto

Maneja los errores que pueden ocurrir durante la comunicación.

La interfaz RFC es de fácil utilización para los programadores ABAP. Los pasos de procesamiento para el llamado a los programas externos están integrados dentro de la sentencia CALL FUNCTION.

Figura 88 – Conexiones RFC

Para poder llamar a una función remota (en un sistema remoto), deberemos definir el sistema remoto como un destino en el sistema desde donde realizamos la llamada. También se requiere autorización de acceso para el sistema remoto.

Se pueden manejar estas conexiones remotas en el sistema que llama. Para hacer esto, utilizamos la función Display and Maintain RFC Destinations, ya sea seleccionando desde el árbol del menú del sistema la ruta Administration → Administration → Network → RFC Destinations o directamente llamando a la transacción SM59. Los tipos

de conexión y todos los destinos existentes se muestran en una estructura de árbol en la pantalla inicial. Para detalles sobre los tipos de conexión disponibles, podemos observar la documentación.

Hay una función de búsqueda para los destinos que ya están configurados. Para

realizar una búsqueda, selecciona Search y luego ingresa el nombre o parte del nombre. El sistema mostrará una lista de las entradas que concuerden.

Para modificar una conexión RFC existente, seleccionamos el destino RFC en el menú

de árbol y seleccionamos Change

Para copiar una conexión RFC existente, primero tenemos que ingresar a la conexión RFC que queremos copiar. Luego seleccionar Connection → Copy.

Variantes de Utilización de RFC

RFC sincrónica (sRFC)

Para comunicación entre diferentes sistemas y entre SAP Netweaver AS y SAP GUI. En estas comunicaciones el llamado a la función remota se basa en una comunicación sincrónica por lo que el sistema remoto debe estar disponible en el momento de la llamada.

RFC asincrónica (aRFC)

Para comunicación entre sistemas y para procesamiento paralelo de tareas. Con este tipo de comunicación, aunque no es realmente asincrónica ya que el sistema remoto debe estar disponible al momento de la comunicación, el sistema origen (desde donde se realiza la llamada a la función remota) no necesita esperar una respuesta del sistema remoto para continuar su procesamiento y en este sentido es por el cual se denomina asincrónica.

RFC transaccional (tRFC)

Este método si utiliza una forma de comunicación realmente asincrónica. El sistema remoto no necesariamente debe estar disponible al momento de la llamada por el programa en el sistema origen. Si una llamada es ejecutada y el sistema destino no está disponible, la llamada se mantiene en una cola local del sistema origen. El programa que ejecutó la llamada puede proceder sin esperar si el resultado de la llamada fue exitoso o no.

RFC encolada (qRFC)

Para garantizar que se procesen en el mismo orden en el que se realizaron las llamadas en el sistema origen, qRFC garantiza esto. Es una extensión de tRFC. Se utiliza cuando necesitamos que el procesamiento se realice con un orden predefinido (establecido por el orden de los llamados desde el programa en el sistema origen). RFC es un término general para diferentes variantes de implementación. sRFC es la llamada de módulo de funciones sincrónica. Esto significa que el cliente espera hasta que el servidor ha completado el procesamiento de la función remota.

Dentro un sistema SAP, una RFC puede también ser ejecutada de forma asincrónica mediante el uso de otro work process. La variante se conoce como aRFC.

También está tRFC que es la Llamada de Función Remota Transaccional, la cual es asincrónica ya que asegura que la información puede ser enviada más de una vez al sistema destino si problemas de comunicación en la red suceden y son reconocidos del lado del servidor. Para esto un identificador de Transacción (TID) se asigna al llamado. Esto es útil para prevenir que la información se procese más de una vez en el sistema lo que podría ocasionar información errónea en la aplicación debido al procesamiento asincrónico.

qRFC con cola de envío es una extensión de tRFC. Crea una capa entre la aplicación y tRFC y permite enviar los parámetros de la función remota si no existen ejecuciones anteriores pendientes en la cola. Luego de que una unidad lógica de trabajo (LUW) es

ejecutada, el coordinador de qRFC automáticamente procesa el siguiente llamado en concordancia con la secuencia de la cola.

Lección 2: Configuración de Conexiones RFC

Transacción SM59

Lección 3: Estructura de Sistemas SAP

En esta lección veremos la estructura de datos de un sistema SAP. Téminos como cliente, customizing (adaptación) dependiente de cliente y customizing inter-cliente (cross-client), datos maestros y de transacciones, datos de usuario y repositorio de objetos serán descriptos. Por último las opciones para modificar y crear objetos de repositorio serán parte de la lección también.

El software de SAP necesita ser adaptado a los requerimientos específicos de las compañías. ¿Cómo podemos transferir esas adaptaciones desde el sistema de desarrollo al sistema de producción? El esfuerzo de trabajo extra debemos procurar que sea mínimo cuando importamos Support Packages o durante un posible Upgrade del sistema. Veremos cómo se relacionan estos en SAP.

Estructura de Datos en un Sistema SAP

Conocer la estructura de datos de un sistema SAP es igualmente importante tanto para los usuarios, desarrolladores y administradores para entender de qué manera un sistema SAP funciona.

Figura 89 – Estructura de Datos de un Sistema SAP

Los sistemas SAP tienen una estructura de datos específica. Adicionalmente a las configuraciones de negocio (customizing) que son relevante únicamente para ciertos clientes del sistema SAP, también contiene configuraciones y el repositorio de objetos que son inter-clientes (cross-client).

El repositorio es el lugar de almacenamiento central para todos los objetos de desarrollo de Workbench ABAP y es inter-cliente. Los objetos de repositorio se almacenan en paquetes (packages).

Los paquetes son contenedores para objetos de desarrollo relacionados semánticamente. Diferentes objetos de desarrollo (programas, tablas, pantallas, módulos de función, clases, etc) pueden estar contenidos dentro de un paquete.

Los paquetes están caracterizados por ciertas propiedades:

Anidado (nesting) Interfaces (interfaces) Visibilidad (visibility) Accesibilidad (accesibility)

Los paquetes son creados y mantenidos con Package Builder, la transacción SPAK. El grabado y transporte de modificaciones de objetos está controlado por el Sistema de Transportes y Cambios, que por sus siglas en inglés se denomina CTS (Change and Transport System) utilizando la asignación de objetos de repositorios a paquetes.

Customizing

El término Customizing, que se podría traducir como adaptaciones, describe las configuraciones de negocio de un sistema SAP. Las funciones provistas tantos generales de una compañía como aquellas que pueden ser específicas para una industria son adaptadas a los requerimientos específicos de la empresa en el proceso de Customizing.

El Customizing comprende cosas simples y básicas como la definición de plantas y almacenes hasta cosas más complejas como funciones de compras basadas en planificación de producción o liquidación de nómina.

Una gran cantidad de Customizing estándar tal como definiciones de país, lenguaje, uso horario están incluidas por SAP como parte de las instalaciones.

El sistema SAP diferencia entre Customizing dependiente de cliente y Customizing inter-clientes. Customizing inter-clientes contiene configuraciones que son independientes de una unidad de negocio particular y tienen una validez general. Entre otros incluye el calendario, configuraciones de impresión o el acceso a la ayuda.

Clientes

Los sistemas SAP están divididos entre unidades de negocio o clientes, que también se conocen como mandantes.

Un cliente es una unidad comercial, organizacional y técnica contenida en un sistema SAP y consiste de configuraciones de negocio (customizing dependiente de cliente), sus propios datos maestros y transaccionales y sus propios datos de usuarios. Los datos de un cliente se conocen como datos dependientes de cliente o específicos de cliente.

Los tipos de datos que son dependientes de un cliente están relacionados entre sí. Por lo tanto, cuando ingresamos información en una aplicación, el sistema verifica si la información ingresada concuerda con la configuración específica de ese cliente (Customizing). Si hay inconsistencias, la información ingresada en la aplicación es rechazada. Esto nos dice que la información de una aplicación es significativa en términos del negocio solamente en el cliente con el Customizing correspondiente. Ejemplos de Customizing dependiente de cliente son los códigos de compañía, plantas y almacenes.

Datos Maestros y de Transacciones son dependientes del cliente también. Son únicamente válidos en el cliente. Esto incluye por ejemplo registros maestros de materiales, órdenes y facturas. Los datos de usuario también son dependientes de cliente.

Varios roles de clientes son utilizados en un sistema SAP. Un cliente de Customizing puede ser configurado para las configuraciones que sean dependientes de cliente en el sistema de desarrollo. En un sistema de calidad, un cliente puede crearse para

propósitos de pruebas y en un sistema de producción, un cliente para trabajo productivo. Los roles se asignan a los clientes desde la transacción SCC4.

Repositorio de Objetos

Figura 90 – Ajustes a las Estructuras de Datos

Así como el Customizing dependiente de cliente e inter-cliente, es posible realizar ajustes adicionales a la estructura de datos de un sistema SAP también. Se pueden realizar cambios o mejoras en el repositorio de objetos. Los cambios o mejoras al repositorio pueden realizarse en diferentes formas:

Extensión del repositorio a través de desarrollos del cliente (customer developments): en el sistema SAP, es posible crear objetos de repositorio propios tales como tablas, programas, transacciones, etc. Todos los desarrollos del cliente son usualmente realizados en el espacio de nombres del cliente y deben comenzar con la letra Y o Z, entre otras cosas. Es posible, de todas formas, también requerir un nombre de espacio propio a SAP que empiece y termine con el caracter /. Este tendrá un máximo de ocho caracteres inlcuyendo /, tal como /Firma/.

Todos los objetos que se creen bajo el nombre del espacio tendrán un nombre que empezará con /Firma/, tal como /Firma/Evaluacion1.

Mejoras de cliente (customer enhancement): el repositorio es suplementado por sub-objetos del cliente aquí. Por ejemplo, un programa estándar de SAP puede ser suplementado con código propio del cliente en puntos predefinidos en el código conocidos como customer exits (salidas de cliente). Las estructuras de tablas pueden ser ampliadas con campos propios utilizando appends (agregados)

Modificaciones al estándar del sistema SAP: cambios a objetos estándar de SAP (programas, tablas, estructuras) se conocen como modificaciones. El repositorio de objetos que vienen junto con el sistema SAP en este caso no es extendido sino directamente modificado.

Varios tipos de modificaciones son posibles, dependiendo del tipo de objeto:

Modificaciones manuales Modificaciones con el asistente de modificaciones Modificaciones con el asistente de notas

Landscape de Tres Sistemas

SAP recomienda un landscape de sistemas múltiples basado en la conformación de la estructura de datos de un sistema SAP, en la que existe solo un repositorio de objetos por sistema. Nunca se debe desarrollar en un sistema SAP que se utiliza también como productivo. En circunstancias normales, un landscape de tres sistemas es suficiente para la operación.

Figura 91 – Landscape de tres sistemas

Como el repositorio de objetos es inter-cliente, SAP recomienda que no se desarrolle en un sistema que al mismo tiempo se utiliza para trabajar en forma productiva, ya que esto conlleva un riesgo de una posible inconsistencia de datos. Si se van a realizar cambios al repositorio, SAP recomienda que se utilice al menos dos, pero idealmente tres sistemas separados. Un sistema para desarrollos, un segundo sistema para pruebas y aseguramiento de la calidad y un tercer sistema productivo.

Un landscape de tres sistemas facilita el siguiente proceso recomendado:

Se realizan desarrollos propios de cliente en el repositorio de objetos y las configuraciones (Customizing) requeridas en el sistema de desarrollo. Las configuraciones de Customizing realizadas, así también como todos los cambios (desarrollos, mejoras y modificaciones) al repositorio se registran en el sistema de desarrollo.

Estos cambios son luego transportados al sistema de calidad y se verifican allí, sin influenciar la operación de producción. Una prueba de aceptación usualmente no es posible realizarse en el sistema de desarrollo, ya que los datos reales no están disponibles en este sistema para una prueba real. La razón principal, de todas formas, es que el sistema de desarrollo no ofrece un

ambiente estable para una prueba comprensiva e integral: muchos desarrolladores trabajan en un número de diferentes proyectos al mismo tiempo.

Luego de que se han probado satisfactoriamente, todos los objetos y configuraciones en el sistema de calidad pueden ser transportados al sistema de producción. Diferentes clientes pueden ser creados para propósitos específicos. Si realizamos un Customizing dependiente de cliente en el sistema de desarrollo y queremos verificarlo antes de transportarlo a los demás sistemas, puede utilizarse un cliente de prueba en el mismo sistema de desarrollo para tal propósito.

Clientes con roles específicos son usualmente creados en cada sistema: un cliente de desarrollo en el sistema de desarrollo, un cliente para pruebas en el sistema de calidad y un cliente productivo en el sistema de producción.

Generalmente, los clientes principales de cada sistema tienen el mismo número ya que por defecto cuando transportamos el cliente origen es igual al cliente destino. Esto último de todas formas no es obligatorio.

Lección 4: Transportes en SAP

Los cambios que los desarrolladores realizan en el sistema de desarrollo deben ser transportados al sistema de calidad para realizar las pruebas necesarias y luego al sistema de producción. El transporte de cambios es una de las tareas del administrador del sistema o de un administrador de transportes.

Órdenes de Transportes y Tareas

Los transportes de Workbench y Customizing pueden ambos ser creados con el Organizador de Transportes (Transport Organizer), transacción SE09 o SE10. Como parte de una orden de transporte, el líder de proyecto es quien se encarga de definir tareas para el tipo de orden (Workbench o Customizing) y asigna cada una a un usuario correspondiente.

Después que cada tarea individualmente es liberada, la orden de transporte puede ser liberada también. Liberar la orden de transporte genera que esta sea exportada. Después de que se realiza la exportación, la orden de transporte está en condiciones de ser importada en el sistema destino.

En un sistema de desarrollo, las configuraciones de Customizing son realizadas y modificadas, los objetos de repositorio son creados y los que existen son modificados.

Para transportar estos objetos en los sistemas siguientes del landscape, necesitamos una orden de transporte. Sin una orden de transporte no podemos transportar configuraciones de Customizing u objetos de repositorio. Esto es porque, dependiendo de la configuración del sistema, necesitaremos asignar a una tarea, la cual está incluida en una orden de transporte, cada modificación o nuevo objeto que creemos o configuración de Customizing que realicemos.

Cuando un proyecto de desarrollo comienza, el líder del proyecto idealmente deberá crear una o más órdenes de transporte. Durante el proceso las personas involucradas en el proyecto son asignadas a tareas dentro de esas órdenes de transporte.

Una orden de transporte por lo tanto pertenece al líder del proyecto y generalmente comprende varias tareas, cada una de ellas asignada a una persona para el proyecto.

Figura 92 – Estructura de Órdenes de Transporte

El Organizador de Transportes

Uno de los lugares donde podemos crear una orden de transporte es en el Organizador de Transportes, transacción SE09.

Figura 93 - El Organizador de Transportes

El Organizador de Transportes genera un nombre para la orden de transporte creada. Este nombre se compone del SID del sistema de desarrollo, o mejor dicho, del sistema donde estamos creando la orden. Luego, los caracteres K9 y cinco dígitos que combinados forman una secuencia alfanumérica. Por ejemplo DEVK901234.

Una orden de transporte debería contener objetos que están lógicamente relacionados y serán transportados juntos. Esto es, una orden de transporte nos permite transportar y administrar desarrollos completos, lógicos y auto-contenidos. Una nueva orden de

transportes no es requerida para cada objeto, ya que esto resultaría en una gran cantidad de órdenes de transportes y la administración se volvería compleja y confusa lo que también llevaría a errores con los transportes potencialmente.

El Organizador de Transportes crea una tarea para cada persona involucrada en la orden de transporte. Si una persona asigna un objeto a la orden de transporte, el objeto se registra en la tarea de esa persona. De esta manera, todos los objetos que una persona edita o crea durante el proyecto de desarrollo son registrados en la tarea. La convención de nombres para las tareas es la misma que para las órdenes de transporte. Una orden de transporte se diferencia entre varios términos.

El término orden de transporte es el término general o neutral. Una orden de modificación o cambio es una orden de transporte utilizada para transportar cambios. Los objetos que contiene, pueden por supuesto, ser transportados sin que ningún cambio se haya realizado sobre ellos, tal es el caso de objetos nuevos creados en el repositorio.

Una orden de Workbench es una orden de transportes en la que objetos de repositorio o Customizing inter-cliente son transportados. Una orden de Customizing es una orden de transporte en la que objetos dependientes de cliente son transportados, en otras palabras, Customizing dependiente de cliente, datos maestros, transaccionales o datos de usuario. De los tres, normalmente solamente Customizing dependiente de cliente es transportado. Una orden de consolidación es una orden de transporte que será transportada al sistema de consolidación (sistema de calidad).

Transportes

El transporte de objetos está dividido en las fases de Exportación e Importación: los objetos son exportados desde el sistema de desarrollo e importados en los sistemas destino tales como el sistema de calidad y el sistema de producción.

Figura 94 – Transportes en un Landscape de Tres Sistemas

La liberación de una orden de transporte dispara la exportación de los objetos que se encuentran registrados por nombre en la orden de transporte. Estos objetos se almacenan ahora en archivos de datos (data files) en el directorio de transportes central. La información respecto del éxito de la liberación y la exportación queda guardada en el log (registro) de transporte de la orden de transporte.

La importación en el sistema destino es usualmente no automática, pero es iniciada por el administrador de transportes en el Sistema de Gestión de Transportes, que por sus siglas en inglés se conoce como TMS (Transport Management System) y podemos acceder mediante la transacción STMS.

Los registros de importación también son guardados en el log de transporte.

Figura 95 – Log de Transporte

En términos técnicos, una copia de los datos desde la base de datos del sistema de desarrollo se escribe al directorio de transportes central durante la exportación de la orden de transporte. Durante la importación, la orden de transporte almacenada en el directorio central de transporte se copia a la base de datos del sistema destino.

El directorio central de transporte está físicamente ubicado en un sistema de archivos (file system) al cual todos los sistemas que pertenecen al landscape de SAP tienen acceso de lectura y escritura.

Cada sistema encuentra la ubicación del directorio de transportes que utilizará, ya sea para escribir o leer las órdenes de transporte, por medio del parámetro de perfil DIR_TRANS. La ubicación por defecto del directorio de transportes es:

/usr/sap/trans De todas maneras, esto puede ser adaptado según los requerimientos. Solo en casos excepcionales puede ser necesario utilizar varios directorios de transporte locales en vez de un directorio central. Esto hace que el proceso de transportes sea un poco más complejo, pero podría ser útil en algunos casos por razones de seguridad de la red.

Importación

El administrador de transportes usualmente inicia la importación en los sistemas subsiguientes manualmente usando el TMS (Transport Management System) en el sistema SAP correspondiente, con la transacción STMS.

En los sistemas posteriores a desarrollo, podemos ver que ordenes de transportes están encoladas para ser importadas dentro del sistema en la transacción STMS. Desde un punto de vista técnico en un landscape de tres sistemas, la orden de transporte es marcada para importación en el sistema siguiente (sistema de calidad) cuando es exportada desde el sistema de desarrollo.

Es posible ver esta marca de la orden de transporte para importación en el siguiente sistema en el TMS, transacción STMS por medio de la opción de menú Overview →

Imports.

Figura 96 – STMS – Colas de Importación

Esto muestra la cola de importación para el sistema. Para ver los detalles sobre la cola de importación, selecciona Import Queue → Display

Figura 97 – Visualización de Cola de Importación

Existe un número de métodos disponibles en la cola de importación de TMS para importar las órdenes de transporte en el sistema destino. Los métodos más importantes son Import All Transport Requests (Importación Masiva de Ordenes de Transporte) e Import Individual Transport Requests (Importación Individual de Ordenes de Transporte). Es posible ejecutar estos métodos en diálogo o en background.

Figura 98 – Métodos de Importación

Cuando importamos ordenes individuales, tenemos que seleccionar la orden de la cola de importación y luego importarla con la opción indicada. Cuando importamos ordenes de transporte de manera masiva, todas las ordenes en la cola de importación son importadas.

En ambos casos, los objetos son importados primero en orden de importancia y segundo en el orden que tiene la orden de transporte en la cola de importación. Una tabla por lo tanto es más importante que un programa porque el programa puede ser dependiente de la tabla.

El orden de las órdenes de transporte en la cola de importación del sistema de calidad asegura que sea el mismo orden en el que se exportaron desde el sistema de desarrollo. Por comparación, el orden en la cola de importación del sistema de producción se define por el orden con el que se importó en el sistema de calidad.

La cola de importación del sistema de producción puede ser por lo tanto organizada de manera diferente a la del sistema de calidad. Esto es correcto, ya que esto refleja el orden de la importación al sistema de calidad y por lo tanto la aceptación técnica en el sistema de calidad.

En el sistema SAP, el administrador de transportes inicia la importación utilizando la transacción STMS, eligiendo la cola de importación con la opción de menú Overview →

Imports, seleccionando el sistema en el cual la importación se llevará a cabo y eligiendo Import Queue → Display. La importación inicia ya sea con el botón Import All

Requests o Import Request

Técnicamente, el programa tp del sistema operativo es utilizado para la exportación y la importación. La importación siempre usa los archivos de datos que fueron generados y almacenados en el directorio central de transportes durante la exportación.

Lección 5: Órdenes de Customizing

Órdenes de Customizing

Una orden de Customizing puede contener objetos de Customizing dependientes de cliente, datos maestros, datos transaccionales y de usuarios. Normalmente, solamente Customizing dependiente de cliente es transportado en una orden de Customizing. En el caso que sea necesario transportar Customizing inter-cliente deberá ser incluido en una orden de tipo Workbench.

El Organizador de Transporte crea una tarea para cada persona en la orden de transporte. Si una persona asigna un objeto de Customizing a la orden de Customizing, el objetos es registrado por nombre en la tarea de esa persona. De esta manera, todos los objetos de Customizing editados por esa persona se registran en la tarea. Cuando las personas han completado el Customizing, liberan sus respectivas tareas. Esto transfiere los objetos registrados en las tareas a la orden de Customizing. Una vez que todas las personas han liberado sus tareas, el líder de projecto puede liberar la orden de Customizing y por lo tanto realizar la exportación.

Figura 99– Ejecución, Liberación y Transporte de Customizing

La estructura de los proyectos de Customizing es similar a la estructura de proyectos de desarrollo. Las personas involucradas en este caso son el líder de proyecto de Customizing, quien crea y libera las ordenes de Customizing, y los miembros del proyecto, quienes realizan el Customizing y asignan las configuraciones realizadas a la orden de Customizing mediante las tareas.

Los cambios a los datos de Customizing se registran en el Organizador de Transportes y en consecuencia en las tareas de las ordenes de Customizing, aunque en el caso de Customizing, las entradas de tabla que son modificadas son solamente bloqueadas

durante el tiempo que se está trabajando en la modificación y es realizado por el enqueue work process.

Para resumir, podemos decir que las configuraciones que son dependientes de cliente, son modificaciones que se realizan en tablas del sistema, las cuales tienen un campo clave que determina el número de cliente donde estamos trabajando.

Figura 100 – Estructura de una tabla de Customizing

Solamente durante el tiempo que estamos realizando los cambios los registros de dichas tablas estarán bloqueadas con el sistema de bloqueo del sistema SAP. Una vez que guardamos los cambios y quedan registrados en la tarea de Customizing, el bloqueo se libera.

Figura 101 – Vista de una Orden de Customizing en el Organizador de Transporte

Lección 6: Órdenes de Workbench

Órdenes de Workbench

Las órdenes de Workbench son órdenes de transporte de Customizing inter-cliente y objetos de repositorio. El proceso ilustrado aquí es utilizando objetos de repositorio como ejemplo. El proceso para el Customizing inter-cliente es el mismo que para las órdenes de Customizing.

El Organizador de Transportes crea una tarea para cada persona en la orden de transporte. Si una persona asigna un objeto de repositorio a la orden de transportes, el objeto de repositorio es registrado por el nombre en la tarea de esa persona.

Cuando el proyecto de desarrollo está completo desde el punto de vista del miembro del proyecto, él o ella libera su tarea. Esto transfiere el objeto en la tarea a la orden de transporte.

Una vez que todas las personas han liberado sus tareas, el líder del proyecto de desarrollo puede liberar la orden de transporte y, en consecuencia, se genera la exportación de la orden de transporte. Una orden de Workbench, por lo tanto, agrupa objetos de repositorio con los que se han trabajado durante un proyecto de desarrollo.

Figura 102 – Desarrollo, Liberación y Transporte de Objetos de Respositorio

Si un objeto de repositorio es editado e incluido en una orden de transporte por un desarrollador, este objeto se encuentra reservado exclusivamente para ser procesado en esta orden de transporte. Cambios a este objeto pueden ser realizados por los desarrolladores que también tengan tareas en la orden de transporte.

El desarrollo o mantenimiento de los objetos está bloqueado para todos los otros desarrolladores que no están involucrados en la misma orden de transporte hasta que la misma es liberada. Estos desarrolladores solo podrán visualizar los objetos.

Figura 103 – Ejemplo de Objeto de Repositorio en el Editor ABAP

Cada persona que está involucrada en la orden de transporte y edita el objeto recibe una entrada correspondiente en la lista de objetos de su tarea. De esta manera, es posible determinar quien o quienes editaron un objeto.

Figura 104 - Visualización de una orden de Workbench en el Organizador de

Transportes

Los objetos son desbloqueados cuando la orden de transporte es liberada. Otros desarrolladores pueden luego trabajar sobre el objeto nuevamente. En los cambios a los datos de Customizing, también son registrados por el Organizador de Transportes, pero las tablas solo están bloqueadas durante el proceso de modificación por el enqueue work process. No hay bloqueo de objetos para Customizing.

El Organizador de Transportes también lleva el versionado de los objetos de repositorio, permitiendo comparaciones y también el acceso a versiones anteriores. De esta manera, es posible documentar y recrear si es necesario, los diferentes estados, posteriores y anteriores, a una orden de transporte o un proyecto de desarrollo. Una versión es generada cuando la orden de transporte es liberada.

Mantenimiento del software SAP

Lección 1: Notas y Support Packages Luego de que finalizamos la instalación de un sistema SAP, es muy probable que necesitemos importar ajustes que se realizaron debido a cambios en requerimientos legales, y corregir errores que podría haber en el software del sistema SAP.

SAP provee las notas de SAP y los Support Packages para este propósito.

Notas SAP y Support Packages

Un sistema SAP se conforma de varios componentes de software. Estos componentes se actualizan regularmente a través de Notas de SAP y Support Packages . Ambos son utilizados para importar al sistema cambios en requerimientos legales, corregir errores y en algunos casos mejorar ciertas funciones existentes o incorporar nuevas funciones.

El sistema SAP debería siempre tener el nivel de actualización más reciente, por un lado para cumplir con los requerimientos legales que puedan existir en el lugar donde opera y para eliminar los errores que existen en el estándar por otro.

Figura 105 – Notas SAP y Support Packages

Las Notas de SAP pueden contener información general, recomendaciones o indicaciones de SAP. También pueden describir un problema y su resolución al error en funciones estándar del software SAP. Este último tipo de Notas SAP contiene una solución a un problema individual, el cual es generalmente una corrección a un error de programación, que obtenemos en la forma de líneas de código fuente con las modificaciones necesarias para solucionar el error.

Las notas de SAP son muy utilizadas por los administradores de sistema para resolver problemas específicos como errores en tiempo de ejecución de programas estándar o fallas en los componentes del kernel por ejemplo. La base de notas de SAP puede accederse a través del enlace rápido http://service.sap.com/notes. La base de Notas de SAP se encuentra dentro del Marketplace de SAP (http://service.sap.com) pero necesitamos de un usuario especial para poder ingresar llamado usuario S.

Cada cliente de SAP es provisto por un super usuario S el cual luego puede crear usuarios S adicionales con diferentes permisos dentro de Marketplace.

Los Support Packages son un conjunto de objetos de repositorio. En principio, cada componente de software para cada nivel de versión tiene sus propios Support Packages. En el caso de componentes de software que intersectan (con add-ons modificados, por ejemplo), existe un tipo de Support Package adicional llamado Transporte de Resolución de Conflictos, que por sus siglas en inglés se conoce como CRT (Conflict Resolution Transport)

Los add-ons se implementan para soluciones de industria específica y modifican un componente de software estándar (tal como por ejemplo SAP_APPL).

Técnicamente hablando, los Support Packages son un tipo de orden transporte que no puede ser importada por los métodos normales que vimos en la unidad anterior. Un Support Package contiene todas las Notas de SAP relevante a ese componente de software y versión que se crearon desde el Support Package anterior al mismo. Los Support Packages son por lo tanto no acumulativos y requieren siempre del anterior para poder ser implementado.

Los Support Packages son implementados en el sistema con el Support Package Manager, transacción SPAM. Las Notas de SAP son implementadas con el Asistente de Notas, transacción SNOTE.

Transacción SNOTE

El Asistente de Notas se accede a través de la transacción SNOTE. Desde el SNOTE podemos implementar varios tipos de notas: cambios a programas SAP, creación de nuevos programas SAP, cambios a módulos de función SAP y varias otras cosas. De todas formas, el Asistente de Notas no puede modificar objetos de Diccionario por ejemplo. Además, el Asistente de Notas puede sólo modificar objetos de repositorio y no Customizing.

Figura 106 – Asistente de Notas: proceso de implementación

Siguiendo la Figura 106, Las Notas de SAP se implementan con el Asistente de Notas en los siguientes pasos:

1. Primero debemos localizar la Nota de SAP requerida en el SAP Marketplace, por ejemplo, buscando por palabras claves o utilizando el número de nota si es que ya conocemos cual es la que necesitamos.

2. Luego podemos cargar la Nota de SAP al sistema de desarrollo mediante el Asistente de Notas (SNOTE)

3. La Nota de SAP es verificada por el Asistente de Notas. Verifica si el nivel de versión del componente de software donde se va aplicar y el nivel de actualización de Support Package del mismo son correctos para los prerrequisitos de la nota. También verifica si la nota requiere de otras notas previamente implementadas y si puede ser implementada cuando existen otras modificaciones sobre los objetos que están afectados por la misma.

4. La Nota de SAP es implementada mediante la función de importación. Esto crea una orden de transporte.

5. El resultado de la implementación de la Nota de SAP se prueba en forma general en el sistema de desarrollo. Si la Nota no corrige el problema puede desimplementarse también mediante la transacción SNOTE.

6. Si el resultado de la prueba es exitoso, por ejemplo si el error ya no se produce luego de implementar la nota en el programa que corrigió, la orden de transporte se libera y se importa en el sistema de calidad mediante el sistema de transportes. La aceptación técnica se realiza en este sistema.

7. Si también resulta correcta la aceptación, entonces la orden de transporte es importada en el sistema de producción.

Support Packages Stacks

En principio, la importación de Support Packages para un componente de software en particular es independiente de los Support Packages de otros componentes de software.

Los componentes individualmente son en general independientes de otro u otros componentes de software. De todas maneras, pueden existir casos donde la importación de Support Packages para un componente en particular tenga algunos requisitos con otros Support Packages en otro componente. Esto significa que por ejemplo la importación de un Support Package de HR puede requerir la importación previa de un Support Package determinado del componente BASIS, o un Support Package de APPL.

También puede suceder que aunque no sea un requisito cierto nivel de Support Package en otro componente de software, resultan efectos adversos. Estos efectos adversos (side-effects) son documentados en una Nota de SAP en cuanto son detectados.

Para que podamos implementar las correcciones de manera consistente en los diferentes componentes de software, SAP recomienda importar los Support Packages usando Support Package Stacks.

Support Packages Stacks son una combinación de Support Packages de diferentes componentes de software que incluyen un nivel determinado a cada componente y evita los inconvenientes de dependencias y efectos adversos descriptos anteriormente. Los Support Packages Stacks están disponibles para varias de las aplicaciones de SAP y para componentes de SAP Netweaver también.

Adicionalmente a los Support Packages Stacks, también contienen actualizaciones para otros componentes, tales como actualizaciones del kernel del sistema. Esto es importante porque incluso puede ser necesario que actualicemos el kernel del sistema SAP para asegurarnos que no sucedan errores con un nuevo nivel determinado de Support Packages.

En el Marketplace de SAP podemos consultar información sobre los Support Packages de los diferentes componentes de software de SAP así también como de los Stacks, como están conformados y también determinar los Support Packages que necesitaremos descargar para pasar del Stack actual al que necesitemos actualizar.

El problema que surge frecuentemente es como actualizar un landscape complejo de SAP, así también como la duda de cómo utilizar los Support Package Stacks para una actualización ordenada y documentada.

¿Cuál es el nivel de actualización actual de mi landscape SAP? ¿Dónde puedo encontrar la información necesaria sobre Support Packages y Stacks?

El Optimizador de Mantenimiento (Maintenance Optimizer) provee la solución a estas preguntas. Con el Optimizador de Mantenimiento pueden requerirse los Support

Package Stacks necesarios para el landascape definido en el Solution Manager en una forma controlada y gestionable.

El Optimizador de Mantenimiento es mandatorio para algunos Support Packages y Stacks, tales como los Support Packages para SAP ECC 6.0 que fueron liberados a partir de Abril de 2007. Si queremos visualizar el estado actual de nivel de Support Packages para los componentes de software de nuestra implementación, podemos hacerlo desde cualquier pantalla de SAP, desde la opción de menú System → Status

Figura 107 - Estado de Sistema

Figura 108 – Información de Componentes de Software

Enhancement Packages

Un upgrade de sistema, por ejemplo de SAP R/3 4.6C a SAP ECC 6.0, es un upgrade completo de sistema a una nueva versión. Luego del upgrade, el sistema funciona con todas las funciones de la nueva versión. Antes de que pueda ser utilizado en la operación de producción es necesario realizar muchos ajustes. Estos incluyen ajustes a modificaciones del estándar, cambios a customizing, cambios a desarrollos propios del cliente y mejoras.

Las pruebas de aceptación necesarias también consumen gran parte del tiempo. Normalmente se necesita un período de varios meses para un proyecto de upgrade para un landscape de sistemas SAP. Esto lo hace que sea de un esfuerzo considerable de recursos y tiempo, por lo tanto costoso.

Para reducir el costo y esfuerzo que involucra, SAP está cambiando paulatinamente a liberar los Enhancement Packages (EhP) para todas las aplicaciones. Esto comenzó con SAP ERP 6.0 en 2007 con el EhP 2.

Enhancement Packages son nuevas versiones completas para un componente de software particular en el sistema SAP, en otras palabras, son upgrades parciales del sistema.

El Panel de Activación (Switch Framework) el cual está disponible a partir de AS ABAP 7.0 es usado para este propósito. Utilizando el Panel de Activación, se pueden realizar cambios a los objetos de repositorio y no utilizarlos ya que necesitaremos activarlos en primer lugar. Esto significa que podemos importar un Enhancement Package para un componente de software en particular y mientras no activemos la o las funciones que incorpora este Enhancement Package desde el Panel de Activación, el sistema seguirá funcionando como antes de la importación.

Desde un punto de vista técnico, esto significa que un programa puede existir en el repositorio en diferentes estados al mismo tiempo. Por lo tanto cuando activamos la función desde el Panel de Activación, lo que estamos haciendo es activar una determinada versión para los objetos de repositorio que dependen de esa función.

La importación de Enhancemente Packages solamente no genera un esfuerzo considerable. Ahora es posible solo activar las funciones que van a ser requeridas desde el punto de vista funcional. Eso mantiene el esfuerzo requerido para la implementación y prueba de forma razonable.

Figura 109 – Enhancement Packages y Componentes de Software

Los Enhancement Packages son por lo tanto upgrades a componentes de software individuales, con la ventaja adicional de que podemos activar las nuevas funciones de una forma controlada y solamente cuando son necesarias.

Las ventajas de los Enhancement Packages son:

Procesos centrales estables Adaptación simple a requerimientos legales Tecnología estable Planificación y mantenimiento sencillo Disminución de upgrades de sistemas

Nuevas funciones pueden ser implementadas selectivamente cuando son requeridas

A diferencia de los Support Packages, los Enhancement Packages son acumulativos, lo que significa que no necesariamente debemos importarlos en secuencia. Por ejemplo, el Enhancement Package 4 para SAP ERP 6.0 contiene a Enhancement Package 2 y 3 por lo que podremos implementar directamente la última versión directamente.

La importación de Enhancement Packages se realiza mediante la transacción SAINT, la cual es para la implementación y actualización de componentes de software. De todas formas, a partir de EhP 4 para SAP ERP 6.0 existe una herramienta externa llamada Ehpi (Enhancement Package Installer) para este propósito.

Los Support Packages al estar vinculados con la versión del componente de software existen en diferentes niveles para cada versión de componente de software. Esto significa que luego de la implementación de Enhancement Package 2 para SAP ECC 6.0, los Support Packages que necesitaremos posteriormente deberán ser para SAP ECC 6.0 EhP 2

Lección 2: Configuración de Impresoras

El administrador configura las impresoras en el sistema SAP y monitorea la salida de los spool requests.

Impresión en el Sistema SAP

Existen varias clases de documentos en el sistema SAP, tales como listas de reportes, SAPscript o SAP Smart Forms. Aunque la manera en que se crean estos documentos es completamente diferente, la salida de impresión en papel de estos documentos siempre se realiza utilizando el mismo mecanismo de dos etapas:

Primero un spool request es creado. El spool request contiene información de impresión independiente del dispositivo de salida e incluye información administrativa tal como autor, fecha, número de copias y la información que se va a imprimir.

Solamente cuando el spool request va a ser direccionado a un dispositivo en particular un output request es creado. La información independiente de dispositivo del spool request es convertida al lenguaje particular de la impresora que comprende el dispositivo de salida seleccionado.

El administrador configura las impresoras en el sistema SAP y monitorea la salida de los spool requests.

Impresión en el Sistema SAP

Existen varias clases de documentos en el sistema SAP, tales como listas de reportes, SAPscript o SAP Smart Forms. Aunque la manera en que se crean estos documentos es completamente diferente, la salida de impresión en papel de estos documentos siempre se realiza utilizando el mismo mecanismo de dos etapas:

Primero un spool request es creado. El spool request contiene información de impresión independiente del dispositivo de salida e incluye información administrativa tal como autor, fecha, número de copias y la información que se va a imprimir.

Solamente cuando el spool request va a ser direccionado a un dispositivo en particular un output request es creado. La información independiente de dispositivo del spool request es convertida al lenguaje particular de la impresora que comprende el dispositivo de salida seleccionado.

Figura 110 – Flujo de datos durante la impresión

Este proceso permite al usuario visualizar el spool request antes de la salida. Puede haber muchos output requests para un spool request. Esto puede evitar que el usuario tenga que recrear un spool request, si por ejemplo, el toner de la impresora está agotado o el papel incorrecto se encontraba en la bandeja. Por supuesto que también la impresión puede ser al mismo tiempo de la creación del spool request mediante la selección de la opción impresión inmediata (Print out immediately).

El contenido real de un documento de un spool request se almacena en el TemSe (para objetos secuenciales temporales), el cual se define el lugar donde se almacenará mediante el parámetro rspo/store_location.

Valor db (valor por defecto): El spool request se almacena en la tabla de base de datos TST03 (ventaja: se respalda junto con el backup de la base de datos)

Valor G: se almacena en el sistema operativo en el directorio global. (ventaja: mayor performance)

Se puede especificar el lugar de almacenamiento individualmente para cada dispositivo de salida en la transacción SPAD (desde el menú Edit → Data

Storage).

La nota de SAP 20176 contiene valores adicionales para el parámetro rspo/store_location.

La creación de un output request solicita al sistema de spool de SAP enviar información con un formato dependiente de la impresora seleccionada al sistema de spool del sistema operativo. Esto significa que el modelo de impresora elegida debe ser conocido por el sistema SAP. Definiciones de este tipo se conocen como tipos de dispositivos (device types).

Si una impresora no puede ser controlada a nivel del sistema operativo, no puede ser usada en el sistema SAP tampoco.

Hay varias maneras en la que un spool work process puede alcanzar a un spool del sistema operativo. Las conexiones más importantes, conocidas como métodos de acceso (access methods) se explican a continuación en esta lección.

Impresión Local

Figura 111 – Impresión Local

Una característica de la impresión local es que el spool work process y el sistema de spool del sistema operativo corren en el mismo servidor. No es relevante si la impresora está conectada directamente a este servidor o se alcanza a través de la red. El spool work process pasa la información de forma local, en el mismo servidor.

En servidores UNIX, la impresión local se define con el método de acceso L. En Microsoft Windows, se utiliza el método de acceso C.

La impresión local es la conexión más rápida y confiable desde el sistema SAP al sistema operativo. Tan pronto como el spool work process ha transferido la

información, puede tomar nuevos output requests, aún si el spool del sistema operativo se encuentra ocupado todavía.

Se pueden configurar multiple spool work processes para una instancia SAP. Esto tiene consecuencias en la secuencia de salida. Spool Requests diferentes para la misma impresora podrían ser impresos en un orden distinto del que fueron creados. Si necesitamos que la salida de impresión respete la secuencia, podemos especificarlo para impresoras de forma individual. Sin embargo, una configuración de este tipo reduce la posibilidad de impresión en paralelo. Para más información sobre esto, podemos consultar la nota de SAP 108799.

Impresión Remota

En la impresión remota, el spool work process y el spool del sistema operativo están corriendo en diferentes hosts. De la misma manera que en la impresión local, es irrelevante desde el punto de vista del sistema SAP si la impresora se conecta directamente al host remoto o es a través de una conexión de red.

Figura 112 – Impresión Remota

Escenarios típicos para la impresión remota son:

Impresoras de red que proveen su propio sistema de spool y son conectadas directamente a la red.

Desde el sistema SAP se acceden mediante el método U con el nombre de la impresora.

El método de acceso U también es utilizado si el host remoto es un sistema UNIX. La nota 39405 describe como el método de acceso U puede ser usado por las diferentes versiones de UNIX.

SAP provee el programa SAPSprint para todos los hosts con sistemas operativos Windows. SAPSprint es un servicio de Windows. Cada output request se procesa en un hilo de ejecución separado. Los output requests de SAP que recibe SAPSprint del sistema SAP pueden ser transferidos a una impresora particular. Si la impresora no

está funcionando, esto no interrumpe la impresión de otros output requests en otras impresoras.

El método de acceso S es usualmente utilizado en este caso (protocolo SAP), pero el método de acceso U también es soportado.

Por razones de performance, solo deberíamos utilizar impresión remota en un entorno LAN y deberíamos asegurarnos que los spools de los sistemas operativos estén disponibles. Los usuarios SAP pueden imprimir documentos en sus impresoras locales usando impresión en front-end.

Estas impresoras locales no necesitan ser definidas en el sistema SAP. Si es necesario que el administrador del sistema configure un dispositivo representativo para cada plataforma de sistema operativo de front-end.

Figura 113 Impresión en Front-end con Tecnología de Control (Método de Acceso G)

Desde la versión SAP Web AS 6.20, un nuevo procedimiento de impresión en front-end se encuentra disponible: impresión en front-end mediante tecnología de control con el método de acceso G. Esto ya no requiere del programa SAPlpd. La ventana de impresión de Windows se llama directamente desde el control.

El programa SAPlpd se instala junto con el programa SAP Logon.

Los controles son DLLs que corren en el contexto de proceso de SAP GUI. El nuevo método de impresión recibe los datos de impresión y lo transfiere al sistema de impresión del sistema operativo. Una ventaja de este método frente al método F es que ofrece la ventaja de que puede ser utilizado también con SAP GUI para JAVA lo que hace que sea independiente de la plataforma del front-end. También puede ser utilizado con Windows Terminal Server. Información sobre impresión de front-end con tecnología de control está disponible en la nota de SAP 821519.

Podemos definir el máximo número de spool work processes que pueden ser utilizados en el sistema SAP para impresión en front-end para cada instancia de SAP mediante el parámetro rdisp/wp_no_Fro_max (el valor por defecto es 1).

Este método de impresión no es recomendado para impresión masiva, sino más bien para impresión en impresoras locales de los usuarios.

Cuando usamos el método de acceso F (para versiones hasta 4.6C), los datos de impresión se transfieren al host en donde el programa SAP GUI del usuario está corriendo. Este método puede ser usado en PCs con diferentes sistemas operativos: En el caso de sistemas operativos de Microsoft Windows, el programa saplpd transfiere los datos recibidos al control de impresión de Windows. Si es necesario, saplpd se inicia automáticamente.

Con otros sistemas operativos (Linux, Apple Macintosh, etc) los datos se transfieren directamente al sistema de spool del sistema operativo. En este caso, el nombre de la impresora debe especificarse en la definición del dispositivo.

Para más información, puedes ver la Nota 128105.

Si utilizamos SAP GUI para HTML y vamos a imprimir en los front-end, debemos utilizar el método de acceso F. Usando este método, los datos de impresión son enviados al navegador y visualizados. Luego puede imprimirse el documento en el front-end.

Creación de Dispositivos de Salida

La configuración del sistema de spool es una tarea del admnistrador del sistema. La herramienta central para esto es la transacción SPAD (menú Tools → CCMS → Print → Spool Administration)

Figura 114 – Creación de Dispositivos de Salida

Con impresión de front-end con tecnología de control (método de acceso G), la impresora tiene un nombre genérico en SAP, y es asignada al dispositivo físico _DEFAULT. Como los modelos utilizados en las impresoras de front-end pueden ser muy variados, el dispositivo SWIN se asigna para las impresoras de los front-ends que utilizan Windows. Cuando se imprime con SAP GUI para JAVA en otros sistemas operativos, deberemos utilizar un dispositivo correspondiente, tal como PostScript.

Si la impresión en front-end se realizará utilzando SAP GUI para HTML con el método de acceso F, el dispositivo de tipo PDF1 debe seleccionarse. Los datos de impresión son luego transferidos al navegador en el front-end como un documento PostScript y puede ser impreso localmente.

Tabla 2 - Dispositivos de Salida para Impresión en Front-end

Para crear un dispositivo de salida, llamamos a la transacción SPAD y elegimos Output Device en la solapa Devices/Servers. Si hay un gran número de dispositivos en el sistema, podemos restringir la lista de devuelta con el campo de texto por ejemplo ingresando PR* (devolverá todas los dispositivos que comiencen con las letras PR)

Dispositivo de Salida (Output Device): Nombre, máximo 30 caracteres.

Nombre corto (Short Name): Para propósitos internos del sistema (puede generarse automáticamente)

Tipo de Dispositivo (Device Type): Modelo de la impresora o familia compatible.

Servidor de Spool (Spool Server): Servidor de aplicación SAP con spool work processes o un servidor lógico (veremos este concepto en la próxima lección)

Lugar (Location): Por ejemplo, edificio u número de oficina. Sirve para que los usuarios sepan donde se hará la impresión)

Mensaje (Message): Utilizado temporalmente para sobrescribir al campo Lugar. Sirve para informar por ejemplo cuando está en mantenimiento el dispositivo)

Impresora Bloqueada en el Sistema SAP (Lock Printer in SAP System): Los output requests para este dispositivo son creados pero no transferidos a la impresora. El usuario recibe un mensaje: sin impresión inmediata.

Método de Acceso (Host Spool Access Method): como un spool work process contacta al sistema de spool del sistema operativo.

Host de Impresora (Host Printer): Nombre de la impresora a nivel del sistema operativo. Este nombre es dependiente de minúsculas y mayúsculas. En Windows, no debe haber espacios en el nombre de impresora.

Nombre de Host (Host Name): solo para impresión local, se calcula automáticamente del servidor de spool.

Host Destino (Destination Host): solo para impresión remota. Nombre del host en el cual el spool del sistema operativo está corriendo.

Tipos de Dispositivos

El sistema SAP utiliza un tipo de dispositivo para formatear la información de impresión a un dispositivo específico.

Cuando se hace referencia a un dispositivo de salida en el ambiente de SAP, no necesariamente significa una impresora. Un dispositivo de salida puede ser, por ejemplo, un Sistema de Gestión de Salida o un Sistema de Archivado.

Cuando el spool work process genera un output request, utiliza las especificaciones del tipo de dispositivo. Esto es, el tipo de dispositivo describe como la impresión de datos debería ser formateada para un dispositivo en particular.

La siguiente figura ilustra como un dispositivo de salida es creado:

Figura 115 – Dispositivo de Salida

La siguiente lista explica los términos de la figura.

Formato de Página (Page Format): Un formato de página describe el formato de una página imprimible en el sistema SAP. Un gran número de formatos de páginas estándar son predefinidos en el sistema. Si un dispositivo va a soportar formatos adicionales, podemos definir nuevos formatos. Hay que considerar que cuando hacemos esto, el dispositivo de salida que vamos a utilizar debe soportar el formato definido.

Tipo de Formato (Format Type): Un tipo de formato describe como la salida debería aparecer en el papel. Principalmente contiene el formato para la página.

Formato (Format): Un formato es una implementación de un tipo de formato específico para un dispositivo. Esto es, el sistema SAP puede usar la descripción en un formato para controlar un dispositivo correctamente. Por ejemplo, realizar una salida

en una página con el formato de Carta. Un tipo de formato es por lo tanto independiente del dispostivo; el formato, por otro lado es una implementación específica de dispositivo para un tipo de formato.

Set de Caracteres (Character Set): Un set de caracteres contine los caracteres que pueden ser utilizados por un dispositivo de salida particular. Significa, que para poder usar un set de caraceteres particular para un modelo de impresora en el sistema SAP, el tipo de dispositivo asignado al modelo de impresora debe contener este set de caracteres.

Control de Impresión (Print Control): Permite el control de la visualización de opciones de los dispositivos de salida, tal como el cambio de tamaño de fuente, o la misma fuente. El control de impresión utiliza un control de secuencia de caracteres específico del dispositivo. Esto significa que para crear nuevos dispositivos, las opciones de visualización ofrecidas por el sistema SAP deben ser almacenadas con el control de secuencia de caracteres que el modelo de impresora elegido soporta.

Lección 3: Administración de Spool Servers

Concepto de Spool Server Lógico

El concepto de impresión mostró hasta acá un idea de una asignación fija de un dispositivo de salida a un servidor de spool. Un servidor de spool, por otro lado, pude ser asignado a múltiples dispositivos de salida lo cual incrementa el riesgo de sobrecarga en este servidor o también de no disponer de muchas impresoras si una instancia no se encuentra operativa.

Por estos motivos sería convenientes tener un mecanismo para balancear la carga entre varios servidores de aplicación SAP. La inclusión de servidores lógicos en el planeamiento de impresión para el landscape de SAP desde un primer momento puede ahorrar mucho esfuerzo en el mantenimiento de la operación.

Cuando el sistema SAP se escala en el tiempo con instancias adicionales y spool work processes se ponen a disposición, los servidores de spool lógico facilitan la adaptación del landscape de impresión.

Figura 116 – Servidores de Spool

Un servidor de spool es un servidor de aplicación SAP con al menos un spool work process. Cada output request es procesado en un servidor de spool real de este tipo. Un dispositivo de salida es creado en el sistema SAP y se asigna a un servidor de spool directamente. Sin embargo, existen varias ventajas asociadas con una capa adicional lógica entre el dispositivo de salida y el servidor de spool. Podemos utilizar servidores de spool lógicos para este propósito.

Podemos clasificar dispositivos de salida y servidores de spool, por ejemplo, para impresión de test o impresión de producción.

El sistema SAP verifica la clasificación y muestra mensajes de advertencia si encuentra una desviación. Por ejemplo, el sistema advierte si intentamos imprimir un gran volumen en un servidor de impresión productivo.

Podemos mantener los servidores de spool en la transacción SPAD mediante la selección de Spool Servers en la solapa Devices/Servers. Información importante de un servidor de spool:

Nombre de Servidor (Server Name): Nombre del servidor de spool, máximo de 20 caracteres y depende si es mayúsculas o minúsculas. El siguiente campo es para una descripción breve.

Clase de Servidor (Server Class): Clasificación del spool server, por ejemplo: impresión masiva.

Servidor Lógico (Logical Server): seleccionamos esta opción cuando creamos un servidor lógico.

Mapeo (Mapping): Nombre de un servidor lógico real al cual este servidor lógico refiere.

Figura 117 – Creación de Servidor Lógico de Spool

Se puede definir un servidor de spool (lógico o real) especificamente para impresión en

front-ends. Si especificamos el parámetro de perfil rspo/local_print/server con el nombre del servidor de spool.

Si vamos a tener una carga siginificante de impresión en front-end, podemos configurar al menos un spool work process adicional por cada servidor de spool de impresión de front-end para otras tareas.

Como se mencionó antes, es posible clasificar dispositivos de salida y servidores de spool. Para clasificar un dispositivo de salida, tendremos que seleccionarlo en la transacción SPAD, bajo Output Devices y seleccionar el menú Edit → Classification.

Ventajas de los Servidores de Spool Lógicos

Cuando creamos un servidor de spool, ya sea un servidor lógico o un servidor real, podemos especificar un servidor alternativo. Si el servidor normal no está disponible, el sistema SAP intenta usar el alternativo.

Figura 118 – Alternativas de Servidores de Spool

Debemos asegurarnos que todas las impresoras que podrían ser usadas por un servidor de spool diferentes puedan ser controladas de la misma manera por cada servidor de spool. Por ejemplo, si el dispositivo de salida Test 1 en el ejemplo de la figura apunta a una impresora del sistema operativo P42 que es controlada localmente, una impresora a nivel del sistema operativo P42 debe existir en los servidores twdf5000 y twdf5001.

No podemos definir más de dos servidores de spool para un servidor lógico. Pero como si puede referenciar a otro servidor lógico, es posible configurar jerarquías extensivas de servidores se spool. O sea configuraciones en cascada de servidores lógicos haciendo referencia a un servidor de spool y como alternativa a otro servidor lógico.

Balanceo de Carga

Podemos permitir balanceo de carga para cada servidor de spool con un servidor alternativo (para esto debemos elegir la opción Allow Load Balancing). La carga de un servidor de spool es calculada con el número de spool work processes, output requests y páginas a imprimir.

Figura 119 – Balanceo de Carga

Para un output request para un servidor de spool con balanceo de carga (la configuración puede ser para servidores lógicos y para servidores de spool), el sistema determina el servidor con la menor carga. El algoritmo es recursivo: el mismo criterio de selección es utilizado en el servidor mapeado y en el servidor alternativo (ambos podrían ser servidores lógicos también).

Procesamiento de solicitudes secuenciales (propiedad de un dispositivo de salida) tiene prioridad sobre el balanceo de carga mostrado aquí (propiedad de un servidor de spool). Esto significa que el output request para un dispositivo de salida con procesamiento de solicitudes secuenciales no será distribuido en concordancia con la carga de trabajo, aunque sea asignado a un servidor de spool con balanceo de carga.

Transportando el Landscape de Impresión

El concepto de servidores lógicos soporta una definición de un landscape de impresión consistente y transportable. A diferencia de servidores de spool reales, los servidore lógicos pueden tener el mismo nombre en varios sistemas SAP. De esta forma, podemos definir una arquitectura de impresión en SAP en el sistema de desarrollo y luego transportarla a los demás sistemas. Luego de transportar, todo lo que necesitaremos hacer es ajustar el mapeo de los servidores lógicos a los servidores de spool del nuevo sistema.

Figura 120 – Transportando el Landscape de Impresión

Existen funciones para el transporte manual de dispositivos de salida y de servidores de spool en la transacción SPAD.

Lección 4: Jobs de Background

¿Qué es el procesamiento en background o de fondo?

El procesamiento en background debería esencialmente separar tareas periódicas y que insumen mucho tiempo de aquellas de interacción de usuarios. Tareas que requieran mucho tiempo y ocuparían un work process en diálogo pueden ser secuencialmente procesadas en background sin afectar la performance de diálogo.

Un requisito importante para conseguir este objetivo es un dimensionamiento apropiado del sistema, ya que, demasiados procesos de background podrían terminar compitiendo por recursos compartidos con procesos de diálogo (memoria principal, CPU).

Los programas que deban ejecutarse regularmente y consuman mucho tiempo son planificados como Jobs de background en el sistema SAP. El administrador planifica los Jobs de background y monitorea la correcta ejecución de los mismos.

Fundamentos

Las siguientes preguntas responderemos en esta lección:

¿Por qué necesitamos procesamiento en background? ¿Qué es un Job de background? ¿Qué podemos realizar en background? ¿Qué condiciones de inicio existen? ¿Cómo son planificados y monitoreados los Jobs? ¿Qué estados puede tener un Job?

Figura 121 – ¿Por qué es necesario el Procesamiento en Background?

Work processes de diálogo deberían estar disponibles para responder a las solicitudes de los usuarios rápidamente. Los recursos de diálogo deberían por lo tanto no ser

utilizados para ejecuciones prolongadas ya que pueden provocar cuellos de botella en el tiempo de respuesta de diálogo. El parámetro rdisp/max_wprun_time existe por este motivo justamente. Limita el máximo tiempo de ejecución de un paso de diálogo en un work process de diálogo.

Esto debería asegurar que los procesos de diálogo no sean bloqueados por programas que requieren demasiado tiempo de ejecución, interfiriendo la operación online. Luego de que el máximo tiempo se ha superado, el programa es terminado.

La manera en que el parámetro rdisp/max_wprun_time funciona está descrito en la nota de SAP 25528.

Podemos utilizar los procesos de background para tareas que consuman mucho tiempo. También se conocen estos como procesos de batch.

Normalmente, los procesos de background no se utilizan solamente para ejecuciones largas, sino que también para tareas repetitivas. Ejemplos de estas son los backups diarios de base de datos o los cierres de mes financieros y contables.

Figura 122 – ¿Qué es un Job de Background?

Un job de background consiste de uno o más pasos (steps). Un paso puede ser:

Un programa ABAP Un comando externo Un programa externo

Cada job se procesa sin interrupción por un único background work process. Los jobs de background pueden ser planificados con diferentes prioridades:

Clase A (Prioridad alta) Clase B (Prioridad media)

Clase C (Prioridad normal)

Si un job es planificado para ser ejecutado en un servidor particular o un grupo de servidores, este tendrá preferencia con respecto a otros jobs de la misma clase. Esta preferencia solamente aplica si múltiples jobs con la misma prioridad solicitan el procesamiento en background al mismo tiempo, por ejemplo, porque se planificaron para que se ejecuten a la misma hora.

Deberíamos asegurarnos que la mayor parte de los jobs de background sean planificados con prioridad normal, clase C, sin especificación de servidor de ejecución. Esto debería aplicar para el 90% o más de todas las tareas de background.

Figura 123 – ¿Qué Podemos Ejecutar en Background?

Un paso dentro de un job puede ejecutar una de estas tres acciones:

Un programa ABAP pude planificarse como un paso de un job. Si el programa ABAP tiene una o más pantallas de selección, tendremos que crear las entradas previamente en una variante. Una variante hace posible ejecutar un programa ABAP en background aunque el programa requiera valores de entrada.

Los valores almacenados en la variante son luego utilizados durante la ejecución del programa. Si un programa ABAP tiene una pantalla de salida como resultado, esto es dirigido a una lista de spool. Podríamos también especificar un recipiente de email para esta lista de spool durante la definición del job. Debemos especificar una impresora para la creación de la lista de spool, aunque no necesariamente tenga que ser impreso en un dispositivo de salida como resultado del procesamiento en background. Esto por ejemplo podría hacerse posteriormente.

Un comando externo es un llamado a un script predefinido, un comando, o un programa a nivel del sistema operativo. Con comandos externos, podemos enmascarar llamadas al sistema operativo y guardarlos en el sistema SAP bajo un nombre. Podemos usar también el concepto de autorización de SAP para proteger la ejecución de un comando externo. Esto permite que podamos determinar que usuarios están permitidos a ejecutar que comandos externos (sobre que servidores y/o sistemas operativos)

Un programa externo es un comando del sistema operativo. El concepto de autorización de SAP solamente especifica si un usuario puede llamar un programa externo o no. Una asignación más detallada de autorizaciones, por ejemplo a nivel de los nombres de programa, no es provista con la ejecución de programas externos. Utilicemos comandos externos para esto.

Figura 124– Criterios de Inicio de un Job de Background

Un job puede ser iniciado:

Mediante la planificación en una fecha y hora particular (esto incluye el inicio inmediato, si no hay background work processes libres disponibles al momento en que debe iniciar el job según la planificación)

Mediante la ocurrencia de un evento particular definido en el sistema SAP. Esto incluye jobs que se iniciarán luego de la finalización de otros jobs o en los cambios de modo de operación o jobs con inicio inmediato si existen background work processes libres al momento.

Planificación y Monitoreo

Podemos utilizar la transacción SM36 para definir nuevos Jobs. Puedes también llamar el Asistente de Job, transacción SM36WIZ o desde la transacción SM36 también.

Figura 125 – Planificación de Jobs

Las especificaciones que requiere la definición de un job son:

Especificaciones generales tales como nombre de job, prioridad del job (por defecto: C) y opcionalmente un servidor de ejecución o grupo.

Definición de uno o más pasos

Definición de una condición de inicio (de tiempo o controlada por evento) El Asistente de Job nos ayuda en la creación del job guiándonos de manera fácil a través del proceso de creación.

El método de creación de un job de background (clásico o mediante el Asistente de Job) no tiene incidencia en el resultado. Algunas funciones (especificar el usuario SAP en la definición del paso de job, modificación del orden de ejecución de los pasos) no están disponibles para el Asistente de Job.

La transacción SM37 nos permite monitorear los jobs. Podemos seleccionar los jobs utilizando diversos criterios en la pantalla inicial de esta transacción. Algunas opciones serían visualizar los jobs que contienen un paso determinado, que tienen un estado particular o que reaccionan a un evento definido.

Figura 126 – Monitoreo de Jobs

Luego de que seleccionamos Execute, una vista de job aparece que es creada por el Visor de Listas SAP (SAP List Viewer: ALV). Seleccionando del menú Settings podemos determinar las columnas que se mostrarán y el orden, entre otras cosas. Podemos también configurar si será el diseño (layout) estándar para el usuario actual o todos los usuarios.

Para el análisis de jobs, una columna que no se visualiza por defecto y es importante, es la columna de servidor de ejecución. Muchas veces algún problema en la ejecución de un job puede estar relacionado al servidor de aplicación donde se ejecuta. Podemos también navegar a otras vistas específicas del job desde la visualización de job mostrada en la figura:

Lista de Spool contiene las listas de salida de los programas de ABAP (si es que existen)

Detalle del Job contiene, entre otras cosas, información sobre la definición del job, duración del procesamiento del job y la fecha y hora de inicio del job.

Todos los mensajes de salida por un programa de background son almacenados en el log del job. Podemos visualizar el log para obtener información sobre un programa que finalizó con error o para realizar una investigación detallada sobre la ejecución de un job de background.

Figura 127 - Estados de un Job

Un job puede tener los siguientes estados:

Planificado (Scheduled): Los pasos que requieren la creación del job han sido definidos ya, de todas formas la condición de inicio aún necesita ser definida.

Liberado (Released): El job ha sido completamente definido, incluyendo la condición de inicio. Un job no puede ser liberado sin una condición de inicio. Solamente un administrador o un usuario con las autorizaciones necesarias para el procesamiento de background puede liberar un job. Esto asegura que usuarios sin autorización no puedan ejecutar jobs sin aprobación.

Listo (Ready): La condición de inicio de un job liberado se ha cumplido. Sin embargo el job se encuentra en la cola de espera por un work process de background libre.

Activo (Active): El job está siendo ejecutado y no puede ser borrado ni modificado. Si un job activo no se ejecuta normalmente, por ejemplo, demora mucho más del tiempo normal, podemos analizar el job en modo de depuración. Luego podemos finalizar el job definitivamente o liberarlo nuevamente. Para esto, en la transacción SM37, seleccionamos Job → Capture: active job.

Para capturar un job de background, debemos iniciar sesión en el servidor SAP donde el job está corriendo.

Finalizado (Finished): todos los pasos del job fueron ejecutados sin problemas.

Cancelado (Canceled): El job finaliza anormalmente, esto puede suceder de dos maneras:

1. El administrador deliberadamente termina el job en la transacción SM37 mediante la selección de Job → Cancel active job.

2. Un paso del job terminó con error.

Podemos modificar un job mientras este tenga los estados Planificado o Liberado. Si la ejecución de un job ya ha comenzado, podemos monitorear el procesamiento en el log del job. Si el job tiene programas ABAP que crean listas de salida, estas se almacenan en las listas de spool.

Podemos crear un nuevo job copiando otro existente. Desde el menú selecciona Job →

Copy.

Lección 5: Administración de Jobs

Planificación Basada en Tiempo

Figura 128 – Inicio Dependiente de Tiempo de un Job

Un job puede ser iniciado de forma dependiente de tiempo o de un evento. En el caso de inicio basado en tiempo, podemos seleccionar entre las siguientes opciones:

El job debe ejecutarse inmediatamente.

El job debe ser ejecutado en una fecha y hora particular.

El job debe ejecutarse en un día laboral determinado.

Puedes seleccionar que el job sea recurrente. Esto significa que el job será ejecutado nuevamente después de un período de tiempo definido. También es posible especificar excepciones, tal como posponer al siguiente día laboral en el caso de un feriado en el calendario.

El job es iniciado en la fecha y hora indicado, en concordancia con la prioridad del job y disponibilidad de work processes de background.

Puedes especificar también un período de tiempo en el cual el job debe iniciarse. Para esto, especificamos un tiempo luego del cual el job no debe ejecutarse. Con esta función, podemos prevenir la ejecución de jobs periódicos en un momento no conveniente, entre otras cosas. Por ejemplo, un job de reorganización que debería solamente ejecutarse durante la noche demora su inicio por falta de disponibilidad de work process de background. Con una ventana de tiempo de inicio, podremos evitar que este job se ejecute durante el día, cuando los usuarios de diálogo están activos y hay menos recursos disponibles.

Balanceo de Carga

El parámetro de perfil rdisp/bctime especifica el período de tiempo en el cual el planificador de jobs dependientes de tiempo está activo (observar la Figura 129). La ejecución de jobs con una condición de inicio inmediata usualmente evita el planificador. En este caso, el work process de diálogo del usuario que solicita el inicio inmediato es quien planifica el job. Solo si no hay recursos libres, el job es planificado de forma basada en tiempo. La fecha y hora planificada de inicio corresponde al momento en el tiempo en el que debería haber iniciado.

Figura 129 – Planificando Jobs y Balanceo de Carga

Los work processes de background pueden ser configurados en cada instancia del sistema SAP utilizando el parámetro de perfil rdisp/wp_no_btc.

El número de work processes requeridos en el sistema SAP depende del número de tareas que se realizarán en batch. Si el sistema de transporte es utilizado, debe haber al menos dos work processes de background en el sistema. La combinación de job ID y el nombre de job definen el job de manera univoca en el sistema.

En cada instancia SAP en la que existen work processes de background definidos, el planificador de job basado en tiempo corre cada la cantidad de segundos definido en

ridsp/btctime (el valor por defecto es 60). Este es un programa ABAP (SAPMSSY2) que corre automáticamente en un work process de diálogo.

A partir de SAP Netweaver 7.0 el planificador de job también se inicia luego de que un job ha finalizado. Esto incrementa la tasa de salida para el procesamiento de background considerablemente dependiendo de cuantos jobs hay planificados y recursos disponibles. La nota de SAP 923228 describe como podemos activar esto para sistemas SAP con una versión a partir de Basis de 4.6C.

El planificador de job basado en tiempo verifica la tabla de planificación de jobs en la base de datos y busca jobs que estén esperando a ser ejecutados. Estos jobs son transferidos a work processes de background que se encuentren libres en la instancia de SAP, de acuerdo a la prioridad y servidor de ejecución.

Los jobs que no son asignados a ningún servidor en particular para la ejecución pueden ser ejecutados con cualquier work process de background libre. Esto significa que la carga de trabajo es automáticamente distribuida entre las instancias SAP.

Si un job es explícitamente asignado a ser ejecutado ya sea en una instancia seleccionada o un grupo de instancias algunas características particulares se derivan de esto, tal como asegurarnos que el job se ejecuta en un sistema operativo particular o en el mismo servidor donde corre la base de datos. Esto significa, de todas maneras, que no contamos con la ventaja de la distribución de carga automática del sistema.

Jobs Estándar

Los jobs estándar son jobs de background que deberían ejecutarse regularmente en un sistema de producción SAP. Estos jobs principalmente realizan ciertas tareas de limpieza en el sistema, tal como el borrado de spool requests obsoletos o el procesamiento de información estadística y de monitoreo.

Figura 130 – Planificación de Jobs Estándar

En la transacción de definición de jobs (SM36), puedes acceder a una selección de jobs estándar importantes que puedes planificar, monitorear y editar seleccionando Standard Jobs.

Si queremos planificar todos los jobs estándar, seleccionamos Default Scheduling. Todos los jobs estándar que están definidos en la tabla REORGJOBS son planificados con una variante y período específico.

Para planificar jobs individuales, selecciona el job y especifica el período de ejecución.

Para definir un job estándar adicional que no está disponible en la selección (tabla REORGJOBS), podemos seleccionar Predefine new job.

Para información sobre jobs estándar, podemos consultar las notas 16083 – Standard Jobs, reorganization jobs y 1034532 – Changes for standard jobs.

Planificación Basada en Eventos

Un evento es una señal para el sistema de procesamiento en background que indica que un estado particular se ha alcanzado en el sistema SAP. El sistema de procesamiento en background recibe eventos y luego inicia todos los jobs que están vinculados a este evento.

Figura 131 – Inicio de Jobs Dependiente de Eventos

Un job dependiente de evento puede ser planificado con una de las siguientes condiciones de inicio:

Luego de un Evento: El job inicia después de que un evento definido en el sistema SAP es recibido.

Modo de Operación: Con esta opción, puedes vincular un job a la activación de un modo de operación cuando planificamos el job.

Luego de un Job: De esta manera, podemos crear cadenas simples de jobs donde la ejecución del job sucesor pude ser dependiente del estado con el que finalizó el job predecesor.

Eventos

Nuevos eventos son definidos por el administrador de sistema en CCMS, transacción SM62. Cuando se hace esto, el administrador diferencia entre eventos de sistema y eventos de usuario. Los eventos de sistema son predefinidos por SAP y no deberíamos modificar o disparar.

Figura 132 – Definición y Disparo de Eventos

Los eventos pueden ser disparados de diferentes formas:

Manualmente en CCMS para propósitos de prueba (transacción SM64). Con un programa ABAP, mediante el uso del módulo de función BP_EVENT_RAISE o

el método RAISE de la clase CL_BATCH_EVENT. Fuera del sistema SAP a nivel del sistema operativo usando el programa sapevt.

Un parámetro puede también ser transferido cuando un evento se dispara. De esta manera, podremos definir jobs que esperan por la ocurrencia del evento junto con el parámetro específico. También podemos acceder al Historial de Eventos en la transacción SM62.

La sintaxis del programa sapevt es:

sapevt <parameters> <Parameters> are multiple individual switches based on: {<EventID> | event=<EventID>} [{-p <EventParam>} | param=<EventParam<´>] [-t[0|1|2][a]] [-v] {[name=<SystemName>] [msserv=<MsServ>] [mshost=<MsHost>] [pf=<Profile>]} {[timeout=<TimeOut>]} [-? | /? | -help | /help]

La nota de SAP 802172 explica los parámetros en detalle.

La salida de sapevt se escribe a un archivo de traza dev_evt. Para que pueda reaccionar a eventos externos, el sistema SAP debe estar activo. De otra manera, un evento que se haya disparado por un programa externo se pierde.

Un ejemplo de ejecución del programa sapevt podría ser: sapevt event=NUEVO_ARCHIVO_INTERFAZ name=DEV mshost=twdf5000.wdf.sap.corp. Si el nombre del evento contiene espacios, deberemos utilizar comillas (“”) cuando llamamos al programa sapevt. Por ejemplo: sapevt "MY EVENT" name=QAS mshost=twdf9999.wdf.sap.corp

Lección 6: Otros Temas de Procesamiento en Background

Reserva para Jobs de Clase A

En la operación normal, cada work process de background procesa jobs de todas las prioridades. De todas formas, podemos reservar tantos work processes de background configurados como deseemos para jobs de prioridad alta, o sea, jobs de clase A.

La reservación de work processes para jobs de clase A no reserva ningún work process en particular. Más bien, el sistema asegura que una cantidad determinada de work processes de background se mantengan libres. Los jobs de clase B y C pueden solamente ser iniciados si el número definido de work processes para posibles jobs de clase A se mantiene libre.

Figura 133 – Reserva de Jobs de Clase A

Para configurar el número de work processes de background de clase A tendremos que configurar los modos de operación en la transacción RZ04. Cuando hacemos esto, tendremos la opción de reservar work processes de background.

Si la carga de jobs de clase A es pequeña, o cuellos de botella raramente ocurre en el procesamiento de background, en otras palabara, al menos un work process de background casi siempre se encuentra libre, la reserva de work processes para jobs de clase A probablemente no ofrezca ventajas. En este caso, la reservación simplemente significará que un work process es muy poco utilizado (solo por jobs de clase A).

SAP recomienda que no reservemos más de un work process de background para el procesamiento de jobs de clase A por cada instancia del sistema. Con esto usualmente es suficiente para un escenario de planificación de jobs de background.

Objetivos de Ejecución

Solamente instancias con work processes de background o un grupo de servidores de job puede ser utilizado para planificar la ejecución de jobs con instancias o grupos específicos.

Un grupo de servidores de job contiene una o más instancias con work processes de background. Los grupos de este tipo pueden ser utilizados de la misma forma que los grupo de logon para usuarios de diálogo. También es posible procesar tareas de background en instancias seleccionadas.

Figura 134- Ejecución en instancias o grupos de servidores de job

Podemos configurar un grupo de servidores de job en la transacción SM61 (menú Tools CCMS → Background Processing → Background Objects). Aquí podremos definir

grupos de servidores con work processes de background asignando las instancias que formarán el grupo.

Usuarios de Background

Con la clásica definición de jobs utilizando la transacción SM36, podemos asignar cada paso de un job a un usuario (observar la Figura 135). El usuario especificado es utilizado para las verificaciones de autorización durante la ejecución del paso. Por defecto, el nombre del usuario que está definiendo el job aparece, y el job luego será ejecutado usando las autorizaciones que ese usuario tenga.

Si el job no debería ejecutarse usando las autorizaciones de ese usuario, podemos ingresar un usuario diferente. Para poder hacer este cambio, deberemos contar con la autorización pertinente S_BTCH_NAM para poder ingresar otros usuarios diferentes al nuestro en el campo User en la definición del paso.

Figura 135 – Usuarios de Background

Es útil configurar usuarios de background para varias áreas de trabajo que cuenten con las autorizaciones necesarias para las actividades que se requieran, y que puedan ser usadas por usuarios con las mismas autorizaciones para planificar jobs de background en esta área de trabajo, tal como la administración de sistema. Los usuarios de background tienen registros maestros de usuario que cuentan específicamente con autorizaciones para el procesamiento de background.

El tipo de usuario de Sistema (System) debe ser elegido cuando creamos usuarios de background. Un logon al sistema de diálogo no es posible con este tipo de usuarios. De la misma manera, los usuarios de este tipo están exentos de la configuración de validez de las contraseñas. El administrador de sistema solo puede cambiar la contraseña mediante la transacción SU01.

Si en cambio usamos el Asistente de Jobs para la creación de los mismos, no tenemos la posibilidad de definir un usuario diferente para cada paso del job.

Utilización de Programas Externos

El sistema de procesamiento en background diferencia entre comandos externos para usuarios normales y programas externos para los administradores de sistema. El propósito de esta diferenciación es darle a los administradores del sistema la posibilidad de ejecutar cualquier programa externo que requieran, mientras que los usuarios normales están restringidos al uso de comandos externos para los cuales hay verificaciones de autorización. En ambos casos, el programa sapxpg es invocado a nivel del sistema operativo e inicia el programa relevante en el sistema operativo.

Figura 136 – Utilizando Programas Externos

Los Comandos Externos son commandos o programas del host predefinidos en el sistema SAP por el administrador. Estos están protegidos por autorizaciones por lo que los usuarios normales pueden solamente planificar los comandos para los cuales el administrador les ha asignado las autorizaciones necesarias. De esta manera, podemos proveer de funciones fuera del sistema SAP, a nivel del sistema operativo, a los usuarios del sistema SAP.

Los Programas Externos son comandos sin restricciones que no son predefinidos o restringidos por autorizaciones. Un usuario que tenga autorizaciones de administrador puede ingresar un programa externo en un paso de un job. Ninguna verificación de autorización SAP se lleva a cabo antes de la ejecución del comando. Los programas externos proveen al administrador la flexibilidad para ejecutar cualquier comando en el sistema operativo en el sistema SAP sin preparación previa.

Un administrador de sistema debe contar con autorizaciones para el objeto S_RZL_ADM: Administrador de Procesamiento en Background.

Figura 137 – Definición y Uso de Comandos Externos

La creación de comandos externos requiere de los siguientes pasos:

1. Llamar a la transacción SM69. 2. Seleccionar Create. 3. Realizar las entradas en el nuevo comando.

Los comando externos son identificados unívocamente con un nombre, comenzando con Z o Y, y un tipo de sistema operativo. El campo Type se completa automáticamente.

Especificar un comando ejecutable del sistema operativo (si es necesario con la ruta completa) y especificar cualquier parámetro requerido u opcional.

Seleccionar el cuadro de verificación (checkbox) Additional Parameters Allowed si los usuarios podrán especificar parámetros adicionales cuando ejecutan el comando externo. Los parámetros adicionales son agregados en una cadena de parámetros especificados bajo el campo Parameters for Operating System Command.

El campo Trace debería dejarse en blanco usualmente. Para seguir la ejecución de un comando externo, utiliza el parámetro de traza para el módulo de función SXPG_COMMAND_EXECUTE.

Si se ha definido una verificación adicional de autorización, ingrese el nombre del módulo de función que realiza la verificación en el campo Check Module. Este es usualmente una copia del módulo de función SXPG_DUMMY_COMMAND_CHECK. El sistema llama al módulo de función automáticamente si un usuario intenta ejecutar el comando externo o lo planifica en un paso de job de background.

4. Guarda el comando. Para regresar a la vista de comandos, selecciona Back.

Indicadores de Control (Control Flags)

Es posible realizar especificaciones sobre la tarea y otras opciones de ejecución usando indicadores de control. Usualmente no es necesario cambiar los valores por defecto.

Por ejemplo, podemos especificar:

Si el proceso va a ser registrado.

Si Los datos de salida se escriben al log del job tal como son devueltos por el programa externo. También es posible registrar información adicional sobre el programa externo en el log del job.

Figura 138 – Indicadores de Control para Programas o Comandos Externos

Otro indicador es si el paso del job espera por la finalización del programa externo.

En el caso de que después de que hemos iniciado un servicio con el sistema de procesamiento en background, tal como un demonio en UNIX o un servicio en Windows, el programa se mantiene activo luego del inicio. Estos programas iniciados como servicio o demonios no devuelven el control al sistema de procesamiento en background de SAP, como en el caso de otros programas. Si iniciamos un programa mediante un servicio, no deberíamos utilizar el indicador de control Job waiting for ext. Termination cuando planficamos el paso del job.

Lección 7: Monitoreo de Sistema

La infraestructura de Monitoreo de Alertas - Permite realizar un monitoreo eficiente de los sistemas SAP

Recolección de Datos --> Cada subarea y componente de un sistema sap es monitoreado por un programa llamado recolector de datos, el cual chequea ciertos intervalos su componente y almacena la información obtenida en la memoria principal de la Instancia. Almacenamiento de Datos --> el área de la memoria q almacena toda la información se conoce como segmento de monitoreo, esta area es continuamente sobrescrita, los datos se copian a la BD para poder ser analizados posteriormente Administración de Datos --> Los datos obtenidos en el monitoreo de segmento son analizados y evaluados tx - RZ20 Herramienta de visualización TX RZ20

Sap provee un set de monitores los cuales ya viene incluidos, dentro de un set de monitores se encuentran los monitores q este contienen, estos ofrecen diferentes vistas de los objetos de monitoreo de un sistema

Una vez q se ingresa al monitor se accede a las vistas de elementos del árbol de Monitor (MTE)

Cada nodo del árbol es un MTE lo cuales nos permiten organizar a los objetos de monitoreo dentro de categorías para facilitar la búsqueda y visualización de los objetos

Luego en las hojas del árbol se encuentran los atributos del objeto de monitoreo

Estos atributos son propios de cada objeto y almacenan los valores y almacenan los valores recolectados por los programas recolectores de datos

Haciendo doble clic al atributo que indica alguna alarma se ingresa al método de análisis

Las alertas se propagan si es severa por los niveles superiores del árbol, rojo es más severo q amarillo.

Cada atributo tiene una serie de propiedades para ajustar la generacion de alarmas a los requerimientos

En los atributos de performance es donde se definen los valores que generaran las alarmas de advertencia

Para poder configurar propios set de monitores se debe activar la función de mantenimiento

Luego de asignar los objetos, se da guardar para asignar un nombre

Luego de finalizar se desactiva la función de mantenimiento

Se pueden revisar que alarmas están abiertas

En el árbol se puede visualizar las alarmas q están pendientes por análisis

Haciendo doble clic sobre el atributo se verán las alarmas pendientes

Luego de q esta determinada la causa y efectuar la corrección se marca como alarma completa para que vuelva el indicar al estado normal.

Administración Avanzada de Clientes

Lección 1: Concepto Copia y Transporte de Clientes

Las copias de clientes pueden reemplazar datos en un cliente nuevo o en uno ya existente. Ingresar a la TX – SCC4 Para crear un nuevo cliente

Una vez creado el cliente, se ingresa a este mismo con el usuario SAP* y la contraseña pass

Siempre que se crea un nuevo cliente, debe realizarse una copia desde un cliente de referencia, puede ser local o remoto: Copia Local entre clientes – en la copia local los datos se leen y se escriben en la misma BD, para todos los tipos de copias siempre la ejecución debe realizarse en el cliente destino, se debe seleccionar desde que cliente se quiere realizar la copia, para el caso de un nuevo mandante es recomendable realizar la copia desde el cliente 000 del sistema. Ingresar a la TX – SCCL

Luego debe elegirse el perfil para la copia, es decir que datos se copiaran desde el cliente origen hacia el nuevo cliente

Por último se observa la verificación antes de iniciar la copia donde se verán los datos del cliente destino, el perfil utilizado y el cliente origen, así también como un detalle de los datos que serán copiados según el perfil utilizado

Se podrá observar el progreso y los logs de la copia de mandante en la TX – SCC3

En la TX- Scc3 se puede ver no solo los logs del cliente en el que estamos logueados, si no también todos los clientes del sistema

Desde acá se podrá ingresar al detalle de los logs de las copias de los otros mandantes, es importante que mientras una copia este en ejecución no se trabaje ni en el cliente destino ni tampoco en el cliente origen

En el detalle, se podrá ver el estado del progreso de la copia, la acción actual que se está realizando y las estadísticas para la ejecución

Con el monitor se puede observar de forma gráfica el progreso de la cantidad de tablas copiadas así también como el tiempo

Con el detalle se puede analizar exactamente cada objeto que ha sido copiado desde el cliente origen.

En la TX SM37, se puede observar el progreso del job en ejecución

En la copia de cliente remota previamente a iniciar la copia, el sistema realizara una verificación de consistencia mediante las conexiones RFC

En el mandante destino desde la TX – SCC9, se realizara la copia remota de clientes, se selecciona un perfil, se debe tener en cuenta que si copiamos datos cross-client se podría afectar el resto de los mandantes que puedan existir en el sistema destino

Se debe seleccionar también una conexión RFC que tenga un usuario con las suficientes autorizaciones para realizar la copia desde el sistema origen

Tanto en la copia local como remoto, podemos seleccionar la cantidad de procesos en paralelo para la ejecución, esto puede ayudar a reducir los tiempos de la copia

En la TX- SCC3, ver los logs de la copia

Se puede observar la acción de cada uno de los procesos escogidos

Otra opción para la copia es la exportación e importación, mediante la TX- SCC8 se exportara el cliente desde un sistema origen y luego con el sistema de transporte se importara en el sistema destino

Se debe seleccionar un perfil para la exportación, dependiendo del perfil seleccionado podremos generar hasta 3 archivos en el directorio de transportes del sistema origen, tenemos que tener en cuenta contar con el suficiente espacio para la exportación

También la información del sistema destino y el mandante destino, esta información será utilizada por el sistema de transportes luego para la importación La ventaja de este método es reproducible, una vez que exportamos el cliente se podrá importarlo en el mandante las veces que sea necesario, lo que es muy útil para un mandante que se usa de entrenamiento el cual podría actualizarse una vez por semana por ejemplo

En la copia remota como en la exportación podremos verificar de ante mano la consistencia con el sistema destino

Debemos contar con una conexión RFC al sistema destino

El resultado del chequeo de consistencias, podría advertir por ejemplo que exista una tabla con diferentes estructuras en el sistema origen y en el sistema destino

Antes de iniciar el proceso de exportación, se podrá verificar los datos que se han seleccionado, tener en cuenta que para este caso se utilizaran las herramientas del sistema transporte tal como el programa de transporte tp

Una ventana de información indicara que hasta 3 archivos se podrán generar dependiendo del perfil seleccionado, básicamente si se selecciona exportar datos cross-client desde el sistema origen, un tercer archivo se generara en el directorio de transportes

Al importar el mandante en el sistema destino, se utilizara la herramienta STMS, luego se debe realizar un post-procesamiento con la TX SCC7 en el mandante destino

Lección 2: Comparación de Clientes

Usando la Herramienta de Comparación de Clientes

Cuando varios sistemas SAP y clientes están siendo implementados, podría ser necesario comparar y ajustar el customizing entre diferentes sistemas y clientes. La función de comparación permite comparar y ajustar el contenido de una tabla o vista en dos clientes diferentes, mediante conexiones RFC.

Figura 138 – Comparación de Clientes

Para usar la función de comparación de clientes, desde la pantalla inicial de SAP, ingresa a la transacción SCU0.

Podemos usar esta función para comparar:

Un cliente con un cliente de referencia, tal como un cliente creado por nosotros o el cliente de SAP 000. Esto es especialmente útil después de un Upgrade o Importación de Lenguaje, ya que solamente el cliente 000 es provisto con datos de las tablas perteneciente a la clase de entrega CC.

Comparar clientes durante un escenario de rollout. Por ejemplo, si las subsidiarias quisieran ajustar sus customizing con respecto al customizing de referencia de un Cliente Maestro.

Comparar el customizing cross-client de distintos sistemas antes de combinar diferentes clientes en un mismo sistema en un escenario de roll-in. Por ejemplo, si las subsidiarias quisieran recibir los cambios de customizing desde un cliente de referencia, cliente maestro de la organización superior.

Figura 139 – Comparación de Clientes: Opciones de Selección

Para seleccionar los objetos a ser comparados en una comparación de clientes, podemos usar un método orientado a proyecto utilizando el IMG para definir los objetos. También podemos seleccionar desde los componentes de aplicación, listas de objetos y órdenes de transporte. También podemos elegir objetos manualmente.

Para iniciar la comparación, utiliza la transacción SCU0 y el procesamiento en background. La transacción primero muestra un resumen de las tablas que pertenecen a vistas para el IMG, componente de aplicación u orden de transporte seleccionado. Luego de la comparación, el sistema crea una lista de las diferencias e indica si estas diferencias se encuentran en la estructura de las tablas o en el contenido. Para visualizar la diferencia de las entradas, selecciona un objeto. Esto permite realizar una comparación detallada.

La comparación de cliente es generalmente con otro sistema, por lo que en estos casos necesitaremos acceder mediante una RFC.

Para más información sobre comparación de clientes, puedes consultar la Nota de SAP 91096

Los resultados de cada comparación es un resumen de las diferencias que existen entre el cliente donde nos encontramos y el cliente seleccionado para la comparación. Este resumen sirve como un punto de inicio para continuar con el análisis de las diferencias. El resultado de la comparación es almacenado en una lista de trabajo o de diferencias.

Usando la Herramienta de Mantenimiento de Clientes

Por cada objeto que es comparado, se lista con una descripción en la salida de la comparación. La información más importante es el indicador de estado. El indicador de estado informa la existencia y naturaleza de cualquier diferencia.

El estado de procesamiento nos permite distinguir entre los objetos que han sido ya procesados o tratados, o sea, que han sido ajustados para igualarse entre ambos clientes y aquellos que todavía no. Este tipo de procesamiento se conoce también como ajuste del objeto. El estado de procesamiento se indica por un pequeño semáforo, donde rojo indica que no ha sido ajustado, amarillo significa que se está realizando el ajuste y verde que se ha completado.

Una breve explicación sobre el estado de comparación y el estado de procesamiento se puede obtener mediante el ícono Legend.

Figura 140 – Ajustando Objetos de Customizing

Podemos ajustar un objeto por vez. Estos objetos que pueden ser ajustados son algunas de las tablas o vistas que pueden mantenerse a través de la transacción SM30. Todos los demás objetos solo pueden ser comparados.

Para realizar un ajuste, desde la pantalla Comparison, selecciona Edit Interact Copy. La pantalla Overview Adjustment se visualiza, mostrando el detalle de las diferencias entre los dos clientes, registro por registro. A la izquierda de cada registro en esta lista de trabajo se encuentra el estado de comparación, el cual inidica si cada entrada de registro existe en el cliente comparado y en el cliente donde nos encontramos.

Figura 141 – Configuración de Cliente

La opción de cliente Protection: Client Copier and Client Comparsion Tool puede ser utilizada para prevenir que un cliente sea sobrescrito por una copia de cliente o una comparación y ajuste de cliente. También puede asegurar que los datos sensibles no puedan ser visualizados desde otro cliente durante una comparación.

Para seleccionar esta opción desde la transacción SCC4, seleccionamos uno de los niveles de protección:

Nivel 1: No overwriting Este nivel de protección asegura que el cliente no puede ser sobrescrito por el programa de copia de cliente. Esta opción debería utilizarse si en el cliente se realiza customizing o el cliente contiene configuraciones críticas o datos que no deberían sobrescribirse.

Nivel 2: No overwirting and no external availability Este nivel de protección también protege contra la sobrescritura del cliente y contra el

acceso a lectura desde otro cliente durante una copia de cliente o una comparación de customizing. Esta configuración debería utilizarse si el cliente contiene datos sensibles. Todos los clientes productivos deberían tener esta opción.

Importación de Ordenes de Transporte

Para configurar el landscape de sistemas, es suficiente contar con un sistema SAP, tal como el de desarrollo; el sistema de calidad y producción no son requeridos en esta etapa. También deberemos crear un directorio de transportes a nivel del sistema operativo, si es que estará ubicado en un servidor distinto del primer sistema que instalemos. Este directorio es requerido por TMS.

Dependiendo del sistema operativo, el directorio de transportes global y todos los subdirectorios necesarios podrían ser creados automáticamente durante la instalación del sistema SAP (ver la guía de instalación para el sistema SAP para más detalles).

Los transportes nos permiten sincronizar el Customizing y los desarrollos en múltiples sistemas SAP a través de la transferencia de los cambios realizados desde el sistema de desarrollo a los sistemas subsiguientes. Los transportes a través de las rutas de transportes deben ocurrir solo en una dirección.

Conceptos y Terminología de TMS

Los conceptos detrás de TMS (Transport Management System):

Configuración centralizada del Sistema de Cambios y Transportes (CTS) para todos los sistemas SAP. Gestión centralizada de órdenes de transportes y del proceso de importación. Estrategia de transportes basada en rutas de transportes predefinidas.

TMS

El propósito de TMS, el cual se accede mediante la transacción STMS, es controlar de forma central la propagación de los cambios a través de los sistemas del landscape basado en caminos predefinidos. Esto está diseñado para asegurar la consistencia del repositorio de SAP y el contenido de las tablas de Customizing en todos los sistemas del landscape.

Con TMS podemos:

Definir el rol de un sistema SAP dentro de un landscape de sistemas o un dominio de transportes. Configurar las rutas de transportes mediante un editor o usando configuraciones estándar. Configurar los parámetros del programa de transportes tp Visualizar las colas de importación de todos los sistemas en el dominio de transportes. Definir los procedimientos de aseguramiento de calidad y aceptación de cambios en el sistema de QA. Planificar la importación de órdenes de transportes en una cola de importación. Dominio de transporte

Un dominio de transportes consiste de todos los sistemas que planeamos manejar usando el mismo TMS. Dentro de un dominio de transportes, todos los sistemas deben tener un ID de sistema (SID) único y solo uno de estos sistemas es identificado, o mejor dicho tiene el rol, de controlador de dominio (de transportes). El controlador de dominio de transportes es el sistema donde todas las configuraciones de TMS se mantienen. Cualquier cambio en la configuración es distribuida a todos los sistemas en el landscape. Esto asegura que todas las configuraciones de TMS son consistentes a través de todo el dominio. El controlador de dominio almacena la configuración y todos los otros sistemas reciben una copia de esta configuración. Un dominio de transportes contiene al menos un grupo de transportes. Más simple, un grupo de transporte consiste de uno o más sistemas que comparten un directorio de transportes común. Las siguientes figuras muestran la relación entre un dominio de transporte y un grupo de transportes.

Los sistemas dentro de un dominio de transportes se comunican cada uno con otro usando funciones de llamadas remotas (RFC). La comunicación RFC necesita un ID de usuario para acceder a los sistemas destinos. Cuando los sistemas se agregan a un dominio de transportes, los destinos RFC necesarios y los ID de usuarios son automáticamente configurados por la herramienta TMS. La configuración de dominio se distribuye a través del dominio usando la comunicación RFC.

Los cambios en la configuración del dominio de transportes se realizan en el controlador de dominio. Cada vez que hacemos un cambio, una ventana se muestra consultando si los cambios deben ser distribuidos inmediatamente a los sistemas del dominio. Podemos distribuir varios cambios en una sola vez.

Estableciendo un Dominio de Transportes

Para configurar un dominio de transportes, primero determinaremos cuales sistemas serán incluidos en el dominio. El domino de transportes debería contener todos los sistemas de todos los landscapes de sistemas que serán administrados centralmente mediante TMS.

La configuración de TMS puede desglosarse en tres pasos individuales.

1. La configuración del dominio de transportes que define los sistemas que serán incluidos en el dominio.

2. La configuración de las rutas de transportes que define los roles de los sistemas (y clientes) dentro del o los landscapes.

3. La configuración del procedimiento de QA que define quien será responsable para la aprobación y aceptación de cambios y la promoción de los mismos a los sistemas de delivery subsiguientes.

Inicializando el Controlador de Dominio de Transportes

El primer sistema que configuramos es automáticamente seleccionado como el controlador de dominio pero más tarde podemos cambiar el rol del controlador de dominio a un sistema diferente.

SAP recomienda que el sistema que seleccionemos para el rol de controlador de dominio tenga los siguientes atributos:

Alta disponibilidad Alta seguridad Alto nivel de mantenimiento

Por lo tanto, un sistema de producción podría ser ideal para ser el controlador de dominio. Como los sistemas de desarrollo usualmente son instalados antes del sistema de calidad o producción, en la práctica es común configurar el sistema de desarrollo como el controlador de dominio y luego mover la asignación al sistema de producción.

Cuando usamos TMS por primera vez luego de la instalación del sistema, automáticamente nos solicitará configurar TMS.

Cuando inicializamos TMS, las siguientes acciones se llevarán a cabo automáticamente por el sistema SAP:

Un grupo de transportes es creado con el nombre GROUP_<SID>. En el cliente 000, el usuario de comunicación TMSADM es creado. Los destinos RFC necesarios para TMS son generados. El archivo de configuración DOMAIN.CFG es almacenado en el subdirectorio bin del directorio de transportes. Este archivo contiene el nombre del dominio de transportes y la descripción así también como el nombre del host de controlador de dominio, número de instancia, SID y grupo de transportes. El perfil de transporte para el programa de control de transportes tp se genera y se almacena en el subdirectorio bin bajo el nombre TP_<DOMAIN>.PFL.

Los parámetros en este perfil se mantienen usando la transacción STMS.

El nombre del domino de transportes no debe contener espacios en blanco y no puede ser modificado después sin reconfigurar el controlador de dominio. Por defecto el dominio de transportes tendrá el nombre DOMAIN_<SID>, donde <SID> es el ID de sistema del controlador de dominio.

El programa de control de transportes tp require un perfil de transporte que contenga información sobre cómo establecer la conexión a la base de datos de todos los sistemas SAP en el dominio de transportes. TMS genera y gestiona este perfil de transportes como una parte de la configuración del dominio de transportes. No debemos modificar el perfil de transportes usando un editor de textos en el sistema operativo.

Para visualizar los parámetros de tp en un sistema SAP, llamamos a la transacción

STMS. Selecciona Overview Systems. Marca uno de los sistemas y selecciona SAP

System Display. Selecciona la solapa Transport tool. Desde el menu, selecciona Goto

Display.

Configuración de las Rutas de Transporte y Verificaciones

Las rutas de transportes indican el rol de cada sistema y el flujo de las órdenes de transportes. Las rutas de transportes son lo que definen el landscape de sistemas.

Aunque TMS ha sido inicializado, no es posible aún realizar transportes hasta que las rutas de transportes hayan sido configuradas y distribuidas.

Después de establecer el dominio de transportes, necesitaremos: 1. Modelar las rutas de transportes desde el controlador de dominio, usando: a. Configuraciones estándar (uno, dos o tres sistemas) b. Editor gráfico para configuraciones no estándar 2. Distribuir y activar la nueva configuración para todos los sistemas SAP dentro del dominio de transportes.

Para reducir el trabajo para especificar las rutas de transportes, podemos usar las configuraciones estándar. Las rutas de transportes se generan automáticamente cuando seleccionamos los sistemas y la configuración para uno, dos o tres sistemas.

Capas y Rutas de Transportes

Como mencionamos anteriormente las rutas de transportes definen el flujo de las órdenes de transportes desde un sistema a otro. Estas rutas se denominan de consolidación o de entrega o reparto (delivery).

Una ruta de consolidación es una ruta de exportación/importación. Típicamente, la ruta de consolidación procede desde el sistema de desarrollo (desde donde las órdenes de transportes son exportadas) al sistema de calidad (donde las órdenes de transporte son importadas) en un landscape estándar de tres sistemas.

Una ruta de reparto es otra ruta de importación. En el landscape de tres sistemas, la ruta de reparto se especifica entre el sistema de calidad y el sistema de producción porque no hay una exportación desde el sistema de calidad pero si una importación al sistema de producción.

El customizing y los objetos de respositorio son asignados a una ruta de consolidación específica mediante una capa de transportes. En el directorio de objetos SAP, el cual es

el catálogo de todos los objetos, están agrupados dentro de unidades lógicas llamadas paquetes, formalmente conocidos como clases de desarrollo.

La definición de cada paquete contiene una asignación a una capa de transportes. Los objetos, a través de la asignación del paquete, indirectamente son asignados a la capa de transportes.

Todos los objetos entregados por SAP están asignados a la capa de transportes SAP. Todos los objetos de customizing y los objetos de desarrollo que vayan a ser transportados por la ruta de transportes son asignados a otras capas de transportes, estas capas de transportes son normalmente denominadas Z<SID>, donde <SID> corresponde al ID del sistema de desarrollo.

En el contexto de las rutas de transporte, un sistema SAP puede tomar los siguientes roles:

Sistema de Integración: el sistema donde se originan los cambios y son asignados a las órdenes de transportes. Es el punto donde las modificaciones de “cliente” se integran con el estándar de SAP.

Sistema de Consolidación: el sistema destino de una ruta de consolidación. Sistema de Entrega o Reparto: es el o los sistemas destino de una ruta de entrega o reparto.

Necesitaremos configurar más capas de transporte si nuestro landscape es más complejo y también si necesitamos redirigir la ruta de ciertos objetos si no usarán la ruta de transportes estándar.

Por ejemplo, si un sistema de entrenamiento separado existe y hay ciertos programas que serán ejecutados allí pero no queremos que esos programas lleguen al sistema de calidad o producción.

Configuración Básica de TMS

Ingresar a la tx STMS

Para realizar la configuración del TMS se debe ingresar al cliente 000 en el controlador de dominio y la TX STMS, al no estar configurado el sistema de transporte, se obtendrá una ventana donde solicitara información del sistema donde estamos realizando la configuración y el dominio de transporte que estamos creando para nuestro sistema de transportes ya que para el ejemplo práctico este sería el primer sistema instalado, se tomara los valores propuestos

Una vez que se guarde la configuración, se empezara a trabajar con la tx STMS

Desde esta vista podrá observarse todos los sistemas que integran nuestro dominio de transporte

Para proseguir con la configuración, se creara sistemas virtuales dentro del dominio

Con el sistema virtual podrá configurarse todos los sistemas de transporte sin la necesidad de tener los demás sistemas realmente instalados

Se crea el sistema de QAS y PRD

Ya se tiene todo el landsacpe con los sistemas necesarios

Ahora veremos las rutas de transportes

Pasamos a la visualización del editor grafico

Desde acá se configuraran las rutas de transportes entre los tres sistemas

Arrastramos DEV y luego damos doble clic sobre QAS y PRD para añadirlos en el entorno grafico

Una vez colocado los tres sistemas, empezaremos con la creación de las rutas

Primero se dibuja la ruta que va desde DEV a QAS

La ruta desde un sistema de desarrollo y calidad es de tipo consolidación, este tipo de ruta se otorga a los sistemas desde donde se liberan las órdenes de transporte y el próximo sistema donde se importaran

En la ruta de consolidación también debemos elegir la capa de transporte, por lo general son dos; una capa llamada SAP para los objetos estándar de sap y otra capa llamada ZDEV dependiendo del nombre que tenga el sistema de desarrollo para los objetos propios

Agregamos la ruta de transporte de consolidación con la capa de transporte Z<SID> O ZDEV para todos los objetos que sean creados para en el sistema de desarrollo

Ahora creamos la ruta entre QAS y el sistema de Producción, en este caso es de entrega o Delivery esta ruta se utilizan entre los sistemas en los cuales ambos realicen importaciones de ordenes de transporte

Luego de configurar el sistema de transporte, se guardan los cambios

Otra opción de configurar el sistema de transportes

Sap provee las configuraciones predeterminadas para landscapes de 1,2 o 3 sistemas

En este caso solo se debe indicar cuales son los sistemas de desarrollo, calidad y producción

Luego el sistema generara automáticamente la ruta ente los tres sistemas

Guardar

Lección 1: El Proceso de Transportes

Como administradores del sistema SAP, deberemos asegurarnos el correcto movimiento de cambios a través del landscape de sistemas mediante el curso del proceso de transportes.

Pasos en el Proceso de Transportes

Figura 142 – Resumen: Estrategia de Transportes

En las versiones anteriores a 3.1H, los transportes se realizaban a nivel del sistema operativo. Con la introducción del Sistema de Gestión de Transportes (TMS), los transportes se realizan desde el mismo sistema SAP.

En el TMS, las órdenes de transportes son transportadas a lo largo de rutas de transportes predefinidas. Ya vimos anteriormente que podemos definir múltiples rutas de consolidación o de entrega. El procedimiento de importación puede ser realizado por cualquier usuario que tenga las autorizaciones desde el sistema SAP sin que se necesite acceso al sistema operativo. Sin embargo, casi todas las funciones en la transacción STMS son ejecutadas por comandos del programa tp en el sistema operativo, que con cierto nivel de conocimiento técnico podríamos llegar a realizar manualmente en algún caso necesario.

Las órdenes de transporte que están pendientes de importación se visualizan en la cola de importación del sistema destino desde cualquiera de los sistemas SAP que conforman el dominio de transportes.

Usando TMS podemos importar completamente la cola de importación, esto es, todas las órdenes de transporte que fueron exportadas desde el sistema de desarrollo. Esto asegura que ningún error de importación ocurra debido a objetos faltantes y que las últimas versiones de un objeto no sean sobrescritas por versiones anteriores.

Liberación y Exportación

Figura 143 – Proceso de Transporte: Liberación y Exportación

El primer paso en el proceso de transportes es liberar una orden de transporte y por consiguiente exportar todos los objetos asociados desde la base de datos del sistema de desarrollo (DEV) a archivos en el directorio de transportes común a nivel del sistema operativo. Para cada orden de transporte, los datos son exportados a un archivo de datos en el subdirectorio data y un archivo de control es creado en el subdirectorio cofiles.

Durante la exportación, las entradas necesarias para la importación siguiente son creadas en el buffer de importación del sistema destino, y una importación de prueba puede realizarse.

En el directorio buffer, en el sistema operativo, hay una buffer de importación para cada sistema SAP en el dominio de transportes. El archivo tiene el nombre del sistema SAP al que pertenece (DEV, QAS, PRD, etc.) y contiene información de control respecto a que órdenes de transporte deben ser importadas y en qué orden.

Varios comandos de control de transporte pueden utilizarse para manejar los archivos de buffer de importación en el sistema operativo. La información de control en los archivos de buffer de importación es leída y representada como las colas de importación accedidas desde el sistema SAP. Una cola de importación muestra todos las órdenes de transportes que están contenidas en el buffer correspondiente.

Figura 144 – Proceso de Transporte: Importación en QAS

Usando TMS desde el sistema SAP, el segundo paso en el proceso de transportes es: importar todas las órdenes listadas en la cola de importación del sistema de calidad (QAS). TMS realiza la importación iniciando el programa de control de transportes tp en el sistema operativo.

Después que las órdenes de transportes se han importado correctamente en el sistema de QAS, las órdenes se agregan en el buffer de importación (con estado inactivas si es que el procedimiento de QA está implementado) y la cola de importación del sistema de producción (PRD) y cualquier otro sistema de entrega según la ruta de transporte.

Figura 145 – Proceso de Transporte: Aseguramiento de Calidad

Después de importar en el sistema de QAS, los objetos necesitan ser testeados por posibles errores. Los errores deben ser corregidos en el sistema de desarrollo, y los cambios importados nuevamente (con una orden de transporte nueva por supuesto) en el sistema de QAS. Durante la importación en QAS, la orden o las órdenes de transportes adicionales son agregadas al buffer de importación del sistema de producción.

Figura 146 – Proceso de Transporte: Importación en PRD

Después que todas las órdenes de transporte que fueron importadas en QAS han sido testeadas y verificadas, las órdenes deben ser aprobadas (si el procedimiento de QA está activo). El estado de la entradas cambian de inactivas a activas y las órdenes de transporte están listas para importar en el sistema PRD.

Usando TMS, podemos importar todas las órdenes de transporte, o simplemente un primer conjunto de las órdenes que fueron verificadas que se encuentran en la cola de importación en la secuencia que se presentan.

Para asegurarnos que no haya ningún efecto negativo en las actividades de producción, debemos asegurarnos que los errores y las correcciones se importen en el orden correcto, o sea, respetando el orden de importación de la cola.

Lección 2: Importación usando TMS

El administrador de transportes debe seguir las normas establecidas para la estrategia y planificación de transportes. De esta forma, nos aseguraremos que los cambios sean distribuidos de forma consistente en el landscape.

Visualizando Órdenes de Transportes usando TMS

Las colas de importación de TMS, reflejan los buffer específicos de cada sistema que se encuentran a nivel del sistema operativo. Las colas de importación muestran el orden correcto en que deben importarse las órdenes. Las colas de importación de todos los sistemas se pueden visualizar desde cualquier sistema del dominio de transportes, así también como realizar las importaciones.

Para acceder lo hacemos mediante la transacción STMS y luego desde el menú

Overview Imports. Allí veremos el estado actual de la cola de importación, a veces es necesario refrescarla para una vista actualizada. El timestamp muestra que tan reciente es la información.

Figura 146 – Información de la Cola de Importación

Para que la información de la cola de importación se refresque automáticamente

podemos configurar un job de background periódico. Para esto elegimos STMS

Overview Imports Extras Update All Import Queues. Luego seleccionamos con qué período se ejecutará el job. Cada una hora es un tiempo razonable. El programa es RSTMSCOL.

Figura 147 – Colas de Importación y Buffer de Importación

Marca de Stop

Los términos buffer de importación y colas de importación están relacionados. La cola de importación en el sistema SAP representa el buffer de importación que se encuentra en el directorio de transportes. La cola de importación resalta las órdenes que serán importadas durante la próxima importación (método importar todo). Debido a la marca de stop (stopmark), podría haber más órdenes de transportes en el buffer de importación que aquellas resaltadas en la cola de importación.

El stopmark indica que solo las órdenes anteriores a la marca serán importadas. El stopmark se crea tanto en la cola de importación como en el buffer de importación. En la cola de importación se muestra con la leyenda “End of Import Queue”. En el buffer, el término stopmark se muestra. Puede solo haber un stopmark en cada buffer de importación.

Para crear un stopmark para cerrar la cola de importación, desde la misma cola de

importación en STMS elegimos Queue Close. Esto es análogo en el sistema operativo con el comando tp setstopmark.

Para quitar la marca de stop, aunque normalmente no se realiza esto, desde la misma

pantalla selecciona Queue Open. En el sistema operativo tp delstopmark.

También podemos mover luego la marca de stop a otra posición en la cola de importación. Seleccionamos la orden delante de la cual queremos situar la marca y

elegimos Queue Move End Mark. En el sistema operativo tp mvstopmark.

Figura 148– Cola de Importación

La cola de importación es útil para: Visualizar el estado de las órdenes. Acceder a listas de objetos en las órdenes, documentación, y logs de transportes. Cerrar y abrir la cola y mover la marca de stop. Importar todas las órdenes, proyectos completos, órdenes preliminares, y órdenes

seleccionadas de acuerdo a ciertos filtros. Agregar, borrar y redireccionar órdenes.

Para mantener los sistemas SAP consistentes, es necesario establecer fechas límites para coordinar la liberación de órdenes de transportes de los desarrolladores. Para prevenir que las órdenes liberadas posteriormente a la fecha límite sean importadas, la cola de importación puede cerrarse. Las órdenes liberadas posterior al cierre de la cola se posicionan luego de la marca de stop en la cola para la próxima importación. Solo las órdenes previas a la marca de stop son importadas.

En casos excepcionales, podemos redireccionar una orden de transporte a otro sistema SAP antes de que sea importada en el sistema destino de la cola de importación. Por ejemplo, antes de importarse en el entorno de calidad, una orden necesita ser enviada al sistema de entrenamiento. Para importar una orden en un sistema fuera de la ruta predefinida, en la pantalla de la cola de importación seleccionamos la orden y luego

Request Forward System.

También podemos borrar o agregar órdenes de transporte a una cola de importación. Las dependencias de objetos pueden causar inconsistencias en el sistema destino luego en la importación. Por ejemplo, si borramos una orden que contiene un nuevo elemento de datos, todas las ordenes que contengan tablas que dependen de ese elemento de dato fallarán. Para evitar estas inconsistencias, es muy importante no borrar órdenes de transporte.

Figura 149 – Importación de Todas las Órdenes de Transporte

Para importar todas las órdenes en la cola, lo que se conoce como un “Importar Todo”, seleccionamos el botón Import All Requests. La ventana Start Import aparece.

Si tenemos configurado el Control de Transporte Extendido, el cliente destino está fijado. De otra forma, deberemos seleccionar el cliente destino.

Tenemos varias opciones para iniciar el transporte: En la solapa Date podemos planificar la importación. En la solapa Execution podemos seleccionar si TMS iniciará tp de forma sincrónica o

asincrónica. De forma asincrónica significa que tp trabajará en background y no bloqueará la sesión durante la importación.

En la solapa Options podemos seleccionar opciones expertas conocidas como modos incondicionales. Las opciones y las que son por defecto varían según la estrategia de transportes configurada.

La pantalla Import Overview muestra si la importación está corriendo. Después de la importación, la marca de stop es removida y la cola se abre nuevamente automáticamente. Después que las órdenes de transporte han sido importadas exitosamente, son automáticamente agregadas a la cola de importación del siguiente sistema.

Si usamos el procedimiento de Aprobación de QA, todas las órdenes en la cola de importación en el o los siguientes sistemas son marcadas como inactivas. Si tratamos de importar órdenes donde al menos una se encuentra inactiva, TMS no realizará la importación.

Solamente podremos importar todas las órdenes en un sistema de entrega si todas las órdenes listas para importar han sido verificadas en todos los pasos del procedimiento de aprobación (ya sea que se aprueben o se rechacen).

Si todas las órdenes para un proyecto han sido aprobadas, puedes importarlas en el sistema de entrega aún si hay todavía otras órdenes sin procesar por el procedimiento de aprobación o rechazadas en la cola de importación.

Si realizamos una importación a través de la opción importar todo, los objetos son importados en la secuencia correcta como se listan en el buffer. Esto significa que si las órdenes de transportes cerca del comienzo de la lista y aquellas cerca del final

afectan a los mismos objetos, las versiones finales de estos objetos después de la importación estarán activos con los últimos cambios. Como resultado, los objetos incorrectos no afectan el ambiente productivo.

Podemos desactivar la opción de realizar una importación completa, importar todo, para cada sistema usando el parámetro de TMS NO_IMPORT_ALL

Figura 150 – Importar un Proyecto Completo

Antes de iniciar la importación, SAP recomienda configurar la marca de stop para cerrar la cola de importación. Esto evita la importación de otras órdenes que podrían aparecer en la cola.

Podemos usar también filtros en la cola de importación para limitar las órdenes que se muestran con propiedades específicas de forma que podamos ver solo las órdenes que pertenecen a un proyecto particular o con cierta relación entre sí por ejemplo porque fueron creadas por el mismo usuario. Para configurar un filtro, debemos posicionar el cursor en una columna de la cola de importación y seleccionar el botón Filters.

Figura 151– Importar una Única Orden de Transporte (Importación Preliminar)

En contraste a las importaciones estándar, las importaciones preliminares son importaciones de una única orden (o un conjunto seleccionado). SAP recomienda

utilizar la importación estándar por la dependencia entre objetos y el riesgo de inconsistencias cuando se importan órdenes individuales.

Por ejemplo, un reporte ABAP en una orden puede ser importado correctamente, pero la tabla a la que refiere puede estar en otra orden de transporte que no ha sido importada aún. Hasta que la tabla no es importada, la ejecución del reporte generará short dumps. Por esto debemos usar la importación preliminar en casos excepcionales.

Para minimizar los riesgos asociados con importaciones preliminares, la orden queda en la cola de importación luego de que ha sido importada y es re-importada la próxima vez que toda la cola es importada. Esto garantiza que la secuencia de exportación e importación es siempre la misma. Esto se define con la opción Leave Transport Request in queue for later import, la cual es marcada dependiendo de la estrategia de transportes.

Lección 3: Opciones y Estrategias de Transportes

Opciones Adicionales en la Importación

En circunstancias particulares, podría ser necesario especificar opciones adicionales cuando realizamos una importación preliminar.

Ignorar que la orden de transporte ya ha sido importada.

Sobrescribir originales: si un objeto fue creado en el sistema destino y la orden contiene el mismo objeto tendremos que usar esta opción para que la importación no falle.

Sobrescribir objetos en reparaciones sin confirmar: un objeto que fue modificado en un sistema donde no es original, por ejemplo un objeto estándar de SAP, es un objeto marcado como reparado en el sistema. Si la orden contiene un objeto que en el sistema destino está marcado como reparado, deberemos utilizar esta opción.

Ignorar tipo de transporte inválido Los objetos de las órdenes de transportes seleccionadas para importación serán importadas de la siguiente manera:

Todos los objetos de todas las órdenes de transportes son tratados de manera conjunta, esto es, independiente de la orden a la que pertenecen.

Primero todos los objetos son ordenados de acuerdo al nivel que pertenecen (ej. las definiciones de tablas antes que los programas).

En caso de un objeto que se encuentra en más de una orden de transporte, solo la versión en la última orden de transporte es importada (de acuerdo a la secuencia en la cola de importación)

Esto es independiente del método de importación elegido (Importar Todo, Importar Proyecto, Importación Individual)

En un landscape de tres sistemas, la cola de importación de QAS refleja el orden de exportación de DEV. La cola de importación de PRD refleja el orden de importación que se realizó en QAS. Esto no siempre es idéntico en todos los casos. Pero es la secuencia correcta.

Planificación de Importación

Figura 152 – Fecha y Hora de Importación

Dependiendo si seleccionamos la importación por proyecto, importación individual, importar todo, o un workflow especial de transporte y particularmente de la versión de SAP y nivel de Support Package, las opciones pueden variar. Cuando iniciamos una importación, podemos elegir las siguientes opciones en la solapa Date:

Immediate

Seleccionando esta opción inmediatamente inicia la importación en un work process de diálogo.

At Start Time

Si elegimos esta opción la importación inicia en una fecha y hora específica. Se planifica un job de background en el sistema destino. Si ingresamos un fecha y hora en el campo No Start After, la importación puede iniciar en la ventana de tiempo entre Planned Start y No Start After. Si no hay work processes de background disponibles durante la ventana de tiempo, la importación no se relaliza. Si queremos que la importación se realice regularmente debemos ingresar la frecuencia en el campo Period.

After Event

Seleccionando esta opción la importación se inicia solamente después que un evento específico se dispare. Si seleccionamos Execute Import Periodically, la importación se inicia cada vez que el evento seleccionado ocurre. De otra manera, la importación ocurre solo la primera vez que sucede el evento.

En los transportes individuales o en un workflow de transporte el campo Period no existe.

Desde la cola de importación de cada sistema SAP, podemos monitorear y mantener

todas las importaciones planificadas seleccionando Goto Job Monitor.

Figura 153 – Frecuencia de Transportes

Después de la exportación, una orden de transporte no es importada automáticamente, sino que debe hacerse manualmente. Cuando planificamos las importaciones, deberíamos incluir un tiempo suficiente entre cada importación para poder realizar las tareas de pos-importación tal como las pruebas de QA. SAP recomienda que la planificación de las importaciones sea intervalos de tiempo regulares tal como mensual, semanal o diaria y usando la estrategia Importar Todo en el sistema destino. La importación frecuente no es recomendada.

Las siguientes acciones tienen que considerarse:

Liberación de órdenes de transportas. Copia en un cliente en el mismo sistema (de desarrollo) mediante la transacción

SCC1 (test unitario). Importación en clientes en sistemas subsiguientes.

La frecuencia de transportes está basada en los siguientes factores:

Clientes y los roles de estos en el landscape de sistemas. Requerimientos de sincronización, esto es, cuando son requeridos los cambios en los

diferentes sistemas. Requerimientos de Congelamiento de Código (Code Freezing).

Estrategias de Transportes

Hay tres estrategias de transportes diferentes disponibles:

Transporte masivo controlado por la cola. Transporte individual controlado por la cola. Transporte controlado por workflow.

La estrategia de transporte es por defecto el Transporte masivo (Importar Todo).

Transportes Masivos: son una buena solución si tenemos que adminsitrar un gran número de transportes y queremos automatizar el proceso lo más que podamos. El uso continuo de importación masiva es la forma más segura de mantener los sistemas sincronizados y consistentes. Antes de importar con este método en el sistema de producción, deberemos verificar que todas las órdenes en el sistema de calidad y la confirmación (o aprobación) de estas en los demás sistemas (por ejemplo el de producción).

Para esto usamos el procedimiento de QA en TMS. También deberemos definir la importación masiva como el método elegido para los sistemas relevantes. Para esto, seleccionamos la estrategia de transportes Queue-controlled mass imports.

El administrador puede planificar las importaciones periódicamente en TMS, o iniciar cada importación manualmente. Solamente deberíamos importar órdenes individuales antes que otras según el orden de la cola de importación en casos especiales. Las órdenes de transportes que son importadas previamente son importadas nuevamente en la importación normal, o sea la importación masiva. Esto es así por la opción Leave transport request in queue for later import la cual se selecciona automáticamente cuando realizamos un transporte que no sea masivo (Importar Todo). También podemos usar workflow para importar órdenes de transportes individuales. Importación Individual: usamos esta estrategia si tenemos pocos cambios para transportar y la organización no nos permite realizar una planificación fija de transportes. Este método usualmente demanda un esfuerzo extra para los administradores en comparación a los transportes periódicos. Los desarrolladores deberán poner atención a la consistencia de sus órdenes de transportes.

Si un número pequeño de desarrolladores están trabajando en un proyecto, y también en un mismo equipo con el administrador, usualmente crean sus propias órdenes de transporte e incluso la importación de las mismas en el sistema de calidad. En el caso en que los transportes individuales que realicemos en el sistema tengan que realizarse por el administrador de sistema, recomendamos que se utilice el workflow de transportes. Este método automáticamente dispara un workflow cuando se libera la orden de transporte.

El workflow asegura la comunicación entre el desarrollador y el administrador. Como requisito tendremos que haber configurado el worfklow de transportes en el sistema.

Lección 4: Establecer y Modificar Estrategias de Transportes

Mantener las Estrategias de Transporte

La estrategia de transporte masivo está configurada por defecto en el sistema luego de la instalación y configuración de TMS. Si queremos trabajar con transportes individuales controlados por cola o transportes controlados por workflow, podremos seguir los pasos de configuración descriptos a continuación:

Figura 154 – Transacción STMS: Overview → Transport Routes

1. Inicia la transacción STMS y luego Overview ->Transport Routes. La pantalla Display ->Transport Routes aparece mostrando las rutas de transportes existentes en el dominios de transportes. 2. Cambia al modo de edición seleccionando Configuration ->Display ↔ Change. 3. Posiciona el cursor sobre el sistema SAP para el cual queremos cambiar la configuración de la estrategia de transportes. 4. Seleccionamos Edit ->System ->Change. El cuadro Change System Attributes aparece. 5. Seleccionamos la solapa System Attributes y luego elegimos la estrategia de transportes.

Dentro de un grupo de transportes debemos configurar a todos los sistemas con la misma estrategia, ya sea Queue-controlled transports o Workflow-controlled transports.

6. Seleccionamos Copy.

7. Luego Configuration Distribute and activate.

Configuraciones en TMS dependiendo de la Estrategia de Transporte

Queue-controlled mass transports (Transportes masivos controlado por cola)

Por defecto la opción Leave transport request in queue for later import está activada, cuando se realiza una importación individual.

La opción de importación Leave transport request in queue for later import hace que las órdenes importadas como transportes individuales se mantengan en la cola de importación para que sean importadas en el orden correcto en la próxima importación de todas las órdenes.

Esta opción es útil si tenemos que hacer una importación preliminar para órdenes individuales. Esto previene que objetos más antiguos sean importados en la próxima importación normal de todas las órdenes.

Queue-controlled single transports (Transportes individuales controlado por cola) Por defecto, la opción de importación Leave transport request in queue for later import está desactivado.

La barra de botones en la cola de importación cambia de acuerdo a los requisitos de la estrategia de importación de transportes individuales. Por ejemplo, contiene una función de selección.

En la función Importar Todo (el camión con carga completa) está solamente disponible si elegimos uno o más proyectos usando la función de filtro. Esto previene que se importe accidentalmente todas las órdenes en la cola.

Workflow-controlled transports (Transportes controlados por workflow) Las propuestas de transportes son creadas automáticamente cuando las órdenes son exportadas.

Las opciones de importación se corresponden con las de los transportes individuales. Las importaciones se agregan a la lista de procesamiento de las propuestas de transportes en la lista de trabajo de TMS.

Una advertencia aparece en la cola de importación si intentamos realizar transportes sin usar el workflow de transportes.

Los siguientes parámetros para el programa de control de transportes y el Sistema de Cambios y Transportes (CTS) son configurados acorde a la estrategia de transportes elegida: Parámetros de tp para las estrategias de transportes:

El parámetro de tp STOPONERROR define a partir de que código de error la importación se detiene. REPEATONERROR define desde que código de error la importación no es clasificada como exitosa y tiene que repetirse. Por ejemplo, con Transportes Individuales, el código de error 8 es tomado como una importación fallida y tiene que ser repetida. Con Transportes Masivos, el mismo código de error 8 será una importación exitosa.

No cambies manualmente los parámetros que son relevantes a la estrategia de transportes. TMS genera estos parámetros cada vez que la configuración de rutas de transportes es modificada.

Transportes de Copias y Reubicación

Figura 155 – Transporte de Copias y Reubicación

Utiliza la función Transport of copies para transportar objetos a otro sistema SAP que seleccionemos. Esta función es especialmente útil si el sistema destino no es un sistema de consolidación desde el sistema donde vamos a generar la orden. Los objetos son transportados con la versión que tienen en el sistema donde nos encontramos. La ubicación original del objeto (sistema origen) no es modificada. La orden de transporte no será agregada tampoco a la cola de importación de un sistema subsiguiente en la ruta de transportes.

La función Relocation of objects w/o package change nos sirve si el trabajo de desarrollo sobre los objetos se realizará temporalmente en otro sistema SAP. Algunos desarrollos especiales podrían ser realizados en un sistema SAP separado, por ejemplo, para no interferir con el proceso normal de desarrollo. Estos tipos de órdenes nos permite mover ubicaciones originales de los objetos a un sistema destino, o sea cambiar el sistema al que pertenece donde es original el objeto. Usamos la función Relocations of objects with package change cuando el sistema de desarrollo de los objetos que transportaremos será cambiado de manera permanente. Este tipo de órdenes nos permite cambiar la ubicación original de los objetos al sistema destino y también cambiar el paquete de los objetos al mismo tiempo. Debido a esto último, los objetos tienen los atributos del paquete al que son asignados en el sistema destino inmediatamente luego de la importación.

Usamos Relocations of Complete Package cuando el sistema de desarrollo de un paquete completo será cambiado de manera permanente.

Lección 5: Configuración y Características del Procedimiento de QA

Las órdenes de transportes serán importadas en el sistema de producción solamente después que sean aprobadas en el sistema de calidad. Por lo tanto necesitaremos contar con un procedimiento de aprobación de calidad.

Aseguramiento de Calidad en TMS

El procedimiento de aseguramiento de calidad (QA) incrementa la calidad y la disponibilidad del sistema de producción permitiéndonos verificar las órdenes de transporte en el sistema de calidad antes de que sean entregadas en los sistemas subsiguientes.

Cuando activamos el procedimiento de aprobación de calidad QA, las órdenes de transporte estarán disponibles para ser importadas en el o los sistemas de entrega si todos los pasos del proceso de calidad han sido aprobados.

Cuando configuramos el sistema de QA determinamos cuantos pasos de QA deberán aprobarse para cada orden de transporte. Si uno de los pasos no es aprobado, entonces la orden no puede ser aprobada. Solo podremos importar órdenes que hayan sido completamente aprobadas.

Las órdenes rechazadas no son importadas en el sistema de entrega.

Figura 156 – Configuración del Procedimiento de Aprobación de QA

Antes que podamos procesar órdenes de transportes deberemos configurar el procedimiento de aprobación de QA. Al menos deberemos contar con un landscape tradicional de tres sistemas (DEV, QAS y PRD). El sistema que que configuremos como el sistema QA deberá contar con los siguientes atributos:

Debe ser el destino de al menos una ruta de consolidación.

Debe tener una ruta de entrega hacia otro sistema al menos.

Después de la configuración, la lista de trabajo de QA es automáticamente creada. Todas las órdenes importadas en el sistema de QA son incluidas en la lista de trabajo de QA.

Pasos en el Procedimiento de Aprobación de QA

Para visualizar la lista de trabajo de QA, usamos las transacción STMS y seleccionamos

Overview Imports Goto QA worklist. La fecha y hora en la parte superior derecha de la pantalla indica cuando la lista de trabajo de QA ha sido actualizada por última vez; la parte susperior izquierda indica cuantas órdenes aún están pendientes de procesamiento.

La lista muestra las órdenes de transporte que se corresponden con el paso de aprobación seleccionado. Por defecto, las órdenes correspondientes a todos los pasos se visualizan en primer lugar. Para seleccionar el paso de aprobación y ver todas las

órdenes que concuerdan con el mismo seleccionamos Worklist Select Approval Step. Con un doble clic sobre uno de los ítems en la lista de trabajo podemos obtener más detalles sobre el mismo.

Figura 157 – Aprobación QA

Antes de importar las órdenes en un sistema de entrega deberíamos testear las órdenes en el sistema de QA. El estado de QA rechazada (rejected) siginifica que uno o más pasos de aprobación no fueron aprobados por la persona responsable. Una orden es aprobada solamente si todos los pasos de aprobación tienen el estado aprobado (approved).

En la lista de trabajo de QA podemos ver:

El estado de QA (St) El estado general (GS) El número de paso (Nr)

Una vez que todos los pasos de aprobación fueron procesados satisfactoriamente entonces la orden de transporte podrá ser importada en el sistema de entrega. Si todas las órdenes para un proyecto han sido aprobadas, pueden ser importadas en el sistema de entrega a pesar que otros proyectos aún tengan órdenes pendientes de procesar o rechazadas en la lista de trabajo de QA.

Las órdenes con el estado rechazada en QA así también como las órdenes aún sin procesar en la lista de trabajo no son importadas en los sistemas de entrega.

A partir de la versión 6.10 la aprobación o rechazo de un paso individual puede ser modificado, mientras que el procedimiento completo de aprobación no esté realizado.

Una vez que todos los pasos de aprobación están completo, no es posible cambiar la decisión. SAP recomienda no rechazar las órdenes que contengan errores, sino más bien corregir los errores en una nueva orden de transporte y luego aprobar todas las órdenes de transportes vinculadas en conjunto.

Figura 158 – Historial de QA

Desde la pantalla de la lista de trabajo de QA, podemos acceder al historial de QA

mediante Goto QA History.

El historial de QA muestra todas las órdenes para un período específico que ya no se muestra en la lista de trabajo. Las órdenes no se visualizan tampoco en la lista de trabajo una vez que han sido aprobadas o borradas. El período por defecto para la lista de QA es de 30 días pero puede ser cambiado.

Para determinar quien fue responsable de aprobar una orden de transporte,

seleccionamos Request Display QA Status

El historial de QA se almacena en la base de datos del sistema de calidad, por lo que si realizamos una copia de base de datos o de sistema desde el sistema de producción por ejemplo, el historial se perderá. Podemos consultar por notas en el Marketplace de SAP para mayor información.

Workflow de Transportes Especiales

Figura 159 – Workflow de Transportes Especiales

Utilizaremos el workflow de transportes si se requieren de manera urgente un transporte de correcciones o si se necesitan transportes que no siguen la ruta de transportes definida.

Antes de utilizar el workflow de transportes, será necesario configurar uno de los sistemas como el Workflow Engine. Este sistema debería tener las siguientes características listadas en orden de importancia:

Alta disponibilidad Carga de trabajo baja a media

Estos requisitos son por ejemplo los que posee el sistema de calidad QAS. Todas las tareas realizadas por el workflow de transportes son centralizadas en el Workflow Engine y luego los resultados se comunican a los sistemas SAP involucrados.

Figura 160 – Configurando el Workflow de Transportes Especiales

Para configurar el workflow de transportes especiales, realizaremos lo siguiente: Ingresamos al sistema que funciona como controlador de dominio de transportes.

Iniciamos la transacción STMS y luego desde el menú Overview Systems Goto Transport Domain.

Seleccionamos la solapa Worfklow Engine.

Cambiamos al modo de edición con el botón de Display ↔ Change. Ingresamos el sistema SAP, el cliente y el host destino para el Workflow Engine. Luego de guardar las modificaciones tendremos que aceptar afirmativamente el cuadro para distribuir la configuración. A continuación ingresamos al sistema que funcionará como el Workflow Engine. El sistema automáticamente:

Crea el usuario TMSADM_WF. Genera los destinos RFC necesarios para el Workflow Engine. Envía los datos propios de Workflow Engine a todos los sistemas en el dominio de

transportes. Realiza el customizing para el worfklow en el sistema.

Figura 161 – Creando las Propuestas de Transportes

Para utilizar el workflow de transportes, tendremos que crear una propuesta de transportes. Para esto, desde el Organizador de Transportes, transacción SE09 y seleccionamos las órdenes liberadas (released requests). Seleccionamos la orden de

transporte que vamos a transportar y luego seleccionamos Utilities Create Transport Proposal.

Una ventana aparece donde ingresamos una descripción y el sistema destino, y también podremos agregar otras órdenes de transporte. La condición es que todas las órdenes que ingresemos en la propuesta de transporte estén liberadas.

Si una propuesta de transporte es creada, el sistema SAP le asigna un número de propuesta y luego es agregada a la lista de trabajo de TMS para el administrador de transportes. Si el administrador de transportes rechaza la propuesta de transporte aparecerá nuevamente en la bandeja de entrada de propuestas de transportes del solicitante. Podremos cancelar la propuesta o revisarla y reenviarla nuevamente al administrador de transportes.

Después que el administrador de transportes ha aprobado la propuesta, la importación se inicia y la propuesta de transportes reaparece en la bandeja de entrada del solicitante. Luego de que verificamos que la orden de transporte se importó correctamente en el sistema destino, confirmamos la propuesta de transporte.

Figura 162 – Lista de Trabajo de Propuestas de Transportes

Para aprobar o rechazar una propuesta de transportes, iniciamos la transacción STMS.

Para visualizar la lista de trabajo de TMS, seleccionamos Overview Worklist. Con doble clic seleccionamos la propuesta de transporte que queremos procesar.

Podremos verificar allí si las órdenes, la lista de sistemas destinos, las fechas de importación y opciones para la propuesta de transportes son correctas. También podemos visualizar las órdenes de transporte seleccionando Display y el ícono de los logs de transportes.

Cambiamos al modo de modificación si queremos hacer modificaciones a las órdenes de transportes, destinos, fecha de importación u opciones de importación.

Se pueden agregar mensajes para un desarrollador por ejemplo con el ícono Manage Attachments. Para procesar la propuesta de transporte, seleccionamos el ícono para aprobar o rechazar la propuesta.

Una vez aprobada una propuesta de transporte, la importación en el o los sistemas destinos es iniciada automáticamente.