✒️SAP BASIS Las notas y support packages

SAP – Aplicando Support Packages – Mis Reglas de Oro

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

1. 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.
2. 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.
3. 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.
4. 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).
5. Actualizamos la SPAM con el parche correspondiente, descargado habitualmente como parte de los parches recomendados en el cálculo de la MOPZ.
6. 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.
7. 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…
8. 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).

En caso de problemas el troubleshooting puede ser más o menos completo, desde el reinicio de la transacción y el relanzado del import a problemas graves en el entorno que sólo podrán ser solucionados por un Consultor experimentado, y en última instancia por SAP. Aún así, si somos metódicos y nos cubrimos bien las espaldas, siempre podemos tirar de backup, aunque no está muy bien visto ;·)

Reglas de Oro

ANTES de aplicar parches a un entorno aplicaremos siempre mis REGLAS DE ORO:

1. Orden de aplicación: Desarrollo – Preproducción (si existe) – Sandboxes (si existen) – Producción. Como regla general Producción SIEMPRE será el último sistema en actualizarse, ya estudiados tiempos, necesidades, problemas, soluciones, refinado el procedimiento y la checklist en los entornos anteriores.
2. Ventanas de intervención con Amplitud para ejecutar marcha atrás. Esto sirve a dos propósitos, el primero es que el cliente tenga claro el tiempo de intervención, y el segundo es que el consultor disponga del tiempo suficiente para llevar a cabo las operaciones de manera sosegada, manteniendo la cabeza fría y con el mínimo de presión. Si el tiempo corre en nuestra contra, cualquier problema, por sencillo que sea, puede terminar siendo un desastre por falta de lucidez mental. Esto no quiere decir que para aplicar 3 parches necesitemos 1 jornada o un fin de semana completo… todo debe ser adecuado y lógico.
3. Checkpoints consensuados y aprobados por el cliente. Horarios, tareas, puntos de no retorno, etc…
4. Backup de los entornos antes de realizar ningún cambio, en la medida de lo posible un backup que permita un recovery rápido, que respete los parámetros temporales del cliente. Un full backup en frío (de base de datos y aplicación) es buena opción casi siempre, tanto en sistemas Wintel como en sistemas Linux/Unix.
5. Tener a mano la documentación necesaria para no perder tiempo: Notas OSS, manuales de instalación de la versión SAP correspondiente sobre la plataforma y la base de datos en que esté el entorno. Toda la documentación que no se conozca por parte del consultor será estudiada ANTES de comenzar con las aplicaciones de parches.
6. Checklist preparada y revisada punto por punto.
7. Descansar física y mentalmente. Si el tema se complica, y dependiendo del cliente y la situación, podemos encontrarnos con muchas horas seguidas de trabajo sin descanso. Es mucho lo que está en juego cuando trabajamos con entornos Productivos. Tenemos que estar al 110%.