SAP

Configurar y optimizar backups Hana con Veeam Backup

Configurar y optimizar backups Hana con Veeam Backup 371 263 SAPMiN

Por todos son conocidas las grandes capacidades que tienen las soluciones de respaldo y restauración ofrecidas por Veeam Backup. En el post de hoy trataremos cómo configurar backups nativos de Hana a través de Veeam, y sin la necesidad de contar con el Hana Cockpit 2.0, aunque bien es cierto que esta herramienta puede sernos de gran ayuda (por ejemplo para planificar los backups sin un sistema SAP ABAP, gestionar el ciclo de vida de los backups, etc.)

¿Cómo funciona el agente de Veeam Backup para Hana?

El agente de Veeam utiliza el interfaz de backint de SAP Hana para comunicarse y enviar los datos a los repositorios del servidor de Veeam Backup, haciendo uso de técnicas de compresión y optimización para reducir el espacio necesario de almacenamiento para estos backups.

Una vez instalado y configurado el agente de Veeam para Hana, e iniciado un backup desde la parte ABAP de SAP, el Hana Studio, el Hana Cockpit o incluso mediante comandos HDBSQL, el agente iniciará un job en el servidor de Veeam, se lanzarán los servicios para el movimiento de los datos hacia el repositorio destino utilizando la cantidad de procesos paralelos definidos hasta completar la transferencia de todos los datos seleccionados según el tipo de backup lanzado.

Pasos previos y requisitos para configurar y optimizar backups Hana con Veeam Backup

Dado que el agente de Veeam se ha de instalar en el servidor Hana, es un tanto improbable que no se cumplan los requisitos necesarios para poder hacerlo. Aún así, son estos:

  • versiones de S.O.: SuSE SLES / SuSE SLES for SAP 12 o superior, y Red Hat for SAP Hana / Red Hat for SAP 7.2 o superiores
  • versiones SAP Hana: Hana 1.0 SP12 o superior y Hana 2.0 SPS 02 o superior (las versiones Hana Express Edition no se encuentran soportadas) 
  • las versiones del plug-in y el servidor de Veeam han de ser compatibles
  • comunicación directa entre el servidor Hana y el servidor Veeam. Será necesario, al menos, habilitar los puertos (cuyo valor estándar por defecto) 10006, 2500 (y si utilizamos varios procesos paralelos para backup tantos puertos del 2500 en adelante como procesos paralelos utilicemos) desde el servidor Hana hacia el servidor de Veeam Backup. Revisar el siguiente enlace para otras opciones de almacenamiento
  • Una licencia de Veeam válida para poder llevar a cabo los backups

Instalación del agente

Descargamos la iso VeeamBackup&Replication_xx.x.x.xxxx.iso de la siguiente url https://www.veeam.com/backup-replication-vcp-download.html

De esta iso, obtenemos el paquete VeeamPluginforSAPHANA-xx.x.x.xxxx-x.x86_64.rpm ubicada en el directorio /Plugins/SAP HANA/x64, lo subimos al servidor hana y lo instalamos como root (o un usuario con permisos sudo) con el comando rpm -ivh VeeamPluginforSAPHANA-xx.x.x.xxxx-x.x86_64.rpm

Configuración del plug-in

Una vez instalado, configuraremos el plug-in con los datos relativos a nuestra instalación de Veeam Server. Para ello, con el usuario <sid>adm de nuestra instancia Hana y desde dicho servidor lanzaremos el siguiente comando que despliega en modo texto el asistente de configuración:

SapBackintConfigTool --wizard

Introducimos todos los datos para conectar con el servidor de Veeam, usuario y password con permiso para los repositorios, etc.

Nota importante: el usuario indicado ha de ser capaz de hacer login en el servidor de Veeam y tener permisos suficientes para gestionar los repositorios de datos en los que queremos dejar los backups.

Instalacion

Para su posterior consulta o modificación, el fichero principal de configuración para el agente se encuentra en la siguiente ubicación, que se ha generado tras la ejecución del comando anterior:

 /opt/veeam/VeeamPluginforSAPHANA/veeam_config.xml

Finalmente verificamos que la configuración en los parámetros de Hana se ha actualizado correctamente. Podemos verificarlo mediante el fichero global.ini → Backup, Hana Studio o mediante la ST04 si estamos utilizando un sistema SAP:

Como se puede apreciar en la imagen, los parámetros para realizar los backups mediante la interface de backint están completados, y haciendo uso del plug-in de Veeam.

Recomendaciones adicionales para optimizar los backups de Hana en Veeam.

A destacar en la parte inferior, correspondiente al backup de log de Hana, que hemos configurado también que Hana haga uso del backing a través de Veeam para salvar los logs de la BBDD, con una frecuencia de 15 minutos.Optimización de los backups (y también de la restauración)Optimización de los backups (y también de la restauración)

En el fichero de configuración de Hana global.ini → backup, podremos ver también los cambios efectuados por el asistente del plug-in Veeam:

global.ini

A partir de este punto, ya podemos lanzar los backups contra Veeam 🙂

Optimización de los backups (y también de la restauración)

Aunque por defecto la configuración de Hana utiliza un único proceso de backup, es posible configurar varios procesos paralelos de tal forma que los tiempos de backup se reduzcan considerablemente, así como también la duración de las restauraciones de BBDD, que harán uso de la misma cantidad de procesos paralelos (definido en el parámetro de Hana max_recovery_backint_channels). Si bien es cierto que Hana de forma automática aumenta esta cantidad de procesos para BBDDs de más de 128GB, nos adelantaremos a ello configurando los procesos que nos parezcan más adecuados para nuestra instalación. Es importante también aclarar que cuantos más procesos paralelos definamos, mayores recursos HW serán utilizados para realizar el backup, y que por tanto será necesario buscar un equilibrio para no afectar negativamente en el rendimiento del sistema Hana durante el tiempo de backup.

Para habilitar esta funcionalidad modificaremos los siguientes parámetros en Hana (fichero global.ini):

  • parallel_data_backup_backint_channels: definiremos la cantidad de procesos paralelos
  • data_backup_buffer_size: indicaremos el parámetro anterior x 512

Recomendaciones adicionales para optimizar los backups de Hana en Veeam

  • utilizar un repositorio de backups exclusivo
  • hacer backups de BBDDs tenant de forma secuencial en vez de en paralelo para optimizar el uso de recursos hardware
  • definir también varios procesos paralelos para la restauración, y siempre menos de 64
  • utilizar el cifrado de datafiles y backups en Hana, ya que Veeam es compatible con este mecanismo
  • realizar también el backup del catálogo de backups, que por defecto se genera en el mismo directorio que los logs de Hana en disco, mediante el agente de Veeam Backup. Para ello configuraremos el parámetro catalog_backup_using_backint a true, y definiremos convenientemente el parámetro catalog_backup_parameter_file con valor /opt/veeam/VeeamPluginforSAPHANA/hdbbackint

Ejecución de backups

Tras configurar y optimizar las tareas de backup, ya estamos prestos a lanzar la primera copia.

Disponemos de diferentes opciones para realizarlas:

  • utilizar los comandos hdbsql de Hana: backup data for nombreDB using backint (‘nombre_backup’);
  • desde el Hana Studio
  • desde el Hana Cockpit
  • desde la TX DB13 en caso de usar Hana con un sistema ABAP

En nuestro caso haremos uso de la última opción:

DB13 Schedule

Como se puede ver en la imagen, hemos seleccionado el destino de tipo backint, y el campo Backup Destination aparece deshabilitado, dado que se utiliza con backups a discos, y por último indicamos el nombre que queremos que tenga el backup, pudiento utilizar algunas variables como el timestamp:

DB13 Schedule

Lanzamos el backup de forma inmediata, y comprobamos que ha finalizado correctamente:

Log

Si vamos a la consola de Veeam podremos ver los jobs que se generan con el plug-in.

Retención de los backups

Como último punto, y no menos importante, tenemos la forma con la que fijar el ciclo de vida para los backups que acabamos de generar. Tenemos varias opciones para gestionar su borrado:

  • borrado manual desde el Hana Studio
  • configurar el período de retención desde el Hana Cockpit
  • borrado mediante comando hdbsql: backup catalog delete {backup_id | all before backup_id}
  • borrado manual desde la consola de Veeam Backup
  • indicar el periodo de retención en el propio agente de Veeam

En esta ocasión haremos uso de la última opción, que permite de forma automatizada borrar en Veeam Backup los backups más antiguos del número de días configurado. Con el usuario <sid>adm y desde el servidor Hana lanzamos el siguiente comando:

SapBackintConfigTool --set-force-delete 

cli

¿te ha parecido interesante esta entrada? ¿te has encontrado algún problema configurando el agente de Veeam para Hana? Puedes dejarnos tus comentarios aquí.

 

Integración de correo Microsoft 365 en SAP, correo entrante

Integración de correo Microsoft 365 en SAP, correo entrante 939 449 SAPMiN

Como vimos en la entrada anterior, integracion-de-correo-microsoft-365-en-sap-correo-saliente, es posible configurar el correo saliente de SAP con Microsoft 365. En esta entrada trataremos el caso opuesto, configurando la integración de correo entrante Microsoft 365 en SAP.

Ésta casuística puede ser más complicada ya que pueden darse múltiples configuraciones, casi tantas posibilidades como entornos existan. Muchas de estas peculiaridades pueden suponer un reto a la hora de realizar una implementación sencilla.

Para ilustrar este post, vamos a basarnos en un caso con las siguientes premisas:

  • Correo corporativo en Microsoft 365
  • Un único dominio
  • Un entorno grande consolidado que busca el mínimo de cambios sobre la estructura actual
  • Conservación de todos los correos en las cuentas entrantes
  • Necesidad de reforzar la seguridad.

Visión general

Para la integración de correo entrante Microsoft 365 en SAP con este caso práctico, dado que Office recepcionará los correos entrantes y deben permanecer en las cuentas originales, deberemos indicarle cual y cómo es el destino al cual debe reenviar una copia de dichos correos.

Para ello generaremos una o más reglas y uno o más conectores según sean las necesidades. Habremos de tener en cuenta dos particularidades del entorno de correo:

  • Microsoft 365 solo enviará información al puerto 25 del destino del conector que definamos. En entornos unix no es recomendable utilizar puertos por debajo del 1024, por lo que utilizaremos el firewall para redirigir el tráfico, evitando así tener que enlazar puertos del sistema.
  • Microsoft 365 utiliza internamente el protocolo propietario TNEF (Transport Neutral Encapsulation Format), por lo que todos los correos enviados hacia uno de los dominios propios utilizará dicho protocolo salvo que se modifique. Puede desactivarse de forma global, pero dado que se va a intentar maximizar la compatibilidad y minimizar los cambios en la infraestructura ya existente, se llevará a cabo una alternativa.

Éstos puntos serán importantes en la solución que se va a proporcionar.

Entorno de Red

Como en la entrada anterior, el primer punto es configurar las conexiones, esta vez en sentido inverso. Debe permitirse el tráfico entrante que llegue desde Microsoft a nuestro entorno, denegando las que lleguen de cualquier otra dirección. Deberemos además redireccionar el tráfico entrante en el puerto 25 a nuestro sistema y puerto adecuado que definiremos más adelante (en este caso el puerto 25000).

Podemos ver las direcciones e ips de Microsoft aquí.

Perfiles, servicio SMTP y SAPConnect [incoming]

Deberemos configurar el parámetro para levantar un servicio SMTP con el arranque de SAP similar al siguiente:

Parametros

icm/server_port_X, donde X es un número correlativo para los servicios del ICM que hayamos definido.

En este parámetro estaremos indicando que se haga uso de un servicio smtp por el puerto 25000 con autenticación TLS/SSL.

El valor TLS especifica los posibles valores para el cifrado TLS usando STARTTLS. Los valores para este parámetro son:

  • 0: indica que no debe utilizarse
  • 1: se ofrece pero es opcional
  • 2: que su uso es obligatorio.

Tal y como indica Microsoft, esta última es la opción correcta.

Hay otros valores que podría ser interesante añadir como TIMEOUT y PROCTIMEOUT para limitar el  intervalo antes del timeout y tiempo de procesamiento respectivamente, que típicamente suelen ser valores entre 60 y 120 segundos. En caso de no indicarlos se tomará el valor por defecto del kernel que suele ser de 60.

Es necesario utilizar un puerto que no interfiera con otros ya activos, como los reservados para el sistema operativo. En entornos linux, si fuera necesario, podríamos utilizar la opción EXTBIND=1 para autorizar el uso de puertos dentro del rango <1024 (más info: 421359 – ICM: Binding ports < 1024 on UNIX), siempre y cuando no exista ya un servicio smtp activo en dicho puerto.

Para que estos parámetros tomen efecto deberemos reiniciar el ICM o directamente la instancia. Podremos ver los valores aplicados en la transacción SMICM → Pasar a → Servicios:

smicm

Una vez el parámetro está definido hay algunos campos que podemos modificar dinámicamente:

smicm2

smicm3

Podemos comprobar que el servicio se ha creado y responde con un telnet:

telnet2

Para poder recepcionar los correos desde SAP es necesario activar el servicio SAPConnect en la transacción SICF:

sapconnect

Una vez llegados hasta este punto el entorno SAP está listo para recibir emails, aunque aún deberemos hacérselos llegar.

Conectores y reenvíos Office 365

En este apartado las combinaciones son numerosas, podríamos reenviar a SAP todos los correos que lleguen a un buzón o solo aquellos con determinado asunto, etc.

Para una de estas posibilidades podemos crear un conector similar al siguiente en el centro de administración de Exchange → Flujo de correo → Conectores:

En la siguiente imagen podríamos, en caso de tener dos dominios, utilizar uno en exclusiva para el reenvío de correos a SAP, aunque en este caso dejaremos la elección del envío en manos de otras reglas:

Indicaremos la(s) IP(s) a la que se intentará realizar el envío, detrás de la cual tendremos el servicio SAP:

 

Con preferencia, y tal como hemos definido en el parámetro del servicio smtp, utilizaremos siempre la capa de seguridad TLS

Será preciso completar un test aunque sea incorrecto para poder avanzar y guardar el conector. Para ello pulsamos validar:

 

Y finalmente pulsamos en crear conector:

Podremos utilizar este conector para reenviar correos a través de él mediante reglas con mayor o menor complejidad. Por ejemplo, podemos crear una regla para que todos los correos enviados a una cuenta en concreto, se canalicen hasta SAP a través del conector:

regla

Es importante tener en cuenta que con dicha configuración estándar el correo no llegará al buzón, sino que será redirigido exclusivamente a SAP salvo error en el conector.

En caso de que quisiéramos que se mantuviera en el buzón, podemos crear una regla para que se envíe una copia dentro del propio buzón marcando la opción de conservar:

reenvio

Transacción SOIN

Podemos verificar los correos entrantes en la transacción SOIN.

Es probable que durante las pruebas iniciales queramos realizar traces a todos los correos entrantes para poder determinar su correcto enrutamiento. Podemos gestionar el uso del trace mediante la opción SOIN →Utilidades → Parametrizaciones de trace:

parametrosTrace

Es importante desactivarlo o activarlo sólo cuando recibamos errores para evitar más traces de los necesarios.

Podremos ver los traces en la transacción SOIN → Utilidades → Selección de trace.

Con ésto habremos terminado la integración de correo entrante Microsoft 365 en SAP. Opcionalmente conviene tener en cuenta el siguiente punto acerca de el formato TNEF.

Formato TNEF [opcional]

Por defecto Outlook, Ms Exchange y por extensión Office 365 utilizan el formato propietario TNEF (https://es.wikipedia.org/wiki/TNEF) siempre y cuando sea posible. Es posible Es probable que por ello nos encontremos con el inconveniente de que lleguen correos a SAP con adjuntos de tipo winmail.dat que nos será imposible tratar dentro del sistema. Dentro de este adjunto encontraríamos la información codificada en dicho formato pero no podremos hacer uso de ella.

Más info: https://support.microsoft.com/en-us/topic/how-email-message-formats-affect-internet-email-messages-in-outlook-3b2c0536-c1c0-1d68-19f0-8cae13c26722

Para abordar este problema Microsoft propone dos soluciones:

  1. Cambiar el formato para los contactos externos
  2. Cambiar el formato para los contactos de un dominio específico.

Más info: https://support.microsoft.com/es-es/topic/c%C3%B3mo-especificar-el-formato-del-mensaje-de-correo-electr%C3%B3nico-que-se-usa-para-los-destinatarios-externos-para-evitar-los-datos-adjuntos-de-winmail-dat-4a379475-1557-9554-ab72-91c5867afc11

Para poder aplicar cualquiera de las dos soluciones deberemos conectarnos a la PowerShell de nuestro Exchange Online:

https://docs.microsoft.com/en-us/powershell/exchange/connect-to-exchange-online-powershell?redirectedfrom=MSDN&view=exchange-ps

Instalamos el proveedor de paquetes a instalar

Install-PackageProvider -Name NuGet -Force Install-Module -Name PowerShellGet -Force 

Posershell1

Instalamos el módulo EXOV2, ExchangeOnlineManagement, que contiene un pequeño conjunto de cmdlets nuevos y optimizados para escenarios de recuperación de datos en masa (miles y miles de objetos).

Install-Module -Name ExchangeOnlineManagement

Posershell2

Modificamos la política para hacerla menos restrictiva:

Set-ExecutionPolicy RemoteSigned

Posershell3

Importamos los modulos:

Import-Module ExchangeOnlineManagement; Get-Module ExchangeOnlineManagement

Posershell4

Import-Module ExchangeOnlineManagement

Posershell5

Nos conectamos para poder operar:

 Connect-ExchangeOnline -UserPrincipalName <UPN> [-ShowBanner:$false] [-ExchangeEnvironmentName <Value>] [-DelegatedOrganization <String>] [-PSSessionOption $ProxyOptions] Connect-ExchangeOnline -UserPrincipalName correo_usuario_admin@...onmicrosoft.com

Posershell6

Esto nos abre una ventana de login y nos conectamos.

Finalmente configuramos nuestro exchange como mejor nos convenga.

¿Te ayudamos a configurarlo?

Nuevo formato de entradas SAP GUI

Nuevo formato de entradas SAP GUI 612 459 SAPMiN

A partir de la release 7.40 del SAPGui encontramos disponible un nuevo formato de entradas SAP GUI para gestionar la información de las conexiones con los diferentes sistemas SAP, el denominado SAP UI Landscape.

Esta nueva configuración es utilizada como estándar a partir de la versión SAPGui 7.50 en adelante.

Como podemos ver a continuación todos los ficheros de configuración de las versiones antiguas pasan a ser sustituidos por dos ficheros en formato xml:

SAP Gui < 7.40           SAP Gui >= 7.40
saplogon.ini             SAPUILandscape.xml
sapshortcut.ini          SAPUILandscapeGlobal.xml
SapLogonTree.xml
sapmsg.ini
saproute.ini

Estos ficheros se encuentran por defecto en la siguiente ubicación %APPDATA%\SAP\Common (por ejemplo C:\Users\usuario\AppData\Roaming\SAP\Common).

En caso de tener un SAPGui instalado en versiones anteriores, y pasar al nuevo formato, el propio programa recopilará todos los datos de los ficheros de configuración .ini y los transformará de forma automática al formato .xml estándar actual.

Edición del fichero de configuración

Tenemos varias alternativas para configurar las entradas a los sistemas, organizarlas en carpetas, crear favoritos etc:

◊ Modo tradicional: mediante el propio SAPGui

Como sucedía hasta ahora podemos incluir entradas directamente en el SAPGui

SAP GUI

El propio SAPGui generará toda la información necesaria en el fichero xml:

XML

Edición manual de los ficheros

Al tratarse de un fichero con formato xml, podemos editar su contenido mediante un editor de texto. En la imagen superior podíamos ver cómo es el detalle del formato de entradas SAP GUI  en el fichero editado generado.

Para que la edición sea correcta, serán necesarias las reglas de definición contenidas en el esquema XML SAPUILandscape.xsd contenido en la siguiente nota:

https://launchpad.support.sap.com/#/notes/2112449

Las etiquetas para definir los diferentes tipos de elementos/recursos dentro del fichero son estas:

Etiquetas XSD

Hay que poner especial atención en el hecho de que si necesitamos añadir una entrada o elemento nuevo, será necesario generar un uuid mediante algún generador externo como por ejemplo https://www.uuidgenerator.net/.

Transacción SLMT

Posiblemente esta es la opción más novedosa: poder editar el fichero XML directamente desde una transacción SAP SLMT (Landscape Maintenance Tool). Para poder utilizarla es necesario tener implementada en el sistema la nota 2311166, y tiene el siguiente aspecto:

Transacción SLMT

Mediante esta transacción podremos crear nuevos accesos a sistemas, nuevos elementos como entradas de saprouter, servidores de mensajes para grupos de logon, etc.

Esta herramienta también nos posibilitará adaptar las entradas de ficheros .ini de releases anteriores al formato actual, editar un xml adicional y consolidarlo con el contenido de nuestro .xml actual, etc:

Transacción SLMT

Distribución de los ficheros xml

Una vez que tengamos definidos los ficheros xml con todas las entradas necesarias, podremos seguir algunas de las siguientes estrategias para hacerlos accesibles a los diferentes usuarios según nuestras necesidades:

  1. Ficheros locales:los ficheros de configuración se guardarán de forma local en el equipo del usuario.
  2. Ficheros en recursos compartidos: podremos compartir en una ubicación de red el fichero con los permisos adecuados para que los usuarios puedan hacer uso de ellos. Por seguridad lo publicaremos con acceso de sólo lectura para restringir la edición de las entradas a usuarios administradores. Para poder utilizar esta estrategia será necesario definir la variable de entorno SAPLOGON_LSXML_FILE con el valor del Path y nombre del fichero xml.
  3. Ficheros en recurso web: Es posible publicar los ficheros xml en un servicio web de tipo http://servidor:puerto/config/SAPUILandscape.xml y configurar el SAPGui para que haga uso de dicho recurso. Adicionalmente añadiremos la url del fichero xml como valor en la varaible CoreLandscapeFileOnServer en la entrada del registro de Windows
    HKEY_LOCAL_MACHINE\SOFTWARE\SAP\SAPLogon\Options en versiones de 32 bit 
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SAP\SAPLogon\Options en versiones de 64 bits
    

    También podemos utilizar la nueva variable de entorno SAPLOGON_LSXML_FILE para indicar la ubicación sin modificar el registro.Conviene destacar, que dentro de SAPUILandscape.xml podemos indicar la ubicación de otros ficheros, con lo que podríamos modificar, por ejemplo, la ubicación de SAPUILandscapeGlobal.xml. Conviene que ambos estén apuntando en la misma dirección para evitar quebraderos de cabeza:

    SAPUILandscapeGlobal.xml en APUILandscape.xml mediante Include

Las dos últimas opciones nos permitirán realizar una gestión centralizada de todos los cambios. En estos casos es interesante activar la opción ‘Allow caching of server configuration files’. De esta forma, los ficheros de configuración quedan cacheados ante un eventual problema con los centralizados. Adicionalmente podemos reflescarlos en cada reinicio o cada cierto intervalo de horas:

SAP GUI Options, allow caching

Podemos encontrar mucha más información de éstas y otras opciones en las guías de administración de SAPGui:

https://www.sap.com/documents/2017/07/883c670b-c97c-0010-82c7-eda71af511fa.html

Esperamos que esta información os haya servidor de ayuda.

¿os habéis encontrado algún problema con el nuevo formato XML del SAPGui? Déjanos tus comentarios abajo o a través de nuestro correo, te ayudaremos encantados.

 

Integración de correo Microsoft 365 en SAP, correo saliente

Integración de correo Microsoft 365 en SAP, correo saliente 939 449 SAPMiN

Microsoft 365, antes Microsoft Office 365, es un conjunto de herramientas que nos permite crear, acceder y compartir a documentos tanto en un entorno local como en la nube, gestión de correo electrónico, etc. entre muchas otras posibilidades.

La integración del correo Microsoft 365 en SAP es una de las formas en las que ambas suites interactúan.

En la siguiente nota (722513 – Desktop Office Integration: Maintenance information) podréis encontrar más información al respecto.

La integración del correo saliente Microsoft 365 en SAP no es un proceso complicado y con Microsoft 365 no difiere mucho de otras alternativas. En esta entrada trataremos el correo saliente y dejamos para una futuro el correo entrante. La configuración del correo saliente es notablemente más sencilla que la del entrante:

Configuración de red / conectividad

El primer paso es asegurarnos de que tenemos acceso desde SAP al servidor smtp.office365.com.

Desde el propio servidor SAP podemos realizar ping y telnet a dicha dirección y puerto 587, y con ello comprobaremos si accedemos correctamente. En caso de no tener éxito habrá que revisar los diferentes elementos de red que intervienen en esta comunicación.

telnet

Nodo de salida a Office 365

Para definir un nodo de salida deberemos ir a la transacción SCOT y definir un nodo de tipo SMTP que enviará los e-mails a través del host smtp.office365.com en el puerto 587.

scot

Como se muestra en la imagen de arriba es necesario indicar en el apartado SMTP Connection → Security la opción más restrictiva: TLS obligatorio. El resto de opciones no funcionarán o podrían presentar problemas, por lo que no es aconsejable su uso.

Dentro de las opciones (SMTP Connection → Settings) del nodo recién creado recomendamos activar las siguientes dos opciones:

  • Check Host Name
  • Check Server Certificate

De esta forma se comprobarán el nombre del servidor de correo y el certificado con el que se autentique. El hecho de utilizar esta última opción nos ofrecerá permitirá indicar el contenedor PSE en el que albergaremos el certificado que debemos aceptar de Microsoft. Indicaremos el contenedor SSL Client por defecto en el campo Client Identity, donde posteriormente importaremos dicho certificado.

Por último, deberemos indicar un usuario y contraseña de una cuenta válida dentro del servicio Microsoft 365.

scot2

Es importante destacar que la cuenta de usuario que hayamos definido en la imagen anterior será la emisor de los correos. Si queremos cambiar el emisor de los mails por otra cuenta diferente, por ejemplo la de un usuario final, la primera cuenta deberá tener permisos para enviar correos en nombre de la segunda dentro de Microsoft 365.

Certificados de seguridad

Una vez definido que debe aceptarse el certificado del servidor, debemos incluir dicho certificado o el de las entidades que lo generen en la transacción STRUST dentro del contenedor pse que hemos definido. De lo contrario veremos en los traces del ICM aparecer errores de certificado cada vez que tratemos de enviar un correo y dichos correos no llegarán al destinatario.

Podemos obtener el certificado del servicio SMTP de Microsoft 365 ejecutando el siguiente comando:

openssl s_client -starttls smtp -showcerts -connect smtp.office365.com:587 -servername smtp.office365.com | openssl x509 > o365.cer

Tras ello abriremos el contenedor definido en el punto anterior, cargaremos el certificado y lo incluiremos en la lista de certificados admitidos, guardaremos y distribuiremos. En función de la versión es posible que sea necesario reiniciar el ICM.

strust

 

Cuentas de correo

En la transacción SU01 podemos añadir/modificar la cuenta de correo de cada usuario. Si la cuenta coincide con la del servidor Microsoft 365 no habrá problema.

No obstante es muy habitual que cada usuario tenga su propia cuenta. En ese caso podemos encontrarnos con errores como el siguiente en la SOST:

ErrorRelay

o en los traces del ICM:

Error_relay

Este problema se debe a que la cuenta de correo definida para el usuario SAP, en la transacción SU01, no tiene permiso para enviar correos en nombre de la que hayamos definido en la transacción SCOT. Debemos entonces asignar estas autorizaciones desde el centro de administración de Microsoft 365. Puede hacerse de forma global mediante comandos PowerShell o manualmente para cada usuario/buzón compartido. Hay que tener en cuenta que no es válido para grupos de Microsoft 365. Para ello seleccionamos un usuario y editamos sus opciones:

buzon_office365

Y añadimos la cuenta definida más arriba en el apartado de autenticación de la TX SCOT:

Delegacion_buzon

Con ésto ya estaría el sistema listo para enviar correos desde SAP haciendo uso del servicio Microsoft 365.

Resumen

En apenas unos pocos pasos hemos configurado la integración del correo saliente Microsoft 365 en SAP con seguridad TLS y comprobación del certificado.

Próximamente configuraremos el correo saliente.

Instala parches en Netweaver Java sin utilizar SUM

Instala parches en Netweaver Java sin utilizar SUM 419 290 SAPMiN

Instala parches en Netweaver Java sin utilizar la herramienta SUM

Es muy posible que se os haya presentado en alguna ocasión la circunstancia de tener que instalar un parche para, por ejemplo, subsanar una vulnerabilidad de seguridad en un entorno Java, como el Solution Manager, el portal, etc. y que hayáis pensado en el esfuerzo que tiene hacerlo mediante el SUM (Software Update Manager) de SAP, y se os hayan pasado las ganas de actualizar nada. Si es así, la entrada de hoy os será de gran utilidad.

Hagamos un poco de memoria: a lo largo del año 2013, ha llovida bastante ya, SAP dejaba de soportar la instalación de parches en los entornos J2EE mediante el JSPM. Esta herramienta permitía, por ejemplo, instalar parches individuales de forma rápida y efectiva, mediante unos pocos clicks. De 2013 en adelante la herramienta “obligada” para las actualizaciones es la SUM.

Esta decisión provoca que cualquier actualización dentro de una instancia Java, ya sea un parche, ya sea un sp-stack completo, se eternice, y nos haga pasar a través de un montón de pasos, como si de un upgrade se tratara.

Además del Java Support Tool, que hablaremos en otro post, os presentamos una forma más directa aún de instalar los parches de forma manual, a través de telnet. Adelante, manos a la masa!

Lo primero de todo, como es costumbre, consistirá en asegurar que tenemos un backup de la BBDD por si acaso. Seguidamente descargamos el parche en cuestión:

Por supuesto, deberemos comprobar si existe alguna dependencia de otros componentes y/o versiones de parches. En caso afirmativo los descargaremos, y volveremos a verificar sus posibles dependencias de forma recursiva, hasta asegurar que contamos con todos los parches necesarios para que el update sea consistente:

A continuación subimos los parches a una carpeta del servidor

Creamos un fichero .txt que contenga el nombre y la ruta absoluta de los parches que vamos a instalar, por si acaso los ponemos en el orden exacto en el que los queremos importar:

Nos conectamos a la consola de administración vía telnet a la dirección localhost 5xx08, donde xx es el número de instancia de la pila Java y hacemos login con el usuario administrador

Listamos los nodos disponibles con el comando lsc, y nos dirigimos a uno de ellos con la instrucción jump id_nodo, lanzamos el comando add deploy y por último ejecutamos:

deploy list=unidad:\usr\sap\XXX\tmp\parches\parches.txt version_rule=all on_prerequisite_error=stop donde el parámetro list se corresponde con la ruta absoluta al fichero que hemos generado en el paso anterior, y que contiene las rutas absolutas a los ficheros de todos los parches que queremos instalar.

En caso de que alguno de los componentes tenga que desplegarse en modo offline, se desconectará la sesión de telnet. Nos volveremos a conectar de nuevo, una vez esté levantada y disponible la instancia, y lanzaremos el comando get_result para comprobar la finalización del proceso.

Verificaremos que todos los componentes se han actualizado adecuadamente:

En ocasiones nos hemos encontrado, sobre todo en entornos Windows, que al realizar el despliegue de tipo offline, la pila Java no levanta pasado un tiempo, cuando debería hacerlo para finalizar la actualización. En estos casos habrá que revisar los logs de los procesos principales para determinar la causa del problema.

¿os habéis encontrado algún inconveniente al utilizar este u otros métodos de actualización?

Déjanos tus comentarios aquí 😉

Fin de soporte para varias versiones SAP Netweaver

Fin de soporte para varias versiones SAP Netweaver 1331 738 SAPMiN

Fin de soporte para algunos sistemas Netweaver

A inicios de este año, SAP anunció por una parte la ampliación del soporte hasta 2030 del ERP, y por otra el fin de soporte de algunas instalaciones basadas en Netweaver.

En concreto, las releases que dejarán de tener soporte a partir del 31 de diciembre de 2020 son estas:

  • NetWeaver ABAP 7.10
  • NetWeaver ABAP 7.11
  • NetWeaver ABAP 7.20
  • NetWeaver ABAP 7.30
  • NetWeaver Java 7.10
  • NetWeaver Java 7.11
  • NetWeaver Java 7.20
  • NetWeaver Java 7.30
  • NetWeaver Java 7.31
  • NetWeaver Java 7.40

Recordemos además que las siguientes versiones están fuera de soporte desde finales del 2017:

  • NetWeaver Java 7.00
  • NetWeaver Java 7.01
  • NetWeaver Java7.02
  • NetWeaver Java 7.03

Para todas estas versiones no se ofrecerá soporte extendido, y por tanto será obligatorio realizar un upgrade de versión.

Es importante destacar que estas fechas afectan a productos como el Enterprise Portal, Business Warehouse, Process Integration, Solution Manager, etc. basados en las releases indicadas.

 

Versiones soportadas

En caso de contar con un sistema en una de las versiones enumeradas anteriormente, deberemos tener en cuenta las siguientes fechas y releases a la hora de llevar a cabo la actualización de los entornos:

Sistemas Netweaver ABAP

Fin de soporte estándar fijado el 31.12.2025, no se prevé soporte extendido.

– Netweaver 7.00

– Netweaver 7.01

– Netweaver 7.02

– Netweaver 7.51

Fin de soporte estándar fijado el 31.12.2027, con soporte extendido hasta 2030.

– Netweaver 7.03

– Netweaver 7.31

– Netweaver 7.4

– Netweaver 7.5

– Netweaver 7.52

Sistemas Netweaver Java

Fin de soporte estándar fijado el 31.12.2027, con soporte extendido hasta 2030.

– Netweaver 7.5

 

Aplicaciones principales Business Suite 7

En cuanto a las aplicaciones core de la Business Suite 7, tendrán un soporte estándar que se alargará hasta finales de 2027. Entre estas soluciones se encuentran las siguientes:

  • SAP ERP 6.0
  • SAP CRM 7.0
  • SAP SCM 7.0
  • SAP SRM 7.0

Todos los respectivos paquetes de mejora o EHPs están incluidos dentro del soporte estándar.

Por último, es importante destacar que las fechas futuras de fin de soporte fijadas en los años 2025, 2027 y 2030 son susceptibles de ser ampliadas, y muy posiblemente sufrirán cambios en las condiciones que las hagan efectivas.

En SAPMiN podemos ayudarte a actualizar todos tus sistemas SAP, ¿hablamos?

Si tienes cualquier duda, déjanos aquí tus preguntas o comentarios.

sapgui_fondo_rojo

SAPGui: Asignar diferente color de fondo para cada entorno

SAPGui: Asignar diferente color de fondo para cada entorno 761 285 SAPMiN

Problemática

Estás trabajando en SAP, con conexiones a varios sistemas diferentes, y con unos cuantos modos en cada una de ellas, y de repente, lanzar una transacción/acción en uno de ellos, y te das cuenta de que lo has hecho en la instancia equivocada.

Comienzas a borrar una serie de datos, cuando de repente ves que lo estás lanzando en producción, cuando creías que lo estabas haciendo en el entorno de calidad.

¿te suenan estas situaciones? ¿te han sucedido en alguna ocasión?

Solución

A continuación te enseñamos un pequeño truco que seguramente te será de gran ayuda. Desde hace ya unas cuantas versiones de SAPGui es posible asignar a cada sistema un color de fondo determinado, de tal forma que podemos configurar el entorno productivo un color de fondo rojo por ejemplo, que nos alertará cada vez que pongamos el foco en un modo correspondiente a este sistema.

Para activar esta configuración basta con hacer login en el sistema deseado y abrimos el botón de opciones del SAPGui que tiene este icono   sapgui_options

y pulsaremos Options. A continuación se desplegará una ventana, y deberemos selección el siguiente path:

Visual Design → Color settings → Colours in System

Como podemos apreciar en la imagen anterior, tenemos unos cuantos colores para elegir. Por si fuera poco, la configuración de diferentes no sólo es aplicable a un sistema, sino que es posible definir diferentes colores para cada mandante en cada uno de los sistemas.

Por ejemplo, configuramos en color rojo para el fondo del entorno de producción, y observamos los resultados:

sapgui_fondo_rojo

Los diferentes temas del SAPGui nos ofrecen una amplia gama de posibilidades. Por ejemplo, seleccionando el tema Enjoy es posible elegir entre los siguientes colores o combinaciones:

Recordatorio: Como de costumbre os recomendamos actualizar la release del SAPGui a la última versión soportada, y con un parche lo más reciente posible. Actualmente sólo se encuentra soportada para Windows la versión 7.60, y la 7.50 en su modalidad Java. Podemos encontrar el roadmap para este componente en la siguiente nota:

147519 – Maintenance strategy / deadlines for SAP GUI for Windows / SAP GUI for Java

Esperamos que este pequeño truco os sea de utilidad y que nadie vuelva a equivocarse de sistema al lanzar las tareas 🙂

¿tienes alguna duda? Si podemos ayudarte no tienes mas que contactar con nosotros a través del siguiente enlace.

Content Server 7.5 ¿qué hay de nuevo?

Content Server 7.5 ¿qué hay de nuevo? 848 210 SAPMiN

Hace un par de semanas SAP liberó la última versión del gestor de contenidos Content Server, en concreto la versión 7.53. Es importante destacar que a pesar de que la versión 6.50 estará soportada hasta 2025, desde finales de 2018 no se han vuelto a liberar parches para dicha versión:

Content Server SW

Por tanto, es altamente recomendable ir pensando en actualizar a la nueva versión.

¿Qué novedades nos encontramos?

  • Una de las principales características que encontramos es que ya no se requiere de los servidores web Apache ni IIS, sino que está basada en el propio Web Dispatcher de SAP.
  • Otra novedad importante es que la instalación del Content Server pasa a ser considerada como una instancia más, con su propio SID y número de sistema, y está integrada dentro del landscape de instancias habitual: se puede gestionar mediante la consola MMC o sapcontrol, se puede interconectar con el Solution Manager, etc.
  • Ligado al punto anterior, durante la instalación se generarán los clásicos usuarios de instancia sidadm y SAPServiceSID.
  • El nombre de los scripts del CS han sido renombrados de ContentServer/ContentServer.dll a sapcs.
  • El contenido de las entradas en el fichero de log pasan a contener por defecto los valores de timestamp, url completa, duración de la operación, etc, para un análisis más completo en caso de problemas y durante un espacio de 7 días.
  • Permite definir un nivel de trace diferente para cada repositorio albergado.
  • En esta nueva versión encontramos una herramienta de gestión gráfica del Content Server a través de navegador web, que nos permitirá parar y arrancar la instancia, revisar logs y traces, accesible a través de la url https://<hostname>:<puerto HTTPS>/sap/admin.
  • Optimización de recursos HW: CPU y RAM.
  • Soporte a documentos de tamaño superior a 4G (2856736 – SAP Content Server 7.5: Support for large documents)

Requisitos de instalación Content Server 7.53

  • Un espacio mínimo de 4GB para la instalación del software
  • El espacio necesario para albergar la BD teniendo en cuenta los datos del sizing
  • Una arquitectura de procesador de 64 bits con al menos 2 cores
  • Memoria RAM de al menos 2GB
  • Memoria SWAP de al menos 2*RAM + 4GB
  • Versión Linux: SuSE SLES 11 o superior, Red Hat 6 o super
  • Versión Windows: W2008 R2 o superior
  • Release de SAP 4.5B o superior

Actualización de una instalación previa

Debido a la nueva arquitectura del Content Server ya no es posible realizar una actualización tipo in-place y es necesario realizar una nueva instalación del servicio y librerías, pero esto no afecta a los datos ya almacenados.

Pasos para la actualización/instalación

Estos son los pasos que deberemos realizar para actualizar un Content Server en versiones inferiores o instalar uno nuevo:

Paso 1: Crear una nueva instalación de Content Server

Si vamos a instalar una instancia del Content mediante el SWPM. Necesitaremos descargar:

Una vez descomprimido el fichero del SWPM, lanzamos el ejecutable del SAPinst y elegimos la opción: Generic Options → SAP Content Server → SAP Content Server and SAP Cache Server (7.5 and later)

Instalaremos la instancia del Content Server según los parámetros requeridos.

Paso 2: Migrar la configuración original (sólo actualización)

A pesar de que el formato general del perfil de las instancias de Content Server no ha cambiado, algunos de los parámetros anteriormente utilizados se han convertido en obsoletos.

Los ficheros de configuración anteriores pueden copiarse al directorio de perfiles de la nueva instancia (/usr/sap/SID/SYS/profile), o simplemente adaptar los nuevos con el contenido original. El nombre del fichero de configuración por defecto será cs.conf

Para adaptar los parámetros originales y eliminar los obsoletos, deberemos consultar la nota 329473 – Description of Content Server and Cache Server configuration file y las secciones 5 y 6:

Detalle Nota 329473

En caso de provenir de versión CS 6.40 o inferior es necesario aplicar la nota 2141940 – Database Repositories adjustment when upgrading from SAP Content Server 6.4 to 6.5 and up (including CS 7.53)

Paso 3: Parar CS original y arrancar la nueva instancia (sólo actualización)

Deberemos para la instalación del Content original, ya sea parando el servicio Apache o IIS.

Seguidamente y con el usuario sidadm generado en el paso 1, iniciamos la nueva instancia del CS utilizando los comandos sapcontrol.

Paso 4: Verificar la instalación

Utilizaremos los reports RSCMSTH0, RSCMSTH1 y RSCMSTH2 para comprobar que el nuevo Content está funcionando correctamente.

De forma adicional probaremos a almacenar nuevos documentos y recuperar los ya existentes.

Podemos acceder a la información del estado de la instancia mediante la url:

http://<hostname>:<port>/sapcs?serverInfo

Paso 5: Borrado de la instalación original (sólo actualización)

Para evitar una posible colisión entre las diferentes versiones del Content Server se recomienda eliminar la instalación previa.

Paso 6: Configuración de conexión cifrada con SSL

Como paso opcional pero recomendado, configuraremos la conexión cifrada con nuestro ERP. Para ello exportaremos con el usuadio sidadm del Content Server el certificado de seguridad con el comando sapgenpse, lo importamos en la TX STRUST de nuestro ERP, y en la TX OAC0 configuramos la conexión https para todos los repositorios.

Esperamos que esta información os haya servidor de ayuda.

¿ya os habéis decidido a actualizar a la nueva versión?

¿os habéis encontrado algún problema en el proceso de instalación o actualización?

Déjanos tus comentarios y te responderemos encantados.