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.

Qué máquina vamos a necesitar

Para poder trastear con oData V4 en el Gateway y poder programar lo que queramos en ABAP, vamos a necesitar un NetWeaver modernito, al menos una 7.50 con SP04 o un 7.51.

Si nos conformamos con hacerlo en CDS, ya lo podemos conseguir con un 7.50 SP01.

¿Cómo? ¿Que no lo tenéis actualizado en esa versión? ¡Qué contrariedad!

Llegados a este punto, ¡no preocuparse! Podemos echar una ojeada al servidor de demo NetWeaver Gateway ES5, la que podéis acceder siguiendo los pasos de este post: New SAP Gateway Demo System Available. Es básicamente lo que he hecho yo.

Qué cosas interesantes vamos a tener

Un resumen de las novedades son:

• Podremos realizar las operaciones definidas en la V4 que no se podían hacer en la V4. Por ejemplo, poder filtrar los resultados de un expand o incluso anidar expands. Aquí se pueden ver las cosicas nuevas que permite la V4 y que no podíamos hacer con la V2. Podéis probar un poco con el servicio de Northwind, como estos ejemplos:

http://services.odata.org/V4/Northwind/Northwind.svc/Categories?$select=CategoryName&$expand=Products($expand=Order_Details)

http://services.odata.org/V4/Northwind/Northwind.svc/Categories?$select=CategoryName&$expand=Products($select=ProductName)

• Los ficheros JSON serán más ligeros (por ejemplo, reduciendo el tamaño del contenido del metadata), para que haya menos flujo de datos.

• La navegación entre servicios nos permitirá navegar de una entidad de un servicio a la entidad de otro servicio. Estos servicios se agruparían en Service Groups. Esto pinta genial para poder hacer cosas como definir servicios genéricos que puedan reutilizarse desde otros servicios, en lugar de tener que reimplementarlos en cada servicio que hagamos.

• Las clase proveedora de datos (DPC) abstracta cambia y pasa a ser /IWBEP/CL_V4_ABS_DATA_PROVIDER, con quien tendremos que lidiar porque va a ser nuestra superclase.
  
  Esta clase abstracta tiene seis interfaces ... bueno, realmente sólo tiene una, /IWBEP/IF_V4_DATA_PROVIDER, pero a su vez está tiene otras seis, que son las que implementaremos.
  
  Hay una genérica que usaremos para la mayoría de las implementaciones, /IWBEP/IF_V4_DP_BASIC, y luego otras para casos más específicos (operaciones batch, operaciones con media, /IWBEP/IF_V4_DP_MEDIA_RESOURCE, que no está en la documentación, etc.).
  
  Los métodos de estas interfaces usarán dos parámetros para gestionar la información: un IO_REQUEST para obtener los datos de la solicitud; y un IO_RESPONSE para devolverlos.
  
  Una de las cosas a destacar es la aparición de unos flags que nos permitirán saber qué opciones se han solicitado en la query y devolver las opciones que se han ejecutado correctamente: Son los "todo" flags (que obtenemos del IO_REQUEST con un get_todos) y los "done" flags (que devolvemos en el IO_RESPONSE con un set_is_done).
  
  Uf, cuanto trabajo por delante. Ponerse al día con todo esto va a ser más duro que leerse el Silmarillion en klingon.
  
  Por ejemplo, para leer un elemento específico (el equivalente al método GET_ENTITY), podemos usar el método /IWBEP/IF_V4_DP_BASIC~READ_ENTITY, donde haremos algo así:

" Recuperamos los campos clave y las operaciones  

io_request->get_key_data( IMPORTING es_key_data = ls_campos_clave ).

io_request->get_todos( IMPORTING es_todo_list = ls_todo_list ).

" Hacemos el código

...

" Devolvemos los valores y actualizamos la operación hecha

io_response->set_busi_data( ls_datos_a_devolver ).

ls_done_list-key_data = abap_true.

io_response->set_is_done( ls_done_list ).

Si queremos cotillear ejemplos con código...

...podemos ver los de ES5. Sólo necesitamos buscar referencias para la clase abstracta /IWBEP/CL_V4_ABS_DATA_PROVIDER.

En mi caso, estuve cotilleando la clase /IWBEP/CL_V4_SAMPLE_BAS_DATA, aunque en los posts de ejemplo que he ido mencionando usan la clase ZCL_E2E001_ODATA_V4_SO_DATA.

Y qué habrá que hacer con los servicios oData en versión 2

Llegados a este punto, la pregunta será, ¿voy a tener que actualizar todo lo que tengo para ser usado en la nueva versión? No, claro que no, podrás crearte servicios en una versión o en otra, según te interese. Así que lo que ya esté hecho, seguiría funcionando en su correspondiente versión.

Es más, leyendo la nota que mencionaba antes, 2485370, ni siquiera aconsejan usar todavía la V4, sólo si nuestros escenarios lo exigen. Si nos vale con la V2, deberíamos seguir trabajando con ella, pero con el nuevo modelo de programación con CDS en mente.

Y si tenemos que usar la V4 porque no nos queda otra y la salvación del universo depende de ello, la recomendación es usar CDS para accesos de sólo lectura y ABAP de toda la vida para el resto, así como crear la clase proveedora a mano, en lugar de usar la SEGW.