✒️SAP BASIS La importación de support packages
SAP BASIS La importación de support packages
En general, cuando llevas mucho tiempo haciendo algo aparecen vicios y costumbres que no siempre son positivos, incluso se llega al punto de pensar que todo es lo mismo, y es un fallo muy común que se resuelve con un poquito de cariño…
La aplicación de parches en entornos SAP es una tarea que se actualmente se puede llevar a cabo de diferentes maneras, por ejemplo, hablando de la pila ABAP podemos aplicar parches a través de la transacción SPAM, todo un clásico, o podemos usar nuevas herramientas como el SUM (Software Update Manager), más orientado a actualizaciones de pilas ABAP y JAVA, además de EHP’s (Enhancement Packages) y cambios de versión (upgrades).
Cuando de aplicar unos pocos parches se trata, y no de grandes colas de actualización, prefiero usar SPAM, básicamente por su simplicidad, robusted y velocidad.
Trataré a continuación los pasos básicos para actualizar un entorno SAP ERP ABAP con SPAM (Atención, aunque el procedimiento en sí mismo no es demasiado complicado, sobre todo después de haber aplicado miles de parches, si aparecen problemas se requieren conocimientos adicionales, es más, el entorno podría quedar totalmente inoperativo):
- Estudiar la nota OSS correspondiente a las versiones de software que tenemos en el entorno. En las nuevas versiones la propia SPAM nos avisa de la necesidad de leer la nota, indicándonos cuál es su número.
- Actualizar Kernel (puede ser descargado directamente desde el Marketplace, pues no requiere de autorización SOLMAN). Normalmente actualizo todo el Kernel, pues siempre viene bien para corregir errores, incluso en los casos en los que no se han sufrido. Además subo a última versión los binarios que corresponden al disp work, tp, R3trans, libdbsl, pues por lo general hay versiones superiores liberadas que solucionan problemas con respecto al último paquete completo liberado.
- Crear tarea de Mantenimiento (MOPZ) en el Solution Manager 7.x, haciendo uso de Solución y sistema, y permitiendo que el entorno proponga los parches que considera oportunos, ya sea para aplicar un Support Stack completo, ya sea para aplicar unos parches de HR. Autorizar la descarga, en su caso guardar el fichero de stack.xml, que será necesario en muchos casos, y descargar los parches a través de SAP Download Manager.
- Desde la transacción SPAM, en mandante 000, en Inglés y con usuario administrador, procederemos a presentar los parches al entorno, ya sea a través del servidor (mejor), ya sea subiéndolos directamente desde nuestro equipo (muchísimo más lento). Si el sistema no dispone de licencia de mantenimiento será necesario descargarla desde el Marketplace o solicitarla a través del Solution Manager, para lo que es necesario que esté correctamente configurado y conectado al sistema satélite (donde estamos parcheando) y a SAP AG (a través de SAPRouter).
- Actualizamos la SPAM con el parche correspondiente, descargado habitualmente como parte de los parches recomendados en el cálculo de la MOPZ.
- Crearemos la cola de support packages a aplicar manualmente, seleccionando los componentes de software y las versiones a las que queremos subir, o de manera automática, usando el fichero de stack.
- Ejecutamos el cálculo de la cola, y si es consistente podemos proceder a la ejecución de la actualización (import de la cola), sin olvidar temas como el modo Archive de la base de datos (se nos puede llenar el log y congelarse, por tanto, el entorno SAP), posibles prerrequisitos que se indican en la nota OSS, backup previo (o snapshot en caso de entornos virtualizados), bloqueo de usuarios, congelación de jobs, aislamiento del entorno en su caso, tuning de los procesos de import (en caso de grandes sistemas y grandes colas de parches), etc…
- En un tiempo más o menos razonable, dependiente de la cantidad de parches a instalar, el hardware de la máquina, etc… tendremos los parches aplicados, amén de la SPAU (modificaciones de código), SPDD (modificaciones de diccionario), prerrequisitos de órdenes pendientes de importar, objetos bloqueados en órdenes no liberadas, y demás cosillas que suelen aparecer muy habitualmente. Si aparecen modificaciones lo más lógico, y lo más rápido es que la persona o el rol que ha participado en ellas realice las adaptaciones necesarias. Todas las modificaciones se adaptan en el sistema de Desarrollo, que por otra parte es el que mantiene el control de versiones, y a través de órdenes de transporte, se transmiten a los sistemas siguientes en la aplicación de parches, haciendo que las ejecuciones en Preproducción y Producción sean rápidas y sin dependencia de terceros (si, los Administradores pasamos muchas horas sol@s).
 
 
 
Sobre el autor
Publicación académica de Hugo Marcelo Ocaranza, en su ámbito de estudios para la Carrera Consultor Basis NetWeaver.
Hugo Marcelo Ocaranza
Profesión: Ing. en Sistemas de Informacion - Argentina - Legajo: OL56D
✒️Autor de: 33 Publicaciones Académicas
🎓Cursando Actualmente: Consultor BASIS Nivel Inicial
Certificación Académica de Hugo Ocaranza