Servicio oData (II)

Voy a tratar de explicar un poco más acerca de los servicios oData tras el primer post, donde hice una introducción sobre este protocolo cada vez más utilizado e importante en el intercambio de datos.

En dicho post hacía referencia al EDM (Entity Data Model), este modelo está compuesto por una serie de elementos que vamos a tratar de ir explicando:

• Entity Types: consiste en el conjunto de propiedades que componen un objeto de datos estructurado. Para la gente que viene del ABAP, yo al explicarlo suelo hacer la analogía con las estructuras.

Al final tenemos un conjunto de propiedades (campos en estructuras), de las cuáles unas cuantas suponen la clave, es decir, una forma unívoca de identificar a una entidad. Esos campos claves forman la Entity Key.

• Entity Set: las instancias de los entity types se llaman entidades. Las entidades se agrupan formando un Entity Set, es decir todas las entidades de un EntitySet son del mismo Entity Type.

Para que quede más claro ponemos un ejemplo:

Definimos el Entity Type Producto, que indica que tiene las propiedades Identificador, Descripción y Precio.

La propiedad Identificador compone la Entity Key.

Luego tendríamos las entidades que serían las instancias de ese Entity Type, es decir, su representación real, podrían ser una tablet y un ordenador portátil. Y estas dos entidades juntas formarían una EntitySet, denominado Productos.

• Complex Type: es muy parecido al Entity Type en cuanto que estamos definiendo un conjunto de propiedades que conforman un tipo estructurado. Otra vez volviendo a la analogía con el ABAP, sería parecido a un Include.

Es decir, realmente no estamos definiendo algo con identidad, sino que sería un tipo complejo que se puede utilizar al definir una propiedad compleja dentro de un entity type. El típico ejemplo que suelo poner para entenderlo, es el tipo complejo Dirección, que estaría formado por las propiedades Calle, Población, Código Postal, etc.

Estos tipos complejos no se pueden utilizar en las asociaciones.

• Associations: es como se llama a la relación entre dos Entity Types. En estas relaciones hay que indicar por supuesto las Entity Types involucradas, las propiedades por las que se relacionan y la cardinalidad. Estas asociaciones impactan en los dos sentidos, y la cardinalidad indica si de una entidad de un tipo pueden involucrar a 0, 1 o N entidades del otro Entity Type.

A través de estas asociaciones entre los entity types podemos generar un tipo especial de propiedades que son las propiedades de navegación. Estas propiedades nos permiten acceder desde una entidad a las entidades de otro tipo relacionadas.

En el ejemplo de la imagen tenemos las Entity Types Comedor y Menú, relacionadas por una determinada asociación. A través de esa asociación la entity Type Comedor tendrá una propiedad de navegación (serveMenus) por la que podremos a acceder a todos los Menús que se sirven en ese comedor.

• Function Import: en el servicio oData también podemos exponer funciones que realicen una determinada funcionalidad. Como cualquier función recibirá una serie de parámetros de entrada y devolverá un resultado. Estas funciones se utilizan para complementar a las funcionalidades implícitas que ya nos ofrece el servicio oData vinculadas a sus entidades, es decir, las operaciones CRUD.

Estas funciones se utilizan para complementar a las funcionalidades implícitas que ya nos ofrece el servicio oData vinculadas a sus entidades, es decir, las operaciones CRUD.

Los parámetros de entradas pueden ser de cualquiera de los tipos primitivos del EDM que veremos a continuación, mientras que el resultado puede ser un tipo primitivo, un tipo complejo, una colección de tipos primitivos, una colección de tipos complejos, una entidad o un Entity Set.

Esta Function Import que realiza una determinada reserva recibe dos parámetros de entrada primitivos (Int y String) y devuelve otro valor primitivo (boolean) indicando si la reserva se ha realizado o no.

Es muy importante antes de empezar a programar nada de la aplicación hacer un buen diseño del modelo de datos, ya que va a ser primordial a la hora de abastecer de datos a nuestra aplicación y tendrá bastante impacto en sus posibilidades y en su rendimiento.

Tipos de datos primitivos

Los servicios oData están muy tipificados, es decir, cada propiedad tiene que estar referida a un tipo. Podemos generar nuestros tipos complejos en el propio servicio o referirnos a los tipos de datos primitivos del EDM, como puede ser boolean o String.

A continuación mostramos todos los tipos de datos primitivos:

Con esto doy por concluido este segundo post acerca de los servicios oData, dejando para más adelante seguir viendo como interactuar con el servicio a través de los componentes de la URI, cómo crear dichos servicios tanto en un back-end ABAP como en SCP con la ayuda de los servicios móviles y por supuesto como llamar a estos servicios desde nuestras aplicaciones SAPUI5.

Espero que os sirva.