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.
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
Iniciar el sistema completo o instancias individuales
Análisis de problemas evaluando logs de inicio
Detener el sistema completo o instancias individuales
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
Logs de inicio de sistema
Todos los servicios de SAP graban en el Event Viewer del servidor
Windows.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
Proceso de actualización de parámetros de instancia
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
Global Technology Services
© 2009 IBM Corporation
Proceso de actualización de parámetros de instancia
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.
Global Technology Services
© 2009 IBM Corporation
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).
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
Crear usuarios
Configurar parámetros de sistema para logon de usuarios
Localizar problemas de autorización
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
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)
Global Technology Services
© 2009 IBM Corporation
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).
Global Technology Services
© 2009 IBM Corporation
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.
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
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
Global Technology Services
© 2009 IBM Corporation
Global Technology Services
© 2009 IBM Corporation
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