La informática móvil y en la nube abren el camino al código abierto

A menudo, un proceso de negocio en una empresa se gestiona a través de varias estaciones o departamentos hasta que el proceso se completa. Los empleados implicados tienen perfiles diferentes: desde expertos en SAP hasta usuarios ocasionales.

Para facilitar al máximo la integración de los usuarios ocasionales en los procesos empresariales, es aconsejable utilizar las tecnologías de interfaz de usuario (UI) existentes. Así se reduce el tiempo de formación y aumenta la aceptación de los usuarios.

A menudo se encuentran tecnologías como Microsoft SharePoint. Si ahora la información almacenada en SAP puede visualizarse y editarse directamente en SharePoint sin redundancias, el umbral de entrada de datos en el sistema SAP se reduce drásticamente.

La calidad y puntualidad de los datos son cada vez mayores. Sin embargo, los empleados también utilizan cada vez más soluciones móviles como tabletas o smartphones. Cómo pueden estos nuevos grupos de usuarios acceder a los datos disponibles en el sistema SAP de la forma más sencilla y segura posible?

Cuando se trata de plataformas de medios sociales, también se plantea la cuestión de cómo pueden crearse nuevas soluciones innovadoras vinculando más estrechamente las plataformas con los datos críticos de la empresa en el sistema SAP.

La configuración de variantes integrada en SAP ERP ofrece una potente solución para iniciar procesos de producción, así como procesos en el back office, en función de la selección de la configuración en el pedido de cliente.

Para simplificar aún más la introducción de la configuración, la opción de entrada en este estudio ha sido posible gracias a un modelo tridimensional integrado que visualiza inmediatamente los atributos seleccionados.

De este modo, las entradas pueden comprobarse visualmente y corregirse de inmediato, aumentando al mismo tiempo la aceptación por parte de los usuarios finales. Otro ejemplo es la solución SAP Citizen Connect.

Basándose en funciones del sistema SAP, se creó aquí una solución móvil que permite a los residentes de una ciudad o municipio enviar problemas o quejas directamente desde el dispositivo móvil al sistema SAP. De este modo se eliminan pasos intermedios antes necesarios, como llamar a una centralita con información imprecisa sobre la ubicación.

Con esta información adicional, ahora es posible tomar una decisión oportuna basada en hechos correctos. Y la respuesta directa al denunciante aumenta la motivación para denunciar en el futuro quejas que, de otro modo, pasarían desapercibidas.

Enfoques de solución para no ABAP

Dado que el sistema SAP es abierto, los escenarios mencionados pudieron realizarse técnicamente hace mucho tiempo. Sin embargo, el inconveniente era que en cada caso se utilizaban soluciones punto a punto.

Además, el desarrollador de la solución no SAP necesitaba un profundo conocimiento detallado del sistema SAP. Desgraciadamente, no siempre se dispone de desarrolladores con un buen nivel de conocimientos tanto de SAP como de otros lenguajes de desarrollo.

Como consecuencia, los proyectos se prolongan o se encarecen y el mantenimiento sólo puede concederse con dificultad, ya que el frontend en particular sigue desarrollándose de forma dinámica. Los clientes y socios actuales de SAP suelen estar muy familiarizados con el lenguaje de programación ABAP.

Sin embargo, los conocimientos de ABAP no están muy extendidos en otras comunidades de desarrolladores, en las que predominan C, Java, Objective-C, PHP o C#. Por este motivo, hoy en día también es habitual encontrar en las empresas dos estructuras organizativas paralelas: un departamento para dar soporte a los sistemas SAP y otro para ocuparse de las cuestiones ajenas a SAP.

El objetivo de NetWeaver Gateway era también reducir las barreras de comunicación entre los dos equipos. En la búsqueda de una herramienta que pudieran entender tanto los expertos de SAP como los que no lo son, se optó por el protocolo OData basado en REST. Este protocolo está en proceso de convertirse en un estándar Oasis para acelerar su difusión.

Pasarela SAP NW

NetWeaver Gateway proporciona una herramienta que acelera y estandariza el desarrollo de los servicios REST necesarios en los sistemas SAP basados en ABAP.

El desarrollador se encarga de muchas actividades que no están directamente relacionadas con el desarrollo del servicio, como el soporte de dialectos (XML o JSON), la preparación de mensajes, el análisis de mensajes y la supervisión central. Un proceso típico para el desarrollo de una nueva interfaz de usuario puede ser el siguiente (de forma simplificada):

• En un taller conjunto entre los usuarios -normalmente representados por un usuario clave, los expertos en interfaces de usuario y los expertos en el backend de SAP- se define y perfila la nueva interfaz de usuario deseada.
• A partir de los resultados del taller, se derivan los requisitos para el backend y el frontend de SAP. Estos requisitos pueden documentarse en un modelo de relación de entidades. Este documento es el punto de partida para los siguientes pasos. Puede importarse a un sistema SAP, así como a las herramientas de desarrollo del frontend.
• Ahora se están realizando los desarrollos necesarios tanto en el backend como en el frontend.

OData está llegando

El protocolo OData se basa en estándares abiertos como HTTP, XML, JSON o AtomPub. Los operadores ya conocidos y definidos por HTTP como Get, Post, Put, Patch o Delete tienen siempre el mismo significado.

La arquitectura basada en REST también permite a los desarrolladores que no tienen conocimientos especiales de SAP empezar a desarrollar con herramientas estándar sin necesidad de mucha formación.

Definición de un modelo OData: Un modelo entidad-relación sirve de base para definir el servicio. Cada servicio definido proporciona un documento de metadatos. Este documento de metadatos, que tiene la misma estructura en todos los casos, abstrae y alinea los datos de los sistemas back-end.

Si, por ejemplo, el modelo de una interfaz de usuario prevista se construye a partir de los objetos producto, fabricante y categoría de producto, el modelo deseado se modela en un documento XML (EDM). Para transferir el modelo a OData, es necesario conocer los conceptos subyacentes de OData:

• Conjunto de entidades: en el ejemplo anterior, "Producto" sería un conjunto de entidades. Es comparable a las listas o entradas de una tabla. Todas las entradas (o entidades) de un conjunto de entidades tienen el mismo tipo de entidad.
• Entidades: son instancias del tipo entidad. Pueden estar estructuradas y tener un elemento clave (clave de entidad). La estructura de una entidad se define mediante propiedades. Se puede acceder a una entidad individualmente a través de la clave. Se pueden devolver varias entradas mediante una búsqueda.
• Clave de entidad: consta de propiedades. Esta clave es importante para poder identificar de forma unívoca las entradas individuales. También es necesaria para definir asociaciones entre tipos de entidades.
• Asociación: es la conexión con nombre entre dos tipos de entidad. Cada asociación consta de dos extremos que definen los tipos de entidad y la cardinalidad (1:N, 1:1).
• Propiedad de Navegación: Se utiliza para la navegación entre entidades y está vinculada a la Asociación y al Tipo de Entidad.
• EntityContainer: aquí se agrupan todos los conjuntos de entidades que pertenecen a un servicio.

Esta metodología puede ilustrarse mejor con el ejemplo expuesto anteriormente: Las propiedades del proveedor son: ID (Clave de entidad), Nombre, Dirección, Concurrencia y Productos (Propiedad de navegación).

El EntityContainer llamado DemoService consiste en los siguientes EntitySets y Asociaciones entre los diferentes objetos (que no están listados aquí): Productos, Categorías y Proveedor. Se define un modelo basado en estos principios.

Operaciones basadas en el modelo: Si este modelo está definido, pueden realizarse operaciones sobre el modelo en tiempo de ejecución. Estas operaciones pueden ser, por ejemplo, buscar, actualizar, eliminar.

Se puede acceder a una lista de todos los productos con la URL http://services.odata.org/OData/OData.svc/Products/ mostrar. Este listado puede restringirse aún más añadiendo un parámetro de búsqueda como $top.

La dirección http://services.odata.org/OData/OData.svc/Products/?$top=3 ahora sólo muestra los tres primeros productos. La respuesta consiste en un documento XML o JSON con el nombre de las propiedades y sus valores.

Además, las propiedades de navegación en la respuesta se marcan con
salida. Los objetos enlazados (categoría y proveedor) se pueden llamar ahora directamente utilizando sus propias URL.

Los desarrolladores que no conozcan en profundidad el sistema backend utilizado también podrán navegar fácilmente a través de las URL devueltas. Ahora se puede acceder directamente a los detalles de las categorías y los proveedores.

Operaciones de consulta: Muchas interfaces de usuario se basan en patrones similares y sencillos. Muy a menudo, estos patrones comienzan con la introducción de una búsqueda. OData tiene varias formas de formular una búsqueda. Todos los operadores van precedidos de un $.

A continuación se formula una consulta de todos los productos con un precio inferior a 20: http://services.odata.org/OData/OData.svc/Products/?$filter=Price le 20.

Si sólo necesita los valores precio y nombre de este resultado, puede utilizar $select para definir las columnas de la respuesta: http://services.odata.org/OData/OData.svc/Products?$select=Price,Name.

Las respuestas también se pueden ordenar por $orderby. Por supuesto, este comando sólo tiene sentido cuando se obtiene una lista. En este ejemplo, los productos están ordenados:

Con $top y $skip, las áreas específicas de un resultado más amplio pueden reducirse a paquetes individuales, que luego se transmiten según sea necesario con un bajo consumo de recursos.

http://services.odata.org/OData/OData.svc/Products?$skip=2&$top=2&$orderby=Rating transfiere la tercera y cuarta fila de productos, ordenados por puntuación.

De la definición a la aplicación

Una vez definido el comportamiento deseado, puede iniciarse la implementación del servicio requerido en el sistema SAP. Para apoyar al desarrollador del servicio requerido de la mejor manera posible, NetWeaver Gateway ofrece soporte para los diferentes casos de uso.

Se distingue en detalle entre la definición y la implementación de un servicio. Todos los pasos siguientes tienen lugar en el Service Builder. Se trata de la interfaz central de NetWeaver Gateway para la definición e implementación de servicios.

Para definir un servicio, el modelo de datos se define según la sintaxis OData descrita anteriormente. El modelo de datos puede definirse de forma declarativa mediante entrada manual.

El Service Builder soporta aquí la definición con una estructura de carpetas basada en el modelo de datos OData, en la que las categorías como relaciones o entidades pueden introducirse en forma tabular. Alternativamente, el modelo de datos también puede definirse importando un modelo de datos ubicado fuera del sistema SAP.

Además, el modelo de datos puede definirse basándose en estructuras e información del sistema SAP subyacente (interfaces DDIC/RFC o BOR) y haciendo referencia a modelos de objetos del sistema SAP. Muchos objetos se desarrollan internamente de forma orientada a objetos.

Por lo tanto, es relativamente fácil transferir estos objetos internos a los servicios OData. Algunos ejemplos son PLM, EAM o CRM. Pero las consultas de Business Warehouse o las vistas de Hana también pueden convertirse fácilmente en un servicio OData.

Además, aquí se crea automáticamente la implementación. Si ya existe un servicio desarrollado a través de NetWeaver Gateway, se puede desarrollar un nuevo servicio basado en el antiguo.

Esto puede ser útil si, por ejemplo, es necesaria una ampliación o modificación pero no se puede cambiar el servicio original.

Especialmente en escenarios basados en BW, las consultas contenidas pueden convertirse en servicios OData a través de los generadores de Service Builder. Dado que no todas las consultas son adecuadas para su uso como servicios OData, las consultas deben marcarse con un indicador Easy Query en el BW Query Designer antes de utilizarlas en el Service Builder.

Si no se puede convertir la consulta, no se puede activar este indicador. Otra opción para integrar información de SAP BW es el formato MDX. Este formato también se puede convertir en un servicio OData a través del generador.

La implementación de los servicios definidos en el sistema SAP puede hacerse ahora de dos maneras: mapeando el modelo OData a módulos de función existentes en el sistema SAP como RFC, BAPI, BOR.

Se puede utilizar un módulo de función independiente para la asignación de cada método (eliminar, leer, añadir). El mapeo se lleva a cabo en el Service Builder de una manera fácil de usar mediante arrastrar y soltar. O mediante implementación manual a través de las herramientas estándar de SAP en ABAP.

El complemento backend proporciona una superclase que debe reimplementarse en consecuencia. Cada método (leer, borrar, buscar) se desarrolla por separado. Este método contiene la lógica real, es decir, la codificación que lee o actualiza los módulos de función y las tablas correspondientes.

Si se ha especificado una asociación entre entidades en la definición del modelo - como de producto a categoría - entonces esta asociación también debe implementarse en el Service Builder.

Todas las implementaciones y la codificación generada se crean en el denominado espacio de nombres del cliente. Por un lado, esto tiene la ventaja de que siempre es posible realizar ajustes manuales. Por otro lado, esto se apoya en un concepto de puntos de ampliación.

Por otro lado, las herramientas comunes del entorno ABAP se utilizan para la gestión y el transporte del código fuente. Como resultado de la definición e implementación, se ha creado un servicio OData funcional.

Una vez creado el servicio, el siguiente paso es activarlo. El trasfondo de este paso es que, teóricamente, la implementación del servicio puede ubicarse en un sistema SAP distinto del servidor NetWeaver Gateway central.

El registro da a conocer el servicio en el sistema central y lo añade a un catálogo central de servicios OData. Dentro de la interfaz de usuario para el registro y la activación también hay herramientas que resultan útiles para solucionar problemas y realizar pruebas.

Así, todas las funciones necesarias para la definición e implementación se encuentran en un mismo lugar en el Service Builder, mientras que todas las herramientas para gestionar un servicio ya existente se encuentran en la interfaz de usuario para el registro y la activación.

Interfaces de usuario

Visual Studio LightSwitch: Ahora que el servicio correspondiente se ha implementado o generado en el sistema SAP, el servicio se puede utilizar directamente en diferentes interfaces, en función de los requisitos.

Al utilizar un estándar abierto, existen muchas opciones y proveedores compatibles con el formato OData. Merece la pena mencionar aquí Visual Studio LightSwitch de Microsoft, ya que ofrece una solución abierta para crear aplicaciones más complejas basadas en plantillas que pueden ampliarse y adaptarse fácilmente tras su generación.

Estas plantillas también pueden vincularse a servicios OData en el asistente de creación. Y desde la versión 2010 de Microsoft Excel, es posible leer en Excel un servicio OData existente y mostrar su contenido en la vista de tabla.

Por supuesto, hay que hacer algunos ajustes durante la conversión, por lo que las relaciones se almacenan en tablas. Para ello, es necesario instalar el complemento gratuito Power Pivot Add-on para Excel 2010.

Aunque Excel no puede actualizar los datos del sistema SAP mediante esta opción, es fácil visualizar valores y realizar análisis basados en Excel.

Herramientas de consumo externas: Las extensiones se ponen a disposición a través de SAP Community Network para ayudar a crear aplicaciones basadas en HTML5 (jQuery mobile o SAP UI5), Android, iOS, Java, PHP o .Net.

El desarrollador cuenta con el apoyo de las extensiones basadas en asistentes. Este asistente analiza el servicio OData, por ejemplo, para identificar las relaciones y los atributos. Dependiendo de la tecnología de la interfaz de usuario, el detalle de la lista y, a veces, el flujo de trabajo están disponibles como plantillas.

En el siguiente paso, el desarrollador debe definir las imágenes, su orden y los campos visibles en ellas. A continuación, se genera el código fuente, que puede utilizarse como base para la personalización.

Muchos elementos, como los proxies, pueden utilizarse entonces directamente como base para la programación individual de la aplicación. Con tecnologías móviles como iOS o Android, la comunicación tiene lugar inicialmente directamente desde la aplicación a través de OData a NetWeaver Gateway.

Si se utiliza SAP Mobile Platform, es muy fácil cambiar la comunicación en los proxies centrales a Mobile Platform, el resto de la aplicación móvil y los servicios creados en el sistema SAP pueden seguir siendo los mismos.

SAP UI5: Muchos fabricantes de navegadores y de herramientas para crear y mantener sitios web trabajan actualmente en el tema de HTML5. SAP también trabaja en ello.

Dado que la empresa de Walldorf se centra en dar soporte a procesos empresariales críticos, también se ha optimizado la compatibilidad con HTML5.

El uso del marco SAP UI5 facilita la creación de interfaces basadas en HTML5. Esto se consigue, por ejemplo, proporcionando controles que ofrecen un aspecto uniforme y una creación más sencilla.

Componentes utilizados

La solución NetWeaver Gateway consta de dos componentes simplificados, un plug-in de backend y el servidor de gateway propiamente dicho. El plug-in de backend contiene las funcionalidades necesarias para integrarse directamente en el backend.

El ejemplo más destacado es el Service Builder como entorno central de desarrollo y modelado. El Gateway Server contiene las funciones de servidor. Aquí es donde convergen de forma centralizada todos los plug-ins backend, donde se generan los archivos XML, donde se reciben las respuestas y mucho más.

Las autorizaciones y el acceso al sistema SAP desempeñan un papel importante. El servidor de aplicaciones NetWeaver ABAP ya incluye soporte para muchos protocolos como SAML 2.0, X.509, autenticación básica o SSO2 Token.

Por lo tanto, estos protocolos pueden utilizarse directamente para la comunicación con el sistema NetWeaver Gateway. Ahora se puede distinguir entre varias arquitecturas:

• Instalación directa en el sistema backend: En la instalación más sencilla, tanto el servidor de pasarela como el plug-in backend pueden instalarse directamente en el sistema SAP, que debe utilizar al menos la versión 7.0 de NetWeaver. La ventaja reside en los bajos costes. No se necesita más hardware. Dado que el servidor NetWeaver Gateway requiere relativamente pocos recursos, ya se pueden atender muchos escenarios.
• Instalación en un sistema separado: Especialmente si hay más de un sistema backend, se recomienda instalar el Gateway Server en un servidor separado. Aquí se siguen instalando los plug-ins backend en los sistemas SAP. Los distintos sistemas SAP se comunican ahora directamente con el Gateway Server. Los servicios necesarios también se desarrollan en los plug-ins backend en este escenario.

  Esto tiene la ventaja de que la lógica correspondiente se encuentra directamente en el sistema SAP. Esto permite un desarrollo de muy alto rendimiento. Sólo se transfieren al servidor central de la pasarela los datos necesarios.

  Incluso son posibles escenarios más complejos, como la asignación de solicitudes del servidor de puerta de enlace al sistema SAP correcto, si, por ejemplo, existe un sistema SAP distinto para cada región.

  Se puede optar por una arquitectura de este tipo si, por ejemplo, se desea aumentar la seguridad del acceso externo mediante un concepto de defensa por capas. El sistema NetWeaver Gateway también puede instalarse en la zona desmilitarizada (DMZ).

• Sin instalación en el sistema SAP: Las dos opciones anteriores

Las opciones tienen el inconveniente de que hay que instalar software adicional en el sistema SAP. En algunas constelaciones es difícil instalar software adicional, por ejemplo si un sistema ha sido validado según las normas de la FDA.

En este caso, tanto el plug-in backend como el servidor de pasarela pueden instalarse en un sistema independiente. La comunicación con el sistema SAP tiene lugar a través de las interfaces ya contenidas en el sistema, como RFC o BAPI.

Continuará ...