ADM100 - Administracion Basis.ppt

Presentación de PowerPointADM100
Breve historia de SAP
SAP fue fundada en 1972 en la ciudad de Manheim, Alemania por antiguos empleados de IBM (Claus Wellenreuther, Hans-Werner Hector, Klaus Tschira, Dietmar Hopp y Hasso Plattner) bajo el nombre de "SAP Systemanalyse, Anwendungen und Programmentwicklung". El nombre fue tomado de la división en la que trabajaban en IBM.
Es la 5ta mas grande compañía de software a nivel mundial, el mayor fabricante europeo y el 3er proveedor de software en el mundo detrás de Microsoft y Oracle.
Actualmente opera en todo el mundo, con 28 sucursales afiliadas y 6 compañías asociadas, manteniendo oficinas en 40 países, 12 millones de usuarios y 100 mil instalaciones.
SAP trabaja en el sector de software de planificación de recursos empresariales (o ERP por las siglas en inglés de Enterprise Resource Planning). El principal producto de la compañía es el software SAP ERP, llamado hasta mediados de 2007 como SAP R/3, en el que la R significa procesamiento en tiempo real y el número 3 se refiere a las tres capas de la arquitectura de proceso: bases de datos, servidor de aplicaciones y cliente. El predecesor de R/3 fue R/2.
SAP también ofrece una nueva plataforma tecnológica denominada SAP NetWeaver. Esta plataforma tecnológica convierte a SAP en un programa Web-enabled, lo que significa que estaría totalmente preparado para trabajar con él mediante la web. Se puede trabajar con SAP mediante cualquier navegador de internet si se tienen los componentes apropiados de SAP NetWeaver (SAP Portals).
Aunque sus principales aplicaciones están destinadas a grandes empresas, SAP también se dirige a la pequeña y mediana empresa con productos como SAP Business One y mySAP All-in-one.
Global Technology Services
© 2009 IBM Corporation
SAP R/3 Enterprise Release 4.70 Release Date March- Dec 2003
SAP ECC 5.0 ERP Release Year 2005
SAP ECC 6.0 ERP Release Year 2006
Breve resumen histórico
1977 Primeros clientes internacionales.
1979 Se lanzan las soluciones SAP R/2.
1988 La empresa sale a bolsa (Francfort).
1992 Se lanzan las soluciones SAP R/3.
1996 La versión 3.1 de SAP R/3 se adapta a Internet.
1996 La empresa lanza las nuevas soluciones de gestión de relaciones con los clientes y de gestión de la cadena de suministro; SAP comienza a desarrollar soluciones específicas para cada sector.
1998 La empresa cotiza en la Bolsa de Nueva York.
1999 SAP presenta mySAP.com.
2000 SAP crea SAPHosting, una filial dedicada a la prestación de servicios de aplicaciones de Internet y a actividades de hosting de aplicaciones.
2000 SAP forma una alianza estratégica con Commerce One para crear SAPMarkets, una filial dedicada a la creación e impulso de marketplaces de business-to-business interconectados globalmente a través de Internet.
2001 SAP adquiere Top Tier y forma SAP Portals.
Definir la estructura y arquitectura de un sistema SAP
Listar los componentes técnicos de un SAP NW Application Server
Usar los términos SISTEMA e INSTANCIA adecuadamente
Un sistema SAP siempre consiste de:
Un sistema SAP consiste de una base de datos con un SID (SAP System ID) de 3 caracteres y una o mas instancias.
Central Instance es la instancia que junto con la base de datos forma un sistema SAP
Siempre existe un Central Instance configurado en cada Sistema SAP
Central System es el sistema SAP que incluye una única instancia con su base de datos en un solo host o servidor.
Es posible instalar 2 instancias de un sistema o de sistemas diferentes en un mismo servidor. Se debe verificar si el HW soportará la carga de ambos sistemas.
Dentro de una compañía no debe asignarse un mismo SID mas de una vez. Debe de ser único.
Una instancia de un sistema SAP es una unidad administrativa en la cual los componentes de un sistema SAP se combinan para suministrar uno o mas servicios.
ABAP Message Server (MS) maneja la comunicación entre los dispatchers distribuidos dentro del AS ABAP. Se configura un solo MS por sistema SAP.
ABAP Dispatcher distribuye las solicitudes de los usuarios en los diferentes workprocesses existentes.
ABAP Gateway reader (GW) permite la comunicación entre sistemas SAP o entre sistemas SAP y aplicaciones externas. Hay un GW por dispatcher.
ABAP Internet Communication Manager (ICM) permite la comunicación con SAP usando protocolos web como el HTTP. El ICM recibe las solicitudes del cliente y se las pasa al sistema SAP para procesarlas. En un sistema ABAP + Java sabe reconocer que tipo de solicitud le llega para derivarlo al dispatcher correspondiente. Se puede configurar máximo 1 ICM por application server.
MPI (Memory Pipes) son estructuras basadas en memoria que son usadas para la comunicación entre el ICM y los workprocess ABAP o los Java Server Processes
Java Dispatcher distribuye las solicitudes del usuario a los server processes.
Java Server Process ejecutan las aplicaciones Java. Cada Server Process es multithread y procesa muchas peticiones en paralelo a diferencia de los workprocess en ABAP. Cada Java Dispatcher tiene por lo menos 1 Server Process y puede tener como máximo 16 Server Process
Java Central Services incluye el Java Message Service y el Java Enqueue Service. Java Message Service maneja la lista de java dispatchers y server processes. Es responsable de la comunicación con el JRE. Java Enqueue Service maneja los bloqueos lógicos hecho por los server process.
Java Software Deployment Manager (SDM) es una herramienta standard usada para instalar los componentes de software Java en el SAP WEB AS Java.
SAP Java Connector (JCo ) sirve para comunicar los diferentes componentes de un sistema ABAP + Java
Una instancia ABAP se configura con un perfil de instancia, tiene areas de memoria compartida y su propia estructura de directorios en el filesystem.
Si tengo varias instancias ABAP en un mismo host, cada una tendrá un # diferente de instancia. La default es 00 y el puerto es 3200.
Si tengo varias instancias ABAP, una de ellas se distingue de las otras y se le denomina Central Instance y tiene el ABAP Message Server (MS) y se ejecuta antes del dispatcher del central instance. Ademas el Central Instance es el único que tiene uno o mas procesos de Enqueue. Desde el punto de vista del modelo cliente-servidor, a una instancia se le denomina tambien application server
Al igual que una instancia ABAP, una instancia Java tiene un solo Java Dispatcher y requiere mínimo 1 server process. So configuro varias instancias Java en un mismo host, c/u tendrá su propio # de instancia.
Una instancia Java se distingue de las demás y se denomina Java central Instance, tiene un proceso SDM (Software Deployment Manager) que se configura 1 solo en todo el sistema y
Instancia AS ABAP
ABAP Message Server (MS) maneja la comunicación entre los dispatchers distribuidos dentro del AS ABAP. Se configura un solo MS por sistema SAP.
ABAP Dispatcher distribuye las solicitudes de los usuarios en los diferentes workprocesses existentes.
ABAP Gateway reader (GW) permite la comunicación entre sistemas SAP o entre sistemas SAP y aplicaciones externas. Hay un GW por dispatcher.
ABAP Internet Communication Manager (ICM) permite la comunicación con SAP usando protocolos web como el HTTP. El ICM recibe las solicitudes del cliente y se las pasa al sistema SAP para procesarlas. En un sistema ABAP + Java sabe reconocer que tipo de solicitud le llega para derivarlo al dispatcher correspondiente. Se puede configurar máximo 1 ICM por application server.
El corazón de una instancia ABAP es el dispatcher. Este proceso inicia otros procesos que pertenecen a esa instancia como el gateway, el ICM y los workprocesses.
Una instancia ABAP se configura con un perfil de instancia, tiene areas de memoria compartida y su propia estructura de directorios en el filesystem.
Si tengo varias instancias ABAP en un mismo host, cada una tendrá un # diferente de instancia. La default es 00 y el puerto es 3200.
Si tengo varias instancias ABAP, una de ellas se distingue de las otras y se le denomina Central Instance y tiene el ABAP Message Server (MS) y se ejecuta antes del dispatcher del central instance. Ademas el Central Instance es el único que tiene uno o mas procesos de Enqueue. Desde el punto de vista del modelo cliente-servidor, a una instancia se le denomina tambien application server
Al igual que una instancia ABAP, una instancia Java tiene un solo Java Dispatcher y requiere mínimo 1 server process. So configuro varias instancias Java en un mismo host, c/u tendrá su propio # de instancia.
Una instancia Java se distingue de las demás y se denomina Java central Instance, tiene un proceso SDM (Software Deployment Manager) que se configura 1 solo en todo el sistema y
Instancia AS Java
Java Dispatcher es el proceso central de una instancia Java y se encarga de distribuir las solicitudes del usuario a los server processes.
Java Server Process ejecutan las aplicaciones Java. Cada Server Process es multithread y procesa muchas peticiones en paralelo a diferencia de los workprocess en ABAP. Cada Java Dispatcher tiene por lo menos 1 Server Process y puede tener como máximo 16 Server Process
Al igual que una instancia ABAP, una instancia Java tiene un solo Java Dispatcher y requiere mínimo 1 server process. Si configuro varias instancias Java en un mismo host, c/u tendrá su propio # de instancia.
Una instancia Java se distingue de las demás y se denomina Java Central Instance que incluye un proceso adicional, el SDM (Software Deployment Manager) que se configura 1 solo en todo el sistema y es una herramienta standard usada para instalar los componentes de software Java en el SAP WEB AS Java..
Adicionalmente tenemos un Java Central Service que incluye el Java Message Service y el Java Enqueue Service. Java Message Service maneja la lista de java dispatchers y server processes. Es responsable de la comunicación con el JRE. Java Enqueue Service maneja los bloqueos lógicos hecho por los server process.
Se pueden instalar otras instancias Java en el mismo host que la Java Central Instance o en otros hosts separados.
Instancia AS ABAP + AS Java
Una instancia ABAP + Java siempre tiene un ABAP + Java Central Instance
Otras instancias pueden ser solo AS ABAP o AS ABAP + Java
Una instancia ABAP siempre consiste de:
Una instancia de un sistema SAP es una unidad administrativa que combina componentes de un sistema SAP para brindar uno o mas servicios.
Los servicios ofrecidos por una instancia pueden ser iniciados o parados de manera conjunta.
El dispatcher dsitribuye las solicitudes en los work process. Hay varios tipos de workprocess :
WP Dialogo : procesa todos los dialogs steps lanzados por un usuario activo. Cada dispatcher requiere al menos 2 workprocess de dialogo
WP Spool : procesa el flujo de datos secuencial hacia las impresoras. Al menos 1 WP de Spool se requiere en un sistema SAP. Cada dispatcher puede tener mas de 1 WP de Spool.
WP Update : procesa las solicitudes de actualización a la BD. Se necesita al menos 1 WP de Update por sistema SAP y se puede configurar mas de 1 por dispatcher.
WP Background : ejecuta los programas sin intervención del usuario. Se necesita al menos 2 WP de Background por sistema y se puede configurar mas de 1 por dispatcher.
WP Enqueue : administra la tabla de bloqueos en la memoria compartida (Shared Memory). Contiene los bloqueos lógicos a nivel de ABAP y se requiere 1 solo por sistema SAP.
Proceso de Logon a una solución SAP
Paso 1 – Para crear una conexión, el SAPGui requiere información en la forma de parámetros de inicio y es enviada al MS para que verifique cual instancia nos va a atender
Paso 2 – Luego de determinar quien nos atiende, se retorna la pantalla de logon al SAPGui por mas información
Paso 3 – SAPGui envía la información de logon a la instancia seleccionada por el MS
Paso 4 – El dispatcher determina que workprocess esta libre para atendernos y le envia la data de logon a este workprocess
Paso 5 – El workprocess seleccionado verifica la información de logon proporcionada por el usuario en los pasos 5, 6, 7 y 8
Paso 9 – Una respuesta positiva devuelve la pantalla de inicio al sistema SAP de lo contrario emitirá el mensaje de error correspondiente
Durante el proceso de logon la asignación de la instancia que va a atender al usuario es única. Solo un nuevo logon permitirá asignar una instancia diferente por parte del MS.
Multiplexación de procesos de diálogo
Workprocess Multiplexing significa que un proceso con múltiples pasos puede ser procesado por varios workprocess de dialogo. Estos pasos son descritos como Transacciones.
Una transacción consiste de múltiples pantallas que pueden ser procesadas por múltiples workprocess de dialogo.
La multiplexación es usada exclusivamente para work process de dialogo. Los demas tipos de workprocess ejecutan procesos de negocio completos.
Acceso directo al programa RSUSR200
Al momento de ejecutar el SAP Logon, se lee el archivo saplogon.ini para mostrar la lista de los sistemas SAP a los que podemos acceder
SAPLogon es un programa que permite a los usuarios logearse a un sistema SAP.
La última versión es la 7.10 con parche 11.
Start SAP Logon Read SAPLogon.ini
Logon pushbutton Start Logon
Variable Logon pushbutton No change to SAPLogon.ini, evaluate sapmsg.ini and services
New Item pushbutton Edit SAPLogon.ini, evaluate sapmsg.ini and services
Change item pushbutton Edit SAPLogon.ini
Delete item pushbutton Edit SAPLogon.ini
SAPLogon Pad (saplgpad.exe)
En “Servidor de aplicación” se digita la IP del sistema SAP
En “Número de sistema“ se digitan los 2 últimos dígitos de los 4 que conforman el Port Address. Los 2 primeros siempre son 32 y los 2 últimos tienen un rango desde 00 hasta 99
Esto significa que tenemos port numbers entre 3200 y 3299. El 3298 esta reservado para el niping y el 3299 para el saprouter.
En “ID sistema” se digita el SID de 3 caracteres.
Si no queremos que los usuarios modifiquen estos datos podemos cambiar el programa SAPLogon (saplogon.exe) por el SAPLogon Pad (saplgpad.exe)
Sin grupos de logon:
Los sistemas SAP normalmente pueden tener mas de una instancia asignada. Cada instancia proporciona áreas de memoria para almacenar programas, objetos de diccionario, estructuras de pantalla y contenido de tablas.
Estos buffers se llenan continuamente a medida que se usa el sistema y usa varios algoritmos para organizar el contenido de manera que lo que se usa mas frecuentemente siempre se encuentre disponible de manera inmediata.
Muchas veces esto no es posible y se genera un intercambio entre el contenido mas antiguo y el mas reciente provocando pérdida en el tiempo de respuesta porque al consultar data antigua el sistema SAP ira nuevamente a buscar la información al sistema operativo o a la base de datos.
Con grupos de logon:
Permite además el balanceo de cargas entre servidores de un mismo grupo de logon
Para evitar este inconveniente se crean grupos de logon en la transacción SMLG para agrupar instancias SAP y aprovechar mejor los recursos de estos equipos.
En el ejemplo se han agrupado 4 instancias para SD y 3 para FI. Estos grupos hay que definirlos en el programa SAPLogon y cuando el usuario trata de acceder a uno de estos grupos el Message Server recibe la petición y devuelve la instancia SAP mas disponible del grupo de logon escogido. SAPLogon inicia el programa SAP GUI con los parámetros de conexión para el dispatcher seleccionado.
La ventaja es que los buffers de memoria son usados de manera mas eficiente evitando el swapping a disco y mejorando el tiempo de respuesta.
SAP recomienda configurar un único logon group excluyendo al Central Instance para que todas las instancias (application servers) tengan tiempos de respuesta comparables o un balanceo de carga equivalente.
Herramientas de administración
SM04 / AL08 resúmen de los usuarios logeados en el sistema. SM04 muestra los usuarios logeados en la instancia y AL08 muestra los usuarios logeados en todo el sistema.
SM51 muestra todas las instancias del Sistema SAP. Desde esta transacción es posible ir directamente a la SM04 o la SM50 de una instancia seleccionada.
SM37 muestra el resúmen de los jobs de fondo ejecutados en el sistema.
SM50 muestra un resúmen de los workprocess configurados en una instancia y la SM66 muestra todos los workprocess de un sistema SAP.
SM12 permite manejar las entradas de la tabla de bloqueos del workprocess de Enqueue. SM13 permite manejar los registros que estan siendo actualizados en el sistema.
SM21 analiza el log del sistema. SM02 permite enviar mensajes a todos los usuarios de un sistema SAP. El mensaje sera visualizado cuando el usuario ejecuta una nueva acción en el sistema.
RZ20 permite monitorear un sistema SAP o centralizar el monitoreo de múltiples sistemas SAP.
Iniciar el sistema completo o instancias individuales
Análisis de problemas evaluando logs de inicio
Detener el sistema completo o instancias individuales
Proceso de inicio de sistema SAP
El inicio de un sistema SAP es un pre-requisito básico para poder trabajar con el sistema y es ejecutado en una serie de pasos por el usuario de istema operativo <sid>adm.
P1 – Levantar la base de datos es lo primero que se debe hacer en un sistema SAP. Sin este paso no se pueden levantar las otras instancias SAP.
P2 – Levantar la instancia central de servicios (CS Instance de un sistema AS Java o AS ABAP+Java) que contiene el enqueue y el message service de la parte Java del sistema SAP
P3 – Levantar la Instancia Central. En este paso se levanta el operating system collector SAPOSCOL que se ejecuta como proceso de fondo del sistema operativo. Luego se inicia el message server, el dispatcher y los workprocess. Si los parámetros de incio estan configurados correctamente se inicia el Internet Communicaction Manager (ICM) y los server process de AS Java (si estan instalados)
P4 – Levantar las instancias de diálogo. Si las instancias de diálogo no estan ejecutandose en el mismo host del central instance entonces se inicia primero el SAPOSCOL, luego el dispatcher y por último los workprocesses.
Inicio de procesos de un sistema SAP
El proceso sapstartsrv es iniciado en cada instancia SAP y no se detiene aún si la instancia SAP se detiene. Cuando inicia, lee el start profile de la instancia y abre su interfase de servicio web en el puerto 5$$13 (5$$14 si es SSL) donde $$ es el número de instancia. Esta interfase de servicio administra y monitorea una instancia SAP, en particular el SAP Management Console.
Logs de inicio de sistema
Todos los servicios de SAP graban en el Event Viewer del servidor Windows.
Logs de inicio de una instancia
El proceso de inicio de un sistema SAP es grabado en archivos de log tanto por el sistema operativo, por el sistema SAP y por la base de datos.
Si el sistema SAP no se inicia, se puede encontrar información de los errores en los diferentes logs del sistema que se almacenan en el DIR_HOME de la instancia SAP.
STDERR1 Inicio de base de datos STDERR2 Inicio del Message Server STDERR3 Inicio del dispatcher
Con el parámetro rdisp/TRACE se puede setear el nivel de trace : 0 Errores, 1 Errores y Warnings, 2 Errores y trace corto, 3 Errores y trace completo
Analisis de problemas:
Revisar los errores y advertencias del sistema operativo con las herramientas correspondientes de cada sistema operativo
Verificar el estado del sistema de base de datos usando los logs correspondientes.
Verificar el log de inicio en el SAP MC. Escoger la instancia y seleccionar List Developer Traces
Verificar los STDERR<n>
Verificar los archivos de trace : dev_ms, dev_rd, dev_disp, dev_w<m>
Si se puede logear al sistema SAP, revisar el log de la SM21
Antes de detener el sistema SAP verificar el estado de :
Usuarios logeados en el sistema (SM04 / AL08)
Procesos de fondo (SM37) y batch inputs (SM35)
Resumen de Actualizaciones a la BD (SM13)
Conexiones externas
Enviar un mensaje de sistema a todos los usuarios (SM02)
Puede ser necesario bajar el sistema por diversas razones : reinicio por cambio de parámetros, despues de un cambio de kernel, despues de upgrades de hardware, etc.
Un ejempolo de conexiones externas es el APO/SCM con el Livecache. Primero debemos bajar el Livecache y posteriormente el APO/SCM para no tener errores posteriores.
Deteniendo un sistema SAP
Detener el sistema SAP es ejecutado a la inversa del proceso de inicio.
Las instancias se pueden detener por la RZ03 (CCMS Control Panel) mediante Control -> Stop SAP Instance o en el MMC (Microsoft Management Console)
Argumentos de startsap :
R3 para iniciar solo la instancia y sus workprocess asociados
ALL para iniciar la base de datos y la instancia (el default si no se pone ningún argumento)
Deteniendo un sistema SAP (Unix/Linux)
Para detener el sistema primero se bajan las instancias (Application Servers) y luego la instancia central (Central Instance)
Argumentos de stopsap :
R3 para detener solo la instancia y sus workprocess asociados
ALL para detener la base de datos y la instancia (el default si no se pone ningún argumento)
Iniciando un sistema SAP (OS/400)
Las cuentas <SID>OFR y <SID>OPR necesitan el grupo <SID>OPRGRP
Al logearnos ejecutamos el comando STARTSAP y luego F4. Digitamos el <SID> como por ejemplo DEV, QAS o PRD y luego la instancia que puede ser 00 o *ALL si hay mas de una en el host.
Con el comando WRKACTJOB SBS(R3_<nn>) podemos verificar si levanto el sistema SAP, R3_<nn> lo cambiamos por la instancia, si es 00 entonces será R3_00. Si es AS ABAP+Java y tenemos 2 instancias (por ejemplo 00 y 01) entonces podemos ejecutar el comando de la siguiente manera => WRKACTJOB SBS(R3_00 R3_01) para ver el sistema como un solo conjunto.
Deteniendo un sistema SAP (OS/400)
Para bajar el sistema o la instancia nos podemos logear como <SID>OFR o <SID>OPR
Digitamos STOPSAP y luego F4, Digitamos el <SID> del sistema que queremos detener y la instancia que puede ser específica (00, 01, etc) o *ALL para bajar todas las instancias.
En R/3 Instance Name podemos digitar *LOCAL para detener una o mas instancias en el local host o *ALL para bajar todas las instancias en todos los hosts.
Determinar la configuración de parámetros del sistema
Ajustar los parámetros del sistema mediante el uso de perfiles
Configurar el cambio dinámico de tipos de work processes mediante el uso de modos de operación
Configuración de parámetros del sistema
La configuración de las instancias individuales y del sistema SAP es ejecutado usando parámetros de sistema (system parameters).
Los valores por omisión (default) para estos parámetros estan definidos en el core del kernel. Se puede cambiar estos valores por default modificando los archivos de perfil que serán leidos cuando se inicie la instancia.
Estos archivos de perfil son creados durante la instalación del sistema y pueden ser editados posteriormente.
Como estos archivos son solo de lectura cuando el sistema se inicia entonces se debe reiniciar la instancia o el sistema completo si es que modificamos los parámetros individuales.
El cambio dinámico (Dynamic Switching) es posible con el sistema iniciado pero solo para un número limitado de parámetros.
Archivos de perfil a nivel de sistema operativo
Los archivos de perfil son creados automáticamente durante la instalación y almacenados a nivel de sistema operativo en el directorio /usr/sap/<SID>/SYS/profile (Link) o /sapmnt/<SID>/profile
El sistema SAP tiene 3 archivos de perfil :
Start Profile
Default Profile
Instance Profile
En principio, estos archivos se pueden modificar con editores del SO pero es mucho mejor hacerlo por la transacción RZ10.
Por ejemplo :
<SID> = PRD
<INSTANCE> = DVEBMGS para una instancia central o D para una instancia de diálogo
<INSTANCE NUMBER> = 00, 01, 02, 03, ...
<HOST_NAME> = sapdbs (instancia central) , sapapp1, sapapp2, sapapp3 (instancias de diálogo)
Start Profile : especifica los procesos que van a ser iniciados en cada instancia (message server, dispatcher, saposcol, etc)
Default Profile : solo existe uno por sistema SAP y es leido por todas las instancias. Contiene parámetros generales como el nombre del sistema, nombre de la base de datos, nombre del servidor de enqueue, logon client
Instance Profile : define parámetros aplicables a una instancia en particular como el # de workprocess, tamaño de buffers de memoria, etc.
Transacción RZ10 (para modificar), RZ11, reporte / transacción RSPFPAR o SE38 / RSPARAM (para visualizar)
En la RZ11 le ingresamos el nombre de un parámetro y nos muestra el valor por default, mínimos, máximos y el valor que esta definido. Incluso muestra si el parámetro es Dynamically Switchable.
En la RSPFPAR vemos todos o un grupo de parámetros con su valor por default definido en el nucleo del kernel y el valor definido por el usuario si es que el parámetro se modificó en la RZ10.
En la tabla TPFYPROPTY tenemos el campo DYNAMIC que nos indica rapidamente si un parámetro es Dynamically Switchable.
A nivel de Sistema Operativo puedo usar el programa “sappfpar <parámetro>” para ver uno en particular, si uso “all” salen todos los parámetros.
Para verificar los parámetros uso “sappfpar check pf=<perfil de instancia> nr=<instance number> name=<SID>”. “sappfpar help” nos da información sobre como usar el comando.
Ejemplo : sappfpar check pf=PRD_DVEBMGS00_sapdbs
Proceso de actualización de parámetros de instancia
Se puede modificar los perfiles con editores del sistema operativo pero corremos muchos riesgos de cometer errores.
Ventajas de administrar los perfiles en el sistema SAP :
Administración centralizada y mantenimientos de las instancias
Los cambios en los perfiles son verificados para consistencia
Administración de múltiples versiones de un determinado perfil
Comparación del perfil activo con el perfil almacenado en la base de datos
Activación inmediata de los parámetros seleccionados
PRECAUCION : Realice copias de seguridad de los perfiles antes de modificarlos (se hace a nivel de sistema operativo)
Despues de terminada la instalación, los perfiles solo se encuentran presentes a nivel de sistema operativo.
Paso 1 : Importamos los perfiles desde el sistema operativo. Durante este paso se ejecuta una verificación de consistencia
Paso 2 : Procedemos a ejecutar cambios a los perfiles porque tienen valores por omisión como por ejemplo el # de workprocess, el mandante, los buffers de memoria
Paso 3 : Los cambios son almacenados en la base de datos
Paso 4 : Al activar los cambios se guarda una copia de los perfiles a nivel de sistema operativo para que ambas copias sean congruentes.
Los cambios se activan cuando son leidos por el sistema y para ello es necesario reiniciar la instancia SAP.
Tenemos 2 tipos de mantenimiento de parámetros : Básico y Extendido.
En el Básico solo se modifican los parámetros mas importantes y ayuda al usuario con una serie de descipciones lógicas.
En el Extendido necesitamos conocer los nombres técnicos de los parámetros y podemos añadir nuevos parámetros al perfil.
Los cambios se efectuan en 2 pasos : Copy y Save. En el Copy solo son cambios temporales, en el Save se hacen permanentes y se graban en la base de datos. Al activar el perfil se almacenan a nivel de sistema operativo.
Los cambios a una instancia en particular solo toman efecto al reiniciar la instancia, los cambios en el default profile solo toman efecto cuando se reinicia todo el sistema SAP.
Verificación de consistencia de los perfiles
La verificación de consistencia y la comparación de perfiles son funciones adicionales de la transacción RZ10.
En la verificación de consistencia, el sistema verifica la sintaxis y la semantica de los perfiles sea indivualmente o en su conjunto (todos)
Durante la comparación de perfiles, el sistema compara el perfil que esta activo con el perfil que esta almacenado en la base de datos. El perfil activo se leyó del sistema operativo durante el proceso de inicio de la instancia.
Esta comparación se hace tambien durante el inicio de la instancia y si exiusten diferencias entonces el sistema muestra un mensaje en el Alert Monitor (RZ20).
Concepto de modos de operación
La demanda de usuarios en un sistema SAP varia durante el curso del dia. Durante el dia, un gran número de usuarios de dialogo trabajan con el sistema y requieren de una gran performance y para ellos necesitan de un grna número de procesos de diálogo. Sin embargo, durante la noche solo un pequeño número de estos workprocess de dialogo son utilizados y el sistema puede utilizarlos para procesar jobs de fondo (job background process)
El tipo y número de workprocess en cada instancia es definido en los perfiles y se optimizan para lograr tiempos de respuesta rápidos. Usualmente se define un gran número de workprocess de dialogo y pocos workprocess de background. Esto significa que durante la noche, los recursos del sistema como la memoria se desperdician y no son totalmente utlilizados por los procesos de background.
Es por ello que existen los Modos de Operación para definir diferentes tipos y número de workprocess de acuerdo a la demanda del sistema.
Ajuste de procesos de acuerdo a la demanda
Con los modos de operación se puede modificar el tipo y número de workprocess para variar la distribución de la carga durante el dia.
Tambien se puede ajustar la distribución de los workprocess para que se ajuste a los requerimientos del negocio y que ocurran una sola vez.
El cambio entre estos tipos de workprocess es ejecutado dinámicamente por el sistema SAP. El cambio se efectua usando una programación previamente definida.
Los workprocess reservados no son inmediatamente terminados pero si marcados para que se ejecute el cambio cuando terminen lo que estan ejecutando. Esto significa que existira un delay en el momento del cambio.
Durante el cambio de un modo de operación, ni la instancia ni el workprocess afectado necesitan ser reiniciados. Esto significa que la calidad del buffer del sistema SAP es retenido durante el cambio y que se esperará la finalización de la solicitud que actualmente esta siendo procesada por el workprocess. Este comportamiento se puede observar en la SM50.
Pasos para configurar los modos de operación
Paso 1 : En la RZ04 creamos los modos de operación (van a estar vacios)
Paso 2 : Todas las instancias activas son detectadas y los workprocess definidos en el perfil de instancia son asignados a los modos de operación como valores por default
Paso 3 : Podemos empezar a hacer ajustes en la cantidad de procesos de dialogo y background dependiende de la distribución de carga del sistema.
Paso 4 : Definimos el período de tiempo en el que se va a realizar el cambio de modos de operación. Esto se ejecuta en la transacción SM63 (Tabla de Tiempos)
Reglas :
Background aumentan o disminuyen el # de workprocess de dialogo
Clase A determina el sub-conjunto de workprocess de background que ejecutarán procesos de clase A
Update si al menos existe 1 workprocess de update disponible, aumenta o disminuye workprocess de dialogo
Update V2 si al menos existe 1 workprocess de update V2 disponible, aumenta o disminuye workprocess de dialogo
Enqueue aumenta si hay al menos 1 de Update V2 disponible, disminuye si al menos existe 1 workprocess de enqueue, para ambos casos aumenta o disminuye workprocess de dialogo
Spool no pueden ser modificados
En la SM63 se distinguen entre modos de operación normal y de excepción.
Modos de Excepción
Si no definimos una tabla de tiempos entonces no se efectuará un cambio de modos de operación. La configuración del perfil de instancia permanecerá activa.
El modo de operación de excepción solo puede ser definido como un evento único.
Se puede lanzar (trigger) un cambio de modo de operación por programa usando la función RZL_PERFORM_BA_SWITCH
Verificación de consistencias modos de operación
Use la transacción RZ03 para monitorear las instancias y los modos de operación. Se puede :
Verificar el estado de todas als instancias y los modos de operación
Iniciar o detener as instancias
Cambiar manualmente el modo de operación
Mostrar un resúmen de los workprocess
Cambiar al Alert Monitor (RZ20)
Si el número de workprocess es modificado, el sistema no podrá cambiar los modos de operación hasta que se reinicie la instancia correspondiente.
Es imperativo modificar los modos de operación despues de un cambio del número de workprocess en los perfiles de instancia.
Accediendo a la ayuda
La ayuda de SAP puede instalarse localmente en el equipo, en un fileserver para que todos la puedan utilizar o acceder directamente de internet desde la ruta http://help.sap.com
La documentación en linea es suministrada en varios idiomas
El SAP Library de un sistema SAP como Netweaver puede ofrecer acceso a mas de 10 mil documentos
4 tipos de help :
HtmlHelpFile Se almacenan en HTML compilado (.CHM) y se pueden almacenar en un fileserver para ser visualizados por el HTML Help Viewer. Ocupa 1/10 del espacio usado por archivos Html regulares. Usado en Win32.
PlainHtmlHttp Se almacenan en HTML standard y disponibles en un Web server para visualizarse en un web browser. Puede ser usado en todas las plataformas front end.
PlainHtmlFile Se almacenan en HTML standard y disponibles en un fileserver para visualizarse en un web browser. Puede ser usado en todas las plataformas front end.
DynamicHelp Se almacenan en HTML standard y disponibles en un servidor de Knowledge Warehouse. Puede ser usado en todas las plataformas front end.
Si todas mis máquinas de usuario son Windows entonces usaré de preferencia HtmlHelpFile por su fortaleza en búsqueda e impresión. Si tengo una plataforma heterogenea entonces se recomienda PlainHtmlHttp desde un web server. Si no tengo web server entonces utilizaré PlainHtmlFile desde un fileserver. Si quiero usar el help desde el SAPGui (windows, Java, Html) entonces no de no usar HtmlHelpFile.
La configuración se realiza en la transacción SR13.
Trabajando con la base de datos
Un Database Management System (DBMS) incluye procesos de base de datos, un buffer en la memoria principal, archivos de datos (data files) que contienen la información y archivos de log donde los cambios a los datos son grabados. Al inicio de un sistema SAP todos los workprocess se asocian con procesos de base de datos.
Las consultas a la base de datos son pasadas de los workprocess de SAP a los procesos de base de datos quienes ejecutan las consultas en la base de datos.
Los datos son almacenados en data files y el acceso se hace únicamente por los buffers en la memoria principal. Procesos especiales de base de datos son los responsables de intercambiar los datos entre el buffer y los data files. Durante este intercambio, los datos siempre son leidos y escritos en páginas completas que normalmente contienen varios registros de datos.
Si efectuamos cambios a los datos, estos son escritos en archivos de log que contienen los cambios de estado de la base de datos. Solo los cambios y no la página completa son grabados en el log. Las entradas son grabadas del log buffer al log file y puede existir mas de un archivos dependiendo de la base de datos.
Existe un mecanismo en todas las bases de datos para respaldar la información del log desde los archivos de log a un medio de backup (disco, cinta, optico, etc). Esto asegura que los archivos de log no crezcan demasiado.
SAP recomienda hacer un mirror (espejo) de los archivos de log. Este mecanismo no debe ser desactivado porque puede perderse los cambios de estado de la base de datos.
Una base de datos siempre incluye datos estructurados que contienen información esencial como el número de data files, número de log files, etc.
Respaldando los datos y el log
El concepto de respaldo de datos siempre incluye un respaldo regular de los archivos de datos, los datos estructurados asi como el log
El proceso de respaldo de datos y de logs puede ejecutarse en diferentes pasos. Se puede programar ambos procesos en el sistemas SAP (excepto en el AS/400) como acciones regulares en un calendario de planificación de eventos de base de datos (transacción DB13)
Escenarios para recuperar una base de datos (con pérdida)
Si ocurre una falla de disco entre el punto t1 y t2, toda la data respaldada en el punto t1 puede ser importada durante un proceso de restauración.
Si no se toma otra acción, todos los cambios efectuados despues del punto t1 son perdidos.
Escenarios para recuperar una base de datos (sin pérdida)
Podemos recuperar los datos con el respaldo efectuado en t1 (algunas BD’s son capaces de importar solo los archivos perdidos). Despues de este paso es necesario restaurar todos los archivos de log hasta el punto de falla, en este caso 21, 22 y 23. Solo es posible recuperar la BD al punto t2 si contamos con un respaldo completo de los log files.
Los archivos de log son eliminados del disco para no tener problemas de falta de espacio en disco. Si una falla ocurre en el punto t5 y la media del respaldo del punto t3 esta defectuosa entonces debemos usar el respaldo del punto t1 y todos los respaldos de los archivos de log desde el 21 al 27 para poder restaurar la base de datos sin pérdida de información.
Por eso es importante ejecutar y mantener de manera regular los respaldos de datos y logs.
Ciclo de respaldo de datos y logs
SAP recomienda un ciclo de respaldo de 28 dias (4 semanas). Esto significa que el medio de respaldo de datos y logs es sobre-escrito cada 28 dias.
SAP recomienda que se ejecuten respaldos completos de datos todos los dias.
Algunas bases de datos permiten implementar esquemas de respaldo diferencial o incremental pero si es usa este método entonces es necesario al menos 1 respaldo completo a la semana.
Por lo menos debe ejecutarse un respaldo completo cada semana y terminar con 4 respaldos durante el ciclo de 28 dias.
Ejecutar un respaldo con verificación del medio de repaldo por lo menos 1 vez en el ciclo de 28 días.
Transacción DB14 – Display DBA Operations Log
Con la transacción DB13 se puede programar y monitorear los procesos de respaldo efectuados de manera regular en el sistema SAP.
Si el backup se realiza sobre un medio manual (cinta intercambiable) entonces asegurese todos los dias de tener el medio de respaldo correcto e insertelo antes de iniciarse el proceso.
En las últimas versiones, la transacción DB13 ha sufrido muchas transformaciones e incluso ahora permite planificar y monitorear otras bases de datos.
Crear usuarios
Configurar parámetros de sistema para logon de usuarios
Localizar problemas de autorización
Usuarios y autorizaciones
Cada usuario en el sistema SAP necesita tener su propia cuenta con las autorizaciones apropiadas para poderse logear. El Administrador Basis es el encargado de crear el User ID para cada usuario.
La combinación de User ID/Contraseña es diferente para el sistema operativo, la base de datos o el sistema SAP. Cada uno tiene su propio esquema de autorización.
NOTA : Las solicitudes del usuario son procesadas en los workprocess de SAP. Todos estos workprocess usan un usuario en comun para acceder a la base de datos.
NOTA : Los User ID y las autorizaciones de datos son dependientes de mandante.
El acceso al sistema operativo y a la base de datos debe de ser protegido para evitar daños al sistema SAP.
En el sistema SAP siempre se realiza una verificación de autorizaciones cada vez que se ejecuta una transacción. Si el usuario no esta autorizado a ejecutarla, obtendrá el mensaje de error correspondiente. Use la SU53 para verificar las autorizaciones faltantes. Use la transacción SU56 para visualizar todas las autorizaciones de un determinado usuario.
User Master Record (SU01)
Al usuario se le asignan autorizaciones mediante el uso de roles y perfiles. Estas autorizaciones se componen de roles y estos roles son ingresados en el registro Maestro de Usuario.
Address Data nombre y apellidos completos, departamento y área, teléfonos, correo eletrónico, compañía
Logon Data alias, fecha de vigencia, tipo de User ID (Dialog, Communication, System, Service, Reference), centro de costo, cuenta contable
Defaults Menu de inicio, lenguaje, impresora por default, notación decimal, formato de fecha, time zone, CATT
Parameters parámetros que se usarán para facilitar el ingreso de datos en las pantallas de las transacciones
Roles lista de autorizaciones que le permiten al usuario acceder a cierta parte del sistema
Profiles lista de perfiles asociados o no a los roles asignados a la cuenta de usuario
Groups grupos definidos para ubicar facilmente a un usuario dentro el sistema SAP
Tipos de cuenta (User types)
Al usuario se le asignan autorizaciones mediante el uso de roles y perfiles. Estas autorizaciones se componen de roles y estos roles son ingresados en el registro Maestro de Usuario.
Hay distintos tipos de usuario :
Dialog Es usado para todos los tipos de logon por solo una persona. Al logon se verifica si la contraseña ha expirado, si se paso de la fecha de vigencia, si puede logearse mas de una vez, etc.
Communication Es usado para comunicación libre de dialogo entre sistemas. No se puede usar para dialogo y para este tipo de cuenta si aplica la fecha de vigencia.
System Es usado para comunicación libre de dialogo o para procesos de fondo dentro de un sistema o por usuarios RFC para ALE, Workflow, TMS, CUA, etc. No se puede usar para dialogo y su contraseña no caduca.
Service Es una cuenta de dialogo usada para grupos de usuarios anonimos. Se debe restringir al máximo sus autorizaciones. El sistema no verifica si la contraseña ha caducado o no ha sido modificada (initial)
Reference Es una cuenta tipo Service pero se usa unicamente como template para asignar autorizaciones adicionales a una cuenta de dialogo.
Concepto de autorización (PFCG)
Entender el concepto de autorizaciones en SAP requiere el conocimiento de los roles y perfiles de autorización del registro maestro de usuario.
En SAP las acciones y el acceso a los datos estan protegidos por objetos de autorización. Estos objetos de autorización se agrupan en clases y permiten verificacione s complejas que involucran multiples condiciones que permiten a un usuario ejecutar una acción.
Las condiciones son especificadas en los campos de autorización de cada objeto de autorización y son sumadas o añadidas durante la verificación.
Una autorización siempre esta asociada exactamente con un objeto de autorización. Una autorización es un permiso para ejecutar una determinada acción en el sistema SAP.
Se puede tener multiples autorizaciones para un objeto de autorización. Algunas autorizaciones son entregadas por SAP pero la mayoría son creadas específicamente para los requerimientos del cliente.
Los objetos de autorización y sus campos de autorización tienen nombres descriptivos y técnicos.
Verificación de una autorización
Cuando un usuario se logea a un cliente (mandante) de un sistema SAP, sus autorizaciones son cargadas a su contexto de usuario. El contexto de usuario esta dentro del buffer del usuario que reside en la memoria principal y se puede consultar a traves de la transacción SU56 del servidor de aplicación.
Cuando el usuario ejecuta una transacción, el sistema verifica si el usuario tiene una autorización dentro de su contexto de usuario que le permita ejecutar la transacción seleccionada. Si esta dentro del contexto de usuario entonces la ejecuta, en caso contrario se obtendra el mensaje de error correspondiente y se podrá utilizar la transacción SU53 para verificar que autorizaciones le falta para poder ejecutar la transacción seleccionada.
Si se agregan o se asignan nuevas autorizaciones al usuario entonces será necesario que salga y vuelva a entrar al sistema para que estas autorizaciones formen parte de su contexto de usuario.
Se puede tener una transacción que consta de muchos pasos. En el primer paso se verificó si puede ejecutar la transacción y muestra la pantalla inicial. En los siguientes pasos es posible que se necesite verificar otras autorizaciones y la informacipon de la pantalla será pasada al dispatcher, que la pasara al workprocess correspondiente y se verificará si tiene el permiso para seguir ejecutando acciones dentro de la transacción. Si el usuario cuenta con todas las transacciones para ese paso, se le mostrará la siguiente pantalla, en caso contrario mostrará el error correspondiente.
Todas las autorizaciones son permisos. No hay autorizaciones para prohibir algo. Cualquier cosa que no este permitida explicitamente es prohibido. Es un concepto de autorización positivo.
Mantenimiento de Roles (PFCG)
El mantenimiento de roles se ejecuta en la transacción PFCG (Profile Generator o activity groups) que simplifica la creación de autorizaciones y el asignamiento a los usuarios.
Las transacciones se agrupan en roles de acuerdo al requerimiento de la compañía. Un rol puede ser asignado a varios usuarios. Un usuario puede tener varios roles. Los cambios a los roles tienen efecto en múltiples usuarios.
Esquema de menú de usuario (PFCG)
En la PFCG se puede construir o ajustar un árbol de menu de acuerdo a las necesidades de los usuarios.
Se pueden agregar o eliminar transacciones, reportes, direcciones internet o link a archivos. Se pueden especificar reportes web de BW, links a sistemas de correo externos y Knowledge Warehouse.
Se pueden crear, mover, eliminar y renombrar directorios y sub-directorios así como usar drag & drop para su mantenimiento.
El mantenimiento de roles crea automáticamente las autorizaciones que son asociadas con las transacciones que fueron especificadas en el árbol de menú.
Sin embargo todos los valores de los campos de autorización deben ser verificados y ajustados manualmente si es requerido. Es responsabilidad del Administrador del Sistema.
Cuando se usen campos a nivel organizacional, NO se deben modificar los valores de los campos de autorización directamente sino por el botón correspondiente a Campos a Nivel organizacional.
Las autorizaciones siempre deben quedar de color verde. Una autorización en amarillo indica que hay campos de autorización sin valor. Una autorización en rojo indica que falta completar un campo a Nivel Organizacional.
Luego de generar un rol se crea un perfil de autorización que se asociará al rol correspondiente. Un rol puede tener uno o mas perfiles de autorización, un perfil de autorización puede existir sin estar asociado a un rol.
Tipos de roles
Rol Simple es un rol individual en el sistema y normalmente esta referido a un proceso dentro de un escenario de Negocios.
Rol Compuesto es una lista de roles y mayormente se utiliza para agrupar procesos de un escenario de negocio para definir un puesto o posición dentro de la organización. Facilita la asignación de roles a los usuarios.
Rol Maestro es una plantilla que sirve para generar Roles Derivados que van a diferenciarse entre sí únicamente por los campos a nivel organizacional. Un rol maestro nunca se asigna y sus campos a nivel organizacional estan en blanco.
login/min_password_lng : Tenemos parámetros adicionales para definir el número de dígitos, letras, mayúsculas, minúsculas y caracteres especiales que una contraseña puede contener.
login/password_expiration_time : especifica el # de dias que pasaran antes de solicitar una nueva contraseña. Si el parámetro es 0 no se necesita cambiar la contraseña. Anteriormente la nueva contraseña tenia que ser diferente de las últimas 5 pero ahora se puede usar el parámetro login/password_history_size para definir el # de contraseñas históricas (default 6, rango entre 1 y 100). Se pueden definir restricciones en la tabla USR40.
login/password_max_idle_initial : indica el tiempo máximo de duración de una contraseña de inicio. Una vez expirada, la contraseña no podra ser usada para autenticación y se requerira de una nueva contraseña de inicio.
login/password_max_idle_productive : indica el tiempo máximo permitido para una contraseña cuando esta no es utilizada. Una vez expirada, se requerira de una nueva contraseña de inicio.
login/min_password_diff : número de caracteres que deben ser diferentes para definir una nueva contraseña. No tendra efecto cuando se crea una nueva cuenta o cuando se define una contraseña de inicio.
Parámetros para logon (continuación..)
login/fails_to_session_end : número de intentos de logon fallidos antes de terminar el SAPGui. Si el usuario desea intentar nuevamente entonces debe de reiniciar el SAPGui.
login/fails_to_user_lock : número de intentos de logon fallidos antes de la cuenta sea bloqueada en el sistema SAP. El contador de intentos fallidos se resetea a cero cuando uno se logea satisfactoriamente.
login/failed_user_auto_unlock : si tiene valor 1 entonces al llegar la medianoche se desbloquean automáticamente las cuentas bloqueadas por logon incorrecto
login/disable_multi_gui_login : si tiene valor 1 entonces no se permite que una cuenta pueda logearse mas de una vez en el mismo cliente (mandante). Si ya estaba logeado en otra estación entonces saldrá una ventana solicitando que continuemos con este logon y terminemos la sesión de la otra estación.
login/multi_login_users : es una lista con las cuentas SAP que si se les va a permitir logearse mas de una vez en el mismo sistema y mandante. (TIP : digitar las cuentas sin espacios, separados por comas y en mayúsculas)
Contraseñas iniciales para usuarios standard
Para prevenir el uso de la cuenta SAP* con contraseña “pass” use el siguiente parámetro :
login/no_automatic_user_sapstar = 1
Esencialmente hay 2 tipos de usuarios standard : los que se crean durante la instalación y los que se crean durante una copia de cliente (mandante)
Durante la instalación de un sistema SAP se crean los clientes (mandantes) 000 y 066 (solo en casos especiales se crea el cliente 001 como por ejemplo una instalación de SAP ECC) y junto con estos clientes se crean usuarios standard con nombres y contraseñas predefinidas. Debemos proteger estas cuentas para prevenir accesos no autorizados.
SAP* es la única cuenta que no necesita estar definida en el registro maestro de usuarios (User Master Record). Esta definido en el kernel con password “pass” y tiene el acceso a todo el sistema SAP. Cuando se instala un sistema SAP se crea la cuenta SAP* en el mandante 000, 001 y 066 con password inicial “06071992” y se le pregunta al administrador si desea habilitar una Master Password con lo que la cuenta SAP* con password “pass” deja de tener vigencia.
DDIC es la cuenta que nos permite modificar el diccionario de datos y el software logistics. Cuando se instala SAP se crea la cuenta en los mandantes 000 y 001 con contraseña “19920706” y durante el proceso se modifica si nosotros habilitamos el Master Password. Es una cuenta importante porque es la única que se utiliza en ciertos pasos de un upgrade a una vueva versión para logearse a SAP.
EARLYWATCH es una cuenta que se crea en el mandante 066 con contraseña “support” y la usan los expertos de SAP para funciones de monitoreo y performance.
Si copiamos un cliente (mandante) entonces habilitamos la cuenta SAP* con contraseña “pass”. Si borramos la cuenta SAP* de un cliente (mandante) entonces tambien estamos activando la cuenta SAP con contraseña “pass”.
Para evitar esta situación se tiene el parámetro “login/no_automatic_user_sapstar = 1” para proteger el sistema SAP de esta situación.
La SUIM nos ayuda a responder ciertas preguntas como :
Liastar los usuarios has sido bloqueados en el sistema por parte del administrador
Listar los usuarios con intentos de logon fallidos
Última fecha de logon al sistema
Cuando se asignaron o desasignaron autorizaciones a una determinada cuenta de usuario
Cuando se crearon o eliminaron las cuentas de usuarios
Que roles contienen una determinada transacción
Trace del sistema para autorizaciones (ST01)
Con la transacción SU53 se puede verificar las autorizaciones fallidas de una cuenta de usuario. El administrador necesita el objeto S_USER_AUT para poder ver los valores de los objetos de autorización fallidos.
Con la transacción ST01 se puede grabar la ejecución de una transacción de su propia sesión o la sesión de otro usuario para analizar y determinar las autorizaciones que necesita para que no falle una transacción.
NOTA : El trace se debe ejecutar en el mismo cliente (mandante) y en la misma instancia (application server) sino no se grabará nada en el log.
El trace del sistema (ST01) esta preparado para encontrar todas las autorizaciones faltantes.
Administración Centralizada de Usuarios (SCUA)
Si se operan múltiples sistemas SAP con muchos clientes y usuarios identicos, entonces se puede reducir significativamente los esfuerzos de administración usando CUA.
CUA centraliza el mantenimiento desde un cliente (mandante) y es descrito como el Central System, los otros sistemas son conocidos como Child Systems.
Con CUA se puede especificar para cada usuario a que clientes (mandantes) va a poderse logear. No significa que todos los usuarios puedan entrar a todos los sistemas y clientes del landscape. Es específico.
Con CUA se puede especificar si los datos de usuario van a ser mantenidos centralizadamente o si algunos datos se van a mantener localmente por los usuarios o por el administrador.
Los datos maestros son intercambiados usando ALE (Application Link Enabling) que es una tecnología hecha para configurar y operar aplicaciones SAP distribuidas. El procesamiento asincrónico de la comunicación asegura que el funcionamiento de la aplicación este libre de errores.
Los sistemas SAP que quieran implementar CUA deben tener al menos SAP Basis 4.5
La siguiente información puede ser intercambiada con CUA :
Registros Maestros de Usuario : direcciones, datos de logon, user defaults, parámetros
Asignar roles y perfiles simples y compuestos para todos los Child Systems. CUA tiene la ventaja de no requerir logearnos a cada sistema y cliente para hacer esta operación.
Transferir la contraseña inicial a los Child Systems.
Estado de bloqueo (Lock Status) que toma efecto en todos los Child Systems
La Interfase RFC
RFC (Remote Function Call) es una llamada a un modulo de función que esta ejecutandose en un sistema diferente al sistema que inicia la llamada. Se puede llamar a un modulo de función en el mismo sistema pero los RFC’s normalmente son usados cuando el sistema que llama y el que recibe la llamada estan en sistemas diferentes.
En SAP se permite el RFC entre sistemas SAP o entre un sistema SAP y una aplicación externa (No-SAP).
RFC es un protocolo de interfase SAP basado en el Common Programming Interfase for Communications (CPI-C)
Los programadores ABAP no necesitan escribir sus propias rutinas de comunicación, simplemente deben usar la interfase RFC para :
Convertir todos los datos y parámetros al formato requerido en el sistema remoto. (CALL FUNCTION statement)
Llamar a las rutinas de comunicación requeridas para comunicarse con el sistema remoto.
Manejar los errores que ocurren durante la comunicación.
Conexiones RFC
Para poder llamar a un modulo de función debemos definir el sistema remoto como un destino en el sistema origen. Se necesita autorización de acceso para el sistema remoto.
La transacción SM59 nos permite manejar estas conexiones remotas y son de diferentes tipos.
Variantes de uso de los RFC’s
sRCF permite al llamado sincrónico de modulos de función. Es decir, el cliente espera hasta que el servidor haya completado su procesamiento.
aRFC permite ejecutar el proceso de manera asincrónica en otro workprocess. Por ejemplo la WF10 para generación masiva de ordenes de compra donde uno controla el proceso y los otros WP’s generan los cálculos.
tRFC es un RFC asincrónico pero asegura que la data sea movida y procesada en el destino una sola vez en caso de errores de red. Para ello usa un TID (Transaction Identifier) para reconocer los paquetes y procesarlos una sola vez en el destino. Debido a que es asincrónico, los parámetros son transferidos del cliente al servidor y no es posible obtener información de retorno o de estado.
qRFC es una extensión del tRFC donde se crea una capa (Layer) entre las aplicaciones y el tRFC permitiendo transferir una unidad lógica de trabajo (LUW) al servidor destino cuando sus predecesors no estan asociados a las colas de espera. Despues que una LUW se procesa, el qRFC manager automáticamente procesa la siguiente LUW tomando en cuenta la secuencia de la cola de espera. Un ejemplo son las colas entre R/3, APO y BW.
Describir la estructura de datos de un sistema SAP
Nombrar las ventajas y necesidad de un esquema multi-sistema
Crear y liberar órdenes de transporte
Describir la arquitectura de un sistema de transporte
Importar órdenes de transporte
Estructura de datos de un sistema SAP
Los sistemas SAP tienen una estructura de datos específica. Los ajustes del negocio (Customizing) son relevantes para algunos clientes (mandates) del sistema SAP, adicionalmente existen otros ajustes que son cross-client además del repositorio que abarcan a todos los clientes del sistema SAP.
El repositorio es el almacen central para todos los objetos de desarrollo que son almacenados en paquetes. Un paquete es un contenedor que puede tener diferentes objetos como programas, tablas, pantallas, modulos de función, clases y son creados y modificados por el Package Builder (transacción SPAK).
La modificación y transporte de los cambios a los objetos es controlada por el Change and Transport System (CTS) usando asignación de paquetes.
Customizing describe los ajustes de negocio que se efectua sobre un sistema SAP. El Customizong es obligatorio durante la primera instalación y durante un upgrade a una nueva versión y se ejecuta en el sistema SAP usando la Guía de Implementación (IMG). Ejemplos de Customizing : definición de plantas y almacenes, cartas de cobranza, planillas, código de país, moneda, lenguaje, time-zone.
Cross-Client Customizing contiene información independiente del cliente (mandante) como el factoy calendar o las definiciones de impresoras.
Un Cliente es una unidad auto-contenida en terminos comercial, organizacional y técnico, tiene sus propios datos maestros y de usuario.
Client-dependent Customizing son por ejemplo los códigos de compañía plantas y almacenes.
Master and transaction data son dependientes del cliente y pueden ser los registro maestros de materiales, ordenes y facturas.
User data es dependiente de mandante y en ella tenemos el registro maestro de usuarios y los roles y perfiles.
La creación de un cliente o mandante se realiza con la transacción SCC4. La copia de mandante con las transacciones SCCL (local), SCC8 (export), SCC9 (remota), SCC1 (O/T), SCC3 (Monitor)
Tenemos Customizing dependiente de mandante e independiente de mandante. Adicionalmente podemos hacer cambios o ampliaciones en el repositorio de diversas maneras :
Customer Development donde creamos objetos propios como tablas, programas, funciones, transacciones que deben pertenecer al espacio de nombres del cliente (customer namespace) y deben empezar con Z o Y.
Enhancement (Mejora) donde el repositorio es complementado con objetos propios. Por ejemplo un programa standard es mejorado por medio de un “User Exit”, una tabla por medio de un “Append”
Modificación a un objeto standard de SAP (tablas, programas, estructuras, funciones, etc) por medio del asistente de modificaciones o del asistente de notas o manualmente.
Ventajas de un esquema (landscape) de 3 sistemas
SAP recomienda un esquema de sistemas múltiples basado en la estructura de datos de un sistema SAP en donde el repositorio de objetos es único. No se debe desarrollar y trabajar productivamente en el mismo sistema SAP.
1-System : Inconsistencias porque se cuenta con un solo repositorio de datos. Un programa mal modificado en DEV afecta tambien a TEST y PROD. Un apagón o una falla de hardware afecta tambien a todos los clientes
2-System : PROD esta estable pero es posible que las pruebas unitarias en DEV afecten a las pruebas integrales en TEST.
3-System : Un sistema para desarrollo, uno para calidad y otro sistema para producción.
Se cuenta con un sistema de desarrollo que tiene su repositorio para crear sus propios objetos y donde se hacen los ajustes requeridos al sistema SAP (Customizing)
Estos cambios son transportados al sistema de calidad y se ejecutan pruebas integrales con data real. Esto no es posible en desarrollo porque hay muchos proyectos en paralelo y no se cuenta con la data para las pruebas.
Despues que el test se ejecuta satisfactoriamente, todos los objetos y ajustes del sistema de calidad son transportados al sistema productivo.
Se pueden tener muchos clientes en un sistema SAP para propositos diferentes. Por ejemplo en desarrollo se puede tener un cliente solo para Customizing y otro para pruebas unitarias.
Los clientes pueden tener # iguales o diferentes. Por ejemplo DEV 100, QAS 200 y PRD 300, en otro caso será DEV = QAS = PRD = 300 y se cumple la regla source client = target client
Estructura de generación de requerimientos
En la transacción SE09 (Transport Organizer) se crean las solicitudes de transporte. Normalmente el nombre de estas O/T empiezan con el <SID> del sistema seguido de “K9” y una combinación de 5 caracteres alfanuméricos.
Una solicitud de transporte debe contener objetos que estan lógicamente conectados y que se pueden transportar juntos. No se debe crear una O/T por cada objeto, haría el transporte complejo y muy confuso.
Se puede delegar a una persona la tarea de crear las solicitudes de transporte así como las tareas para cada uno de los desarrolladores o analistas de proyectos. De esta manera, los desarrollos de cada empleado se almacenaran en la tarea correspondiente. Las tareas siguen la misma nomenclatura de las solicitudes de transporte y si somos lo suficientemente rápidos tendran una numeración secuencial.
El termino “solicitud de transporte” es en general un termino neutral
Una “solicitud de cambio” (change request) es una solicitud de transporte usada para transportar cambios (tambien se incluyen los objetos nuevos)
Una “solicitud de workbench” es una solicitud de transporte que contiene objetos del repositorio y customizing independiente de mandante.
Una “solicitud de customizing” es una solicitud de transporte que contiene objetos dependientes del cliente (mandante), es decir, customizing dependiente de mandante, master data y user data.
Un “transporte de consolidación” es una solicitud de transporte que sera transportada en el sistema de consolidación (principalmente es el sistema de calidad)
Proceso de liberación de solicitudes de workbench
Si un objeto del repositorio es editado e incluido en una solicitud de transporte por un desarrollador, entonces este objeto es reservado para ser procesado exclusivamente en esta solicitud de transporte.
Los cambios a este objeto solo puede ser realizado por desarrolladores que tienen tareas en esta solicitud de transporte. El desarrollo o mantenimiento de estos objetos de desarrollo son bloqeados para todo el resto de desarrolladores hasta que la solicitud de transporte sea liberada. Estos desarrolladores solo podrán visualizar los objetos.
En el caso de datos de Customizing, las tablas son bloqueadas durante el procesamiento del workprocess de enqueue. No hay bloqueo de objetos para Customizing.
El Transport Organizer lleva el control de versiones de los objetos del repositorio, permitiendo comparar y acceder a versiones anteriores. Una versión es generada cuando se libera una solicitud de transporte.
Una solicitud de Customizing contiene objetos de customizing dependientes de mandante, master data y user data.
El Transport Organizer crea una tarea para cada empleado implicado en la solicitud de transporte.
Como se menciono anteriormente, una solicitud de Customizing no genera bloqueo de objetos, solo bloquea la tabla mientras esta siendo modificada.
Proceso de transporte entre sistemas
El proceso de transporte esta dividido en 2 fases : Export e Import. Los objetos son exportados del sistema de desarrollo e importados al sistema de calidad y producción.
Cuando se libera una solicitud de transporte, se esta haciendo un export de los objetos al directorio de transporte centralizado que reside en el sistema operativo.
El import en el sistema destino (calidad o producción) generalmente no es automático y es efectuado por el administrador de transportes en el TMD (Transport Management System) o transacción STMS
Tanto el Export como el Import generan logs que deben ser leidos para determinar el exito o fracaso del proceso de exrpot / import.
En terminos técnicos, los cambios hechos a los objetos y que residen en la base de datos son exportados por medio de archivos al sistema operativo y desde el directorio de transporte son importados a la base de datos del sistema de calidad y producción.
El parámetro de perfil DIR_TRANS contiene la ruta del directorio de transporte (generalmente /usr/sap/trans en Unix)
Import de ordenes
En la transacción STMS se puede transportar una solicitud de transporte de manera individual o todas las solicitudes de transporte. En ambos casos los objetos son importados primero en orden de importancia y luego en el orden que aparecen en la cola de import. Una tabla por ejemplo, tiene mas importancia que un programa porque el programa puede ser dependiente de la tabla.
El orden de la cola de export del sistema de desarrollo es el mismo de la cola de import del sistema de calidad, es decir, esta ordenado de acuerdo al orden en que hemos liberado las solicitudes de transporte. El orden de la cola de import del sistema productivo debe ser igual al orden de transporte del sistema de calidad.
Tecnicamente, el programa ejecutable tp del sistema operativo es usado para el Export y para el Import. El Import siempre usa los archivos de datos que han sido generados y almacenados en el directorio central de transporte durante el export.
Verificación de transportes
Durante el transporte, los pasos ejecutados en las diferentes fases son grabadas en archivos de log.
Se puede usar el Transport Organizer (transacción SE09) para verificar estos logs e identificar el éxito o fracaso por medio de colores, comentarios o codigos de retorno.
Todos los pasos del import son grabados durante el import que es ejecutado en la transacción STMS. Se puede visualizar los logs en la transacción SE09 o en la STMS.
Describir el concepto de notas SAP y Support Packages
Explicar el concepto de Support Package Stack y del Maintenance Optimizer
Explicar el uso de Support Package Manager e importar una actualización de SPAM/SAINT
Importar Support Packages con la transacción SPAM
Entender el concepto de Enhancement Packages
Notas SAP y Support Packages
Un sistema SAP esta compuesto de varios componentes de software. Estos componentes reciben actualizaciones regulares a traves de Notas SAP o Support Packages que son usados para importar ajustes basados en cambios en requerimientos legales, corrección de errores, mejoras de funciones ya existentes o para entregar nuevas funciones al sistema. Un sistema SAP siempre debe tener el mas reciente nivel de parche liberado.
Las Notas SAP contienen información general, consejos y sugerencias o recomendaciones de SAP. Tambien describen un problema y la solución de errores en funciones standard del software de SAP. Este tipo de nota SAP contiene la solución a un problema individual que a menudo es la solución a un error de programación, en la forma de líneas de codigo fuente.
Support Package son paquetes conteniendo objetos de repositorio y Customizing. En principio, cada componente de SW y cada nivel de parche liberado tienen su propio support package.
En el caso de existir componentes de software que se intersectan (mediante la aplicación de un Add-On) existe un support package adicional que resuelve el inconveniente y se denomina CRT (Conflict Resolution Transport)
Tecnicamente, un Support Package es un tipo de solicitud de transporte que no puede ser transportado en la STMS. Un Support Package contiene todas las notas SAP creadas desde el último Support Package liberado.
Los Support Package no so acumulativos pero estan basados en sus predecesores. Los Support Package son importados con el Support Package Manager (transacción SPAM).
Las notas SAP son implementadas en el Notes Assistant (transacción SNOTE)
Asistente de Notas (SNOTE)
El Asistente de Notas es llamado con la transacción SNOTE. Forma parte del sistema SAP desde el Basis release 6.10. En anteriores releases se importaba como un componente de software adicional (Add-on)
La versión actual de la SNOTE permite implementar varios tipos de notas : cambios a programas, creación de nuevos programas, cambios a modulos de función y muchas otras cosas.
Sin embargo no puede modificar objetos del diccionario de datos. El Asistente de Notas solo puede cambiar objetos del repositorio pero no de Customizing.
Pasos para implementar una nota SAP :
1 Ubicar la Nota SAP en el Service Marketplace buscando por palabras clave o seleccionando el número de la nota SAP si la conoce
2 Cargar la Nota SAP en el sistema de desarrollo por medio del Asistente de Notas (transacción SNOTE)
3 La Nota SAP es verificada en el Asistente de Notas y determina si es implementable o no. Para ello verifica el nivel del componente de software, el nivel del support package, si requiere de otras Notas SAP.
4 La Nota SAP es implementada en el sistema y se crea una solicitud de transporte
5 El resultado de implemantar la Nota SAP es probado en el sistema de desarrollo y si es correcto entonces se libera para generar el export correspondiente
6 La solicitud de transporte es importada en el sistema de calidad y se ejecuta una prueba de aceptacipon con data real (cercana a producción)
7Si el test es satisfactorio se importa la solicitud de transporte en el sistema productivo donde puede ser utilizado por todos los usuarios
Suppport Package Stack y Solution manager
En principio, un Support Package de un componente de SW es independiente de otro. Sin embargo existen casos en los que el importar un Support Package puede traer efectos secundarios. Por ejemplo un SP de HR puede requerir de un SP de Basis o un SP de APPL. Tan pronto como son identificados estos efectos secundarios se documentan en una nota SAP compuesta (composite SAP Note)
SAP recomienda usar Support Package Stacks para implementar parches de manera consistente. Un Support Package Stack es una combinación de Support Package de diferentes componentes de software.
Surge el problema de parchar el sistema con un landscape complejo. Surgen preguntas como ¿cuál es el nivel de parche actual de mi sistema?, ¿dónde encuentro información del Support Package Stack que me correspponde?
La respuesta es el Maintenance Optimizer. Con el Maintenance Optimizer puedo solicitar los Support Package Stack requeridos para mi landscape que he definido en el Solution Manager.
NOTA : El Maintenance Optimizer es obligatorio para descargar los Support Package y Support Package Stacks liberados desde Abril del 2007.
El Support Package Manager (transacción SPAM) ofrece las siguientes funciones :
Cargar Support Packages desde el SAP Service Marketplace al Sistema SAP
Importar Support Packages con la posibilidad de reiniciarlo en el punto que se quedo luego de una falla, visualizar el estado del import, minimizando el tiempo de parada, control del tiempo de inicio de las fases, programarlo para procesamiento en fondo o background.
La SPAM puede reconocer las dependencias entre componentes y tomarlos en cuenta pero sin los efectos secundarios. La actualización de la SPAM/SAINT se hace en la transacción SPAM
Procedimiento :
Verificar que el último parche de SPAM/SAINT en el Marketplace sea mayor que el que tenemos instalado, bajarlo del Marketplace, extraer los archivos en el directorio de transporte del sistema de desarrollo (/usr/sap/trans/EPS/in), logearse en el sistema de desarrollo mandante 000 y ejecutar la SPAM, comunicar el parchado a la SPAM (Support Package -> Load Package -> From Application Server) es una simple notificación porque no levanta el parche, importar la actualización SPAM/SAINT (Support Package -> Import SPAM/SAINT Update). En un landsapce multi-sistema se debe hacer en cada sistema (DEV, QAS, PRD)
Debe haber suficiente espacio en el file system de transporte.
El import debe realizarse durante horas de baja carga de usuarios.
La última versión de SPAM/SAINT es requerida.
TMS/CTS debe estar configurado.
NO debe haber support packages abortados en el sistema.
Mandante 000 usado para import; en los demás, solo ay opciones de visualización
Usar un usuario con permisos suficientes para SPAM.
Solamente el administrador de sistema debe tener acceso a descargar e importar support packages (SPAM) o Add-ons (SAINT).
Proceso de actualización durante el import
Es una tarea del Administrador del sistema SAP. Las nuevas versiones de los objetos SAP incluidos en los Support Packages estabilizan y extienden el ambito funcional del sistema SAP.
Un Support Package Stack representa combinaciones de Support Packages recomendados por SAP. Un parche de Kernel a menudo forma parte de un Support Package Stack y debe de importarse antes.
Importar el último parche de la SPAM/SAINT, descargar el Support Package del Marketplace, extraer los archivos en el directorio de transporte (/usr/sap/trans/EPS/in), logearse al sistema en el cliente 000 y ejecutar la SPAM, notificar los Support Package (Support Package -> Load Packages -> From Application Server), ajustar el procedimiento de import, definir la cola a ser importada que puede incluir uno o varios Support Packages, preparar las condiciones para el inicio, importar la cola, ejecutar ajustes en la SPDD/SPAU, verificar los logs y confirmar la cola.
Enhancement Packages
En el pasado, nuevas funciones para un release existente es “escondido” en el Support Package. Esto significa que el Support Package no solo corrige errores sino trae tambien nuevas funciones.
Si embargo la mayor cantidad de nuevas funciones solo pueden ser logradas con un upgrade del sistema a una versión superior. Para llegar al sistema productivo debe de probarse exhaustivamente en desarrollo y calidad y es una tarea que consume mucho dinero, tiempo y recursos.
Para reducir este esfuerzo se implementan los Enhancement Packages desde el 2007 con el SAP ERP 6.0 Enhancement Package 2. Un Enhancement Package es un upgrade de componentes de software individual con la ventaja adicional de que las nuevas funciones pueden ser activadas selectivamente. Las ventajas de un Enhancement Package son las siguientes :
Procesos del nucleo estables
Tecnología estable
Pocos upgrades del sistema
Manejo de impresoras en sistemas SAP
Describir la arquitectura y el flujo de datos para el procesamiento de salida de un sistema SAP
Crear impresoras y servidores de impresión en un sistema SAP
Listar los metodos de acceso a impresoras
Adminstración de requerimientos de spool
Describir el concepto de servidores de impresión lógicos
Configurar servidores de impresión lógicos
Administrar requerimientos de impresión
Flujo de proceso de impresión
En SAP tenemos varios tipos de documentos desde listas simples hasta documentos hechos en SAPScript o en Smart Forms.
A pesar de que la manera de crear estos documentos puede ser muy diferente, la salida en papel impreso siempre es ejecutada en 2 pasos :
Paso 1 : El Spool Request (Solicitud de Impresión) es creado y contiene datos de impresión independientes del dispositivo e incluye información administrativa (autor, fecha, # de copias) y los datos a ser impresos
Paso 2 : Solo cuando Spool Request va a ser impreso en algún dispositivo entonces se crea una Output Request (Solicitud de Salida). Los datos de impresión independientes del dispositivo son convertidos al lenguaje de la impresora para que sean entendidos apropiadamente por el dispositivo de salida seleccionado.
Este proceso permite poder ver el spool request antes de ser impreso. Pueden existir varios output request para 1 solo spool request. Esto evita que el usuario ten

ADM100 - Administracion Basis.ppt

Documents

Transcript of ADM100 - Administracion Basis.ppt