UNIDAD II

LECCION 1. ARQUITECTURA DEL SAP NETWEAVER AS

1| Características 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 211 – 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.

¿Que 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)

2| Arquitectura principal del SAP Netweaver AS

Durante la implementación de un sistema SAP deberemos decidir la arquitectura de nuestro sistema SAP y  como 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.

3| 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 212 – Dos definiciones de Cliente-Servidor

4| 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 213 – Configuraciones Cliente-Servidor.

En las implementaciones de SAP vamos a encontrar las opciones de dos y tres tiers comúnmente. En el caso del sistema que utilizamos para la práctica del curso es un ejemplo de configuración de single-tier ya que todos los procesos, base de datos, aplicación y presentación corren en una única máquina.

5| 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 214 – 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 214 – 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) tal como nuestro sistema Netweaver que instalamos para este curso. 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.

6| ¿Que 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.

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

Figura 215 – Variantes de instancias Netweaver SAP

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 211 – Combinaciones posibles de instancias en un sistema SAP

8| 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 216 – 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 area de memoria en el servidor donde corre así también como su propia estructura de directorio.

 Figura 216 – 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).

 9| 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 217 – 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 217 – 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.

 10| 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 218 – Sistema ABAP+JAVA

LECCION 2. PROCESOS DEL SAP NETWEAVER AS

1| Procesos ABAP

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 221 – 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 sumariza estos parámetros:

  

Tabla 221 – Parámetros de Work Processes

Vamos a ver un poco más en detalles estos procesos en las próximas lecciones.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.

 2| Procesos JAVA

En el ambiente de ejecución de una instancia JAVA (o ABAP+JAVA) vamos a encontrar principalmente estos procesos:

El dispatcher distribuye los pedidos entre los server processes  de la instancia. El server process es quien finalmente ejecuta el pedido de la aplicación JAVA.  Estos procesos son multi-thread (multi-hilo) por lo que pueden procesar en paralelo un gran número de pedidos, en contraste a los procesos ABAP. 

Por cada dispatcher tendremos al menos un server process y como máximo un total de 16 server processes.

El Message Service de JAVA maneja la lista de dispatchers activos y también de server processes. Es responsable de la comunicación dentro del entorno de comunicación de JAVA. Existe solo uno por sistema.

El Enqueue Service administra los bloqueos lógicos que las aplicaciones JAVA solicitan durante su ejecución en el server process. Las solicitudes de bloqueo están incorporadas en el código de cada programa JAVA, por lo que es responsabilidad de los programadores cómo y cuándo solicitar un bloqueo en sus aplicaciones. Este proceso es único para todo el sistema también.

El Software Deployment Manager (SDM) es la herramienta estándar utilizada para instalar componentes de software de JAVA en el servidor de aplicación. 

 

Figura 222 – Procesos del entorno de ejecución JAVA

Durante el curso no profundizaremos mucho más sobre el entorno de ejecución JAVA o su administración ya que está fuera del alcance de este curso inicial.

LECCION 3. PROCESOS DE DIALOGO ABAP

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

2| 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 231 – 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 232 – 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 area 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.

3| 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 233 – 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.

LECCION 4. MULTIPLEXADO DE WORK PROCESSES

LECCION 5. Procesos Transacciones y Unidades de Trabajo Lógico

LECCION 6. PROCESOS DE BLOQUEOS

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)

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

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

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

 4| 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 261 – Gestión de bloqueos en SAP

En la figura 261 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.

 5| 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 262 – Transacción SM12

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

1| 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 271 – 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.

2| 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 272 – 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 273 – Transacción SM13 – Actualizaciones

LECCION 8. OTROS PROCESOS

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

2| 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 281 – Impresión en un servidor de aplicación ABAP

3| Spool work process

Como puede verse en la figura 281, 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 282 – Transacción SP02

  

Figura 283 –Transacción SU3: Configuraciones Personales

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

5| 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 284 – 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 284.

La transacción SMX nos muestra los jobs planificados por nuestro usuario.

(Figura 285 – Transacción SMX)

Más adelante en el curso dedicaremos más lecciones sobre este tema.

6| 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 286 – 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.

7| 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 287 – Internet Communication Manager (ICM)

UNIDAD III. TAREAS BASICAS DE ADMINISTRACION ABAP

LECCION 1. PROCESOS DE LOGON EN UN SISTEMA ABAP

1| Proceso de Logon 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 pocesoMessage

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 311 – 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 workprocess de diálogo libre para procesar el logon, transfiere los datos de logon a este workprocess, paso 4.

El workprocess 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 workprocess 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. En la próxima lección veremos cómo configurar los diferentes métodos.

LECCION 2. CONFIGURACION DEL SAP LOGON

Si bien ya utilizamos el programa SAP Logón para configurar el acceso a nuestro sistema SAP Netweaver, ahora veremos con mayor detalle los archivos que utiliza este programa para evaluar los parámetros de conexión.

1| Configuración de 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 Logónevalua varios archivos de configuración que se encuentran en el front-end del usuario. Estos archivos también pueden ser editados utilizando SAP Logón.

  

Figura 321 – Programa SAP logón

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 322 – 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. La 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 323 – 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 324 – 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 sistemay ID de sistema) sin consultar al Message Server.

 

Figura 325 – 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 326 - Activación de Asistente

Cuando nos logueamos utilizando un grupo de logón, el message server de ABAP es consultado primero para poder identificar la instancia con mayor disponibilidad en base a la cantidad de workprocess 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 327 - 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 328 - 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 329 -  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.

¿Donde 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)    Windowssystem32driversetcservices

 

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.

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

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

LECCION 3. TRANSACCIONES DE ANALISIS

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

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

LECCION 4. INICIO Y PARADA DEL SISTEMA SAP

Starting an SAP System is performed in a number of steps and is the task of the operating system user <sid>adm.

Start the database:. The underlying element of the entire SAP system is the database. Before the SAP instances are started, this must have operational status. The database is therefore always started as the first step.

Start the Central Services instance (AS Java and AS ABAP+Java)

. Start the Central Services instance that contains both the enqueue and the message service for the Java part of the SAP system. The Central Services are installed as an independent instance.

Starting the Central Instance:

. Next, the operating system collector SAPOSCOL is started, if it is not already active. This standalone program runs in the operating system background, independently of SAP instances. This program collects data about operating system resources and makes this data available through the shared memory of all SAP instances.

Note: If you later discover that SAPOSCOL has not been started, you can start it at any time by calling transaction ST06 and choosing the path Detail Analysis Menu → OS Collector → Start.

. The central instance with the message server and the dispatcher and its work processes is then started. If the start up parameters are set accordingly, the dispatcher also starts the Internet Communication Manager (ICM) and the processes of AS Java (if it is installed). You should only start other (optional) instances once the message and enqueue servers are active.

Starting the dialog instances. If the dialog instance is not running on the same host as the central instance, the SAPOSCOL operating system collector is first started on this host (if it is not yet running).. The dispatcher is then started with its work processes.

As of release SAP NetWeaver 7.0, the start service sapstartsrv that has been used for many years in the Windows installation is installed on all platforms. The service is a Windows service or a Unix daemon for the administration of an SAP instance.

A sapstartsrv process is started for each SAP instance and does not terminate even if the instance is stopped. When it starts, sapstartsrv reads the start profile of its instance and opens its Web service interface by default on the ports 5$$13 (HTTP,, $$ represents the instance number) and, providing SSL is configured, on 5$$14 (HTTPS). The start service then waits for incoming requests from Web service clients and processes these. The Web service interface contains a number of functions for administrating and monitoring an SAP instance, in particular the SAP Management Console (SAP MC). sapstartsrv also has a limited Web server function that allows you to download all files under DIR_EXECUTBALE/servicehttp by way of HTTP(S). This can be used to start the SAP Management Console from a Web browser on any host, for example. If no other URL is specified (for example, http://<hostname>:5$$13), the system automatically redirects you to http://<hostname>:5$$13)/servicehttp/sapmc/sapmc.html, for example, to start the SAPMC.

sapstartsrv manages an internal list of protected operations. These can be changed, if necessary, with the start profile parameter service/protectedwebmethods. With the start profile parameter service/hostname you

can also determine the IP address / host name to which the Web service port should be connected (default: all / 0.0.0.0), to limit accessibility in the network. You then have to restart sapstartsrv. To do this, refer to SAP Note 927637 - Web service authentication in sapstartsrv as of release 7.00.

Before you stop the system, you should check the status of the system. This involves,among other things:

. Active Users:Check which users are logged on using the User List (SM04).

. Background Processing :Check which jobs are active using the Job Overview (SM37). If jobs are terminated by the system stop, these jobs must be rescheduled. Jobs that are scheduled for the time when the system is stopped run automatically once the system restarts.

. Batch Input:The transaction Batch Input: Session Overview (SM35) displays running batch input jobs.

. Update:Use the Update Overview (SM13) to check whether update processes are terminated by the system stop. These update records are rolled back during the stop, and are set to the status .init.. These records are then updated again during the restart.

Before you stop your system, you should inform users using a system message (SM02).

The stopping of the SAP system is performed in the opposite order of starting.

Stop the instances:

. In the SAP system itself within the CCMS (transaction RZ03) by choosing Control → Stop SAP Instance.

. In the Microsoft Management Console, right-click to show the context menu and choose the Stop function. Depending on whether you have selected an individual instance or the SAP system, the following are stopped:

. A single instance

. Central instance and all dialog instances

The SAP service waits for a stop message from the SAP MC or from the CCMS and then stops the SAP system. The service itself does not stop.

The services themselves can be stopped and restarted with the corresponding operating system tools, such as the Windows Service Control Manager.

The database is stopped using the relevant database system tools.

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

1| 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 351 – 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 dependen 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 352: 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 dispatcherdev_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 aun puedes loguearte al sistema SAP, verfica el log del sistema utilizando la transacción SM21.

LECCION 6. HERRAMIENTAS DE ADMINISTRACION

LECCION 7. 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 371 – 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 órden 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 372 – 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 373 – 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 374 – 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 375- 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 archivosshmem.<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.

LECCION 8. EXTENSION DE LA LICENCIA DE SAP NETWEAVER

1| Pasos para extender la licencia de SAPNetWeaver

Vamos a explicar los pasos a seguir para extender la licencia de SAPNetWeaver. Recordemos que la licencia inicial de la instalación es de 30 días por lo tanto antes de cumplirse este plazo deberemos realizar este procedimiento. El plazo de la nueva licencia será por 3 meses y podrá ser renovada indefinidamente.

Lo primero que debemos hacer es solicitarle a SAP una nueva licencia para nuestro producto. Esto lo haremos desde la siguiente dirección web.

DESCARGAS

Solicitar nueva licencia de SapNetWeaver

Allí veremos la siguiente pantalla donde se especifican todas las versiones gratuitas disponibles de los productos SAP. La correspondiente a nuestra instalación es la NSP - SapNetWeaver 7.0.

Al fondo de la pantalla completamos la información pedida con nuestros datos. El SDN User ID es el nombre de usuario que creamos en la primera unidad para la instalación de SapNetWeaver.Tildamos la conformidad de la licencia. El System ID es NSP - SapNetWeaver 7.0/2004s.

 

Para obtener el Hardware key vamos a loguearnos en SAP e ir a la transacción SLICENSE. El Hardware key es el número que aparece a la derecha del texto Active Hardware key.

Una vez que obtenemos el Hardware key, volvemos a la pantalla de la licencia, copiamos el número, presionamos el botón Submit y veremos la siguiente ventana.

 

Si todo andubo bien, veremos el mensaje: "Your request has been succesfully submited. You will receive an email with your license key information".

Luego, recibiremos un mail en nuestro correo, que tendrá adjunto el archivo NSP.txt con la información de nuestra nueva licencia. Descargaremos el archivo adjunto en nuestro escritorio.

 

Luego verificamos que el Active Hardware Key que figura en la transacción SLICENSE del sistema coincida con el mismo código que figura al final del archivo.

En caso de no coincidir ambos, debemos copiar el Active Hardware Key de la transacción SLICENSE encima del mismo código que se encuentra al final del archivo.

Luego en la transacción SLICENSE, presionamos el botón New licenses, luego el botón Install y por último seleccionamos el archivo NSP.txt con la información de la licencia del escritorio.

Luego veremos la siguiente ventana indicandonos que la nueva licencia se instaló correctamente.

Por último, vemos que la nueva fecha de expiración es tres meses posterior a la fecha actual.

UNIDAD IV. MANTENIMIENTO DEL SISTEMA

LECCION 1. EVALUACION DE PARAMETROS 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.

1| 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 411 – 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 donde 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 412 – 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)

 

2| 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 413 – 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 414 – 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 415 – 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 416 – Transacción RZ11

Cuando modificamos un parámetros 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=numero 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.

LECCION 2. MANTENIMIENTO DE PARAMETROS SAP

 

LECCION 3. CONFIGURACION DE MODOS DE OPERACIÓN

The type and number of work processes for each instance is defined in the profiles.

The distribution of work processes in the profiles is optimized for fast dialog response times; that is, there are usually lots of dialog work processes and a small number of background work processes. This means that during the night, system resources, such as the main memory, are tied to the dialog work processes, or are not fully utilized by the background processes, such as the CPU. It is therefore practical to define different types and numbers of work processes for these different demands on the SAP system. This is realized through the concept of operation modes.

Using the operation modes, you can adjust the type and distribution of the work processes to the varying load distribution during the day. You can also adjust the distribution of the work processes to business requirements that only occur once.

By defining operation modes, you can change not only the total number of work processes defined in the profiles, but also the type and distribution of the individual work process types within this total number. The switch between the work process types is performed dynamically during the runtime of the SAP system. The switch is triggered using a defined schedule. A reserved work process is not immediately terminated, but marked for switching. This means that certain delays may occur. This type change is logged in the system log.During the switch of the operation modes, neither the instance nor the affected work processes needs to be restarted. This means that the quality of the buffer of the SAP system is retained during an operation mode switch, and that the request that is currently being processed by a work process is completed. The individual work processes retain their process ID after the switch. You can observe this in the process overview (SM50).

Setting Up Operation Modes

The operation modes are set up in a number of steps.

Steps to Configure Operation Modes. First, the operation modes are created as empty containers in transaction RZ04.. Next, all active instances of the system are detected and the work processes defined in the instance profile are assigned to the operation modes as default values.

. You can now make allocations for the individual operation modes in the total number of work processes taken from the instance profile. The allocation should be made primarily between the dialog and background work processes.

. You then specify the periods for which the operation modes are valid and when the switch between the operation modes should occur in the time table (SM63).

Monitoring and Consistency Check

The Control Panel (RZ03) allows you to monitor the instances and the operation modes and provides functions to:. Checkthe status of all instances and of the operation modes. Start and stop the instances. Manually switch operation mode. Displayan overview of the work processes. Switch to the Alert Monitor

You can switch the operation mode either for all instances (Control → Switch operation mode→All servers) or for a selected instance (Control→Switch operation mode → Selected servers).

You can first simulate the switch of operation modes (Control → Switch operation mode → Simulation). The system checks for which instances a switch can be performed.

You can display a detailed analysis of the status of the individual instances by choosing Monitoring → Status Details.

If it is not possible to switch between operation modes, this is usually due to inconsistencies in the SAP system. These inconsistencies can occur if the number of work processes is defined differently in different places in the system. These are the instance profiles at operating system level, the instance profile in the database, and the definition of the operation modes themselves.

If, for example, the number of work processes in the profiles is changed, the systemcan no longer switch operation modes until after a restart of the instance. It is thereforenecessary to adjust the configuration of the operation modes after a change to the profiles.

LECCION 4. ACCESO A LA AYUDA

Cuando se instala un sistema SAP, será necesario configurar la ayuda online para los usuarios. También en ciertos casos, tendremos que mantener la configuración de la ayuda.

 1| Acceso a la documentación con la Librería SAP

La Librería SAP, la cual es también conocida como la documentación online, es una fuente importante de información sobre los temas relevantes en el ambiente de SAP. Instalando la documentación online de forma local o a través de toda la compañía ayuda a los usuarios a trabajar de manera más eficiente con el sistema SAP.

La Librería de SAP puede ser llamada seleccionando Help SAP Library y provee acceso a la documentación online completa para el sistema.

Figura 441 – Librería SAP

Mediante la selección de la Librería SAP en el menú de ayuda (Help menú), puedes acceder a la documentación online. El término Librería SAP y documentación online son frecuentemente utilizados como sinónimos. Para SAP Netweaver, por ejemplo, la Librería SAP actual ofrece acceso a más de 10.000 documentos.

Utilizando la Librería SAP, puedes fácilmente buscar documentos online, acceder al glosario y visualizar la introducción al uso del sistema SAP (Getting Started).La documentación online es proviste en varios idiomas y si la ayuda ha sido correctamente configurada en el sistema, como se verá más adelante, esta es llamada en el lenguaje de logon del usuario.

 

2| Tipos de ayuda soportados

Figura 442 – Tipos de ayuda soportados

Las guías de instalación describen los diferentes tipos de ayuda y las propiedades de cada una con mayor detalle. A continuación se muestran las principales características de cada tipo de ayuda disponible para los sistemas SAP.

HtmlHelpFile: con este tipo de ayuda, los documentos se almacenan en el formato HTML Compilado (*.CHM). Estos archivos están disponibles utilizando un servidor de archivos y se pueden visualizar con el programa Visor de Ayuda HTML (HTML Help Viewer). El formato HTML Compilado fue desarrollado por Microsoft para almacenar archivos HTML en un formato comprimido. El requerimiento de espacio de almacenamiento para archivos CHM es aproximadamente un 10% del que es necesario para archivos HTML no comprimidos.

El programa HTML Help Viewer está basado en Internet Explorer por lo que puede ser utilizado en front ends con plataformas Windows de 32 bits. Este tipo de ayuda provee búsqueda completa de texto (full text) en todos los documentos (búsqueda global) o en los documentos del archivo actual de ayuda (búsqueda local).

PlainHtmlHttp: con este tipo de ayuda, los documentos se almacenan en el formato estándar HTML. Los documentos se presentan utilizando un servidor Web y se visualizan con un navegador estándar. Este tipo de ayuda puede ser usada en todos los tipos de plataformas de los front ends.

PlainHtmlFile: este es el tipo más simple de ayuda y también almacena los documentos en el formato estándar HTML. Los documentos se presentan en un servidor de archivos y son visualizados con un servidor Web. Esta variante de ayuda puede ser utilizada en todos los tipos de plataformas de los front ends.

DynamicHelp: pude ser usada en todas las plataformas de front ends. Utiliza el formato estándar de archivos HTML; el acceso a los archivos se realiza mediante un servidor de Knowledge Warehouse. Los documentos se visualizan utilizando un navegador.

SAP Knowledge Warehouse (Almacén de Conocimiento), SAP KW, es una de

las Soluciones de SAP provistas mediante SAP Netweaver que puede utilizarse para almacenar y presentar toda la documentación y material de entrenamiento, documentos de ayuda y manuales.

El criterio para seleccionar el tipo de ayuda a instalar depende entonces principalmente del sistema operativo que utilicen los front ends. De todas formas, veremos que pueden configurarse más de un tipo de ayuda en el sistema.

3| Configuración de la Ayuda

Para realizar la configuración de la ayuda en nuestro sistema utilizaremos la transacción SR13 donde definiremos la variante o variantes de la documentación online que estarán disponibles para los usuarios del sistema SAP.

Figura 443 – Transacción SR13

Creando múltiples configuraciones de la ayuda online podemos hacer que esté disponible de diferentes maneras. Una configuración de ayuda especifica un tipo de ayuda, lugar de almacenamiento de los archivos (o ruta) y el lenguaje de la ayuda.

Siempre es necesario indicar una documentación online por defecto en la configuración para cada plataforma de front end que hayamos configurado. Si múltiples tipos de ayuda son instalados, el usuario luego podrá optar entre las variantes desde el menú Help  Settings, en la solapa Application Help.

 

4| Personalizar la configuración de ayuda a nivel de Front End

En algunas ocasiones es necesario realizar configuraciones especiales para la documentación online en ciertos front ends. La documentación online puede ser

controlada en aquellos front end que utilicen Windows utilizando el archivo sapdoccd.ini.

Figura 444 – Ubicaciones posibles del sapdoccd.ini

Los posibles lugares para almacenar el archivo sapdoccd.ini se muestran en la figura.

Una razón para usar esta opción sería en los casos en que una conexión lenta WAN entre el front end y el servidor donde se almacenan los archivos de la documentación online definido en la transacción SR13. Por lo tanto, para evitar un incremento en la carga de la red, la documentación online se configura para que esté disponible de manera local en la red de área local (LAN) del front end.

Esta documentación online local puede accederse utilizando la información en el archivo sapdoccd.ini que se encuentra en el front end.

Si este archivo existe con una configuración válida, esta reemplazará a la configuración en el sistema (transacción SR13) para el tipo de front end.

Las posibles entradas en el archivo sapdoccd.ini se muestran en la siguiente figura:

 Figura 445 - Archivo sapdoccd.ini

Las entradas en el archivo sapdoccd.ini son evaluadas solamente si existe alguna configuración a la documentación online en el sistema mediante la transacción SR13. De otra manera, el sistema muestra el mensaje: No documentation available.

LECCION 5. TAREAS RELACIONADAS A LA BASE DE DATOS

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.

1| 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 451 - 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 liberada por el sistema de base de datos para ser reutilizado y registrar nuevos cambios a la base de datos en el log file.

LECCION 6.  BACKUP Y RECUPERACION DE LA BASE DE DATOS

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.

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.

1| 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 461 – 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.

2| 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 462 – 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 463 – 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.

3| 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 464 – 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.

4| Planificación y Monitoreo de Backups

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

Figura 465 – Transacción DB13

Figura 466 – 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 467 – 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 468 – Transacción DB12 1/2

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

 

Figura 469 – 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.

LECCION 7. MONITOREO DE LA 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.

1| 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 471 – 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 472 – Determinando el Mejor Camino de Acceso

 

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

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

Hay varias transacciones de base de datos disponibles  en el sistema, así también como el monitor CCMS (el monitor CCMS será estudiado en otra unidad del curso).

La Figura 473, 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 473, 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 473 – 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 474 – Análisis de Base de Datos (DB02)

 

4| 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 475 – Transacción DBACOCKPIT

UNIDAD V

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

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

Esta unidad trata exclusivamente sobre usuarios SAP, los cuales la gente utiliza para loguearse a un cliente de un sistema SAP.

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.

 

2| Autorizaciones

Figura 512 – 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 513 – Registro Maestro de Usuario.

3| 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 514 – Tipos de Usuarios

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

LECCION 2. CONCEPTO DE AUTORIZACION

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.

 

1| 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 521 – 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 521, 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 522 – 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.

2| Mantenimiento de Roles: Menú y Autorizaciones

Figura 523 – 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 524 – 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 525 – 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 525_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)

3| 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 526 – 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 527 – Comparación de Registro Maestro de Usuario

Una comparación de registros maestros de usuarios determina si los perfiles de autorización deben ser agregado 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.

LECCION 3. ASIGNACION DE ROLES Y PERFILES

LECCION 4. PARAMETROS DE LOGON Y USUARIOS ESTANDAR

En esta lección veremos una serie de parámetros importantes para la administración de usuarios, por ejemplo, el comportamiento de logon.

 1| Parámetros del Sistema para Logon de Usuarios

 

Figura 541 – 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 caracter.

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 542 – Parámetros del Sistema para Logon de Usuarios 2/2

 

Figura 543 – 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.

2|  Usuarios estándar

Figura 544 – 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 (veremos más sobre la copia de clientes en una unidad posterior en el curso).

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

 

LECCION 5. ADMINISTRACION AVANZADA DE USUARIOS

En esta lección, haremos una introducción de la Administración Central de Usuarios y la conexión a los servicios de directorio.

1| Administración Central de Usuarios

 

Figura 551 – 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 552 - ¿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.

2| Servicios de Directorio

 

Figura 553 – Conexión a Servicios de Directorio

Los servicios de directorio permiten a varias aplicaciones en un landscape IT acceder a información compartida en un lugar central. La información se almacena en un servidor de directorio central que varios sistemas del landscape IT pueden acceder. De esta manera, el servidor de directorio actúa como una libreta de direcciones IT para información que comúnmente es usada por los diferentes sistemas, tal como datos personales, datos de usuario e información sobre recursos y servicios de sistemas.

Podemos utilizar los servicios de directorio para mantener la información en los sistemas SAP para las aplicaciones compatibles con directorios, tal como la administración de usuarios (SU01). 

El estándar LDAP (Lightweight Directory Access Protocol) se utiliza normalmente como protocolo de acceso. Los servicios de directorio proveen un punto central de información y administración y por lo tanto una forma simple de compartirla entre varias aplicaciones.

Los sistemas SAP pueden intercambiar datos con los servicios de directorio usando el protocolo LDAP. Se especifica la dirección de sincronización para cada campo, lo que significa, si el sistema SAP sobrescribe la información en el directorio o el directorio sobrescribe la información en el sistema SAP.

El sistema SAP puede intercambiar información con el servicio directorio de diferentes marcas. SAP provee extensiones de esquemas para los servicios de directorio que soporta, con esto logra que los directorios puedan entender atributos que son propios de los sistemas SAP.

Una conexión a un servicio de directorio puede extender  el concepto de CUA. Esto no significa que estos dos conceptos deben ser implementados conjuntamente,  pero funcionan muy bien juntos.

 

UNIDAD VI

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

1| 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 611 – 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 612 – 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.

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

LECCION 2. CONFIGURACION DE CONEXIONES RFC

TRANSACCION SM59

LECCION 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 como  se relacionan estos en SAP.

1| 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 que manera un sistema SAP funciona.

Figura 631 – 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.

2| 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 que vimos previamente en una unidad.

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

4| Repositorio de Objetos

 

Figura 632 – 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

5| 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 633 – 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.

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

1| Ó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 641 – Estructura de Órdenes de Transporte

2| 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 642 - 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 un 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).

 3| Transporte

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 643 – 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 644 – 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 ordenes 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.

4| 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 645 – 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 646 – 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 estós métodos en diálogo o en background.

Figura 646 – 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.

LECCION 5. ORDENES DE CUSTOMIZING

1| Ó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 objeto 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 651 – 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 652 – 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 653 – Vista de una Orden de Customizing en el Organizador de Transporte

LECCION 6. ORDENES DE WORKBENCH

1| Ó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 661 – 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 662 – 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 663 - Visualización de una órden 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.

LECCION 7. VERIFICACION DE TRANSPORTE

Accessing and Editing ABAP Repository Objects

The ABAP Workbench is the SAP system's integrated graphical development environment. It supports, among other things, the development, testing, and administration of applications written in ABAP. This lesson introduces various ABAP Workbench tools and the connections between them.Let's briefly introduce the ABAP programming language first. You will see how you can navigate into the source code shipped by SAP. You will also write your own short ABAP program.

Following that, the meaning of the ABAP Dictionary is explained. Here, a table is used to talk about the domain concept.

The Language ABAP

ABAP (Advanced Business Application Programming) is a programming language developed by SAP. The majority of the business applications of an SAP system are written in ABAP. An ABAP program consists of individual statements. Every statement begins with a keyword and ends with a period. The example program contains two statements, one on each line. The keywords are REPORT and WRITE. The program displays a list. In this case, the list contains the line .My first ABAP report!.

REPORT first report.WRITE 'My first ABAP report!'.

The above graphic shows an excerpt from an ABAP program. You can use special commands or keywords in ABAP programs to create selection screens (keyword PARAMETERS), to print lists (keyword WRITE), or to access table content (for example, using the keyword SELECT). The ABAP statement CALL SCREEN calls a screen (consisting of a screen image and its flow logic) defined in the Screen Painter.ABAP generally uses Open SQL commands to access the database. Open SQL consists of a set of ABAP statements that execute operations on the central database of the SAP system. These operations return the same results or error messages, regardless of the type of database used. This means that the programs developed are independent of the type of database used.

Some characteristics of the ABAP programming language are:. Multilingual capability (text elements such as list headers, input field texts, and so on, are stored separately). Simple, effective development of graphical user interfaces (using the Screen Painter). Object-oriented programming (.ABAP Objects.). Platform independence (using Open SQL and the database interface). Efficient access to data structures (tables, data elements, and so on)

ABAP StandardsThe economic core functions of an SAP ERP system (for example, ECC 6.0) are programmed in the ABAP language. The client-server architecture of the SAP system (which is often three-level) is reflected in the structure of traditional ABAP applications. The standards provided by SAP for development will be described in the following sections.

ABAP Standards and Enhancements for SAP Applications

Conventional application programs are programmed in ABAP. ABAP dynpros(screens) are displayed in the conventional SAP GUI; they are only displayed in theSAP GUI for HTML after conversion into HTML.In the era of browser-based Internet access, you can also access ABAP applicationsusing a web browser and operate applications or even administrate systems in thisway. Of course, the ABAP applications do not need to be reprogrammed for this, theoutput is presented using web dynpros which can be programmed for the ABAPand Java runtime environments.Free-style Business Server Pages (BSP) can be programmed in ABAP forcustomer-specific, web-based applications. These are usually dynamic webapplications and not static pages. The dynamic behavior is attained by means of theprocessing of the ABAP coding or runtime Java script. Business Server Pages cancontain both process and presentation logic.The standard applications can be enhanced and supplemented with custom webservices. As part of the Enterprise Service Orientated Architecture (ESOA) from SAPSystems, Enterprise and Web Services are being supplied as standard with increasingfrequency.SQL is supported for accessing a database, for example, for table queries from anABAP application. Open SQL should be used in the ABAP as this ensures that yourapplication is database-independent. The Native SQL, SQL*NET and Open DatabaseConnect (ODBC) technologies are also supported, enabling you to access databasesoutside of your SAP system.

The ABAP Workbench and its ToolsYou use the ABAP Workbench to write application programs. The Workbench is a graphical programming environment. The Workbench enables you to call programming tools, using pushbuttons, for example, or the context menu (right mouse click) or forward navigation (double-click on an object name). An ABAP application is, for example a transaction or a report.

You can find the ABAP Workbench tools in SAP Easy Access under Tools → ABAPWorkbench → Development. From there, you can access a range of tools, including. ABAP Editor (transactions SE38 or SE80) to write ABAP programs. ABAP Dictionary (transaction SE11) to define and describe tables, data elements, lock objects and so on. Screen Painter (transaction SE51, in the User Interface subdirectory) to create interactive user interfaces. Function Builder (transaction SE37), to create and manage function modules (these are encapsulated sections of ABAP code with a defined input/output Interface

The individual Workbench tools combine to form an integrated system. If, forexample, you are working with program objects in the ABAP Editor, then the Editorwill also recognize objects created using other tools. By selecting an object andsubsequently double-clicking, the tool is started from the workbench in which theobject was created. Following that, you can edit this object.

When working in the Workbench, you will come across development objects and packages:. Development objects are objects that you can edit using the ABAP Workbench, such as reports, transactions or screens. A package contains logically related development objects, for example, all objects for a specific application

Hint: In releases before SAP Web AS 6.10, packages were still called development classes, which is why, in SAP statements, the data element and the domain DEVCLASS still exist (for a definition of data elements and domains, see below).

SAP provides the Object Navigator (transaction SE80) to help you organize your development processes in your integrated environment ABAP Workbench. Menu path Tools → ABAP Workbench → Overview → Object Navigator). This enables simple, uniform access to Repository objects. Instead of working with tools and packages, you can work with objects in the Object Navigator, and the Workbench will call the right tool for each object.

Accessing ABAP Source CodeSAP delivers the source code for all ABAP programs. You can view the code and use it, for example, as a template for your own programs.In any application, you can choose System → Status, and double-click to navigate to the relevant ABAP Workbench tool. The Workbench displays the selected object in the appropriate tool (given that you have authorization to do this).

Creating ABAP Reports Using the ABAP Editor

You can use the ABAP Editor (transaction SE38 or link in the Object Navigator,transaction SE80) to create and edit programs. ABAP programs are not stored in theSAP system as external files, but as entries in database tables.When you want to create a new program, you need to enter both a program title andattributes for the program. These attributes include program type (such as .Executableprogram.), status (for example, .Test program.), and application component. Whensaving your program, you also need to assign it to a package.Once you have completed these activities, you can write your program text in theABAP Editor.The Editor provides a range of functions, including a syntax check and an optionfor ABAP keyword capitalization. You can also display syntax help for an ABAPkeyword by positioning the cursor on the keyword and pressing F1. SAP recommendsthat you only develop ABAP programs using the ABAP Editor.From the Editor, you can navigate to other tools in the development environment suchas the ABAP Dictionary, the Screen Painter or the Menu Painter, by double-clickingon Repository objects in the coding.If you create or change a program (or a development object in general) and then saveit, an inactive version is always saved first in the Repository. This makes it possible tocontinue developing without changing the active system.

To make a Repository object available throughout the system, you then need to.activate. it. This creates an active version of the program that is then used if, forexample, a user wants to execute your program.You can execute your program in the ABAP Editor using Direct processing (F8).

Hint: You can find an extensive collection of example programs for testing intransaction ABAPDOCU.

Creating Business Server Pages using the Object Navigator

The Internet Communication Manager enables SAP systems to communicate outsidethe SAP environment using the HTTP, HTTPS and SMTP protocols. The ICM canprocess requests from the Internet that include its server/port combination in theirURLs. If database data is required for processing the request, then a connection to awork process is created using memory pipes.

As of SAP Web AS 6.10, work processes are able to directly create Web-enabledcontent that the ICM then transmits to the browser front end that sent the originalrequest. You can develop this content, called Business Server Page applications, inthe SAP system using a tool in transaction SE80, theWeb Application Builder.Business Server Pages (BSPs) enable you to map complex Internet business processesin the SAP NetWeaver AS. You can use the SAP system to create some of the graphicelements required for a corporate website (such as HTML pages, or Web themes) andto manage (and store) those and other elements (such as the MIME objects used).You can use both ABAP and JavaScript as scripting languages. The business logicis created in ABAP Objects. ABAP Objects is an object-oriented extension of theABAP programming language. It enables you to use the principles of object-orientedprogramming in ABAP by using concepts such as encapsulation, inheritance, classes,and interfaces.

Hint: You should not confuse Business Server Pages with Java Server Pages(JSP), which are executed in the Java runtime environment of the SAPNetWeaver AS.Often, SAP customers already have tools for creating attractive corporate websites. Toenable you to continue using these tools, SAP systems support the WebDAV standard(DAV = Distributed Authoring and Versioning). In other words, you can design pagesin the SAP NetWeaver AS, although you need not, if you prefer to use other tools.

Business Server Page programming is very much a modern technique. It shouldbe used in projects in which the flow logic and the display in the web browser arelinked to each other. Put briefly: Business Server Pages are used for specific customerprojects which require free-style programming.Web Dynpro is an ideal solution if your major priority is a browser-based interfacefor traditional ERP applications. Web Dynpros can be created for ABAP as of SAPNetWeaver AS 7.00 and for Java runtime environments as of SAP Web AS 6.40.

What Is the ABAP Dictionary?The ABAP Dictionary is a central component of the ABAP Workbench. It containsboth business and technical definitions and descriptions of SAP data. Many toolsof the ABAP Workbench (such as the ABAP and Screen Processor, Screen Painter)constantly access the information of the ABAP Dictionary.The ABAP Dictionary enables all data definitions used in the SAP system to bedescribed and managed centrally. It is an integrated and active dictionary, that is, theABAP Dictionary is completely integrated in the SAP development environment. TheDictionary information is created only once, but is available throughout the systemat all times. The ABAP Dictionary (transaction SE11) automatically provides all theinformation that has been created or modified, thus ensuring that runtime objects areup-to-date, and that data is consistent and secure.The tasks of the ABAP Dictionary can be subdivided into:. Database object definitions (tables, views, and so on). Type definitions (structures, table types, and so on)

. Services definitions (F1 help, F4 help, lock objects, and so on)

Tables, views, lock objects, and domains are important object types in the ABAPDictionary:. The definition of tables in the ABAP Dictionary is database-independent. Thistable definition then serves as the basis for the creation of a table with the samestructure in the underlying database.. Views are logical views of one or more tables. View structures are defined inthe ABAP Dictionary. This structure is then the basis for the creation of a viewon the database.. Lock objects coordinate attempts by several users to access the same dataset.Function modules are generated from the lock object definition in the ABAPDictionary; you can then use these function modules in application programs.. You can use domains to group fields that have similar technical or businesspurposes. A domain defines the value range for all table fields and structurecomponents that refer to that domain.The documentation (F1 help) and the input help (also called F4 help) for a field on aninput screen are also provided by the ABAP Dictionary.

The integration of the ABAP Dictionary into the program flow is based on theinterpretative method of the SAP Web AS runtime environment. Instead of workingwith the original of an ABAP program, the ABAP processor interprets a runtime object generated from the program text prior to its first execution. Runtime objects areautomatically generated again before execution if a time stamp comparison revealsthat they are no longer consistent with the current status of the ABAP Dictionary.The ABAP Dictionary also allows you to manage, in the SAP system, databasetables relevant to the SAP system. You do not need detailed, product-specificdatabase knowledge for application development. The ABAP Dictionary convertsthe definitions at database level.The interaction between the ABAP Dictionary on one side and the developmentenvironment or runtime environment on the other is outlined in the graphic.Significance of the ABAP Dictionary..

Hint: Every database system also contains contains a so called dictionary.This is not the dictionary referred to in this lesson.

Appendix: Table Definition and the Two-Level Domain Concept

You can define tables database-independently in the ABAP Dictionary. When youactivate the table, a physical table definition is created in the database on the basis ofthe table definition stored in the ABAP Dictionary. The table definition in the ABAPDictionary is converted into a definition for the database used.

A table is a two-dimensional matrix consisting of columns (fields) and rows (entries).It has a name and attributes, such as the table type. Every table in the ABAP Dictionaryhas a primary key. This is a combination of columns that uniquely identifies everyrow in the table. Primary key values can therefore not exist twice in a table.A field (that is, a column in a table) has a name and attributes, for example, it may bea primary key field. A field is not an independent object; it depends on the table andcan only be maintained within that table. You can use domains and data elements todefine table fields:. The domain is used to technically define the table field. Field length and type,output attributes and possible values restriction using fixed values, for example,are defined in the domain.. Dataelements are used to describe the semantic attributes of a field in thecontext of the table. These attributes are only significant within the table, butnot generally (as technical attributes are). In the data element, you can, forexample, define a short description of the table field that is displayed on thescreen when you call the F1 help. You can also specify in the data element thetext that is displayed on input fields that refer to the data element (field label,for example, .Destination Airport.).

The two-level domain concept (consisting of the data element level and the domainlevel) allows technical field attributes to be defined and maintained at the domainlevel. A domain can pass its field attributes on to any number of fields, and youonly need to explicitly change the domain itself, but not the individual fields, whenmodifying the field attributes thus described. Basing fields on the same domainensures that field values can be compared safely and without conversion.Tables, data elements and domains are managed centrally in the ABAP Dictionary.Hint: If you want to check where in the SAP system a particular datadefinition (data element, domain, table, or similar) is used, then you can lookin the Where-used list in transaction SE11 for that data definition.

The graphic uses table SPFLI from the flight data model as an example. Flights (forexample, Lufthansa flight XY from Frankfurt to Tokyo) are maintained centrally inthis table. The table contains fields for the departure airport (AIRPFROM) and thedestination airport (AIRPTO). Because departure and destination airports are differentthings in a business context, two data elements, S_FROMAIRP and S_TOAIRP, havebeen defined. However, because both columns contain the names of airports, bothdata elements refer to the same domain, S_AIRPID, that has the technical type CHAR,with the length 3.

UNIDAD 7

MANTENIMIENTO DEL SISTEMA

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

1| 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 711 – 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.

  2| Transacción SNOTE

 

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

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.

Siguiendo la Figura 712, 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.

 3| 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 713 -  Estado de Sistema

 Figura 714 – Información de Componentes de Software

4| 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 715 – 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

LECCION 2. Importación de Support Packages

Importacion de SP

Cliente 000 usuario DDIC

Ingresar a la tx SPAM

Confirmar advertencia sobre el certificado de mantenimiento de sistemas SAP - renovarse cada 3 meses

1.Actualizar la herramienta SPAM

Todos los paquetes de actualización pueden Subirse al servidor de aplicación de dos maneras

- Directamente desde el front end buscar el paquete descargado desde el marketplace

- subir al servidor de aplicacion si no es muy pesado

Ver el contenido del paquete y la ubicacion del servidor donde sera descomprimido

Iniciar la actualizacion de la herramienta SPAM

- La herramienta puede actualizarse de manera acumulativa, se pueden saltar versiones

- Ante un error de actualizacion de la spam o de SP la importacion luego continua desde el punto donde se detuvo, nuevamente se llama la tx spam para continuar con la actualizacion de la importación para finalizar

Cuando finaliza la actualizacion mostrara el siguiente mensaje

Proceso de importacion de SP

Descargalo desde el Marketplace

Copia del programa sapcar.exe (descomprimir los paquetes) desde el kernel del sistema hasta el directorio de transporte

Abrir una ventana de comandos y ubicarnos en el directorio donde esta la herramienta sapcar

Ingresar el comando sapcar -xvf y la ruta completa en donde se encuentran los SP, se ejecuta para cada uno, seran descomprimidos dentro de la carpeta usr/sap/trans/EPS/in

Ingresar tx SPAM

Notificar a la transaccion q hay un nuevo paquete en el directorio urs/sap/trans/EPS/in

Ver los SP y si cumplen los requisitos

Para verificar la versión, se escoge New Support Packages y se da clic en Display

Parte II

Configurar la SPAM para realizar un Test de importacion para poder detectar problemas que ocurrirían durante la importación de los SP

Para defirnir la cola de importacion se da clic en el botón Display/define de los SP que serán importados

Selecionar los componente de software

Calcular la cola de importación

En el mensaje se escoge la opcion NO

Con la cola de importación definida, se puede dar inicio a la importacion

Cuando finaliza informa con un mensaje

Cambiar la configuracion para la importación

Importacion de los SP

Configuracion de etapas

Monitorear el job - Usuario no trabajen en el sistema

Verificar el log de importacion

Ultimo paso confirmacion de importacion de la cola de SP

LECCION 3. CONFIGURACION DE IMPRESORAS

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

 1| 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 731 – 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.

2| Impresión Local

 

Figura 732 – 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.

 

3| 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 733 – 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 734 – 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.

4| 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 735 – 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 711 - 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.

5| 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 736 – 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.

LECCION 4. ADMINISTRACION DE SPOOL SERVERS

1| 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 741 – 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 742 – 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.

2| 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 743 – 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.

3| 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 744 – 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.

4| 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 745 – Tranportando 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.

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

1| 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 751 – ¿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 752 – ¿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 753 – ¿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 754 – 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.

2| 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 755 – 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 756 – 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 del 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 757 -  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.

LECCION 6. ADMINISTRACION DE JOBS

1| Planificación Basada en Tiempo

Figura 761 – 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 indicada, 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.

2| 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 762). 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 762 – 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.

3| 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 763 – 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.

4| 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 764 – 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.

5| 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 765 – 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

LECCION 7. Otros Temas de Procesamiento en Background

1| 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 771 – 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.

2| 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 grupos de logon para usuarios de diálogo. También es posible procesar tareas de background en instancias seleccionadas.

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

3| 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 773). 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 773 – 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.

4| 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 774 – 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 775 – 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.

5| 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 776 – 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.

LECCION 8. Monitoreo de Sistema

La infraestructura de Monitoreo de Alertas - Permite realizar un monitoreo eficiente de los sistemas SAP

3 Partes

Recoleccion 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 informacion obtenida en la memoria principal de la Instancia.

Almacenamiento de Datos --> el area de la memoria q almacena toda la informacion 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 visualizacion

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 arbol de Monitor (MTE)

Cada nodo del arbol es un MTE lo cuales nos permiten organizar a los objetos de monitoreo dentro de categorias para facilitar la busqueda y visualizacion de los objetos

Luego en las hojas del arbol 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 metodo de analisis

Las alertas se propagan si es severa por los niveles superiores del arbol, rojo es mas sevreo 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 funcion de mantenimiento

Luego de asignar los objetos, se da guardar para asignar un nombre

Luego de finalizar se desactiva la funcion de mantenimiento

Se pueden revisar que alarmas estan abiertas

En el arbol se puede visualizar las alarmas q estan pendientes por analisis

Haciendo doble clic sobre el atributo se veran las alarmas pendientes

Luego de q esta determinada la causa y efectuar la correccion se marca como alarma completa para que vuelva el indicar al estado normal.