Amazon Web Services (AWS1) nos permite disponer de equipos virtuales sobre los que instalar SAP. Las ventajas de este producto es que se paga sólo por el uso del mismo, un servidor apagado no produce ningún coste. Sólo el espacio en disco produce costes continuos, salvo que borremos también los datos, en cuyo caso tampoco se generan costes. También el flujo de información desde y hacia la nube tiene un coste. Es el hardware como servicio (HaS).
Para la gestión de incidencias y bugs en el software que desarrollo llevo ya varios años usando la herramienta bugzilla
No la suelo actualizar al mismo ritmo que sacan nuevas versiones, pero una vez al año mas o menos procuro ponerme al día. El proceso de upgrade está muy bien explicado en la documentación y no suele ser problematico. Digo suele porque mi instalación es en un hosting compartido donde el servidor Apache, mySQL y PERL se ejecutan con SUExec y las cosas no van siempre como pone en el manual.
Lo primero es obtener los instalables para windows:
Llevo unos 10 años trabajando con sistemas de control de versiones (SCM: Source Code Management, en inglés) para gestionar el código de mis desarrollos. Empecé con CVS y cuando descubrí las mejoras de Subversion migré mis repositorios al mismo.
Es posible en SAP ejecutar en TEST varias funciones seguidas para comprobar su funcionamiento. Un ejemplo típico es el caso de los módulos de funciones que requieren la llamada a BAPI_TRANSACTION COMMIT para que se hagan efectivos los cambios.
Es la segunda vez que realizo una instalación por red de un sistema trixbox y he tenido que repasar todos los conceptos de PXE y arranque por red que ya tenia oxidados. Como no hay dos sin tres, y seguramente tendré que realizar alguna instalación más de este tipo en un futuro no muy lejano, pero lo suficiente para que ya no me acuerde del procedimiento, me he decidido a crear esta mini-guía que me sera de gran utilidad en estos menesteres, y quizás a alguien mas pueda serle de provecho.