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.

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:

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?

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:

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

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.

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:

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 😉

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 :

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:

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:

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?

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

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

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:

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.

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

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.

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

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

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:

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:

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:

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.

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.

3. 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.
4. 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:

5. 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)

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

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

8. 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.