Todos sabemos, que los recursos TI son una parte fundamental en la estructura de las empresas hoy en día. Su mal funcionamiento puede causar una pérdida en la productividad. Por ello, es muy importante controlar la salud de la infraestructura TI. De esta manera, se pueden aplicar medidas correctivas para evitar caídas o en caso de haberlas actuar lo antes posible para restablecer el servicio. Para poder conocer la salud de los recursos TI se utilizan los sistemas monitorización. En nuestro caso, para monitorizar servidores no SAP (para esto tenemos el Solution Manager) utilizamos la herramienta de monitorización Check_MK.

¿Qué es Check_MK?

Check_MK es un sistema de monitorización de código abierto. Está basado en la herramienta Nagios, al cual, le añade mejoras en funcionalidad y rendimiento. Permite monitorizar todos los recursos de TI de una empresa tanto hardware como software. Check_MK se puede obtener de forma gratuita, aunque también cuenta con dos versiones de pago. La monitorización se realiza mediante los agentes que te ofrece la herramienta y mediante el protocolo SNMP.

 Características de Check_MK

Configuración y motor de chequeo

Utiliza una forma diferente para configurar los objetos respecto a Nagios, siendo más potente y funcional que el estándar. Para aprovecharlo es necesario instalar los agentes de monitorización en los elementos a monitorizar. De esta forma, nos permite añadir una serie de chequeos de forma automática.

MK Livestatus

Permite conocer el estado de los elementos monitorizados en tiempo real de forma rápida y funcional. Hasta ahora la forma de acceder al estado de los objetos de Nagios era leyendo un fichero o consultando una base de datos. Check_MK crea un socket que permite sin apenas consumir recursos saber de forma rápida el estado de nuestra infraestructura.

Multisite

Es una nueva interfaz web respecto a Nagios-GUI que permite la gestión de varias instalaciones desde un solo sitio. Además, permite hacer vistas personalizadas aplicando diferentes filtros. Esta herramienta también permite tener una monitorización distribuida pudiendo conectarse a diferentes instalaciones y sitios de Check_MK pudiendo gestionarlos desde un punto centralizado.

Wato

Es la abreviación de Web Administration Tool. Esta herramienta permite realizar todas las configuraciones y añadir nuevos host y servicios a monitorizar mediante una interfaz web sencilla e intuitiva.

 Consola de eventos

Permite gestionar todos los eventos que se reciben en el check_mk. Pudiendo clasificarlas, relacionarlas, reescribirlas, crear nuevos eventos y ejecutar acciones mediante la utilización de diferentes reglas.

Notificaciones

Contiene un sistema de alertas que permite enviar notificaciones de forma personalizada. Por defecto, ofrece algunos canales como el e-mail o el sms pero puedes crear tus propios canales. Por ejemplo, sería posible enviar notificaciones mediante Telegram. En artículo futuro ahondaremos en el tema de los bots de Telegram y su aplicación en diferentes situaciones.

Extras

Check_mk permite incluir dos herramientas muy interesantes como son pnp4nagios y NagVis. La primera permite tener gráficas sobre todos los host y servicios monitorizados. Pudiendo ver el comportamiento en diferentes periodos de tiempo.

Ejemplo pnp4nagios

NagVis permite crear mapas para ver una situación en tiempo real de la infraestructura de la empresa. Permite tanto crear mapas con topologías de red como mapas por geolocalización pudiendo ubicar cada equipo o servicio en un mapa mundial.

Ejemplo NagVis

Business Intelligence

Permite llevar la monitorización un paso más allá. Permite agregar diferentes checks pudiendo relacionarlos entre ellos. De esta manera es posible monitorizar lógicas de negocio. Por ejemplo, se podría monitorizar si una aplicación o un proceso está funcionando correctamente relacionando todos los elementos que la componen.

Móvil

La herramienta es accesible desde dispositivos móviles ofreciendo una interfaz amigable para este tipo de dispositivos.

Como veis, Check_MK es una herramienta de monitorización muy completa y potente, además de ofrecer un buen rendimiento a nivel de recursos. Con la implantación de un sistema de monitorización pasamos de ser reactivos a ser proactivos en cuanto a la gestión de los recursos TI. Gracias a tener el control del estado en tiempo real podemos adelantarnos a posibles fallos y caídas. Utilizando las diferentes notificaciones y gráficas podemos mejorar la calidad de nuestros servicios. También, nos ofrece una intervención más rápida ante fallos, por ejemplo, gracias a las notificaciones de Telegram.

Si al final la lectura del artículo estáis interesados en saber más sobre Check_MK realizaremos un webinar con una demostración explicando y enseñando el funcionamiento de la herramienta. ¡Estate atento para cuando lo publiquemos!

Las aplicaciones de mensajería instantánea las usamos constantemente en nuestro día a día. Están a nuestro alcance en todo momento a través de nuestros smartphones. Por ello, desde Oreka IT pensamos en buscarles una aplicación en el ámbito laboral, más allá de intercambiar mensajes entre compañeros. Nos centramos en Telegram, entre otras cosas, porque tiene una funcionalidad que destaca sobre las demás, la posibilidad de crear bots.

¿Qué son los bots?

Los bots son pequeños programas que son capaces de interactuar con otros usuarios de Telegram pudiendo añadir todo tipo de funcionalidades. La comunicación con los bots se hace enviando mensajes por el chat de Telegram al bot. También, se pueden añadir bots a grupos. La implementación de las funcionalidades del bot se realizar mediante el lenguaje de programación python. En Oreka IT, decidimos crear un bot para nuestro departamento de sistemas. A continuación, explicaremos algunas de las funcionalidades de Zordon (así se llama nuestro bot).

Posibilidades de los bots

Notificaciones

Probablemente la funcionalidad más útil e importante. Zordon nos avisa de cualquier caída que se produzca en cualquiera de nuestros sistemas. Además, es capaz de notificar cualquier evento que detecte nuestro sistema de monitorización. Esto nos permite estar al tanto y actuar de forma rápida ante cualquier incidencia de nuestros sistemas sin importar donde estemos. Para evitar una recepción masiva de mensajes y recibir tan sólo las que consideramos críticas, desde Check_MK elegimos qué tipo de eventos queremos que se notifiquen al bot. Para saber más sobre el sistema de monitorización Check_MK podéis ver mi anterior artículo.

Ejemplo de notificación caída y arranque de Host

Comandos desde remoto

Zordon es capaz de ejecutar cualquier comando en el servidor Linux que nosotros le hemos especificado. Esta es una funcionalidad delicada y es por ello que en nuestro caso está limitado a la utilización del comando ping pero si se quisiera se podría habilitar para la ejecución de cualquier comando. Además de limitar los comandos que se pueden utilizar también aplicamos otras medidas de seguridad. El bot se asegura que el mensaje enviado sea desde el grupo de sistemas y que haya sido alguno de los usuarios miembros del grupo. Esta característica se utiliza mediante interacción directa con el bot como veremos en el siguiente ejemplo:

Ejemplo de comando ping

Funciones en sistemas SAP:

Este es un comando interesante que nos permite ahorrar tiempo en algunas tareas repetitivas. Como puede ser que un compañero te solicite el desbloqueo de su usuario porque ha introducido demasiadas veces la contraseña incorrectamente. En el caso de que no se acuerde de la clave, poder reinicializarla con una temporal. Recordemos que el bot de Telegram está programado en python y se puede usar este lenguaje, por ejemplo, para conectarse a un sistema SAP y ejecutar BAPIs. Ejemplo de reseteo de contraseña de un usuario:

Ejemplo reinicio contraseña en un sistema SAP

Hemos podido ver cómo el bot de Telegram nos facilita la gestión de nuestros recursos TI, pudiendo estar al tanto de incidencias y siendo capaces de realizar algunos tareas sencillas en cualquier momento desde nuestro teléfono móvil. Desde Oreka IT pensamos que la implantación de Zordon es un acierto, ya que, nos permite una reacción inmediata ante situaciones inesperadas. Es un miembro más del equipo que ha venido para quedarse.

¡Si necesitas más información no dudes en dejarnos un comentario o ponerte en contacto con nosotros!

Un estudio publicado recientemente por las empresas de ciberseguridad Digital Shadows y Onapsis, evidenciaba recientes ciberataques a los sistemas ERP de SAP y Oracle en al menos una docena de compañías y agencias gubernamentales, y afirma que  miles de empresas más poseen vulnerabilidades vinculadas a viejos fallos de seguridad.

El informe pone como ejemplo 2 empresas gubernamentales de energía y finanzas, que fueron vulneradas por no aplicar las medidas de seguridad aconsejadas por SAP y Oracle.

El estudio, del que se ha hecho eco el Departamento de Seguridad Nacional de EE. UU. para emitir una alerta, resalta el riesgo de miles de empresas con estos sistemas de gestión sin parchear.

La alerta viene causada por la criticidad de las empresas anteriormente citadas, ya que almacenan datos altamente confidenciales, como son, resultados financieros, secretos de fabricación o números de tarjetas de crédito de sus clientes, proveedores y empleados en sus programas de gestión.

No se trata de un tema reciente, ya que puede decirse que hace una década que empezaron a realizarse ciberataques a los ERPs, pero el informe muestra un creciente interés por hackers y agencias de espionaje para sacar provecho de estas vulnerabilidades.

Para proteger la infraestructura de los ataques, SAP recomienda aplicar los parches de seguridad tan pronto como sean liberados, generalmente el segundo martes de cada mes. Sin embargo, los clientes a menudo son reacios a realizar correcciones por miedo a que sus actividades de negocio se vean afectadas.

Desde Oreka, recomendamos seguir las buenas practicas mencionadas por SAP, ya que normalmente estos parches no afectan a las líneas de negocio sino a la base tecnológica, y cierran la puerta a los atacantes preparados para explotar vulnerabilidades antiguas, que dan acceso total sin ser detectados a nuestros sistemas de gestión.

Si tienes cualquier duda sobre este tema, déjanos un comentario o ponte en contacto con nosotros y te ayudaremos a mantener tus sistemas protegidos. 

Hace unos días SAP informaba de la actualización de la infraestructura de Soporte que permite la conexión de nuestros sistemas con SAP. Debido a esta actualización ciertos sistemas dejarán de poder conectarse con SAP a partir del 1 de enero de 2020.

La infraestructura central de SAP, llamada SAP Support Backbone, es la que se encarga de prestar soporte técnico a sus clientes. Se compone de varios sistemas para atender diferentes propósitos. Por ejemplo: proporcionar la infraestructura del Support Portal, el maintenance planner, la infraestructura detrás de SNOTE y EarlyWatch Alert y mucho más.

Como no puede ser de otra manera, SAP asegura que esta infraestructura crítica esté siempre actualizada y que su comunicación se realice de forma segura. El problema en esta última actualización es que tiene impacto en la conectividad de los sistemas Solution Manager, así como en la conectividad de todos los demás sistemas que se comunican con SAP. Este proceso finalizará en enero de 2020 y los clientes deberán tomar medidas antes de esta fecha para garantizar una transición sin problemas.

Además de las actualizaciones técnicas del sistema, el cambio más importante es la actualización de la comunicación mediante https, permitiendo que los certificados del servidor utilicen SSL. Esta actualización afecta a SAP Solution Manager y a los sistemas SAP que se están comunicando con SAP Support Backbone.

Es por ello que los clientes deberán actualizar su sistema Solution Manager antes de enero de 2020, para seguir teniendo comunicación con SAP. Las situaciones que nos podemos encontrar son las siguientes:

Escenario 1: El cliente ya se encuentra en SAP Solution Manager 7.2:

• Implementar el SPS07 (más notas adicionales) o implementar el SPSP08.

Escenario 2: El cliente todavía se encuentra en SAP Solution Manager 7.1:

• Solicitar un technical S-User.
• Realizar la migración a SAP Solution Manager 7.2 SPS07 (más notas adicionales) o migrar a SAP Solution Manager 7.2 SPS08.

En cualquier caso, nuestra recomendación es mantener los sistemas siempre actualizados haciendo una subida de stack cada 6 meses o cada año, como sugieren las buenas prácticas de SAP. Nuestra opinión para este caso en concreto, si tenemos en cuenta que la fecha limite es enero de 2020 para realizar esta actualización obligatoria, es esperar a mediados de 2019 para empezar a abordar este proyecto y así instalar el ultimo stack que haya liberado SAP.

Si tienes cualquier duda al respecto de este artículo, déjanos un comentario o contacta con nosotros. 

Aunque parezca un tema trivial no nos damos cuenta del tiempo que dedicamos metiendo el mismo usuario y contraseña para acceder a los sitios mediante los navegadores. SAP no es una excepción, debiendo loguearse cada vez que se quiere revisar notas en el caso de los funcionales o como en el caso del administrador para solicitar claves, dar de alta sistemas o un montón de tareas más. El caso además se complica si se administran varias cuentas.

Es por ello, que hoy quiero enseñaros la herramienta SAP Passports para acceder al portal de SAP mediante Single Sign-on.

La idea es generar un certificado para el usuario OSS en SAP e instalarlo en el navegador para que no vuelva a solicitar credenciales.

Los pasos son los siguientes:

Generar el certificado

Acceder a la URL https://launchpad.support.sap.com/#/sappassport y loguearnos con nuestro usuario.

Nombre y User ID vienen alimentados, tendremos que alimentar la contraseña del usuario y elegir la longitud de la clave.

Cuando le damos a Apply for SAP Passport nos pide una contraseña para el certificado.

Esto genera un .pfx que es el fichero que deberemos importar en el navegador.

Importar certificado

Firefox

Ponemos about:preferences#privacy en Firefox y bajamos hasta el apartado “Certificados” donde clicaremos en “Ver certificados”

Se abrirá el administrador de certificados e importaremos el certificado.

Cerramos el navegador y la próxima vez que entremos a http://launchpad.support.sap.com/ nos saldrá un pop-up para la selección de certificado

En caso de administrar mas de una cuenta, realizaremos los pasos Generar el certificado e imporlo con los demás usuarios que se posea.

Chrome

En Chrome es mas de lo mismo, poner en la barra de dirección chrome://settings/ y en configuración avanzada en el apartado HTTPS/SSL clicar en administrar certificados

Importamos el certificado generado y la próxima vez que abramos el navegador ya estará listo para usar en el launchpad de SAP.

Este ultimo método nos sirve también para usarlo con Microsoft EDGE e Internet Explorer ya que el certificado lo almacena en Windows.

Esperamos que te resulte de ayuda a la hora de ahorrarte un poco de tiempo en este proceso. Puedes dejarnos las dudas que tengas en comentarios.

Hace unos meses publicamos un artículo avisando de la necesidad de actualizar Solution Manager mínimo al stack 8 de la versión 7.2 para poder mantener la conexión con el centro de soporte de SAP tras la actualización que van a realizar en la infraestructura. La fecha límite para realizar esta actualización y seguir conectándose sin problema es el 1 de enero de 2020.

En relación con la actualización, SAP ha decidido securizar las notas. Para ello, ha implementado la obligatoriedad de que las notas estén firmadas digitalmente. Esto implica que cualquier sistema que no actualice la forma de descargar y subir notas, no podrá implementar notas. Va a ser necesario habilitar en los sistemas ABAP el poder utilizar notas SAP digitalmente firmadas.

Hay dos formas de poder habilitar la funcionalidad para poder usar notas digitalmente firmadas:

• Mediante la implementación de notas manuales usando la transacción SNOTE.
• Mediante la implementación de un paquete usando el TCI, que si no está instalado es necesario instalarlo, que incluye todas las notas del anterior punto. Este segundo método es el recomendado por SAP.

Para poder habilitar la funcionalidad, ya sea bien por notas o por TCI, es necesario que los sistemas estén en un Stack mínimo dentro de cada Release:

Para ambos casos, después de la implementación, es necesario habilitar conexiones seguras mediante HTTPS con el SAP Support Backbone. Además, es necesario crear una conexión HTTPS contra el servicio de descargar de notas.

En conclusión, la necesidad de actualizar Solution Manager al stack 8 de la versión 7.2 se suma la necesidad de adaptar los sistemas SAP para que se puedan implementar las notas firmadas antes del 1 de enero de 2020. En caso de no hacerlo, Solution Manager no tendrá conexión con SAP (EWA, Maintenance Planner…) y además, no será posible descargar notas de los servidores de SAP para implementarlos.

Si tienes cualquier duda o pregunta, puedes dejarnos un comentario o ponerte en contacto con nuestro departamento de Administración de Sistemas SAP.

Área de administración de sistemas SAP

La entrada Implementando digitally signed SAP Notes se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En este artículo vamos a hablar de la arquitectura para SAP FIORI con S/4 HANA. Vamos a explicar los componentes que lo forman y las conexiones necesarias para cada tipo de aplicación. Durante el artículo no se muestra la arquitectura completa, solamente los componentes relevantes desde el punto de vista de las autorizaciones. Éste será el primero de una serie de artículos que hablarán sobre autorizaciones para S/4 HANA.

En la imagen superior se puede observar cuáles son los elementos principales que componen SAP Fiori en S/4 HANA. El cliente es el SAP Fiori Launchpad desde donde los usuarios lanzan todas las aplicaciones Fiori. El Front-End Server (FES) es un sistema SAP NetWeaver ABAP Stack como cualquier ERP SAP. La diferencia es que no tienen ningún add-on de negocio instalado. La arquitectura recomendada para SAP Fiori separa la parte UI de la parte de lógica de negocio que está en el SAP Back-End Server (BES). Se pueden conectar varios BES a un sólo FES. Esta arquitectura tiene, entre otras, algunas de las siguientes ventajas:

• Separar el ciclo de vida de las aplicaciones UI del backend.
• Permitir iteraciones más rápidas con las aplicaciones UI.
• Permiter realizar cambios en las aplicaciones UI sin necesidad de tener autorizaciones en el backend.
• El administrador del metadata UI no necesita permisos de administrador en el backend donde se alojan los datos sensibles del negocio

La imagen representa la arquitectura completa en cuanto a autorizaciones para S/4 HANA donde se pueden ver los tipos de aplicaciones Fiori, los componentes que interactúan en cada servidor y los tipos de conexión que utilizan para conectarse entre ellos. A continuación, se explica brevemente en que consiste cada tipo de aplicación y como interactúa con el resto de componentes.

• Legacy: no son aplicaciones UI5. Son WebDynpro y transacciones GUI para aplicaciones HTML. No son aplicaciones portables, a pesar de contar un aspecto Fiori. Estas aplicaciones se conectan mediante HTTPS directamente contra el backend.
• Transactional, Analytical, Object Page: las tres funcionan de la misma manera, se les da un nombre diferente dependiendo del uso para el que hayan sido desarrollados. Son aplicaciones SAPUI5 Fiori. Tienen el despliegue de su interfaz en el FES. No son parte del Central UI pero necesitan add-ons específicos de prodecuto del Product UI. Por otro lado, estas aplicaciones necesitan recoger datos de negocio del servidor S/4 HANA del backend. Estos datos se transfieren mediante el protocolo OData. Para ello, se crea un RFC-TRUSTED entre el FES y el BES. Los usuarios de SAP Fiori necesitan tener un usuario en cada servidor con diferentes autorizaciones.
• Search: la aplicaciones Search del Fiori Launchpad tienen otra forma de funcionar. La interfaz del usuario se consigue mediante HTTPS desde el Central UI del FES. En cambio, los datos van por el protocolo InA directamente contra el motor Enterprise Search del servidor S/4 HANA.

Por último, comentar que es posible tener un sistema SAP Fiori con S/4 Hana sin necesidad de usar la arquitectura anterior. Se puede incluir el Front-End dentro del Back-End pero no es lo que recomienda SAP. Este tipo de arquitectura se puede observar en servidores Solution Manager 7.2.

En conclusión, la arquitectura presentada en el artículo es la que deberían de adoptar las empresas que estén pensando en hacer una conversión. Se puede observar cómo interactúa cada aplicación con los diferentes componentes de los dos servidores. Esta arquitectura separa las interfaces de los datos sensibles del negocio permitiendo tener dos usuarios con diferentes autorizaciones en cada sistema. El traspaso de datos y autorizaciones mediante los dos sistemas se hace mediante una RFC-TRUSTED. Los artículos futuros se centrarán más en la parte de la creación de autorizaciones en el FES y en el BES.

Esperamos que este artículo sobre la arquitectura de SAP Fiori con S/4 HANA te haya resultado útil. Recuerda que muy pronto estarán disponibles los siguientes artículos sobre autorizaciones para S/4 HANA.

Si tienes cualquier duda, puedes dejarnos un comentario o ponerte en contacto con nuestro departamento de SAP BASIS.

Área Administración de sistemas SAP

La entrada Arquitectura para SAP FIORI con S/4 HANA se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Las actualizaciones SAP consisten en pequeñas correcciones (SAP Notes), que SAP libera según se van descubriendo errores en los sistemas. Estas notas conforman los SP (Support Package), incluyendo en un nuevo SP todas las notas liberadas desde el SP anterior. Siguiendo la misma metodología, SAP agrupa los SP en Stacks de SPs, que permiten facilitar y mejorar la logística del software. Instalando un SP Stack en lugar de instalar en el sistema los componentes individualmente, SAP asegura que un sistema se encuentra libre de conflictos y se respetan las dependencias y requisitos de los niveles de SP de los componentes que lo conforman.

En las distintas actualizaciones de Netweaver 7.0 y ERP 6.0, SAP ha ido liberando paquetes de actualizaciones mayores, los EHP (EnHancement Package) que se tenían que aplicar utilizando una herramienta específica. El programa SAP EnHancement Package Installer o EHPI.

SAP, con el desarrollo del Software Logistics Toolset, creó la herramienta SUM (Software Update Manager) que agrupa la mayoría de las tareas de actualización y conversión de los sistemas SAP en una sola herramienta.

Para descargar el SUM, hay que acceder al SAP Support Portal que requiere de un usuario S-User con autorización para descargar archivos. Los paquetes .SAR del SUM se encuentran en la sección Software Download On Premise del SAP Support Portal, o directamente en el siguiente enlace:

https://support.sap.com/en/tools/software-logistics-tools/software-update-manager.html

A partir del Software Logistics Toolset 1.0 SPS21 SAP lanza SUM 1.0 SP21 y 2.0 SP0 y cuando se muestran los resultados para descargar, aparecen dos versiones: SUM1.0 y SUM2.0. Este punto puede resultar un poco confuso para saber qué versión de SUM se necesita.

La elección depende de la versión de Netweaver a actualizar. La información relativa a las versiones de SUM disponibles y los escenarios en los que utilizar cada versión se explica en la siguiente SAP Note:

2519216 – SUM 2.0 : Introducing the new Software Update Manager family member

Los escenarios de uso para SUM 1.0 / SUM 2.0 y qué versión corresponde a cada tipo de sistema en función del nivel del sistema origen y destino de la migración/actualización son:

• En actualizaciones con destino ABAP NW 7.40 o inferior se usará SUM 1.0 y también en sistemas JAVA o dual stack ABAP+JAVA.
• La opción ZDO (Zero Downtime Option) solo está disponible con SUM 2.0 (aunque el destino sea NW 7.40 o anterior).
• SUM 2.0 se usará para Sistemas ABAP single stacks basados en NW 7.50 o superior. El sistema fuente debe ser Unicode y basado en NW 7.0 o superior.
• Las conversiones de sistemas (pasar de un SAP ERP a SAP S/4HANA) necesitan SUM 2.0. Por tanto la opción DMO solo funciona en SUM 2.0.

No obstante, la mayoría de las veces no es necesario elegir entre SUM 1.0 y SUM 2.0, ya que la propia aplicación Maintenance Planner incluye la versión requerida a la lista de ficheros de descarga.

El Maintenance Planner, que está disponible en el SAP ONE Support Launchpad, y es la herramienta que hay que utilizar para generar los ficheros .xml requeridos para la actualización.

Por último, no se puede dejar sin comentar que el equipo de SAP Software Logistics es un equipo con mucha actividad. Es el encargado de desarrollar y corregir los errores detectados en la herramienta SUM y libera parches del programa a un ritmo casi de una actualización por mes. Es por ello muy recomendable intentar utilizar la última versión disponible para evitar errores.

Para consultar la última versión disponible del SUM, documentación y últimas SAP Notes, revisar la página oficial de Software Update Manager.

La información detallada de las características y uso se encuentra en las guías correspondientes de SUM:

• Guides for SUM 1.0

• Guides for SUM 2.0

Esperamos que este artículo te haya resultado de ayuda.Recuerda que puedes dejarnos tus preguntas en comentarios o puedes ponerte en contacto con nuestro departamento de Administración de sistemas SAP.

Área Administración de sistemas SAP

La entrada SAP Software Update Manager SUM 1.0 y SUM 2.0 se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

SAP acaba de lanzar recientemente la versión 1.0 SPS 25 de sus herramientas de Logística de Software. El SL Toolset 1.0 SP 25 está disponible desde el 21 de enero de 2019. Comparado con la revisión SPS 24, SAP no ha añadido ninguna herramienta nueva. Las herramientas que componen el conjunto de herramientas de logística de software son las siguientes:

Las herramientas de logística de Software se dividen en dos grupos:

• Mantenimiento de Software
  • Software Update Manager (SUM) 1.0 y 2.0
    • SUM 1.0 SP 23
    • SUM 2.0 SP 04
  • “nZDM SAP Netweaver Java” 1.0 SP 22
  • SPAM/SAINT 7.00 – 7.53 / versión 0071

• Aprovisionamiento de Software
  • Software Provisioning Manager
    • SWPM 1.0 SP 25
    • SWPM 2.0 SP 02
  • SAP setup
  • Software Lifecycle Plugin 1.0

Las herramientas de aprovisionamiento se utilizan para realizar instalaciones de sistemas nuevos, copiar y renombrar sistemas, instalar instancias de diálogo adicionales y más tareas genéricas relacionadas con la preparación y distribución de sistemas SAP. El mantenimiento de los sistemas, instalación de Support Packages y Add-ons, upgrades y conversiones se realiza utilizando las herramientas de mantenimiento de software como SPAM, SAINT y SUM respectivamente.

En la última versión de estas herramientas, SAP ha terminado de cambiar la interfaz de usuario del Software Provisioning Manager (SWPM) a la versión web utilizando la tecnología Fiori para la representación de las pantallas, que ya había introducido en versiones anteriores del Software Update Manager (SUM) y en el SAP ONE Support Launchpad.

Versión SWPM anterior:

Versión SWPM actualizada:

Utilizar el interfaz Web en el SWPM agiliza el proceso de instalación facilitando la ejecución de la herramienta en entornos Unix/Linux, donde no es necesario utilizar un X Server para visualizar las pantallas del instalador. Ejecutando el programa sapinst directamente en un shell del servidor proporciona una URL, que utilizando un navegador Web muestra la interfaz de usuario de la herramienta.

Para obtener más detalles de todas las novedades y seguir la evolución del SL Toolset, se recomienda revisar el SAP Support Portal donde SAP publica todas las novedades. Para acceder a estas secciones es necesario tener un usuario S-User con el que hacer login en el Portal.

Esperamos que este artículo te haya resultado de interés. Puedes dejarnos tus preguntas en la zona de comentarios y si necesitas ampliar información, puedes ponerte en contacto con nuestro departamento de Administración de sistemas SAP.

Área Administración de sistemas

La entrada Novedades de SAP Software Logistics Toolset 1.0 SP 25 se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Este año tuve la suerte de poder acudir al SAP TechEd de Barcelona. Mi principal objetivo era disfrutar de la experiencia y poder aprender lo máximo posible sobre los temas que son tendencia en el mundo SAP. Como no es posible abordar todo el contenido ni todas las ramas diferentes que ofrece el evento decidí centrarme en dos aspectos: la seguridad y la conversión a S/4 HANA, dejando un poco de tiempo libre para algunas charlas que me parecían interesantes, pero no estaban relacionadas directamente con los temas mencionados anteriormente. A continuación, intentaré hacer un resumen de lo visto en el evento.

En cuanto a seguridad, puede ver y probar algunos de los servicios que ofrece SAP para securizar nuestros sistemas. Entre todos ellos destaco sobre todo dos productos para la gestión de identidades y accesos en SAP. Los cuales parece que serán el eje para la securización de sistemas híbridos.

El primero de ellos es SAP Cloud Platfrom Identity Authentication Service. Este servicio ofrece la autenticación segura para servicios on-premise y cloud. Algunas de sus funcionalidades destacadas son la integración con Single Sign On, la posibilidad de habilitar la autenticación de dos factores, la gestión de usuarios y la posibilidad de delegar la autenticación a almacenes de usuarios on-premise como Active Directory. El otro producto para destacar sería el SAP Cloud Platform Identity Provisioning Service. Este servicio ofrece una forma segura y fácil de gestionar todo el ciclo de vida de la identidad entre sistemas SAP. Es capaz de gestionar tanto repositorios de usuarios on-premise, Active Directory o un sistema SAP Netweaver, como gestionar repositorios en la nube, por ejemplo, el de SuccessFactors. Este servicio se integra con el servicio de Identity Authentication Service ofreciendo así una solución completa para la gestión de identidades y accesos. Por último, relacionado con la seguridad en sistemas híbridos, comentar que se antoja esencial contar con SAP Cloud Connector bien configurado para poder gestionar de manera segura las conexiones entre los sistemas on-premise y cloud.

El otro tema en el que me centré durante el evento fue la conversión a S/4 HANA. En este aspecto se presentó la versión 2.0 del SAP Readiness Check. Esta herramienta es esencial a la hora de abordar una conversión a S/4 HANA. La nueva versión ofrece nuevas y mejoradas analíticas. Además de ofrecer un nuevo aspecto con un rediseño basado en Fiori 3.0. También, hubo una ponencia muy interesante que constaba de dos partes donde se explicaba el proceso End-to-end para hacer una conversión a S/4 HANA. En estas ponencias, se explicaban las herramientas y los pasos necesarios para llegar a convertir un sistema R/3. Lo más destacado fue que las salas donde se exponían las cosas referentes a la conversión había colas para entrar y estaban llenas. Indicando que las empresas ya están interesando y moviendo en este sentido.

Para finalizar, pude acudir a algunas charlas interesantes. Destacaría la charla que ofreció SUSE donde explicaron las posibilidades de cómo implementar SAP en SUSE. Hablaron sobre las soluciones de alta disponibilidad, algunas herramientas interesantes que se integran con SAP y sobre las novedades que se esperan en versiones futuras como mejoras en la monitorización de sus sistemas mediante código abierto. Otra de las charlas más interesantes fue en la que presentaron, con un ejemplo práctico, el producto SAP Conversational AI (Artificial Intelligence). Permite la creación de un chatbot integrado en nuestro sistema SAP para interactuar con el usuario y poder hacer, por ejemplo, consultas. Además, la posibilidad de integrar el chatbot con Telegram, Teams y otros servicios de mensajería.

A pesar de la cantidad ingente de información recibida, sirvió para aprender muchísimas cosas nuevas y resultó extremadamente interesante. Con las ganas de poder volver en un futuro ahora es tiempo de asimilar toda esa información y ponerla en contexto. Durante el evento se trastea con la última tecnología disponible pero luego hay que aterrizar y ver cuál es la realidad de las empresas que nos rodean y sus necesidades reales.

Puedes leer el resto de novedades que conocimos en el SAP TechEd de Barcelona en esta noticia.

La entrada #StoryTime: seguridad y conversión a S/4 HANA en el SAP TechEd 2019 se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Actualmente todas las empresas tienen documentación digital que deben almacenar en un gestor documental. Por lo tanto, la importancia de tener toda esa información ordenada y accesible de forma sencilla es mayor. En este sentido, como proveedores de servicio de SAP nos hemos enfocado en la forma de poder gestionar y almacenar de forma sencilla los documentos que se adjuntan en el ERP. Si observamos el actual ecosistema de soluciones para repositorios documentales, Sharepoint es una de las principales soluciones tanto en su versión onpremise como en su versión online incluida en la suite Office365.

El actual problema es que Sharepoint no es compatible con ArchiveLink el protocolo de SAP para enviar documentos a los repositorios documentales. Por ello desde Oreka, hemos decidido llegar a un acuerdo de colaboración con la empresa Intellidocx, el cual, cuenta con un conector certificado tanto por SAP como por Microsoft para poder juntar SAP y Sharepoint de una forma transparente para el usuario. Siendo compatible con los diferentes módulos de SAP (FI – MM – HR – PM…).

Este conector viene a cubrir las necesidades de las siguientes necesidades que los usuarios pudieran tener:

• Tener los documentos centralizados en un repositorio documental. Añadiendo metadatos a los documentos.
• Compartir documentos de SAP. Gracias a la integración con Sharepoint es posible compartirlos con usuarios de forma ocasional o permanente. Tanto con usuarios de la organización como externos.
• Organizar el contenido mediante vistas de negocio. Por ejemplo, por líneas o procesos de negocio, por ubicación o clientes.
• Búsqueda rápida de contenidos. Usando los metadatos se puede buscar la documentación de una forma sencilla.
• Acceso desde el móvil. Es posible acceder a la documentación desde dispositivos móviles gracias a las aplicaciones de Sharepoint.

Además, el conector es bidireccional esto quiere decir que se pueden agregar documentos desde SAP a Sharepoint pero también es posible realizar acciones desde Sharepoint hacia SAP. Es posible asociar contenidos personalizados a objetos de SAP. A pesar de que Sharepoint sea el repositorio documental, el conector es capaz de integrar cualquier aplicación de Microsoft en Office365.

En resumen, este conector permite integrar dos de las soluciones empresariales más utilizadas SAP y Sharepoint, pudiendo así avanzar en un gestor documental centralizado para toda la organización. Donde poder integrar todos los procesos de negocio de forma bidireccional. Como hemos comentado antes el funcionamiento es transparente para los usuarios y la utilización del conector se realiza de forma sencilla.

Si tu empresa utiliza tanto SAP como Sharepoint, ésta puede ser una buena oportunidad para poder integrar ambas soluciones y de esta forma poder tener todos los documentos de SAP en el mismo gestor que el resto de la información de la organización. El conector tiene muchas funcionalidades que podrían resultar útiles para mejorar los procesos de negocio de vuestras organizaciones. Para obtener más información sobre el conector no dude en contactar con nosotros. Además, permaneced atentos a nuestras redes sociales, ya que es posible que próximamente se realice un webinar para enseñar algunas de las características de esta solución.

Área Administración de sistemas

La entrada Integrar Sharepoint con SAP se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....