Una de las funciones básicas de cualquier consulta a base de datos en nuestros SAP ABAP CDS son los Joins. En las vistas ABAP CDS, al igual que en ABAP, tenemos la posibilidad de ejecutar diferentes tipos de joins.
INNER JOIN/ JOIN: este tipo de enlace busca coincidencias entre las dos tablas o vistas enlazadas a través de las columnas que tienen en común e indiquemos en la clausula ON. Este join recuperará solo los datos resultados de la intersección.
LEFT OUTER JOIN: este tipo de enlace da prioridad a la tabla situada en la izquierda del join, buscando en la tabla o vista de la derecha las coincidencias a través de las columnas indicadas en la clausula ON. Encuentre o no coincidencias en la tabla de la derecha, mostrará todos los registros encontradas en la tabla de la izquierda, solo que aquellos campos de la tabla de la derecha que no haya encontrando coincidencia se mostrará como NULL en nuestra vista CDS.
RIGHT OUTER JOIN: este tipo de enlace da prioridad a la tabla situada a la derecha del join, buscando en la tabla o vista de la izquierda las coincidencias a través de las columnas indicadas en la clausula ON. Del mismo modo que el caso anterior, encuentre o no coincidencias en la tabla de la izquierda, mostrará todos los registros encontrados en la tabla de la derecha, teniendo en cuenta que los campos de la tabla izquierda que no hayan tenido coincidencia se mostrarán como NULL en nuestra vista CDS.
Para entender cada tipo de join, vamos a implementar un ejemplo de vista SAP ABAP CDS para cada caso continuando con el ejemplo de vuelos que empezamos en el primer artículo.
En primer lugar, veremos la sintaxis para implementar un INNER JOIN. En este caso, vamos a emplear la tabla SPFLI. La tabla origen, SFLIGHT, nos proporciona información sobre los diferentes vuelos; la segunda tabla, SPFLI, nos indica información del vuelo, tal como ciudad origen y destino, horario, distancia, etc.
@AbapCatalog.sqlViewName: 'ZVEJEMBLOG'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Vista cds ejemplo blog'
define view ZCDS_EJEMPLO_BLOG
as select from sflight as Flight
inner join spfli as Schedule on Flight.carrid = Schedule.carrid
and Flight.connid = Schedule.connid
{
key Flight.carrid as IdEmpresa,
key Flight.connid as CodVuelo,
key Flight.fldate as Fecha,
Flight.price as Precio,
Flight.currency as Moneda,
Schedule.cityfrom as CiudadOrigen,
Schedule.cityto as CiudadDestino,
Schedule.distance as Distancia
}
Lo primero que tenemos que tener claro es la sintaxis. En este caso utilizamos la palabra reservada INNER JOIN seguido de la tabla que queremos enlazar, un alias que representa a dicha tabla y la clausula ON, donde indicamos las columnas por las que queremos enlazar la tabla. Siempre trataremos de enlazar las tablas a través de los campos clave que coexisten en ambas.
Para este código, obtendremos los datos resultado de la intersección entre ambas tablas, es decir, aquellas vuelos que tengan información registrados en la segunda tabla. Aquellos registros que no tengan coincidencias no aparecerán en el listado resultante.
Importante destacar el uso de los alias. No será necesario indicarlo en los campos expuestos , siempre y cuando dichos campos sean únicos para esa tabla. En este caso, el campo CARRID y CONNID coexisten en ambas tablas, por lo que será obligatorio indicar de qué tabla queremos recuperar dichos campos, y esto lo haremos indicando NOMBRE_ALIAS.campo . En este ejemplo, he utilizado para todos lo campos el alias de su tabla para que sea mas representativo.
En segundo lugar, veremos la sintaxis de los otros dos tipos de JOIN que existen. En estos casos, no mostraré los resultados porque para estas tablas de ejemplo en SAP, los registros son exactos, por lo que no tenemos resultado diferente a INNER JOIN. No obstante, como vimos antes, si existiesen más vuelos en la tabla SFLIGHT que datos del vuelo en la tabla SPFLI, con el LEFT OUTER JOIN obtendríamos todos los registros de la tabla SFLIGHT y aquellos campos expuestos para los que no encontrase coincidencias se mostraría como vacío – NUL
@AbapCatalog.sqlViewName: 'ZVEJEMBLOG'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Vista cds ejemplo blog'
define view ZCDS_EJEMPLO_BLOG
as select from sflight as Flight
left outer join spfli as Schedule on Flight.carrid = Schedule.carrid
and Flight.connid = Schedule.connid
// right outer join spfli as Schedule on Flight.carrid = Schedule.carrid
// and Flight.connid = Schedule.connid
{
key Flight.carrid as IdEmpresa,
key Flight.connid as CodVuelo,
key Flight.fldate as Fecha,
Flight.price as Precio,
Flight.currency as Moneda,
Schedule.cityfrom as CiudadOrigen,
Schedule.cityto as CiudadDestino,
Schedule.distance as Distancia
}
Por último, destacar que todos los campos expuestos de las diferentes tablas que intervienen en los distintos tipos de join siempre serán recuperados, sea cual sea la información que solicite el usuario desde la aplicación. Esto es IMPORTANTE tenerlo en cuenta cuando implementemos vistas CDS y queramos obtener un buen rendimiento de ejecución.
Asociaciones
Las asociaciones son un tipo de join, similar al LEFT JOIN, que obtiene como resultado las relaciones entre las tablas o vistas enlazadas. No obstante, existe una diferente VITAL entre un JOIN y una asociación: los campos expuestos resultado de una asociación solo se recuperarán en el caso de que el usuario solicite dicha información desde la aplicación. Esto quiere decir, que si tenemos un informe en Fiori con una variante creada, en la cual, solamente nos interesa 5 campos de nuestra vista CDS y de estos campos, ninguno se corresponde con nuestra asociación, esta no se ejecutará, por lo que optimizamos el rendimiento en función de la información que necesita el usuario.
La sintaxis de las asociaciones es la siguiente:
@AbapCatalog.sqlViewName: 'ZVEJEMBLOG'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Vista cds ejemplo blog'
define view ZCDS_EJEMPLO_BLOG
as select from sflight as Flight
association [0..1] to spfli as Schedule on Flight.carrid = Schedule.carrid
and Flight.connid = Schedule.connid
{
key Flight.carrid as IdEmpresa,
key Flight.connid as CodVuelo,
key Flight.fldate as Fecha,
Flight.price as Precio,
Flight.currency as Moneda,
Schedule.cityfrom as CiudadOrigen,
Schedule.cityto as CiudadDestino,
Schedule.distance as Distancia
}
Para definir una asociación indicamos:
- Cardinalidad: podrá ser 0..1, 0..n o 0.., 1..0 y 1..n o 1...
- Tabla o vista CDS con la establecemos la relación
- Condiciones de la relación en la clausula ON
Tal y como hemos explicado, solo aquellos campos solicitados por el usuario que se obtengan a través de una asociación serán calculados por nuestra vista CDS. En nuestro ejemplo, los campos obtenidos directamente de la tabla SFLIGHT siempre serán calculados y obtenidos por la vista, sin importar si el usuario los ha solicitado para mostrar por pantalla o no. Lo mismo sucede si los campos vienen calculados a través de un join, left join o right join. Sin embargo, los campos obtenidos en la asociación con alias Schedule, se calcularán en nuestra vista CDS solo si el usuario solicita alguno de sus campos (cityfrom, cityto, distancia).
Será importante entonces tener en cuenta este comportamiento de nuestras vistas CDS de cara a implementar vistas más complejas, donde el volumen de información sea extenso y diferentes usuarios puedan solicitar diferente información. Para ponernos en la piel del usuario, en próximos artículos comenzaremos con el desarrollo de nuestra aplicación Fiori básica, a través de las anotaciones CDS correspondiente, nuestro servicio oData y nuestro proyecto en WebIDE.
Podemos complementar la información de este artículo con la indicada en este artículo de los Blogs de SAP, de donde obtuve la información base para construir este artículo.