Conozca RAP: defina el modelo de datos basado en CDS – Parte 2
By s4pcademy
¡Bienvenido de nuevo!
En el publicación de blog anterior, cubrí mi experiencia con la creación de un modelo de datos CDS y el llenado de algunos datos. En este post, continuaré con el tutoriales para desarrollar una aplicación Fiori utilizando el modelo de programación de aplicaciones ABAP RESTful. También compartiré conclusiones clave de mi experiencia. definir y exponer un modelo de datos de viaje basado en CDS.
Repasamos el flujo de desarrollo en la introducción de esta serie. En la última publicación, creamos una tabla de base de datos. Esta vez, lo explicaré por mi experiencia al exponer un modelo de datos de viaje basado en CDS para la aplicación Fiori. Lo usaremos para definir el modelo de datos del objeto comercial de viajes y reservas.
Flujo de desarrollo de RAP
Para aquellos que no están familiarizados, CDS significa Servicios de datos centrales. Es la infraestructura de modelado de datos de próxima generación en la plataforma ABAP, que ofrece un enfoque declarativo para definir modelos de datos semánticamente ricos y específicos de dominio. Las vistas de CDS se pueden consumir de muchas maneras, incluso como una fuente de datos para las aplicaciones SAP Fiori, expuestas mediante SAP Gateway en el formato OData. También puede crear aplicaciones de Fiori sobre CDS Views utilizando plantillas de SAP Fiori Elements.
Para obtener más información sobre la vista CDS: https://help.sap.com/docs/btp/sap-abap-cds-development-user-guide/about-abap-cds-development-user-guide
Definición del modelo de datos de viaje basado en CDS
Bien, ¡vamos a cambiar las cosas un poco! Entonces, en este tutorial nos sumergimos en el mundo del modelo de datos de viajes CDS. Comenzamos desafiando el modelo de datos de viajes de CDS. Deberá crear una definición de datos para el objeto comercial raíz de viaje, que es bastante simple. Simplemente haga clic derecho en su paquete y elija «Otro objeto de repositorio ABAP». Y no olvides, como mencionamos en la última publicación, cambiar el sufijo por el que más te convenga.
Modelo de datos para viajes
Nota: Dado que las vistas de CDS son vistas de interfaz (pública), tienen el prefijo I_ de acuerdo con la convención de nomenclatura VDM (modelo de datos virtuales). Además, agregamos el sufijo _M al nombre de la vista en caso de que sea específico para nuestro escenario de tipo de implementación administrada. Para obtener información detallada, consulte: Convenciones de nomenclatura para objetos de desarrollo
Una vez que se estableció la definición de datos, procedí a agregar los componentes necesarios para la asociación, los campos y la semántica de la interfaz de usuario al nodo raíz. El tutorial proporcionó un fragmento de código que reemplacé en el editor. Esencialmente, lo que estamos haciendo es usar la tabla de viajes como fuente de datos e insertar sus campos en la lista de proyección entre llaves. Como siempre, proporcionaré una explicación de los pasos tomados en el código para su comprensión y referencia. Es importante asegurarse de tener una buena idea de la vista de CDS para poder comprender completamente el código.
Modelo de datos de viaje basado en CDS
Explicación del código:
- Este código define una entidad de vista raíz para el objeto de negocio raíz de viaje, denominada “ZI_TRAVEL_M_000” (con “000” reemplazado con el sufijo deseado). Se crea seleccionando datos de la entidad «ztravel_000».
- Las asociaciones se definen en el código CDS para acceder a datos maestros de otras entidades. Estas asociaciones se refieren a entidades CDS en el escenario de la aplicación de demostración. La entidad “ZI_TRAVEL_M_000” tiene una relación con estas entidades y las asociaciones se definen con cardinalidad [0..*]. Esto significa que se puede asignar cualquier cantidad de instancias de reserva a cada instancia de viaje. Él [0..1] indica que puede haber cero o una entidad asociada con cada asociación.
- La lista de selección incluye campos de datos de administración estándar, con anotaciones semánticas para la moneda y campos administrativos para un procesamiento de datos uniforme. Él código de moneda el campo se especifica como un campo de referencia para los campos de moneda Tarifa_de_reserva y Precio total. Él “@Semantics.user.createdBy: verdadero” anotación indica que el campo created_by almacena el usuario que creó los datos, mientras que el “@Semantics.systemDateTime.creationAt: verdadero” indica que el Creado en El campo almacena la hora y la fecha de creación. Las anotaciones de los campos administrativos son necesarias para permitir actualizaciones automáticas de los campos administrativos en cada operación.
Información de elementos de código para definiciones de datos:
Mientras trabajaba en este paso, encontré la ventana emergente Información del elemento y la vista Información del elemento ABAP. Estas pantallas proporcionan información sobre los objetos de diccionario ABAP utilizados en CDS. Esto puede ser extremadamente útil al codificar, ya que proporciona más detalles sobre los elementos que se utilizan.
Puede acceder a la ventana emergente Información del elemento haciendo clic en el elemento correspondiente en el código fuente de CDS y seleccionando «Mostrar información del elemento del código» en el menú contextual. La vista de información del elemento ABAP se puede abrir desde la ventana emergente haciendo clic en el icono «Mostrar en la vista de información del elemento ABAP». Esta vista le permite ver simultáneamente el código fuente de su CDS y la información del elemento relacionado.
Ventana emergente Información del elemento y vista Información del elemento ABAP
El siguiente paso fue activar y guardar el código. Después de la activación, podrá obtener una vista previa de los datos en ADT. Durante mi vista previa de los datos, descubrí varias funciones que se pueden alternar. Por ejemplo, es posible navegar a los datos asociados al obtener una vista previa de las vistas de CDS. Encontré esta característica útil y creo que también podría ser beneficiosa para otros.
Vistas de proyección para viajar
Una vez que definimos el modelo de datos para nuestros datos de viaje, pasamos al siguiente paso de crear una vista de proyección. Básicamente, se trata de un subconjunto de los campos del modelo de datos de viajes que se consideran relevantes para nuestra aplicación de reserva de viajes. Nos sumergiremos en la creación de la vista de proyección, siguiendo el flujo de desarrollo a continuación.
Flujo de desarrollo de RAP
En este paso, creamos una vista de proyección definiendo una definición de datos. Los pasos son similares a los que seguimos cuando creamos el modelo de datos para viajes. El proceso involucró hacer clic derecho en el paquete y seleccionar «Otro objeto de repositorio ABAP». La convención de nomenclatura para la vista de proyección sigue el modelo de datos de SAP S/4HANA, comenzando con el espacio de nombres y una letra «C» mayúscula seguida del sufijo «_M» para indicar que es específico para el escenario de tipo de implementación administrada. Por ejemplo, llamamos a nuestra vista de proyección “ZC_TRAVEL_M_000” y proporcionó la descripción «vista de proyección para viajar». Es importante tener en cuenta que la vista de proyección es un subconjunto de los campos del modelo de datos de viaje que son relevantes para la aplicación de reserva de viajes.
La nueva definición de datos apareció en el editor y reemplazamos el código con el fragmento de código del tutorial. Comprender el código y su propósito es importante para poder usar de manera efectiva la vista de proyección en su aplicación. Es por eso que proporcionaré una explicación del código para que pueda tener una comprensión clara de lo que hemos logrado en este paso.
@EndUserText.label: 'Travel projection view - Processor'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@UI: {
headerInfo: { typeName: 'Travel', typeNamePlural: 'Travels', title: { type: #STANDARD, value: 'TravelID' } } }
@Search.searchable: true
define root view entity ZC_TRAVEL_M_000
as projection on ZI_TRAVEL_M_000
{
@UI.facet: [ { id: 'Travel',
purpose: #STANDARD,
type: #IDENTIFICATION_REFERENCE,
label: 'Travel',
position: 10 } ]
@UI.hidden: true
key mykey as TravelUUID,
@UI: {
lineItem: [ { position: 10, importance: #HIGH } ],
identification: [ { position: 10, label: 'Travel ID [1,...,99999999]' } ] }
@Search.defaultSearchElement: true
travel_id as TravelID,
@UI: {
lineItem: [ { position: 20, importance: #HIGH } ],
identification: [ { position: 20 } ],
selectionField: [ { position: 20 } ] }
@Consumption.valueHelpDefinition: [{ entity : {name: '/DMO/I_Agency', element: 'AgencyID' } }]
@ObjectModel.text.element: ['AgencyName']
@Search.defaultSearchElement: true
agency_id as AgencyID,
_Agency.Name as AgencyName,
@UI: {
lineItem: [ { position: 30, importance: #HIGH } ],
identification: [ { position: 30 } ],
selectionField: [ { position: 30 } ] }
@Consumption.valueHelpDefinition: [{ entity : {name: '/DMO/I_Customer', element: 'CustomerID' } }]
@ObjectModel.text.element: ['CustomerName']
@Search.defaultSearchElement: true
customer_id as CustomerID,
@UI.hidden: true
_Customer.LastName as CustomerName,
@UI: {
lineItem: [ { position: 40, importance: #MEDIUM } ],
identification: [ { position: 40 } ] }
begin_date as BeginDate,
@UI: {
lineItem: [ { position: 41, importance: #MEDIUM } ],
identification: [ { position: 41 } ] }
end_date as EndDate,
@UI: {
lineItem: [ { position: 50, importance: #MEDIUM } ],
identification: [ { position: 50, label: 'Total Price' } ] }
@Semantics.amount.currencyCode: 'CurrencyCode'
total_price as TotalPrice,
@Consumption.valueHelpDefinition: [{entity: {name: 'I_Currency', element: 'Currency' }}]
currency_code as CurrencyCode,
@UI: {
lineItem: [ { position: 60, importance: #HIGH },
{ type: #FOR_ACTION, dataAction: 'acceptTravel', label: 'Accept Travel' } ],
identification: [ { position: 60, label: 'Status [O(Open)|A(Accepted)|X(Canceled)]' } ] }
overall_status as TravelStatus,
@UI.identification: [ { position: 70, label: 'Remarks' } ]
description as Description,
@UI.hidden: true
last_changed_at as LastChangedAt
}
Explicación del código:
- @UI: especifica los atributos de la interfaz de usuario (UI) de la entidad de vista, incluida la información del encabezado, la visualización de elementos de línea, la identificación, el campo de selección y la visualización de facetas.
- @Search.buscable: verdadero habilita la búsqueda de texto completo, haciendo que la entidad se pueda buscar
- @Search.DefaultSearchElement habilita la búsqueda de estilo libre para las columnas de vista
- agencia_id como ID de la agencia: se utiliza para almacenar el ID de la agencia y se define como ID de agencia. Él @Consumo.valueHelpDefination La anotación especifica que se debe proporcionar una ayuda para el valor para este atributo y la entidad que se utilizará para la ayuda para el valor es /DMO/I_Agencia y su elemento local es ‘ID de la agencia’. Él @ObjectModel.texto.elementoLa anotación t especifica que el texto que se muestra para este atributo es ‘Nombre de agencia’
- fecha de inicio como Fecha de inicio y fecha final como Fecha final: Él fecha de inicio y fecha final El atributo se utiliza para almacenar la fecha de inicio y finalización del viaje.
- Precio total como Precio total: Este atributo se utiliza para almacenar el precio total del viaje. Él @Semenatics.amount.currencyCode La anotación especifica que el código de moneda debe usarse para este atributo.
- estado general como Estado de viaje: Este atributo se utiliza para almacenar el estado del viaje (Abierto, Aceptado, Cancelado). Las anotaciones de la interfaz de usuario especifican su posición, importancia y etiqueta en la interfaz de usuario.
Definición de servicio y enlace de servicio
El siguiente paso del tutorial fue crear el servicio OData y obtener una vista previa de la aplicación. Este es un paso crucial, ya que da vida a nuestro modelo de datos de viajes y vista de proyección al permitir que aplicaciones externas accedan a ellos y los consuman. Al crear el servicio OData y obtener una vista previa de la aplicación, podremos validar la corrección de nuestra implementación y asegurarnos de que todo funcione como se esperaba.
La definición del servicio describe el alcance del servicio OData, mientras que el enlace del servicio lo conecta al protocolo OData como un servicio de interfaz de usuario.
Para obtener una vista previa de la aplicación, abra la Vista previa de la aplicación Fiori Elements haciendo clic derecho sobre ella en el explorador de proyectos y seleccionando la opción «Abrir vista previa de la aplicación Fiori Elements» en el menú contextual. Esto le permite ver cómo se ve y funciona su aplicación antes de implementarla.
Luego verá la aplicación de informe de lista de viajes. Solo un aviso, una vez que abra la aplicación de informe de lista de viajes, no olvide presionar «VAMOS» para cargar los datos de back-end. Me quedé atrapado allí por un tiempo, así que no te preocupes, ¡te tengo cubierto!
En esta publicación de blog, lo guío a través de los pasos del tutorial para definir y exponer un modelo de datos de viaje basado en CDS. Repasamos los códigos que se proporcionaron en el tutorial y aprendimos sobre la definición del servicio y el enlace del servicio. Luego hicimos una vista previa de la aplicación de elementos SAP Fiori en ADT. En la próxima publicación de blog, crearemos una definición e implementación de comportamiento para un escenario administrado.
Publicación de blog anterior:
Conozca RAP: Introducción
Conozca RAP: Definir modelo de datos – Parte 1
