✒️SAP BASIS / La importación de support packages Por Arnaldo Salazar

IMPORTACION DE SUPPORT PACKAGES

Para importar support packages debemos trabajar en el cliente o mandante 000.

Trabajar con el usuario DDIC o una copia de este.

Idioma ingles.

Ingresar a la TX SPAM.

Actualizar la herramienta SPAM antes de importar los support packages.

Todos los paquetes de actualización se pueden subir al servidor de aplicación de dos maneras, desde el frond end y desde el application server.

Primer escenario desde el frond end:

· Buscamos el paquete de actualización de la herramienta SAPM descargado desde el market place.

· Luego parecerá el contenido del paquete y la ubicación donde será descomprimida en el servidor de aplicaciones.

· Actualizamos la herramienta spam en la opción del menú support packages, import spam/saint update.

· Muestra un mensaje de recomendación de lectura sobre problemas conocidos sobre la importación de support packages.

· Esta herramienta SPAM en particular puede actualizarme de manera acumulativa, es decir no es necesario paquetes anteriores para ejecutar la ultima.

· Es común que muestre un mensaje de error ya que estamos actualizando la misma herramienta donde nos encontramos, luego del error ingresamos de nuevo a la TX SPAM.

· Volvemos a entrar en la opción del menú support packages, import spam/saint update.

· Al finalizar la actualización el sistema pide reiniciar o reingresar a la TX SPAM.

· Listo ya despues de actualizar la TX SPAM estamos en la capacidad de proceder con la actualización de los support packages.

· Buscamos los paquetes de support packages descargados previamente desde el market place.

· Copiar el programa o ejecutable sapcar.exe desde el kernel del sistema hasta el directorio de transporte de nuestro sistema SAP. (SAPCAR sirve para descomprimir los support packages)

· Ejecutamos SAPCAR.exe abriremos una pantalla de comandos, esto nos dejara ubicados en el directorio donde ejecutamos el SAPCAR.exe.

· Luego colocamos el comando “SAPCAR –xvf espacio y la ruta completa donde se encuentran los support packages. Se repite para cada uno de los support packages.

· Una vez sean descomprimidos ingresamos de nuevo a la TX SPAM pero esta vez tomaremos la SEGUNDA OPCION del menú support packages / load packages / from application Server. Con esto le decimos a la TX SPAM que exiten nuevos paquetes de actualización en el directorio eps/in dentro del directorio de transportes.

· El sistema detectara y notificara que paquetes a encontrado dentro del directorio.

· Volvemos a la pantalla inicial de la TX SPAM en el grupo directory marcamos la opción new support packages y tomamos el botón display, allí veremos los paquetes que ha sido cargados y si cumplen con los prerrequisitos necesarios para la importación. Allí evaluara si el paquete de software es válido y si cumple el prerrequisito del nivel de support packages que requiere.

· Es necesario correr la actualización en forma de test para corregir los errores que puedan ocurrir de forma preventiva y no de forma corectiva.

· Para tan fin tomamos en el menú principal la opción Extras / settings y en el grupo escenario marcamos TEST.

· Luego de aceptar definiremos la cola de support packages que serán importados, tomaremos en la pantalla principal de la TX SPAM la opción display/define, en la siguiente ventana tomaremos la opción todos los componentes.

· En la siguiente ventana en la columna target packages veremos la versión del support packages mas alto de cada subcompoente de software que la herramienta SPAM detecto al cargar los support packages.

· Luego con el botón calcúlate queue la TX SPAM calculara automáticamente la cola de importación, en el siguiente mensaje tomamos la opción NO.

· Antes de iniciar podemos verificar en el botón del camioncito que la cola de importación se realizara en el escenario seleccionado, en esta ocasión en el modo test.

· Después de esta verificación confirmamos y el sistema da inicio a la importación, muestra un mensaje donde nos notifica tal cosa.

· Si no muestra errores cambiamos la configuración de test a standard y tomamos la opción import mode: downtime – minimized, de esta manera con el downtime el tiempo que los usuarios no podrán trabajar con el sistema seria menor.

· Luego iniciamos la importación en el icono del camioncito, configura si se hara de forma de dialogo o en background en la opción star options, tomar la opción start in background para que ocurra en fondo. Asegurar que los usuarios no continúen trabajando, luego dar inicio a la importación.

· Cuando la importancia llega al punto donde debe detenerse antes de dar inicio a la fase de import 2 el estatus de la SPAM indica la condición user stop (icono amarillo).

· Vamos de nuevo al camiocinto para continuar con el import 2 volvemos a tomar la opción star options y start in background sin embargo en la pestaña clean up tomamos la opción continue en background inmediately aceptamos y la importación continua por todas la etapas, import 2 y continuara con la etapa clean de objetos opsoletos.

· Luego nos queda confirmar la cola de importación, icono del lapiz.

· Siempre estar seguro que no existan usuarios en el sistema al momento de hacer la importación.

· En caso de existir errores podremos obtener informacion del mismo en los logs de la SPAM.

IMPORTANTE

PLAN DE TRABAJO PARA LA IMPLEMENTACION DE LOS SUPPORT PACKAGES.

1 - Si, la aplicación de los support package es siempre en el mandante o cliente 000, independiente de los mandantes que se hayan crado luego, la aplicación no te va a dejar aplicar nada si no estas ejecutando la transacción desde el 000,

2 - El plan de trabajo, primero y principal, seguramente cuentas con un landscape para tu sistema en donde tienes un ambiente de desarrollo DEV, otro de testing QAS, y el productivo PRD, por lo tanto los pasos siempre van a ser:

a) Antes de aplicar cualquier Support package o corrección de cualquier tipo es indispensable que se realice un backup del sistema para resguardar todo...

b) Los jobs no hace falta y de hecho no se deberían cancelar, si todo está bien configurada deberían correr con un numero acotado de usuarios, con lo cual se puede bloquear a esos usuarios de modo que no corran por falta de autorización pero nunca borrarlos o modificarlos...

Muchas veces no se puede bloquear a los usuarios, de modo que el sistema simplemente en algún momento cuando el support package comience con los cambios en la base va a realizar bloqueos, y en ese punto a los usuarios les va a generar dumps con lo cual se podrían dejar...

Conclusión, con los usuarios podrías no tocar nada! lo que si, buscar el momento propicio para PRD, por ejemplo un fin de semana o feriado de modo que nadie se encuentre trabajando.

c) Por último debes crear un plan para aplicarlos, es decir primero vas a instalar los SP, en DEV, y una vez finalizados vas a esperar al menos un día para verificar que no haya dumps en el sistema desde la transacción st22 ni otros problemas nuevos en la SM21.

Luego lo debes instalar en el ambiente de pruebas, o sea QAS o como se llame, y allí le pediras a los funcionales de la empresa que hagan pruebas referentes a las tareas diarias, de modo que se chequee que no haya cambiado nada o dejado de funcionar a causa de la aplicación del SP, y una vez finalizadas las pruebas en QAS recien allí se deben aplicar en PRD.

3 - En el caso de la base de datos, siempre es aconsejable un buen backup offline, pero de nuevo, muchas veces no es posible por el tipo de negocio para lo cual habría que hacer un online logs al instante antes de aplicar el SP... no mezclar los posteriores...