SAP Netweaver archivos - Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap...

En el siguiente artículo técnico os vamos a explicar la manera de firmar los documentos PDF digitalmente a traves de SAP PI, de manera sencilla y gracias a la web http://www.java4less.com/

Han desarrollado un módulo que, unido al File Adapter estándar, es capaz de firmar con certificado en servidor, el documento que reciba SAP PI. A continuación pasamos a explicar detalladamente como conseguirlo.

Deployando

Para ello, primero tenemos que deployar el componente en el servidor, teniendo en cuenta la versión de SAP PI y la versión de JAVA que tenga.

File Adapter

Una vez deployado, la configuración del File Adapter es bien sencilla

Tal y como dice la propia documentación de los creadores, la firma digital debe de estar en el propio servidor de PI. Lógicamente esto nos vale para firmar documentos de manera automática con una firma general, por ejemplo, y sin la interacción humana.

La firma

Una vez hecha toda la configuración en SAP PI, tanto en el Enterprise Service Builder como en el Integration Builder, el sistema es capaz de generar un documento PDF con la firma:

Esperamos que este tutorial os sirva de ayuda!

A partir de la versión 7.11 de Netweaver, en el WAS JAVA ha desaparecido la herramienta de JAVA Visual Administrator (/usr/sap/<system_name>/<instance_name>/j2ee/admin/go):

A cambio, han incorporado todas las tareas de administrador al portal de administración, http://server:port/nwa

Tareas como deployar un .sda/.ear, configurar el ADS para formularios Adobe…ya no se hacen desde la aplicación JAVA residente en el servidor y tienen que hacerse a través del navegador.

Una vez configurado el Message Mapping usando un RFCLookUp para ejecutar una Función RFC en un sistema remoto, hay que hacer la configuración oportuna en el Operation Mapping.

Veámos cómo:

Para ello, el Operation Mapping tiene que tener también un parámetro de tipo RFC que permita recibir la conexión SAP donde se debe de ejecutar la transformación:

Pulsando el botón parameter, se debe de crear el parámetro y después hacer el Binding con el parámetro creado anteriormente en el Message Mapping:

Una vez conectado el parámetro del Message Mapping con el del Operation Mapping, la configuración está realizada.

Para testear el Operation Mapping, ocurre lo mismo que en el Message Mapping, hay que instanciar el parámetro con un canal de comunicación existente en el Integration Builder:

Para terminar con la serie de artículos relacionados con la nueva funcionalidad de RFC LookUP, vamos a ver como usar éste objeto dentro de un Process Integration…

Con la inclusión de la posibilidad de hacer una llamada RFC a un sistema SAP Remoto desde un mapeo gráfico de PI, se ha añadido también la posibilidad de usar estos mapeos dentro de un Integration Process, BPM.

Para ello se debe de usar el Transformation Step clásico en el que SAP PI permite aplicar un Operation Mapping dentro de un BPM. El sistema es capaz de detectar que el Operation Mapping a aplicar tiene un parámetro de tipo RFC:

Una vez hecho el Integration Process, al importarlo al Integration Builder el sistema te pide que enlaces ese parámetro con un canal de comunicación de tipo RFC Receiver existente:

Hay que tener cuidado porque, si se reimporta el Integration Process al Integration Builder, el parámetro se borra y hay que alimentarlo otra vez con el canal de comunicación correspondiente.

Oreka IT presente en la primera edición de la Azoka Enpresarean

Gaur Kursaalen ospatu den Enpresarean Igo Azokan izan da Oreka IT.

Streaming bidez ikusi daiteke Iraitz Perez de Goldarazenaren hitzaldia, SAP, Oreka eta euskararen inguruan.

Laister gure laburpena irakurri ahalko duzue gure blogean, bitartean, irakurri hedabideetan argitaratu dena:

http://www.enpresarean.org/

Albistea

Esta semana hemos instalado en un par de máquinas el nuevo SAP Netweaver Business Client 4.0 (NWBC), y lo cierto es que nos hemos quedado bastante impresionados. Os contamos a continuación el porqué.

SAP NetweaverBusiness Client 4.0 Pre-requisitos

Estos son los requerimientos para la versión Desktop que se listan en la documentación más reciente de NWBC 4.0:

Microsoft .Net 3.5 SP1
Compatible con Microsoft Windows XP SP2: Hotfix 919477
Para WTS Instalación: Hotfix 955692
SAP GUI para Windows 7.30

En relación con la versión de servidor back-end ABAP requerida, la documentación todavía no es clara al respecto. De todos modos, decir que lo hemos probado con un sistema ABAP NetWeaver 7.31 (ERP6 Ehp6).

Dentro del ICF (Internet Communication Framework) en el servidor back-end, hay que usar la transacción SICF para los nodos en el servidor ICF dentro de la ruta /sap/bc/nwbc. Para más información, sigue este link.

SAP NetweaverBusiness Client 4.0 : Descarga

Sigue las instrucciones de la nota OSS 1707626 para encontrar y descargar la versión NWBC 4.0 desde la web de SAP Service Marketplace. También hay que descargar e instalar el nuevo SAP GUI 7.30 (publicado el pasado Junio).

SAP NetweaverBusiness Client 4.0 : Documentación

Puedes encontrar la versión on-line de la documentación del NWBC 4.0 aquí.

Ahora, respecto a nuestras ideas e impresiones…

SAP NetweaverBusiness Client 4.0 : Primeras impresiones

La primera cosa que llama la atención del NWBC 4.0 es que el paradigma o la forma de interactuar con el usuario es completamente diferente – en nuestra opinión, supone una evolución a mejor respecto a las versiones anteriores. Esta es la pantalla de presentación de la edición desktop después de pasar por el log-in (y después de asignar unos cuantos centros de trabajo a través de la transacción PFCFG )…

En el ejemplo de arriba la página de inicio por defecto es la ‘Index Page’, en la que se ven los Centros de Trabajo asignados. Si hacéis click sobre un Centro de Trabajo las opciones se despliegan bajo él. Se puede ver que SAP ha tratado de maximizar y racionalizar el uso de la pantalla para ayudar en la navegación.

Al hacer click sobre cualquiera de esas opciones se abre una nueva interfaz de usuario en una nueva pestaña. Esta es en nuestra opinión una importante mejora en cuanto a interacción con el sistema, ya que trata de sortear el típico problema de abrir nuevos modos o ventanas separadas, con el riesgo de perder el hilo de lo que estábamos haciendo. En cambio, al abrir nuevas aplicaciones o transacciones en nuevas pestañas tenemos más facilidad para tener nuestras cosas en orden y reducir las posibles confusiones.

Lo cierto es que se asemeja bastante a la experiencia de los modernos navegadores (tipo Google Chrome). Por ejemplo, al abrir Cost Center Manager -> Master Data -> Cost Center, la aplicación aparece en una nueva pestaña – hay que tener en cuenta que la ‘Index Page’ sigue apareciendo en la primera pestaña.

En el ejemplo de arriba, haciendo click con el botón derecho en la pestana abre la opción ‘Pin Tab’ (Fijar Pestaña). Esto quiere decir que la próxima vez que ejecutes el NWBC la pestaña de Búsqueda de Centros de Coste (en el ejemplo) estará disponible. Como os podéis imaginar, esto es una gran idea para fijar las pantallas o aplicaciones más usadas por el usuario.

Además, tenemos la opción de usar el icono de la estrella para marcar (poner una flag) a nuestras pantallas favoritas.

Otra de las ventajas claves del nuevo NWBC es que puedes tener las transacciones nativas del SAP GUI ‘conviviendo’ con aplicaciones nuevas ‘Web Dynpro’. A continuación os ponemos una transacción SAP GUI en el NWBC 4.0 – fijaos lo bien que se combina con el tema Corbu:

Tienes la opción de añadir nuevas pestañas como si efectivamente se tratara de un navegador. Al hacerlo aparece una útil página por defecto, que incluye un listado de las aplicaciones más usadas, y el histórico con las últimas aplicaciones usadas.

Primeras impresiones (Edición HTML)

En caso de que todavía no te hayas enterado, hay una edición HTML de NWBC servida directamente por el servidor ABAP. Esta edición funciona como una ‘aplicación de portal ligera’ – sin necesitar del Portal Netweaver SAP (en JAVA). Por supuesto, con NWBC para HTML no tienes las opciones más potentes que tiene el SAP Netweaver Portal, como KM, Colaboraciones, Federación, Wiki, etc…

Primero, asegurate de que el nodo ICF está activado bajo path/sap/bc/nwbc (como en los pre-requisitos mencionados arriba). Luego, te recomendamos que vayas a la tabla NWBC_CFG y utilices la transacción SE16 para añadir una entrada que active el tema Corbu para la versión HTML de NWBC.

Puedes ejecutar NWBC para HTML de manera sencilla usando la transacción ‘nwbc’ en el SAP GUI. Esta transacción abrirá una sesión browser. Ahora, si haces click en la opción ‘/nwbc’ se abrirá el NWBC en versión HTML con el tema Corbu.

Una de las características más interesantes de NWBC versión HTML es la habilidad para incrustar (embed) contenido en otros portales Web, como Sharepoint o IBM Websphere. En el ejemplo de abajo, podemos ver una aplicación con un contenedor NWBC incrustada en una página Web no-SAP.

Un detalle que nos gustaría destacar es que la página de inicio de NWBC para HTML no contiene una ‘Index Page’ como pasaba con NWBC 4.0 para Desktop. Esperamos que las versiones se lleguen a alinear pronto.

Esperamos que con este artículo os hayáis podido hacer una idea de los beneficios y el potencial de la última encarnación del SAP Netweaver Business Client.

Por favor, no te olvides de compartir con nosotros tus comentarios y opiniones en la sección de comentarios.

Con el lanzamiento de SAP Netweaver 7.3 se han introducido una serie de cambios importantes en la configuración y administración de las instancias SAP que a más de un administrador de sistemas le habrá vuelto loco hasta encontrar la nueva forma en la que SAP ha organizado todas las funcionalidades.

Hay funcionalidades que ya estaban presentes en las versiones 7.1 y 7.2, pero que en la versión 7.3 se mantienen y se amplían junto con otras que se mencionan a continuación:

1. SAP NetWever 7.3 apuesta por el verde

SAP NW7.3 se ha optimizado para conseguir un menor consumo energético desde el punto de vista de la arquitectura. En la siguiente entrada del SCN se pude ver un detalle de los cambios introducidos:

Cambios en SAP NW 7.3

2. Integración y rendimiento

Para la integración de procesos, sólo JAVA, está disponible un adaptador ligero para NW7.3, eliminando así la necesidad de ejecutar SAP NetWeaver Process Integration (SAP NetWeaver PI) en una instancia dual.

Con esta versión se puede reducir el hardware necesario como consecuencia de utilizar unas opciones despliegue JAVA comunes para todos los tipos de uso JAVA, incluyendo Enterprise Portal, SAP NetWeaver BW y SAP NetWeaver Composition Environment (SAP NetWeaver CE), con un solo servidor de aplicación JAVA.

NetWeaver Portal 7.3 usa la mitad de memoria en la navegación

El nodo de servidor arranca con NetWeaver Portal 7.3 en menos tiempo que 7.01 con una mejora del 33% de media.

3. Nombres de instancias

Desde SAP NetWeaver 7.1, las instancias de los sistemas SAP han sufrido algunos cambios. Ya no se utilizan los términos “central instance” (CI) y “dialog instance” (DI). En su lugar un sistema SAP se compone de las siguientes instancias:

Instancias de servidor de aplicación

Estas instancias se pueden instalar como “primary application server instance” (PAS) o “additional application server instance” (AAS).

Instancia central de servicios
Instancia de base de datos

4. Instancia central servicios ABAP

La instancia central de servicios para ABAP (instancia ASCS) ahora se instala en todas las opciones de instalación de sistemas SAP ABAP:

❶Sistema estándar ❷Sistema distribuído ❸Alta disponibilidad

La instancia de replicación de servicios (instancia ERS) se puede instalar junto con la instancia centrar de servicios:

Sistema estándar (opcional)
Sistema distribuído (opcional)
Alta disponibilidad (opcional)

En el momento de la instalación de la instancia SCS también se pude instalar la instancia de réplica (ERS) junto a la instancia de servicios centrales.

5. Instancias centrales de servicios ABAP – SCS

En la instalación de sistemas ABAP+JAVA, no está disponible la opción de separar la instancia ASCS (ABAP) de la instancia SCS (JAVA). Sin embargo se pueden separar posteriormente después de la instalación:

6. Separación de instancia ASCS

A partir de la nueva versión, en el programa de instalación tiene la opción de separar en dos servidores la instancia central de servicios ABAP de la instancia primaria en un sistema ABAP o un sistema de doble pila ABAP+JAVA.

7. Clave de instalación de Solution Manager

En SAP NetWeaver 7.3 ya no es necesario registrar el sistema en Solution Manager para obtener la clave del sistema que se solicitaba en el programa SAPInst de instalación.

8. Perfil de inicio desaparece

El perfil de inicio de los sistemas NW 7.3 ya no existe como tal en un fichero del directorio del perfil. En versiones anteriores de NetWeaver había un perfil Default por sistema SAP, 1 perfil de Inicio por instancia y 1 perfil de Instancia por instancia.

Con este cambio el contenido del perfil de inicio se integra con el perfil de Instancia. De esta forma leyendo este perfil SAP inicia los procesos que antes arrancaban desde el perfil de Inicio consiguiendo de esta forma reducir el número de ficheros a mantener.

9. JSPM (JAVA Support Package Manager) credenciales de conexión

A la hora de arrancar JSPM se solicitaba la contraseña del usuario SDM. Con la desaparición del SDM, ahora para arrancar el JSPM se solicita un usuarios Administrador de JAVA y su contraseña.

Al remplazar el SDM con la JSPM el directorio del SDM también desaparece quedando los siguientes directorios en sistemas JAVA:

/SIDadm$pwd

/usr/sap/<SID>/Jnn

/SIDadm$ls

data exe igs j2ee log sec work

y en sistemas ABAP+JAVA:

/SIDadm$pwd

/usr/sap/<SID>/DVEBMGSnn

/SIDadm$ls

data exe igs j2ee log sec work

Con JSPM no es posible des-deployar ficheros SCAs/EARs. Para ello se puede usar un NWDI.
Se deja de soportar ficheros PAR. Para todas las aplicaciones se utilizan ficheros EAR (Enterprise Archive) y los ficheros PAR se deben convertir a EAR para poder importarlos.

10. JCMON cambia de menú

A partir de NetWeaver 7.01 la entrada 20 del menú JCMON: Local Administration Menu deja se ser funcional

La opción Solid Rock permite visualizar el estado de los diferentes componentes/nodos. A diferencia de la versión anterior no hay una opción para refrescar la pantalla. Basta con salir al menú principal y volver a entrar a esta opción.

11. Visual Administrator se integra en NWA

Desde SAP NetWeaver 7.1, las funcionalidades del Visual Administrator se integran dentro del Netweaver Administrator (NWA)

12. Nivel de Support Packages BW – ABA/BASIS

En versiones anteriores de SAP NetWeaver, el nivel de support package del componente de BW estaba 2 niveles por encima del nivel de los componentes ABA y BASIS. En NetWeaver 7.3 estos componentes se distribuyen al mismo nivel

Artículo completo:

Siguiendo con las nuevas funcionalidades de SAP NetWeaver 7.3, que ya comenzamos con el primer artículo que publicamos recientemente y que puedes consultar aqui, [sap netweaver 7.3] , Añadimos más nuevas funcionalidades introducidas por SAP en la versión 7.3 de NetWeaver.

13. SAP JVM

En las versiones anteriores de SAP Netweaver había que tener instalada una versión del jsdk de java antes de iniciar la instalación con sapinst. A partir de la versión NW 7.3 esto ya no es necesario ya que el propio programa de instalación sapinst instala una versión sapjvm6 requerida.

El jvm de SAP proporciona estadísticas sobre los hilos, consumo de memoria, el garbage collector y actividades de E/S. Esta información se puede consultar en las herramientas de monitorización y gestión proporcionadas en el SAP Netweaver Application Server Java. Para solucionar problemas con SAP JVM, se pueden activar varias trazas que proporcionan información adicional e información sobre la VM como el sistema de carga de clases, los algoritmos del garbage collector y Entradas/Salidas.

Parchear el JVM SAP en un sistema SAP NetWeaver sólo es posible con la herramienta Java Package Manager (JSPM) pero hay problemas para la actualización de SAPJVM6 en sistemas distribuidos ya que la JSPM se inicia en la PAS y la BD al encontrarse en otro servidor no se puede actualizar.

En este caso se puede actualizar de forma manual. Primero se actualizan los parámetros de perfil para JVM 6:

_CPARG0 = list:$(DIR_CT_SAPJVM)/sapjvm_6.lst
 
_CPARG1 = source:$(DIR_CT_SAPJVM)
 
SAPJVM_VERSION = 6.1.032
 
DIR_SAPJVM = $(DIR_EXECUTABLE)$(DIR_SEP)sapjvm_6
 
jstartup/vm/home = $(DIR_SAPJVM)

Después se descomprime el paquete sapjvm6 en el directorio de jvm del kernel. Dependiendo del SO el nombre del subdirectorio puede variar. Si no se utiliza PI ni Java este directorio no existirá y no es necesaria su actualización.

14. SUM: Software Update Manager

El Software update Manager es una herramienta que sirve para varias operaciones como instalar enhancement packages o aplicar stacks de support packages.

El programa anterior conocido con SAPehpi 7.10 se ha sustituido con el SUM:

El SAP Enhancement Package Installer (SAPehpi) que se utilizaba para instalar el Enhancement Package 1 para SAP Netweaver PI / MOBILE / ABAP 7.1, se remplaza con SUM.

El Software Update Manager se puede utilizar para los siguientes procesos:

Actualizar SAP Netweaver a la versión 7.3
Aplicar stacks de support packages
Instalar Enhancement packages

Para instalar SUM ejecutar:
SAPCAR -xvf /<directory>/SUM10SP02_9-20006543.SAR -R /usr/sap/<SAPSID>

Iniciar SUM:

Con sid<adm> en el Primary Application Server ejecutar:

> /usr/sap/<SID>/SUM/sdt/exe/DSUGui

Los siguientes pantallazos pueden recordar al SAP upgrade tool y al Ehp installer:

Para más detalles revisar la nota SAP Note 1557404 – Central Note – Software Update Manager

15. CUA e IDM

SAP NetWeaver 7.3 AS Java soporta completamente los últimos estándares de seguridad como el protocolo SAML 2.0

En SAP NW 7.3, el CUA (Central User Administration) se remplaza completamente con SAP NetWeaver Identity Management. Pero no significa que NW 7.3 no soporte CUA, todavía se puede utilizar con la versión NW7.3 sin ningún problema.

Este es un escenario IDM típico de referencia:

16. Parámetros de perfil dinámicos

Para hacer el sistema más dinámico y reducir lo tiempos de parada, en la versión NetWeaver 7.3 se han cambiado varios parámetros para hacerlos dinámicos y no necesitar reiniciar el sistema para que sean efectivos.

En la transacción RZ11 se pueden ver todos los parámetros dinámicos:

Artículo completo:

Tercer y último artículo de la serie donde listamos las nuevas funcionalidades de SAP NetWeaver 7.3. Al final del mismo podrás encontrar sendos enlaces a las entregas anteriores para que no te pierdas nada. ¿Os ha parecido útil? ¿ Añadiríais algo?

17. Procesos de trabajo dinámicos

Esta característica se introdujo en la versión NetWeaver 7.0 Ehp1, pero no se utiliza frecuentemente y en NetWeaver 7.3 promueve el concepto del comportamiento dinámico de los procesos de trabajo. Se puede incrementar en número total de procesos de trabajo sin reiniciar el sistema SAP. Es distinto a lo que se puede hacer con los modos de operación en la RZ04. Para todo el detalle se puede seguir el siguiente link a la ayuda de SAP.

18. ABAP Apagado Soft

SAP NetWeaver 7.02 y 7.3 incluyen la opción parada Soft de ABAP. Hay varias opciones posibles con la ayuda de estos parámetros.

rdisp/shutdown/disable_gui_login – Este parámetro elimina las conexiones de GUI durante la parada. Esto se aplica independientemente de los roles y las autorizaciones del usuario.
rdisp/shutdown/gui_auto_logout – Define un periodo en el que el usuario puede estar inactivo durante la parada del kernel antes de que sean expulsados del sistema. Si se utiliza un valor mayor que 0, el tiempo máximo se toma del mínimo de los parámetros rdisp/gui_auto_logout y rdisp/shutdown/gui_auto_logout.
rdisp/shutdown/idle_wp_timeout – Tiempo que el kernel espera a que todos los procesos de trabajo estén en estado “waiting” antes de parar.
rdisp/shutdown/message_frequency – Frecuencia con la que se solicita a los usuarios de diálogo desconectarse antes parar el kernel.
rdisp/shutdown/j2ee_timeout – Cuánto tiempo espera la parada del kernel a que la instancia AS Java (JEE Engine) se detenga.
rdisp/shutdown/load_balance_wait_time – Cuánto tiempo espera la parada del kernel a que la información del balanceo de carga se elimine. Durante este tiempo, todas las peticiones son procesadas.
rdisp/shutdown/abap_trigger_timeout – Define cuánto tiempo espera la parada de kernel a que el evento de parada sea leído por Auto ABAP.

La opción Soft Shutdown (traducido como Parada regular) está disponible desde la transacción SM51 y desde la SAP MMC:

SAP MMC : Desde navegador Web -> http://<hostname>:5nn13
Hacer click con el botón derecho sobre la instancia a parar y pulsar sobre Stop o Restart

Se abre una ventana para seleccionar la opción Soft shutdown:

19. Asistente SSO2 más potente

A partir de NetWeaver 7.3 no es necesario utilizar la transacción STRUSTSSO2 y el link de certificados de NWA a menos que se quiera importar/exportar certificados.

El asistente SOO2 automatiza todo el proceso.

20. Netweaver 7.3 en la nube

Con el lanzamiento de NetWeaver 7.3 SAP se está enfocando en la integración en la nube, mobilidad y tareas de computación en memoria.

Desde NW 7.3 los siguientes concentradores pueden encontrarse en la nube:

SAP Enterprise Portal 7.3
SAP BW NetWeaver 7.3
SAP PI Netweaver 7.3
HANA

Para más detalles se puede consultar los siguientes enlaces:

21. Se introduce JSMON en lugar de JCMON

A partir de la versión NetWeaver 7.1 se puede utilizar JSMON igual que JCMON para monitorizar las instancias Java. jsmon pf=<nombre del perfil de instancia>

 Tecleando el comando help se obtiene la ayuda que muestra las opciones disponibles. Como se ve en el siguiente pantallazo se pueden introducir los comandos: instance,

Con estos 21 puntos se pretende mostrar algunas de las características básicas que han sufrido cambios considerables en la versión NetWeaver 7.3

Traducción del artículo de Ishteyaque Ahmad publicado en SAP NetWeaver Administrator

Artículo completo:

Podemos decir que SAP PI empezó a hacerse ‘popular’ y comercializarse de manera regular a partir de su versión SAP XI 3.0, pero ya existió un poco antes. Vamos a realizar un rápido repaso por todas las versiones por las que ha pasado SAP PI, hasta llegar a la versión mas actual y mejorada. ¿Nos acompañas en este paseo por la historia?

Evolución cronológica de SAP XI hasta SAP PIuci

XI 2.0SAP Exchange Infrastructure XI 2.0 SR1

Fecha de disponibilidad general en Mayo 2003

Fue la primera versión. Ya adelantaba algunos de los conceptos y capacidades de XI: Tecnología 100% SAP (en contra de su hermano pequeño, el Business Connector), con doble instalación: pila ABAP conjuntamente con pila Java J2EE (comunicados vía JCO RFC).

Habilitaba por primera vez el protocolo Web Service desde su concepción. Potente en cuanto a sus posiblidades de mapeo.

Sus principales carencias fueron que únicamente se liberó la versión bajo base de datos SAP DB, limitando las posibles plataformas.

También el Adapter Engine era en formato aplicación stand-alone local J2SE, con las limitaciones que conllevaba en cuanto a escalabilidad.

XI 3.0 SAP NetWeaver 2004 Exchange Infrastructure (SAP XI)

Fecha de disponibilidad general el 31 de Marzo 2004

Principal versión de SAP XI (la que generalmente se ha instalado como primera versión de XI).

Se aumenta el soporte a prácticamente todas las plataformas de Bases de Datos y Sistemas Operativos que se encuentran dentro del paraguas de SAP Netweaver 2004.

Se añade el motor BPM (Business Process Management) para orquestaciones avanzadas de flujos de procesos.

También el Adapter Engine se rediseña para ofrecerse en modo centralizado (ejecutado en la pila J2EE.

PI 7.0 -> SAP NetWeaver 7.0 (2004s) Usage Type Process Integration (PI)

Fecha de disponibilidad general en el año 2006

Versión posterior de SAP XI, donde ya se produce un cambio en el nombre. Queda obsoleta la denominación XI para empezar a usarse PI.

Se basa en el SAP Basis 7.0 (equivalente a NW 2004s ) pero funcionalmente no se diferencia respecto a XI 3.0 (los añadidos son mínimos, y son básicamente en cuanto a performance y de-bug)

PI 7.1 -> SAP NetWeaver Process Integration 7.1 (PI)

Fecha de disponibilidad general desde el 25 de Julio 2008

En su versión PI 7.1 es el Middleware SOA (Service-Oriented Architecture) de la plataforma Netweaver. Los beneficios son:

El uso como SOA backbone al ser el ESB de SAP (Enterprise Service Bus)
El uso del Enterprise Service Repository (ES Repository) para construir, modelar y gestionar Web Services
Aprovechar el soporte de estándares adicionales como UDDI, WS-BPEL, WS-RM asíncrono, etc.
Mejor rendimiento a altos volúmenes futuros y escenarios de integración críticos
Beneficiarse de nuevas funcionalidades como la Propagación de las credenciales iniciales entre emisor al receptor (basada en estándar SAML, para garantizar el cumplimiento de acuerdos de confianza), la validación XML y las capacidades de BAM (Business Activity Monitoring, comprobación del estado de los documentos a lo largo de su flujo)

PI 7.1 EHP1 -> SAP NetWeaver Process Integration 7.1 EHP1 (PI)

Fecha de disponibilidad general desde 07/2009

Enhanced Package de la versión 7 (Paquete de mejoras) , entre lo que destaca la eliminación del JAVA Administrator, incluyendo toda su gestión a través del Portal de SAP (/nwa). Esta mejora no es una novedad propia de SAP PI, sino de la plataforma Netweaver en su globalidad.

SAP PI 7.3

Fecha de disponibilidad año 2012

Dos de las características más importantes de PI 7.3 son:

Posibilidad de configurar Escenarios Integrados, los cuales no se replican en la pila Abap y se ejecutan directamente en el motor JAVA.
Relacionado con lo anterior y casi la novedad más impactante hasta ahora, posibilidad de instalar SAP PI solo con pila JAVA.

Referencias:

http://blogs.salleurl.edu - http://help.sap.com - wikipedia - deset.es

En la mayoría de páginas o aplicaciones web existe la posibilidad de pasar parámetros en las direcciones URL con el fin de publicar el mismo contenido a través de varias URLs diferentes. A las aplicaciones Web Dynpro también se le pueden pasar parámetros vía URL, para poder utilizarlos como el programador desee. Existen una serie de parámetros estándar que afectan de distinta manera en la aplicación, divididos en tres grupos:

Parámetros URL para Web Dynpro
Parámetros SAP URL
Parámetros de la aplicación Web Dynpro

En el siguiente enlace se puede ver una lista con los diferentes parámetros estándar de cada grupo. En el último grupo, a parte de los parámetros que ya existen por defecto, se pueden crear otros personalizados para una ventana Web Dynpro. En este artículo vamos a ver cómo utilizar y crear este tipo de parámetros.

Para definir parámetros propios, primero se debe modificar el plug de la ventana que se utiliza en la aplicación WD. En el método handle del plug (normalmente se utiliza default, el plug por defecto de la ventana) se pueden definir los parámetros de entrada que se quieran.

En este método es en el único sitio que se puede recoger los parámetros que creemos, así que en él se debería guardar el valor del parámetro en el contexto o en un atributo del Component Controller para poder utilizar el valor en el resto del componente.

Ahora, si se quiere dar un valor al parámetro al ejecutar la aplicación, se debe escribir el nombre del parámetro seguido de un ‘=’ y el valor que se quiera dar al final de la URL que ejecuta la aplicación, un ejemplo en el caso anterior sería:

http:// orekait.com:8000/sap/bc/webdynpro/sap/zblog?parametro1=pruebas&parametro2=X

Esto sirve para todo tipo de parámetros, tanto estándar como propios.

También existe la posibilidad de dar un valor por defecto a cualquier parámetro de la aplicación. Para ello se debe indicar su valor en la pestaña parameters de la aplicación en cuestión. En esta pestaña, se debe poner el nombre del parámetro y en la siguiente casilla el valor que tendrá por defecto.

En la ayuda de búsqueda podemos encontrar una lista de todos los parámetros de la aplicación que se pueden utilizar, tanto estándares como creados manualmente.

A primera vista puede parecer que la versión NW 2004s es una ampliación de la versión SAP Netweaver 04. Sin embargo esto no es así.

A continuación se explican algunas de las principales diferencias entre SAP Netweaver 04 y NW 2004s:

Diferencia de Release

La primera versión de SAP Netweaver se distribuyó en 2004 y tomó el nombre de Netweaver 04. Posteriormente se lanzó el primer Support Release: SR1.

La versión de los componentes BASIS de NW04 es la 640 y soporta un kernel de la versión 6.40 o 6.40 EXT que permite instalar el sistema sobre las últimas versiones de base de datos de Oracle 11g.

La segunda versión de SAP Netweaver corresponde a la NW 2004s, que posteriormente fue denominada como SAP Netweaver 7.0. De esta versión se liberaron los SR1, SR2 y SR3.

La denominación 04s puede llevar a la confusión de que se trata de una actualización de NW2004, con componentes BASIS 640, pero realmente se trata de un cambio de release tanto de los componentes de BASIS, que pasan a ser 700 como de la versión de kernel que se actualiza a la versión 7.0.

En este caso las versiones de kernel 7.20 y 7.20 EXT son compatibles con la versión NW 2004s.

Estrategias de mantenimiento de SAP

A partir del año 2005, SAP decide simplificar la estrategia de lanzamientos y mantenimiento y adopta la estrategia de 5 años de mantenimiento general, 1 año de mantenimiento extendido con una tasa 2% y 2 años mantenimiento adicional con tasa del 4%.

Con la introducción del paquete Business Suit 7 esta estrategia cambia a un mantenimiento general de 7 años y 2 años de mantenimiento extendido.

Fechas de lanzamiento

Datos de lanzamiento y mantenimiento de Netweaver04

Release to Customer: 31/03/2004
General Availability: 01/01/2005
End of Mainstream Maintenance: 31/03/2010
End of Extended Maintenance: 31/03/2013

Datos de lanzamiento y mantenimiento de NW2004s

Release to Customer: 24/10/2005
General Availability: 06/06/2006
End of Mainstream Maintenance: 31/12/2017

Rutas de actualización a versiones en mantenimiento actuales

Las posibilidades de actualización de un sistema Netweaver 2004 pasan por las siguientes opciones:

Para actualizar un sistema NW2004s se puede seguir la siguiente ruta:

Se puede encontrar más detalle de posibilidades de actualización en la página de SAP.

Equivalencia ECC y NW

A modo de conclusión se puede indicar que la versión de SAP ECC 6.0 en cuanto a nivel de componentes BASIS es equivalente a Netweaver 7.0 y que SAP ECC 5.0 cuenta con componentes de SAP Netweaver 2004.

El 10 de mayo de 2013 SAP lanzó la cuarta versión de SAP Netweaver: SAP Netweaver 7.4. Su instalación se realiza directamente con el nuevo software SAP Software Provisioning Manager (SWPM).

Tras una instalación aparentemente sin problemas, en un sistema operativo Linux con SAP kernel 7.40, el sistema no arranca y el proceso disp+work se queda en un status GRAY, Stopped:

A continuación explicamos algunas opciones para solucionar este problema y conseguir arrancar el proceso disp+work y con ello finalizar la instalación de SAP Netweaver 7.4.

Arrancar SAP NW 7.4. deshabilitando el Firewall

Para intentar arrancar el proceso disp+work se ejecuta el comando IPTABLES con el que se pueden ver los puertos abiertos en el firewall. Así y todo no se consigue arrancar el proceso.

iptables -L

Si se deshabilita el Firewall mediante el siguiente comando, el sistema arranca correctamente y permite el acceso mediante SAP Logon.

service IPTABLES STOP

Sin embargo, deshabilitar el Firewall no es una práctica recomendada, dado que se vulnera la seguridad del sistema.

Arrancar SAP NW 7.4. configurando el tráfico multicast

La solución para poder arrancar el sistema SAP con el firewall activado, es asegurarse que el sistema soporta el tráfico multicast. Esto se consigue permitiendo el tráfico UPD añadiendo las siguientes reglas en el firewall, normalmente en el fichero /etc/sysconfig/iptables:

-A INPUT -i eth0 -p udp -d 224.0.0.0/24 -j ACCEPT
...
-A OUTPUT -p udp -d 224.0.0.0/24 -j ACCEPT

Como resultado las reglas del Firewall quedarán de la siguiente manera:

Tras asegurarnos de que se soporta el multicast, el sistema arranca sin problemas:

Para más detalles del problema se pueden consultar las siguientes notas de SAP:

1932555 – Dispatcher startup issue with SAP Kernel 740

1931675 – IP multicast configuration for dispatcher wakeup mechanism

Publicar servicios web SAP puede ser la mejor solución a la hora de ejecutar funciones remotamente para obtener datos o resultados de SAP, y utilizarlos en otras aplicaciones externas, en un escenario en el que conviven un sistema SAP con otros entornos.

En este artículo dividido en dos partes explicaremos cómo publicar una función o grupo de funciones ABAP como un servicio web SAP. Además veremos cómo consumir un servicio web publicado en SAP desde otro entorno diferente.

Los servicios web permiten acceder y ejecutar un determinado código de forma remota desde cualquier sistema, independientemente de su plataforma y lenguaje de programación utilizando estándares como el protocolo HTTP, el protocolo SOAP y el lenguaje de programación XML.

Publicar una función como servicio web SAP

Para publicar un servicio web SAP a partir de una función, es necesario marcar esta como “Módulo de acceso remoto” en la pestaña de atributos en la transacción SE37.

Una vez hecho esto, hay que publicar el servicio web SAP desde el menú Utilidades eligiendo la opción “Generar servicio Web” e indicando si se desea incluir en el servicio web el módulo de funciones concreto o todo el grupo de funciones.

Tras indicar esta opción se iniciará la ejecución de un asistente a través del que se establecerán las siguientes opciones de publicación del web service SAP: nombre del servicio web y descripción; funciones a incluir (si se ha optado por incluir el grupo de funciones); tipo de autenticación y nivel de seguridad y ubicación donde guardar el servicio web SAP.

Se puede elegir entre cuatro perfiles de autenticación y seguridad:

Alta: Autenticación con certificado y garantía de transporte (HTTPS)
Media: Autenticación con usuario y contraseña y garantía de transporte (HTTPS)
Baja: Autenticación con usuario y contraseña sin garantía de transporte (HTTP)
Ninguna: Sin autenticación ni garantía de transporte

Una vez establecidos todos los parámetros del servicio web SAP, aparecerá un resumen con la descripción del mismo: propiedades, visión interna, visión externa (puede variar si se realiza un mapeo de los nombres), tipos de datos, configuración e incluso el WSDL o descriptor del servicio web SAP publicado.

Sin embargo, con esto no será suficiente para consumir el servicio web SAP desde otro entorno: falta crear el binding correspondiente, mediante el que se definirá el formato del mensaje (SOAP) así como la localización del servicio web SAP completo.

En el siguiente artículo explicaremos cómo crear estos bindings y publicar el servicio web SAP definitivamente para su consumo desde otra aplicación.

En el anterior artículo se vio cómo publicar servicios web en SAP a partir de una función o grupo de funciones. Sin embargo, quedó pendiente explicar cómo crear los bindings necesarios para completar el WSDL que describirá el servicio web SAP para su consumo desde otro entorno o aplicación externa.

Crear el binding para activar servicio web SAP

Mediante el binding se determina el formato de los mensajes y protocolos usados para el servicio web. En este caso vamos a publicar un servicio web SAP basado en el protocolo SOAP.

En SAP este paso se efectúa desde la transacción SOAMANAGER:

En el apartado “Web Service Configuration” hay que realizar una búsqueda del servicio web SAP a partir del nombre especificado durante su creación.

Existen tres categorías de búsqueda mediante las que se pueden filtrar los servicios web:

Service Definition (publicar servicio web SAP)
Consumer Proxy (consumir servicio web SAP)
Service Group (grupo de servicios web SAP)

En este caso, filtramos por la primera categoría y seleccionaremos el servicio web a publicar pulsando el botón “Apply Selection” con lo que aparecerá un nuevo grupo de pestañas en la parte inferior.

En la pestaña “Configurations” hay que crear una nueva configuración para publicar el servicio web SAP seleccionado pulsando el botón “Create”. Con esto, aparecerá una ventana emergente en la que se solicitarán el nombre del servicio web, su descripción y el nombre del binding a crear.

A partir de estos datos, aparecerá un tercer grupo de pestañas en el que sólo quedará establecer los detalles de esta nueva configuración o binding:

Perfil de autenticación y seguridad correspondiente con lo establecido al crear el servicio web.
Versión SOAP: SOAP 1.1. o SOAP 1.2.
Mensajes
…

Para guardar la configuración y activar el servicio web SAP no hay que olvidar pulsar el botón “Save”. Una vez hecho esto, estará disponible el WSDL completo del servicio web SAP creado pulsando el enlace “Open WSDL document for selected binding on service”.

En el WSDL entre otros aspectos importantes se podrán obtener las rutas de las acciones (funciones SAP publicadas como servicio web SAP) y la localización del propio servicio web SAP.

Después de publicar el servicio web SAP, con la información ofrecida por este fichero ya es posible consumir el servicio web SAP desde cualquier otra aplicación sea cual sea su plataforma y su lenguaje de programación.

Las tablas de customizing de SAP sólo pueden ser modificadas por un usuario a la vez. Esto es debido a que están protegidas por bloqueos que no permiten la actualización simultánea de los datos. En ocasiones puede ser interesante eliminar bloqueos SAP, como por ejemplo en un curso de formación donde varios usuarios deben actualizar la misma tabla al mismo tiempo. En el siguiente artículo se muestra cómo se pueden desbloquear tablas SAP que hayan sido bloqueadas automáticamente por el sistema.

Para eliminar los bloqueos SAP sobre las tablas de customizing, y así poder acceder varios usuarios a modificar las mismas tablas hay que seguir los siguientes pasos:

1. Crear tabla de bloqueos SAP

En primer lugar, se debe crear una tabla de bloqueos SAP del diccionario para guardar qué mandantes están desbloqueados. La tabla debe tener la siguiente estructura:

En esta tabla, si el registro de un mandante tiene `X` el campo FLAG, querrá decir que en ese cliente existen bloqueos. Si por el contrario en el campo se pone el carácter ‘O’ no funcionará el bloqueo de tablas, por lo tanto dos o más usuarios podrán modificar simultáneamente la misma tabla.

2. Programas para bloquear/desbloquear tablas SAP

Se pueden crear dos programas, uno para bloquear y otro para desbloquear tablas SAP, que guardarán en la tabla anterior el estado del mandante donde se ejecute.

Desbloquear mandante SAP

Creamos un programa con el nombre ZSEQOFF y le pegamos el siguiente código:

TABLES: zenq.
DATA: off.
IF sy-mandt = '000'.
  MESSAGE 'Esta función no se permite en el mandante 000' TYPE 'A'.
ENDIF.
SELECT SINGLE FOR UPDATE * FROM zenq WHERE sysname = syst-sysid
                                     AND mandt = syst-mandt.
IF sy-subrc = 0.
  zenq-flag = 'O'.
  UPDATE zenq.
  IF sy-subrc = 0.
    off = 'X'.
  ELSE.
    off = ' '.
  ENDIF.
ELSE.
  zenq-sysname = syst-sysid.
  zenq-mandt = syst-mandt.
  zenq-flag = 'O'.
  INSERT zenq.
  IF sy-subrc = 0.
    off = 'X'.
  ELSE.
    off = ' '.
  ENDIF.
ENDIF.
IF off = 'X'.
  WRITE: / 'Desbloqueos desactivados (dependiente de mandante)'.
ELSE.
  WRITE: / 'Error al desactivar los desbloqueos'.
ENDIF.

Al ejecutar este programa, se crea o modifica un registro en la tabla con el nombre de la máquina y el cliente en el que se está ejecutando. A este registro se le pone en el campo FLAG de la tabla ‘O’, de manera que se eliminarán los bloqueos SAP automáticos.

Bloquear mandante SAP

Creamos un programa con el nombre ZSEQON y le copiamos el siguiente código:

TABLES: zenq.
DATA: on.
SELECT SINGLE FOR UPDATE * FROM zenq WHERE sysname = syst-sysid
                                     AND mandt = syst-mandt.
IF sy-subrc = 0.
  zenq-flag = 'X'.
  UPDATE zenq.
  IF sy-subrc = 0.
    on = 'X'.
  ELSE.
    on = ' '.
  ENDIF.
ELSE.
  on = 'X'.
ENDIF.
IF on = 'X'.
  WRITE: / 'Bloqueos activados (dependiente de mandante'.
ELSE.
  WRITE: / 'Error al activar los bloqueos'.
ENDIF.

Este programa tiene la misma funcionalidad que el programa anterior, con la diferencia que escribe ‘X’ en el campo FLAG del registro. Con ello se consigue que los bloqueos en el sistema se encuentren activados.

3. Modificar include

Para que los desbloqueos de las tablas SAP surtan efecto, es necesario modificar un include estándar. Para ello vamos a la transacción SE80 y elegimos el objeto de desarrollo LSENAF01. Para modificar un objeto estándar hay que registrar el objeto en SAP. En la línea 242, introducimos tras el código rc = SY-SUBRClas siguientes líneas:

IF syst-mandt <> '000'.
  DATA e_zenq TYPE zenq.
  SELECT SINGLE * FROM zenq INTO e_zenq
    WHERE sysname = syst-sysid AND mandt = syst-mandt.
  IF  e_zenq-flag = 'O'.
    rc = 0.
    EXIT.
  ENDIF.
ENDIF.

Este include se ejecuta cada vez que se intenta acceder a una tabla o vista de actualización de una tabla de customizing. Si el campo RC es distinto de 0, querrá decir que la tabla está bloqueada por algún usuario. Al introducir este código, leemos de la tabla el registro del cliente en el que nos encontremos, y si su campo FLAG está marcado, omitirá el aviso de que la tabla SAP se encuentra bloqueada.

Con estos pasos podremos hacer que las tablas de la SPRO no sean bloqueadas por un usuario, de manera que varios puedan modificarlas al mismo tiempo. Hay que tener cuidado con esto, ya que es algo peligroso ya que si dos usuarios modifican un mismo registro de manera inadecuada puede dar lugar a errores graves. Por lo tanto, se recomienda sólo eliminar bloqueos SAP en cursos y máquinas de formación, para poder agilizar el tiempo del curso.

Hace un tiempo publicamos dos artículos sobre cómo publicar un servicio web SAP. En esta ocasión, vamos a ver cómo consumir un servicio web SAP desde una plataforma completamente diferente como puede ser una aplicación web, concretamente cómo consumir un web service de SAP con PHP.

Realmente el método para consumir un servicio web con PHP es equivalente sea este un servicio web SAP o no. Tomamos el ejemplo de un servicio web SAP para dar continuidad a los artículos anteriores y ver cómo pasarle las credenciales de usuario.

Acceso al WSDL para consumir servicio web SAP

En primer lugar, a la hora de consumir un servicio web SAP o no SAP, debemos obtener los datos de este disponibles en su descriptor WSDL.

Tal y como vimos en el segundo artículo sobre publicar servicios web en SAP, desde la transacción SOAMANAGER se puede acceder al fichero WSDL del servicio web a consumir de donde es posible extraer las funciones disponibles desde ese servicio web y la manera en la que pueden ser accedidas.

Cliente SOAP para consumir servicio web SAP

Para consumir un web service SAP, php es una buena opción ya que definiendo unas pocas líneas de código podemos acceder y utilizar funciones SAP desde una aplicación web.

En primer lugar se debe crear un cliente SOAP a partir de la URL del fichero WSDL del servicio web SAP y de la localización del servicio que se va a consumir.

$location_URL = 'http://ruta_sevicio_web.com/zlast_news2/100/zlast_news2/zb_last_news2';
$wsdl = 'http://ruta_servicio_web.com/wsdl/srvc_00505692214C1EE3B6D524ADE1ECD0F4/wsdl11/allinone/standard/document?sap-client=100?wsdl';

Para ello se crea una instancia de la clase SoapClient de PHP, indicando las opciones que correspondan en cada caso.

Según el nivel de autenticación indicado al crear el servicio web puede ser necesario la especificación de usuario y contraseña. Estos datos se han de pasar al crear el cliente SOAP y no al llamar a una acción. En realidad esta información se transfiere a través de la cabecera del mensaje SOAP. Por tanto, un ejemplo de cliente SOAP para consumir un web service SAP con PHP sería el siguiente:

$client = new SoapClient($wsdl, array(
			'location' => $location_URL,
			'uri'      => "",
			'trace'    => 1,
			'login'    => $usuario,
			'password' => $pass
			));

Consumir web service SOAP de SAP con PHP

Una vez disponemos del cliente SOAP creado en PHP, hay que llevar a cabo una llamada a la acción del servicio web SAP que se desee. En PHP existe un método propio de SoapClient que devuelve la lista de funciones disponibles en el servicio web: __getFunctions.

Suponiendo que la función que deseemos consumir del servicio web SAP sea ZNEWS_FM_GET_ULTIMAS_NOTICIAS la forma de llamarla y pasarle los parámetros de entrada necesarios es la siguiente:

try{
		$response = $client->ZNEWS_FM_GET_ULTIMAS_NOTICIAS(array("IM_NUM_NOTICIAS" => "5"));
		$xml = simplexml_load_string($order_return);
		foreach( $xml->children() as $child ) {
			echo $child->FECHA_CREACION;
		}
	}
	catch (SoapFault $exception){
		var_dump(get_class($exception));
		var_dump($exception);
	}

En la variable $response obtendremos el resultado de la llamada a la función que tendrá el formato indicado en el WSDL como mensaje de respuesta.

Una vez disponemos de la respuesta en PHP podemos extraer de esta los datos que deseemos y formatearla como sea conveniente en cada caso. Como se puede comprobar una vez se dispone del descriptor WSDL, es muy sencillo consumir un servicio web con PHP.

En el anterior artículo sobre la configuración del SAP SNC sin Single Sing-On en Linux/Unix se detalló como descargar los paquetes de librerías del marketplace, descomprimirlos en el servidor y crear un usuario en el Active Directory. En esta ocasión, se van a explicar los pasos para configurar el SNC en el servidor ABAP.

1. Configuración de certificados en servidor ABAP

En primer lugar, hay que establecer la variable de entorno SECUDIR al directorio /usr/sap/<SID>/<Instancia>/sec.
Después, acceder al directorio /usr/sap/<SID>/<Instancia>/SLL para crear el entorno PSE.
Crear una entrada para el SPN creado antes. Para ello se ejecuta “./snc crtkeytab -s <SPN>@<DominioActiveDirectory>”. La contraseña que se solicita debe ser la misma que la del usuario creado en el dominio. Hay que tener en cuenta que la parte de <DominioActiveDirectory> debe ir en mayúsculas.

2. Configuración de parámetros de perfil

A continuación se detallan los valores que se deben configurar en los distintos parámetros de perfil:

snc/permit_insecure_start = 1
snc/accept_insecure_cpic = 1
snc/r3int_rfc_qop             = 8
snc/r3int_rfc_secure         = 0
snc/data_protection/use     = 3
snc/data_protection/min   = 2
snc/data_protection/max   = 3
snc/identity/as                  = p:CN=<SPN>@<ActiveDirectoryDomain>
snc/gssapi_lib                   = /usr/sap/<SID>/<Instance>/SLL/libsecgss.so
snc/enable                         = 0
snc/force_login_screen     = 1
snc/accept_insecure_rfc   = 1
snc/accept_insecure_gui   = 1
ssf/name                           = SAPSECULIB
ssf/ssfapi_lib                     = $(ssl/ssl_lib)
ssl/ssl_lib = $(DIR_EXECUTABLE)$(DIR_SEP)$(FT_DLL_PREFIX)sapcrypto$(FT_DLL)
sec/libsapsecu                   = $(ssl/ssl_lib)

Con el parámetro snc/enable desactivado (valor 0) se reinicia la instancia para que los parámetros tengan efecto.
Se accede al sistema y en la transacción STRUST se debe crear el certificado PSE en el nodo “SNC Cryptolib”. El valor viene dado por los parámetros indicados.
A continuación se reinicia de nuevo la instancia, esta vez con el parámetro snc/enable activo (valor 1).

3. Activar configuración de seguridad SCN

En el cliente del usuario, el programa SAP GUI en Windows, tras instalar el paquete SNC CLIENT ENCRYPTION hay que modificar la entrada del SAP Logon para activar la parametrización de seguridad SNC:

Tras realizar estos pasos de configuración, podremos observar que al acceder al SAP GUI aparecerá el candado que indica el estado del SNC cerrado, y por lo tanto dispondremos del Secure Network Communication activado.

La cada vez más extendida factura electrónica sigue siendo un verdadero quebradero de cabeza para las empresas que trabajan con SAP.

Además, muchas administraciones están adoptando su propia solución de facturación electrónica y obligan a sus proveedores y clientes a hacer uso de la misma. Esto hace que desde SAP debas adaptarte a todas las administraciones y sistemas de facturación con los que tengas que intercambiar, bien sean facturas, bien otro tipo de documentación oficial como por ejemplo nóminas, certificados…

Conector SAP para firma electrónica de entidad

A la espera de la solución estándar que vaya a proponer SAP, Oreka IT ha desarrollado un módulo que permite firmar toda la documentación que quieras sacar de tu sistema SAP.

Tan sólo tienes que disponer de un certificado de entidad, por ejemplo uno de Izenpe, de la casa de moneda y timbre, etc. para poder subirlo a la Key Store de la pila JAVA de tu sistema SAP PI:

Deberás conocer la contraseña del certificado para configurar el módulo de firma electrónica:

Y con estos sencillos pasos de configuración ¡ya podrás firmar todos los documentos que desees!

Acciones permitidas por el Módulo de Firma

El módulo de firma está preparado para que puedas realizar las siguientes acciones:

Comprimir/descomprimir
Firmar individualmente
Firma masiva
Cifrar/Descifrar

Y por supuesto todas las combinaciones entre las diferentes acciones. Por ejemplo, se podría mandar un .ZIP con tantos documentos como se quisieran, y el módulo se encargaría de descomprimir el paquete, firmar electrónicamente cada documento individualmente, y /o volver a comprimir el paquete.

Requisitos de sistema

Para poder hacer uso del módulo de firma necesitarás, como ya hemos comentado, un certificado de entidad y subirlo al sistema.

Además tendrás que tener un sistema SAP PI para poder deployar el módulo de firma y subir el certificado.

¿Más información?

¿Te interesa? ¿Quieres más información? Ponte en contacto con nosotros!

Después de explicar en artículos anteriores en qué consiste esto de SAP Fiori UX, la nueva apuesta de SAP para hacer por fin la interfaz de usuario más amigable, sencilla y accesible desde cualquier dispositivo, en esta ocasión vamos a explicar cómo debe ser la arquitectura que debemos de tener en nuestros sistemas SAP para poder usar SAP Fiori UX.

Tal y como se puede ver en la imagen anterior, será necesario montar la siguiente arquitectura SAP Fiori UX:

1. Reverse Proxy (o similar)

La apuesta y recomendación de SAP en este sentido, lógicamente es montar un SAP Web Dispatcher, pero podría valer cualquier otra solución similar.

2. Servidor SAP Front-End

Este servidor tiene que tener SAP Netweaver Gateway: aquí os dejamos una presentación de SAP explicando qué es esto del Gateway. Básicamente es un sistema que nos permite publicar aplicaciones mediante el uso del oData o REST.

Este servidor Front-End utilizará SAPUI5: en esta máquina tendremos que instalar un montón de parches y Add-ons para que tengamos el SAP Fiori Launchpad accesible, el cual se encargará de renderizar todo el sistema en HTML5.

3. Servidor SAP Back-End

Este servidor SAP Back-End se corresponde con todos los sistemas que tengamos que “consumir” a través de SAP Fiori UX, bien sea nuestro SAP ERP o nuestro SAP CRM…es decir, los sistemas donde residen nuestros datos.

Aquí también hay varios trucos y es que, a nivel de parches también se exige bastante, por lo menos SAP Netweaver 740 SPS07.

Además, cada aplicación SAP Fiori UX que queramos publicar en el SAP Fiori Launchpad y consumir lleva un Add-On asociado que hay que instalar. Como podéis ver en la siguiente imagen existen aplicaciones específicas para solicitud de vacaciones, imputaciones de horas…

4. Base de datos y SAP HANA

Tanto en el gráfico inicial, como en toda la documentación de SAP nos encontraremos con SAP HANA.

Hay que decir que no es obligatorio tener SAP HANA para usar SAP Fiori UX, sin embargo, sin SAP HANA la potencia del segundo se ver reducida bastante. En próximos artículos os contaremos los tipos de aplicaciones SAP Fiori UX que se pueden consumir y entenderemos mejor este aspecto.

Este es por tanto, otro pequeño truco que nos mete SAP en medio y es que SAP HANA viene pegando fuerte. Hay que tener claro que para instalar SAP Fiori UX, primero hay que hacer muchas cosas antes y dejarlo todo bien ordenadito: HANA, parches, SPS…