Administración de sistemas | Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap...

Los sistemas SAP JAVA disponen de una herramienta que se llama SLD (System Landscape Directory) en la cual se guarda un catálogo de todos los productos y componentes de SAP.

Este catálogo se va actualizando a medida que SAP lanza nuevas versiones de sus productos, enhancement packages, support packages etc. De la misma manera SAP recopila mensualmente todas estas actualizaciones y confecciona unos paquetes para actualizar el catálogo del SLD.

En este artículo explicamos cómo actualizar el modelo CIM y el CR Content en SAP a través del SLD.

Para conseguir estos paquetes hay que acceder al SAP Software Download Center con un usuario y contraseña del portal de SAP, concretamente en la sección Support Packages and Patches -> Additional Components -> SAP CR CONTENT como se indica en la siguiente imagen:

Dentro de la sección SAP CR CONTENT los ficheros se organizan por años. Para realizar la actualización es necesario descargar dos tipos de ficheros:

El último fichero disponible correspondiente al Model Version. Este fichero tiene un nombre cimsapxxxxxx_x-xxxxxxxx.zip y es suficiente.
Los ficheros de contenido con el nombre CRDeltaXXXXXX_X-XXXXXXXX.ZIP. De este tipo de ficheros hay que descargar el último paquete disponible cada año para pasar de cada SAP CR Content Version a la siguiente versión.

Una vez descargados todos los ficheros de los paquetes necesarios, los tenemos que importar en el SLD desde la opción Administration-> Content Import:

1. Actualizar el CIM Model en SAP

Primero se debe actualizar el modelo CIM cargando el fichero nombrado cimxxxxxx.zip:

Tras pulsar “importar” se muestra un resumen del fichero y se pide confirmación para cargar el fichero:

Se muestra el progreso mientras se carga el paquete:

2. Actualizar el CR Content en SAP

Cuando el modelo CIM está actualizado con la última versión, se continúa importando cada uno de los ficheros CRDelta de cada año ya que son paquetes incrementales:

En el apartado Administration -> Details -> pestaña Data se muestra la versión y el nivel actual del modelo CIM y el contenido CR:

Mantener estos componentes del SLD actualizados es importante, sobre todo en el SLD del sistema Solution Manager, porque a la hora de actualizar un SP stack o instalar un EHP, para la generación de ficheros .xml mediante el Maintenance Optimizer del Solution Manager, éste consulta el catálogo de productos del SLD. En caso de no tenerlo actualizado la MOPz obliga a actualizarlo.

Para consultar más artículos sobre el Maintenance Optimizer:

http://orekait.com/blog/sap-solution-manager-maintenance-optimizer-12/

http://orekait.com/blog/como-actualizar-sap-solution-manager-7-1-a-sp-stack-08/

http://orekait.com/blog/tutorial-sap-aprobar-ficheros-de-download-basket/

Hay una serie de casos en los que es necesario registrar un sistema ABAP en un SLD (System Landscape Directory) de un sistema JAVA. Por ejemplo, a la hora de actualizar el sistema ABAP con un stack de parches, hay que crear un fichero .xml desde el Solution Manager. Para ello, es necesario que el sistema ABAP esté registrado en el SLD de la instancia JAVA del propio Solman.

Otro caso puede ser, configurar conexiones JCO entre el sistema ABAP y un EP Java, donde nuevamente, es necesario que el sistema ABAP esté registrado en el SLD del sistema JAVA.

Desde el sistema ABAP se accede a la transacción RZ70 donde se indica el nombre de servidor y el servicio Gateway en el que está registrado un id de programa: SLD_UC o SLD_NUC, en función de si el sistema es un sistema Unicode o NO Unicode respectivamente.

En la parte inferior de la transacción RZ70 se pueden seleccionar los datos que se transfieren al SLD:

Ejecutando la transacción RZ70 se crea automáticamente una conexión RFC de tipo TCP/IP en el repositorio de conexiones, transacción SM59.

Para que estas conexiones funcionen, hay que configurar el SLD para que registre los IDs de programa, SLD_NUC y SLD_UC en el Gateway del sistema ABAP. Para esta configuración hay que acceder al SLD con un usuario con permisos suficientes y entrar a Administration -> Settings y en Section, elegir la opción: datasupplier.

En esta pantalla se deben configurar los parámetros GatewayHost y GatewayService con los datos del sistema ABAP que se quiere registrar en el SLD:

Tras la configuración, es necesario reiniciar el servidor SLD con el botón Stop SLD:

Y volver a arrancarlo pulsando Start SLD:

Esto registra los IDs de programa en el Gateway del sistema ABAP para que puedan funcionar las conexiones RFC SLD_NUC y SLD_UC de la transacción SM59.

Si éstas fallan, hay que revisar en el Gateway Monitor, transacción SMGW, para que sistemas externos pueden registrar IDs de programa en el Gateway. Para ello se utiliza el fichero reginfo, que se puede visualizar en el menú Goto -> Expert Functions -> External Security -> … Aquí se encuentras las opciones de visualizar, crear y recargar ficheros de autorizaciones:

El fichero se configura al estilo del fichero de permisos del saprouter, indicando una letra P, para permitir el registro y una letra D, para denegar el registro, de lo que figura en la línea:

En este momento se puede ejecutar la transacción RZ70 y se muestra un mensaje parecido al que se muestra en la siguiente imagen, indicando que la transferencia de datos al SLD se ha realizado correctamente:

Una vez ejecutada la RZ70, en pocos segundos aparece el sistema ABAP registrado en el SLD. En el tipo de sistema técnico se elige el tipo AS ABAP:

En esta ocasión, toca registrar sistemas SAP JAVA en un SLD. El propio sistema JAVA dispone de un SLD, pero aun así hay que registrarlo en el SLD. Para ello hay que acceder a la configuración de SLD Data Supplier desde el SAP Netweaver Administrator (/nwa):

Y desde ahí, accederemos a toda la configuración necesaria para registrar sistemas SAP JAVA.

En la ventana de SLD Data Supplier se puede lanzar el envío de los datos del sistema al SAP SLD configurado:

Es importante tener presente que la URL a la que se conecta el portal para registrar el sistema en el SLD está definida en el destino RFC SLD_Client. A este apartado se puede acceder desde la pestaña: Configuration -> Security -> Destinations:

La conexión que hay que configurar es:

En la configuración de la conexión hay que introducir la dirección URL del sistema JAVA indicando http://<hostname>:<puerto> sin añadir más:

Para que la conexión se pueda realizar, hace falta rellenar en la pestaña Logon Data un usuario con roles suficientes:

Se indican más detalles sobre el usuario en la ventana emergente de ayuda que se abre al pulsar en el enlace de ayuda de la sección SLD Data Supplier del NWA:

Como véis es sencillo registrar un sistema JAVA en SLD de SAP.

Desde un tiempo atrás, para actualizar un sistema SAP, ya sea ABAP o JAVA, se lanzó el paquete: Software Update Manager (SUM), que remplazaba el EHP Installer (ABAP) y el JSPM (JAVA).

En las primeras versiones del SAP SUM se iniciaba un servicio al que había que conectarse utilizando un plugin JAVA accediendo a la dirección:

http://<hostname>:4239.

Con el lanzamiento de las nuevas versiones de la herramienta SAP SUM, el modo de acceso utilizando JAVA y el puerto 4239 ha de ser válido y se muestra el siguiente mensaje:

Configuración de SAP SUM

A partir de la versión SUM15 para iniciar el programa de actualización hay que seguir los siguientes pasos:

Instalar la última versión del SAP Host Agent
Descargar la última versión disponible del paquete SUM
Descomprimir el SUM. Se recomienda hacerlo en la ruta /usr/sap/<SID>/SUM que es donde el script de configuración espera encontrar el software.
Lanzar el script de inicio con los nuevos parámetros:
# ./STARTUP confighostagent <SID>

Es conveniente hacerlo con el usuario root, porque se actualizan ficheros del directorio del saphostagent: /usr/sap/saphostagent

Este es un ejemplo de la ejecución del script:

Acceso GUI

Tras configurar el SAP SUM se muentran distintas URLs para actualizar los distintos tipos de sistemas: JAVA, ABAP, Dual stack, acceder como observador, …

Para acceder por http hay que utilizar el puerto 1128 y para https 1129.

JAVA     https://<hostname>:1129/lmsl/sumjava/<SID>/index.html
ABAP     https://<hostname>:1129/lmsl/sumabap/<SID>/doc/sluigui
Dual       https://<hostname>:1129/lmsl/sumjava/<SID>/dual.html
Observer https://<hostname>:1129/lmsl/sumobserver/<SID>/monitor/index.html

Al acceder a las URLs el servidor pide autenticación con el usuario administrador de la instancia:

Una vez se accede, se muestra la nueva interfaz de SAP UI5 donde se puede iniciar todo el proceso de actualización que comienza pidiendo un fichero .xml con un stack de parches:

Este ha sido un pequeño resumen sobre el nuevo modo de acceso GUI utilizando las nuevas versiones de SAP SUM. Si quieres seguir investigando, te dejamos un enlace con más información sobre el SUM SP 15.

En instalaciones SAP sobre GNU/Linux, en función de la versión del kernel del sistema operativo, al iniciar sesión con SAPGui, puede aparecer un mensaje de error indicando que el demonio UUID no está activo:

En este artículo vamos a tratar el error de demonio no activo que en ocasiones puede aparecer en SAP Linux UUID.

Diagnóstico del error UUID

El error de demonio UUID no activo, se produce con las versiones de kernel más recientes de SAP. Se aconseja revisar la nota SAP 1391070 para solucionar el problema antes de continuar utilizando el sistema SAP.

Para diagnosticar el problema, en la nota mencionada se adjunta un script para verificar el estado del demonio UUID:

Si no está ya instalado, se instala el paquete UUID desde el repositorio correspondiente a la distribución de nuestro sistema operativo:

Arranque de servicio y chequeo final

Una vez instalado el paquete UUID, debemos iniciar o arrancar el servicio:

Una vez iniciado el demonio, el chequeo tras ejecutar el script proporcionado en la SAP note es correcto, y nos aparecerá un mensaje como el que vemos a continuación:

Ya no se muestra el mensaje de error del SAPGui anterior y de hecho, si accedemos a la transacción SICK veremos que ya, no aparecen errores:

Para más información, se recomienda visitar esta página; 1391070 – Linux UUID solutions

Con estas sencillas instrucciones, podemos solucionar el error de demonio UUID no activo que puede aparecer con las últimas versiones del kernel de SAP Linux.

En este artículo aprenderemos a manejar la configuración de SSL en SAP Host Agent.

Con la nueva forma de iniciar y conectarse a la herramienta de actualización, Software Update Manager (SUM), SAP permite conectarse al servidor utilizando una conexión segura cifrada con un certificado SSL. El puerto en el que el SAP hostagent escucha con el protocolo HTTPS, por defecto es el 1129. Aprenderemos por tanto a configurar SAP Host Agent para que utilice el protocolo seguro.

Inicialmente, antes de realizar ninguna configuración adicional, después de instalar el paquete SAP Host Agent, el servidor sólo escucha en el protocolo no seguro (HTTP) y no escucha en el puerto 1129, protocolo HTTPS:

Para realizar la configuración SSL hay que utilizar el programa sapgenpse que se encuentra en los paquetes sapcryptolib y commoncryptolib. Para evitar problemas de seguridad, se recomienda descargar la última versión disponible en el SAP Support Portal: Descarga de la última vesión sapgenpse

Prerrequisitos

Hay que estar conectado con un usuario con permisos root para realizar los siguientes pasos.

Contexto

En este artículo se asume el nombre por defecto para el PSE del servidor. Para cambiar el nombre por defecto se puede usar el siguiente parámetro en el perfil de SAP Host Agent (host_profile):

ssl/server_pse = <ruta al PSE de Servidor>

Procedimiento

Inicialmente hay que establecer la variable de entorno SECUDIR para el usuario sapadm. Si el directorio /usr/sap/hostctrl/exe/sec no existe, se crea previamente y se establecen el propietario y grupo:

orekait.com:root> mkdir -p /usr/sap/hostctrl/exe/sec
orekait.com:root> chown sapadm:sapsys /usr/sap/hostctrl/exe/sec
orekait.com:sapadm> setenv SECUDIR /usr/sap/hostctrl/exe/sec

Se genera un fichero SAPSSLS.pse

orekait.com:sapadm> sapgenpse gen_pse -p SAPSSLS.pse -r <hostname>.csr "CN=<hostname>.orekait.com,O=SAP AG,C=DE"

Con la solicitud de firma se debe obtener un certificado firmado, bien por una autoridad certificadora (CA), o auto-firmando el certificado por uno mismo. El certificado firmado obtenido, se debe importar en el fichero PSE y añadirle credenciales para el usuario sapadm:

orekait.com:sapadm> sapgenpse import_own_cert -p SAPSSLS.pse -c <hostname>.cer -r ca-chain.pem
orekait.com:sapadm> sapgenpse seclogin -p SAPSSLS.pse -O sapadm

Reiniciar el SAP Host Agent.

Resultado

Si se el certificado se ha instalado correctamente, el SAP Host Agent escucha en el puerto 1129 el servidor para la comunicación SSL:

Siguiendo estos pasos ya tendremos finalizada la configuración SSL para SAP Host Agent. Para información adicional:

SSL Configuration for the SAP Host Agent

En el artículo Registrar un sistema ABAP en SLD con RZ70 se explicaba cómo registrar un sistema ABAP en el SLD (System Landscape Directory) de Solution Managaer. En esta ocasión, aprenderemos a configurar SLD para conectarlo a un Gateway ABAP ya que el anterior se basaba en la versión 7.1 de Solution Manager, que es un sistema tipo Dual-Stack y la configuración inicial del SLD es suficiente para poder registrar sistemas ABAP mediante la transacción RZ70.

Tras finalizar la fase de Ramp-up y con la liberación de la versión 7.2 de Solution Manager para la disponibilidad general, la configuración del System Landscape Directory cambia un poco, dado que en esta versión la instalación de la instancia ABAP y la instancia JAVA se realiza de forma separada:

Configuración del SLD de la instancia JAVA

A la hora de configurar el SLD de la instancia JAVA, en la configuración de los parámetros, hay que indicar los datos del Gateway del servidor ABAP:

De esta forma, cuando se reinicie el servidor SLD, los siguientes ID de programa se registrarán en el Gateway ABAP:

Configuración del fichero reginfo

Ahora bien, si la instalación de las instancias ABAP y JAVA del Solution Manager se ha realizado en distintos servidores, la configuración de seguridad por defecto del Gateway ABAP impedirá que el SLD registre los Program ID en el Gateway.

Para permitir esta conexión, hay que acceder a la transacción SMGW del sistema ABAP y crear el fichero reginfo:

Se seleccionan los programas que hace falta registrar en el Gateway (SLD_NUC y SLD_UC) y se pulsa el botón de guardar las entradas en fichero:

Este fichero, por defecto, se genera para permitir registrar los programas de forma local, por lo que hay que añadir el nombre del servidor JAVA desde el que se está intentando registrar el servidor SLD. Este fichero se crea en la ruta:

/usr/sap/<SID>/SYS/global/reginfo

#VERSION=2
P TP=* HOST=local
P TP=* HOST=internal
#
# appended by SOLMAN_ADMIN at 20161021 093705
#
P TP=SLD_UC HOST=local CANCEL=local ACCESS=*
P TP=SLD_UC HOST=internal CANCEL=internal ACCESS=*
P TP=SLD_UC HOST=<JAVA_hostname> CANCEL=internal ACCESS=*
P TP=SLD_NUC HOST=local CANCEL=local ACCESS=*
P TP=SLD_NUC HOST=internal CANCEL=internal ACCESS=*
P TP=SLD_NUC HOST=<JAVA_hostname> CANCEL=internal ACCESS=*

Una vez modificado el fichero, hay que cargarlo desde SAP para que los cambios sean efectivos:

Por último, es necesario reiniciar el servicio SLD para que se registren los Program IDs y el TP Name, aparezca en la lista de clientes conectados en el Gateway ABAP. Lo que nos permite utilizar la transacción RZ70 para registrar directamente sistemas ABAP en el SLD:

Así es como podemos configurar SLD para conectarlo a un Gateway ABAP a partir de la versión 7.2. del Solution Manager.

En este artículo se explica cómo transportar objetos SAP. La forma habitual es hacerlo mediante órdenes de transporte que contienen la definición de los objetos a transportar.

Sistema SAP destino del transporte

Las órdenes de transporte tienen la propiedad ‘Sistema destino‘, que indica cuál es el sistema SAP de destino para los objetos que contiene la orden.

Cuando la orden tiene informado el <SID> del sistema de destino, si la orden se libera, el sistema SAP genera dos ficheros con la definición y la versión de los objetos SAP. Por el contrario, si la orden no tiene informado el parámetro ‘Sistema destino‘, se dice que la orden es local, y a la hora de liberar la orden no se genera ningún fichero.

Algunos objetos en un sistema SAP no se permiten transportar, y sólo pueden ser incluidos en órdenes de transporte locales. Para transportar este tipo de objetos, hay que utilizar órdenes de transporte del tipo transporte de copias.

Añadir objetos en una orden de transporte SAP

Se pueden añadir objetos en una orden de transporte SAP, de varias maneras:

Modificando el objeto en un sistema de desarrollo. Cuando se realiza algún cambio en un objeto SAP en un sistema de desarrollo, el propio sistema pide una orden de transporte (depende de la configuración del mandante).

Escribir entrada de transporte. Desde el Object Navigator (Tcode: SE80) se pueden elegir los objetos del repositorio de SAP para transportar. En el campo desplegable del Repository Browser, se puede elegir el tipo de objetos:

Una vez elegido el objeto a transportar, desde el menú contextual del objeto:

Otras funciones -> Escribir entrada de transporte

Se abre una ventana (pop-up) para indicar una orden de transporte:

Incluir los objetos en la orden de transporte. En las órdenes de transporte se pueden indicar los objetos directamente en la tabla de la orden, indicando el ID programa, Tipo objeto y Objeto (nombre del objeto).

Con estos pasos, ya sabes todo sobre cómo transportar objetos SAP utilizando órdenes de transporte que contienen la definición completa del objeto. Además, puedes incluir objetos a tu orden, de una forma sencilla.

En el siguiente artículo se exponen las principales razones por las cuales deberíamos considerar como importante el Solution Manager.

Esta plataforma es la solución estándar de SAP para llevar a cabo una monitorización al detalle de los sistemas de éste, siendo el pilar en que se apoya el mantenimiento exitoso de los mismos.

Por ello, no debería sorprendernos que sea uno de los aspectos más críticos y que más atención merece en las implementaciones y mantenimiento de los sistemas de gestión SAP.

SAP Solution Manager

SAP Solution Manager, si bien no deja de ser una maquina técnica que en principio es invisible para los usuarios de negocio, cuenta con una serie de prestaciones y capacidades que, bien utilizadas, la convierten en uno de los sistemas más importantes de la empresa.

Respecto a novedades, en julio de 2016 SAP liberó la versión 7.2 dando de plazo para migrar a la versión 7.1 hasta el 31 de diciembre de 2017.

Son muchas las razones por las que nosotros recomendamos migrar a la nueva versión, pero a continuación exponemos las que a nuestro parecer son las más significativas:

Experiencia de usuario mejorada a través de SAP Fiori

La última versión incorpora Fiori Launchpad, que proporciona una interfaz gráfica e intuitiva que reemplaza a los workcenters de la versión anterior.

Los cuadros de mando (dashboards) para el control de indicadores se han migrado de Adobe Flash a HTML5 . Ya es posible visualizarlo en cualquier dispositivo sin necesidad de aplicaciones adicionales.

Monitorización en SAP Solution Manager

En la nueva versión, se ha ampliado la gama de dashboards para la monitorización de indicadores relacionados con:

Seguridad
Incidentes
Disponibilidad
Rendimiento del sistema
Otros aspectos críticos para la correcta operatividad de los sistemas

Con la nueva versión tenemos la posibilidad de crear dashboards a la medida del cliente de forma sencilla, mediante plantillas predefinidas. Esto incluye paneles para monitorizar no sólo métricas técnicas sino métricas de negocio.

Vemos pues que, con la nueva versión, Solution Manager ha salido del armario de sistemas para entrar en la lógica del negocio y en aspectos más relacionados con el día a día de los usuarios.

Gestión de Procesos de Negocio

SAP ha renovado completamente la funcionalidad de Business Process Management. En esta nueva versión, se ha introducido una herramienta gráfica de modelado de procesos empresariales basada en el estándar BPMN 2.0.

Esto supone una mejora significativa en la comunicación entre las áreas de Negocio e Informática, al proporcionar una visualización intuitiva de los procesos de la empresa.

Soporte en Solution Manager

Soporte en sistemas híbridos

Debido a que el alojamiento de entornos y servicios en la nube es un fenómeno al alza, Solution Manager 7.2 está pensado para dar soporte a sistemas en la nube, como puede ser el caso de SuccessFactors.

Soporte implementación de HANA y S/4HANA

La versión 7.2 esta optimizada para gestionar sistemas basados en HANA y S/4HANA. Además, también cabe la posibilidad de hacer la instalación directamente en HANA.

Conclusión

En resumen, se puede decir que SAP ha transformado el Solution Manager en algo más que una herramienta de soporte, mejorando la parte funcional para ser una herramienta esencial para el negocio.

Las mejoras incluidas en 7.2 simplifican el mantenimiento y la creación de procesos de negocio, abarcando desde la documentación de la solución a la gestión del cambio.

Más allá del lado funcional, el lado técnico también ha sido actualizado, incluyendo mejoras en la interfaz de usuario gracias a SAPUI5 y Fiori.

Y no hay que olvidar la inclusión de SAP HANA en la licencia para Solution Manager 7.2.

Ahora, cualquiera puede ejecutar Solution Manager 7.2 en SAP HANA sin el costo de la licencia.

Una vez conocida la importancia de SAP Solution Manager 7.2, podemos empezar a hacer uso de todas sus ventajas.

En los artículos ‘¿Por qué debería importarme el SAP Solution Manager?‘ y ‘Solution Manager: ¿Actualizar o re-implementar?’ se hablaba de aspectos destacables de esta plataforma.

En el artículo de hoy, dejamos un vídeo del Webinar impartido el pasado 4 de mayo, en el que hablamos sobre Solution Manager 7.2.

¿Qué es SAP Solution Manager?

Como venimos comentando a lo largo de los últimos artículos publicados sobre Solution Manager, está es la plataforma estandar que proporciona SAP para la monitorización de todos sus sistemas. Es por esto precisamente, por lo que es tan importante para llevar a cabo implementaciones y mantenimientos de todos los sistemas de gestión SAP.

Además, cuenta con unas prestaciones y capacidades que pueden resultar muy útiles en la gestión general de una empresa.

Resumen Webinar SAP S0lution Manager 7.2

En el webinar que se presenta, hablamos sobre todos los cambios introducidos en la nueva versión liberada a finales del pasado 2016, y hacemos una pequeña demostración de un sistema de monitorización y alertas.

Principales cambios en la nueva versión.
Mejores prácticas de migración o actualización.
Pasos generales de configuración.
Demo sistema de alertas y monitorización.
Presentación de paquete de migración desarrollado por Oreka IT.

Además, os damos unas cuantas razones para actualizar y las claves para saber cómo hacerlo.

Esperamos que os guste y os sea de utilidad.

En este artículo, solucionaremos uno de los problemas más comunes a la hora de acceder a la transacción SCC4 de SAP S/4HANA 1511 y crear un mandante nuevo.

En muchas ocasiones, al intentar crear un nuevo mandante, no se muestra el botón “Entradas Nuevas” (New Entries), tal y como se muestra en la imagen. A continuación, os explico paso a paso todo lo que necesitais hacer para solucionar el error.

Existe una Nota SAP referente a este problema:

Nota SAP

En la nota, se indica que el problema de que no visualicemos el botón “Nuevas Entradas” dentro de la transacción SCC4 de SAP S/4HANA 1511, es debido a que sólo existe una entrada en la tabla.

La solución propuesta por SAP, es crear una entrada ”Dummy” desde la transacción SE11, SE16 o SE16N. Desde la transacción SE16N se puede acceder a la tabla T000 de SAP:

Pero las modificaciones no están disponibles en esta tabla.

Habilitar Modificaciones dentro de la tabla T0000

Para conseguir crear una entrada “Dummy” en la tabla, utilizaremos la función SE16N_INTERFACE desde la transacción SE37:

Para poder activar la edición, hay que marcar los parámetros de edición I_EDIT = X:

Crear entrada ”Dummy” en SAP

Una vez realizados estos pasos, será posible modificar las entradas de la tabla T000:

Por último, solo nos queda grabar la entrada “Dummy”:

Tras seguir todos estos pasos, en la transacción SCC4 de SAP S/4HANA 1511 aparece el botón “Nuevas Entradas“ (New Entries) para así poder modificar las entradas desde la tabla.

A continuación, se muestra una imagen con el botón habilitado.

A partir de la versión 2.0 de SAP HANA, el Cockpit de Hana no se instala junto con la base de datos:

En este artículo, seguiremos el proceso de instalación SAP HANA Cockpit 2.0 paso a paso.

Al intentar acceder al Cockpit, se abre un navegador con el siguiente mensaje:

La descarga del paquete de instalación se realiza desde el SAP Support Portal, tal y como se muestra en la imagen.

A primera vista, puede parecer que desde el Lifecycle Management residente en el sistema, se puede instalar el HANA Cockpit 2.0 como se ve en las siguientes imágenes:

En realidad, el HANA Cockpit 2.0 se instala como una instancia independiente. Es por ello, que a la hora de instalarlo haya que utilizar el Lifecycle Management del propio paquete descargado y descomprimido.

Para ejecutar la instalación desde línea de comando, se ejecuta ./hdblcm.sh . Para la versión con interfaz gráfico sin embargo, ejecutaremos el siguiente comando; ./hdblcmgui.sh.

En la instalación se indica que se va a instalar un sistema nuevo:

Se indican el nombre de host, directorio de instalación, <SID> que por defecto es H4C y número de instancia dentro del rango 00 – 97 que por defecto es 96. En la imagen se muestran estos parámetros de instalación ya configurados.

En el siguiente paso, se debe indicar una contraseña maestra:

A continuación, se nos muestra un resumen de los parámetros introducidos para la instalación, que se ejecutará inmediatamente después.

Como comentamos, una vez configurados todos los parámetros anteriores, el proceso de instalación SAP Hana Cockpit 2.0 comenzará una vez que pulsemos el botón ‘Install’ y finaliza en unos minutos.

Una vez instalado el HANA Cocpit 2.0, antes de que los usuarios puedan acceder al SAP HANA Cockpit, hay que realizar una serie de tareas de administración. Se debe iniciar el Cockpit manager y conectarse con el usuario COCKPIT_ADMIN para registrar recursos.

Para identificar las direcciones URLs y puertos se accede al directorio que se indican a continuación y ejecutamos en consola el comando que se muestra:

/<sapmnt>/<SID>/bin

./xs-admin-login

Dicho comando requiere autenticarse con el usuario COCKPIT_ADMIN:

El directorio /<sapmnt> por defecto es /hana/shared

Después se ejecuta ./xs apps que muestra un listado de las aplicaciones disponibles:

Si se accede a la URL: https://<hostname>:51023 y se usa el usuario COCKPIT_ADMIN para autenticarse, la primera vez aparece un mensaje indicando que no se dispone de los permisos necesarios y si se desea asignárselo:

Si se comprueba la versión instalada, se verifica que la versión del HANA Cockpit es 2.2.6

En el siguiente enlace, se puede encontrar una recopilación de preguntas frecuentes sobre SAP HANA 2.0 Cockpit, así como información sobre requisitos del sistema, versiones, características que se incorporan en la versión 2.0, etc.

Preguntas frecuentes sobre SAP Hana 2.0 Cockpit

A la hora de crear un sistema SAP, uno de los aspectos más importantes es la creación y configuración de la máquina en la que irá instalado.

En este artículo, se explicarán los pasos a seguir para tener creada una máquina virtual donde poder alojar un sistema SAP. Como ejemplo utilizaremos la herramienta VMware vSphere ESXi y la distribución Oracle Linux.

Definir hardware necesario mediante VMware

Para definir el hardware lo primero que hay que hacer es una aproximación del volumen de datos y usuarios que se cree que va a tener el servidor. Es decir, la carga de trabajo que tendrá que soportar. Para ello, se puede usar como apoyo la herramienta quick sizing (se necesita usuario en Service SAP) que proporciona SAP.

En la herramienta de VMware, accediendo a la opción “Edit Settings” y en la pestaña Hardware se puede añadir y modificar el hardware necesario para la máquina.

Partición en la instalación de SO Linux

El artículo está dirigido a sistemas operativos Linux. Por lo tanto, habrá que decidir las diferentes particiones que crearemos dependiendo de los puntos de montaje.

Lo primero que se hará, es crear un “volumen group” que en este caso se le ha dado el nombre de vg_sys, el cual, tendrá dentro las siguientes particiones:

/
/var
/tmp
/usr
swap.

También, habrá que reservar un espacio para la partición /boot. A continuación, hay un ejemplo de una instalación realizada utilizando la distribución Oracle Linux y 30GB para la parte del sistema.

Resultado del comando lsblk:

Particiones de BBDD y SAP

Una vez instalado el sistema operativo, el siguiente paso sería crear las particiones donde estarán la parte de SAP y la BBDD.

En este caso, se necesitará dos nuevos “volumen group” uno para SAP (vg_sap) y otro para la BBDD, por ejemplo, Sybase (vg_sybase). Es recomendable que cada el sistema operativo, SAP y la BBDD vayan en discos duros separados.

Lo primero, será coger los discos duros de SAP y BBDD y crear una partición de tipo LVM mediante el comando cfdisk.

Para el sistema SAP, es recomendable crear los siguientes volúmenes lógicos:

lv_sapmnt, lv_usrsap
lv_usrsaptrans.

Después, hay que asignarles un filesystem y montarlos en los directorios, que habrá que crear:

/sapmnt,
/usr/sap
/usr/sap/trans.

Para la base de datos, en este caso Sybase, sólo es necesario crear un volumen lógico que cogerá el 100% del espacio de vg_sybase. Una vez se le haya asignado un filesystem lo montaremos en directorio /sybase.
El último paso es añadir los puntos de montaje en el fichero /etc/fstab para que sean permanentes, por ejemplo:

/dev/mapper/vg_sap-lv_usrsap /usr/sap           xfs     defaults        0 0
/dev/mapper/vg_sap-lv_usrsaptrans /usr/sap/trans xfs     defaults        0 0
/dev/mapper/vg_sap-lv_sapmnt /sapmnt             xfs     defaults        0 0
/dev/mapper/vg_sybase-lv_sybase /sybase          xfs    defaults        0 0

Resultado del comando lsblk en este punto:

Configuración de red

La configuración de red es importante tanto para poder identificar el sistema como para que el sistema sea accesible. Dependiendo de la infraestructura de la red la configuración puede cambiar, pero hay dos puntos que serán comunes.

Lo primero, será cambiarle el hostname con el que se quiera identificar la máquina. Se utilizará el comando:

hostname <nombre_host>

Además, habrá que modificar el archivo /etc/hostname.

Lo segundo, será añadir una dirección IP de la subred en la que tiene que ir y especificar la máscara de subred, mediante el comando:

ifconfig <nombre_interfaz> <IP> netmask <máscara_subred>

Para que los cambios de IP sean permanentes habrá que cambiar el fichero:

/etc/sysconfig/network-scripts/ifcfg-<nombre_interfaz>

Concretamente, el campo IPADDR.

Instalación de librerías SAP

El quinto paso, será instalar algunas librerías necesarias para no tener problemas cuando se lance la instalación de SAP.

Para instalar estar librerías se ha utilizado el comando yum.

Libaio-devel: permite realizar llamadas I/O asíncronas al sistema. Es importante, por ejemplo, para la BBDD.
csh ksh tcsh: permite la posibilidad de interpretar diferentes scripts de diferentes Shell que tiene SAP.
Uuid: permite identificar la información de forma única en un entorno distribuido. Se puede usar para etiquetar objetos que tengan una corta duración o para verificar objetos persistentes a través de la red. Por ejemplo, se puede usar en bases de datos para asegurarse que filas y registros son únicos a través de diferentes bases de datos.
Perl: permite instalar un intérprete de Perl para poder ejecutar el diferente código que tiene SAP desarrollado en Perl.

Con el correcto seguimiento de los pasos explicados anteriormente, se conseguiría una máquina virtual preparada para poder lanzar la instalación de un sistema SAP. En este punto estaría todo listo para poder comenzar, a través del Software Provisioning Manager, la instalación.

El mantenimiento Basis de los sistemas SAP es un tema delicado ya que es el encargado de la disponibilidad del sistema y, por consiguiente, de la viabilidad del negocio. No obstante, existe una tendencia a no valorar suficientemente la importancia del mantenimiento Basis. Hasta que surgen los problemas. El equipo encargado de llevar a cabo las labores de mantenimiento Basis bien se podría comparar a la figura de un portero de fútbol: nadie se acuerda de él hasta que le meten gol.

Por ello, es clave elegir un partner capacitado que transmita experiencia, conocimiento, seguridad, cercanía, fiabilidad y que sepa llevar a cabo las actuaciones necesarias para sacar el máximo rendimiento a los sistemas SAP de una empresa u organización.

Un punto importante del mantenimiento BASIS de SAP es el que hace referencia a la monitorización de los sistemas. Tradicionalmente, esta monitorización se ha venido haciendo de forma manual. En esencia, se ejecutaban transacciones específicas de BASIS para chequear el estado del sistema. Es verdad que con los monitores CCMS se podían crear alertas, pero no era el método más usado. Todavía a día de hoy no es raro encontrarse con departamentos que funcionan bajo este modelo. Pensamos que no es la forma óptima de monitorizar los sistemas, ya que es difícil poder anticiparse a los problemas, además de suponer un esfuerzo adicional para realizar las comprobaciones manuales.

Centro de soporte de Oreka IT

En el Centro de Soporte de Oreka IT gestionamos las alertas generadas en el Solution Manager y, tras un rápido análisis, valoramos la criticidad y proponemos una solución al cliente. De esta manera, la incidencia no llegará a un punto que ponga en riesgo la disponibilidad del sistema. Nos parece que este tipo de soporte flexible es más acorde con lo que un responsable de IT debería esperar de un mantenimiento Basis.

Capacidades del Centro de Soporte de Oreka IT

Nuestro equipo de soporte Basis se compone de personas con una larga trayectoria en labores tanto de administración y arquitectura de sistemas SAP, como de gestión de infraestructura TIC. Por supuesto, contamos con las certificaciones oficiales de SAP para los aspectos relativos a Basis y arquitectura de sistemas SAP.

Además, nuestras personas han sido formadas para trabajar con el Solution Manager y están capacitadas para realizar una lectura global de los tipos de alertas, lo que se traduce en saber cuándo hay margen para avisar al cliente y cuándo hay que actuar de manera inmediata antes de que el sistema caiga.

Valor de Solution Manager

El uso del Solution Manager es un valor añadido para el cliente ya que se trata de una herramienta pensada para centralizar la monitorización de los sistemas satélites y tener un repositorio de documentación actualizado con todo el histórico de incidencias acaecidos en los sistemas. Ya sean ERPs convencionales, como pilas JAVA, maquinas HANA y con la nueva versión, también es capaz de monitorizar servicios in Cloud. Esta automatización de procesos supone un ahorro en los costes de IT. Por hablar de números, según fuentes de SAP, el uso correcto del Solution Manager, reduce un 25% las incidencias técnicas y un 40% el gasto en monitorización de sistemas.

Por poner un ejemplo, si al año se utilizan 100 horas para monitorización con 20 incidencias, con el Solution Manager se podría reducir a 60 horas, reduciendo las incidencias a 15.

Esto hace que haya un ahorro en costes de un 35% que se puede utilizar para otras labores.

Comunicación con Cliente & Buenas Prácticas

En Oreka IT, pensamos que el cliente merece una respuesta cercana e interesante, es por ello por lo que, para una comunicación fluida con el cliente, disponemos de un gestor de incidencias propio donde la primera respuesta ya es atendida por una persona de BASIS y podrá hacer una primera valoración dentro de los tiempos acordados ajustados a la comodidad del cliente.

Por último, tanto nuestra herramienta de gestión de incidencias como nuestro modelo de mantenimiento están avalados por la certificación ISO 20000, que provee un marco de buenas prácticas, de tal manera que el servicio de mantenimiento esté alineado con las expectativas del cliente.

El mantenimiento BASIS en un servicio fundamental para la optimización de los recursos, anticiparse a los problemas y hacer un sistema más eficiente. En Oreka IT te podemos ayudar. ¡Pregúntanos!

A continuación se plantea una situación un tanto atípica en un sistema SAP.

Tras finalizar con éxito una instalación de un sistema SAP S/4HANA on premise 1610, los objetos workbench estándar del repositorio ABAP (reports, tablas, elementos de datos, dominios, etc.) son completamente modificables.

En un mandante de desarrollo donde la configuración de la transacción SCC4 permita realizar modificaciones sin restricciones y las opciones de modificación globales del sistema, transacción SE06, los objetos estándar del sistema se pueden modificar sin registrarlos en el SAP Support Portal.

En un mandante de desarrollo/formación las opciones más comunes son:

Y las opciones de modificación del sistema se encuentran en status Modificable:

La versión de Netweaver es 7.51 y los componentes del sistema S/4HANA 1610 on premise son los siguientes:

El release instalado es SAP S/4HANA 1610 como se pude ver en el status del sistema:

Los objetos estándar del repositorio ABAP es totalmente modificable:

Al pasar a modificar el objeto, se muestran las siguientes ventanas advirtiendo que las modificaciones de objetos estándar no están permitidas:

Una vez seleccionado el idioma en el que modificar el objeto, se habilita la modificación del objeto estándar:

Lo mismo sucede a la hora de modificar un programa (report) o un módulo de función:

Se muestra la advertencia siguiente:

Si se desactiva el asistente de modificaciones, el objeto se puede modificar sin ninguna restricción:

El report es completamente modificable y se puede grabar y activar sin introducir ningún tipo de clave de registro del objeto:

En esta situación se plantean varias cuestiones:

¿Es consciente SAP de esta circunstancia?
¿Está previsto que en un SP stack liberado SAP bloquee el código estándar?