Trucos

Categories, unlike tags, can have a hierarchy.

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í 😉

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.

Renovación de certificados entre SCC y SAP Cloud Platform

Renovación de certificados entre SCC y SAP Cloud Platform 1280 720 SAPMiN

SAP Cloud Platform

SAP Cloud Platform es una plataforma como servicio desarrollada por SAP SE en línea con las tendencias actuales de cloud computing.

Permite extender las capacidades de aplicaciones, procesos de negocio, integraciones, etc para un sinfín de escenarios, tanto cloud como on-premise. Y todo ello con estándares abiertos.

SAP Cloud Connector

SAP Cloud Connector es un agente que sirve de unión entre aplicaciones en la plataforma cloud y aplicaciones on-premise con capacidades de alta disponibilidad y seguridad. Debe instalarse on-premise haciendo las veces de saprouter (y mucho más) y evitando proxies inversos, DMZs, o reglas complejas en firewalls.

Consume muy pocos recursos y puede conectar múltiples entornos a la vez, incluidos entornos no SAP. Existe versión para Microsoft Windows, GNU/Linux, Mac OS e incluso también una versión portable.

SCC permite varias configuraciones relacionadas con la seguridad según sean las necesidades del entorno que conviene conocer y ajustar.

La primera de ellas y muy recomendable es modificar antes que cualquier otra cosa es la contraseña de acceso al servicio.

Por defecto, la contraseña de SCC viene hardcodeada en local en el fichero config\users.xml

config\users.xml

No estará presente en texto plano sino su hash mediante sha1 o sha-256. En este último caso tendrá el valor password=”181229424893BB65D94A74C2132B8B9E5ADFE851464FDB5CB9F49E8A8204BE7B” que se corresponde con la contraseña manage. Y que puede ser utilizado para resetear la contraseña al valor por defecto.

Hash de la contraseña

Por lo que una de las primeras cosas que debemos hacer es cambiar dicha contraseña y restringir el acceso al fichero. Aunque una función hash no es reversible, no hay que olvidar que puede ser comparada contra un diccionario. SCC nos permite también habilitar el acceso al servicio mediante el LDAP de nuestra organización, agregando una capa más de seguridad.

Configuración inicial

Como con cualquier servicio web, es recomendable (más bien necesario) configurar certificados SSL/TLS para evitar que la información viaje en texto plano y pueda ser interceptada mediante un sniffer o en un ataque mitm.

En este punto podemos hacer uso de una entidad autofirmada que gestionemos nosotros mismos para aprobar el request certificate generado en el servicio.

Éste certificado (User Interface), una vez firmado, puede ser reutilizado por el propio sistema para otros propósitos. O viceversa, el certificado de sistema puede ser reutilizado para el interfaz.

Certificados entre Cloud y onPremise

Además de estos certificados, que son los más evidentes, hay otro que pasa desapercibido y es el que desencadena esta entrada, son los certificados entre SCC y SAP Cloud Platform

Con la versión SCC 2.12.2 ha llegado una pequeña característica que echábamos en falta. Y es que, a partir de esta versión se muestra la caducidad del certificado que cifra la conexión entre el entorno cloud y on-premise. Así que, si tu versión es anterior, te recomendamos que la actualices.

Si no es así y todavía continúas con una versión antigua es probable que ya te hayas encontrado con el inconveniente de tener que renovarlo cuando te enterabas de que fallaban las aplicaciones o veías que se había perdido la conectividad en las subcuentas de SAP Cloud Platform Cockpit.

El error puede verse tanto en el apartado Alerting del SCC como en SAP Cloud Cockpit, ya que se muestran como desconectados o con un error 401 Unauthorized.

O en los traces del servicio:

Traces!

La solución es sencilla, basta con actualizar el certificado y habremos resuelto el problema durante un año:

Certificado

Nos pedirá que introduzcamos la contraseña del usuario con el que se establece la comunicación. Volveremos a ver como se restablece la comunicación entre ambas partes y se muestra correctamente:

Certificado renovado

Podemos enviar las alertas por correo para prevenir futuros problemas.

En esta pantalla, en las nuevas versiones, se muestra además la validez del certificado. Pero para las versiones antiguas también es posible conocerlo. Si analizamos la estructura de carpetas podemos ver que las subcuentas conectadas almacenan diversos ficheros de configuración (xml, ini) en scc20\scc_config\hana.ondemand.com\<subaccount>\ que identifican el frontend y el backend y sus puertos expuestos.

Vemos además un fichero un repositorio de certificados de seguridad llamado scc.jks.

SCC tiene como prerrequisito JDK, por lo que podremos utilizar la herramienta keytool incluida en ella para explorar el contenido y con ello averiguar la caducidad del certificado con el que se cifrará la comunicación entre SCC y Cloud.

Para ello ejecutamos: keytool -list -v -keystore scc.jks. Por defecto no hay que proporcionar ninguna contraseña:

keytool info

Keytool info 2

En las imágenes superiores podemos ver que en el almacén se guardan el certificado de la entidad con la que SAP firma sus certificados y el certificado que acabamos de renovar, habiendo desaparecido la versión anterior.

Sencillo, ¿verdad?

Datos a medida en entornos cloud (SAP IAS)

Datos a medida en entornos cloud (SAP IAS) 857 392 SAPMiN

El origen, SAP Identity Authentication Service

Hace unos días nos encontramos con la necesidad de conocer el grado de madurez de una implantación. En la comunidad de usuarios de un entorno dado era un dato importante para averiguar la tasa de errores total sobre el parcial recogido en una casuística de problemas concretos. Es decir, dado un censo de usuarios, conocer el parcial de los que hacían uso de la nueva estructura implantada y cotejarla con los errores para conocer si era un buen ratio o por el contrario debía mejorar. En este caso necesitábamos hacer una extracción de datos a medida de un entorno cloud con SAP Identity Authentication Service.

El reto era obtener una medición concreta que fuera objetiva e independiente de la percepción de los usuarios.

Con los datos obtenidos, posteriormente analizarlos en función de diversos atributos para estudiar las áreas de mejora y la estrategia en caso necesario. Así como obtener una muestra representativa de usuarios clave.

usersCloudMonth

En el caso actual, las herramientas estándar de la plataforma SAP Cloud Platform ofrecen una información global que no era de utilidad a la hora de realizar la medición. Servían para un uso comparativo a lo largo del tiempo pero no para descartar los problemas ya que no se disponían de datos previos efectivos.

Más en concreto, el servicio de autenticación Identity Authentication Service es una plataforma de identificación segura SSO para usuarios en la nube SAP. Permite autenticar usuarios mediante usuario y contraseña, LDAP corporativos, social sign-on, TFA, etc, para dar acceso a múltiples aplicaciones en la nube, entre otras características.

Es también un punto centralizado donde se guardan datos de acceso de usuarios que habían hecho uso de la nueva plataforma. Y los datos que necesitábamos estaban allí a la espera de ser recogidos para su análisis. A veces diseminados a lo largo de las múltiples pantallas y a veces agrupados de una forma que no era práctica para la necesidad puntual

La idea, cURL

De entre todas las opciones posibles, una fue especialmente interesante dada la sencillez y efectividad. Y es que las herramientas de siempre, lo son a menudo gracias a su efectividad.

Básicamente la idea fue extraer los datos mediante curl y analizarlos según la medición a investigar.

Curl es un proyecto de software que proporciona una librería, libcurl, y un comando curl, que es el que emplearemos. Es ampliamente utilizado en scripts para transferencia de datos o automatizar procesos y está presente en multitud de ámbitos y dispositivos del día a día aunque a menudo no lo veamos. Soporta infinidad de protocolos (ftp, http, ldap, pop3, sus variantes seguras y muchos otros)

Hace menos de dos años que curl fue incluido en windows, en la versión w2010. Algo que acerca un poco más el escenario de windows a linux. Para quien tenga un especial interés: Guía de instalación del Subsistema de Windows para Linux para Windows 10

Cabe decir que también hubieran valido otros clásicos como wget.

La ejecución

Así que nos pusimos manos a la obra. Lo primero era averiguar la proveniencia de los datos. Para eso con las herramientas de desarrollo de casi cualquier navegador y un poco de conocimiento de HTML y de análisis del tráfico es fácil el origen del cual debían de provenir dichos datos.

En este caso de ejemplo, inmediatamente después de acceder a la aplicación, podemos ver el origen de los datos analizando el tráfico con el navegador:

AnalisisRed

En función del navegador podemos copiar la llamada como cURL o la dirección y datos necesarios como usuario, cookie a reutilizar, etc. Con esta información y curl, podemos dar forma a las direcciones que debemos consultar para obtener la información que necesitábamos:

En este caso obtendremos el resultado de los datos de un usuario en concreto, pero es fácilmente extensible para obtener los de todos los usuarios en una única ejecución.

Con los datos obtenidos utilizamos nuestra herramienta preferida para hacer un informe, excel, qlikview, gráfico, etc. a medida. O incluso dentro de de nuestro sistema de monitorización preferido: Nagios, Pandora FMS.

En este caso la tasa de usuarios con errores reportados para la población total de los mismos según la fase de la implantación era el dato más relevante:

Aunque las posibilidades son amplias:

¿Hablamos?

Resetea las opciones por defecto de las ALVs

Resetea las opciones por defecto de las ALVs 403 216 SAPMiN

Posiblemente te sientas reconocido en la siguiente situación: generas un listado en SAP y el resultado es una pantalla con una ALV, con un aspecto similar a esta:

Ahora pulsamos la opción de exportar a Excel por ejemplo, y obtenemos la siguiente pantalla:

Aquí es cuando viene el problema, y es que si marcamos la opción de Always Use Selected Format este cuadro de diálogo no volverá a aparecer, y mantendremos esta opción para el fin de nuestros días.

¿qué hacemos ahora?

Muy sencillo, lo primero que vamos a hacer es activar la traza de nuestro usuario en la TX ST01, usando como filtros el id de nuestro usuario y las actividades de tipo SQL, repetimos los pasos descritos anteriormente, y finalmente analizamos los resultados.Verificamos que una de las tablas que utiliza es la SALV_CSQ_PARAMS, y bingo!

Hemos encontrado la tabla que almacena la configuración de los ALVs de las diferentes pantallas para cada usuario.Encontramos que la tabla tiene el siguiente contenido:

¿y cómo reseteamos estas opciones?

Pues bien, tenemos dos alternativas:

  • borrar las entradas a mano directamente de la tabla SALV_CSQ_PARAMS
  • utilizar el report SALV_BS_ADMIN_MAINTAIN, que nos permitirá modificar y/o borrar las propiedades por defecto de ALVs tradicionales y ALVs en Webdynpros:

Una vez seleccionada la opción concreta, vemos que se muestran las parametrizaciones relativas a nuestro usuario:

Como podemos ver en la imagen anterior, tenemos opción de crear una preferencia nueva, modificar las ya existentes, o borrarlas directamente.

Si optamos por borrar la entrada, el sistema nos volverá a preguntar el formato u opción que queremos utilizar.

Esperamos que este pequeño truco os haya podido ayudar.

¿te has encontrado alguna preferencia que no has podido volver a modificar? Cuéntanoslo 😉

Configuración de nuevos accesos a SAP Support Backbone

Configuración de nuevos accesos a SAP Support Backbone 1280 553 SAPMiN

Debido a la reciente actualización de la infraestructura con la que SAP presta soporte a sus clientes, denominada Support Backbone, ha cambiado la operativa y tecnología de conexión de los sistemas con SAP. Los cambios más significativos son:

  • Las comunicaciones pasan de ser de tipo RFC ABAP a RFC https cifradas
  • Los usuarios de conexión dejan de ser genéricos a ser technical users nominales ligados a la instalación de cada cliente
  • Se hace uso de notas y ficheros firmados digitalmente

Por ello, y antes del 1 de Enero de 2020 es necesario actualizar la forma en la que nuestros sistemas SAP se conectan con este soporte. En este artículo describiremos los principales pasos para llevar a cabo la configuración necesaria.

¿A qué sistemas afecta el cambio?

Es necesario asegurar las comunicaciones con la nueva plataforma de soporte para los siguientes entornos:

  • Solution Manager
  • Sistemas con acceso para descarga de notas (normalmente entornos de desarrollo)
  • Instancias que envía datos de Early Watch Alert a SAP (habitualmente productivos)

En general, y por consistencia, recomendamos que la nueva configuración se replique en todas las instancias SAP, dado que será necesario actualizar parches e importar correcciones de notas.

Pasos para configurar los nuevos accesos:

1. Pedir un nuevo technical user

Es necesario contar con al menos un technical user para conectar vía https con los sistemas de soporte del backbone. Este tipo de usuario es de tipo no interactivo, y cuenta con los permisos necesarios para gestionar el intercambio de información con el soporte de SAP.
Podemos crear o gestionar este tipo de usuarios en el siguiente enlace.

2.Actualización de add-ons ST-PI y ST-A/PI

Para evitar cualquier tipo de problema es imprescindible actualizar los add-ons ST-PI y ST-A/PI a la última release y nivel de parche liberados. A día de hoy los más recientes son estos:

Actualización de add-ons ST-PI y ST-A/PI 1/2

Actualización de add-ons ST-PI y ST-A/PI 2/2

3.Habilitar conexiones de red

Es necesario habilitar las siguientes conexiones de red para garantizar el acceso desde los sistemas SAP al backbone de SAP:

  • apps.support.sap.com, puerto 443
  • documents.support.sap.com, puerto 443
  • notesdownloads.sap.com, puerto 443
  • softwaredownloads.sap.com, puerto 443
4.Configurar parámetro ssl/client_ciphersuites

En cada sistema configuraremos el parámetro ssl/client_ciphersuites con los siguientes valores recomendados en la transacción rz10 y reiniciaremos la instancia para que los cambios sean efectivos:

  • 918:PFS:HIGH::EC_P256:EC_HIGH para sistemas Solution Manager
  • 150:PFS:HIGH::EC_P256:EC_HIGH para sistemas no Solution Manager
5.Import de certificados de seguridad

En cada uno de los sistemas deberemos importar los siguientes certificados de seguridad, que pueden descargarse de la nota 2631190:

  • VeriSign Class 3 Public Primary Certification Authority – G5
  • DigiCert Global Root CA
  • DigiCert Global Root G2
  • DigiCert High Assurance EV Root CA

Nos dirigimos a la transacción STRUST, e importaremos estos cuatro certificados tanto en el contenedor Cliente SSL anónimo como en el Cliente SSL anónimo.

6.Configuración de conexiones

A continuación procederemos a configurar las nuevas conexiones. Lo primero de todo será revisar si es aplicable, dependiendo de la release de nuestros sistemas SAP, la nota 2827658. En caso afirmativo la implementaremos siguiendo las instrucciones detalladas en dicha nota.
Posteriormente nos dirigiremos a la transacción STC01 y ejecutamos la tarea SAP_BASIS_CONFIG_OSS_COMM

Configuración de conexiones 1/2

En el paso 4 de esta lista de tareas, introducimos el technical user creado en el primer paso y su contraseña. Ejecutamos todas las tareas y verificamos que finalizan correctamente.

Configuración de conexiones 2/2

Nota: en caso de versiones SAP que no cuenten con la tarea SAP_BASIS_CONFIG_OSS_COMM, crearemos a mano las RFCs https SAP-SUPPORT_PORTAL y SAP-SUPPORT_PARCELBOX siguiendo las instrucciones de las notas 2289984 y 2716729.

Será necesario verificar que todos los recursos anteriormente citados son accedidos desde todos los sistemas directamente, o al menos pasando a través del saprouter disponible.

7.Activación de notas firmadas digitalmente

Como comentábamos anteriormente, a partir del 1 de Enero de 2020 todas las notas estarán firmadas digitalmente, y por ello deberemos habilitar esta opción en la herramienta SNOTE.
No deberemos realizar ninguna acción adicional si el nivel de release y SP es superior a las siguientes combinaciones:

Activación de notas firmadas digitalmente, SP Realeases

En caso de no cumplir con estos requisitos, aún así probable que el sistema esté habilitado para este tipo de notas ya que era uno de los requisitos para poder utilizar el framework utilizado para el SII. Podemos comprobarlo descargando en la transacción SNOTE por ejemplo la nota 2424539, y revisando su log. Si obtenemos una entrada similar a esta, es que hemos tenido suerte 😉

Activación de notas firmadas digitalmente

Si tampoco hemos tenido éxito en el chequeo, será imprescindible seguir los pasos de la nota 2836302 – Automated guided steps for enabling Note Assistant for TCI and Digitally Signed SAP Notes para habilitar el uso de notas firmadas digitalmente.

8.Activación de TCIs en la SNOTE

Es altamente recomendable habilitar también las correcciones TCI (Transport-Based Correction Instructions) en la SNOTE. Esta opción está activa por defecto en las siguientes releases y niveles de SPs :

Activación de TCIs en la SNOTE

En caso de no cumplir con estos requisitos, será necesario revisar el PDF adjunto a la nota 2836302 – Automated guided steps for enabling Note Assistant for TCI and Digitally Signed SAP Notes para verificar la activación y configuración de esta propiedad.

9.Probando que todo funciona

Por último probaremos que todos los pasos se han realizado correctamente, y que estamos utilizando la nueva interfaz https para descarga de notas. Para ello en la transacción SE38 ejecutamos el report RCWB_SNOTE_DWNLD_PROC_CONFIG, seleccionamos las dos RFCs de tipo https que hemos generado en los pasos anteriores, y guardamos la configuración:

Probando que todo funciona

Ahora vamos a la transacción SNOTE y descargamos la última versión de la nota 2755640, revisamos el log de dicha nota, y verificamos que efectivamente la nota está firmada digitalmente y se ha descargado mediante https:

Probando que todo funciona

10.Últimos pasos

Por último deberemos reconfigurar el envío de datos relativos al EWA en la transacción SDCCN:

  • conexión directa al support backbone: será necesario realizar los siguientes pasos:
    1. Remplazar el destino SDCC_OSS por el nuevo SAP-SUPPORT_PORTAL
    2. Recrear todas las tareas con sistema destino OS2 usando los destinos SAP- SUPPORT_PORTAL y/o SAP-SUPPORT_PARCELBOX
  • conexión indirecta al support backbone: verificar en la SDCCN que en la lista de destinos RFC se encuentra configurada la conexión BACK hacia el Solution Manager y que tiene marcado el flag Master.

Esperamos que el contenido os haya servido de ayuda.

¿Habéis configurado ya los accesos en los sistemas SAP de vuestra compañía?

¿Os habéis encontrado algún problema en todo el proceso?

Intercambia ficheros entre tu equipo y SAP

Intercambia ficheros entre tu equipo y SAP

Intercambia ficheros entre tu equipo y SAP 600 412 SAPMiN

Estamos seguros de que en algún momento se os ha presentado esta problemática. Lanzamos algún proceso en SAP, y el resultado es un fichero almacenado en algún directorio del servidor. O por contra necesitamos dejar un fichero en el servidor para poder procesarlo desde SAP. Y casi siempre tenemos el mismo problema: no contamos con acceso directo al servidor, ya sea escritorio remoto, ftp, carpeta compartida, o similares.

No os preocupéis, a continuación os explicamos como poder esquivar estas dificultades.

Notas: Partiremos de la base de que tenéis autorizaciones suficientes en SAP para poder lanzar estas transacciones/reports. En caso negativo, será necesario que lo tratéis con vuestros admins más cercanos 😛

Aclarar también que no se podrán cargar/descargar ficheros de directorios a los que usuarios que la instalación de SAP lleva por detrás (sidadm y SAPServiceSID) no tengan acceso a nivel de Sistema Operativo.

Solución 1

Módulos de funciones ARCHIVFILE_CLIENT_TO_SERVER y ARCHIVFILE_SERVER_TO_CLIENT

La descarga/carga de ficheros desde/hacia nuestro servidor SAP es tan sencillo como entrar en la transacción SE37 y ejecutar el módulo de fuciones ARCHIVFILE_SERVER_TO_CLIENT o ARCHIVFILE_CLIENT_TO_SERVER. Con la primera función transferimos el fichero del servidor a nuestro equipo local, y con la segunda el traspaso se realiza desde el equipo local hacia el propio servidor.

Pongamos el ejemplo de que queremos descargar desde el servidor SAP el fichero zprueba.txt albergado en el directorio /usr/sap/tmp

Intercambia ficheros entre tu equipo y SAP

Ejecutamos el módulo de funciones ARCHIVFILE_SERVER_TO_CLIENT y completamos los campos de selección con los siguientes datos:

Intercambia ficheros entre tu equipo y SAP

Hay que tener en cuenta marcar el flag de mayúsculas y minúsculas cuando nos encontremos en entornos Linux/Unix, y escribir adecuadamente todas las letras para que la ejecución sea correcta.

El campo path representa la ruta absoluta hacia el fichero que queremos descargar dentro del servidor, y el campo targetpath la ruta absoluta de nuestro equipo donde queremos depositar el fichero. Ejecutamos con F8 y verificamos que ya contamos con el fichero en nuestro equipo.

En versiones antiguas, podemos encontrar los siguientes módulos de función con similar funcionalidad: C13Z_FILE_DOWNLOAD_ASCII, C13Z_FILE_DOWNLOAD_BINARY, C13Z_FILE_UPLOAD_ASCII y C13Z_FILE_UPLOAD_BINARY.

Solución 2

Report CACS_FILE_COPY.

Mediante este programa podremos también transferir ficheros desde/hacia el servidor SAP. En el primer bloque de selección le indicamos el origen de la transferencia: servidor → cliente GUI o cliente GUI → servidor, y en el segundo bloque le indicaremos las rutas absolutas del origen del fichero y del destino donde queremos almacenarlo. Siguiendo con los datos del ejemplo anterior:

Intercambia ficheros entre tu equipo y SAP

Solución 3

Transacciones CG3Y y CG3Z.

Estas transacciones tienen un funcionamiento similar y sirven para la descarga y carga de ficheros respectivamente. Es necesario especificar las rutas absolutas origen y destino del fichero, el formato, sea ASCII o binario, y la posibilidad de sobrescribir el archivo en caso de que exista.

Intercambia ficheros entre tu equipo y SAP

Solución 4

Exportar el contenido como una lista sencilla.

Si podemos visualizar el contenido del fichero, por ejemplo en la transacción AL11, podemos descargarlo a fichero desde el menú del SAPGui con la siguiente opción: Menú superior → Sistema → Lista → Grabar → Fichero Local

Intercambia ficheros entre tu equipo y SAP

Esta opción permite descargar el contenido en diferentes formatos, como texto enriquecido, sin formato, texto con tabuladores para hojas de cálculo, e incluso formato html.

Instalación SAP al último nivel de parches

Instala tu Sistema SAP al último nivel de parches

Instala tu Sistema SAP al último nivel de parches 639 409 SAPMiN

¿has instalado alguna vez una instancia SAP y has pensado en lo beneficioso que sería poder hacerlo al último nivel de parches? Continúa leyendo porque seguro que este texto te interesa 😉

Primero analicemos un poco los hábitos de SAP: se lanza un nuevo producto bajo la denominación de Initial Shipment, con un nivel de parches muy bajo o directamente en nivel SP00. Posteriormente, y según avanza el tiempo, se publican los nuevos dumps o exports del producto actualizados bajo las nomenclatura SRx (Support Release), y que habitualmente no suelen pasar del SR2 o SR3. El problema lo encontramos cuando queremos instalar una solución SAP en concreto, pongamos la última versión del Solution Manager, y vemos que el export más reciente disponible en el OSS tiene fecha de 2017:

Instala tu Sistema SAP al último nivel de parches

Si revisamos las notas vemos que el último SP Stack disponible para este producto es el SP09 liberado en Junio de 2019:

Instalación SAP al último nivel de parches

Hasta hace no mucho lo habitual era realizar la instalación completa de la instancia SAP, y posteriormente realizar la actualización de todos los parches, a mano en la transacción SPAM/SAINT (en entornos ABAP) o mediante la herramienta SUM (Software Update Manager, en entornos ABAP y/o Java).

Te presentamos la solución: up-to-date installation.

Gracias a esta nueva característica del sapinst podremos integrar la actualización de un SP Stack en la propia instalación de nuestras instancias SAP. Elegiremos el nivel de parches al que queremos actualizar, en un proceso integrado, sin tener que preocuparnos de registrar el sistema en la web de soporte de SAP ni en nuestro Solution Manager, haciendo uso de la herramienta Maintenance Planner, y generando un fichero stack.xml que contendrá todos los componentes y parches necesarios para el proceso. A continuación la secuencia a seguir:

Instalación SAP al último nivel de parches

Pasos principales para la up-to-date installation:

  1. Descarga de todo el material necesario para hacer una instalación tradicional: guías, notas, SWPM, kernel, exports, software de BBDD, etc. Descomprimimos todos los componentes y les damos los permisos necesarios para la instalación. Adecuamos y configuramos el servidor según las guías de instalación.
  2. Generación del stack.xml: Nos dirigimos a la aplicación del Maintenance Planner de SAP y lanzamos la opción de Plan a New System:

Instalación SAP al último nivel de parches

A continuación seleccionamos el SID del sistema que queremos instalar, si se trata de una Pila ABAP o una Java, el producto concreto y su release, y finalmente el nivel de parches al que queremos actualizar, en este caso al SP09:

Instalación SAP al último nivel de parches

Posteriormente seleccionamos los ficheros de kernel, y de algunos componentes adicionales, como parches de SAP_UI, HHRR, y similares. La herramienta ya nos ha calculado todos los componentes y parches que necesitamos para la actualización, resolviendo las dependencias entre componentes.

Instalación SAP al último nivel de parches

Por último descargamos el fichero stack.xml generado, y añadimos todos los ficheros a la cesta de descarga (botón Push to Download Basket)

En el botón de Utilities tenemos varias opciones adicionales muy interesantes, como generar el informe de efectos colaterales, análisis de notas de seguridad, y la verificación de las dependencias para el upgrade.

  1. Descarga de los parches. Deberemos descargar los parches que acabamos de seleccionar en el punto anterior (preferiblemente mediante el Download Manager de SAP) y ubicarlos en un directorio del servidor junto con el stack.xml generado.
  2. Lanzamiento del sapinst. Dentro del directorio del SWPM, lanzamos el ejecutable del sapinst indicando la ubicación del directorio en el que se encuentra el stack.xml mediante la opción       SAPINST_STACK_XML, por ejemplo:

./sapinst SAPINST_STACK_XML=/software/parches/stack.xml (para entornos Linux/Unix)

sapinst.exe SAPINST_STACK_XML=D:\software\parches\stack.xml (para entornos Windows)

A continuación veremos que en el sapinst únicamente nos aparece la opción de instalación para el producto que hemos definido al generar el stack.xml:

Instalación SAP al último nivel de parches

  1. Instalación. Una vez lanzado el sapinst, parametrizamos todas las opciones a lo largo de las pantallas como cualquier otra instalación, y comenzamos con ella. Una vez que se hayan completado todos los pasos incluido el import de los datos, y justo antes del inicio de las actividades de post-proceso, se lanzará automáticamente el proceso de actualización (SUM)

Instalación SAP al último nivel de parches

  1. Actualización de parches. Nos dirigimos a la SUM, y realizamos la importación de todos los parches incluidos en el stack.xml

Instalación SAP al último nivel de parches

  1. Finalización de la instalación. Una vez completado el proceso de SUM, volvemos al proceso del sapinst, y terminamos la instalación.

Instalación SAP al último nivel de parches

  1. Post-proceso. Para finalizar la instalación realizamos todas las tareas incluidas en las guías y notas recogidas en el punto #1.

Nota aclaratoria: El proceso descrito se corresponde con la instalación y actualización de una instancia ABAP. La opción up-to-date para las pilas Java consiste en instalar completamente primero, para lanzar manualmente la actualización mediante la SUM después.

  • 1
  • 2