Error al usar servicio Northwind con SAPUI5 - Aprendiendo a buscar errores

La semana pasada, dos lectores comentaron que el ejemplo para crear una aplicación usando el servicio oData de Northwind no funcionaba. La verdad es que el error no era nada intuitivo, "HTTP request failed", así que probé a volver a crear la aplicación a ver qué fallaba. Y, efectivamente, ahí estaba el error.

Por todos los draconianos de Krynn, yo juraría que esto antes funcionaba

¿Qué es lo que podía pasar? ¿Por qué había comenzado a fallar? Había que investigar para descubrirlo.

Aplicación SAPUI5 para ver un PDF: Servicio oData (II)

En el post anterior, nos habíamos comenzado a pelear con la visualización de un PDF, generándolo desde SAP, ya fuese mediante un Smartform, un Adobe Form o la salida de un informe ABAP.

Pero ese PDF en SAP no nos vale para mucho, y para poder mostrarlo en una aplicación SAPUI5 necesitamos exponerlo de alguna forma. ¿Cómo lo vamos a hacer? Pues claro, mediante un servicio oData.

El objetivo final es crear una aplicación de tipo Master-Detail para mostrar un listado de autores en la parte maestra y un PDF con su bibliografía en la parte del detalle. Es ese PDF el que recuperaremos del formulario anterior y exponemos con nuestro servicio.

Así que vamos a tener que realizar los siguientes pasos:

• Crear un servicio oData con una entidad de tipo Media.
• Redefinir el método DEFINE de la Model Provider Class (XXX_MPC_EXT) para indicar qué propiedad será la que identifique el tipo de contenido.
• En la Data Provider Class (XXX_DPC_EXT), implementar el método XXX_GET_ENTITYSET para devolver el listado de autores.
• Si quisiésemos mostrar todos los datos de un único autor (aparte de un empleado), implementaríamos también el método XXX_GET_ENTITY, pero para este ejemplo esto NO lo vamos a hacer.
• Implementar el método /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_STREAM, que será donde devolveremos el contenido del PDF. ¿Y cuándo será invocado este método? Cuando solicitemos una entidad específica, añadiendo la opción $value.

Aplicación SAPUI5 para ver un PDF: Introducción (I)

Una aplicación muy común que nos van a pedir en algún momento, es aquella que nos permitirá visualizar un PDF. Pero no un PDF cualquiera, no, nada de un archivo que hemos creado y colgado en algún repositorio, sino un smartform o un adobe form que ya tenemos en SAP y que queremos mostrar. O incluso algún report estándar que se usa mucho y queremos colgarlo en el portal. Nos puede venir a la mente aplicaciones estándar como la del recibo de nómina (my paystubs), donde vamos a ver las monedas de oro que cobramos mensualmente mediante la visualización de un PDF.

Pues nada, eso es lo que vamos a aprender en esta ocasión, la creación de un servicio oData que nos devolverá el contenido de un PDF y visualizaremos en una aplicación SAPUI5.

Lo veremos en tres post, que son los siguientes:

• En el primero (en este), no jugaremos aún con Fiori. Lo que haremos será generar, en ABAP, el contenido de un PDF en una variable de tipo XSTRING, que es con lo que vamos a trabajar. Para ello, vamos a ver los pasos a seguir para smatforms y adobe forms y haremos un ejemplo más detallado con un report, del que recuperaremos la salida para generar más tarde el PDF. Ojo, que esto del report es sólo para tener un punto de partida, ser tan cutre no debería ser la norma.

• En el siguiente post, crearemos un servicio oData para poner accesible el contenido del PDF: Aprenderemos a usar entidades de tipo "media" y a saber para qué sirve la opción $value, tocaremos la model provider class (MPC_EXT... sí, esa clase que nunca hace falta tocar) y pondremos disponible el contenido del PDF en la data provider class (DPC_EXT) mediante el método GET_STREAM, usando la función que hemos creado en el punto uno.

• En el último post, mostraremos el PDF en nuestra aplicación SAPUI5. Para ello, usaremos un componente de tipo sap.ui.core.HTML, donde añadiremos el código HTML estándar que nos permita incrustar el PDF en la página. La URL a usar será la del servicio oData con la opción $value.

NetWeaver Gateway y OData V4

Hasta ahora, siempre que hemos usado y creado servicios oData a lo largo de este blog, lo hemos hecho en la versión 2, que es la versión que soporta el NetWeaver Gateway 2.0 de SAP. Podemos obtener documentación de esta versión en este enlace.

Pero resulta que OASIS ya hace tiempo que definió la versión 4.0. En general, para nuestras aplicaciones sencillitas, la versión 2.0 nos vale perfectamente. Pero puede que nos encontremos con especificaciones que sólo se cubren con la 4.0.

Pues, por fin, el Gateway ya comienza a dar soporte para esta última versión. En el TechEd, cuando vi que había una sesión al respecto, aproveché para colarme y ponerme un poco al día. Pero como a lo mejor ya nos pilla mal eso de visitar el TechEd, podemos encontrar información en la documentación de SAP y este blog.

Eso sí, tenemos que diferenciar dos formas de programar: Con el nuevo modelo de programación ABAP, basándose en CDS; o de forma tradicional, con lo que parece que llaman el code based implementation. Obligatorio leer la nota 2485370 - "Development of OData V4 services using code based implementation" para saber dónde y cómo podemos desarrollar en cada modelo. 

De momento, sólo he podido ejercer tareas de investigación, no he desarrollado nada porque no he tenido oportunidad, pero bueno, os cuento lo que he ido descubriendo por si a alguno le pica la curiosidad y quiere investigar más, o incluso corregir cualquier tontería que diga.

Primero de Fiori: Los palabros

En los posts que van apareciendo en este blog como por arte de magia, voy mencionando términos de forma espontánea, creyendo que cualquiera que llega aquí los conoce. Pero claro, a lo mejor hay alguien que no sabe ni papa del tema y todo esto le suena a sindarín.

Por eso voy a hacer en este post un glosario de los términos más comunes con los que nos podemos encontrar relacionados con Fiori, para orientarnos un poco si hace falta. Ojo, explicados a mi manera. Así que estamos en el curso de...

Debemos recordar que tenemos tres posibles escenarios con Fiori: El clásico (Fiori instalado en un front-end ABAP), un SAP Portal con el desktop de Fiori (que, por detrás, atacará realmente al front-end clásico) y Fiori en la nube con el portal de SAP Cloud Platform. Algunos de los términos de este post pueden ser técnicamente diferentes para cada uno de estos entornos, pudiendo incluso no existir en algunos de ellos.

Cuidado con lo que envías en el servicio oData

Para la mayoría de los lectores, que ya estarán metidos en materia fiorística (término que, por supuesto, me acabo de inventar), puede que este post resulte más que evidente. Pero quizá no lo sea para aquellos que se acaban de sumergir en esta materia del Gateway, los servicios oData y las aplicaciones SAPUI5.

Y es que gracias a los servicios oData podemos enviar información a nuestra aplicación SAPUI5 y luego allí decidimos qué mostramos o que no. ¡Pero la información se sigue enviando! Aunque no la veamos bien pintadita en la pantalla, podemos descubrir fácilmente lo que se ha enviado sin ser unos genios informáticos. ¡Si hasta yo sé cómo hacerlo! Nos basta con una simple tecla: F12.

Así que, cuando creemos nuestro propio servicio oData (proceso que podemos recordar en este post), sólo debemos enviar aquello que el receptor realmente tenga permiso para leer. La parte web sólo se tiene que preocupar en si un dato se pinta o no, pero no en si tienes permiso o no para recibir ese dato.

Veamos lo que no debemos hacer y cómo descubrir toda la información que se envía, aunque la aplicación no nos lo muestre.

SAPUI5: Mostrar el tamaño de una tabla en el IconTabFilter

Cuando tenemos un IconTabBar con una tabla que recupera datos de un servicio oData y no tenemos ni repajolera idea de cuantas entradas tiene la tabla, queda muy chulo poder recuperar el número de entradas y mostrarlo en el icono donde esta la tabla. De esta manera tenemos una información visual muy útil.

Así que si partimos de una aplicación como la que hicimos en este post, podríamos querer conseguir algo como lo siguiente:

¿Pero cómo podemos obtener y rellenar ese dato?

¡El Gran Circo de SAPUI5 ya está aquí! ¡Pasen y vean, señoras y señores, pasen y vean!

SAPUI5: Crear una tabla (II, tabla enlazada con servicio oData)

En un post anterior, estuvimos viendo cómo funcionan las tablas con un ejemplo sencillo, mostrando datos estáticos. Pero claro, eso no nos vale para mucho. Lo que queremos hacer es mostrar los datos de un servicio oData, obteniendo así una tabla dinámica megachula.

Y eso es lo que vamos a hacer ahora. Partiendo de la aplicación del otro día, añadiremos una tabla que consulte la colección Employees del servicio de Northwind.

Los pasos que vamos a seguir son:

• Modificar la aplicación para cargar el servicio oData. Esto no tiene que ver con tablas, pero nos toca hacerlo.
• Crearemos una tabla que cargue los datos de la colección Employees.
• Modificaremos la tabla para darle formato y que quede más guapetona.

OData Provisioning: Configurar el Gateway en la nube

Hace un tiempo vimos las distintas ubicaciones en las que podíamos tener el Gateway. Una de las posibilidades era tener el Gateway en la nube, y eso lo conseguimos gracias a un servicio que nos proporciona el Cloud Platform: OData Provisioning (a partir de ahora, ODP, para no escribir tanto).

Venga, vamos a pelearnos un poco para ver cómo activamos este servicio. Lo básico, sólo conseguir que nos funcione.

Los pasos que vamos a tener que seguir son:

• Activar el servicio oData Provisioning en Cloud Platform.
• Crear las autorizaciones necesarias para poder administrarlo y usarlo.
• Activar el servicio IWBEP en el back-end.
• Crear un destination que apunte al componente IWBEP del back-end.
• Registrar los servicios oData que queramos utilizar en el ODP.
• Crear un destination que apunte al ODP.
• Crea la aplicación que usará dicho destination.
• Tomarnos unas cervezas para celebrarlo.

Cómo configurar el servicio oData de Northwind

En los post que hemos ido viendo, siempre creábamos un servicio oData en nuestro Back-End. Lo cual es normal, todo sea dicho, ya que estamos aprendiendo a hacer cosas tanto en el Front-End como en el Back-End.

¿Pero qué pasa si no tenemos acceso a un SAP en el que poder hacer nuestras prácticas o que simplemente le tenemos tirria al ABAP y sólo queremos aprender un poquinín de SAP UI5? En ese caso, podemos usar el servicio de Northwind.

Este servicio está disponible en la siguiente URL: https://services.odata.org/V2/Northwind/Northwind.svc/

Hay también una versión 3 y versión 4 de oData, pero para el Web IDE sólo podemos usar hasta la versión 2.

SAP UI5 y oData: Asociaciones, navegación y expand (II, oData y ABAP)

En el capítulo anterior... 

Habíamos estado hablando de lo que eran las asociaciones, la navegación y el expand en los servicios oData. Así, en plan teórico. Y poníamos como ejemplo una posible aplicación para mostrar los personajes de las películas de ciencia ficción.

Esta es la aplicación que queríamos crear... a ver cómo creamos el servicio oData

Pues ahora nos vamos a poner con la parte práctica, vamos a meterle mano a la máquina. Lo primero es crear el servicio oData, y eso es lo que vamos a hacer aquí. En el siguiente post ya lo enlazaremos con la aplicación en SAP UI5.

Si nunca has creado un servicio oData en SAP, quizá te interese revisar este post anterior.

Es importante destacar que la asociación la vamos a crear relacionando propiedades. Esto no siempre es necesario, pero a la hora de codificar en ABAP nos va a facilitar mucho el trabajo. Me dejaré pendiente hacer un post para explicar otra manera de codificar las navegaciones.

Este ejemplo de aplicación hecho en el Web IDE hace los siguientes tipos de llamada, que nos sirve como idea para determinar lo básico que necesitamos implementar.

• Servicio_de_saga/Sagas
• Servicio_de_saga/Sagas('STARWARS')
• Servicio_de_saga/Sagas('STARWARS')/LosPersonajesDeEsaSaga

 Pero nos complicaremos un poco más la vida para obtener más información y aprender más:

• Servicio_de_saga/LosPersonajes?$expand=SuSaga

Los pasos que seguiremos son:

• Crear las estructuras y tablas que necesitaremos, incluyendo datos (SE11 y SM30).
• Crear el proyecto en la SEGW y activar el servicio oData en la /IWFND/MAINT_SERVICE.
• Programar los métodos para permitir la funcionalidad de la aplicación estándar (entidad de saga, entityset de saga y navegación hacia personajes).
• Reprogramar el método que nos permite expandir la saga de un personaje (navegación de un personaje hacia su saga).

Como he metido mucha chicha, siempre podéis leer en diagonal y prestar atención a las imágenes ;).

 

SAP UI5 y oData: Asociaciones, navegación y expand (I, teoría)

Cuando tenemos una tabla sencilla en SAP y queremos mostrar los datos en una aplicación SAP UI5, nos podemos crear una aplicación que consuma un servicio oData sencillito y nos quedamos tan contentos (como podemos hacer viendo los distintos post en la página de tutoriales).

Pero claro, las cosas no son tan sencillas, y seguro que nos toca crear una aplicación que muestre datos de muchas tablas que están relacionadas entre ellas. Manda narices, siempre pidiéndonos cosas complicadas.

Pues para solucionar ese problema, vamos a aprender tres cosas muy importantes en un servicio oData: las asociaciones, las navegaciones y el expand.

Gracias a las asociaciones (y compañía), podremos crearnos una aplicación en SAP UI5 que nos muestre los datos de ambas tablas relacionadas, sin tener que comernos mucho la cabeza para hacer múltiples llamadas al servicio oData y tratar los datos en la aplicación. Con una llamada obtendremos los datos de ambas tablas, de sopetón.

Web IDE: Ver los datos de un servicio oData al crear una nueva aplicación

Con las novedades de Marzo de 2017 del Web IDE, una de ellas me había llamado la atención y, al ir a investigarla, he descubierto la de cosas que se van añadiendo y de las que uno no es consciente hasta que un día tiene tiempo para trastear un poco con ellas.

En este caso, la novedad hace referencia a una mejora a la hora de elegir el servicio oData, cuando estás creando una aplicación SAP UI5 nueva: Poder ver los datos reales.

Pero claro, ya puestos a ver cómo funcionaba, pues he estado revisando lo que ya se podía hacer y que, mísero de mí, desconocía.

SAPUI5, oData y filtros: Consultar sólo los datos que nos interesan (y II)

En el post anterior habíamos creado una aplicación para aprender a usar tanto filtros como selección por propiedades clave. Lo habíamos hecho todo a manubrio, como unos campeones. ¿Pero cómo lo hace el Web IDE?

Vamos a ver cómo se genera automáticamente una búsqueda usando filtros mediante las plantillas del Web IDE y así aprendemos a hacerlo más bonito. Podemos utilizar una aplicación como la que creamos en este post, de tipo Worklist.

SAPUI5, oData y filtros: Consultar sólo los datos que nos interesan (I)

Nos habíamos creado una aplicación SAPUI5 para poder consultar una colección de un servicio oData, y lo habíamos hecho de dos formas: Asignando la colección a un elemento de la vista, como hacen las plantilllas del Web IDE, y mediante el método read del objeto oDataModel.

Pero hasta ahora lo único que hemos conseguido es obtener toooooodo el listado de la colección. Sin embargo, ¿qué ocurre si lo que queremos obtener es sólo una parte de ese listado? Que tenemos que aplicar filtros.

Pues venga, vamos a ver cómo podemos aplicar esos filtros.

SAPUI5: Maneras de cargar un servicio oData y hacer el binding

Gracias al Web IDE de SAP HCP, nos podemos crear una aplicación rápidamente consumiendo un servicio oData sin picar casi código. Tiramos tan pocas líneas, que llega un punto en el que creamos aplicaciones sin saber realmente como funcionan sus tripas, como si fuésemos imperiales del Warhammer 40K.

Así que voy a contar aquí un par de cosas sobre como leer un servicio oData para poder tratar el resultado y como mostrar los datos en la vista mediante el binding. Muy básico todo ello. Si buscas algo complicado... sigue buscando.

¿Intranet inaccesible para el Web IDE? SAP Cloud Connector al rescate (y II)

Como habíamos tenido un problema de conectividad a la hora de consumir un servicio oData desde nuestro Web IDE, nos habíamos instalado el SAP Cloud Connector. Habíamos elegido la versión portable porque los de sistemas no se fían de nosotros y no nos habían dado permisos de administrador en el equipo.

Ahora sólo nos falta configurar la conexión, la cuenta SAP HCP y ponernos a trabajar. Así dicho suena rápido, pero tenéis un buen post por delante ;)

¿Intranet inaccesible para el Web IDE? SAP Cloud Connector al rescate (I)

Resulta que hemos descubierto el SAP Web IDE para desarrollar aplicaciones SAP UI5 fácilmente, y nos hemos ofrecido voluntariamente (como pasaba en la mili) para hacer una aplicación Fiori que lea los datos de SAP.

Nos hemos creado nuestro servicio oData, lo hemos probado mediante el Gateway Client y funcionaba chachi piruli juan pelotilla. Ahora vamos a meterle mano a la parte web.

Así que comenzamos a construir la app, creamos nuestro Destination para apuntar al entorno de desarrollo y... oh, oh, esto no funciona. Comenzamos a cambiar parámetros, a hacer pruebas, a tirarnos de los pelos, pero esto no lo consigue arrancar ni Carlos Sainz.

¿Qué puede pasar? Desde la oficina nos estamos conectando sin problemas con el servidor, pero el SAP HCP no está por la labor.

Lo que ocurre es que tenemos un problema de conectividad: El servidor front-end (y por tanto, el Gateway) no es accesible desde el exterior. Tienen capado el acceso (lo que es normal, todo sea dicho) y sólo los equipos dentro de la intranet pueden acceder. Por eso nosotros podemos (ya que estamos en local) pero el destination no llega (está fuera de la red local).

Acceso al servicio oData desde HCP: Crear destination

Habíamos creado un servicio oData con el Gateway de nuestro sistema SAP y lo habíamos probado con el Gateway Client o haciendo consultas directas en el navegador. ¡Ya estábamos obteniendo datos!

¿Pero cómo vamos a consultar este servicio mientras desarrollamos nuestra aplicación SAPUI5 en el Web IDE? ¿Y si la queremos poner disponible en el portal del SAP HCP? En ambos casos necesitamos una manera de "poner en contacto" la aplicación con el servidor SAP, y eso lo vamos a conseguir creándonos un destination.

Cómo extraer los datos de SAP: Gateway y servicios oData (y II)

Queremos hacer una aplicación megachula en SAPUI5 en plan profesional. Hemos pintado la aplicación (ya sea en una servilleta de papel o en una aplicación de diseño como el BUILD, disponible como servicio del SAP HCP) y luego hemos picado el código con el Web IDE.

Imaginemos que ya tenemos esa aplicación todo pintona, pero sólo nos muestra datos ficticios (el mock data que llaman), que hemos cargado mediante código o leyendo un fichero plano en formato JSON.

Entonces nos preguntamos, ¿cómo hacemos para mostrar datos de verdad? Pues necesitaremos una fuente de la que extraigamos los datos, que en nuestro caso será un servidor SAP. Y como ya vimos anteriormente la teoría (básica, muy básica) de los servicios oData y el SAP NetWeaver Gateway 2.0, ahora vamos a ver si somos capaces de ponerlo en práctica.